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?
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:
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:
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.
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.
…and here’s what you need to do, step by step:
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!