Gantt chart as a project plan. Is it enough? Mar 01

  This blog post is a short version of Brad Egelands article at PMTips.net. You can read the original from here http://pmtips.net/components-project-plan/ 

It is a good read about must-have parts of project management and gives a good overview of the process.

We often make the mistake of referring to the Gantt chart as the ‘project plan.’  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.

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.