Do you have a perfect PM documents kit that would suit almost all of the projects you manage? What are the Project Management docs that you always need?
Hey Crizpers, let’s chat about the most common project management documents that we might need on a regular basis. Obviously, every project is unique and may require a couple of additional papers for support. However, in many cases we are aiming to maintain a Project Plan according to the templated standards as this facilitates significantly the overall project management process. Here I am going to share my PM docs kit list. Let’s compare with what you use. Let me know what documents you need frequently on a project!
Project Plan
To skip possible confusion, let’s clarify this from the scratch. A Project Plan is not a document itself, but is a set of docs that we compose for a project (referring to the Top 13 PM terms). The plan includes all the project management documentation that you need for leading, managing, supervising and checking out a project. Factually, the Project Plan documentation and the information these docs contain is called Project Knowledge. Besides, keeping the project plan up-to-date is labeled Project Knowledge management. Thus in this article we are going to touch base on what documents we need to compose most frequently in order to fulfill the Project Plan and to create the Project Knowledge.
Project Charter
Project Charter (PCH) is the main project management document and basically this doc should be composed for every project in order to initiate it. PCH officially authorizes a Project Manager to act on behalf of a Project Owner or a Customer and to manage a project. And this information should be formally mentioned in the Charter. Thus, the key information in these document is who pays for the project, or who orders the work to be done; and who is accountable and is authorized to manage a project. This to be always pointed out in the first lines of the Project Charter. From a glans people should be able to grasp the information and understand who is in charge and who they may address the queries to.
Although there are no rigid criteria for the Project Charter structure, you may also include relevant details, or a shorter nuances about the project that are mostly important. I guess we could set up a separate presentation on how to create Project Charter.
Scope Management Plan
This is one of the essential top-level documents sets that should be included in the Project Plan. On a high level, Scope Management Plan (SMP) contains:
- Project Requirements;
- Scope of Work or Statement of Work;
- Work Breakdown Structure or WBS;
- Project specification with the description of how the solution should function.
While composing Scope Management Plan we are conducting the initial research, business analysis, architectural and UX design.
This documentation helps to clarify among all the involved parties how exactly the product or service should look and feel. The Product or Service Workflow description is extremely important for translating the requirements into the digestible action and flows for ensuring that everybody is aligned and have a similar outcome on mind.
Additionally, if possible I would strongly recommend including the wireframes and mockups to the plan. This would significantly facilitate both an overall understanding and a final verification process. As I have mentioned before, sometimes one pic could worth a thousand words (UX importance article).
Resources Management Plan
Here we are to define who is going to work on a project and what tools and techniques are required to be used. We have the scope, thus we could define:
- skills,
- tools,
- materials,
- techniques and
- methodologies
that are required for the product delivery. Record this information and make it transparent for all the members of the project to avoid variations in the approach. We are aiming to standardize the techniques the project is gonna be developed with in order to meet the necessary level of quality.
Additionally, in the Resource Management Plan we are going to outline details about the project team,
- build a list of participants and
- create a responsibility chart, or RACI.
Cost Management Plan
Sequentially, after we got the Project Scope and WBS, we need to estimate the work. There are a ton of estimation approaches, and we are going to discuss them individually. Nevertheless, no matter which approach is chosen, finally we need to get the appropriate numbers in order to define how much the work should cost.
What is good, for the overall estimation and scheduling procedure could use the universal measurement in hours or days of work. However, here we need to explicitly clarify and centralize the information about the duration of the business day or business week so that we could move on further efficiently.
As for the cost itself, once we have the estimates, this is not gonna be a simple math to sum up the numbers. I would recommend considering other nuances that could impact the overall project budget. I am referring to:
- procurement that might be necessary, should this be materials, external resources, equipment, environment or licenses. All these items add additional cost the the project budget.
- Besides, here we need to think of the possible possible risks and mitigation activities. I am referring to the Contingency and Management reserves.
Therefore, Cost Management Plan in addition to the
- scope estimates
should also contain a strategy on how are we going to pay for all the additional cost consumption instances with numbers.
Risk Management Plan
We have already discussed how Risk Management Works. Now it’s time to document it. Basically, we are not going to document the process of risks identification itself, however, this flow is supported by the documents as they are the outcome of the possible risks analysis.
For the Risk Management Plan (RMP) I would consider documents such as:
- known risks is a probability and impact matrix;
- quantitative estimates;
- action plan for the high-probability / impact risks mitigation;
- issue log for recording the risks that has occurred and the measures applied.
Quality Management Plan
I am a huge fan of quality and can talk about quality for hours. This is a general component of the project value thus we need to precisely work on the quality management and verification.
The Quality Management Plan may vary depending on the company policies and guidelines, however, the main goal here is to ensure that Quality is built into the project delivery process. Therefore, as a ground rule we are outlining here, or referring to the general quality standards, such as when an error is found it must be recorded and fixed instantly based on the issue priority; encouraging peers not to close their eyes if they have notices problems; address issues promptly and efficiently and so on. For the relevant project documentation related to the quality management, let’s point out:
- success criteria that we need to comply with;
- scope verification process;
- verification requirements – flow, methodologies and techniques for QA;
- pass score for the final product (number and priority of errors acceptable for production).
Schedule Management Plan
And here we finally are. Based on all the relevant nuances, WBS, estimates, risks and dependencies we are operating to schedule the project work. For the Schedule Management Plan I would consider:
- Project Schedule maybe with a Gantt Chart;
- list of Milestones and delivery dates;
- project delivery phases based on the SDLC;
- available ways for the Schedule variance elimination. Such as the possibility of the additional resources engagement, buffers and so on.
More Rags
We already have a pretty big folder of docs that will help to manage a project efficiently. Supplementary to the above I would consider adding a Communication Management Plan (Speaking out Loud), Change Log (Changes and Project Management) and we also should not forget of Stakeholders and of a plan how to manage them. However, this specific information could either demand to be treated as separate papers, or might be included within the already created docs. I would rely on the project specific to define the approach.
That was a long check-list! Let me know what documents do you use on your projects regularly, and which of them you create only occasionally?
Cheers!