Tag Archives: project plans

Project plans are your source of truth

by

It’s been a while since I last wrote about project plans, calling them living, breathing documents. As part of the recent series digging into the critical components of scope and estimates, project plans are the next logical discussion point. Project plans are the manifestation of the scope and estimates. It comes in the form of gantt charts, excel work breakdown structures, calendars, etc.

The project plan, in whatever form, is a combination of tasks (scope), timelines (schedule ), resources and cost (sometimes). They can be high-level or very detailed. They should show dependencies among tasks. However, I would caution you to make them too detailed, as they aren’t set in stone, and making them complicated means it can be painful to update. Give yourself and your project team enough information to see what needs to happen, when it will happen, and discussion points for scope changes, issues, etc.

Most project managers have their preferred tool. My preference is the simplest tool for the project team. In my cases, this is usually a work-breakdown chart in excel. Excel is something that most business professionals know how to use. You also have flexibility in how much detail you provide and it’s fairly easy to update.

Most important is for the project manager to be regularly reviewing and updating the project plan. Always accurately represent where you are in the project. This is something that you should be sending out to key stakeholders on a weekly, or semi-weekly basis. It really does become the point of reference for discussions. Stakeholders may not read it, but you can use it to guide discussions, and point to it as the single source of truth. This is key.

The Myth of the Project Plan

by

 

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.