In software development, project planning is often viewed as a definitive prediction that charts the future of the project, rather like laying down track for a railroad. If the plan is “good” the project will follow it unerringly like a train on rails. … This might be true for highly deterministic activities, tasks that are predictable and do not vary from their expected course, and tasks that are not subject to volatile internal and external forces. Unfortunately, that does not describe most software projects. Phillip G. Armour, A Little Queue Theory When More Work Means Less Done. Communications of the ACM, January 2015.

As anyone who has ever tried to use Microsoft Project (or any project planner) to plan a project comes to learn, projects are not deterministic. They don’t always have hard dependencies nor do they start and end on given dates and nor do tasks take exactly five days. At best a project planning tool such as these provide one view of a project, rather than providing the definitive view of the complete project.

We had engaged some contractors to solve our project planning difficulties. The solution they sold to senior management? They had a tool that would combine together all our Microsoft Project plans into one huge linked and interdependent plan. The contractor regularly assured me that once we accomplished this, tied all the plans together, then project planning and tracking would become simple.

What do you think happened? Yup, we tied them all together and got a hugely complex impossible to change plan that did no one any good, except the contractors who sold us the tool and their services. Project plans were simply not deterministic and certainly the Microsoft Project paradigm of dependencies and start and stop dates didn’t capture the full dynamics of a real project being touched by almost 2000 engineers.

The other notion of a project plan that people don’t get is that most plans are descriptive rather than prescriptive. The rookie project manager (or manager of any type) who builds a plan that tells everyone what to do, often fails. The experienced project manager who builds a plan that describes, as best as any tool can capture reality, what is going to happen based upon the existing organization is much closer to having a good plan.

The trick is to find the tools we need to describe the project we are managing. The project described by any given tool is NOT the project. It is simply a representation of the project using a tool that can’t possibly capture the full reality of managing any real life large project. It is often useful to describe a project using multiple tools or at least multiple views on what data we have. What is in the tool and described in the views is an attempt to model a project, but as I said, it is NOT the project.

For similar see Does Your Requirements Really Drive Your Schedule?

If we keep in mind that the plan encoded in the tool is not really the plan but our best representation of the plan in this tool, then it helps us, our team, and more senior management to understand the role any mechanical plan plays in managing a project.  It is not perfect and it is not truth. It is just a tool to help us visualize and manage some of the more important details.

See also how to Get the Schedule right.

What tools do you use to help you describe to others what the plan will really be?