Do you know what I see when I talk about Project Management Plan? I see fear or misunderstanding. They imagine Project Management Plan as a pile of formally written text. And there are signatures of a senior manager on every page. But let’s try to demystify the major document on any project.
Project Management Plan
What should you include into the Project Management Plan?
It might not be clear what you can put into the plan. So I prepared a slide deck for you. It is a bit wordy. But I believe it is the best way for you to discover major topics included into Project Management Plan. So now, please check it out.
Right after that, please note that there are other commonly used documents on a project. But they are not a part of a Project Management Plan.
Usually, the plan includes:
Three Baselines:
- Scope Baseline
- Schedule Baseline
- Cost Baseline
Subsidiary Plans (knowledge area plans):
- Scope Management Plan
- Schedule Management Plan
- Cost Management Plan
- Risk Management Plan
- Quality Management Plan
- Procurement Management Plan
- Human Resources Management Plan
- Stakeholder Management Plan
- Communication Management Plan
And some extra Plans:
- Requirement Management Plan
- Configuration Management Plan
- Change Management Plan
It may also include:
- Information about project life cycle
- Description of project management methodology
- Project nature specifics
How Detailed Should It Be?
There is no word count you can aim at. The general rule is that it should be sufficient for a project. How do you know when it is enough?
I read quite a lot of books and articles on the topic. They all suggest the same. You need to describe all processes required for a project to operate smoothly. I think that is a bad way to do it. It’s overwhelming and scary.
I suggest you go incrementally. You don’t have a comprehensive project management plan today, right? So, most probably your project will not die if tomorrow the plan is not entirely ready.
Here is a step by step instruction how to get started:
- Write down a high-level description of how the project team does the work on the project. Including your responsibilities.It may look like this:
“We receive requirements via email or Skype from a customer. Then I put them into the Confluence and create a task in the “Task Tracker” to analyze the requirement. When it is time to analyze the requirement I expect that QA Lead, Dev Lead, Business Analytic meet up and read it out. They should prepare questions or clarification and draft out WBS…”And so on. It should cover all the processes from receiving a requirement to hand off of a deliverable to a customer.Even if you are using a popular framework like Scrum, I still suggest you do this exercise. It will be 90% of copy and paste of common Scrum practices. But I can bet that there will be some specifics that you will be doing a bit different. - Describe the process of executing actual work. It should include:
- What activity (task) a team member should do next. It should be a crystal clear process.
- What is a workflow for a task. You need to show a life cycle of a task from its creation to execution through different stages of work. It should also be clear how to verify that a task is fully finished.
- How to use a task tracking system. In fact, it is a manual for the tools you are using. It should be closely related to the life cycle of a task described above.
- How to track and report progress on a task.
- How to escalate problems with the execution of a task.
Try not to use formal language here. First, create a description that is clear for everyone. You will polish it later.
- Describe the processes that you had to explain more than three times recently. While writing and discussing first and second points, you will discover a lot of inconsistencies. Your team will ask a lot of questions. Usually, it will be points where responsibility goes from one person to another.That is the pain points of your project. Clarifying them is the priority. Describe them together with the team.
- Outline the details of the key processes.I suggest you to think it terms of Inputs => Techniques/Tool => Outputs. At this moment, you need only to outline. Do not go into details for now.Here is how it may look for Requirements Analysis process.
Input: Requirements from stakeholders (email, documents, user stories, etc).
Technique: Meeting, Document Review.
Outputs: List of Questions, Draft WBS, Wireframes.It will give you a rough understanding of the documents, artifacts, and tools you use. By analyzing them, you can identify which are critical for a project. For example, a Work Breakdown Structure is crucial for any project. - Create templates for critical documents, describe processes of their creation and quality criteria. Yes, each document on the project should comply with quality requirements. At least, they should follow a predefined format, type of data, and level of details.
- Start piling up the project management plan. By this moment, you should already see how your project operates. You have all critical processes and documents described. Now structure everything you wrote and created so far by knowledge areas. See if you can make any part of the plan reusable.Take your outline from point #4. Put a short description of each entry into Project Management Plan. Check whether the plan looks finished and all areas are complete.
- Maintain, update, improve. Once you have a framework of your plan, you can add a description of other processes. First, identify which parts can be left at a summary level. Then start working on the ones that cause problems, misunderstanding or look inefficient.
It is a long process. Do not try to do all at once. And keep in mind that it is a good practice to involve team members in the creation of project management plan.
Project Documentation
There are a lot of other documents, charts, and artifacts on a project. They are not a part of the plan. There is a reason to understand the difference.
Once a project management plan was approved, you can only make a correction in it using a formal change request.
These documents listed below are auxiliary. You create and use them during planning to make educated decisions. For example, to mitigate a risk from Risk Register you added an activity the scope and allocated resources. Therefore, this activity will be included into baselines. The document served it’s purpose for now.
Here is a list of commonly used artifacts. We will discuss some of them in details later.
Activity list. After decomposing Work Packages you receive activities. They are the main entity for your estimation of cost, duration, and schedule. Usually, all attributes of activities are combined in one document.
Agreements. Formal and informal agreements that you made before project execution.
Basis of Estimates. It is a good practice to document your assumptions and investigation notes during estimations. You will use them to verify estimates later during execution.
Change log. A document where you describe changes made in project management plan.
Issue Log. A document where you note all the conflicts that appear on a project and their resolution.
Milestone list. A list of important dates for the project life cycle.
Procurement documents. Any documents used for procurement.
Project Schedule Network Diagrams. It is a network diagram that shows dependencies between activities. It is used to define a critical path and a project duration.
Quality checklists, Quality control measurements, Quality metrics. These are documents that will help you to assure quality.
Requirements traceability matrix. A tool to track requirements on a project.
Resource Calendar. It is a calendar that shows availability of resources for the project.
Risk Register. A document that lists all project risks and their attributes.
Stakeholder register A list of stakeholders and their attributes.
Creation of project management plan is not that difficult. It does require efforts. But there is no way you can overestimate the benefits you get from it.
project management