The PM2 Guide describes, for each activity of each process group (Initiating, Planning, Executing/Controlling and Closing), which artefacts should be produced and how each role should be involved following a RASCI matrix (Responsible, Accountable, Supports, Consulted, Informed). Several versions of these documents are to be produced during the project lifecycle, to keep updated evidence of all significant management topics.

A total of 33 document templates are published. Most of them are Microsoft Word files, some of them are Microsoft Excel files. They are all great quality documents, covering most cases in all kind of projects, not just UE’s ones. These templates can be easily tailored to any organization.

An updated version can be downloaded easily, without registering, for free, at these links, among others:

Following are the definitions of these artefacts, taken from the guide.


  • 1. The Project Initiation Request is the starting point for documenting a project proposal. It gives a high-level overview of the current situation (needs, problems, and opportunities), desired outcomes and the estimated effort, impact, risks, constraints, and assumptions associated with the implementation of a solution.
  • 2. The Business Case is a document that provides contextual information to the decisionmakers on the project’s costs and benefits, strategic alignment and/or business problems the project intends to solve. It captures the reasoning for the project, presents several alternative solutions, provides the justification for the investment in time and effort, and establishes the budgetary needs.
  • 3. The Project Charter is a document that captures the essence of the envisaged solution in the form of high-level needs and features that gives the reader an overview of the final project deliverable(s). It includes information regarding the project scope, cost, time, and risks, as well as information such as milestones, deliverables, and project organization and approach. It is a document initiated by the business sponsor that formally authorizes the existence of the project and the project team and provides the Project Manager (PM) with the authority to use organizational resources to staff project activities.


  • 4. The Project Handbook establishes the high-level approach for implementing the project objectives. It is one of the first artefacts created in the Planning Phase and it identifies the project standards, roles & responsibilities, approach, and the artefacts to be used.
  • 5. The Project Stakeholder Matrix lists all the people, groups or organizations involved in the project, and clarifies their roles.
  • 6. The Project Work Plan identifies and organizes the project into deliverables, work packages, activities, and tasks, needed to achieve the project objectives. It establishes a base from which to estimate the duration of the project, determine the required resources and schedule the work.
  • 7. The Outsourcing Plan describes the contracting strategies that will be used to outsource services or products outside the organization to fulfil the project needs. It outlines the scope of products and/or services to be contracted and identifies responsibilities for the full contract lifecycle. It also includes the criteria for evaluating the contractors’ service and deliverables.
  • 8. The Deliverables Acceptance Plan is a quality management artefact. It defines and documents the deliverables acceptance approach, activities, responsibilities, and acceptance criteria along with acceptance tolerance levels.
  • 9. The Transition Plan defines the pre-requisites of rolling out the new solution. This is useful to ensure a smooth transition from project mode to operations mode.
  • 10. The Business Implementation Plan outlines the project’s impact and deliverables for the requestor organization, along with the change management activities that need to take place. The organization must ensure that the project does not disrupt normal operations, and that project outputs are effectively integrated into the organization. A change management plan is devised to ensure this and to increase the chances of achieving the desired project outcomes and benefits.
  • 11. The Requirements Management Plan describes the requirement management process to be used for the project; defines the roles and responsibilities related to requirements management; and specifies the methodology, standards, tools and techniques and templates used to support requirements management.
  • 12. The Project Change Management Plan defines and documents the change process for a project. It defines the activities, roles and responsibilities involved in identifying, documenting, assessing, approving, prioritizing, implementing, controlling, and communicating project changes.
  • 13. The Risk Management Plan defines and documents the risk management process for a project. It describes how risks will be identified and assessed, what tools and techniques will be used, the risk level bands, the relevant roles and responsibilities, and how often risks need to be revisited, etc. It also defines the risk monitoring and escalation process as well as the structure of the Risk Log used to document and communicate the risks and the risk-response actions.
  • 14. The Issue Management Plan defines and documents the activities, roles and responsibilities involved in identifying, assessing, assigning, resolving, and controlling project issues.
  • 15. The Quality Management Plan defines and documents the project’s quality requirements, including the quality management approach, process, and responsibilities, and outlines the quality assurance and control activities to be carried out throughout the project. Also includes the Configuration Management process.
  • 16. The Communications Management Plan determines how to communicate most efficiently and effectively to the various stakeholders. It defines and documents the communication items content, format, frequency, the audience and expected results. It also defines how to communicate project status and the assignment of activities to the various stakeholders, and the communication strategy for each stakeholder, based on their interests, expectations, and influence in the project.


  • 17. The Meeting Agenda indicates the points to be discussed.
  • 18. The Minutes of Meeting (MoM) includes the action points after the meeting.
  • 19. The Project Status Report is a frequent report (e.g. every 1-2 months) that is sent to the Project Steering Committee (PSC) and contains just a one-page summary of the project status.
  • 20. The Project Status Report EVM is similar to last artefact, but including cost control information using the Earned Value Management method.
  • 21. The Change Request Form has the purpose to capture the need and characteristics of a project change request.
  • 22. The Project Progress Report is an artefact created by the Project Manager (PM) to inform the Project Steering Committee (PSC) on how the project is progressing compared to the baselines and the Project Charter. It covers the status of the deliverables, effort, risks, major issues, actions, achievements, and scope changes.

Monitor and Control (Logs)

  • 23. The Risk Log is the central repository for all risks identified by the project or organization. It includes information for each risk such as its likelihood, impact, level, risk-response strategies, and risk owner. A Risk Log can also be referred to as a Risk Register or Risk List.
  • 24. The Issue Log is a register (log file) used to capture and maintain information on all issues that are being formally managed. The Project Manager (PM) monitors the Issue Log on a regular basis.
  • 25. The Decision Log contains a summary of project decisions taken. It brings visibility to decisions and tracks responsibility for how and by whom they are taken, when decisions are implemented, as well as to whom they should be communicated.
  • 26. The Change Log is a register of project changes used for recording, assessing, monitoring, controlling, and tracking change requests and respective decisions. It also serves as a way of communicating changes to the Project Owner (PO) and/or Project Steering Committee (PSC).

Monitor and Control (Checklists)

  • 27. Phase-Exit Review Checklists are spreadsheet-based documents used by the Project Manager (PM) to ensure that all the necessary items are in place before the project proceeds to the next phase or is closed. They are concerned with checking key information in each phase and gathering Lessons Learned.
  • 28. The Quality Review Checklist is a tool used throughout the project (when performing quality control) to check if quality management activities have been performed as defined in the Quality Management Plan.
  • 29. The Deliverables Acceptance Checklist is used to ensure that deliverables meet the predefined objectives and criteria outlined in the Deliverables Acceptance Plan.
  • 30. The Transition Checklist helps the Project Manager (PM) when verifying whether the transition activities were performed as planned. An extension for IT Specific projects is also provided.
  • 31. The Business Implementation Checklist helps the Business Manager (BM) and the Project Manager (PM) when verifying whether the business implementation activities were performed as planned.
  • 32. The Stakeholders Checklist is a document created to help deal with stakeholders during the lifecycle of the project.


  • 33. The Project-End Report summarizes the project experience, performance, lessons learned, successful project practices and pitfalls.

PM2 artefacts with PMPeople

Documentation is quite important in all projects, but we need to avoid the pattern described in the book Adrenaline Junkies and Template Zombies: Understanding Patterns of Project Behavior. Precisely, the pattern 86. Template Zombies discusses the harm of being driven by form rather than content:

There are many predictive projects that consider comprehensive documentation as a kind of waste, or bureaucracy. Agile projects need only a few documents. In general, we should produce only those documents that help to achieve the project management goals and deliver the value.

PMPeople allows people to easily access the project documents stored in any file sharing tool like Google Drive, One Drive, Dropbox, etc. In many projects, though, users do not need documents to follow the project management processes. This is the case when managing items like:

  • changes
  • risks
  • issues
  • requirements
  • deliverables
  • milestones
  • stakeholders
  • procurement
  • lessons learned
  • project charter
  • team charter
  • calendars
  • timesheets
  • expenses
  • baselines
  • effort
  • tasks
  • funding
  • phases
  • status reports
  • progress reports
  • earned value management
  • retrospectives
  • etc.

For UE’s projects, but also for projects in many organizations, it is valuable to follow a strict methodology based on documented evidence. Even for those cases, PMPeople enables people to collaborate first, and document the project later, saving time and fostering project teams productivity.

PMPeople is the tool for the project economy. It is aimed to unify professional project management by these differential points:

  • Designed by and for professional project managers, following professional project management standards.
  • Online productivity –less meetings, less documents, less workflows– through distributed collaboration among 12 specialized roles: Organization Owner, 6 roles on demand management and 5 roles on supply management.
  • Freemium product –unlimited time, unlimited users, only managers have to pay– usable via web and mobile application.

Start using PMPeople for free, for unlimited time and for any number of users. In premium organizations, only managers have to pay. Several roles –stakeholders, team members, sponsors and resource managers– are always free. You can increase or decrease your premium seats according to the organization actual needs. Premium organizations have access to our interactive support through Slack. Our servers are located in EU. This software can also be hosted on customer premises.