For all my projects, I have always needed three plans.
Why three?
The first is the plan on a page. This one gets used for most reporting and is waved about at project board meetings. The trick with this one is prudence. Only put essential information on it as the more there is, the harder it is to understand. IT consultancies are masters at producing incredible plan pictures that look good, but nobody has a clue what they mean. The things a one page plan should highlight are:
- The key sequence of events (e.g. sprints or phases to a release)
- The key milestones (especially the customer's deliveries1)
- The range of possible release dates (never give a single date2)
The plan needs to be quick and easy to update, so you always have the latest version handy. I find a spreadsheet is good for this. You can use the grid lines to line everything up and then turn them off to look good.
Copy the area needed and paste it as a picture into a slide or document. Always send out your plan as a picture or PDF so people can't fiddle with it.
I have wasted too many hours messing about with boxes and aligning them when doing it directly in a slide software (like PowerPoint). Even worse, if the receiver has their slide size set differently, it royally screws it up.
The second plan is the detailed plan, created in suitable project planning software3. The trick with this one is getting the level of detail right. Too much, and maintaining it becomes a cottage industry. Too little, and important dependencies and schedule risks will be missed. A rule of thumb is to be able to allocate all the resources and have enough detail that it could generate an accurate budget. Also detailed enough to see the impact of adding people's holidays or sudden absences. It doesn't need to go into infinite detail, but enough to feel confident about achieving deadlines. For agile projects, you can roughly pencil in what could go in which sprint and the sequencing of backlog items. A sort of sketched out version of the product backlog. This plan is never shared. The detail would allow people to pick holes, get unrealistic expectations, or have some genius of a manager take the contingency away. It is your private master plan to rule the world. Look after it.
The third plan is the team plan. For a very short horizon, it details what everyone is doing. In Agile, it is the sprint backlog and the burn down chart. In Waterfall, it is a day-by-day team plan.
It is detailed enough to identify within a day, at most, that the plan is drifting. Projects don't overrun because of big delays but from the cumulative effect of lots of little ones4. Slippage must be jumped on immediately and only detail will identify when a tiny slip is happening. This can be as trivial as a delayed meeting or a short network outage slowing work down. Time lost is never recovered unless you work longer hours and you probably do that already. With the amount of change that goes on in a project, a horizon of over two to three weeks is pointless, something Agile projects have recognised for ages.