Here’s a mistake I make often….referring to the Gantt chart or project schedule as the project plan. And it may be that for a project plan that is all you have or need – especially if you’re running a fairly small project. And we aren’t the only ones making that mistake…it’s a common one. Especially 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 – which usually will do a pretty good job of the “when” and the “who”. 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 hold 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.
Summary
I’ve known this for – well – most of my project management lifetime and still I rarely create a full-fledged “project plan” with all of this information all in one place. And when I do it is a static, signed off, approved, and usually paid for document that is a one-time official document. Then the schedule becomes the living breathing manageable piece of the project reporting process. How about you – how often do you create a complete project plan? Under what criteria do you do so?
