Do you know what I see when I talk about Project Management Plan? I see fear or misunderstanding. They imagine a 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.

So what is a Project Management Plan? It is a plan that describes how you will execute, monitor, and control the project. Do you need much to complete a project in a controlled way? No, usually not much. But projects are all unique. So, it depends.

Project Management Plan

What should you include in 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 in the Project Management Plan. So now, please check it out.

Practical Guide to Useful Project Management Plan from Dmitriy Nizhebetskiy

Practical Guide to Useful Project Management Plan from Dmytro Nizhebetskyi

Right after that, please note that there are other commonly used documents on a project. But they are not 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 the 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 on how to get started:

1. 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, and Business Analyst 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 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 differently.
2. 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.
3. 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.
4. Outline the details of the key processes. I suggest you to think of it in terms of Inputs => Techniques/Tools => Outputs. At this moment, you need only to outline. Do not go into details for now. Here is how it may look for the 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.
5. Create templates for critical documents and 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 detail.
6. Start piling up the project management plan. By this moment, you should already see how your project operates. You have all the 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 the Project Management Plan. Check whether the plan looks finished and all areas are complete.
7. Maintain, update, improve. Once you have a framework for 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 it all at once. And keep in mind that it is a good practice to involve team members in the creation of a 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 to 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 to the scope and allocated resources. Therefore, this activity will be included in baselines. The document served its purpose for now.

Here is a list of commonly used artifacts. We will discuss some of them in detail 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 the 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 the 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 the 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 a project management plan is not that difficult. It does require effort. But there is no way you can overestimate the benefits you get from it.