When any project – large or small – gets done, it gets done because a sequence of jobs is carried out.
Determining the sequence of these jobs after the completion of a project is sometimes called a ‘project postmortem’.
It is also often known as a ‘disaster’!
Figuring out the sequence of jobs as you go along is called ‘firefighting’.
Figuring out the sequence of jobs before you start is called ‘planning’.
If you want to estimate anything accurately, the following method will do it for you:
Build the plan with the project team.
Get the team that is going to do the project – the people with specialist knowledge – to build the plan.
If that’s not possible because they haven’t been identified, assigned or hired yet, get somebody to help you by looking over your plan after you’ve finished it.
And when I say ‘look over’, I mean a line-by-line review.
You’ll be grateful for this when you go to sell your plan to your stakeholders, secure in the knowledge that you haven’t made silly mistakes in your estimates – for example, mixing up duration and work or not doing the arithmetic correctly.
Figure out the big chunks or phases.
If we think of a project as a journey to a destination, then the next step is to figure out the big pieces of the journey – the big chunks of stuff that have to be done and that get you from the start to the end.
Figure out the little jobs.
For each big task, break it down and figure out the little jobs that will make up that chunk.
If you’re wondering how little is ‘little’, then each little job should be between half a day and five days’ duration, or half to five person-days’ work. (While there are exceptions to this – for example, many military operations are planned down to the minute – this ‘half to five days’ rule should work for most of the kinds of things you and I do.)
Say what you mean and use simple language.
For each little job that you identify, say exactly what that job consists of.
Don’t use complicated or fancy-sounding words and phrases.
The advice I give on my training courses is to write the plan so that a ten-year-old could understand it.
Use knowledge and assumptions.
The problem in project management is that we never have enough knowledge about the project while it’s in progress – we don’t know all the facts.
The only day we know all the facts is the day that the project ends, and they’re no good to us then – it’s over.
For this reason, we need to use assumptions when we don’t know the facts.
These assumptions become a central part of the plan, meaning that if any of them turn out to be false, the resulting changes can be treated as big changes.
Use cause and effect.
Little jobs don’t exist in isolation.
As soon as we write down one job, it triggers other jobs.
So, the question we need to keep asking ourselves here is, “What happens next?”
By repeatedly asking this question, we build unbroken chains of small jobs that take us through from the start of the project to the end.
Whenever we come to a piece of the project where we don’t have the necessary knowledge, this is no problem!
We make an assumption – we gather the missing information and document it.
Then we continue building unbroken chains of little jobs that take us from the start of the project through to the end.
Store all of this information.
Next, we list all this information in what’s known as a ‘work breakdown structure’ or WBS.
This is nothing more than a structured list showing: the name of the project, how the project is broken down into big jobs how these big jobs are broken down further, through as many levels of detail as we need until we get to the half-day to five-day level of detail.
Represent it all in a Gantt chart.
Finally, this information is often represented in a Gantt chart.
A Gantt chart typically shows: the WBS down the left-hand side the durations of jobs, mapped onto a calendar on the right-hand side between these two, a number of columns showing things like work, duration and dependencies.