No battle plan survives contact with the enemy – Helmuth vonMoltke
Project plans, to me, are a rough estimate of what the project team thinks should be done to get from point A to point B. It’s a living document, not carved in stone.
In my experience, the real value in the project plan is in getting the steps and “to do” list out of people’s heads and onto paper.
Once I have that “paper” (or, in many cases, a computerized project plan), I can:
- Identify the “next step”
- See whether we are getting closer to Point B
- Surface potential resource issues and bottlenecks
- Surface potential timing issues within and between tasks
- Evaluate the impact of changes to the environment to the project (such as key resources getting pulled away for other priorities)
- et cetera (add your favorite benefit of tangible plans here….)
Project execution, in my experience, will then validate whether each task is necessary, whether we accurately estimated the time to complete each task, whether the order of the tasks is correct, and whether we captured everything that needed to happen.
Each “miss” we capture in the plan is more information for the next time.
Or, if there isn’t a next time, we can use it for something similar.
Or at least to see trends, such as regularly underestimating the amount of time it takes to build a report because we aren’t accommodating for time spent in requirements collection and analysis, research into which fields to pull, and visualization design.