Like a piece of machinery, plans need a good design, room to breathe, and good maintenance…
I attended an APM presentation on the role of the dedicated Project Planner, part of a series given by Andrew Jones, who at the time worked with Athena Project Services.
His presentation contained several key points that resonated with me and so I thought were worth restating in the light of my own experience.
- Estimates need to have a solid foundation. No, a finger in the air won’t do here. Base your estimate on a similar project that was done recently. Base it on productivity figures and lines of code. Base it on PERT or three-time estimating if you like, but be comfortable with how you derived it and have at least some idea of the potential error margin. I have used all of these estimating techniques at some time or other, and knowing the likely accuracy at least gives you a guide for how much contingency to build in, which brings me to…
- Build in some contingency. A knotty one, this! In most plans where I have explicitly built in contingency, I have been required to remove it to reduce timescales. In most cases, of course, something has then happened to increase the project timescales, and the final delivery has ended up where it would have been with contingency in place, except that the project is now Late. No wonder project managers are tempted to build in “secret” contingency, and deliver on time?
- Update the plan with actuals (durations, costs, etc,). This is essential for keeping your schedule on the right track. If a task was late due to a delay, add in a task showing this delay and label it accordingly. The schedule then acts as an audit trail for delivery. If any of the tasks are repeated, use the actuals from iteration 1 to refine the estimates for iteration n. Follow through and see what the impact is on delivery. I have found it is very difficult to get people to care about activities once they’re complete, but this approach does mean that you can apply your learning from the past to the future, and best of all this happens while the project is still running.
- Manage the Critical path. Make sure you make good use of dependencies, and as little use of time constraints as possible. I always do this as much as possible, as it enable you to see the effect of any changes on the critical path at the touch of a button. The plan should be a useful mathematical model of the project, not just a pretty picture on the wall of some coloured bars linked together.
- The act of developing the plan is as important as the plan itself. Or perhaps more important! Thinking through the steps in detail, rehearsing the project in the team’s collective mind, is a great way of identifying potential pitfalls and managing them while they are still risks, if appropriate.
What are your experiences? Do you agree with Andrew and me? Do you have any planning tips you would like to share?