Who can tell me what should be in my Project Plan document?

Bill Hoberecht - This email address is being protected from spambots. You need JavaScript enabled to view it.

The Project Plan is one of the most important sources of project information, yet there is little consensus on what constitutes a sufficiently thorough project plan that is not excessively detailed.  A project manager may inadvertently fall into a pattern of constructing and using a cursory or superficial project plan, introducing several risks to the project. Or, the project manager may fall into the all-too-common habit of believing that the project schedule is the entirety of the project’s plan.  The cure for this is to develop an improved understanding of project plan topics, structure & uses, and then apply this critical knowledge when creating a project plan.

The meeting didn't go all that well.  In fact, it didn't go well at all - some might have even called it a disaster.  Campbell, a respected project manager, had been running projects in the company for many years and had been looking forward to this first opportunity to present the project plan to the new program executive.  The program executive spent most of the time asking questions about information that wasn't included in the project plan, and seemed to be conveying a rather disappointing message of "you didn't plan this project very well." Who could think of a worse way to start a relationship with a new executive!

So what was really happening here?  Was this a matter of project manager incompetence, or was this really a clash of two very different but valid views of a project plan? Let's look at each person's perspective:

• Campbell, building on a decade of experience in the same company, had constructed and published a plan that was very much like the typical project plan produced in the organization - the plan consisted only of a project schedule assembled in MS-Project.  A review by anyone would have concluded that this listing of project tasks was very complete, and that the information about each project task was reasonably thorough.  From Campbell's perspective, the MS-Project schedule is essentially the only information needed to manage the project and thus is the only planning information needed for the project.
• The program executive, upon joining the company recently, had discovered that the program rarely completed any projects to the satisfaction of the business units - projects were almost always late, sometimes exceeded allocated budgets, and often required several additional weeks, post-delivery, to bring quality up to minimum requirements.  Project plans were characterized as “superficial and sketchy".  From prior experience elsewhere, this executive knew that one direct cause of project failure is inadequate planning and the lack of a sufficiently complete project plan.  Because of this, very little of the discussion during the project plan review was about project tasks, most time was devoted to exploring topics like project scope, constraints, budget, risks, issues, and measures of success. The project executive felt that these aspects of the project were key to overall success and concluded that the omission of these basic elements significantly decreased the chances of project success. 

Situations like this are not unusual in organizations that lack a strong project management culture.  Projects regularly fail or disappoint but it takes the introduction of a new factor (e.g., a new executive/director, launch of a PMO) to highlight the need for discussing, and perhaps implementing, a different approach that will improve organizational performance and results.

I regularly see project plans that appear to be wholly inadequate, and have little surprise when the project inevitably fails to complete as "planned" (or succeeds only because of the valiant efforts of many heroes who go well beyond expectations to recover a poorly planned effort).  As well, I occasionally see the voluminous project plan that seems to write about every imaginable facet of the project, regardless of significance; I shrug my shoulders and wonder if such a plan is actually a "write only, read never" document that will be destined to a life of gathering dust on the shelf once the project is underway. Clearly there is an enormous lack of consensus within the project management community on what constitutes a good project plan.  Indeed, the search for a perfect project plan that is applicable to all projects may be a fool’s errand.

Let's look at some important "project plan concepts" and then re-visit Campbell and the project executive to see how they moved forward from the catastrophe that was their first project plan review.

What is a Project Plan?

A project plan contains information that is used to manage a project.  You’ll create it early in the life of the project and the team will use it in managing the execution of the project.Here’s what some credible project management references have to say when defining a project plan:

• The Project Management Institute, as published in the Project Management Body of Knowledge says that a project plan is:
  • "... a formal, approved document used to guide both project execution and project control. The primary uses of the project plan are to document planning assumptions and decisions, facilitate communication among stakeholders, and document approved scope, cost, and schedule baselines. A project plan may be summary or detailed."
• PRINCE2 (a project management standard used extensively by the UK Government, also having worldwide recognition) says that a project plan is:
  • "... a statement of how and when a project's objectives are to be achieved, by showing the major products, milestones, activities and resources required on the project.
• The IEEE Standard for Software Project Management Plans defines a software project management plan as:
  • “… the controlling document for managing a software project; it defines the technical and managerial processes necessary to develop software work products that satisfy the product requirements.”

Here’ my take on project plans – a project plan . . .

• Is accurate
  • It is a credible, viable, realistic description of a project
• Includes information that is essential for managing the project to success
  • Includes information that is important to be considered while initiating and planning the project
  • Also includes information that guides and directs the team in executing, controlling and closing out the project
• Is used to lead the project
  • It sets a direction for the project team and stakeholders by providing a record of decisions made about important aspects of the project (e.g., management approach, project scope)
• Is used to control the project
  • The information in the project plan is the baseline against which project performance is monitored

What a Project Plan isn’t

Let’s look at the project plan from another perspective – what a project plan isn’t:

• A project plan isn’t a few presentation slides listing milestones, activities or tasks
  • For some communications needs, you’ll likely share some aspects of a project plan in summary form with team members or stakeholders; those presentation materials are not a complete project plan.
• A project plan isn’t synonymous with project schedule.
  • A 'Project Plan' is quite different than a Project WBS or a Project Schedule.  Perhaps the largest reason for believing that a schedule and plan are the same thing is the widespread use of the phrase 'Microsoft Project Plan' to describe a project schedule. A Project Plan provides information about how to manage the project to successful completion. A project schedule is a component of a project plan; it describes tasks to be performed, the relationships  between tasks, and the schedule for completing this work.
• A project plan isn’t static and unchanging.
  • The moment a project plan is baselined, it is possible that potential changes to the project plan are already known.  As the project progresses, chances are that incremental learning, internal & external influences, and project performance will require updates to the project plan.  It is the rare project that will be able to baseline a plan and go through to completion by executing that exact plan without any changes.  (I’m not implying that projects are doomed to be unable to deliver on the commitments listed in their project plan; rather, I am suggesting that no one should be surprised when changes to project execution are necessary in order to deliver on the commitments made by the project team).  Anticipate making updates to the plan as the project progresses.
• A project plan isn’t where you document all of your project management processes, methods and templates.
  • Some project plan templates suggest that the documented plan is where processes are detailed, but it isn’t effective to have each project independently document their processes.  You’ll want to establish a repository of standard processes, methods and templates for the organization, and then tailor the use of those assets for your project – thus, the project plan, when discussing processes and methods, would refer to either the standard organizational asset (which the project would be using ‘as is,’ or to a version of that asset that has been tailored specifically for the project.
• A project plan isn’t a document that is created in isolation by the project manager.
  • While an early draft of a project plan may be constructed by a project manager without consulting with others, this early version would be a vehicle for subsequent planning discussions with others.  A project plan is the result of collaborative planning activities that include team members and stakeholders, and it reflects an agreed view of the project. 

Determining the Contents of Your Project’s Plan

Project Managers, you may encounter someone (e.g., your organization’s PMO, an expert project manager, a consultant) who approaches you with a complete and comprehensive specification of everything that must be included in your project plan;  raise your shields, put on your thinking cap, and apply some considered thought before unquestioningly using their template or specification.

There is no one perfect specification that accurately lists the complete set of information that must be in all project plans – any such specification could not possibly be applicable to the many different types of projects you'll probably manage in your career.  The absence of a universally valid project plan specification that is valid across an extreme range of project characteristics creates a few problems for project managers: if we don't know what constitutes a perfect project plan, how does a project manager actually know what type of project plan to construct for their project?  How can the management and executive team know that the right plans are being constructed for use in managing the organization's projects?  How can a project manager prepare to satisfy the company or organization's expectations and requirements of the project planning activities?  The answer to these questions lies in gaining enough expert knowledge about project plans, and then applying your newly-developed expert judgment.  Here is an approach that is actionable by all project managers:

• Become an expert on all of the different types of information that could possibly go into a plan.  This is not a passive activity – applying energy to understanding project plans is the key to developing ‘expert judgment’ in this area.  Through these activities you’ll reinforce much of the project planning information with which you are already familiar.  As well, you’re likely to develop a deeper understanding of other project planning information that you’ve never actually used; some of these will be valuable, and including these items could potentially strengthen the plans created for your projects.
  • Project Plan Templates. Examine, dissect and analyze various project planning templates to understand the value, importance and utility of the information required by those templates.  Look for annotated templates that go beyond just giving section titles – you’ll want to read through a description for each project plan section.  Your organization or PMO might have a project plan template, and you can probably find at least four or five good examples searching the internet.  Don’t hesitate to check with colleagues at a PMI chapter meeting for their recommendations.
  • Existing Project Plans. Read through existing project plans to understand the actual information published in those plans (and not just a description of the information, as is sometimes included in template annotations).  Strive to find at least four or five good examples within your company and another few examples by searching the internet; seek out the project plan author(s), engaging them in discussion about the importance and usefulness of the information they elected to put into their plans.
  • Group Sharing - Project Managers.  Consider organizing an information sharing session (e.g., brown bag lunch) where project managers present actual project plans that they have created and used.  Because project plans almost always contain information that is private to a company, you’ll probably need to keep this as an internal company gathering.  This has the potential to be valuable for all attendees as project managers describe their project characteristics and explain their rationale for determining the contents and level of detail for their project plans. 
• Apply your knowledge and experience in deciding which information needs to be assembled or created for your project.  Using your project plan expertise, you can make informed decisions on what must be considered during project planning and subsequently used during project execution.  Equally importantly, you’ll have a sufficient understand of project planning information to decide what types of planning information are not essential for your project.
  • Omit irrelevant items.  Your time is precious and limited.  Allocating time to constructing some text just because a template requires it may not be the best approach.  If you are required to use a standard project plan template, understand how that information would be used in managing the project - if the information is not relevant and will not be used, then there is little sense in putting it into the plan.
  • Don’t get lazy.  Steering clear of some planning areas because they are difficult to address (or require a significant effort to plan sufficiently) is not such a good approach.  Don’t omit important project planning formation with because of “it’s too much work” or “it’s too hard to do that part of the plan.”

Moving Forward with Campbell and the Program Executive

Following their first project plan review, Campbell and the Program Executive recognized that they had two very different views of project planning.  After an initial rush of anxiety and concern about job security, Campbell recognized that this was an opportunity to learn more about project planning.  The program executive arranged project plan training for Campbell and other project managers, and set an expectation of improved performance in creating more thorough project plans; organizational line managers established specific performance goals with their project managers, reinforcing the high level expectations set by the program executive.

In upcoming months a few project managers recognized that they had neither the skills nor the inclination to develop the skills that were needed to manage projects in this organization, and they departed for other opportunities.  Campbell and other project managers starting applying improved approaches to planning and creating a project plan, and had excellent results in improving the organization’s project completion performance.

One Important Point to Ponder

So, what is your response when a project manager asks: Who can tell me what should be in my Project Plan document?