A Project Management Plan (PMP) is an ever evolving document throughout life cycle of the project. It lays the foundations of the project purpose, scope, structure and actions to complete the required product. The PMP will start as a shell, containing high level information, but will be completed in more detail as the project progresses. The estimates, risks, strategies and plans contained in the PMP will become more specific as the information becomes available to the Project Manager.
The PMBoK guide defines the PMP as " the process of documenting the actions necessary to define, prepare, integrate and coordinate all subsidiary plans. The Project Management Plan defines how the project is executed, monitored and controlled, and closed".
The Planning Process Group is the process to define scope, objectives and the actions to complete the requirements to reach the project goal. The Project Integration Management Knowledge Area includes processes to identify, define, combine and coordinate the various project management activities across all of the Project Management Process Groups. This is the only Knowledge Area to exist in all of the Process Groups.
The PMBoK defines the Inputs as the Project Charter, Various Planning Outputs, Enterprise Environmental Factors and Organisational Process Assets. The only Tool & Technique is Expert Judgement. The single Output is the Project Management Plan. This sounds very simple, however, the data flow diagram in the PMBoK Guide tells a different story.
The PMP can be of varying complexity, from a small simple document, to a large complex multi-document pack. The complexity of the plan is down to the complexity of the project. Once the document has been published, it must be controlled through change control.
The document will contain many topics and depending on complexity, will contain an Appendix of documents. These documents will be tailored to each company and environment, but they will all run along the same theme. Below, I highlight the various chapters that I use as a standard template for my projects Project Management Plan and what is contained in each section or sub-section.
Section : Overview - This will contain a summary for the executives.
Sub-Section : Management Summary - Why are we doing this project, what are the business benefits and what would happen if we do not complete this project.
Sub-Section : Life Cycle Phases - A short description of each project phase, expected deliverables and expected completion dates
Sub-Section : Costs - Estimated costs will be included in this section at the start of the project, however, as the project progresses, the estimates will become more accurate.
Sub-Section : Resources - Management will want to understand how much the project will cost in terms of manpower and resources, so break down these figures to indicate the days required within each project phase.
Sub-Section : Develierables - Projects often have many deliverables. In this section, detail each deliverable and explain which phase they will be delivered.
Sub-Section : Related Projects and Dependencies - A short explanation of all project dependencies.
Section : Project Goal - A short, to the point, explanation of what the project is going to achieve.
Section : Project Scope - The scope of the project is a priority, when creating the PMP. The scope definition is one of the most important agreements you need as a Project Manager, which will ensure your project is a success. The scope must be clearly defined, but so must the Out of Scope items.
Section : Business Requirements - With small projects, I would keep this section content to a page or less. With larger projects, I would make this section a single sentence, referring to an external document for the full business requirements.
Section : Project Organisation Structure - The Project Organisation Structure is defined in this section to ensure all stakeholders, teams and management have a clear definition of who is involved in the project. The Project Governance can be defined here to indicate the communication paths and escalation routes for the project.
Section : Communication Strategy - This section will describe the types of communications and the frequency of distribution.
Section : Project Methodology - This section describes the actions required to complete the project.
Sub-Section : Implementation Strategy - How will the project deliverables be implemented into the necessary environments.
Sub-Section : Test Strategy - What will the testing consist of, who will complete the testing and who will authorise that tests are completed successfully.
Sub-Section : Roll-out / Roll-back - How will the project deliverables be rolled out to the users. If it is unsuccessful, how will the project ensure that users can go back the original way of working, so that there is little, or no, impact to the business.
Sub-Section : Decommission - If this project is replacing as process or system, which items can be removed from the environment.
Sub-Section : Disaster Recovery - In the future, if there is an issue with the project deliverable, what are the plans to keep the business running and how do you restore the functionality and Business As Usual in a timely manner.
Section : Quality Strategy - How will the quality of the project deliverables be measured and how will you obtain these objectives.
Section : Change Control - How will all changes within the project be managed. The changes could be to the project scope, the deliverable quality specification, or a number of project related items. You must detail how these changes will be managed and authorised.
Section : Risks and Issues - In this section, I usually have a table of the major issues and risks. I keep a separate RAID, but highlight only the tops issues in the Project Management plan. It is important that the owners, the mitigation actions and the dates are all included.
Section : Containers (Appendix) - Usually my documentation is placed on a server, or Sharepoint site, so this section is contained in a single page, with links to the various external documents.
Sub-Section : Master Plan (Phases and Milestones plan) - High level plan of the project phases and major milestones.
Sub-Section : Master Plan (Work Breakdown Structure) - At the start of the project, the planning phase may have a WBS, however as the project progresses, further phases and break down of the WBS will be added.
Sub-Section : Design Documents - As documents are completed and designs are finalised, documents can be shared with the stakeholders and Project Teams. These could include the conceptual designs, network diagrams, detailed design document and software design documents, and many more....
Sub-Section : Budgets, Quotes - When you start to obtain quotes from suppliers and your budgets become firm prices, you can add the quotes to the Appendix. This means that you can show the Project Governance over supplier selection and commitments.
Sub-Section : Lessons Learned - The final part to the document is useful Lesson Learned from the project. As you move through the phases, you will find processes went well, or could be improved. Ensure you add both positive and negative lessons.
That is a short summary of the standard document format that I use. I am sure there are many templates around the world, in different companies and corporations, but this is a good base to start with if you do not have an Organisation Asset.
As mentioned earlier, the smaller the project, the less the content of the PMP, however, the document is an important tool for the management of the project. At anytime, you should reference the project plan and keep it updated. You will find the PMBoK states the "Project Management Plan" as an input and "Update the PMP" as an output of many processes.
Sub-Section : Design Documents - As documents are completed and designs are finalised, documents can be shared with the stakeholders and Project Teams. These could include the conceptual designs, network diagrams, detailed design document and software design documents, and many more....
Sub-Section : Budgets, Quotes - When you start to obtain quotes from suppliers and your budgets become firm prices, you can add the quotes to the Appendix. This means that you can show the Project Governance over supplier selection and commitments.
Sub-Section : Lessons Learned - The final part to the document is useful Lesson Learned from the project. As you move through the phases, you will find processes went well, or could be improved. Ensure you add both positive and negative lessons.
That is a short summary of the standard document format that I use. I am sure there are many templates around the world, in different companies and corporations, but this is a good base to start with if you do not have an Organisation Asset.
As mentioned earlier, the smaller the project, the less the content of the PMP, however, the document is an important tool for the management of the project. At anytime, you should reference the project plan and keep it updated. You will find the PMBoK states the "Project Management Plan" as an input and "Update the PMP" as an output of many processes.
No comments:
Post a Comment