Search in book...
Toggle Font Controls
Create new playlist

Name your new playlist

Playlist description (optional)
Sign In

Email address

Password

Forgot Password?

or

Continue with Facebook

Continue with Google
Sign Up

Full Name

Email address

Confirm Email Address

Password

or

Continue with Facebook

Continue with Google

2
Planning Forms

2.0 PLANNING PROCESS GROUP

The purpose of the Planning Process Group is to elaborate the information from the project charter to create a comprehensive set of plans that will enable the project team to deliver the project objectives. There are 24 processes in the Planning Process Group.

Develop project management plan
Plan scope management
Collect requirements
Define scope
Create work breakdown structure (WBS)
Plan schedule management
Define activities
Sequence activities
Estimate activity durations
Develop schedule
Plan cost management
Estimate costs
Determine budget
Plan quality management
Plan resource management
Estimate activity resources
Plan communications management
Plan risk management
Identify risks
Perform qualitative analysis
Perform quantitative analysis
Plan risk responses
Plan procurement management
Plan stakeholder management

The intent of the Planning Process Group is to at least:

Elaborate and clarify the project scope
Develop a realistic schedule
Develop a realistic budget
Identify project and product quality processes
Identify and plan for the needed project resources
Determine and plan for the communication needs
Establish risk management practices
Identify the procurement needs of the project
Determine how to effectively engage stakeholders
Combine all the planning information into a project management plan and a set of project documents that are cohesive and integrated

Planning is not a one-time event. It occurs throughout the project. Initial plans will become more detailed as additional information about the project becomes available. Additionally, as changes are approved for the project or product, many of the planning processes will need to be revisited and the documents revised and updated.

Many of the forms in this section provide information needed for other forms. The form description indicates from where information is received and to where it goes.

The forms used to document planning information include:

Project management plan
Change management plan
Project roadmap
Scope management plan
Requirements management plan
Requirements documentation
Requirements traceability matrix
Project scope statement
Assumption log
Work breakdown structure (WBS)
Work breakdown structure dictionary
Schedule management plan
Activity list
Activity attributes
Milestone list
Network diagram
Duration estimates
Duration estimating worksheet
Project schedule
Cost management plan
Cost estimates
Cost estimating worksheet
Bottom-up cost estimating worksheet
Cost baseline
Quality management plan
Quality metrics
Responsibility assignment matrix
Roles and responsibilities
Resource management plan
Team charter
Resource requirements
Resource breakdown structure
Communications management plan
Risk management plan
Risk register
Risk report
Probability and impact assessment
Probability and impact matrix
Risk data sheet
Procurement management plan
Procurement strategy
Source selection criteria
Procurement strategy
Stakeholder engagement plan

Some forms in this section are not explicitly described in the PMBOK® Guide – Sixth Edition, but they are useful in planning and managing a project. Use the forms here as a starting point for your project. You should tailor the forms to meet the needs of your project by editing, combining, or revising them.

2.1 PROJECT MANAGEMENT PLAN

The project management plan describes how the team will execute, monitor, control, and close the project. While it has some unique information, it is primarily comprised of all the subsidiary management plans and the baselines. The project management plan combines all this information into a cohesive and integrated approach to managing the project. Typical information includes:

Selected project life cycle
Development approach for key deliverables
Variance thresholds
Baseline management
Timing and types of reviews

The project management plan contains plans for managing all the Knowledge Areas as well as specific aspects of the project that require special focus. These take the form of subsidiary management plans and can include:

Change management plan
Scope management plan
Schedule management plan
Requirements management plan
Cost management plan
Quality management plan
Resource management plan
Communications management plan
Risk management plan
Procurement management plan
Stakeholder engagement plan

The project management plan also contains baselines. Common baselines include:

Scope baseline
Schedule baseline
Cost baseline
Performance measurement baseline (an integrated baseline that includes scope, schedule, and cost)

In addition, any other relevant, project-specific information that will be used to manage the project is recorded in the project management plan.

The project management plan can receive information from all the subsidiary management plans and baselines. Because it is the foundational document for managing the project it also provides information to all subsidiary plans. In addition, the project management plan provides information to all other integration processes.

The project management plan is an output from the process 4.2 Develop Project Management Plan in the PMBOK^® Guide – Sixth Edition. This document is developed as the initial project planning is conducted, and then it is not usually changed unless there is a significant change in the charter, environment, or scope of the project.

Tailoring Tips

Consider the following tips to help tailor the project management plan to meet your needs:

For large and complex projects, each subsidiary management plan will likely be a separate standalone plan. In this case you may present your project management plan as a shell with just information on the life cycle, development approach, and key reviews, and then provide a link or reference to the more detailed subsidiary management plans.
For smaller projects, a project roadmap that summarizes the project phases, major deliverables, milestones, and key reviews may be sufficient.
You will likely have additional subsidiary management plans that are relevant to the nature of your project, such as a technology management plan, a logistics management plan, a safety management plan, and so forth.

Alignment

The project management plan should be aligned and consistent with the following documents:

All subsidiary management plans
Project roadmap
Milestone list

Description

You can use the element descriptions in Table 2.1 to assist you in developing a project management plan.

TABLE 2.1 Elements of a Project Management Plan

Document Element	Description
Project life cycle	Describe the life cycle that will be used to accomplish the project. This may include the following: Name of each phase Key activities for the phase Key deliverables for the phase Entry criteria for the phase Exit criteria for the phase Key reviews for the phase
Development approaches	Document the specific approach you will take to create key deliverables. Common approaches include predictive approaches, where the scope is known and stable; and adaptive approaches, where the scope is evolving and subject to change. It may also include iterative or incremental development approaches.
Subsidiary management plans	List the subsidiary management plans that are part of the project management plan. This can be in the form of a “table of contents,” links to electronic copies of the subsidiary plans, or a list of the other plans that should be considered part of the project management plan, but are separate documents.
Scope variance threshold	Define acceptable scope variances, variances that indicate a warning, and variances that are unacceptable. Scope variance can be indicated by the features and functions that are present in the end product, or the performance metrics that are desired.
Scope baseline management	Describe how the scope baseline will be managed, including responses to acceptable, warning, and unacceptable variances. Define circumstances that would trigger preventive or corrective action and when the change control process would be enacted. Define the difference between a scope revision and a scope change. Generally, a revision does not require the same degree of approval that a change does. For example, changing the color of something is a revision; changing a function is a change.
Schedule variance threshold	Define acceptable schedule variances, variances that indicate a warning, and variances that are unacceptable. Schedule variances may indicate the percent of variance from the baseline or they may include the amount of float used or whether any schedule reserve has been used.
Schedule baseline management	Describe how the schedule baseline will be managed, including responses to acceptable, warning, and unacceptable variances. Define circumstances that would trigger preventive or corrective action and when the change control process would be enacted.
Cost variance threshold	Define acceptable cost variances, variances that indicate a warning, and variances that are unacceptable. Cost variances may indicate the percent of variance from the baseline, such as 0–5 percent, 5–10 percent, and greater than 10 percent.
Cost baseline management	Describe how the cost baseline will be managed, including responses to acceptable, warning, and unacceptable variances. Define circumstances that would trigger preventive or corrective action and when the change control process would be enacted.
Baselines	Attach all project baselines.

PROJECT MANAGEMENT PLAN

Project Title: _______________________ Date Prepared: _______________________

Project Life Cycle:

Phase	Key Activities	Key Deliverables

Phase	Reviews	Entry Criteria	Exit Criteria

Development Approaches:

Deliverable	Development Approach

Subsidiary Management Plans:

Name	Comment
Scope
Time
Cost
Quality
Resource
Communications
Risk
Procurement
Stakeholder
Other Plans

Variance Thresholds:

Scope Variance Threshold	Scope Baseline Management
Schedule Variance Threshold	Schedule Baseline Management
Cost Variance Threshold	Cost Baseline Management

Baselines:

Attach all project baselines.

2.2 CHANGE MANAGEMENT PLAN

The change management plan is a component of the project management plan. It describes how change will be managed on the project. Typical information includes:

Structure and membership of a change control board
Definitions of change
Change control board
- Roles
- Responsibilities
- Authority
Change management process
- Change request submittal
- Change request tracking
- Change request review
- Change request disposition

The change management plan is related to:

Change log
Change request form

It provides information to:

Project management plan

The change management plan is a part of the project management plan and as such it is an output from the process 4.2 Develop Project Management Plan in the PMBOK^® Guide – Sixth Edition. This document is developed once and is not usually changed.

Tailoring Tips

Consider the following tips to help tailor the change management plan to meet your needs:

If you have a few product components or project documents that require configuration management, you may be able to combine change management and configuration management into one plan.
The rigor and structure of your change management plan should reflect the product development approach. For predictive approaches, a rigorous change management approach is appropriate. For adaptive approaches, the change management plan should allow for evolving scope.

Alignment

The change management plan should be aligned and consistent with the following documents:

Project roadmap or development approach
Scope management plan
Requirements management plan
Schedule management plan
Cost management plan
Quality management plan
Configuration management plan

Description

You can use the descriptions in Table 2.2 to assist you in developing a change management plan.

TABLE 2.2 Elements of a Change Management Plan

Document Element	Description
Change management approach	Describe the degree of change control and how change control will integrate with other aspects of project management.
Definitions of change	Schedule Change: Define a schedule change versus a schedule revision. Indicate when a schedule variance needs to go through the change control process to be re-baselined. Budget Change: Define a budget change versus a budget update. Indicate when a budget variance needs to go through the change control process to be re-baselined. Scope Change: Define a scope change versus progressive elaboration. Indicate when a scope variance needs to go through the change control process to be re-baselined. Project Document Change: Define when updates to project management documents or other project documents need to go through the change control process to be re-baselined.
Change control board	Name	Individual’s name
	Role	Position on the change control board
	Responsibility	Responsibilities and activities required of the role
	Authority	Authority level for approving or rejecting changes
Change control process	Change request submittal	Describe the process used to submit change requests, including who receives requests and any special forms, policies, or procedures that need to be used.
	Change request tracking	Describe the process for tracking change requests from submittal to final disposition.
	Change request review	Describe the process used to review change requests, including analysis of impact on project objectives such as schedule, scope, cost, etc.
	Change request outcome	Describe the possible outcomes, such as accept, defer, or reject.

CHANGE MANAGEMENT PLAN

Project Title: _______________________ Date Prepared:_______________________

Change Management Approach:

Definitions of Change:

Schedule change:

Budget change:

Scope change:

Project document changes:

Change Control Board:

Name	Role	Responsibility	Authority

Change Control Process:

Change request submittal
Change request tracking
Change request review
Change request disposition

Attach relevant forms used in the change control process.

2.3 PROJECT ROADMAP

The project roadmap is a high-level visual summary of the life cycle phases, key deliverables, management reviews and milestones. Typical information includes:

Project life cycle phases
Major deliverables or events in each phase
Significant milestones
Timing and types of reviews

The project roadmap can receive information from the project charter and the project management plan. In particular, the key deliverables, project life cycle, management reviews, and scope and schedule baselines.

It provides information to

Project schedule
Risk register
Milestone list

The project roadmap is not listed as an output in the PMBOK^® Guide – Sixth Edition. If it is developed it would be in conjunction with the project management plan. It is developed once, and then only changed if dates of the key events, milestones, or deliverables change.

Tailoring Tips

Consider the following tips to help tailor the project roadmap to meet your needs:

For large and complex projects this will likely be a separate stand-alone document.
For smaller projects the project roadmap may serve as the project management plan.

Alignment

The project roadmap should be aligned and consistent with the following documents:

Project management plan
Milestone list

Description

You can use the element descriptions in the following table to assist you in developing a project management plan.

Document Element	Description
Project life cycle phases	The name of each life cycle phase
Major deliverables or events	Key deliverables, phase gates, key approvals, external events, or other significant events in the project
Significant milestones	Milestones in the project
Timing and types of reviews	Management, customer, compliance, or other significant reviews

2.4 SCOPE MANAGEMENT PLAN

The scope management plan is part of the project management plan. It specifies how the project scope will be defined, developed, monitored, controlled, and validated. Planning how to manage scope should include at least processes for:

Developing a detailed scope statement
Decomposing the project into discrete deliverables using a WBS
Determining what constitutes a scope change versus a revision and how scope changes will be managed through the formal change control process
Maintaining the WBS and the scope baseline
How deliverables will be accepted

In addition, the scope management plan may provide direction on the elements that should be contained in a WBS Dictionary and how the scope and requirements management plans interact.

The scope management plan can receive information from:

Project charter
Project management plan

It provides information to:

Requirements documentation
Scope statement
WBS
WBS dictionary

The scope management plan is an output from the process 5.1 Plan Scope Management in the PMBOK^® Guide – Sixth Edition. It is developed once and does not usually change.

Tailoring Tips

Consider the following tips to help tailor the scope management plan to meet your needs:

For smaller projects you can combine the scope management plan with the requirements management plan.
For larger projects consider a test and evaluation plan that defines how deliverables will be validated and accepted by the customer.
If your project involves business analysis you may want to incorporate information on how business analysis activities and project management activities will interact.
If you are using an agile or adaptive development approach you may want to incorporate information on the release and iteration plans.

Alignment

The scope management plan should be aligned and consistent with the following documents:

Development approach
Life cycle description
Change management plan
Requirements management plan
Release and iteration plan

Description

You can use the descriptions in Table 2.3 to assist you in developing a scope management plan.

TABLE 2.3 Elements of the Scope Management Plan

Document Element	Description
WBS	Describe the WBS and whether it will be arranged using phases, geography, major deliverables, or some other way. The guidelines for establishing control accounts and work packages can also be documented in this section.
WBS Dictionary	Identify the information that will be documented in the WBS Dictionary and the level of detail required.
Scope baseline maintenance	Identify the types of scope changes that will need to go through the formal change control process and how the scope baseline will be maintained.
Deliverable acceptance	For each deliverable, identify how the deliverable will be validated for customer acceptance, including any tests or documentation needed for sign-off.
Scope and requirements integration	Describe how project and product requirements will be addressed in the scope statement and WBS. Identify the integration points and how requirements and scope validation will occur.
Project management and business analysis integration	Describe how business analysis and project management will integrate as scope is being defined, developed, tested, validated, and turned over to operations.

2.5 REQUIREMENTS MANAGEMENT PLAN

The requirements management plan is part of the project management plan. It specifies how requirements activities will be conducted throughout the project. Managing requirements activities includes at least:

Planning activities such as:
- Collecting/eliciting
- Analyzing
- Categorizing
- Prioritizing
- Documenting
- Determining metrics
- Defining the traceability structure
Managing activities such as:
- Tracking
- Reporting
- Tracing
- Validating
- Performing configuration management

The requirements management plan can receive information from:

Project charter
Development approach
Quality management plan

It is related to:

Scope management plan

It provides information to:

Requirements documentation
Requirements traceability matrix
Quality management plan
Risk register

The requirements management plan is an output from the process 5.1 Plan Scope Management in the PMBOK^® Guide – Sixth Edition. It is developed once and does not usually change.

Tailoring Tips

Consider the following tips to help tailor the management plan to meet your needs:

For smaller projects you can combine the requirements management plan with the scope management plan.
If your project involves business analysis, you may want to incorporate information on how business analysis requirements activities and project management requirements activities will interact.
You can document the test and evaluation strategy in this plan. For larger projects you may want to have a separate testing plan.
If you are using an agile or adaptive development approach you may want to incorporate information on how the backlog will be used to manage and track requirements.

Alignment

The requirements management plan should be aligned and consistent with the following documents:

Development approach
Change management plan
Scope management plan
Release and iteration plan
Requirements backlog

Description

You can use the descriptions in Table 2.4 to assist you in developing a requirements management plan.

TABLE 2.4 Elements of the Requirements Management Plan

Document Element	Description
Requirements collection	Describe how requirements will be collected or elicited. Consider techniques such as brainstorming, interviewing, observation, etc.
Requirements analysis	Describe how requirements will be analyzed for prioritization, categorization, and impact to the product or project approach.
Requirements categories	Identify categories for requirements such as business, stakeholder, quality, etc.
Requirements documentation	Define how requirements will be documented. The format of a requirements document may range from a simple spreadsheet to more elaborate forms containing detailed descriptions and attachments.
Requirements prioritization	Identify the prioritization approach for requirements. Certain requirements will be non-negotiable, such as those that are regulatory or those that are needed to comply with the organization’s policies or infrastructure. Other requirements may be nice to have, but not necessary for functionality.
Requirements metrics	Document the metrics that requirements will be measured against. For example, if the requirement is that the product must be able to support 150 lb, the metric may be that it is designed to support 120 percent (180 lb) and that any design or engineering decisions that cause the product to go below the 120 percent need approval by the customer.
Requirements traceability	Identify the information that will be used to link requirements from their origin to the deliverables that satisfy them.
Requirements tracking	Describe how often and what techniques will be used to track progress on requirements.
Requirements reporting	Describe how reporting on requirements will be conducted and the frequency of such reporting.
Requirements validation	Identify the various methods that will be used to validate requirements such as inspection, audits, demonstration, testing, etc.
Requirements configuration management	Describe the configuration management system that will be used to control requirements, documentation, the change management process, and the authorization levels needed to approve changes.

2.6 REQUIREMENTS DOCUMENTATION

Project success is directly influenced by the discovery and decomposition of stakeholders’ needs into requirements and by the care taken in determining, documenting, and managing the requirements of the product, service, or result of the project.

These requirements need to be documented in enough detail to be included in the scope baseline and be measured and validated. Requirements documentation assists the project manager in making tradeoff decisions among requirements and in managing stakeholder expectations. Requirements will be progressively elaborated as more information about the project becomes available.

When documenting requirements, it is useful to group them by category. Some common categories include:

Business requirements
Stakeholder requirements
Solution requirements
Transition and readiness requirements
Project requirements
Quality requirements

Requirements documentation should include at least:

Identifier
Requirement
Stakeholder
Category
Priority
Acceptance criteria
Test or verification method
Release or phase

Requirements documentation can receive information from:

Project charter
Assumption log
Stakeholder register
Scope management plan
Requirements management plan
Stakeholder management plan
Lessons learned register

It provides information to:

Stakeholder register
Scope baseline
Quality management plan
Resource management plan
Communications management plan
Risk register
Procurement management plan
Project close out report

Requirements documentation is an output from the process 5.2 Collect Requirements in the PMBOK^® Guide – Sixth Edition. This process is done once for projects that have a well-defined scope that is not likely to change. For projects that are adaptive, the requirements documentation can evolve and change throughout the project.

Tailoring Tips

Consider the following tips to help tailor the requirements documentation to meet your needs:

If you are using an agile or adaptive development approach you may want to incorporate information on the release or iteration for each requirement.
For a project with a lot of requirements you may want to indicate the relationships between requirements.
You can add information about assumptions or constraints associated with requirements.
For small and quick adaptive or agile projects, the requirements documentation and backlog can be combined.

Alignment

The requirements documentation should be aligned and consistent with the following documents:

Requirements management plan
Benefits management plan
Quality management plan
Requirements traceability matrix
Release plan

Description

You can use the descriptions in Table 2.5 to assist you in developing requirements documentation.

TABLE 2.5 Elements of Requirements Documentation

Document Element	Description
ID	A unique identifier for the requirement
Requirement	The condition or capability that must be met by the project or be present in the product, service, or result to satisfy a need or expectation of a stakeholder
Stakeholder	Stakeholder’s name. If you don’t have a name you can substitute a position or organization until you have more information
Category	The category of the requirement
Priority	The priority group, for example Level 1, Level 2, etc., or must have, should have, or nice to have
Acceptance criteria	The criteria that must be met for the stakeholder to approve that the requirement has been fulfilled
Test or verification method	The means that will be used to verify that the requirement has been met. This can include inspection, test, demonstration, or analysis
Phase or release	The phase or release in which the requirement will be met

REQUIREMENTS DOCUMENTATION

Project Title: _______________________ Date Prepared: _______________________

ID	Requirement	Stakeholder	Category	Priority	Acceptance Criteria	Test or Verification	Phase or Release

2.7 REQUIREMENTS TRACEABILITY MATRIX

A requirements traceability matrix is used to track the various attributes of requirements throughout the project life cycle. It uses information from the requirements documentation and traces how those requirements are addressed through other aspects of the project. The following form shows how requirements would be traced to project objectives, WBS deliverables, the metrics they will be measured to, and how they will be validated.

Another way to use the matrix is to trace the relationship between categories of requirements. For example:

Business objectives and technical requirements
Functional requirements and technical requirements
Requirements and verification method
Technical requirements and WBS deliverables

An inter-requirements traceability matrix can be used to record this information. A sample form is included after the requirements traceability matrix.

The requirements traceability matrix can receive information from:

Project charter
Assumption log
Stakeholder register
Scope management plan
Requirements management plan
Stakeholder engagement plan
Lessons learned register

It provides information to:

Quality management plan
Procurement statement of work
Product acceptance
Change requests

The requirements traceability matrix is an output from the process 5.2 Collect Requirements in the PMBOK^® Guide – Sixth Edition.

Tailoring Tips

Consider the following tips to help tailor the requirements traceability matrix to meet your needs:

For complex projects you may need to invest in requirements management software to help manage and track requirements. Using a paper form is usually only helpful for small projects or when tracking requirements at a high level.
For projects with one or more vendors you may want to add a field indicating which organization is accountable for meeting each requirement.
Consider an outline format with the business requirement at a parent level and technical requirement and specifications subordinate to the business requirement.

Alignment

The requirements traceability matrix should be aligned and consistent with the following documents:

Development approach
Requirements management plan
Requirements documentation
Release and iteration plan

Description

You can use the element descriptions in Tables 2.6 and 2.7 to assist you in developing a requirements traceability matrix and an inter-requirements traceability matrix. The matrix shown uses an example of business and technical requirements.

TABLE 2.6 Requirements Traceability Matrix

Document Element	Description
ID	Enter a unique requirement identifier.
Requirement	Document the condition or capability that must be met by the project or be present in the product, service, or result to satisfy a need or expectation of a stakeholder.
Source	The stakeholder that identified the requirement.
Category	Categorize the requirement. Categories can include functional, nonfunctional, maintainability, security, etc.
Priority	Prioritize the requirement category, for example Level 1, Level 2, etc., or must have, should have, or nice to have.
Business objective	List the business objective as identified in the charter or business case that is met by fulfilling the requirement.
Deliverable	Identify the deliverable that is associated with the requirement.
Verification	Describe the metric that is used to measure the satisfaction of the requirement.
Validation	Describe the technique that will be used to validate that the requirement meets the stakeholder needs.

TABLE 2.7 Inter-Requirements Traceability Matrix

Document Element	Description
ID	Enter a unique business requirement identifier.
Business requirement	Document the condition or capability that must be met by the project or be present in the product, service, or result to satisfy the business needs.
Priority	Prioritize the business requirement category, for example Level 1, Level 2, etc., or must have, should have, or nice to have.
Source	Document the stakeholder who identified the business requirement.
ID	Enter a unique technical requirement identifier.
Technical requirement	Document the technical performance that must be met by the deliverable to satisfy a need or expectation of a stakeholder.
Priority	Prioritize the technical requirement category, for example Level 1, Level 2, etc., or must have, should have, or nice to have.
Source	Document the stakeholder who identified the technical requirement.

REQUIREMENTS TRACEABILITY MATRIX

Project Title: _______________________ Date Prepared: _______________________

Requirement Information					Relationship Traceability
ID	Requirement	Source	Priority	Category	Business Objective	Deliverable	Verification	Validation

INTER-REQUIREMENTS TRACEABILITY MATRIX

Project Title: _______________________ Date Prepared: _______________________

ID	Business Requirement	Priority	Source	ID	Technical Requirement	Priority	Source

2.8 PROJECT SCOPE STATEMENT

The project scope statement assists in defining and developing the project and product scope. The project scope statement should contain at least this information:

Project scope description
Project deliverables
Product acceptance criteria
Project exclusions

The project scope statement can receive information from:

Project charter
Assumption log
Scope management plan
Requirements documentation
Risk register

It provides information to:

Work breakdown structure
Scope baseline

The project scope statement is an output from the process 5.3 Define Scope in the PMBOK^® Guide – Sixth Edition. It is developed once and is not usually updated unless there is a significant change in scope.

Tailoring Tips

Consider the following tips to help tailor the project scope statement to meet your needs:

For smaller projects you can combine the project scope statement with the project charter.
For agile projects you can combine the information with the release and iteration plan.

Alignment

The project scope statement should be aligned and consistent with the following documents:

Project charter
Work breakdown structure
Requirements documentation

Description

You can use the element descriptions in Table 2.8 to assist you in developing a project scope statement.

TABLE 2.8 Elements of a Project Scope Statement

Document Element	Description
Project scope description	Project scope is progressively elaborated from the project description in the project charter and the requirements in the requirements documentation.
Project deliverables	Project deliverables are progressively elaborated from the project description key deliverables in the project charter.
Product acceptance criteria	Acceptance criteria is progressively elaborated from the information in the project charter. Acceptance criteria can be developed for each component of the project.
Project exclusions	Project exclusions clearly define what is out of scope for the product and project.

2.9 WORK BREAKDOWN STRUCTURE

The work breakdown structure (WBS) is used to decompose all the work of the project. It begins at the project level and is successively broken down into finer levels of detail. The lowest level, a work package, represents a discrete deliverable that can be decomposed into activities to produce the deliverable.

The WBS should have a method of identifying the hierarchy, such as a numeric structure. The WBS can be shown as a hierarchical chart or as an outline. The approved WBS, its corresponding WBS dictionary, and the project scope statement comprise the scope baseline for the project.

The WBS can receive information from:

Scope management plan
Project scope statement
Requirements documentation

As part of the scope baseline it provides information to:

Activity list
Network diagram
Duration estimates
Project schedule
Cost estimates
Project budget
Quality management plan
Resource management plan
Activity resource requirements
Risk register
Procurement management plan
Accepted deliverables

The work breakdown structure is an output from the process 5.4 Create WBS in the PMBOK^® Guide – Sixth Edition. The high levels of the WBS are defined at the start of the project. The lower levels may be progressively elaborated as the project continues.

Tailoring Tips

Consider the following tips to help tailor the WBS to meet your needs:

The needs of the project will determine the way that the WBS is organized. The second level determines the organization of the WBS. Some options for organizing and arranging the WBS include:
- Geography
- Major deliverables
- Life cycle phases
- Subprojects
For smaller projects you may use a WBS that is depicted like an organizational chart with deliverables in boxes and subordinate deliverables beneath them.
For larger projects you will need to arrange the WBS in an outline format and provide a numbering structure.
At the beginning of the project you may only have two or three levels of the WBS defined. Through the process of progressive elaboration you will continue to decompose the work into more refined deliverables.
If your organization has accounting codes you may need to align each deliverable to a specific accounting code to track expenditures.

Alignment

The WBS should be aligned and consistent with the following documents:

Project charter
Requirements documentation
Project scope statement
WBS dictionary
Activity list

Description

You can use the element descriptions in Table 2.9 to assist you in developing a work breakdown structure.

TABLE 2.9 Elements of a Work Breakdown Structure

Document Element	Description
Control account	The point where scope, schedule, and cost are integrated and used to measure project performance
Work package	The lowest-level deliverable defined in the WBS for estimating and measuring resources, cost, and duration. Each work package rolls up to one and only one control account for reporting purposes.

2.10 WBS DICTIONARY

The WBS dictionary supports the work breakdown structure (WBS) by providing detail about the control accounts and work packages it contains. The dictionary can provide detailed information about each work package or summary information at the control account level. The approved WBS, its corresponding WBS dictionary, and the project scope statement comprise the scope baseline for the project. Information in the WBS dictionary can include:

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

The WBS dictionary is progressively elaborated as the planning processes progress. Once the WBS is developed, the statement of work for a particular work package may be defined, but the necessary activities, cost estimates, and resource requirements may not be known. Thus, the inputs for the WBS dictionary are more detailed than for the WBS.

Use the information from your project to tailor the form to best meet your needs.

The WBS dictionary can receive information from:

Requirements documentation
Project scope statement
Assumption log
Activity list
Milestone list
Activity resource requirements
Cost estimates
Quality metrics
Contracts

As part of the scope baseline, the WBS dictionary provides information to:

Activity list
Network diagram
Duration estimates
Project schedule
Cost estimates
Project budget
Quality management plan
Resource management plan
Activity resource requirements
Risk register
Procurement management plan
Accepted deliverables

The WBS dictionary is an output from the process 5.4 Create WBS in the PMBOK^® Guide – Sixth Edition. It is progressively elaborated throughout the project.

Tailoring Tips

Consider the following tips to help tailor the WBS dictionary to meet your needs:

For smaller projects you may not need a WBS dictionary.
For projects that do use a WBS dictionary you can tailor the information to be as detailed or as high level as you need. You may just want to list a description of work, the cost estimate, key delivery dates, and assigned resources.
For projects that have deliverables outsourced you can consider the WBS dictionary as a mini-statement of work for the outsourced deliverables.
Projects that use WBS dictionaries can reference other documents and the relevant sections for technical, quality, or agreement information.

Alignment

The WBS dictionary should be aligned and consistent with the following documents:

Project charter
Requirements documentation
Project scope statement
Wbs
Activity list

Description

You can use the element descriptions in Table 2.10 to assist you in developing a WBS dictionary.

TABLE 2.10 Elements of a WBS Dictionary

Document Element	Description
Work package name	Enter a brief description of the work package deliverable from the WBS.
Code of account	Enter the code of account from the WBS.
Milestones	List any milestones associated with the work package.
Due dates	List the due dates for milestones associated with the work package.
ID	Enter a unique activity identifier—usually an extension of the WBS code of accounts.
Activity	Describe the activity from the activity list or the schedule.
Team resource	Identify the resources, usually from the resource requirements.
Labor hours	Enter the total effort required.
Labor rate	Enter the labor rate, usually from cost estimates.
Labor total	Multiply the effort hours times the labor rate.
Material units	Enter the amount of material required, usually from the resource requirements.
Material cost	Enter the material cost, usually from cost estimates.
Material total	Multiply the material units times the material cost.
Total cost	Sum the labor, materials, and any other costs associated with the work package.
Quality requirements	Document any quality requirements or metrics associated with the work package.
Acceptance criteria	Describe the acceptance criteria for the deliverable, usually from the scope statement.
Technical information	Describe or reference any technical requirements or documentation needed to complete the work package.
Agreement information	Reference any contracts or other agreements that impact the work package.

WBS DICTIONARY

Project Title: _______________________ Date Prepared: _______________________

Work Package Name:			Code of Accounts:
Description of Work:			Assumptions and Constraints:
Milestones: 1. 2. 3.			Due Dates:
ID	Activity	Resource	Labor			Material			Total Cost
ID	Activity	Resource	Hours	Rate	Total	Units	Cost	Total	Total Cost




Quality Requirements:
Acceptance Criteria:
Technical Information:
Agreement Information:

2.11 SCHEDULE MANAGEMENT PLAN

The schedule management plan is part of the project management plan. It specifies how the project schedule will be developed, monitored, and controlled. Planning how to manage the schedule can include at least:

Scheduling methodology
Scheduling tool
Level of accuracy for duration estimates
Units of measure
Variance thresholds
Schedule reporting information and format
Organizational procedure links
Schedule updates

The schedule management plan can receive information from:

Project charter
Project management plan

It provides information to:

Activity list
Activity attributes
Network diagram
Activity duration estimates
Project schedule
Schedule baseline
Risk register

The schedule management plan is an output from the process 6.1 Plan Schedule Management in the PMBOK^® Guide – Sixth Edition. It is developed once and does not usually change.

Tailoring Tips

Consider the following tips to help tailor the schedule management plan to meet your needs:

Add information on the level of detail and timing for WBS decomposition based on rolling wave planning.
For projects that use agile, add information on the time box periods for releases, waves, and iterations.
For projects that use earned value management, include information on rules for establishing percent complete and the EVM measurement techniques (fixed formula, percent complete, level or effort, etc.).

Alignment

The schedule management plan should be aligned and consistent with the following documents:

Project charter
Cost management plan

Description

You can use the descriptions in Table 2.11 to assist you in developing a schedule management plan.

TABLE 2.11 Elements of the Schedule Management Plan

Document Element	Description
Schedule methodology	Identify the scheduling methodology that will be used for the project, whether it is critical path, agile, or some other methodology.
Scheduling tool(s)	Identify the scheduling tool(s) that will be used for the project. Tools can include scheduling software, reporting software, earned value software, etc.
Level of accuracy	Describe the level of accuracy needed for estimates. The level of accuracy may evolve over time as more information is known (progressive elaboration). If there are guidelines for rolling wave planning and the level of refinement that will be used for duration and effort estimates, indicate the levels of accuracy required as time progresses.
Units of measure	Indicate whether duration estimates will be in days, weeks, months, or some other unit of measure.
Variance thresholds	Indicate the measures that determine whether an activity, work package, or the project as a whole is on time, requires preventive action, or is late and requires corrective action.
Schedule reporting and format	Document the schedule information required for status and progress reporting. If a specific reporting format will be used, attach a copy or refer to the specific form or template.
Organizational procedure links	The schedule outline should follow the numbering structure of the WBS. It may also need to follow the organization’s code of accounts or other accounting and reporting structures.
Schedule updates	Document the process for updating the schedule, including update frequency, permissions, and version control. Indicate the guidelines for maintaining baseline integrity and for re-baselining if necessary.

2.12 ACTIVITY LIST

The activity list defines all the activities necessary to complete the project work. It also describes the activities in sufficient detail so that the person performing the work understands the requirements necessary to complete it correctly. The activity list contains:

Activity identifier
Activity name
Description of work

The activity list can receive information from:

Schedule management plan
Scope baseline (particularly the deliverables from the WBS)

It provides information to:

Network diagram
Activity duration estimates
Gantt chart or other schedule presentation
Activity resource requirements

The activity list is an output from process 6.2 Define Activities in the PMBOK^® Guide – Sixth Edition. This process is performed throughout the planning of the project. For adaptive approaches, or projects that are progressively elaborated, this process is done throughout the project.

Tailoring Tips

Consider the following tips to help tailor the activity list to meet your needs:

For some projects you will enter your activities into the schedule tool rather than keep a separate activity list.
Not all projects require a column to describe the work.
For projects that use an adaptive development approach your activity list will evolve as the requirements are added or changed in the product backlog.
For projects that use an adaptive development approach you may want to add a column that indicates the planned release or iteration for each activity.

Alignment

The activity list should be aligned and consistent with the following documents:

Milestone list
Activity attributes
WBS
WBS dictionary
Product backlog
Iteration release plan

Description

You can use the element descriptions in Table 2.12 to assist you in developing an activity list.

TABLE 2.12 Elements of an Activity List

Document Element	Description
ID	Unique identifier
Activity name	A brief statement that summarizes the activity. Activities usually start with a verb and are only a few words.
Description of work	If needed use this field to provide more detail to the activity description, such as a process or method to accomplish the work.

2.13 ACTIVITY ATTRIBUTES

Activity attributes are the details about the activity. Sometimes the information is entered directly into the schedule software. Other times the information is collected in a form that can be used later to assist in building the schedule model. Activity attributes can include:

Activity identifier or code
Activity name
Activity description
Predecessor and successor activities
Logical relationships
Leads and lags
Imposed dates
Constraints
Assumptions
Resource requirements and skill levels
Location of performance
Type of effort

The activity attributes are progressively elaborated as the planning processes progress. Once the activity list is complete, the description of work for a particular activity may be defined but the necessary attributes, such as logical relationships and resource requirements, may not be known. Thus, the inputs for the activity attributes are more detailed than for the activity list and are added to as new information becomes available.

The activity attributes can receive information from:

Schedule management plan
Activity list
Network diagram
Scope baseline
Assumption log
Activity resource requirements

It provides information to:

Network diagram
Duration estimates
Project schedule
Resource requirements

Activity attributes are an output from process 6.2 Define Activities in the PMBOK^® Guide – Sixth Edition. They are developed throughout the planning of the project. For adaptive approaches, or projects that are progressively elaborated, they are updated throughout the project.

Tailoring Tips

Consider the following tips to help tailor the activity attributes to meet your needs:

For some projects you will enter your activities into the schedule tool rather than keep a separate set of activity attributes.
Only include the fields you feel necessary to effectively manage your project.
Constraints and assumptions can be recorded in the assumption log rather than this form.
For projects that use an adaptive development approach your activity list will evolve as the requirements are added or changed in the product backlog.
For projects that use an adaptive development approach you may want to add a field that indicates the planned release or iteration for each activity.

Alignment

The activity attributes should be aligned and consistent with the following documents:

Assumption log
WBS
WBS dictionary
Milestone list
Activity list
Network diagram
Duration estimates
Schedule
Cost estimates
Resource requirements

Description

You can use the descriptions in Table 2.13 to assist you in developing the activity attributes.

TABLE 2.13 Elements of Activity Attributes

Document Element	Description
ID	Unique identifier
Activity name	Document a brief statement that summarizes the activity. The activity name starts with a verb and is usually only a few words.
Description of work	A description of the activity in enough detail that the person(s) performing the work understands what is required to complete it.
Predecessor and successor activities	Identify any predecessor activities that must occur before the activity. Identify any successor activities that can’t occur until after the activity.
Logical relationships	Describe the nature of the relationship between predecessor or successor activities, such as start-to-start, finish-to-start, or finish-to-finish.
Leads and lags	Any required delays between activities (lag) or accelerations (lead) that apply to the logical relationships
Imposed dates	Note any required dates for start, completion, reviews, or accomplishments.
Constraints	Document any limitations associated with the activity, such as finish-no-later-than dates, approaches to work, resources, etc.
Assumptions	Document any assumptions associated with the activity, such as availability of resources, skill sets, or other assumptions that impact the activity.
Team resources and skill levels	Document the number and roles of people needed to complete the work along with the skill level, such as junior, senior, etc.
Required physical resources	Document the materials, supplies or equipment needed to complete the activity.
Location of performance	If the work is to be completed somewhere other than at the performing site, indicate the location.
Type of effort	Indicate if the work is a fixed duration, fixed effort, level of effort, apportioned effort, or other type of work.

ACTIVITY ATTRIBUTES

Project Title: _______________________ Date Prepared: _______________________

ID:	Activity:
Description of Work:
Predecessors	Relationship	Lead or Lag	Successor	Relationship	Lead or Lag

Number and Type of Team Resources Required:		Skill Requirements:		Required Resources:
Type of Effort:
Location of Performance:
Imposed Dates or Other Constraints:
Assumptions:

2.14 MILESTONE LIST

The milestone list defines all the project milestones and describes the nature of each one. It may categorize the milestone as optional or mandatory, internal or external, interim or final, or in any other way that supports the needs of the project.

The milestone list can receive information from:

Project charter
Schedule management plan
Scope baseline

It provides information to:

Network diagram
Duration estimates
Gantt chart or other schedule presentation
Change requests
Close out report

The milestone list is an output from process 6.2 Define Activities in the PMBOK® Guide – Sixth Edition. This is developed once and is not usually changed unless there is a significant scope change.

Tailoring Tips

Consider the following tip to help tailor the milestone list to meet your needs:

For some projects you will enter your milestones directly into the schedule tool rather than keep a separate list of milestones.

Alignment

The milestone list should be aligned and consistent with the following documents:

Project charter
Activity list
Network diagram
Duration estimates
Schedule

Description

You can use the descriptions in Table 2.14 to assist you in developing the milestone list.

TABLE 2.14 Elements of a Milestone List

Document Element	Description
Milestone name	Milestone name that uniquely defines the milestone
Milestone description	A description of the milestone in enough detail to understand what is needed to determine the milestone is complete
Type	A description of the type of milestone, such as Internal or external Interim or final Mandatory or optional

MILESTONE LIST

Project Title: _______________________ Date Prepared: _______________________

Milestone	Milestone Description	Type

2.15 NETWORK DIAGRAM

The network diagram is a visual display of the relationship between schedule elements. The purpose is to visually depict the types of relationships between components. The components are shown nodes that are connected by lines with arrows that indicate the nature of the relationship. Relationships can be one of four types:

Finish-to-start (FS). This is the most common type of relationship. The predecessor element must be complete before the successor element can begin.
Start-to-start (SS). In this relationship, the predecessor element must begin before the successor element begins.
Finish-to-finish (FF). In this relationship, the predecessor element must be complete before the successor element can be complete.
Start-to-finish (SF). This is the least common type of relationship. The successor element must begin before the predecessor element can be complete.

In addition to the types of relationships, the network diagram may show modifications to the relationships, such as leads or lags:

A lag is a directed delay between elements. In a finish-to-start relationship with a three-day lag, the successor activity would not start until three days after the predecessor was complete. This would be shown as FS+3d. Lag is not float.
A lead is an acceleration between elements. In a finish-to-start relationship with a three-day lead, the successor activity would begin three days before the predecessor was complete. This would be shown as FS–3d.
Leads and lags can be applied to any type of relationship.

The network diagram can receive information from:

Assumption log
Schedule management plan
Activity list
Activity attributes
Milestone list
Scope baseline

It provides information to:

Project schedule

The network diagram is an output from the process 6.3 Sequence Activities in the PMBOK^® Guide – Sixth Edition. This is developed once and is not usually changed unless there is a significant scope change.

Tailoring Tips

Consider the following tips to help tailor the network diagram to meet your needs:

At the start of the project you may want to use sticky notes to create a network diagram to get the idea of the flow of deliverables.
For some projects you will enter the type of relationship directly into the schedule tool rather than draw it out. Most scheduling software has the option to see the schedule as a network diagram.
The network diagram can be produced at the activity level, the deliverable level, or the milestone level.

Alignment

The network diagram should be aligned and consistent with the following documents:

Project schedule
Project roadmap
Milestone list

2.16 DURATION ESTIMATES

Duration estimates provide information on the amount of time it will take to complete project work. They can be determined by developing an estimate for each activity, work package, or control account, using expert judgment or a quantitative method, such as:

Parametric estimating
Analogous estimating
Three-point estimating

For those activity durations driven by human resources, as opposed to material or equipment, the duration estimates will generally convert the estimate of effort hours into days or weeks. To convert effort hours into days, take the total number of hours and divide by 8. To convert to weeks, take the total number of hours and divide by 40.

Duration estimates include at least:

ID
Activity description
Effort hours

Duration estimates can receive information from:

Assumption log
Scope baseline
Schedule management plan
Activity list
Activity attributes
Milestone list
Resource requirements
Resource breakdown structure
Resource calendars
Project team assignments
Resource breakdown structure
Risk register
Lessons learned register

It provides information to:

Schedule baseline
Project schedule
Risk register

Duration estimates are an output from process 6.4 Estimate Activity Durations in the PMBOK^® Guide – Sixth Edition. They are developed throughout the project as schedule and activity details are refined.

Tailoring Tips

Consider the following tips to help tailor the duration estimates to meet your needs:

Duration estimates may include contingency reserve to account for risks related to uncertainty in the duration estimates, ambiguity in the scope, or resource availability.
Duration estimates at the level of accuracy that suits your project needs. Rolling wave planning is often used for duration estimating; as more information is known about the project activities, duration estimates are refined and updated.
For projects that are using an agile development approach, set time boxes are used rather than duration estimates. Additionally, different estimating methods are used.

Alignment

The duration estimates should be aligned and consistent with the following documents:

Assumption log
Activity attributes
Resource requirements

Description

You can use the descriptions in Table 2.15 to assist you in developing the duration estimates.

TABLE 2.15 Elements of Duration Estimates

Document Element	Description
ID	Unique identifier
Activity description	A description of the work that needs to be done
Effort hours	The amount of labor it will take to accomplish the work; usually shown in hours, but may be shown in days
Duration estimates	The length of time it will take to accomplish the work; usually shown in days, but may be shown in weeks or months

DURATION ESTIMATES

Project Title: _______________________ Date Prepared: _______________________

ID	Activity Description	Effort Hours	Duration Estimate

2.17 DURATION ESTIMATING WORKSHEET

A duration estimating worksheet can help to develop duration estimates when quantitative methods are used. Quantitative methods include:

Parametric estimates
Analogous estimates
Three-point estimates

Parametric estimates are derived by determining the effort hours needed to complete the work. The effort hours are then calculated by:

Dividing the estimated hours by resource quantity (i.e., number of people assigned to the task)
Dividing the estimated hours by the percent of time the resource(s) are available (i.e., 100 percent of the time, 75 percent of the time, or 50 percent of the time)
Multiplying the estimated hours by a performance factor. Experts in a field generally complete work faster than people with an average skill level or novices. Therefore, a factor to account for the productivity is developed.

Duration estimates can be made even more accurate by considering that most people are productive on project work only about 75 percent of the time.

Analogous estimates are derived by comparing current work to previous similar work. The size of the previous work and the duration is compared to the expected size of the current work compared to the previous work. Then the ratio of the size of the current work is multiplied by the previous duration to determine an estimate. Various factors, such as complexity, can be factored in to make the estimate more accurate. This type of estimate is generally used to get a high-level estimate when detailed information is not available.

A three-point estimate can be used to account for uncertainty in the duration estimate. Stakeholders provide estimates for optimistic, most likely, and pessimistic scenarios. These estimates are put into an equation to determine an expected duration. The needs of the project determine the appropriate equation, but a common equation is the beta distribution:

In formulas, duration is often represented by “t” for “time.”

The duration estimating worksheet can receive information from:

Assumption log
Scope baseline
Activity list
Activity attributes
Resource requirements
Resource calendars
Project team assignments
Risk register
Lessons learned register

It provides information to:

Duration estimates

Duration estimates are an output from process 6.4 Estimate Activity Duration in the PMBOK^® Guide – Sixth Edition. They are developed throughout the project as schedule and activity details are refined.

Description

You can use the element descriptions in Table 2.16 to assist you in estimating durations with the worksheet.

TABLE 2.16 Elements of an Activity Duration Estimating Worksheet

Document Element	Description
ID	Unique identifier
Parametric estimates
Effort hours	Enter amount of labor it will take to accomplish the work. Usually shown in hours, but may also be shown in days. Example: 150 hours
Resource quantity	Document the number of resources available. Example: 2 people
Percent available	Enter amount of time the resources are available. Usually shown as the percent of time available per day or per week. Example: 75 percent of the time
Performance factor	Estimate a performance factor if appropriate. Generally effort hours are estimated based on the amount of effort it would take the average resource to complete the work. This can be modified if you have a highly skilled resource or someone who has very little experience. The more skilled the resource, the lower the performance factor. For example, an average resource would have a 1.0 performance factor. A highly skilled resource could get the work done faster, so you multiply the effort hours times a performance factor of .8. A less skilled resource will take longer to get the work done, so you would multiply the effort hours times 1.2. Example: A skilled worker with a performance factor of .8
Duration estimate	Divide the effort hours by the resource quantity times the percent available times the performance factor to determine the length of time it will take to accomplish the work. The equation is:
Analogous estimates
Previous activity	Enter a description of the previous activity. Example: Build a 160 square foot deck.
Previous duration	Document the duration of the previous activity. Example: 10 days
Current activity	Describe how the current activity is different. Example: Build a 200 square foot deck.
Multiplier	Divide the current activity by the previous activity to get a multiplier. Example: 200/160 = 1.25
Duration estimate	Multiply the duration for the previous activity by the multiplier to calculate the duration estimate for the current activity. Example: 10 days × 1.25 = 12.5 days
Three-point estimate (Beta distribution)
Optimistic duration	Determine an optimistic duration estimate. Optimistic estimates assume everything will go well and there won’t be any delays in material and that all resources are available and will perform as expected. Example: 20 days
Most likely duration	Determine a most likely duration estimate. Most likely estimates assume that there will be some delays but nothing out of the ordinary. Example: 25 days
Pessimistic duration	Determine a pessimistic duration estimate. Pessimistic estimates assume there are significant risks that will materialize and cause delays. Example: 36 days
Weighting equation	Weight the three estimates and divide. The most common method of weighting is the beta distribution:
Expected duration	Enter the expected duration based on the beta distribution calculation. Example: 26 days

DURATION ESTIMATING WORKSHEET

Project Title: _______________________ Date Prepared: _______________________

Parametric Estimates
ID	Effort Hours	Resource Quantity	% Available	Performance Factor	Duration Estimate







Analogous Estimates
ID	Previous Activity	Previous Duration	Current Activity	Multiplier	Duration Estimate







Three-Point Estimates
ID	Optimistic Duration	Most Likely Duration	Pessimistic Duration	Weighting Equation	Expected Duration Estimate

2.18 PROJECT SCHEDULE

The project schedule combines the information from the activity list, network diagram, resource requirements, duration estimates, and any other relevant information to determine the start and finish dates for project activities. A common way of showing a schedule is via Gantt chart showing the dependencies between activities. The sample Gantt chart is for designing, building, and installing kitchen cabinets. It shows the:

WBS identifier
Activity name
Start dates
Finish dates
Resource name (next to the bar)

The project schedule can receive information from:

Assumption log
Schedule management plan
Activity list
Activity attributes
Milestone list
Network diagram
Duration estimates
Project team assignments
Resource calendars
Project scope statement
Risk register
Lessons learned register

It provides information to:

Cost estimates
Project budget
Resource management plan
Risk register
Stakeholder engagement plan

The project schedule is an output from the process 6.5 Develop Schedule in the PMBOK^® Guide – Sixth Edition. It is updated and elaborated throughout the projects.

Tailoring Tips

Consider the following tips to help tailor the project schedule to meet your needs:

For smaller projects you may not require scheduling software; you can use a spreadsheet or some other means to show the schedule.
For projects that use scheduling software, the needs of your project will determine the fields you use and the information you enter and track.
At the beginning of the project you may only enter the information from the WBS into the schedule. As you further decompose the work you will enter activities, durations, resources, and other information. The level of detail depends on the needs of the project.
You may choose to only distribute a milestone chart that shows only the dates of the important events or key deliverables. The sample milestone chart is for constructing a house. It shows the activity milestones as well as their dependencies. Showing dependencies on a milestone chart is optional.

Alignment

The project schedule should be aligned and consistent with the following documents:

Project charter
Assumption log
Schedule management plan
Project roadmap
Scope baseline
Activity list
Network diagram
Duration estimates
Project team assignments
Project calendars

2.19 COST MANAGEMENT PLAN

The cost management plan is a part of the project management plan. It specifies how the project costs will be estimated, structured, monitored, and controlled. The cost management plan can include the following information:

Level of accuracy for cost estimates
Units of measure
Variance thresholds
Rules for performance measurement
Cost reporting information and format
Process for estimating costs
Process for developing a time-phased budget
Process for monitoring and controlling costs

In addition, the cost management plan may include information on the level of authority associated with cost and budget allocation and commitment, funding limitations, and options and guidelines on how and when costs get recorded for the project.

The cost management plan can receive information from the:

Project charter
Schedule management plan
Risk management plan

It provides information to:

Activity cost estimates
Cost baseline
Risk register

The cost management plan is an output from the process 7.1 Plan Cost Management in the PMBOK^® Guide – Sixth Edition. It is developed once and does not usually change.

Tailoring Tips

Consider the following tips to help tailor the cost management plan to meet your needs:

On smaller projects, often the project manager does not manage the budget. In those cases you would not need this form.
Units of measure for each type of resource may be indicated in the cost management plan or the resource management plan.
For projects that use earned value management, include information on rules for establishing percent complete, the EVM measurement techniques (fixed formula, percent complete, level or effort, etc.). For those that don’t, delete this field.

Alignment

The cost management plan should be aligned and consistent with the following documents:

Project charter
Schedule management plan

Description

You can use the descriptions in Table 2.17 to assist you in developing a cost management plan.

TABLE 2.17 Elements of a Cost Management Plan

Document Element	Description
Units of measure	Indicate how each type of resource will be measured. For example, labor units may be measured in staff hours, days, or weeks. Physical resources may be measured in gallons, meters, tons, or whatever is appropriate for the material. Some resources are based on a lump sum cost each time they are used.
Level of precision	Indicate whether cost estimates will be rounded to hundreds, thousands, or some other measurement.
Level of accuracy	Describe the level of accuracy needed for estimates. The level of accuracy may evolve over time as more information is known (progressive elaboration). If there are guidelines for rolling wave planning and the level of refinement that will be used for cost estimates, indicate the levels of accuracy required as time progresses.
Organizational procedure links	Cost estimating and reporting should follow the numbering structure of the WBS. It may also need to follow the organization’s code of accounts or other accounting and reporting structures.
Control thresholds	Indicate the measures that determine whether an activity, work package, or the project as a whole is on budget, requires preventive action, or is over budget and requires corrective action. Usually indicated as a percent deviation from the baseline.
Rules of performance measurement	Identify the level in the WBS where progress and expenditures will be measured. For projects that use earned value management indicate whether costs will be reported at the work package or control account level. Describe the measurement method that will be used, such as weighted milestones, fixed-formula, percent complete, etc. Document the equations that will be used to forecast estimates to complete (ETC) and estimates at completion (EAC).
Cost reporting information and format	Document the cost information required for status and progress reporting. If a specific reporting format will be used, attach a copy or refer to the specific form or template. Indicate the reporting frequency.
Additional details	Describe variables associated with strategic funding choices, such as make or buy, buy or lease, borrowing funds versus using in-house funding, etc.

COST MANAGEMENT PLAN

Project Title: _______________________ Date Prepared: _______________________

Units of Measure:	Level of Precision:	Level of Accuracy:

Organizational Procedure Links:

Control Thresholds:

Rules of Performance Measurement:

Cost Reporting and Format:

Additional Details:

2.20 COST ESTIMATES

Cost estimates provide information on the cost of resources necessary to complete project work, including labor, equipment, supplies, services, facilities, and material. Estimates can be determined by developing an approximation for each work package using expert judgment or by using a quantitative method such as:

Parametric estimates
Analogous estimates
Three-point estimates

Cost estimates should include at least:

ID
Labor costs
Physical resource costs
Reserve
Estimate
Basis of estimates
Method
Assumptions
Range
Confidence level

Cost estimates can receive information from:

Cost management plan
Scope baseline
Project schedule
Quality management plan
Resource requirements
Risk register
Lessons learned register

They provide information to:

Cost baseline
Resource requirements
Risk register

Cost estimates are an output from the process 7.2 Estimate Costs in the PMBOK^® Guide – Sixth Edition. Cost estimates are developed and then refined periodically as needed.

Tailoring Tips

Consider the following tips to help tailor the cost estimates to meet your needs:

Cost estimates may include contingency reserve to account for risks related to uncertainty in the Cost estimates or ambiguity in the scope or resource availability.
If considerations for the cost of quality, cost of financing, or indirect costs were included, add that information to your cost estimate.
Estimate costs at the level of accuracy and precision that suits your project needs. Rolling wave planning is often used for cost estimating; as more information is known about the scope and resources, cost estimates are refined and updated.
If using vendors, indicate the estimated cost and indicate the type of contract being used to account for possible fees and awards.

Alignment

The cost estimates should be aligned and consistent with the following documents:

Assumption log
Activity attributes
Project schedule
Resource requirements
Project team assignments

Description

You can use the descriptions in Table 2.18 to assist you in developing the cost estimates.

TABLE 2.18 Elements of an Activity Cost Estimate

Document Element	Description
ID	Unique identifier, such as the WBS ID or activity ID
Resource	The resource (person, equipment, material) needed for the WBS deliverable
Labor costs	The costs associated with team or outsourced resources
Physical costs	Costs associated with material, equipment, supplies, or other physical resources
Reserve	Document contingency reserve amounts, if any
Estimate	The sum of the cost of labor, physical resources, and reserve costs
Basis of estimates	Information such as cost per pound, duration of the work, square feet, etc.
Method	The method used to estimate the cost, such as analogous, parametric, etc.
Assumptions/constraints	Assumptions used to estimate the cost, such as the length of time the resource will be needed
Range	The range of estimate
Confidence level	The degree of confidence in the estimate

2.21 COST ESTIMATING WORKSHEET

A cost estimating worksheet can help to develop cost estimates when quantitative methods or a bottom-up estimate are developed. Quantitative methods include:

Parametric estimates
Analogous estimates
Three-point estimates

Parametric estimates are derived by determining the cost variable that will be used and the cost per unit. The number of units is multiplied by the cost per unit to derive a cost estimate.

Analogous estimates are derived by comparing current work to previous similar work. The size of the previous work and the cost are compared to the expected size of the current work. Then the ratio of the size of the current work compared to the previous work is multiplied by the previous cost to determine an estimate. Various factors, such as complexity and price increases, can be factored in to make the estimate more accurate. This type of estimate is generally used to get a high-level estimate when detailed information is not available.

A three-point estimate can be used to account for uncertainty in the cost estimate. Stakeholders provide estimates for optimistic, most likely, and pessimistic scenarios. These estimates are put into an equation to determine an expected cost. The needs of the project determine the appropriate equation, though a common equation is a beta distribution:

Bottom-up estimates are detailed estimates done at the work package level. Detailed information on the work package, such as technical requirements, engineering drawings, labor duration, and other direct and indirect costs are used to determine the most accurate estimate possible.

The cost estimating worksheet can receive information from:

Cost management plan
Scope baseline
Project schedule
Quality management plan
Resource requirements
Risk register
Lessons learned register

Cost estimating worksheets are process 7.2 Estimate Costs in the PMBOK^® Guide – Sixth Edition. Cost estimating worksheets are developed and then refined as periodically as needed.

Description

You can use the element descriptions in Table 2.19 to assist you in developing a cost estimating worksheet and the element descriptions in Table 2.20 to assist you in developing a bottom-up cost estimating worksheet.

TABLE 2.19 Elements of a Cost Estimating Worksheet

Document Element	Description
ID	Unique identifier, such as the WBS ID or activity ID
Parametric estimates
Cost variable	Enter the cost estimating driver, such as hours, square feet, gallons, or some other quantifiable measure. Example: Square feet
Cost per unit	Record the cost per unit. Example: $9.50
Number of units	Enter the number of units. Example: 36
Cost estimate	Multiply the number of units times the cost per unit to calculate the estimate. Example: $9.50 × 36 = $342
Analogous estimates
Previous activity	Enter a description of the previous activity. Example: Build a 160 square foot deck.
Previous cost	Document the cost of the previous activity. Example: $5,000
Current activity	Describe how the current activity is different. Example: Build a 200 square foot deck.
Multiplier	Divide the current activity by the previous activity to get a multiplier. Example: 200/160 = 1.25
Cost Estimate	Multiply the cost for the previous activity by the multiplier to calculate the Cost Estimate for the current activity. Example: $5,000 × 1.25 = $6,250
Three-point estimate (Beta distribution)
Optimistic cost	Determine an optimistic cost estimate. Optimistic estimates assume all costs were identified and there won’t be any cost increases in material, labor, or other cost drivers. Example: $4,000
Most likely cost	Determine a most likely cost estimate. Most likely estimates assume that there will be some cost fluctuations but nothing out of the ordinary. Example: $5,000
Pessimistic cost	Determine a pessimistic cost estimate. Pessimistic estimates assume there are significant risks that will materialize and cause cost overruns. Example: $7,500
Weighting equation	Weight the three estimates and divide. The most common method of weighting is the beta distribution, where c = cost:
Expected cost	Enter the expected cost based on the beta distribution. Example: $5,250

TABLE 2.20 Elements of a Bottom-Up Cost Estimating Worksheet

Document Element	Description
ID	Unique identifier, such as the WBS ID or activity ID
Labor hours	Enter the estimated effort hours.
Labor rate	Enter the hourly or daily rate.
Total labor	Multiply the labor hours times the labor rate.
Material	Enter quotes for material, either from vendors or multiply the amount of material times the cost per unit.
Supplies	Enter quotes for supplies, either from vendors or multiply the amount of supplies times the cost per unit.
Equipment	Enter quotes to rent, lease, or purchase equipment.
Travel	Enter quotes for travel.
Other direct costs	Enter any other direct costs and document the type of cost.
Indirect costs	Enter any indirect costs, such as overhead.
Reserve	Enter any contingency reserve cost for the work package.
Estimate	Sum the labor, materials, supplies, equipment, travel, other direct costs, indirect costs, and any contingency reserve.

You can use the element descriptions in the following table to assist you in developing a bottom-up cost estimating worksheet.

COST ESTIMATING WORKSHEET

Project Title: _______________________ Date Prepared: _______________________

Parametric Estimates
ID	Cost Variable	Cost per Unit	Number of Units	Cost Estimate







Analogous Estimates
ID	Previous Activity	Previous Cost	Current Activity	Multiplier	Cost Estimate







Three-Point Estimates
ID	Optimistic Cost	Most Likely Cost	Pessimistic Cost	Weighting Equation	Expected Cost Estimate

BOTTOM-UP COST ESTIMATING WORKSHEET

Project Title: _______________________ Date Prepared: _______________________

ID	Labor Hours	Labor Rate	Total Labor	Material	Supplies	Equipment	Travel	Other Direct Costs	Indirect Costs	Reserve	Estimate

2.22 COST BASELINE

The cost baseline is a time-phased budget that is used to measure, monitor, and control cost performance for the project. It is developed by summing the costs of the project by the time period and developing a cumulative cost curve that can be used to track actual performance, planned performance, and the funds spent.

A project may have multiple cost baselines; for example, the project manager may keep a separate baseline for labor or procurements. The baseline may or may not include contingency funds or indirect costs. When earned value measurements are being used, the baseline may be called the performance measurement baseline.

The cost baseline can receive information from:

Scope baseline
Cost management plan
Cost estimates
Project schedule
Resource management plan
Risk register
Agreements (contracts)

It provides information to:

Project management plan
Risk register

The cost baseline is an output from process 7.3 Determine Budget in the PMBOK^® Guide – Sixth Edition. This is developed once and is not expected to change unless there is a significant change in scope.

Tailoring Tips

Consider the following tips to help tailor the cost baseline to meet your needs:

The cost baseline generally includes contingency reserve to account for known risks. It does not generally include management reserve. Management reserve is held above the cost baseline, but is considered part of the project budget. If your company policies differ, the reserve in your baseline may be different.
Your cost baseline may be displayed to show the funding constraints, funding requirements, or different sources of funding.
Your organization may not require a graphic display of the cost baseline; they may require a spreadsheet or internal budgeting system displays instead.

Alignment

The cost baseline should be aligned and consistent with the following documents:

Assumption log
Project schedule
Cost estimates
Project team assignments
Risk register

The cost baseline on the following page is displayed in a form called an S-curve.

2.23 QUALITY MANAGEMENT PLAN

The quality management plan is a component of the project management plan. It describes how applicable policies, procedures, and guidelines will be implemented to achieve the quality objectives for the project. Information in the quality management plan can include:

Quality standards that will be used on the project
Quality objectives
Quality roles and responsibilities
Deliverables and processes subject to quality review
Quality control and quality management activities for the project
Quality procedures applicable for the project

The quality management plan can receive information from:

Project charter
Assumption log
Stakeholder register
Requirements management plan
Risk management plan
Stakeholder engagement plan
Scope baseline
Requirements documentation
Requirements traceability matrix
Risk register

It provides information to:

Scope management plan
Cost estimates
Resource management plan
Risk register
Procurement documents (RFP, RFQ)

The quality management plan is an output from process 8.1 Plan Quality Management in the PMBOK^® Guide – Sixth Edition. This is developed once and is not usually changed.

Tailoring Tips

Consider the following tips to help tailor the quality management plan to meet your needs:

On smaller projects quality, requirements, and scope are often handled as a single aspect, whereas in larger projects they are separated out and may have distinct roles and responsibilities for each aspect.
In many industries there are specific standards that must be adhered to. Your quality management plan may reference these by citing specific regulations, or they may be integrated into organizational policies and procedures.
Quality management planning must be consistent with your organization’s quality policies, processes, and procedures.

Alignment

The quality management plan should be aligned and consistent with the following documents:

Project charter
Scope management plan
Requirements management plan
Resource management plan
Procurement documents (RFP, RFQ, etc.)

Description

You can use the element descriptions in Table 2.21 to assist you in developing a quality management plan.

TABLE 2.21 Elements of a Quality Management Plan

Document Element	Description
Quality standards	Quality standards are usually industry or product driven. They may be ISO standards, IEEE, or some other regulatory or industry body.
Quality objectives	Quality objectives are the measures that must be achieved by the project or product components to meet the stakeholder needs. Objectives are the target you want to achieve. You may have metrics or specifications that provide a quantifiable measurement of success.
Quality roles and responsibilities	Define the roles necessary to conduct quality activities on the project and the responsibilities associated with each.
Deliverables and processes subject to quality review	The key deliverables that have metrics or measures associated with quality objectives
	The processes used in the project that require verification or validation that they are being performed correctly, or in accordance with quality requirements or objectives
Quality management approach	The approach that will be used to manage the quality process. Includes the timing and content of project and product quality audits.
Quality control approach	The approach that will be used to measure the product and the project performance to ensure the product meets the quality objectives
Applicable quality procedures	Procedures that will be used for the project, such as Nonconformance and rework Corrective actions Quality audits Continuous improvement

QUALITY MANAGEMENT PLAN

Project Title: _______________________ Date Prepared: _______________________

Quality Standards

Quality Objectives

Metric or Specification	Measure
1.	1.
2.	2.
3.	3.
4.	4.

Quality Roles and Responsibilities

Roles	Responsibilities
1.	1.
2.	2.
3.	3.

Deliverables and Processes Subject to Quality Review

Deliverables	Processes

Quality Management Approach

Quality Control Approach

Applicable Quality Procedures

2.24 QUALITY METRICS

Quality metrics provide specific detailed measurements about a project or product attribute, and how it should be measured to verify compliance. Metrics are consulted in the manage quality process to ensure that the processes used will meet the metric. The deliverables or processes are measured in the control quality phase and compared to the metric to determine if the result is acceptable or if corrective action or rework is required.

Quality metrics can receive information from:

Project management plan
Requirements documentation
Stakeholder register

Quality metrics are an output from process 8.1 Plan Quality Management in the PMBOK^® Guide – Sixth Edition. They are generally determined as the requirements are developed. If requirements are stable, they will be developed once. If requirements are evolving or changing, they will evolve and change as well.

Tailoring Tips

Consider the following tips to help tailor the quality metrics to meet your needs:

On smaller projects quality metrics, requirements, and specifications are considered the same thing. Different industries may use the term “specifications” rather than “metrics.”
In many industries there are specific standards that include metrics. These must be adhered to in your project. Your quality management plan may reference these by citing specific regulations, or they may be integrated into organizational policies and procedures.

Alignment

The quality metrics should be aligned and consistent with the following documents:

Requirements documentation
Quality management plan

Description

You can use the element descriptions in Table 2.22 to assist you in documenting quality metrics.

TABLE 2.22 Elements of Quality Metrics

Document Element	Description
ID	Unique identifier. This can be the WBS ID or activity ID number.
Item	Describe the attribute to be measured.
Metric	The specific, quantifiable measurement
Measurement method	The method of measuring, including any equipment or procedures

2.25 RESPONSIBILITY ASSIGNMENT MATRIX

The responsibility assignment matrix (RAM) shows the intersection of work packages and resources. Generally, RAMs are used to show the different levels of participation on a work package by various team members rather than physical resources. RAMs can indicate different types of participation depending on the needs of the project. Some common types include:

Accountable
Responsible
Consulted
Resource
Informed
Sign-off

The RAM always should include a key that explains what each of the levels of participation entails. An example follows using a RACI chart, as demonstrated in the PMBOK^® Guide – Sixth Edition. The needs of your project should determine the fields for the RAM you use.

The responsibility assignment matrix can receive information from:

Scope baseline
Requirements documentation
Stakeholder register

It is a data representation tool that provides information to the resource management plan in process 9.1 Plan Resource Management in the PMBOK^® Guide – Sixth Edition. It is progressively elaborated as more information about the scope and the resource requirements is known.

Tailoring Tips

Consider the following tips to help tailor the RAM to meet your needs:

Tailor the types of participation appropriate for your project. Some projects require “sign-off” of specific deliverables, whereas others use the term “approve.”
Determine the appropriate level to record information on the RAM. Large projects with multiple vendors and large deliverables often use the RAM as the intersection of the WBS and the OBS (organizational breakdown structure). Small projects may use it at the deliverable or activity level to help enter schedule information.

Alignment

The RAM should be aligned and consistent with the following documents:

Work breakdown structure
Requirements documentation
Resource requirements
Procurement documents (RFP, RFQ, etc.)

Description

You can use the element descriptions in Table 2.23 to assist you in developing a responsibility assignment matrix.

TABLE 2.23 Elements of a Responsibility Assignment Matrix

Document Element	Description
Work package	Name of the work package you are assigning resources to. The RAM can be used at the work package level, control account level, or activity level.
Resource	Identify the person, division, or organization that will be working on the project.

RESPONSIBILITY ASSIGNMENT MATRIX

Project Title: _______________________ Date Prepared: _______________________

	Person 1	Person 2	Person 3	Person 4	Etc.
Work package 1	R	C	A
Work package 2		A		I	R
Work package 3		R	R	A
Work package 4	A	R	I	C
Work package 5	C	R	R		A
Work package 6	R		A	I
Etc.	C	A		R	R

R = Responsible: The person performing the work.

C = Consult: The person who has information necessary to complete the work.

A = Accountable: The person who is answerable to the project manager that the work is done on time, meets requirements, and is acceptable.

I = Inform: This person should be notified when the work is complete.

2.26 RESOURCE MANAGEMENT PLAN

The resource management plan is part of the project management plan. It provides guidance on how team and physical resources should be allocated, managed, and released. Information in the resource management plan includes:

Estimating methods used to identify the type, number, and skill level of team resources
Information on how project team members will be acquired and released
Roles and responsibilities associated with the project
Project organizational chart
Training requirements
Rewards and recognition
Team development
Methods used to identify the type, amount, and grade of physical resources
Information on how physical resources will be acquired
Methods for managing physical resources, such as inventory, supply chain, and logistics

The resource management plan can receive information from:

Project charter
Quality management plan
Scope baseline
Project schedule
Requirements documentation
Risk register
Stakeholder register

It provides information to:

Project budget
Resource requirements
Resource breakdown structure
Team performance assessments
Communications management plan
Risk register
Procurement management plan

The resource management plan is an output from 9.1 Plan Resource Management in the PMBOK^® Guide – Sixth Edition. It is generally developed once and does not change.

Tailoring Tips

Consider the following tips to help tailor the resource management plan to meet your needs:

If you need to bring in outside contractors for the project you will need to include information on how to on-board them to the project. You will also need to consider how to ensure they have all the information they need, but no access to proprietary data. This may include a “non-disclosure agreement” or similar forms.
For any team or physical resources that are acquired from outside the organization you will need to work with procurement policies for the organization and the project.
Projects with large amounts of inventory, supplies, or material should either reference organizational policies regarding managing physical resources, or provide sufficient detail to ensure appropriate control.

Alignment

The resource management plan should be aligned and consistent with the following documents:

Work breakdown structure
Requirements documentation
Quality management plan
Procurement management plan

Description

You can use the element descriptions in Table 2.24 to assist you in developing a resource management plan.

TABLE 2.24 Elements of a Resource Management Plan

Document Element	Description
Team member identification	Methods used to identify the skill sets needed and the level of skill needed. This includes techniques to estimate the number of resources needed, such as information from past projects, parametric estimates, or industry standards.
Team member acquisition	Document how staff will be brought on to the project. Describe any differences between internal team members and contract team members with regard to on-boarding procedures.
Team member management	Document how team members will be managed and eventually released from the team. Management methods may vary depending on the relative authority of the project manager and whether team members are internal to the organization or contract staff. Team member release should include methods for knowledge transfer.
Project organizational chart	Create a hierarchy chart to show the project reporting and organizational structure.
Roles and responsibilities	Provide information on the following: Role. Identify the role or job title and a brief description of the role. Authority. Define the decision-making, approval, and influence levels for each role. Examples include alternative selection, conflict management, prioritizing, rewarding and penalizing, etc. Responsibility. Define the activities that each role carries out, such as job duties, processes involved, and the hand-offs to other roles. Qualifications. Describe any prerequisites, experience, licenses, seniority levels, or other qualifications necessary to fulfill the role. Competencies. Describe specific role or job skills and capacities required to complete the work. May include details on languages, technology, or other information necessary to complete the roles successfully.
Training requirements	Describe any required training on equipment, technology, or company processes. Include information on how and when training will be accomplished.
Rewards and recognition	Describe any reward and recognition processes and limitations.
Team development	Describe methods for developing individual team members and the team as a whole.
Physical resource identification	Methods used to identify the materials, equipment, and supplies needed to complete the work. This includes units of measure and techniques to estimate the amount of resources needed, such as information from past projects, parametric estimates, or industry standards.
Physical resource acquisition	Document how equipment, materials, and supplies will be acquired. This can include buy, lease, rent, or pull from inventory. In the event resources are acquired, ensure alignment with procurement management processes.
Physical resource management	Document how materials, equipment, and supplies will be managed to ensure they are available when needed. This can include appropriate inventory, supply chain, and logistics information.

RESOURCE MANAGEMENT PLAN

Project Title: _______________________ Date Prepared: _______________________

Team Member Identification and Estimates

Role	Number	Skill Level
1. 2. 3. 4. 5. 6.	1. 2. 3. 4. 5. 6.	1. 2. 3. 4. 5. 6.

Staff Acquisition	Staff Release:

Roles, Responsibilities, and Authority

Role	Responsibility	Authority
1. 2. 3. 4. 5. 6.	1. 2. 3. 4. 5. 6.	1. 2. 3. 4. 5. 6.

Project Organizational Structure

Training Requirements

Rewards and Recognition

Team Development

Physical Resource Identification and Estimates

Resource	Amount	Grade
1. 2. 3. 4. 5. 6.	1. 2. 3. 4. 5. 6.	1. 2. 3. 4. 5. 6.

Resource Acquisition

Resource Management

2.27 TEAM CHARTER

The team charter is used to establish ground rules and guidelines for the team. It is particularly useful on virtual teams and teams that are comprised of members from different organizations. Using a team charter can help establish expectations and agreements on working effectively together. The contents of the team charter typically include:

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

The team charter is an output from 9.1 Plan Resource Management in the PMBOK^® Guide – Sixth Edition. It is generally developed once and does not change; however, if there is substantial team member turnover, the team should periodically revisit the team charter and reaffirm or update it accordingly.

Tailoring Tips

Consider the following tips to help tailor the team charter to meet your needs:

If you bring in contractors for key roles in the project you should include them in developing the team charter.
If your organization has organizational values, make sure your team charter is aligned with the organizational values.
International teams may need to spend more time developing this document as different cultures have different ways of making decisions and resolving conflicts.

Alignment

The team charter should be aligned and consistent with the following documents:

Resource management plan

Description

You can use the element descriptions in Table 2.25 to assist you in developing a team charter.

TABLE 2.25 Elements of a Team Charter

Document Element	Description
Team values and principles	List values and principles that the team agrees to operate within. Examples include mutual respect, operating from fact not opinion, etc.
Meeting guidelines	Identify guidelines that will keep meetings productive. Examples include decision makers must be present, start on time, stick to the agenda, etc.
Communication guidelines	List guidelines used for effective communication.
	Examples include everyone voices their opinion, no dominating the conversation, no interrupting, not using inflammatory language, etc.
Decision-making process	Describe the process used to make decisions. Indicate the relative power of the project manager for decision making as well as any voting procedures. Also indicate the circumstances under which a decision can be revisited.
Conflict resolution process	Describe the process for managing conflict, when a conflict will be escalated, when it should be tabled for later discussion, etc.
Other agreements	List any other agreements or approaches to ensuring a collaborative and productive working relationship among team members.

TEAM CHARTER

Project Title: _______________________ Date Prepared: _______________________

Team Values and Principles:

1.
2.
3.
4.
5.

Meeting Guidelines:

1.
2.
3.
4.
5.

Communication Guidelines:

1.
2.
3.
4.
5.

Decision-Making Process:

Conflict Resolution Process:

Other Agreements:

Signature:		Date:
____________________________		________________
____________________________		________________
____________________________		________________
____________________________		________________
____________________________		________________
____________________________		________________
____________________________		________________
____________________________		________________

2.28 RESOURCE REQUIREMENTS

The resource requirements describe the type and quantity of resources needed to complete the project work. Resources include:

People
Equipment
Material
Supplies
Locations (as needed)

Locations can include training rooms, testing sites, and so on.

The activity resource requirements can receive information from:

Assumption log
Resource management plan
Scope baseline
Activity list
Activity attributes
Cost estimates resource calendars
Risk register

It provides information to:

Duration estimating worksheet
Project schedule
Cost estimating worksheet
Risk register
Procurement management plan

The resource requirements form is an output from process 9.2 Estimate Activity Resources in the PMBOK^® Guide – Sixth Edition. Resource requirements are based on the project scope. Therefore, if the scope is known and stable, the requirements should remain relatively stable. If the scope is evolving, the resource requirements will evolve as well. The resource requirements will become more detailed and more stable over time.

Tailoring Tips

Consider the following tips to help tailor the resource requirements to meet your needs:

You may want to divide the form into two sections—one for team resources and one for physical resources. As an alternative you can have one section for internal resources and one section for contracted or purchased resources.
Consider adding a column that includes the basis of estimates. This can include supporting detail such as:
- Method used for estimating the quantities
- Range of estimates
- Confidence level of estimates
- Constraints or risks associated with the resource
For projects with large amounts of inventory, supplies, or material you may want to document support requirements, such as inventory, supply chain, and logistical requirements.

Alignment

The resource requirements should be aligned and consistent with the following documents:

Project schedule
Cost estimates
Bid documents

Description

You can use the element descriptions in Table 2.26 to assist you in developing resource requirements.

TABLE 2.26 Elements of Resource Requirements

Document Element	Description
ID	Unique identifier
Type of resource	Indicate whether the resource is a team resource or physical resource. If physical, indicate if it is equipment, supplies, material, location, or some other form of resource.
Quantity	Document the number or quantity of the resource needed for the activity. Indicate the unit of measure used for estimating resources.
Assumptions	Enter assumptions associated with the resource, such as availability, certifications, etc.
Comments	Include information on basis of estimate, grade, competency, or other relevant information.

RESOURCE REQUIREMENTS

Project Title: _______________________ Date Prepared: _______________________

ID	Resource	Quantity	Assumptions	Comments

2.29 RESOURCE BREAKDOWN STRUCTURE

The resource breakdown structure is a hierarchical structure used to organize the resources by type and category. It can be shown as a hierarchical chart or as an outline.

The resource breakdown structure can receive information from:

Assumption log
Resource management plan
Scope baseline
Activity attributes

It provides information to:

Duration estimates worksheet

The resource breakdown structure is an output from process 9.2 Estimate Activity Resources in the PMBOK^® Guide – Sixth Edition. Resources are based on the project scope. Therefore, if the scope is known and stable, the requirements should remain relatively stable. If the scope is evolving, the resource requirements will evolve as well.

Tailoring Tips

Consider the following tips to help tailor the resource breakdown structure to meet your needs:

For projects with many different types of team resources you may want to decompose the team branch further by including information on skill level, required certifications, location, or other information.
For projects that have different locations you may want to organize the resource breakdown structure by geography.

Alignment

The resource breakdown structure should be aligned and consistent with the following documents:

Resource management plan
Resource requirements

2.30 COMMUNICATIONS MANAGEMENT PLAN

The communications management plan is a component of the project management plan. It describes how project communications will be planned, structured, implemented, and monitored for effectiveness. Typical information includes:

Stakeholder communication requirements
Information
Method or media
Time frame and frequency
Sender
Communication assumptions and constraints
Glossary of common terminology

In addition, the communications management plan can include resources, time, and budgets associated with communication activities, methods for addressing sensitive or proprietary information, and methods for updating the communications management plan.

The communications management plan can receive information from:

Project charter
Requirements documentation
Resource management plan
Stakeholder register
Stakeholder engagement plan

It provides information to:

Stakeholder register
Stakeholder engagement plan

The communications management plan is an output from process 10.1 Plan Communications Management in the PMBOK^® Guide – Sixth Edition. It is updated periodically throughout the project as stakeholders are added and leave the project and as communications needs emerge and shift.

Tailoring Tips

Consider the following tips to help tailor the communications management plan to meet your needs:

When multiple organizations are working on a project there will be additional information needed, such as:
- Person responsible for authorizing release of internal or confidential information
- How different communication hardware, software, and technologies will be addressed to ensure information gets to everyone regardless of their communication infrastructure
If you have a multinational team your plan will need to account for the business language, currency unit of measure, translation, and other factors required to ensure effective communication across multiple countries and cultures.
On a project that has a significant communication component you will want to identify the resources allocated for communication activities, the time requirements, and the budget allocated.
For projects with complex communication needs, include a flowchart of the sequence of communication events.

Alignment

The communications management plan should be aligned and consistent with the following documents:

Project schedule
Stakeholder register
Stakeholder engagement plan

Description

You can use the element descriptions in Table 2.27 to assist you in developing the communications management plan.

TABLE 2.27 Elements of a Communications Management Plan

Document Element	Description
Stakeholder communication requirements	The people or the groups of people who need to receive project information and their specific requirements
Information	Describe the information to be communicated, including language, format, content, and level of detail.
Method or media	Describe how the information will be delivered; for example, email, meetings, web meetings, etc.
Time frame and frequency	List how often the information is to be provided and under what circumstances.
Sender	Insert the name of the person or the group that will provide the information.
Communication constraints or assumptions	List any assumptions or constraints. Constraints can include descriptions of proprietary, secure, or sensitive information and relevant restrictions for distribution.
Glossary of common terminology	List any terms or acronyms unique to the project or that are used in a unique way.

COMMUNICATIONS MANAGEMENT PLAN

Project Title: _______________________ Date Prepared: _______________________

Stakeholder	Information	Method	Timing or Frequency	Sender

Assumptions	Constraints

Glossary of Terms or Acronyms:

Attach relevant communication diagrams or flowcharts.

2.31 RISK MANAGEMENT PLAN

The risk management plan is a component of the project management plan. It describes how risk management activities will be structured and performed for both threats and opportunities. Typical information includes:

Risk strategy
Methodology
Roles and responsibilities for risk management
Funding to identify, analyze, and respond to risk
Frequency and timing for risk management activities
Risk categories
Stakeholder risk appetite
Definitions of probability
Definitions of impact by objective
Probability and impact matrix template
Methods to track and audit risk management activities
Risk report formats

The risk management plan can receive information from:

Project charter
Project management plan (any component)
Stakeholder register

It provides information to:

Cost management plan
Quality management plan
Risk register
Stakeholder engagement plan

The risk management plan is an input to all the other risk management processes. It describes the approach to all other risk management processes and provides key information needed to conduct those processes successfully.

The risk management plan is an output from process 11.1 Plan Risk Management in the PMBOK^® Guide – Sixth Edition. It is developed once and does not usually change.

Tailoring Tips

Consider the following tips to help tailor the risk management plan to meet your needs:

For a small, simple, or short-term project you can use a simplified risk register with a 3 × 3 probability and impact matrix. You would also include risk information in the project status report rather than a separate risk report.
For larger, longer, and more complex projects you will want to develop a robust risk management process, including a more granular probability and impact matrix, quantitative assessments for the schedule and budget baselines, risk audits, and risk reports.
Projects that are using an agile approach will address risk at the start of each iteration and during the retrospective.

Alignment

The risk management plan should be aligned and consistent with the following documents:

Scope management plan
Schedule management plan
Cost management plan
Quality management plan
Resource management plan
Procurement management plan
Stakeholder engagement plan

Description

You can use the element descriptions in Table 2.28 to assist you in developing the risk management plan.

TABLE 2.28 Elements of a Risk Management Plan

Document Element	Description
Strategy	The general approach to managing risk on the project
Methodology	Describe the methodology or approach to the risk management. This includes any tools, approaches, or data sources that will be used.
Roles and responsibilities	Document the roles and responsibilities for various risk management activities.
Risk categories	Identify categorization groups used to sort and organize risks. These can be used to sort risks on the risk register or for a risk breakdown structure, if one is used.
Risk management funding	Document the funding needed to perform the various risk management activities, such as utilizing expert advice or transferring risks to a third party. Also establishes protocols for establishing, measuring, and allocating contingency and management reserves.
Frequency and timing	Determine the frequency of conducting formal risk management activities and the timing of any specific activities.
Stakeholder risk appetite	Identify the risk thresholds of the organization(s) and key stakeholders on the project with regard to each objective.
Risk tracking and audit	Document how risk activities will be recorded and how risk management processes will be audited.
Definitions of probability	Document how probability will be measured and defined. Include the scale used and the definition for each level in the probability scale. The probability definitions should reflect the stakeholder risk appetite. For example: Very high = there is an 80 percent probability or higher that the event will occur High = there is a 60–80 percent probability that the event will occur Medium = there is a 40–60 percent probability that the event will occur Low = there is a 20–40 percent probability that the event will occur Very low = there is a 1–20 percent probability that the event will occur
Definitions of impact by objective	Document how impact will be measured and defined for either the project as a whole or for each objective. The probability definitions should reflect the stakeholder risk appetite. Include the scale used and the definition for each level in the impact scale. For example: Cost Impacts: Very high = overrun of control account budget of >20 percent High = overrun of control account budget between 15–20 percent Medium = overrun of control account budget between 10–15 percent Low = overrun of control account budget between 5–10 percent Very low = overrun of control account budget of <5 percent
Probability and impact matrix	Describe the combinations of probability and impact that indicate a high risk, a medium risk, and a low risk and the scoring that will be used to prioritize risks. This can also include an assessment of urgency to indicate how soon the risk event is likely to occur.

RISK MANAGEMENT PLAN

Project Title: _______________________ Date Prepared: _______________________

Strategy

Methodology

Roles and Responsibilities

Role	Responsibility
1. 2. 3. 4.	1. 2. 3. 4.

Risk Categories

Risk Management Funding

Contingency Protocols

Frequency and Timing

Stakeholder Risk Tolerances

Risk Tracking and Audit

Definitions of Probability

Very High
High
Medium
Low
Very Low

Definitions of Impact by Objective

	Scope	Quality	Time	Cost
Very High
High
Medium
Low
Very Low

Probability and Impact Matrix

Very High
High
Medium
Low
Very Low
	Very Low	Low	Medium	High	Very High

2.32 RISK REGISTER

The risk register captures the details of identified individual risks. It documents the results of risk analysis, risk response planning, response implementation, and current status. It is used to track information about identified risks over the course of the project. Typical information includes:

Risk identifier
Risk statement
Risk owner
Probability of occurring
Impact on objectives if the risk occurs
Risk score
Response strategies
Revised probability
Revised impact
Revised score
Actions
Status
Comments

The risk register can receive information from anywhere in the project environment. Some documents that should be specifically reviewed for input include:

Assumption log
Issue log
Lessons learned register
Requirements management plan
Requirements documentation
Scope baseline
Schedule management plan
Duration estimates
Schedule baseline
Cost management plan
Cost estimates
Cost baseline
Quality management plan
Resource management plan
Resource requirements
Risk management plan
Procurement documents
Agreements
Stakeholder register

The risk register provides information to:

Scope statement
Duration estimates
Cost estimates
Quality management plan
Resource requirements
Risk report
Procurement management plan
Stakeholder engagement plan
Lessons learned register
Project closeout

The risk register is an output from process 11.2 Identify Risks in the PMBOK^® Guide – Sixth Edition. It is developed at the start of the project and is updated throughout the project.

Description

You can use the element descriptions in Table 2.29 to assist you in developing the risk register.

TABLE 2.29 Elements of a Risk Register

Document Element	Description
Risk ID	Enter a unique risk identifier.
Risk statement	Describe the risk event or condition. A risk statement is usually phrased as “EVENT may occur, causing IMPACT” or “If CONDITION exists, EVENT may occur, leading to EFFECT.”
Risk owner	The person responsible for managing and tracking the risk
Probability	Determine the likelihood of the event or condition occurring.
Impact	Describe the impact on one or more of the project objectives.
Score	If you are using numeric scoring, multiply the probability times the impact to determine the risk score. If you are using relative scoring then combine the two scores (e.g., high-low or medium-high).
Response	Describe the planned response strategy to the risk or condition.
Revised probability	Determine the likelihood of the event or condition occurring after the response has been implemented.
Revised impact	Describe the impact once the response has been implemented.
Revised score	Enter the revised risk score once the response has been implemented.
Actions	Describe any actions that need to be taken to respond to the risk.
Status	Enter the status as open or closed.
Comments	Provide any comments or additional helpful information about the risk event or condition.

RISK REGISTER

Project Title: _______________________ Date Prepared: _______________________

				Impact
ID	Risk Statement	Owner	Probability	Score	Response	Scope	Quality	Schedule	Cost

	Impact
Revised Probability	Scope	Quality	Schedule	Cost	Revised Score	Responsible Party	Actions	Status	Comments

2.33 RISK REPORT

The risk report presents information on overall project risk and summarizes information on individual project risks. It provides information for each of the processes from identification of risks, through analysis, response planning and implementation, and monitoring risks. Typical information includes:

Executive summary
Description of overall project risk
Description of individual project risks
Quantitative analysis
Reserve status
Risk audit results (if applicable)

The risk report can receive information from anywhere in the project environment. Some documents that should be specifically reviewed for input include:

Assumption log
Issue log
Lessons learned register
Risk management plan
Project performance reports
Variance analysis
Earned value status
Risk audit
Contractor status reports

The risk report provides information to:

Lessons learned register
Project closeout report

The risk report is an output from process 11.2 Identify Risks in the PMBOK® Guide – Sixth Edition. It is developed at the start of the project and is updated throughout the project.

Tailoring Tips

Consider the following tips to help tailor the risk report to meet your needs:

For a small, simple, or short-term project you can summarize this information in the regular project status report rather than create a separate risk report.
Many projects do not include a quantitative risk analysis; if yours does not, omit this information from the report.
For larger, longer, and more complex projects you can tailor the quantitative risk analysis techniques used to those most appropriate to your project.
For more robust risk reports include appendices that may include the full risk register and quantitative risk model input (probabilistic distributions, branch correlation groups).

Alignment

The risk report should be aligned and consistent with the following documents:

Assumption log
Issue register
Project performance report
Risk management plan
Risk register

Description

You can use the element descriptions in Table 2.30 to assist you in developing the risk report.

TABLE 2.30 Elements of a Risk Report

Document Element	Description
Executive summary	A statement describing the overall project risk exposure and major individual risks affecting the project, along with the proposed responses for trends.
Overall project risk	Provide a description of the overall risk of the project, including: High-level statement of trends Significant drivers of overall risk Recommended responses to overall risk
Individual project risks	Analyze and summarize information associated with individual project risks, including: Number of risks in each box of the probability impact matrix Key metrics Active risks Newly closed risks Risks distribution by category, objective, and score Most-critical risks and changes since last report Recommended responses to top risks
Quantitative analysis	Summarize the results of quantitative risk analysis, including: Results from quantitative assessments (S-curve, tornado, etc.) Probability of meeting key project objectives Drivers of cost and schedule outcomes Proposed responses
Reserve status	Describe the reserve status, such as reserve used, reserve remaining, and an assessment of the adequacy of the reserve.
Risk audit results (if applicable)	Summarize the results of a risk audit of the risk management processes.

RISK REPORT

Project Title: _______________________ Date: _______________________

Executive Summary

Overall Project Risk

Overall Risk Status and Trends

Significant Drivers of Overall Risk	Recommended Responses

INDIVIDUAL PROJECT RISKS

Indicate the number of individual risks in each box below.

VH
H
M
L
VL
	VL	L	M	H	VH

Metrics

Number of scope risks
Number of schedule risks
Number of cost risks
Number of quality risks
Number of very high probability risks
Number of high probability risks
Number of medium probability risks
Number of active risks
Newly closed risks

Critical Risks

Top Risks	Responses
1.	1.
2.	2.
3.	3.
4.	4.
5.	5.

Changes to Critical Risks

Quantitative Analysis Summary

Probability of Meeting Objectives:

Scope	Schedule	Cost	Quality	Other

Range of Outcomes

Range of Schedule Outcomes	Range of Cost Outcomes

Key Drivers of Variances	Proposed Responses

Reserve Status

Total Cost Reserve	Used to Date	Used This Period	Remaining Reserve

Total Schedule Reserve	Used to Date	Used This Period	Remaining Reserve

Assessment of Reserve Adequacy

Risk Audit Summary

Summary of Risk Events
Summary of Risk Management Processes
Summary of Recommendations

2.34 PROBABILITY AND IMPACT ASSESSMENT

Definitions for probability and impact are defined in the risk management plan. If your project does not have a risk management plan, you can develop a probability and impact assessment to record definitions for the likelihood of events occurring (probability), and the impact on the various project objectives if they do occur. It also has a key to assign an overall risk rating based on the probability and impact scores.

The probability and impact assessment can receive information from:

Risk management plan
Risk register

It provides information to the risk register.

The probability and impact assessment is a tool used in 11.3 Perform Qualitative Risk Analysis in the PMBOK^® Guide – Sixth Edition. It is developed once and does not usually change.

Tailoring Tips

Consider the following tips to help tailor the probability and impact matrix to meet your needs:

On smaller projects the impacts may be grouped together without distinguishing impact by objective.
The matrix can be 3 × 3 for a small project, 5 × 5 for a medium project, and 10 × 10 for a complex or large project.
To indicate the relative criticality of various objectives (usually scope, schedule, cost, and quality), you can include a tighter range of thresholds between levels. For example, if cost is a critical factor, consider a very low impact as a 2 percent variance, a low variance as a 4 percent impact, a medium variance as a 6 percent variance, a high variance as 8 percent, and a very high variance as a 10 percent variance. If the cost is more relaxed you might have a loose range such as: very low impact as a 5 percent variance, a low variance as a 10 percent impact, a medium variance as a 15 percent variance, a high variance as 20 percent, and a very high variance as a 25 percent variance.
If there are other objectives that are important to the project, such as stakeholder satisfaction, you can incorporate them. Some organizations combine scope and quality into one objective.
You can make the assessment more robust by including urgency information to indicate if a risk is imminent or in the distant future.

Alignment

The probability and impact assessment should be aligned and consistent with the following documents:

Risk management plan
Risk register
Probability and impact matrix
Stakeholder register

Description

You can use the assessment descriptions in Table 2.31 to assist you in developing a probability and impact assessment.

TABLE 2.31 Elements of a Probability Impact Assessment

Document Element	Description
Scope impact	Very High	The product does not meet the objectives and is effectively useless
	High	The product is deficient in multiple essential requirements
	Medium	The product is deficient in one major requirement or multiple minor requirements
	Low	The product is deficient in a few minor requirements
	Very Low	Minimal deviation from requirements
Quality impact	Very High	Performance is significantly below objectives and is effectively useless
	High	Major aspects of performance do not meet requirements
	Medium	At least one performance requirement is significantly deficient
	Low	There is minor deviation in performance
	Very Low	There is minimal deviation in performance
Schedule impact	Very High	Greater than 20 percent overall schedule increase
	High	Between 10 percent and 20 percent overall schedule increase
	Medium	Between 5 percent and 10 percent overall schedule increase
	Low	Noncritical paths have used all their float, or overall schedule increase of 1 to 5 percent
	Very Low	Slippage on noncritical paths but float remains
Cost impact	Very High	Cost increase of greater than 20 percent
	High	Cost increase of 10 to 20 percent
	Medium	Cost increase of 5 to 10 percent
	Low	Cost increase that requires use of all contingency funds
	Very Low	Cost increase that requires use of some contingency but some contingency funds remain
Probability	Very High	The event will most likely occur: 80 percent or greater probability
	High	The event will probably occur: 61 to 80 percent probability
	Medium	The event is likely to occur: 41 to 60 percent probability
	Low	The event may occur: 21 to 40 percent probability
	Very Low	The event is unlikely to occur: 1 to 20 percent probability
Risk rating	High	Any event with a probability of medium or above and a very high impact on any objective Any event with a probability of high or above and a high impact on any objective Any event with a probability of very high and a medium impact on any objective Any event that scores a medium on more than two objectives
	Medium	Any event with a probability of very low and a high or above impact on any objective Any event with a probability of low and a medium or above impact on any objective Any event with a probability of medium and a low to high impact on any objective Any event with a probability of high and a very low to medium impact on any objective Any event with a probability of very high and a low or very low impact on any objective Any event with a probability of very low and a medium impact on more than two objectives
	Low	Any event with a probability of medium and a very low impact on any objective Any event with a probability of low and a low or very low impact on any objective Any event with a probability of very low and a medium or less impact on any objective

2.35 PROBABILITY AND IMPACT MATRIX

The probability and impact matrix is a table that is used to plot each risk after performing a probability and impact assessment. The probability and impact assessment determines the probability and impact of the risk. This matrix provides a helpful way to view the various risks on the project and prioritize them for responses. It may be constructed for threats and opportunities. Information from this matrix will be transferred to the risk register.

This matrix also provides an overview of the amount of risk on the project. The project team can get an idea of the overall project risk by seeing the number of risks in each square of the matrix. A project with many risks in the red zone will need more contingency to absorb the risk and likely more time and budget to develop and implement risk responses.

The probability and impact matrix can receive information from:

Risk management plan
Probability and impact risk assessment
Risk register

It provides information to the risk register.

The probability and impact matrix is a tool used in 11.3 Perform Qualitative Risk Analysis in the PMBOK^® Guide – Sixth Edition. It is updated throughout the project.

Tailoring Tips

Consider the following tips to help tailor the probability and impact matrix to meet your needs:

The matrix can be a 3 × 3 for a small project, 5 × 5 for a medium project, and 10 × 10 for a complex or large project.
The numbering structure of the probability and impact matrix can be tailored to emphasize the high risks by creating a nonlinear numbering structure. For example, impact scores can be set up to double every increment. For example: Very Low = .5, Low = 1, Medium = 2, High = 4, and Very High = 8.
The relative importance of the objectives can be weighted. If schedule is most important you may weight that as 40 percent of the score, whereas scope, quality, and cost all have a weight of 20 percent (make sure the total is 100 percent).
The combination of probability and impact that indicates a risk is high, medium, or low can be tailored to reflect the organization’s risk appetite. An organization with a low risk appetite may rank events that fall in the medium or high range for both impact and probability as high risk. An organization with a higher risk threshold may only rank risk with a very high probability and impact as high risk.

Alignment

The probability and impact assessment and matrix should be aligned and consistent with the following documents:

Risk management plan
Risk register
Probability and impact assessment
Stakeholder register

2.36 RISK DATA SHEET

A risk data sheet contains information about a specific identified risk. The information is filled in from the risk register and updated with more detailed information. Typical information includes:

Risk identifier
Risk description
Status
Risk cause
Probability
Impact on each objective
Risk score
Response strategies
Revised probability
Revised impact
Revised score
Responsible party
Actions
Secondary risks
Residual risks
Contingency plans
Schedule or cost contingency
Fallback plans
Comments

The risk data sheet can receive information from:

Risk register

It can be started in process 11.2 Identify Risks from the PMBOK^® Guide – Sixth Edition. It is continuously updated and elaborated throughout the project.

Tailoring Tips

Consider the following tips to help tailor the risk data sheet to meet your needs:

Not all projects require risk data sheets. Where they are used, they are considered an extension of the risk register.
You can add or delete any fields you feel necessary.

Alignment

The risk data sheet should be aligned and consistent with the following documents:

Risk register
Probability and impact matrix
Risk report

Description

You can use the element descriptions in Table 2.32 to assist you in developing the risk data sheet.

TABLE 2.32 Elements of a Risk Data Sheet

Document Element	Description
Risk ID	Enter a unique risk identifier.
Risk description	Provide a detailed description of the risk.
Status	Enter the status as open or closed.
Risk cause	Describe the circumstances or drivers that are the source of the risk.
Probability	Determine the likelihood of the event or condition occurring.
Impact	Describe the impact on one or more of the project objectives.
Score	If you are using numeric scoring, multiply the probability times the impact to determine the risk score. If you are using relative scoring then combine the two scores (e.g., high-low or medium-high).
Reponses	Describe the planned response strategy to the risk or condition.
Revised probability	Determine the likelihood of the event or condition occurring after the response has been implemented.
Revised impact	Describe the impact once the response has been implemented.
Revised score	Enter the revised risk score once the response has been implemented.
Responsible party	Identify the person responsible for managing the risk.
Actions	Describe any actions that need to be taken to respond to the risk.
Secondary risks	Describe new risks that arise out of the response strategies taken to address the risk.
Residual risk	Describe the remaining risk after response strategies.
Contingency plan	Develop a plan that will be initiated if specific events occur, such as missing an intermediate milestone. Contingency plans are used when the risk or residual risk is accepted.
Contingency funds	Determine the funds needed to protect the budget from overrun.
Contingency time	Determine the time needed to protect the schedule from overrun.
Fallback plans	Devise a plan to use if other response strategies fail.
Comments	Provide any comments or additional helpful information about the risk event or condition.

2.37 PROCUREMENT MANAGEMENT PLAN

The procurement management plan is a component of the project management plan that describes the activities undertaken during the procurement process. It describes how all aspects of a procurement will be managed. Typical information includes:

How procured work will be coordinated and integrated with other project work. Of specific interest is:
- Scope
- Schedule
- Documentation
- Risk
Timing of procurement activities
Contract performance metrics
Procurement roles, responsibility, and authority
Procurement constraints and assumptions
Legal jurisdiction and currency
Information on use of independent estimates
Risk management concerns, such as need for bonds or insurance
Prequalified sellers lists

The procurement management plan can receive information from:

Project charter
Stakeholder register
Scope management plan
Requirements documentation
Requirements traceability matrix
Scope baseline
Milestone list
Project schedule
Quality management plan
Resource management plan
Resource requirements
Risk register
Project team assignments

It provides information to:

Risk register
Stakeholder register

The procurement management plan is an output from process 12.1 Plan Procurement Management in the PMBOK^® Guide – Sixth Edition. It is developed once and does not usually change.

Tailoring Tips

Consider the following tips to help tailor the procurement management plan to meet your needs:

For a project that will be done using internal resources only, you do not need a procurement management plan.
For a project where materials will be purchased and there is a standing purchase order with a vendor, you will not need a procurement management plan.
For projects with a few procurements consider combining this form with the procurement strategy.
You may wish to combine the assumptions and constraints for procurements with the assumption log.
Work with the contracting or legal department to ensure compliance with organizational purchasing policies.

Alignment

The procurement management plan should be aligned and consistent with the following documents:

Scope management plan
Requirements management plan
Scope baseline
Schedule management plan
Project schedule
Cost management plan
Cost estimates
Project budget
Procurement strategy

Description

You can use the element descriptions in Table 2.33 to assist you in developing the procurement management plan.

TABLE 2.33 Elements of a Procurement Management Plan

Document Element	Description
Procurement integration	Scope	Define how the contractor's WBS will integrate with the project WBS.
	Schedule	Define how the contractor's schedule will integrate with the project schedule, including milestones and long lead items.
	Documentation	Describe how contractor documentation will integrate with project documentation.
	Risk	Describe how risk identification, analysis, and response will integrate with risk management for the overall project.
	Reporting	Define how the contractor's status reports will integrate with the project status report.
Timing	Identify the timetable of key procurement activities. Examples include when the statement of work (SOW) will be complete, when procurement documents will be released, the date proposals are due, and so forth.
Performance metrics	Document the metrics that will be used to evaluate the seller's performance.
Roles, responsibilities, and authority	Define the roles, responsibilities, and authority level of the project manager, contractor, and procurement department, as well as any other significant stakeholders for the contract.
Assumptions and constraints	Record assumptions and constraints related to the procurement activities.
Legal jurisdiction and currency	Identify the location that has legal jurisdiction. Identify the currency that will be used for pricing and payment.
Independent estimates	Document whether independent cost estimates will be used and if they will be needed for source selection.
Risk management	Document requirements for performance bonds or insurance contracts to reduce risk.
Prequalified sellers	List any prequalified sellers that will be used.

PROCUREMENT MANAGEMENT PLAN

Project Title: _______________________ Date: _______________________

Procurement Integration

Area	Integration Approach
Scope
Schedule
Documentation
Risk
Reporting

Timing of Key Procurement Activities

Date	Activity

Performance Metrics

Item	Metric	Measurement Method

Roles, Responsibility, and Authority

Role	Responsibility	Authority

Assumptions and Constraints

Category	Assumption/Constraint

Legal Jurisdiction and Currency

Independent Estimates

Risk Management

Prequalified Sellers

2.38 PROCUREMENT STRATEGY

The procurement strategy is a project document that describes information about specific procurements. Typical information includes:

Delivery methods
Contract types
Procurement phases

The procurement strategy can receive information from:

Project charter
Stakeholder register
Project roadmap
Requirements documentation
Requirements traceability matrix
Scope baseline
Milestone list
Project schedule
Resource management plan
Resource requirements

It provides information to:

Project schedule
Project budget
Quality management plan
Risk register

The procurement strategy is an output from process 12.1 Plan Procurement Management in the PMBOK® Guide – Sixth Edition. It is developed once for each procurement when needed.

Tailoring Tips

Consider the following tips to help tailor the procurement strategy to meet your needs:

For a project that will be done using internal resources only, you do not need a procurement strategy.
For projects with few procurements consider combining this form with the procurement management plan.
For simple purchases, or for purchases where you have worked with a vendor successfully for a length of time, you may not need a formal procurement strategy; rather you would record the information in a statement of work (SOW) that would be part of the contract.
Work with the contracting or legal department to ensure compliance with organizational purchasing policies.

Alignment

The procurement strategy should be aligned and consistent with the following documents:

Project charter
Project roadmap
Requirements documentation
Requirements traceability matrix
Schedule management plan
Cost management plan
Resource management plan
Procurement management plan

Description

You can use the element descriptions in Table 2.34 to assist you in developing the procurement strategy.

TABLE 2.34 Elements of a Procurement Strategy

Document Element	Description
Delivery methods	Professional services	Describe how the contractor will work with the buyer; for example, in a joint venture, as a representative, with or without subcontracting allowed.
	Construction services	Describe the limitations of delivery, such as design build, design bid build, etc.
Contract types	Describe the contract type, fixed, incentive, or award fees. Include the criteria associated with the fees. Common contract types include: Fixed Price: FFP – Firm Fixed Price FPIF – Fixed Price with Incentive Fee FP-EPA – Fixed Price with Economic Price Adjustment Cost Reimbursable: CPFF – Cost Plus Fixed Fee CPIF – Cost Plus Incentive Fee CPAF – Cost Plus Award Fee Time and Materials (T&M)
Procurement phases	List the procurement phases, milestones, criteria to advance to the next phase, and tests or evaluations for each phase. Include any knowledge transfer requirements.

PROCUREMENT STRATEGY

Project Title: _______________________ Date: _______________________

Delivery Method

Contract Type

□ FFP

□ FPIF

□ FP-EPA

□ CPFF

□ CPIF

□ CPAF

□ T&M

□ Other

Incentive or Award Fee	Criteria

Procurement Life Cycle

Phase	Entry Criteria	Key Deliverables or Milestones	Exit Criteria	Knowledge Transfer

2.39 SOURCE SELECTION CRITERIA

Source selection criteria is a set of attributes desired by the buyer that a seller must meet or exceed to be selected for a contract. The source selection criteria form is an aid in determining and rating the criteria that will be used to evaluate bid proposals. This is a multistep process.

The criteria to evaluate bid responses are determined.
A weight is assigned to each criterion. The sum of all the criteria must equal 100 percent.
The range of ratings for each criterion is determined, such as 1–5 or 1–10.
The performance necessary for each rating is defined.
Each proposal is evaluated against the criteria and is rated accordingly.
The weight is multiplied by the rate and a score for each criterion is derived.
The scores are totaled and the highest total score is the winner of the bid.

Evaluation criteria commonly include such items as:

Capability and capacity
Product cost and life cycle cost
Delivery dates
Technical expertise
Prior experience
Proposed approach and work plan
Key staff qualifications, availability, and competence
Financial stability
Management experience
Training and knowledge transfer

The source selection criteria is an output from process 12.1 Plan Procurement Management in the PMBOK^® Guide – Sixth Edition. Source selection criteria is established for each major procurement.

Tailoring Tips

Consider the following tips to help tailor the source selection criteria to meet your needs:

For a small procurement that is not complex, you likely won't need to develop a weighted source selection criteria form.
For international procurements you may also want to include familiarity with local laws and regulations, as well as experience and relationships in the locations involved.
For construction projects, or projects with many logistical concerns, you could include logistics handling as a selection criteria.

Alignment

The source selection criteria should be aligned and consistent with the following documents:

Requirements documentation
Scope baseline
Project schedule
Resource management plan
Resource requirements
Procurement management plan
Procurement strategy

Description

You can use the element descriptions in Table 2.35 to assist you in developing the source selection criteria.

TABLE 2.35 Elements of Source Selection Criteria

Document Element	Description
Criteria	Describe what a 1 means for the criteria. For example, for experience, it may mean that the bidder has no prior experience. Describe what a 2 means for the criteria. For example, for experience, it may mean that the bidder has done 1 similar job. Describe what a 3 means for the criteria. For example, for experience, it may mean that the bidder has done 3 to 5 similar jobs. Describe what a 4 means for the criteria. For example, for experience, it may mean that the bidder has done 5 to 10 similar jobs. Describe what a 5 means for the criteria. For example, for experience, it may mean that the job is the bidder’s core competency.
Weight	Enter the weight for each criterion. Total weight for all criteria must equal 100 percent.
Candidate rating	Enter the rating per the criteria above.
Candidate score	Multiply the weight times the rating.
Total	Sum the scores for each candidate.

SOURCE SELECTION CRITERIA

Project Title: _______________________ Date Prepared: _______________________

	1	2	3	4	5
Criterion 1
Criterion 2
Criterion 3
Criterion 4
Criterion 5

	Weight	Candidate 1 Rating	Candidate 1 Score	Candidate 2 Rating	Candidate 2 Score	Candidate 3 Rating	Candidate 3 Score
Criterion 1
Criterion 2
Criterion 3
Criterion 4
Criterion 5
Totals

2.40 STAKEHOLDER ENGAGEMENT PLAN

The stakeholder engagement plan is a component of the project management plan. It describes the strategies and actions that will be used to promote productive involvement of stakeholders in decision making and project execution. Typical information includes:

Desired and current engagement level of key stakeholders
Scope and impact of change to stakeholders
Interrelationships and potential overlap between stakeholders
Engagement approach for each stakeholder or group of stakeholders

In addition, the stakeholder engagement plan can include methods for updating and refining the plan throughout the project.

The stakeholder engagement plan can receive information from:

Project charter
Assumption log
Change log
Issue log
Stakeholder register
Resource management plan
Project schedule
Communications management plan
Risk management plan
Risk register

It provides information to:

Requirements documentation
Quality management plan
Communications management plan
Stakeholder register

The stakeholder engagement plan is an output from process 13.2 Plan Stakeholder Engagement in the PMBOK^® Guide – Sixth Edition. It is updated periodically throughout the project as needed.

Tailoring Tips

Consider the following tips to help tailor the stakeholder engagement plan to meet your needs:

For small projects you may not need a stakeholder engagement plan. You can combine the information with the stakeholder register as appropriate.
Projects with multiple stakeholders with overlapping and intersecting relationships can benefit from having a stakeholder relationship map that shows the connections.
For many high-risk projects, stakeholder engagement is critical to success. For projects with many stakeholders, complex interactions, and high-risk stakeholders you will need to have a robust stakeholder engagement plan.

Alignment

The stakeholder engagement plan should be aligned and consistent with the following documents:

Stakeholder register
Communications management plan
Project schedule

Description

You can use the element descriptions in Table 2.36 to assist you in developing the stakeholder engagement plan.

TABLE 2.36 Elements of a Stakeholder Engagement Plan

Document Element	Description
Stakeholder engagement assessment matrix	Use information from the stakeholder register to document stakeholders. Document “current” stakeholder engagement level with a “C” and “desired” stakeholder engagement with a “D.” A common format includes the following stakeholder participation descriptions: Unaware. Unaware of project and its potential impacts Resistant. Aware of project and potential impacts and resistant to the change Neutral. Aware of project yet neither supportive nor resistant Supportive. Aware of project and potential impacts and supportive of change Leading. Aware of project and potential impacts and actively engaged in ensuring project success
Stakeholder changes	Describe any pending additions, deletions, or changes to stakeholders and the potential impact to the project.
Interrelationships	List any relationships between and among stakeholder groups.
Stakeholder engagement approach	Describe the approach you will use with each stakeholder to move them to the preferred level of engagement.

STAKEHOLDER ENGAGEMENT PLAN

Project Title: _______________________ Date Prepared: _______________________

Stakeholder	Unaware	Resistant	Neutral	Supportive	Leading

C = Current level of engagement

D = Desired level of engagement

Pending Stakeholder Changes

Stakeholder Relationships

Stakeholder Engagement Approach

Stakeholder	Approach

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.

Table of Contents for 2 Planning Forms

Create new playlist

Sign In

Sign Up

2.0 PLANNING PROCESS GROUP

2.1 PROJECT MANAGEMENT PLAN

Tailoring Tips

Alignment

Description

2.2 CHANGE MANAGEMENT PLAN

Tailoring Tips

Alignment

Description

2.3 PROJECT ROADMAP

Tailoring Tips

Alignment

Description

2.4 SCOPE MANAGEMENT PLAN

Tailoring Tips

Alignment

Description

2.5 REQUIREMENTS MANAGEMENT PLAN

Tailoring Tips

Alignment

Description

2.6 REQUIREMENTS DOCUMENTATION

Tailoring Tips

Alignment

Description

2.7 REQUIREMENTS TRACEABILITY MATRIX

Tailoring Tips

Alignment

Description

2.8 PROJECT SCOPE STATEMENT

Tailoring Tips

Alignment

Description

2.9 WORK BREAKDOWN STRUCTURE

Tailoring Tips

Alignment

Description

2.10 WBS DICTIONARY

Tailoring Tips

Alignment

Description

2.11 SCHEDULE MANAGEMENT PLAN

Tailoring Tips

Alignment

Description

2.12 ACTIVITY LIST

Tailoring Tips

Alignment

Description

2.13 ACTIVITY ATTRIBUTES

Tailoring Tips

Alignment

Description

2.14 MILESTONE LIST

Tailoring Tips

Alignment

Description

2.15 NETWORK DIAGRAM

Tailoring Tips

Alignment

2.16 DURATION ESTIMATES

Tailoring Tips

Alignment

Description

2.17 DURATION ESTIMATING WORKSHEET

Description

2.18 PROJECT SCHEDULE

Tailoring Tips

Alignment

2.19 COST MANAGEMENT PLAN

Tailoring Tips

Alignment

Description

2.20 COST ESTIMATES

Tailoring Tips

Alignment

Table of Contents for
2 Planning Forms