McFilter

Why we plan

To put a stake in the ground. Pick a date, it might be defined by your customer, or as a useful date by the industry (you want to get it out to the public in time for Christmas), or just to set a point to aim at.

If you don't have a target, how will you know when you've achieved it? And it's a very good way of motivating you to get things done - "I've realised we haven't got much time to fit all this stuff in".

So then you take your first guess ('cos estimates aren't really very accurate when it comes to software, IME) and map things out roughly. You should split the project into a number of milestones, putting the most important things into the earlier milestones, and resisting the "we'll do that first 'cos it's easy" trap. If it's important and easy, then cool, but it's the important bit that's important :-)

The plan for the first milestone should be the most well defined, purely because that's what you're going to do first, so you best know how you're going to approach it. You'll re-plan towards the end of each milestone (and you may have to replan during a milestone) anyway, so you'll refine what the future milestones' plans look like then.

Then you track the plan. This is pretty much the only reason that you've done any planning!

Identifying where you're going wrong is a useful side-effect of the tracking, but the aim isn't to use the plan to beat developers up for not achieving what they said they'd achieve at the start. Let them use it to learn how to make better guesses, and I suppose you can use it as back-up evidence if someone isn't pulling their weight, but failure to meet some plucked-out-of-the-air figure isn't a true test of whether someone is pulling their weight.

The reason you track the plan is so you can notice as early as possible that you aren't going to make the end date (in theory it's possible that you'll notice you're going to finish early, but I think we usually try to fit too much in, rather than the other way round). You want to notice this so that you can take some action to keep the project on track. Now, this action will depend on what you're aims are.

If the functionality is set in stone, then your action will be to come up with better guesses for when you'll be finished, and communicate them to the interested parties.

It might also be possible that you can get some extra manpower to help address the slip. However, the tasks that you farm out to fresh blood need to be pretty self-contained, and you have to be able to parallelize them with what else is going on, and there needs to be time to get the new person up to speed with the project. All of which is harder than it would first appear, but that just means that it's even more important to realise you have to do it as soon as possible.

Usually, the end date is the important thing, so you need to work with the interested parties to decide which bits of functionality you're going to cut. This is why you loaded the important things to the start of the project - to keep to the milestone date you might push some of the work from this milestone into the next one, and that will cascade through to push something out of the project completely. This means that some less important stuff gets dropped from the final deliverable, but this is a good thing. The initial requirements will have included a bunch of things that weren't really requirements, they were just nice to haves, and being date-driven is a good way to flush some of that stuff out.

We plan so we can ship. Useful software, sooner.