Since moving away from hands on project management a couple of years ago I’d forgotten some of the trials and tribulations of getting sites live to agreed timescales. These were brought back to me recently as we put two sites live for one client within a couple of days of each other.  Having been a project manager for a number of years the experience of old soon came rushing back. The most important thing during the pressurised time of go-live is communication. Therefore having the right communication tools in place is essential to delivery.

The skill of the PM is ensuring that the communication is clear, agreed and documented, giving the client confidence in the delivery team and protecting the agency against any last minute scope creep.  So to aid communication we use an issue tracking tool called JIRA which made tracking issues and client feedback through project delivery straight forward.

Both Steve and I have used JIRA before at previous agencies and always sing its praises. Whenever a new project starts we setup a JIRA account giving all stakeholders access to the project. Clients can login, report and prioritise any issues they find on designs, prototypes and acceptance sites with accompanying screen shots and notes. The issue entry is done through a really simple user interface and the issue is stored in a central repository where the PM can assess and assign it to the relevant resource. The development resource can put time estimations against each issue as it is assigned and associate it with a particular release of the code. This allows a development roadmap to be created, clearly articulating which bugs and issues will be fixed in which realises and by when.

The other really nice thing about JIRA is that it allows release notes to be exported, listing all the changes within any release, making it easy to identify which code areas might cause any subsequent problems.

This tool is definitely worth considering if you’re currently struggling with spreadsheets and emails containing feedback from clients.  It will give your clients (and you as a PM) confidence that all feedback is being worked on and will save you time on the phone explaining where you are within the development plan.

One of the things I really want to make sure we do at Gibe is make sure we're writing great code. I don't want any buggy as hell, written by developers a couple of weeks before go live who are doing 14 hour days, barely tested, held together by blind luck and duct tape, we'll fix in the mythical phase 2 code. A quick indicator of the likely quality of code a team is putting together is where that team's company scores on the Joel Test (if you've never read anything on that site have a browse, he writes some great stuff). Over the next few months I plan on keeping a log of where we are on the test with an aim of getting 10 points covered pretty quickly, and then working on the next couple as we grow. Our main objective is to come up with a great place to work, and an environment that is condusive to getting things done. Something that is hard to actually achieve based on previous places I've worked. Basically trying to be the opposite of Initech in Office Space.

This may seem silly as our development team consists of me and a loose knit group of freelancer/contractors. That might be true but we plan on adding at least one developer to the team fairly soon. I think as the team grows it'll be easier if most of these things are in place so that's just the way it is rather than letting them get used to one way of working and gradually switching it over the next couple of months.

So where are we on the test currently? Lets have a run through

1. Do you use source control?

Definately one of the most important items on the test, if you are writing software you must have source control. We use Subversion, and I've used CVS it's not as good but works reliably. I've also heard good things about Mercurial.

So that's 1 point.

2. Can you make a build in one step?

I'm going to put Finalbuilder and the Finalbuilder server in place to do this. Finalbuilder is great, it comes with tons of built in taskts support for doings stuff like checking out of source control, copying, uploading, testing, pretty much anything you can think of. And the server lets you trigger these builds through a website. The plan is to be able to deploy any site we've developed in pretty much one click and it'll make sure the right web.config goes up etc. Basically it'll eliminate most of the chances of someone forgetting a step when uploading and breaking a live site.

Not yet, but is coming, 0 points.

3. Do you make daily builds?

Nope, 0 points.

4. Do you have a bug database?

Yes, we're using Jira. I've tried Fogbugz and Bugzilla and always come back to Jira, it's got a nice interface and does everything we need. Our clients get access to Jira so they can report issues straight in and then see what's happening with their issues.

1 point.

5. Do you fix bugs before writing new code?

Yes we definately make sure we're getting the bugs out of way before we start adding new features, seems crazy to build on top of known buggy code.

1 point.

6. Do you have an up-to-date schedule?

Yes, definately, 1 point

7. Do you have a spec?

Yes, We write specs for pretty much everything we do, even if it's just being used internally.

1 Point

8. Do programmers have quiet working conditions?

I'd say yes, we keep the office mostly quiet with just a little background music. 

1 Point

9. Do you use the best tools money can buy?

This one is tricky, we definately get the best kit we can afford, but it's not quite the best money can buy. I think quad core, 8Gb of RAM and dual widescreen monitors is pretty close to the best you can buy. 

The plan is to get the best we can afford, we're a startup and not made of money. That said, on Joel's point about not torturing your employees, I've worked for fairly large agency where there was a fortnightly email that went round complaining about the quantity of milk being consumed, and that someone is using the office milk for their cereal. This was never going to aid morale or give anyone that feeling of being valued, when you get moaned at about an additional £5 of milk each week.This was particularly demoralising when the suspected cause of the additional milk usage was that half the employees had been donating an additional 3 hours plus each night for the last couple of weeks to get a new site out of the door!

1 Point

10. Do you have testers?

Not full time, we swap code internally and test as thoroughly as we can, but we don't have dedicated testers yet.

0 Points.

11. Do new candidates write code during their interview?

Yes candidates will have to write code in their interviews, I've also been looking at doing an online test to send to potential candidates to screen them initially. Think I'd have to make the time quite tight for the test as they'll have access to Google.

1 Point 

12. Do you do hallway usability testing?

At the minute I'd say no, although we do work with Usability experts for some of our sites. It should be as simple as mailing round a link and getting everyones feedback so this is something we'll definately implement pretty quickly.

0 Points.

So that's 8 points so far, not bad, and I think we should be able to add a couple of points on pretty quickly.