The Myth of the Project Plan

 

The Project Management Institute Project Management Book of Knowledge defines a “project plan as a formal, approved document used to guide project execution and project control.” It further specifies that “it should be used to document approved scope, cost, and schedule baselines.” In my experience, a project plan is treated heavy on the “formal” and “approved” and light on the “baseline.” I think the process of approval gives the perception of longevity on the life of the plan. This minimizes the impact of the project plan as a baseline. Unfortunately this misunderstanding causes many complaints about project delays and delivery.

I was struck by this Computer Weekly quote when I conducted a google search for “project plan”: “[It] is one of the most misunderstood terms in project management. It is a set of living documents that can be expected to change over the life of the project.” This is polar opposite to how I have seen the project plan treated. The project plan is usually created at the beginning of the project, based on a statement of work, with fairly limited information. Even in cases where all stakeholders understand that the project scope is fluid, the project plan is expected at the beginning of the project and is used for making time-specific business decisions (training, user acceptance testing, etc).

Historically this has resulted in project managers padding their project plans with additional time so that the project is guaranteed to come in on time. Alternatively, the project plan isn’t padded, but issues of either scope creep, or scope reduction occur. In all cases, decisions are being made to meet a deadline, often selected artificially, which only aligns to the information available at the beginning of the project. There is no consideration to the fluidity of project implementation and information availability.

It would alleviate quite a few problems in project delivery & success if we chose to leverage the project plan as a living, breathing document. As time progresses, and additional details are obtained, the project plan should be updated. As a project team, we would be in a much better position to make decisions, and set more realistic deadlines as we get into the details and work through the development. Furthermore, sharing regular status and having constructive conversations about the state of a project and the next steps result in a more successful deployment.