Hi Jack,
There's a task description in Project HEADWAY that goes into some detail about assembling a project plan. If you give it a quick runthrough, I think it will help you see that a schedule is typically a subset of the overall plan.
Best,
Dave
Assemble Project Plan
Description
Collect the results of your planning efforts and assemble them into a project plan document. Pull together all of the materials that describe what the project is about, how it will be conducted, what it will deliver, when it will take place, what it will cost, and who will be involved. Remember that each project is part of a fundamental and integrated plan to support the business and growth of an enterprise. Ensure that the project plan is coordinated with other enterprise-level efforts.
The content of the project plan should contain/describe the following:
* Introduction and summary
* Goals and objectives
* Quantified business benefits
* Scope
* Approach
* Project schedule and major milestones
* Project tasks and products
* Tools and techniques to be employed
* Project organization, key roles and team size
* Resource estimates
* Project budget
* Project risk
In addition, the project plan may include attachments that provide detailed levels of information and related documents. Typical attachments include but are not limited to:
* Project standards
* Project risk management approach
* Issue management approach
* Change control procedures
* Configuration management procedures
* Detailed descriptions of tools, technology, techniques used
Review the detailed project plan with your project sponsor. Obtain feedback from the project sponsor and ensure that you have his contined support and commitment. Revise the project plan as necessary to gain the project sponsor's approval.
Tips and Tricks
In putting together the various components of the project plan, consider the following:
* Reduce duplication on phased or similar projects. On projects where you are entering a new project phase or doing a project that is very similar in approach and structure to other projects, consider using a master project plan and make updates accordingly based on the needs and issues of the current project or phase or to reflect anything that may have changed. For example, you may choose to do this on an application development project that has moved into the maintenance or enhancements phase to reflect updates to the maintenance and enhancement activities, rather than developing a completely new project plan.
* Short form vs. long form. In some cases, the project will be small enough or familiar enough that it does not warrant including all the required information. For those projects, consider using a revised project plan that includes the key components but leaves the unnecessary documentation out. There are two key benefits to this:
o As a project manager, the short form makes your project easier because it allows you to maximize your time completing only the important documentation.
o Those reviewing the project plan will find it easier to understand because it wont be weighted down with too much documentation.
* Keep it organized. Obviously, it does not have to read like a story as maybe the business case does, but try to ensure that it provides readers with a complete picture. Keep it organized and clean.
* Convey only what is needed. . Regardless which form of project plan you select, keep the level of detail to what best conveys your message and doesn’t overwhelm the reader. For complex and highly intricate or detailed projects, consider providing a detailed project plan. For simpler projects, consider providing a less formal or cumbersome document.
* Review the detailed project plan with your project sponsor. Obtain feedback from the project sponsor and ensure that you have his continued support and commitment. Revise the project plan as necessary to gain the project sponsor's approval.
PMI Team Member
