Project Management Templates - 50 Downloadable PM Templates

-What are the Project Management Templates in this package?

There are 50 Downloadable Project Management Templates in this package. You will be able to download all of these project management templates with a zip file. If you wish, you will be able to visit each project management template file by knowledge area as well. Following is the list of project management templates in this package

Project Management Template #1 - Project Charter

The project charter is the document issued by the project initiator or sponsor that formally authorizes the existence of a project and provides the project manager with the authority to apply organizational resources to project activities. It documents the high-level information on the project and on the product, service, or result the project is intended to satisfy, such as project purpose, project objectives, success criteria, key deliverables etc.

At a high level, the project charter ensures a common understanding by the stakeholders of the key deliverables, milestones, and the roles and responsibilities of everyone involved in the project.

Project Management Template #2 - Assumption Log

High-level strategic and operational assumptions and constraints are normally identified in the business case before the project is initiated and will flow into the project charter. Lower-level activity and task assumptions are generated throughout the project such as defining technical specifications, estimates, the schedule, risks, etc. The assumption log is used to record all assumptions and constraints throughout the project life cycle.

Project Management Template #3 - Change Management Plan

Change management plan describes how the change requests throughout the project will be formally authorized and incorporated. For instance, there should be a change control board who will evaluate, reject or approve change requests rising during your project.

Project Management Template #4 - Configuration Management Plan

Configuration management plan describes how the information about the items of the project (and which items) will be recorded and updated so that the product, service, or result of the project remains consistent and/or operative.

Project Management Template #5 - Decision Log

During project meetings, executive meetings or meeting with individual team members, project managers might have to make critical decisions about the project. Critical decisions made about the project are kept in decision log.

Project Management Template #6 - Issue Log

Throughout the life cycle of a project, the project manager will normally face problems, gaps, inconsistencies, or conflicts that occur unexpectedly and that require some action so they do not impact the project performance. The issue log is a project document where all the issues are recorded and tracked. Data on issues may include issue type, who raised the issue and when, description, priority etc.

The issue log will help the project manager effectively track and manage issues, ensuring that they are investigated and resolved. The issue log is updated as a result of the monitoring and control activities throughout the project’s life cycle.

Project Management Template #7 - Change Request

A change request is a formal proposal to modify any document, deliverable, or baseline. When issues are found while project work is being performed, change requests can be submitted, which may modify project policies or procedures, project or product scope, project cost or budget, project schedule, or quality of the project or product results. Other change requests cover the needed preventive or corrective actions to forestall negative impact later in the project.

Any project stakeholder may request a change. Change requests can be initiated from inside or outside the project and they can be optional or legally/contractually mandated. Change requests may include corrective action, preventive action, an intentional activity, defect repair or updates.

Project Management Template #8 - Lessons Learned Register

The lessons learned register can include the category and description of the situation. The lessons learned register may also include the impact, recommendations, and proposed actions associated with the situation.

The lessons learned register may record challenges, problems, realized risks and opportunities, or other content as appropriate. The persons or teams involved in the work are also involved in capturing the lessons learned. Knowledge can be documented using videos, pictures, audios, or other suitable means that ensure the efficiency of the lessons captured. At the end of a project or phase, the information is transferred to an organizational process asset called a lessons learned repository.

Project Management Template #9 - Variance Analysis

Variance analysis reviews the differences (or variance) between planned and actual performance. This can include duration estimates, cost estimates, resources utilization, resources rates, technical performance, and other metrics.

In Monitor and Control Project Work, the variance analysis reviews the variances from an integrated perspective considering cost, time, technical, and resource variances in relation to each other to get an overall view of variance on the project. This allows for the appropriate preventive or corrective actions to be initiated.

Project Management Template #10 - Work Performance Report

Work performance information is combined, recorded, and distributed in a physical or electronic form in order to create awareness and generate decisions or actions. Work performance reports are the physical or electronic representation of work performance information intended to generate decisions, actions, or awareness. They are circulated to the project stakeholders through the communication processes as defined in the project communications management plan.

Work performance reports can contain earned value graphs and information, trend lines and forecasts, reserve burndown charts, defect histograms, contract performance information, and risk summaries. They can be presented as dashboards, heat reports, stop light charts, or other representations useful for creating awareness and generating decisions and actions.

Project Management Template #11 - Change Log

The change log is used to document changes that occur during a project. It contains the status of all change requests throughout the project or phase. The change log is used to communicate changes and approved, deferred, and rejected change requests to the impacted stakeholders.

The change log may introduce a new stakeholder or change the nature of an existing stakeholder’s relationship to the project. The change log contains changes to the original scope of the project. It usually links to specific stakeholders because they fall into categories of requesting certain changes, making decisions about change requests, or being impacted by the implementation of approved changes.

Change requests and their status are documented in the change log and communicated to the appropriate stakeholders. The change log contains the status of all change requests.

Project Management Template #12 - Project Management Plan

The project management plan is the document that describes how the project will be executed, monitored and controlled, and closed. Project Management Plan integrates and consolidates all of the subsidiary management plans and baselines, and other information necessary to manage the project. The needs of the project determine which components of the project management plan are needed.

Project Management Template #13 - Final Report

The final report provides a summary of the project performance. It can include information such as:

• Summary level description of the project or phase.
• Scope objectives, the criteria used to evaluate the scope, and evidence that the completion criteria were met.
• Quality objectives, the criteria used to evaluate the project and product quality, the verification and actual milestone delivery dates, and reasons for variances.
• Cost objectives, including the acceptable cost range, actual costs, and reasons for any variances.
• Summary of the validation information for the final product, service, or result.
• Schedule objectives including whether results achieved the benefits that the project was undertaken to address. If the benefits are not met at the close of the project, indicate the degree to which they were achieved and estimate for future benefits realization.
• Summary of how the final product, service, or result achieved the business needs identified in the business plan. If the business needs are not met at the close of the project, indicate the degree to which they were achieved and estimate for when the business needs will be met in the future.
• Summary of any risks or issues encountered on the project and how they were addressed.

Project Management Template #14 - Scope Management Plan

The scope management plan is a component of the project management plan that describes how the scope will be defined, developed, monitored, controlled, and validated. The components of a scope management plan include:

• Process for preparing a project scope statement
• Process that enables the creation of the WBS from the detailed project scope statement
• Process that establishes how the scope baseline will be approved and maintained
• Process that specifies how formal acceptance of the completed project deliverables will be obtained.

The scope management plan can be formal or informal, broadly framed or highly detailed, based on the needs of the project.

Project Management Template #15 - Requirements Management Plan

The requirements management plan is a component of the project management plan that describes how project and product requirements will be analyzed, documented, and managed. According to Business Analysis for Practitioners:
A Practice Guide, some organizations refer to it as a business analysis plan. Components of the requirements management plan can include but are not limited to:

• How requirements activities will be planned, tracked, and reported
• Configuration management activities such as: how changes will be initiated; how impacts will be analyzed; how they will be traced, tracked, and reported; as well as the authorization levels required to approve these changes
• Requirements prioritization process
• Metrics that will be used and the rationale for using them
• Traceability structure that reflects the requirement attributes captured on the traceability matrix.

Project Management Template #16 - Requirements Documentation

Requirements documentation describes how individual requirements meet the business need for the project. Requirements may start out at a high level and become progressively more detailed as more information about the requirements is known. Before being baselined, requirements need to be unambiguous (measurable and testable), traceable, complete, consistent, and acceptable to key stakeholders.

The format of the requirements document may range from a simple document listing all the requirements categorized by stakeholder and priority, to more elaborate forms containing an executive summary, detailed descriptions, and attachments.

Many organizations categorize requirements into different types, such as business and technical solutions, the former referring to stakeholder needs and the latter as to how those needs will be implemented. Requirements can be grouped into classifications allowing for further refinement and detail as the requirements are elaborated.

Project Management Template #17 - Requirements Traceability Matrix

The requirements traceability matrix is a grid that links product requirements from their origin to the deliverables that satisfy them. The implementation of a requirements traceability matrix helps ensure that each requirement adds business value by linking it to the business and project objectives. It provides a means to track requirements throughout the project life cycle, helping to ensure that requirements approved in the requirements documentation are delivered at the end of the project. Finally, it provides a structure for managing changes to the product scope.

Attributes associated with each requirement can be recorded in the requirements traceability matrix. These attributes help to define key information about the requirement. Typical attributes used in the requirements traceability matrix may include: a unique identifier, a textual description of the requirement, the rationale for inclusion, owner, source, priority, version, current status (such as active, cancelled, deferred, added, approved, assigned, completed), and status date. Additional attributes to ensure that the requirement has met stakeholders’ satisfaction may include stability, complexity, and acceptance criteria.

Project Management Template #18 - Project Scope Statement

The project scope statement is the description of the project scope, major deliverables, assumptions, and constraints. The project scope statement documents the entire scope, including project and product scope. It describes the project’s deliverables in detail. It also provides a common understanding of the project scope among project stakeholders. It may contain explicit scope exclusions that can assist in managing stakeholder expectations.

Project Scope Statement enables the project team to perform more detailed planning, guides the project team’s work during execution, and provides the baseline for evaluating whether requests for changes or additional work are contained within or outside the project’s boundaries. The degree and level of detail to which the project scope statement defines the work that will be performed and the work that is excluded can help determine how well the project management team can control the overall project scope. The detailed project scope statement, either directly or by reference to other documents.

Although the project charter and the project scope statement are sometimes perceived as containing a certain degree of redundancy, they are different in the level of detail contained in each. The project charter contains high-level information, while the project scope statement contains a detailed description of the scope components. These components are progressively elaborated throughout the project.

Project Management Template #19 - Scope Baseline

The scope baseline is the approved version of a scope statement, WBS, and its associated WBS dictionary, which can be changed only through formal change control procedures and is used as a basis for comparison. It is a component of the project management plan. Components of the scope baseline include:

• Project scope statement. The project scope statement includes the description of the project scope, major deliverables, assumptions, and constraints
• WBS. The WBS is a hierarchical decomposition of the total scope of work to be carried out by the project team to accomplish the project objectives and create the required deliverables. Each descending level of the WBS represents an increasingly detailed definition of the project work.
• Work package. The lowest level of the WBS is a work package with a unique identifier. These identifiers provide a structure for hierarchical summation of costs, schedule, and resource information and form a code of accounts. Each work package is part of a control account. A control account is a management control point where scope, budget, and schedule are integrated and compared to the earned value for performance measurement. A control account has two or more work packages, though each work package is associated with a single control account.
• Planning package. A control account may include one or more planning packages. A planning package is a work breakdown structure component below the control account and above the work package with known work content but without detailed schedule activities.
• WBS dictionary. The WBS dictionary is a document that provides detailed deliverable, activity, and scheduling information about each component in the WBS. The WBS dictionary is a document that supports the WBS. Most of the information included in the WBS dictionary is created by other processes and added to this document at a later stage.

Project Management Template #20 - WBS Dictionary

The WBS dictionary is a document that provides detailed deliverable, activity, and scheduling information about each component in the WBS. The WBS dictionary is a document that supports the WBS. Most of the information included in the WBS dictionary is created by other processes and added to this document at a later stage. Information in the WBS dictionary may include but is not limited to:

• Code of account identifier
• Description of work
• Assumptions and constraints
• Responsible organization
• Schedule milestones
• Associated schedule activities
• Resources required
• Cost estimates
• Quality requirements
• Acceptance criteria
• Technical references
• Agreement information.

WBS Dictionary is part of the Scope Baseline.

Project Management Template #21 - Work Breakdown Structure (WBS)

The WBS is a hierarchical decomposition of the total scope of work to be carried out by the project team to accomplish the project objectives and create the required deliverables. Each descending level of the WBS represents an increasingly detailed definition of the project work.

WBS is part of the Scope Baseline.

Project Management Template #22 - Schedule Management Plan

The schedule management plan is a component of the project management plan that establishes the criteria and the activities for developing, monitoring, and controlling the schedule. The schedule management plan may be formal or informal, highly detailed, or broadly framed based on the needs of the project, and includes appropriate control thresholds.

Project Management Template #23 - Activity List

The activity list includes the schedule activities required on the project. For projects that use rolling wave planning or agile techniques, the activity list will be updated periodically as the project progresses. The activity list includes an activity identifier and a scope of work description for each activity in sufficient detail to ensure that project team members understand what work is required to be completed.

Project Management Template #24 - Milestones List

A milestone is a significant point or event in a project. A milestone list identifies all project milestones and indicates whether the milestone is mandatory, such as those required by contract, or optional, such as those based on historical information. Milestones have zero duration because they represent a significant point or event.

Project Management Template #25 - Network Diagram

A project schedule network diagram is a graphical representation of the logical relationships, also referred to as dependencies, among the project schedule activities. A project schedule network diagram is produced manually or by using project management software. It can include full project details, or have one or more summary activities. A summary narrative can accompany the diagram and describe the basic approach used to sequence the activities. Any unusual activity sequences within the network should be fully described within the narrative.

Activities that have multiple predecessor activities indicate a path convergence. Activities that have multiple successor activities indicate a path divergence. Activities with divergence and convergence are at greater risk as they are affected by multiple activities or can affect multiple activities. Activity I is called a path convergence, as it has more than one predecessor, while activity K is called a path divergence, as it has more than one successor.

Project Management Template #26 - Duration Estimates

Duration estimates are quantitative assessments of the likely number of time periods that are required to complete an activity, a phase, or a project. Duration estimates do not include any lags. Duration estimates may include some indication of the range of possible results. For example:

• A range of 2 weeks ± 2 days, which indicates that the activity will take at least 8 days and not more than 12 (assuming a 5-day work week); or
• A 15% probability of exceeding 3 weeks, which indicates a high probability—85%—that the activity will take 3 weeks or less.

Project Management Template #27 - Project Schedule

The project schedule is an output of a schedule model that presents linked activities with planned dates, durations, milestones, and resources. At a minimum, the project schedule includes a planned start date and planned finish date for each activity. If resource planning is done at an early stage, the project schedule remains preliminary until resource assignments have been confirmed and scheduled start and finish dates are established. This process usually occurs no later than the completion of the project management plan. A target project schedule model may also be developed with a defined target start and target finish for each activity. The project schedule may be presented in summary form, sometimes referred to as the master schedule or milestone schedule, or presented in detail.

Although a project schedule model can be presented in tabular form, it is more often presented graphically, using one or more of the following formats:

• Bar charts.Also known as Gantt charts, bar charts represent schedule information where activities are listed on the vertical axis, dates are shown on the horizontal axis, and activity durations are shown as horizontal bars placed according to start and finish dates. Bar charts are relatively easy to read and are commonly used. Depending on the audience, float can be depicted or not. For control and management communications, the broader, more comprehensive summary activity is used between milestones or across multiple interdependent work packages and is displayed in bar chart reports.
• Milestone charts. These charts are similar to bar charts, but only identify the scheduled start or completion of major deliverables and key external interfaces.
• Project schedule network diagrams. These diagrams are commonly presented in the activity-on-node diagram format showing activities and relationships without a time scale, sometimes referred to as a pure logic diagram, or presented in a time-scaled schedule network diagram format that is sometimes called a logic bar chart.
  These diagrams, with activity date information, usually show both the project network logic and the project’s critical path schedule activities. This example also shows how each work package is planned as a series of related activities. Another presentation of the project schedule network diagram is a time-scaled logic diagram. These diagrams include a time scale and bars that represent the duration of activities with the logical relationships. They are optimized to show the relationships between activities where any number of activities may appear on the same line of the diagram in sequence.

Project Management Template #28 - Cost Management Plan

The cost management plan is a component of the project management plan and describes how the project costs will be planned, structured, and controlled. The cost management processes and their associated tools and techniques are documented in the cost management plan.

Project Management Template #29 - Cost Estimates

Cost estimates include quantitative assessments of the probable costs required to complete project work, as well as contingency amounts to account for identified risks, and management reserve to cover unplanned work.

Cost estimates can be presented in summary form or in detail. Costs are estimated for all resources that are applied to the cost estimate. This includes but is not limited to direct labor, materials, equipment, services, facilities, information technology, and special categories such as cost of financing (including interest charges), an inflation allowance, exchange rates, or a cost contingency reserve. Indirect costs, if they are included in the project estimate, can be included at the activity level or at higher levels.

Project Management Template #30 - Cost Baseline

The cost baseline is the approved version of the time-phased project budget, excluding any management reserves, which can only be changed through formal change control procedures. It is used as a basis for comparison to actual results.

The cost baseline is developed as a summation of the approved budgets for the different schedule activities. Cost estimates for the various project activities, along with any contingency reserves for these activities, are aggregated into their associated work package costs. The work package cost estimates, along with any contingency reserves estimated for the work packages, are aggregated into control accounts.

The summation of the control accounts makes the cost baseline. Since the cost estimates that make up the cost baseline are directly tied to the schedule activities, this enables a time-phased view of the cost baseline, which is typically displayed in the form of an S-curve. For projects that use earned value management, the cost baseline is referred to as the performance measurement baseline.

Management reserves are added to the cost baseline to produce the project budget. As changes warranting the use of management reserves arise, the change control process is used to obtain approval to move the applicable management reserve funds into the cost baseline.

Project Management Template #31 - Quality Management Plan

The quality management plan is a component of the project management plan that describes how applicable policies, procedures, and guidelines will be implemented to achieve the quality objectives. It describes the activities and resources necessary for the project management team to achieve the quality objectives set for the project.

The quality management plan may be formal or informal, detailed, or broadly framed. The style and detail of the quality management plan are determined by the requirements of the project. The quality management plan should be reviewed early in the project to ensure that decisions are based on accurate information. The benefits of this review can include a sharper focus on the project’s value proposition, reductions in costs, and less frequent schedule overruns that are caused by rework.

Project Management Template #32 - Quality Metrics

A quality metric specifically describes a project or product attribute and how the Control Quality process will verify compliance to it. Some examples of quality metrics include percentage of tasks completed on time, cost performance measured by CPI, failure rate, number of defects identified per day, total downtime per month, errors found per line of code, customer satisfaction scores, and percentage of requirements covered by the test plan as a measure of test coverage.

Project Management Template #33 - Quality Audit

Quality control measurements are the documented results of Control Quality activities. They should be captured in the format that was specified in the quality management plan.

Project Management Template #34 - Responsibility Assignment Matrix (RAM)

A Responsibility Assignment Matrix (RAM) shows the project resources assigned to each work package. It is used to illustrate the connections between work packages, or activities, and project team members. On larger projects, RAMs can be developed at various levels. For example, a high-level RAM can define the responsibilities of a project team, group, or unit within each component of the WBS. Lower-level RAMs are used within the group to designate roles, responsibilities, and levels of authority for specific activities.

The matrix format shows all activities associated with one person and all people associated with one activity. This also ensures that there is only one person accountable for any one task to avoid confusion about who is ultimately in charge or has authority for the work.

One example of a RAM is a RACI (responsible, accountable, consult, and inform) chart. The sample chart shows the work to be done in the left column as activities. The assigned resources can be shown as individuals or groups. The project manager can select other options, such as “lead” and “resource” designations, as appropriate for the project. A RACI chart is a useful tool to use to ensure clear assignment of roles and responsibilities when the team consists of internal and external resources.

Project Management Template #35 - Resources Management Plan

The resource management plan is the component of the project management plan that provides guidance on how project resources should be categorized, allocated, managed, and released. It may be divided between the team management plan and physical resource management plan according to the specifics of the project.

The resource management plan may include but is not limited to:

• Identification of resources. Methods for identifying and quantifying team and physical resources needed.
• Acquiring resources. Guidance on how to acquire team and physical resources for the project.
• Roles and responsibilities:
• Role. The function assumed by, or assigned to, a person in the project. Examples of project roles are civil engineer, business analyst, and testing coordinator.
• Authority. The rights to apply project resources, make decisions, sign approvals, accept deliverables, and influence others to carry out the work of the project. Examples of decisions that need clear authority include the selection of a method for completing an activity, quality acceptance criteria, and how to respond to project variances. Team members operate best when their individual levels of authority match their individual responsibilities.
• Responsibility. The assigned duties and work that a project team member is expected to perform in order to complete the project’s activities.
• Competence. The skill and capacity required to complete assigned activities within the project constraints. If project team members do not possess required competencies, performance can be jeopardized. When such mismatches are identified, proactive responses such as training, hiring, schedule changes, or scope changes are initiated.
• Project organization charts. A project organization chart is a graphic display of project team members and their reporting relationships. It can be formal or informal, highly detailed or broadly framed, based on the needs of the project. For example, the project organization chart for a 3,000-person disaster response team will have greater detail than a project organization chart for an internal, 20-person project.
• Project team resource management. Guidance on how project team resources should be defined, staffed, managed, and eventually released.
• Training. Training strategies for team members.
• Team development. Methods for developing the project team.
• Resource control. Methods for ensuring adequate physical resources are available as needed and that the acquisition of physical resources is optimized for project needs. Includes information on managing inventory, equipment, and supplies during throughout the project life cycle.
• Recognition plan. Which recognition and rewards will be given to team members, and when they will be given.

Project Management Template #36 - Team Charter

The team charter is a document that establishes the team values, agreements, and operating guidelines for the team. The team charter may include but is not limited to:

• Team values
• Communication guidelines
• Decision-making criteria and process
• Conflict resolution process
• Meeting guidelines
• Team agreements

The team charter establishes clear expectations regarding acceptable behavior by project team members. Early commitment to clear guidelines decreases misunderstandings and increases productivity. Discussing areas such as codes of conduct, communication, decision making, and meeting etiquette allows team members to discover values that are important to one another.

The team charter works best when the team develops it, or at least has an opportunity to contribute to it. All project team members share responsibility for ensuring the rules documented in the team charter are followed. The team charter can be reviewed and updated periodically to ensure a continued understanding of the team ground rules and to orient and integrate new team members.

Project Management Template #37 - Team Directory

Team Directory stores the high level information about the resources in a project such as title, department, planned holidays, working hour etc.

Project Management Template #38 - Resource Requirements

Resource requirements identify the types and quantities of resources required for each work package or activity in a work package and can be aggregated to determine the estimated resources for each work package, each WBS branch, and the project as a whole. The amount of detail and the level of specificity of the resource requirement descriptions can vary by application area. The resource requirements’ documentation can include assumptions that were made in determining which types of resources are applied, their availability, and what quantities are needed.

Resource requirements identify the types and quantities of resources required for each work package or activity used to create the schedule model.

Resource leveling can have a significant effect on preliminary estimates for the types and quantities of resources required. If the resource-leveling analysis changes the resource requirements, then the resource requirements are updated.

The estimated activity resource requirements will have an effect on the duration of the activity, since the level to which the resources assigned to the activity meet the requirements will significantly influence the duration of most activities. For example, if additional or lowerskilled resources are assigned to an activity, there may be reduced efficiency or productivity due to increased communication, training, and coordination needs leading to a longer duration estimate

Project Management Template #39 - Resource Breakdown Structure

The resource breakdown structure is a hierarchical representation of resources by category and type. Examples of resource categories include but are not limited to labor, material, equipment, and supplies. Resource types may include the skill level, grade level, required certifications, or other information as appropriate to the project.

In Plan Resource Management, the resource breakdown structure was used to guide the categorization for the project. In this process it is a completed document that will be used to acquire and monitor resources.

Project Management Template #40 - Individual Assessment

Individual and team assessment tools give the project manager and the project team insight into areas of strengths and weaknesses. These tools help project managers assess team members’ preferences, aspirations, how they process and organize information, how they make decisions, and how they interact with people.

Various tools are available such as attitudinal surveys, specific assessments, structured interviews, ability tests, and focus groups. These tools can provide improved understanding, trust, commitment, and communications among team members and facilitate more productive teams throughout the project.

Project Management Template #41 - Team Performance Assessments

As project team development efforts such as training, team building, and colocation are implemented, the project management team makes formal or informal assessments of the project team’s effectiveness. Effective team development strategies and activities are expected to increase the team’s performance, which increases the likelihood of meeting project objectives.

The evaluation of a team’s effectiveness may include indicators such as:

• Improvements in skills that allow individuals to perform assignments more effectively
• Improvements in competencies that help team members perform better as a team
• Reduced staff turnover rate
• Increased team cohesiveness where team members share information and experiences openly and help each other to improve the overall project performance.

As a result of conducting an evaluation of the team’s overall performance, the project management team can identify the specific training, coaching, mentoring, assistance, or changes required to improve the team’s performance. This should also include identifying the appropriate or required resources necessary to achieve and implement the improvements identified in the assessment.

Project Management Template #42 - Communications Management Plan

The communications management plan is a component of the project management plan that describes how project communications will be planned, structured, implemented, and monitored for effectiveness. The plan contains information such as Stakeholder communication requirements, Information to be communicated, including language, format, content, and level of detail, Escalation processes etc.

The communications management plan can include guidelines and templates for project status meetings, project team meetings, e-meetings, and email messages. The use of a project website and project management software can be included if these are to be used in the project.

Project Management Template #43 - Risk Management Plan

The risk management plan is a component of the project management plan that describes how risk management activities will be structured and performed. The risk management plan may include some or all of the following elements:

• Risk strategy. Describes the general approach to managing risk on this project.
• Methodology. Defines the specific approaches, tools, and data sources that will be used to perform risk management on the project.
• Roles and responsibilities. Defines the lead, support, and risk management team members for each type of activity described in the risk management plan, and clarifies their responsibilities.
• Funding. Identifies the funds needed to perform activities related to Project Risk Management. Establishes protocols for the application of contingency and management reserves.
• Timing. Defines when and how often the Project Risk Management processes will be performed throughout the project life cycle, and establishes risk management activities for inclusion into the project schedule.
• Risk categories. Provide a means for grouping individual project risks. A common way to structure risk categories is with a risk breakdown structure (RBS), which is a hierarchical representation of potential sources of risk. An RBS helps the project team consider the full range of sources from which individual project risks may arise. This can be useful when identifying risks or when categorizing identified risks. The organization may have a generic RBS to be used for all projects, or there may be several RBS frameworks for different types of projects, or the project may develop a tailored RBS. Where an RBS is not used, an organization may use a custom risk categorization framework, which may take the form of a simple list of categories or a structure based on project objectives.
• Stakeholder risk appetite. The risk appetites of key stakeholders on the project are recorded in the risk management plan, as they inform the details of the Plan Risk Management process. In particular, stakeholder risk appetite should be expressed as measurable risk thresholds around each project objective. These thresholds will determine the acceptable level of overall project risk exposure, and they are also used to inform the definitions of probability and impacts to be used when assessing and prioritizing individual project risks.
• Definitions of risk probability and impacts. Definitions of risk probability and impact levels are specific to the project context and reflect the risk appetite and thresholds of the organization and key stakeholders. The project may generate specific definitions of probability and impact levels or it may start with general definitions provided by the organization. The number of levels reflects the degree of detail required for the Project Risk Management process, with more levels used for a more detailed risk approach (typically five levels), and fewer for a simple process (usually three). These scales can be used to evaluate both threats and opportunities by interpreting the impact definitions as negative for threats (delay, additional cost, and performance shortfall) and positive for opportunities (reduced time or cost, and performance enhancement).
• Probability and impact matrix. Prioritization rules may be specified by the organization in advance of the project and be included in organizational process assets, or they may be tailored to the specific project. Opportunities and threats are represented in a common probability and impact matrix using positive definitions of impact for opportunities and negative impact definitions for threats. Descriptive terms (such as very high, high, medium, low, and very low) or numeric values can be used for probability and impact. Where numeric values are used, these can be multiplied to give a probability-impact score for each risk, which allows the relative priority of individual risks to be evaluated within each priority level.
• Reporting formats. Reporting formats define how the outcomes of the Project Risk Management process will be documented, analyzed, and communicated. This section of the risk management plan describes the content and format of the risk register and the risk report, as well as any other required outputs from the Project Risk Management processes.
• Tracking. Tracking documents how risk activities will be recorded and how risk management processes will be audited.

Project Management Template #44 - Risk Register

The risk register captures details of identified individual project risks. The results of Perform Qualitative Risk Analysis, Plan Risk Responses, Implement Risk Responses, and Monitor Risks are recorded in the risk register as those processes are conducted throughout the project. The risk register may contain limited or extensive risk information depending on project variables such as size and complexity.

On completion of the Identify Risks process, the content of the risk register may include but is not limited to:

• List of identified risks. Each individual project risk is given a unique identifier in the risk register. Identified risks are described in as much detail as required to ensure unambiguous understanding. A structured risk statement may be used to distinguish risks from their cause(s) and their effect(s).
• Potential risk owners. Where a potential risk owner has been identified during the Identify Risks process, the risk owner is recorded in the risk register. This will be confirmed during the Perform Qualitative Risk Analysis process.
• List of potential risk responses. Where a potential risk response has been identified during the Identify Risks process, it is recorded in the risk register. This will be confirmed during the Plan Risk Responses process.

Additional data may be recorded for each identified risk, depending on the risk register format specified in the risk management plan. This may include: a short risk title, risk category, current risk status, one or more causes, one or more effects on objectives, risk triggers (events or conditions that indicate that a risk is about to occur), WBS reference of affected activities, and timing information (when was the risk identified, when might the risk occur, when might it no longer be relevant, and what is the deadline for taking action).

Project Management Template #45 - Risk Report

The risk report presents information on sources of overall project risk, together with summary information on identified individual project risks. The risk report is developed progressively throughout the Project Risk Management process. The results of Perform Qualitative Risk Analysis, Perform Quantitative Risk Analysis, Plan Risk Responses, Implement Risk Responses, and Monitor Risks are also included in the risk report as those processes are completed.

On completion of the Identify Risks process, information in the risk report may include but is not limited to:

• Sources of overall project risk, indicating which are the most important drivers of overall project risk exposure; and
• Summary information on identified individual project risks, such as number of identified threats and opportunities, distribution of risks across risk categories, metrics and trends, etc.

Additional information may be included in the risk report, depending on the reporting requirements specified in the risk management plan.

Project Management Template #46 - Risk Probability and Impact Matrix

A probability and impact matrix is a grid for mapping the probability of each risk occurrence and its impact on project objectives if that risk occurs. This matrix specifies combinations of probability and impact that allow individual project risks to be divided into priority groups.

Risks can be prioritized for further analysis and planning of risk responses based on their probability and impacts. The probability of occurrence for each individual project risk is assessed as well as its impact on one or more project objectives if it does occur, using definitions of probability and impact for the project as specified in the risk management plan. Individual project risks are assigned to a priority level based on the combination of their assessed probability and impact, using a probability and impact matrix.

An organization can assess a risk separately for each objective (e.g., cost, time, and scope) by having a separate probability and impact matrix for each. Alternatively, it may develop ways to determine one overall priority level for each risk, either by combining assessments for different objectives, or by taking the highest priority level regardless of which objective is affected.

Project Management Template #47 - Procurement Management Plan

The procurement management plan contains the activities to be undertaken during the procurement process. It should document whether international competitive bidding, national competitive bidding, local bidding, etc., should be done. If the project is financed externally, the sources and availability of funding should be aligned with the procurement management plan and the project schedule.

The procurement management plan can include guidance for:

• How procurement will be coordinated with other project aspects, such as project schedule development and control processes;
• Timetable of key procurement activities
• Procurement metrics to be used to manage contracts
• Stakeholder roles and responsibilities related to procurement, including authority and constraints of the project team when the performing organization has a procurement department
• Constraints and assumptions that could affect planned procurements
• The legal jurisdiction and the currency in which payments will be made
• Determination of whether independent estimates will be used and whether they are needed as evaluation criteria
• Risk management issues including identifying requirements for performance bonds or insurance contracts to mitigate some forms of project risk; and
• Prequalified sellers, if any, to be used.

A procurement management plan can be formal or informal, can be highly detailed or broadly framed, and is based upon the needs of each project.

Project Management Template #48 - Stakeholder Analysis Matrix

Stakeholder analysis results in a list of stakeholders and relevant information such as their positions in the organization, roles on the project, “stakes,” expectations, attitudes (their levels of support for the project), and their interest in information about the project. Stakeholders’ stakes can include but are not limited to a combination of:

• Interest. A person or group can be affected by a decision related to the project or its outcomes.
• Rights (legal or moral rights). Legal rights, such as occupational health and safety, may be defined in the legislation framework of a country. Moral rights may involve concepts of protection of historical sites or environmental sustainability.
• Ownership. A person or group has a legal title to an asset or a property.
• Knowledge. Specialist knowledge, which can benefit the project through more effective delivery of project objectives, organizational outcomes, or knowledge of the power structures of the organization.
• Contribution. Provision of funds or other resources, including human resources, or providing support for the project in more intangible ways, such as advocacy in the form of promoting the objectives of the project or acting as a buffer between the project and the power structures of the organization and its politics.

Project Management Template #49 - Stakeholder Register

The main output of the Identify Stakeholders process is the stakeholder register. This document contains information about identified stakeholders that includes but is not limited to:

• Identification information. Name, organizational position, location and contact details, and role on the project.
• Assessment information. Major requirements, expectations, potential for influencing project outcomes, and the phase of the project life cycle where the stakeholder has the most influence or impact.
• Stakeholder classification. Internal/external, impact/influence/power/interest, upward/downward/outward/sideward, or any other classification model chosen by the project manager.

Project Management Template #50 - Stakeholder Engagement Plan

The stakeholder engagement plan is a component of the project management plan that identifies the strategies and actions required to promote productive involvement of stakeholders in decision making and execution. It can be formal or informal and highly detailed or broadly framed, based on the needs of the project and the expectations of stakeholders. The stakeholder engagement plan may include but is not limited to specific strategies or approaches for engaging with individuals or groups of stakeholders.

-Want to learn more about Project Management Templates?

Enroll in our Free Project Management Templates program.