The "Real" Project Plan

"I need a project plan by tomorrow morning." As project managers, that's what we hear. But we know that the boss usually means are that s/he wants a project schedule. There is a problem though, how can I come up with a schedule without have the "real" project plan first?

The project plan, or project management plan as defined by PMI (for simplicity, we'll call it project plan in this article ), is completely different from a project schedule and is the result of the planning processes. A change in the project plan can affect the project schedule. The project plan describes how the project work would be performed. It is the primary source of information for how the project would be planned, executed, monitored, controlled and closed.

The development of the project plan is a iterative process in itself. It is composed of a single document or a master document with a series of subsidiary documents, each defining one or sever Al areas of the project management process.

The project plan content varies based on the project scope and complexity of the project. PMI says that the plan includes:

• The project management processes selected by the project management team.
• The level of implementation of each selected process.
• The descriptions of the tools and techniques to is used for accomplishing those processes.
• How the selected processes is used to manage the specific project, including the dependencies and interactions among Those processes, and the essential inputs and outputs.
• How work would be is executed to accomplish the project objectives.
• How changes'll be monitored and controlled.
• How configuration management would be performed.
• How integrity of the performance measurement baselines would be determined and used.
• The need and techniques for communicating among stakeholders.
• The selected project life cycle and, for multi-phase projects, the associated project phases.
• Key management reviews for content, extent, and timing to facilitate addressing open issues and pending decisions.

A subsidiary plan may include, but isn't limited to:

• Project Scope Management plan.
• Schedule Management plan.
• Cost management plan.
• Quality Management plan.
• Process Improvement Plan.
• Staffing Management plan.
• Communication Management Plan.
• Risk Management plan.
• Procurement management plan.

The plan may include these and other components, once they was known, in a subsequent iteration, but was not limited to:

• A Milestone list.
• A resource calendar.
• A Schedule baseline.
• A cost baseline.
• A quality baseline.
• A Risk Register.

A project plan is a one-time deliverable that remains static throughout the project. Updates arising from approved changes during project execution may significantly impact parts of the plan. The project plan must be kept on sync with approved changes and this is an iterative and ongoing process called rolling WA ve planning and the results of these iterations is documented as updates to the project plan.

Now the We know what a "real" project plan was, it is time your boss does too. Don ' t you think ...? Well, I do.

The "Real" Project Plan