We often make the mistake of referring to the Gantt chart as the ‘project plan.’ I’m often still guilty of that. I know it isn’t, but it’s been incorrectly identified as such so many times by others and myself that it’s still easy to make that connection. This seems to be most prevalent in the world of information technology. In reality, the Gantt chart, or project schedule – is only one component of a real, true project plan.
According to Wikipedia, at a minimum, a project plan should answer the following four basic questions about the project:
Why?
What is the problem or value proposition addressed by the project? Why is it being sponsored? Why is there a need? Why is a particular technology being addressed?
What?
What is the work that will be performed on the project? What are the major products/deliverables? What is the end goal? What is the desired outcome? What will we do when there are major issues or decisions on the project?
Who?
Who will be involved and what will be their responsibilities within the project? How will they be organized? Who will make approvals along the way? Who will fund it? Who will be responsible for specific types of communication on the project?
When?
What is the project timeline and when will particularly meaningful points, referred to as milestones, be complete? When will formal and informal meetings take place? When will regular status information be exchanged? When will testing and reviews take place?
Examples of items that can be – and often are – included in a project plan, depending on the industry and type of project, include:
- A problem statement
- A project mission statement
- Project objectives
- Project work requirements
- Exit criteria. These criteria are used to determine when each milestone has actually been reached.
- End-item specifications (engineering specifications, architectural specs, building codes, government
- regulations, etc.)
- Work Breakdown Structure (WBS)
- Schedules (both milestone and working schedules)
- Required resources (people, equipment, materials, and facilities)
- Control system – if applicable
- Major contributors
- Risk areas, with contingencies if possible
As you can see, the project plan has a lot to cover well beyond just the project schedule. As project managers we may be guilty of not always putting together a formal project plan. I know I am.
Depending on the size and formality of the project, I often leave this type of information to be scattered among several documents or plans that may never have a formal signoff or deliverable status. The project schedule holds some of the information.
The statement of work will other information. Some deliverable plans, like the communication plan may hold some of this information as well, but it is not likely formally produced on every single project.
It is far better to have key project information contained in one document – the project plan – and to have it be regarded as a formal project deliverable very early in the engagement and for it to require a formal approval and signoff from the customer.
That way, everything is covered and everyone is covered. And it’s likely to be a paid deliverable as well, if you can negotiate that into the plan and schedule. One more thing - to be a complete project plan according to industry standards such as the PMBOK or PRINCE2, the project plan must also describe the execution, management and control of the project. This information can be provided by referencing other documents that will be produced so it isn’t absolutely necessary that it be contained in the project plan – it just needs to be referenceable somewhere. Documents such as a Procurement Plan or Construction Plan may contain such information.