Maltpress

How to buy your website, part VII – managing a web project

Cripes. Seven whole parts. We’re in deadly sin territory, here… and today we’ll be discussing how not to sin with your project management! Ha ha ha ha I’m so clever. Anyway, if you’d like to see all the earlier parts, click here – and you can also sign up to the mailing list for future updates, in particular when this whole lot is edited into a proper e-book guide.

So, you’ve found your team, they’ve got the briefs and are working on creating you the website you need. Brilliant! Time to sit back with a book and a biscuit and wait for it to be done, right?

Well, possibly – if you’re confident that you’ve got a decent project manager working for you. If, however, you’re working with a couple of freelancers – a freelance designer and a freelance developer – then maybe you’ll not be so confident. It’s very easy for projects without a strong lead to stretch on and on, so today we’ll discuss some of the things you can do to avoid that.

One of the other problems you might come across without good steer is that you feel out of control. This can happen with a project manager in place, too; you’re investing a lot of money into this website, so you want to know exactly what’s happening with it, and when you don’t get constant email updates you start to worry. The problem with this, of course, is that if you start bothering your project manager (or the people on your team) constantly, they’ll very rapidly get very annoyed and possibly stop talking to you. We’ll deal with that next time, I’m afraid.

This time, though, it’s a bit theoretical – how do you plan a project, making sure you know what steps should happen when? What does your project manager actually do?

What a project manager does

A project manager makes sure a project hits budget, deadlines, and expectations. Simple as that. Give a project manager the functional specification and your agreed deadline, and you should get your project when you expect it – or at least a damn good reason why not. Good project management is not something which is forced on the people doing the “actual” work (the developers and designers) – it’s not about setting them tasks and holding them to account if they’re not done. It’s about finding out the steps they need to take, and how you as project manager can make these happen. Find out what they need, and make them happen. A good project manager is more like a project concierge – removing obstacles for the people doing their jobs so they can concentrate on what they’re good at.

How do you do this? A variety of ways, of course – different project managers have different techniques – but here’s how I do it:

The Gantt Chart

Ah, the Gantt. The bane of a project manager’s life. Many swear by them; many swear at them. So what is it, and how is it actually useful?

Well, a Gantt – in simple terms – is a visual representation of stages in a project, how long they take, and what job depends on what. The simplest can be done with pen and paper or in Excel (or other spreadsheeting software) using coloured cells. Complex ones can be done in MS Project (not an out-of-the-box Office product, sadly), or (my favourite) OmniPlan for the Mac, or there are lots of open source possibilities.  I’ve not tried any of these, though. Let me know if you have.

Now, you can do long courses on getting the most out of this kind of project management, or you can do what I do and use it in a nice, simple way. It’s something wonderfully visual and putting together your Gantt is one of the most useful things you can do just to get your own head around what’s involved.

Start off by listing all the steps in the order you think they should be done. You can use your functional spec and just list the functions here; or work with your developer to break it into the logical steps they might take. For example, you may have a calendar, blog, and shop on your site, and list them like that. You could also break these down into common tasks, like set up database, code back-end, code front-end… think about who this project plan is for, whether it’s your technical team or you (or the client).

Next up, assign durations to each of the tasks. Remember – this project plan needs to be created with the people doing the work. You can’t tell a developer something will be done in a week if you don’t know, for certain, that it will take that long. Also be realistic – remember the difference between billed time and working time. A 3-hour job might need to be done over 3 days if – for example – we’re working with DNS or getting approval for some online service. At the moment we’re not, however, trying to be too accurate; roughly assign days and half-days to tasks, and set milestones (steps which don’t actually take any time, such as “release to client”).

Now you can think about the most important part – dependencies. If you’re a chemist or biochemist, you should be familiar with the idea of the “rate limiting step”: the bit of a reaction which slows all the other bits up. This is kind of what we mean by dependencies – which bits must be done before we can do the next bit. Let’s use making a cup of tea as an example.

If I’m making tea, I have the following steps: add milk, add sugar, add teabag, boil kettle, add hot water, stir, remove teabag, drink.

Of course, we can’t do all of these things at the same time. But we don’t have to do each in turn, and there might be a logical order we can do these things. So let’s start by thinking of the things which are dependent on each other:

• Before we can remove the teabag we must add the teabag. We should also have added hot water and stirred.
• Before we can add hot water we must boil the kettle.
• Before we stir we should have added the teabag, sugar and milk.
• Before we drink we must have done all the other tasks.

So you can see dependencies starting to form here. You’ll also notice that some things are “shoulds” and some are “musts” – they don’t teach you about this on project management courses, but it’s real life. You can make a cup of tea – a very weak, horrible one – by steeping the tea in the milk, stirring, removing the bag and then adding the hot water. Bleurgh! But it is possible. It’s the same with a web project. You shouldn’t – really – build a website before you have an idea of the content or structure. But it’s possible, if circumstances force it.

Anyway, what you do end up with after linking up all the dependencies is that nothing needs to come before putting the teabag, milk and sugar in the cup; also, nothing needs to come before turning the kettle on. You could wait until the kettle has boiled to put these things in the cup, or you could do these and then put the kettle on. But then you’re sitting idle while the kettle boils.

So the logical way to do it is to turn the kettle on, and then while it’s boiling, do all the other tasks which don’t yet have dependencies which are not yet complete. Turn the kettle on, put the stuff in the cup, and then do the rest.

It’s exactly the same with a website. You could – and, if one person is doing it all, might have to – do all the tasks one after another. But you could, while your designer is busy pushing pixels, have your developer start on the back-end while you start writing the copy (which should always start earlier than you think as it takes twice as long as you’ll ever imagine and will always be the thing which holds up a project…). Front-end development is always going to be dependent on design being finished to some extent. But could you have a certain sub-page designed after the build has started? Could your developer be putting together a bit of functionality without design? A good site keeps design and content separate anyway – so there’s often no reason why not.

After you’ve got your Gantt, it just remains to get your developer to agree a start date, add in any time they know they’ll not be available, and make sure they’re agreed (in writing) that certain milestones can and will be met at certain times.

That sort of stuff is pretty logical and you should have thought of most of it already. But here’s something else to think about: for how much time do you let your team go “fallow” on a project? What I mean is, let’s say your designer has said it’ll take three weeks to get his bit done, and your developer has said he can start doing back-end setup right away and it’ll take two days. Do you set them off together? Maybe, but bear this in mind: your developer works for two days on a project then doesn’t look at it for over two weeks. Then the designs arrive and he needs to quickly get back up to speed again (having been off doing another project). Would it be better for the developer to start in week three – when the designs are nearly done – so he can have a straight run through his work in one block? Knowing the developer mindset, and the best way to code, yes it would. Think carefully when putting together your Gantt about using solid blocks of time where possible, rather than have someone on-and-off a project over a protracted period.

Helping to do the do.

Finally, the project manager needs to clear the way for these tasks to be undertaken as efficiently as possible. This might be a case of arguing with other project managers about who gets what resource (developer), and when; it might be a case of doing some of the dull jobs like data entry, or finding someone else to do them. You may need to source holding servers, or chase API keys, or any number of any other little jobs which take time, distract from coding, and might rely on a bit of diplomacy, tact, or low boredom thresholds.

Put it all together…

…and here’s what you need to do, step by step:

• Check the functional specification for what’s required from the project.
• Talk to each supplier about what they’re producing – design, front-end, back-end, copy. See what they need to be done before they can start. Draw up a Gantt without any dates on it.
• Check your Gantt with suppliers in terms of dependencies to make sure you’ve got it right. Get an idea of start times and holidays they might be taking. Some freelancers will work weekends too. If you are a freelancer, never agree to do this, or it becomes expected of you. If you do and you get it done early, great… remember the Scotty Principle.
• Finalise your Gantt by adding dates. Get agreement from each of your suppliers that they can and will finish each stage at a particular date, and let them know you need to know if this isn’t going to happen before the date it’s due. Tell them you’ll be after a weekly update email – even if it’s just “all on time” – and that you’ll remind them of this each week. If you’re reporting to someone else, make sure you summarise these emails to that person so they know what’s happening as well.
• Don’t hide, or hide from, problems and delays. Remain transparent. Tackle issues early. Stuff goes wrong all the time with every project. A good project manager is not one whose projects all run smoothly (because that’s impossible), but is one who solves problems, faces responsibility, takes all the blame and none of the glory but who goes home knowing that without them the project would never have been finished. Project management is not a popularity contest, to use a terrible cliche.
• Find out what each supplier needs in order to finish their tasks, and make it happen as soon as you can. Never leave anything until the last minute. You should always aim to finish projects early, just so you never finish one late.

Next time I want to talk about enacting the plan, which should be a bit more useful to buyers, because we’ll be discussing things like keeping track of milestones and how best to chase. In the mean time, anyone used any open source project planning software? Leave me a comment!