Chapter 5
Planning Project Resource, Communication, Procurement, Change, and Risk Management

THE PMP® EXAM CONTENT FROM THE PLANNING PERFORMANCE DOMAIN COVERED IN THIS CHAPTER INCLUDES THE FOLLOWING:

  • images Develop the human resource management plan by defining the roles and responsibilities of the project team members in order to create a project organizational structure and provide guidance regarding how resources will be assigned and managed.
  • images Develop the communications management plan based on the project organizational structure and stakeholder requirements in order to define and manage the flow of project information.
  • images Develop the procurement management plan based on the project scope, budget, and schedule in order to ensure that the required project resources will be available.
  • images Develop the change management plan by defining how changes will be addressed and controlled in order to track and manage change.
  • images Plan for risk management by developing a risk management plan; identifying, analyzing, and prioritizing project risk; creating the risk register; and defining risk response strategies in order to manage uncertainty and opportunity throughout the project life cycle.

images In this chapter, we continue to address content that belongs to the Planning process group and related exam domain. Specifically, we will address the following Knowledge Areas: Project Resource Management, Project Communications Management, Project Procurement Management, and Project Risk Management.

Planning is by far the largest process group when it comes to the number of project management processes. In the chapter that follows, Chapter 6, we will finalize our review of the Planning process group.

Developing a Resource Management Plan

The project manager creates a resource management plan by carrying out a process called Plan Resource Management. Through this process, roles and responsibilities of the project team members are defined and the strategies for using and managing the project team, equipment, and inventory are documented. The high-level purpose of the plan itself is to create an effective project organization structure.

The Plan Resource Management process is responsible for defining how to estimate, acquire, manage, and use physical and human resources; it documents the roles and responsibilities of individuals or groups for various project elements and then documents the reporting relationships for each. Reporting relationships can be assigned to groups as well as to individuals, and the groups or individuals might be internal or external to the organization or a combination of both. This process will result in the creation of the resource management plan, which considers factors such as the availability of resources, skill levels, training needs, and more.

Figure 5.1 shows the inputs, tools and techniques, and outputs of the Plan Resource Management process.

Image described by caption and surrounding text.

FIGURE 5.1 Plan Resource Management process

Inputs of Plan Resource Management

Inputs of the Plan Resource Management process you should know are as follows:

  • Project charter
  • Project management plan
  • Project documents
  • Enterprise environmental factors
  • Organizational process assets

Project Charter The project charter includes high-level details about the project, which can provide useful information for establishing how resources will be identified and managed. Information utilized from within the charter can include key stakeholder list, summary milestones, any preapproved or assigned resources, and a high-level description of the project.

Project Management Plan The resource management plan borrows several elements from the project management plan, including but not limited to the following:

  • Quality management plan that aids in identifying resources needed for quality activities
  • Scope baseline, which contains the deliverables that will be produced and then managed
  • The project life cycle and the processes that will be applied to each phase
  • Definition of how work will be performed to meet project objectives
  • A change management plan that documents the monitoring and controlling of changes
  • A configuration management plan that documents how configuration management will be performed
  • The maintenance of project baselines
  • Needs and methods of communicating with stakeholders

Project Documents Resources are needed to perform and complete the activities outlined in the project schedule. During the Plan Resource Management process, these resources are defined in further detail.

In addition to the schedule, other project documents that are useful in planning how resources will be identified and managed include the requirements documentation, risk register, and stakeholder register.

Enterprise Environmental Factors Enterprise environmental factors play a key role in determining resource roles and responsibilities. The following is a list of factors that are used:

  • Organizational factors
  • Existing human resources and marketplace conditions
  • Personnel policies
  • Technical factors
  • Interpersonal factors
  • Location and logistics
  • Political factors
  • Organizational structures
  • Collective bargaining agreements
  • Economic conditions

Organizational Process Assets The following elements of the organizational process assets are used in this process:

  • Organizational processes and standardized role descriptions
  • Safety and security policies
  • Templates and checklists
  • Historical information
  • Escalation procedures for handling issues within the team

Tools and Techniques of Plan Resource Management

The following are tools and techniques of the Plan Resource Management process that you should be familiar with:

  • Expert judgment
  • Data representation
  • Organizational theory
  • Meetings

Expert Judgment Expert judgment helps inform the resource management plan as follows:

  • Listing the preliminary requirements for the required skills
  • Assessing the roles required for the project based on standardized role descriptions
  • Determining number of resources and level of effort needed to meet project objectives
  • Determining reporting relationships
  • Providing guidelines for lead time required for staffing
  • Identifying risks associated with staff acquisition, retention, and release plans
  • Using programs for complying with contracts, with both government and unions

Data Representation Charts are a data representation technique that can be useful in documenting the resource plan. Information is presented in the following types of organization charts and position descriptions:

  • Hierarchical Charts Hierarchical charts, like a WBS, are designed in a top-down format. Two types of hierarchical charts that can be used are OBS and RBS:
    • Organization breakdown structure (OBS), which displays departments, work units, or teams in an organization and their respective work packages
    • Resource breakdown structure (RBS), which breaks down the work of the project according to the types of resources needed
  • Matrix-Based Charts Matrix-based charts are used to show the type of resource and the responsibility that resource has in the project. You can use a couple of types of matrix-based charts:
    • Responsibility assignment matrix (RAM) is displayed as a chart with resource names listed in each column and project phases or WBS elements listed as the rows. Indicators in the intersections show where the resources are needed.
    • A RACI chart is a type of RAM. Table 5.1 shows a sample portion of an RACI chart for a software development team. In this example, the RACI chart shows the roles and expectations of each participant.

    TABLE 5.1 Sample RAM

    Olga Rae Jantira Nirmit
    Design R A C C
    Test I R C A
    Implement C I R A

    R = Responsible, A = Accountable, C = Consult, I = Inform

    The letters in the acronym RACI are the designations shown in Table 5.1

    • R = Responsible for performing the work
    • A = Accountable, the one who is responsible for producing the deliverable or work package and approving or signing off on the work
    • C = Consult, someone who has input to the work or decisions
    • I = Inform, someone who must be informed of the decisions or results

    Text-Oriented Formats Text-oriented formats are used when there is a significant amount of detail to record. These are also called position descriptions or role-responsibility-authority forms. Text-oriented formats typically provide the following information:

    • Role
    • Responsibility
    • Authority of the resource

Organizational Theory Organizational theory refers to all the theories that attempt to explain what makes people, teams, and work units behave.

Meetings Meetings help in the planning of human resources and allow team members to reach consensus on the human resource management plan.

Outputs of Plan Resource Management

There are three outputs of the Plan Resource Management process:

  • Resource management plan
  • Team charter
  • Project documents updates

Resource Management Plan The resource management plan documents how human and physical resources should be defined, obtained or staffed, managed, controlled, and released from the project when their activities are complete. This plan is meant to clearly outline the roles and responsibilities of the project team and to create an effective project organization structure. As a result, guidance is provided on how resources are to be used and managed throughout the project. In some cases, the resource management plan may be broken out into two separate plans—one for managing human resources, sometimes called the team management plan, and another for managing the physical resources.

This output captures the methods for identifying, quantifying, and acquiring resources, as well as the following additional components:

Roles and Responsibilities The roles and responsibilities component includes the list of roles and responsibilities for the project team. It can take the form of the RAM or RACI, or the roles and responsibilities can be recorded in text format. The following key elements should be included in the roles and responsibilities documentation:

  • Role describes which part of the project the individuals or teams are accountable for. This should also include a description of authority levels, responsibilities, and what work is not included as part of the role.
  • Authority describes the amount of authority the resource has to make decisions, dictate direction, and approve the work.
  • Responsibility describes the work required to complete the project activities.
  • Competency describes the skills and ability needed to perform the project activities.

Project Organizational Charts The project organizational charts display project team members and their reporting relationships in the project.

Project Team Resource Management The resource management plan documents how and when resources are introduced to the project and the criteria for releasing them. The plan should be updated throughout the project. The following elements should be considered and included in the plan:

  • Staff acquisition describes how team members are acquired, where they’re located, and the costs for specific skills and expertise.
  • Resource calendars describe the time frames in which the resources will be needed on the project and when the recruitment process should begin.
  • Staff release plan describes how project team members will be released at the end of their assignment, including reassignment procedures.
  • Training needs describe any training plans needed for team members who don’t have the required skills or abilities to perform project tasks.
  • Recognition and rewards describe the systems used to reward and reinforce desired behavior.
  • Compliance details regulations that must be met and any human resource policies the organization has in place that deal with compliance issues.
  • Safety includes safety policies and procedures that are applicable to the project or industry and should be included in the staffing management plan.

Team Charter According to the PMBOK® Guide, the team charter documents the team values, agreements, and operating guidelines. It typically includes the following:

  • Team values
  • Team agreements
  • Communication and meeting guidelines
  • Conflict resolution process

Project Documents Updates The assumption log and risk register might require updates as a result of carrying out this process.

Developing a Communications Management Plan

Communications plays an important role in effectively and efficiently carrying out a project—with successful results! Like other plans, the communications management plan should be as detailed as needed for the project at hand and should be based on the project organization structure and stakeholder requirements. This plan is responsible for managing the flow of project information and is created out of the Plan Communications Management process.

Keep in mind that, according to PMI®, a good project manager spends up to 90 percent of their time communicating. Therefore, the communications management plan should be well thought out and clearly documented.

The Plan Communications Management process involves determining the communication needs of the stakeholders by defining the types of information needed, the format for communicating the information, how often it’s distributed, and who prepares it. All of this is documented in the communications management plan, which is an output of this process. The total number of existing communication channels is also calculated in this process.

Figure 5.2 shows the inputs, tools and techniques, and outputs of the Plan Communications Management process.

Diagram shows plan communication management process with inputs and tools and techniques leading to plan communication management giving outputs (communications management plan, project management plan updates, and project documents updates).

FIGURE 5.2 Plan Communications Management process

Inputs of Plan Communications Management

Know the following inputs of the Plan Communications Management process:

  • Project charter
  • Project management plan
  • Project documents
  • Enterprise environmental factors
  • Organizational process assets

Project Charter The project charter captures the list of key stakeholders, which can be useful in planning out how communications are to occur throughout the project.

Project Management Plan The project management plan will provide direction on how information on the project will be executed, monitored, controlled, and closed. In particular, the resource management plan and stakeholder engagement plan should be referenced.

Project Documents The stakeholder register is a list of all the project stakeholders and contains additional information, including their potential influence on the project and their classifications. This and the requirements documentation are key project documents that should be referenced when developing the communications management plan.

Enterprise Environmental Factors All enterprise environmental factors can be used within the Plan Communications Management process. Special attention should be given to the organizational structure and culture as well as external stakeholder requirements. This information will be key to managing the flow of the project’s information.

Organizational Process Assets All the elements described previously as organizational process assets can be used in this process. Particular consideration should be given to lessons learned and historical information.

Tools and Techniques of Plan Communications Management

The Plan Communications Management process includes the following tools and techniques:

  • Expert judgment
  • Communication requirements analysis
  • Communication technology
  • Communication models
  • Communication methods
  • Interpersonal and team skills
  • Data representation
  • Meetings

Expert Judgment Tapping into experts when developing any of the subsidiary plans is important. In this process, experts can help properly shape how efficient and effective communication should occur for the project; they also participate actively in utilizing other tools and techniques used in this process.

Communication Requirements Analysis Communication requirements analysis involves analyzing and determining the communication needs of the project stakeholders. According to the PMBOK® Guide, there are several sources of information you can examine to help determine these needs:

  • Company and departmental organizational charts
  • Stakeholder responsibility relationships
  • Other departments and business units involved in the project
  • The number of resources involved in the project and where they’re located in relation to project activities
  • Internal needs that the organization may need to know about the project
  • External needs that organizations such as the media, government, or industry groups might have that require communication updates
  • Stakeholder information (documented in the stakeholder register and stakeholder management strategy outputs of Identify Stakeholders)

The preceding list goes through analysis to make certain that information that is valuable to the stakeholders is being supplied. It is important to know the number of communication channels, also known as lines of communication, that exist. Figure 5.3 shows an example of a network model with six stakeholders included.

Diagram shows network communication model with six nodes linked together in series with lines of communication between participants.

FIGURE 5.3 Network communication model

The nodes are the participants, and the lines show the connection between them all. The formula for calculating the lines of communication is as follows (where n represents total participants):

numbered Display Equation

Let’s consider six participants. When you plug the total participants into the formula, the result is a total of 15 communication channels, as noted in the following example:

numbered Display Equation

Communication Technology Communication technology examines the methods (or technology) used to communicate the information to, from, and among the stakeholders. This tool and technique examines the technology elements that might affect project communications.

The following are examples of methods used when communicating:

  • Written
  • Spoken
  • Email
  • Formal status reports
  • Meetings
  • Online databases
  • Online schedules

Communication Models Communication models depict how information is transmitted from the sender and how it’s received by the receiver. According to the PMBOK® Guide, the key components of a communication model are as follows:

  • Encode Encoding the message means to put information or thoughts into a language that the receiver will understand.
  • Message and Feedback Message The result or output of the encoding.
  • Medium The method used to communicate, such as written, oral, or email.
  • Noise Anything that keeps the message from being either transmitted or understood.
  • Decode The receiver translates the information that was sent by the sender.

The sender is responsible for encoding the message, selecting the medium, and decoding the feedback message. The receiver is responsible for decoding the original message from the sender and encoding and sending the feedback message. Figure 5.4 shows this dynamic through the basic communication model.

Image described by caption and surrounding text.

FIGURE 5.4 Communication model

Communication Methods Communication methods refer to how the project information is shared among the stakeholders. According to the PMBOK® Guide, there are three classifications of communication methods:

  • Interactive Communication Interactive communication involves multidirectional communication where two or more parties must exchange thoughts or ideas. This method includes videoconferencing, phone or conference calls, and meetings.
  • Push Communications Push communications refers to sending information to intended receivers. It includes methods such as letters, memos, reports, emails, voicemails, and so on. This method ensures that the communication was sent but is not concerned with whether it was actually received or understood by the intended receivers.
  • Pull Communications The likely recipients of the information access the information themselves using methods such as websites, e-learning sites, knowledge repositories, shared network drives, and so on.

Interpersonal and Team Skills When planning communications, there are various interpersonal and team skills that can be used:

  • Communication styles assessment, where the communication style of various stakeholders is considered
  • Political awareness, where the project environment is considered and planned against
  • Cultural awareness, where stakeholder cultures, as well as the organizational culture, are considered

Data Representation Stakeholder engagement assessment matrices can be useful in identifying gaps in the expected stakeholder engagement. Identifying these gaps early and iteratively can help fill or reduce them.

Meetings Meetings are used by the project manager to facilitate conversations with the project team on how project communications should occur throughout the life of the project. According to the PMBOK® Guide, various types of meetings can be used, many of which help resolve issues and facilitate decisions.

Outputs of Plan Communications Management

The following three outputs result from carrying out the Plan Communications Management process:

  • Communications management plan
  • Project management plan updates
  • Project documents updates

Communications Management Plan The communications management plan documents the following:

  • Types of information needs the stakeholders have
  • When the information should be distributed
  • How the information will be delivered

According to the PMBOK® Guide, the communications management plan typically describes the following elements:

  • The communication requirements of each stakeholder or stakeholder group
  • Purpose for communication
  • The information to be communicated
  • Frequency of communications, including time frames for distribution
  • Name of the person responsible for communicating information, the individual that authorizes the communication, and recipients
  • Individuals assigned to communications-related activities
  • Format of the communication, communication flow charts, and method of transmission
  • Any communication constraint, including those resulting from laws, technology, or policies
  • Method for updating the communications management plan
  • Glossary of common terms

The information that will be shared with stakeholders and the distribution methods are based on the following items:

  • Needs of the stakeholders
  • Project complexity
  • Organizational policies

Project Management Plan Updates The communications management plan may trigger updates to any other plan that exists.

Project Documents Updates The following updates may be required as a result of performing this process:

  • Project schedule
  • Stakeholder register


Developing a Procurement Management Plan

In many cases, some resources will need to be obtained externally (meaning outside of the project’s organization). When this is the case, a procurement management plan will be needed. This plan is created out of the Plan Procurement Management process, which is also responsible for producing other key procurement documents.

The procurement management plan should be based on the project’s scope and schedule and is responsible for guiding the procurement-related processes and ensuring that the required project resources will be available when and as needed.

Plan Procurement Management is a process of identifying what goods or services will be purchased from outside the organization. This process addresses the make-or-buy decision and when acquired goods or services will be needed. By the end of this process, a procurement management plan will have been created, make-or-buy decisions will have been made, and a contract statement of work will have been drafted.

Figure 5.5 shows the inputs, tools and techniques, and outputs of the Plan Procurement Management process.

Diagram shows plan procurement management process where organizational process assets and meetings leads to plan procurement management giving outputs (organizational process, change requests, et cetera).

FIGURE 5.5 Plan Procurement Management process

Inputs of Plan Procurement Management

You should be familiar with these inputs to the Plan Procurement Management process:

  • Project charter
  • Business documents
  • Project management plan
  • Project documents
  • Enterprise environmental factors
  • Organizational process assets

Project Charter The project charter provides a high-level summary of the project as well as other information that may aid the procurement planning activities, such as a summary milestone and any preapproved financial resources.

Business Documents Business documents referenced as part of this process include the business case and benefits management plan. The business case helps ensure alignment of the procurement strategy, while the benefits management plan may end up driving some of the procurement details, such as procurement dates and contract language.

Project Management Plan The Plan Procurement Management process uses several components of the project management plan:

  • Scope management plan, which documents how the scope performed by contractors will be managed.
  • Quality management plan, which may reveal industry standards and codes impacting the project that have already been documented.
  • Resource management plan, which notes how purchased or leased resources will be managed.
  • Scope baseline, which contains the project scope statement, WBS, and WBS dictionary. These may be useful in drafting the statement of work and terms of reference.

Project Documents Multiple documents are used to plan procurements, including the following:

  • Milestone List The milestone list is key in determining when deliverables are due by sellers.
  • Project Team Assignments Team assignments also capture the skills and capabilities of assigned team members as well as their availability to participate in the procurement process.
  • Requirements Documentation The requirements documentation established the details of the project requirements. For a more detailed description, see “Outputs of Collect Requirements” in Chapter 3.
  • Requirements Traceability Matrix The requirements traceability matrix links product requirements to the deliverables that satisfy them.
  • Resource Requirements The availability of the assigned resources affects the procurement process and will aid in make-or-buy decisions.
  • Risk Register The risk register guides the project team in determining the types of services or goods needed for risk management. It also identifies which procurement decisions are driven as a result of a risk response, such as acquiring insurance or other services to transfer liability to a third party.
  • Stakeholder Register The stakeholder register shows details on the participants in the project and their interest in the outcomes.

Enterprise Environmental Factors Marketplace conditions are the key element of enterprise environmental factors used within this process. Other factors include products, services, and results available in the marketplace; unique local requirements; any contract management systems or financial accounting and contract payment systems that exist within the organization, as well as legal advice; and industry-specific typical terms and conditions.

Organizational Process Assets The organization’s guidelines, policies, and procedures (including any procurement policies and guidelines) are the elements of the organizational process assets used in this process. Legal contractual relationships are another component to organizational process assets for the Plan Procurement Management process and include any existing preapproved seller lists. Contracts will generally fall into three general categories: fixed-price, cost reimbursable, and time and materials.

A contract is a compulsory agreement between two or more parties and is used to acquire products or services from outside the organization. Contracts are enforceable by law and require an offer and an acceptance, with money typically exchanged for goods or services. As reflected in Figure 5.6 , there are different types of contracts for different purposes.

Image described by caption and surrounding text.

FIGURE 5.6 Contract types

The PMBOK® Guide divides contracts into three categories:

Fixed-Price or Lump-Sum Contracts Fixed-price contracts (also referred to as lump-sum contracts) either can set a specific, firm price for the goods or services rendered (known as a firm fixed-price contract) or can include incentives for meeting or exceeding certain contract deliverables. There are three types of fixed-price contracts:

  • In a firm fixed-price (FFP) contract, the buyer and seller agree on a well-defined deliverable for a set price. In this kind of contract, the biggest risk is borne by the seller. The seller assumes the risks of increasing costs, nonperformance, or other problems.
  • Fixed-price incentive fee (FPIF) contracts are another type of fixed-price contract. The difference is that the contract includes an incentive—or bonus—for early completion or for some other agreed-upon performance criterion that meets or exceeds contract specifications. Some of the risk is borne by the buyer as opposed to the firm fixed-price contract, where most of the risk is borne by the seller.
  • A fixed-price with economic price adjustment (FP-EPA) contract allows for adjustments due to changes in economic conditions, like cost increases or decreases, inflation, and so on. These contracts are typically used when the project spans many years. This type of contract protects both the buyer and the seller from economic conditions that are outside their control.

Cost-Reimbursable or Cost Plus Contracts With cost-reimbursable contracts, the allowable costs associated with producing the goods or services are charged to the buyer. All the costs the seller takes on during the project are charged back to the buyer; thus, the seller is reimbursed. Cost-reimbursable contracts carry the highest risk for the buyer because the total costs are uncertain and are used most often when the project scope contains a lot of uncertainty or for projects that have large investments early in the project life. The following list includes three types of cost-reimbursable contracts:

  • Cost plus fixed fee (CPFF) contracts charge back all allowable project costs to the seller and include a fixed fee upon completion of the contract. The fee is always firm in this kind of contract, but the costs are variable. The seller doesn’t necessarily have a lot of motivation to control costs with this type of contract.
  • Cost plus incentive fee (CPIF) is the type of contract in which the buyer reimburses the seller for the seller’s allowable costs and includes an incentive for meeting or exceeding the performance criteria laid out in the contract. A possibility of shared savings between the seller and buyer exists if performance criteria are exceeded.
  • Cost plus award fee (CPAF) is the riskiest of the cost plus contracts for the seller. In a CPAF contract, the seller will recoup all the costs expended during the project, but the award fee portion is subject to the sole discretion of the buyer.

Time and Material (T&M) Contracts T&M contracts are a cross between fixed-price and cost-reimbursable contracts. The full amount of the material costs is not known at the time the contract is awarded. T&M contracts are most often used when human resources with specific skills are needed and when the scope of work needed for the project can be quickly defined. Time and material contracts include the following characteristics:

  • This type of contract resembles a cost-reimbursable contract because the costs will continue to grow during the contract’s life and are reimbursable to the contractor. The buyer bears the biggest risk in this type of contract.
  • This type of contract resembles fixed-price contracts when unit rates are used. Unit rates might be used to preset the rates of certain elements or portions of the project.

Tools and Techniques of Plan Procurement Management

Know these five tools and techniques of the Plan Procurement Management process:

  • Expert judgment
  • Data gathering
  • Data analysis
  • Source selection analysis
  • Meetings

Expert Judgment Expert judgment can be used within the Plan Procurement Management process to aid in procurement and purchasing activities, to determine what contract type or documents are needed, and to provide information on regulation or compliance items that impact procurements.

Data Gathering With market research, an examination is conducted of industry- and vendor-specific capabilities. This effort can be conducted with information obtained at industry conferences, by evaluating online reviews, and by using a variety of sources to identify market capabilities.

Data Analysis Make-or-buy analysis is concerned with whether it is more cost-effective to buy or lease the products and services or more cost-effective for the organization to produce the goods and services needed for the project. Costs should include both direct costs and indirect costs. Other considerations in make-or-buy analysis are as follows:

  • Capacity issues
  • Skills
  • Availability
  • Trade secrets

Source Selection Analysis According to the PMBOK® Guide, the competing demands and priorities of the project should first be evaluated before selection criteria or methods can be determined. Typical selection methods are as follows:

  • Least cost
  • Qualifications only
  • Quality-based / technical proposal score
  • Quality and cost-based
  • Sole source
  • Fixed budget

Meetings As a complement to the effort of market research, meetings with potential bidders may be conducted to help augment the interchange of information. This approach can be mutually beneficial to both the purchaser and the supplier.

Outputs of Plan Procurement Management

Know the following outputs of the Plan Procurement Management process:

  • Procurement management plan
  • Procurement strategy
  • Bid documents
  • Procurement statement of work
  • Source selection criteria
  • Make-or-buy decisions
  • Independent cost estimates
  • Change requests
  • Project documents updates
  • Organizational process assets updates

Procurement Management Plan The procurement management plan details how the procurement process will be managed. According to the PMBOK® Guide, it includes the following information:

  • Types of contracts to use
  • Timetable of procurement activities
  • Authority of the project team
  • How the procurement process will be integrated with other project processes
  • Where to find standard procurement documents (provided your organization uses standard documents)
  • How many vendors or contractors are involved and how they’ll be managed
  • How the procurement process will be coordinated with other project processes, such as performance reporting and scheduling
  • How the constraints and assumptions might be impacted by purchasing
  • How multiple vendors or contractors will be managed
  • Coordination of purchasing lead times with the development of the project schedule
  • Schedule dates that are determined in each contract
  • Identification of prequalified sellers (if known)
  • Risk management issues
  • Procurement metrics for managing contracts and for evaluating sellers
  • Directions to sellers regarding the development and maintenance of the WBS
  • Setting the form and format of statements of work
  • Selection of prequalified sellers to be used, if there are any
  • Identification of procurement metrics to be used to manage contracts and evaluate sellers
  • Prequalified sellers

As with other plans, the procurement management plan can be highly detailed or broadly stated and can be formal or informal based on the needs of the project.

Procurement Strategy After procurement decisions are made, a procurement strategy document is pulled together and documents the following:

  • Delivery methods
  • Contract payment types
  • Procurement phases

Bid Documents Procurement documents are used to solicit vendors and suppliers to bid on procurement needs. These documents are prepared by the buyer to ensure as accurate and complete a response as possible from all potential bidders. Examples of procurement documents include the following:

  • Request for proposal (RFP)
  • Request for information (RFI)
  • Invitation for bid (IFB)
  • Request for quotation (RFQ)

Procurement documents typically include the following information:

  • Clear description of the work requested
  • Contract SOW
  • Explanation of how sellers should format and submit their responses
  • Any special provisions or contractual needs

The following words are used during the procurement process:

  • When the decision will be based primarily on price, the words bid and quotation are used, as in IFB or RFQ.
  • When considerations other than price (such as technology or specific approaches to the project) are the deciding factor, the word proposal is used, as in RFP.

Procurement documents are posted or advertised according to the buyer’s organizational policies. This might include ads in newspapers and magazines or ads/posts on the Internet.

Procurement Statement of Work A procurement statement of work (SOW) contains the details of the procurement item in clear, concise terms. It includes the following elements:

  • Project objectives
  • Description of the work of the project and any post-project operational support needed
  • Concise specifications of the product or services required
  • Project schedule, time period of services, and work location

The procurement SOW is prepared by the buyer and is developed from the project scope statement and the WBS and WBS dictionary. The seller uses the SOW to determine whether they are able to produce the goods or services as specified. It will undergo progressive elaboration as the procurement processes occur.

Source Selection Criteria The term source selection criteria refers to the method the buyer’s organization will use to choose a vendor from among the proposals received. The criteria might be subjective or objective.

Here are some examples of criteria used:

  • Purchase price
  • Scoring models
  • Rating models

The following list includes some of the criteria for evaluating proposals and bids:

  • Comprehension of the needs of the project as documented in the contract SOW
  • Cost
  • Technical ability of the vendor and their proposed team
  • Technical approach
  • Risk
  • Experience on projects of similar size and scope, including references
  • Project management approach
  • Management approach
  • Financial stability and capacity
  • Production capacity
  • Reputation, references, and past performance
  • Intellectual and proprietary rights

Make-or-Buy Decisions The make-or-buy decision is a document that outlines the decisions made during the process regarding which goods and/or services will be produced by the organization and which will be purchased. This can include any number of items:

  • Services
  • Products
  • Insurance policies
  • Performance
  • Performance bonds

Independent Cost Estimates In some cases, a project team may elect to have an independent cost estimate prepared for the work being procured. This may include having the internal project team develop these estimates or having an external professional estimator produce the estimates. Independent estimates can serve as a benchmark or proposed response to seller bids.

Change Requests As a result of going through this process, changes to the project management plan may be required due to vendor capability, availability, cost, quality considerations, and so on. Change requests must be processed through the Perform Integrated Change Control process.

Project Documents Updates According to the PMBOK® Guide, the list of project documents that may be updated includes but is not limited to the following items:

  • Lessons learned register
  • Milestone list
  • Requirements documentation
  • Requirements traceability matrix
  • Risk register
  • Stakeholder register

Organizational Process Assets Updates Organizational process assets may need to be updated as a result of carrying out this process. This may include archiving information on qualified sellers.


Developing a Change Management Plan

Managing changes is important to successfully managing a project overall. Scope creep is often the result of a poorly documented scope and poorly documented change control procedures. To ensure that changes are managed appropriately, a change management plan should be created. It should be noted that there isn’t a formal documented process that creates this plan.

The change management plan should document the following:

  • How changes will be monitored and controlled
  • Detailed processes for managing change to a project
  • How change requests are to be documented and managed
  • Process for approving changes
  • How to document and manage the final recommendation for the change requests

Once created and approved, the change management plan becomes part of the overarching project management plan.

Developing a Risk Management Plan

The first official step in performing risk management is creating a risk management plan. This is done by carrying out the Plan Risk Management process, which is the first official process of the Project Risk Management Knowledge Area. Five of the seven processes that fall in this Knowledge Area belong to the Planning process group.

The risk management plan is created to manage uncertainty throughout the project life cycle, which allows the project management team to control the outcome of the project to the extent possible. Like other plans, it plays an important role in guiding the rest of the processes that fall within its respective Knowledge Area. Without the risk management plan, a project management team cannot effectively identify and manage risks because this plan ensures that everyone is on the same page when it comes to assessing, prioritizing, responding to, and managing risks.

Aside from the Plan Risk Management process, the following risk-related processes fall within the Planning process group: Identify Risks, Perform Qualitative Risk Analysis, Perform Quantitative Risk Analysis, and Plan Risk Responses. Remember that there are two other processes within this Knowledge Area: Implement Risk Responses, which is part of the Executing process group, and Monitor Risks, which is a part of the Monitoring and Controlling process group.

Plan Risk Management

The Plan Risk Management process determines how the project team will conduct risk management activities. The risk management plan, which will be developed during this process, guides the project team in carrying out the risk management processes and also ensures that the appropriate amount of resources and time is dedicated to risk management. By the end of this process, the project team will have developed a common understanding for evaluating risks throughout the remainder of the project.

Figure 5.7 shows the inputs, tools and techniques, and outputs of the Plan Risk Management process.

Image described by caption and surrounding text.

FIGURE 5.7 Plan Risk Management process

Inputs of Plan Risk Management

You should know the following inputs of the Plan Risk Management process:

  • Project charter
  • Project management plan
  • Project documents
  • Enterprise environmental factors
  • Organizational process assets

Project Charter From the project charter, various inputs can be gleaned, including risks, project descriptions, and requirements, all at a high level.

Project Management Plan For the purposes of risk management planning, it is necessary to consider all other approved subsidiary management plans and baselines. The project management plan sets the baseline for all risk-affected areas, especially scope, schedule, and cost.

Project Documents The stakeholder register provides details related to the project stakeholder, including an overview of their roles.

Enterprise Environmental Factors One of the key elements of the enterprise environmental factors to consider in this process is the risk tolerance levels of the organization and the stakeholders. This is important for evaluating and ranking risk.

Organizational Process Assets Organizational process assets include policies and guidelines that might already exist in the organization. The following should be considered when developing the risk management plan:

  • Risk categories
  • Risk statement formats
  • Risk management templates tailored to the needs of the project
  • Defined roles and responsibilities
  • Authority levels of the stakeholders and project manager

Tools and Techniques of Plan Risk Management

The Plan Risk Management process has three tools and techniques: expert judgment, data analysis, and meetings.

  • Expert judgment
  • Data analysis
  • Meetings

Expert Judgment In the creation of a comprehensive risk management plan, judgment and expertise should be considered from those with specialized training or knowledge in the subject area, including but not limited to the following:

  • Senior management
  • Other project managers who have performed similar work efforts
  • Subject matter experts in the field
  • Project stakeholders
  • Industry groups and consultants
  • Technical and professional associations

Data Analysis To create and communicate the overall risk management context of the project, analytical techniques are used. The risk management context combines the strategic risk exposure of a given project with the stakeholders’ attitude on risk. These assessments will inform the project team on the appropriate resource allocation and allow the team to focus on risk management activities.

Meetings During these meetings, the fundamental plans for performing risk management activities will be discussed and determined and then documented in the risk management plan.

Outputs of Plan Risk Management

The output of the Plan Risk Management process is the risk management plan. The risk management plan describes how you will define, respond to, and monitor risks throughout the project. It also details how risk management processes will be implemented and managed. According to the PMBOK® Guide, the risk management plan should include the following elements:

Risk Strategy The risk strategy captures the general approach to how risks will be managed in the project.

Methodology Methodology is a description of how you’ll perform risk management, including elements such as methods and tools, and how you’ll determine where you might find risk data that you can use in the later processes.

Roles and Responsibilities The risk management plan should include descriptions of the people who are responsible for managing the identified risks and their responses and the people responsible for each type of activity identified in the plan.

Funding The budget for risk management activities is included in the plan as well. In this section, you’ll assign resources and estimate the costs of risk management activities and methods. These costs are then included in the cost performance baseline.

Timing Timing refers to how often and at what point in the project life cycle risk management processes will occur. You may also include protocols designed to establish contingency schedule reserves.

Stakeholder Risk Appetite As the project proceeds through the risk management processes, risk appetite will change. This is documented in the risk management plan. Risk management should be carried out according to stakeholder risk appetite.

Reporting Formats In the reporting formats section, you’ll describe the content and format of the risk register. You should also detail how risk management information will be maintained, updated, analyzed, and reported to project participants.

Tracking This includes a description of how you’ll document the history of the risk activities for the current project and how the risk processes will be audited.

Risk Categories Risk categories are a way of systematically identifying risks and providing a foundation for understanding. Risk categories should be identified during this process and documented in the risk management plan.

There are multiple ways of displaying risk categories, such as through a simple list or by constructing a risk breakdown structure (RBS), which lists the categories and subcategories. Figure 5.8 shows a sample of an RBS.

Diagram shows project name leading to technical, project management, organizational, and external which in turn leads to unproven technology, schedule planning, project schedules, weather, et cetera.

FIGURE 5.8 Risk breakdown structure

The following list includes some examples of the categories you might consider during this process:

  • Technical/quality/performance risks
  • Project management risks
  • Organizational risks
  • External risks

Definitions of Risk Probability and Impacts The definitions for probability and impact are documented in the risk management plan as they relate to potential positive or negative risk events and their impacts on project objectives.

  • Probability describes the potential for the risk event occurring.
  • Impact describes the effects or consequences the project will experience if the risk event occurs.

Probability and Impact Matrix A probability and impact matrix prioritizes the combination of probability and impact scores and helps determine which risks need detailed risk response plans.

Identify Risks

The Identify Risks process describes all the risks that might impact the project and documents their characteristics in the risk register. Identify Risks is an iterative process that continually builds on itself as additional risks emerge. The risk register is created at the end of this process. The risk register documents all risk information, proposed responses, responses implemented, and status.

Figure 5.9 shows the inputs, tools and techniques, and outputs of the Identify Risks process.

Diagram shows risks process identification with documents, agreements, data gathering, prompt lists, leading to risk identification giving outputs as risk register, report, and documents.

FIGURE 5.9 Identify Risks process

Inputs of Identify Risks

You should be familiar with the following inputs of the Identify Risks process:

  • Project management plan
  • Project documents
  • Agreements
  • Procurement documentation
  • Enterprise environmental factors
  • Organizational process assets

Project Management Plan Several subsidiary plans and baselines are used from within the project management plan to identify risk, including the following:

  • Risk Management Plan In this process, the roles and responsibilities section of the risk management plan will be used, as well as the budget and schedule set aside for risk activities.
  • Cost Management Plan, Schedule Management Plan, Quality Management Plan, Resource Management Plan, Requirements Management Plan An understanding of these subsidiary plans is necessary for identifying risks. A thorough review of these documents should be carried out to identify risks associated with them.
  • Baselines The project scope statement, part of the scope baseline, contains a list of project assumptions, which are issues believed to be true. The assumptions about delivery times are reexamined, and it is determined if they are still valid.

Project Documents Multiple project documents will be used when carrying out the Identify Risks process. Below are examples:

  • Assumption Log Noted assumptions and constraints from within the log may generate risks associated with them.
  • Cost Estimates Activity cost estimates may provide insight into the identification of risks if the estimates are found to be insufficient to complete the activity.
  • Duration Estimates Activity duration estimates may reveal existing risks in relation to the time that has been allotted for completing an activity or the project as a whole.
  • Issue Log As with the assumption log, issues captured within the issue log may generate risk.
  • Lessons Learned Register Since the identification of risks is an iterative process, the lessons learned register should be reviewed regularly to guide future risk identification activities.
  • Requirements Documentation and Resource Requirements The project team should inspect the list of requirements and resources for any associated risks.
  • Stakeholder Register Understanding stakeholder influence is essential to risk management. The stakeholder register provides a list of stakeholders and may list levels of influence.

Agreements If the project includes procurement activities, the agreements should be inspected for any risks associated with the contract type chosen, acceptance criteria used within the agreement, or milestone dates to which vendors will be held accountable.

Procurement Documentation When a project requires the use of external procurement of resources, procurement documents are an influential input to the Identify Risks process.

Enterprise Environmental Factors The enterprise environmental factors include aspects from outside the project that might help determine or influence project outcomes. Industry information or academic research that might exist for your application areas regarding risk information is especially relevant.

Organizational Process Assets Historical information, such as from previous project experiences and project team knowledge, is used from within the organizational process assets. Risk register templates can also be used from past similar projects.

Tools and Techniques of Identify Risks

The Identify Risks process includes the following tools and techniques:

  • Expert judgment
  • Data gathering
  • Data analysis
  • Interpersonal and team skills
  • Prompt lists
  • Meetings

Expert Judgment For risk identification purposes, experts can include individuals with the following experience:

  • Experience with similar projects
  • Experience in the business area for which the project was undertaken
  • Industry-specific experience

The bias of experts regarding the project or potential risk events should be considered when using this technique.

Data Gathering Data-gathering techniques referenced by the PMBOK® Guide for risk identification includes brainstorming, checklists, and interviews.

  • Brainstorming Simply bringing team members together for brainstorming sessions is a creative way to help the team initially identify risks. Many times, brainstorming can yield a comprehensive list of risks and allow the team to categorize them.
  • Checklists Checklists used during the Identify Risks process are usually developed based on historical information and previous project team experience. The lowest level of the RBS or a list of risks from previous similar projects may be used. The WBS can also be used as a checklist.
  • Interviews Interviews can capture risks from a broad list of participants. This aids in capturing risks in a way that can promote confidentiality, trust, and unbiased feedback.

Data Analysis Data analysis techniques used to identify risks include root cause analysis, assumption and constraint analysis, SWOT analysis, and document analysis.

  • Root Cause Analysis Two types of diagramming techniques are used in the Identify Risks process that aid in root cause analysis:
  • Cause-and-Effect Cause-and-effect diagrams show the relationship between the effects of problems and their causes. This diagram depicts every potential cause and subcause of a problem and the effect that each proposed solution will have on the problem. This diagram is also called a fishbone diagram or Ishikawa diagram after its developer, Kaoru Ishikawa. Figure 5.10 shows a sample cause-and-effect diagram.
    Diagram shows cause-and-effect having material, process, project staff, and hardware as cause and problem or defect statement as effect with several steps.

    FIGURE 5.10 Cause-and-effect diagram

  • System or Process Flowcharts The system or process flowcharts show the logical steps needed to accomplish an objective, how the elements of a system relate to each other, and which actions cause which responses. Figure 5.11 shows a flowchart to help determine whether risk response plans should be developed for the risk.
    Flowchart shows risk trigger leading to plan into action or not if yes then plans reexamined and if no documenting results.

    FIGURE 5.11 Flowchart diagram

  • Assumption and Constraint Analysis Assumptions analysis is a matter of validating the assumptions identified and documented during the course of the project planning processes. Assumptions should be accurate, complete, and consistent. All assumptions are tested against two factors:
    • Strength of the assumption or the validity of the assumption
    • Consequences that might impact the project if the assumption turns out to be false
  • SWOT Analysis Strengths, weaknesses, opportunities, and threats (SWOT) analysis is a technique that examines the project from each of these viewpoints and from the viewpoint of the project itself. SWOT should also be used to examine project management processes, resources, the organization, and so on to identify risks to the project, including risks that are generated internally. SWOT analysis uncovers the following:
    • Negative risks, which are typically associated with the organization’s weaknesses
    • Positive risks, which are typically associated with the organization’s strengths

    SWOT analysis also determines whether any of the organization’s strengths can be used to overcome its weaknesses.

  • Document Analysis Documentation reviews involve reviewing project plans, assumptions, and historical information from previous projects from a total project perspective as well as from an individual deliverables and activities level. This review helps the project team identify risks associated with the project objectives.

Interpersonal and Team Skills With many of the techniques listed within this process, facilitation will be required. Facilitation is a form of interpersonal and team skills and may be carried out by a professional facilitator, the project manager, or other skilled team member.

Prompt Lists According to the PMBOK® Guide, a prompt list is a predetermined list of risk categories that may identify project risks or overall sources of project risk.

Meetings Meetings or workshops are a common way of bringing the team together in combination with other techniques to identify risks.

Outputs of Identify Risks

There are three outputs of the Identify Risks process:

  • Risk register
  • Risk report
  • Project documents updates

Risk Register The risk register contains the following elements:

  • List of identified risks
  • List of potential responses
  • Potential risk owners
  • List of Identified Risks Risks are all the potential events and their subsequent consequences that could occur as identified during this process. A list provides a means of tracking risks and their occurrence and responses. The list should contain the following items:
    • All potential risks
    • Tracking number
    • Potential cause or event
    • Potential impact
    • Responses implemented
  • List of Potential Responses While you’re identifying risks, you may identify a potential response at the same time. If this is the case, these potential responses are documented.

    Table 5.2 shows a sample template for a risk register.

    TABLE 5.2 Risk register template

    ID Risk Trigger Event Cause Impact Owner Response Plan
    1 Infrastructure team is not available when needed. Predecessor tasks are/were not completed on time. Operating system upgrade is/was delayed. Equipment was not delivered on time. Schedule delay Brown Compress the schedule by beginning tasks in the next milestone while working on operating system upgrade.
  • Potential Risk Owners Along with risks identified and potential responses, potential risk owners may also be documented while carrying out this process. Risk owners will not be confirmed until the Perform Qualitative Risk Analysis process is carried out.

Risk Report The focus of the risk report is at the project level. The risk report documents information on the sources of overall project risk and typically includes the following:

  • Sources of overall risk
  • Summary of risks identified, including the number of threats, opportunities, and risks across the risk categories

Project Documents Updates As risks are identified, the following project documents might require an update:

  • Assumption log
  • Issue log
  • Lessons learned register

Perform Qualitative Risk Analysis

The Perform Qualitative Risk Analysis process involves determining what impact the identified risks will have on the project objectives and the probability that they will occur. It also ranks the risks in priority order according to their effect on the project objectives. The purpose of this process is to determine risk event probability and risk impact. By the end of this process, updates will have been made to the risk register.

Figure 5.12 shows the inputs, tools and techniques, and outputs of the Perform Qualitative Risk Analysis process.

Image described by caption and surrounding text.

FIGURE 5.12 Perform Qualitative Risk Analysis process

Inputs of Perform Qualitative Risk Analysis

Know the following inputs of the Perform Qualitative Risk Analysis process and how they apply:

  • Project management plan
  • Project documents
  • Enterprise environmental factors
  • Organizational process assets

Project Management Plan The project management plan contains the risk management plan, which is the primary subsidiary plan referenced when performing qualitative risk analysis. The risk management plan documents the following, which are used when prioritizing risks:

  • Roles and responsibilities of risk team members
  • Budget and schedule factors for risk activities
  • Stakeholder risk tolerances
  • Definitions for probability and impact
  • Probability and impact matrix

Project Documents There are three key documents used to perform this process: the assumption log, risk register, and stakeholder register.

  • Assumption Log Assumptions captured may influence the priority of individual project risks. Assumptions and constraints should be monitored throughout the project.
  • Risk Register The list of risks from within the risk register is used in this process.
  • Stakeholder Register The list of stakeholders is helpful for reference as decisions are made regarding risk owners.

Enterprise Environmental Factors As with other processes that we have examined earlier, enterprise environmental factors provide insight and context to the risk assessment, including studying industry projects of a similar nature and exploring risk databases that may be available from industry or proprietary sources.

Organizational Process Assets Historical information, lessons learned, and risk databases from past projects are used from within the organizational process assets as a guide for prioritizing the risks for this project.

Tools and Techniques of Perform Qualitative Risk Analysis

The following tools and techniques are used in the Perform Qualitative Risk Analysis process:

  • Expert judgment
  • Data gathering
  • Data analysis
  • Interpersonal and team skills
  • Risk categorization
  • Data representation
  • Meetings

Expert Judgment Expert judgment is used to determine the probability, impact, and other information derived to date from this process. Interviews and facilitated workshops are two techniques used in conjunction with expert judgment to perform this process.

Data Gathering Interviews, a data-gathering technique, can be used when assessing the probability and impact of individual project risks. As noted previously, interviews promote a sense of confidentiality, trust, and unbiased feedback.

Data Analysis There are three data analysis techniques used in this process: risk data quality assessment, risk probability and impact assessment, and the assessment of other risk parameters.

  • Risk Data Quality Assessment The risk data quality assessment involves determining the usefulness of the data gathered to evaluate risk. The data must be unbiased and accurate. Elements such as the following are used when performing this tool and technique:
    • Quality of the data used
    • Availability of data regarding the risks
    • How well the risk is understood
    • Reliability and integrity of the data
    • Accuracy of the data
  • Risk Probability and Impact Assessment This tool and technique assesses the probability that the risk events identified will occur and determines the effect (or impact) they have on the project objectives:
    • Probability: Probability is the likelihood that an event will occur.
    • Impact: Impact is the amount of pain or gain that the risk event poses to the project. The following are two types of scales used to assign a value to risk:
    • The risk impact scale, also known as an ordinal scale, can be a relative scale that assigns values such as high, medium, or low.
    • Cardinal scale values are actual numeric values assigned to the risk impact. Cardinal scales are expressed as values from 0.0 to 1.0 and can be stated in equal (linear) or unequal (nonlinear) increments.

    Table 5.3 shows a typical risk impact scale for cost, time, and quality objectives based on a high-high to low-low scale.

    TABLE 5.3 Risk impact scale

    Objectives Low-Low Low Medium High High-High
    0.05 0.20 0.40 0.60 0.80
    Cost No significant impact Less than 6% increase 7%–12% increase 13%–18% increase More than 18% increase
    Time No significant impact Less than 6% increase 7%–12% increase 13%–18% increase More than 18% increase
    Quality No significant impact Few components impacted Significant impact requiring customer approval to proceed Unacceptable quality Product not usable

    The idea behind both probability and impact values is to develop predefined measurements that describe which value to place on a risk event. Assumptions used to arrive at these determinations should also be documented in this process.

  • Assessment of Other Risk Parameters Risk urgency assessment determines how soon the potential risks might occur and quickly determines responses for those risks that could occur in the near term. The following play a role in determining how quickly a risk response is needed:
    • Risk triggers
    • Time to develop and implement a response
    • Overall risk rating

    In addition to urgency, the following are other characteristics that may be assessed, as noted by the PMBOK® Guide:

    • Proximity
    • Dormancy
    • Manageability
    • Controllability
    • Detectability
    • Connectivity
    • Strategy impact
    • Propinquity
  • Probability and Impact Matrix The outcome of a probability and impact matrix is an overall risk rating for each of the project’s identified risks. The following are characteristics of the probability and impact matrix:
    • The combination of probability and impact results in a classification usually expressed as high, medium, or low.
    • Values assigned to the risks determine how the Plan Risk Responses process is carried out later on during the risk-planning processes.
    • Values for the probability and impact matrix (and the probability and impact scales) are determined prior to the start of this process.
    • The impact and probability matrix is documented in the risk management plan.
  • Hierarchical Charts In addition to showing risks based on a probability and impact matrix, hierarchical charts can be used. An example of this type of chart is a bubble chart, which can reflect multiple dimensions of data.

Interpersonal and Team Skills Facilitation is a form of interpersonal and team skills used to carry out this process. This may include a trained facilitator, a skilled team member, or the project or risk manager.

Risk Categorization Risk categorization is used to determine the effects risk has on the project. This involves grouping risks in multiple ways to determine what areas within the project are the most exposed. Examples of how risks can be categorized include areas affected, RBS components, WBS components, and risk categories.

Data Representation Data representation techniques that you should be familiar with include the probability and impact matrix and hierarchical charts.

Meetings Risk workshops are often held to bring team members together to carry out several of the techniques discussed within this process.

Outputs of Perform Qualitative Risk Analysis

The output of the Perform Qualitative Risk Analysis process delivers project documents updates, including updates to the risk register, issue log, risk report, and assumption log.

According to the PMBOK® Guide, the risk register will receive the following updates, which are added as new entries:

  • Risk ranking (or priority) for the identified risks
  • Risks grouped by categories
  • Causes of risk
  • List of risks requiring near-term responses
  • List of risks that need additional analysis and response
  • Watch list of low-priority risks
  • Trends in qualitative risk analysis results

The assumption log will receive updates as new information is made available through the qualitative risk assessment. Assumptions could be incorporated in the project scope statement or in a separate log.

Perform Quantitative Risk Analysis

The Perform Quantitative Risk Analysis process evaluates the impacts of risk prioritized during the Perform Qualitative Risk Analysis process and quantifies risk exposure for the project by assigning numeric probabilities to each risk and determining their impacts on project objectives. The purpose of this process is to perform the following:

  • Quantify the project’s possible outcomes and probabilities.
  • Determine the probability of achieving the project objectives.
  • Identify risks that need the most attention by quantifying their contribution to overall project risk.
  • Identify realistic and achievable schedule, cost, or scope targets.
  • Determine the best project management decisions possible when outcomes are uncertain.

Figure 5.13 shows the inputs, tools and techniques, and outputs of the Perform Quantitative Risk Analysis process.

Diagram shows perform quantitative risk analysis process with enterprise environmental factors and representations of uncertainty leading to perform quantitative risk analysis giving outputs as project documents updates.

FIGURE 5.13 Perform Quantitative Risk Analysis process

Inputs of Perform Quantitative Risk Analysis

Know the following inputs of the Perform Quantitative Risk Analysis process:

  • Project management plan
  • Project documents
  • Enterprise environmental factors
  • Organizational process assets

Project Management Plan The risk management plan, a component of the project management plan, guides the project team in carrying out the risk processes. The following key elements are used from within the risk management plan:

  • Roles and responsibilities
  • Risk management activities
  • Guidelines for setting aside contingency reserves
  • RBS
  • Stakeholder tolerances

All project baselines (scope, cost, schedule) are considered when performing quantitative risk analysis. Baselines provide a starting point against which to measure uncertainty.

Project Documents The risk register contains a list of identified risks as well as any other documented information on risks to date. In addition to the risk register, there are several other documents that may prove useful in quantifying risks:

  • Assumption log
  • Basis of estimates
  • Cost estimates
  • Cost forecasts
  • Duration estimates
  • Milestone list
  • Resource requirements
  • Risk report
  • Schedule forecasts

Enterprise Environmental Factors Enterprise environmental factors contribute insight and context to the risk analysis. Two factors to consider are industry studies of similar projects that are conducted by risk specialists and a review of risk databases available from the industry or through proprietary sources.

Organizational Process Assets The organizational process assets include historical information from previous projects.

Tools and Techniques of Perform Quantitative Risk Analysis

Five tools and techniques are used in the Perform Quantitative Risk Analysis process:

  • Expert judgment
  • Data gathering
  • Interpersonal and team skills
  • Representations of uncertainty
  • Data analysis

Expert Judgment Experts can come from inside or outside the organization and should have experience that’s applicable to the project. When performing quantitative risk analysis, experts can also assist in validating the data and tools used and translating information on individual project risks.

Data Gathering Data-gathering and representative techniques used primarily consist of interviews. Project team members, stakeholders, and subject matter experts are typical interview subjects. Oftentimes, three-point estimates are gathered from the experts to quantify the probability and impact of risks on project objectives. The following interview topics are common:

  • Experiences on past projects
  • Experiences working with the types of technology or processes used during this project

Interpersonal and Team Skills As with other risk management processes, facilitation is a key interpersonal and team skill used in combination with other techniques described within the Perform Quantitative Risk Analysis process.

Representations of Uncertainty Continuous probability distributions (particularly beta and triangular distributions) are commonly used in Perform Quantitative Risk Analysis. According to the PMBOK® Guide, the following probability distributions are often used:

  • Normal and lognormal
  • Triangular
  • Beta
  • Uniform distributions
  • Discrete distributions

Distributions are graphically displayed and represent both the probability and time or cost elements.

Data Analysis Data analysis techniques referenced by the PMBOK® Guide include simulation, sensitivity analysis, decision tree analysis, and influence diagrams.

  • Simulation Modeling and simulation techniques are often used for schedule risk analysis and cost analysis. Simulation techniques compute the project model using various inputs, such as cost or schedule duration, to determine a probability distribution for the variable chosen. Modeling and simulation techniques examine the identified risks and their potential impacts to the project objectives from the perspective of the whole project.

    Monte Carlo analysis is an example of a simulation technique. It is replicated many times, typically using cost or schedule variables. Every time the analysis is performed, the values for the variable are changed with the output plotted as a probability distribution. This type of information helps the risk management team determine the probability of completing the project on time and/or within budget.

  • Sensitivity Analysis Sensitivity analysis is a quantitative method of analyzing the potential impact of risk events on the project and determining which risk event (or events) has the greatest potential for impact by examining all the uncertain elements at their baseline values. Figure 5.14 shows a sample tornado diagram, which is one of the ways that sensitivity analysis data can be displayed.
    Diagram shows Tornado process having technical risk, quality risk, project management risk, organizational risk ranging from minus 12,000 to 12,000.

    FIGURE 5.14 Tornado diagram

  • Decision Tree Analysis Expected monetary value (EMV) analysis is a statistical technique that calculates the average, anticipated future impact of the decision. EMV is calculated by multiplying the probability of the risk by its impact and then adding them together:
    • Positive results generally indicate an opportunity within the project.
    • Negative results generally indicate a threat to the project.

    EMV is used in conjunction with the decision tree analysis technique. Decision trees are diagrams that show the sequence of interrelated decisions and the expected results of choosing one alternative over the other. Typically, more than one choice or option is available in response to a decision. The available choices are depicted in tree form, starting at the left with the risk decision branching out to the right with possible outcomes. Decision trees are usually used for risk events associated with time or cost. Figure 5.15 shows a sample decision tree using EMV as one of its inputs.

    Diagram shows decision tree having start divided into choice X and choice Y which are in turn divided into good outcome, poor outcome probabilities giving expected value of decision.

    FIGURE 5.15 Decision tree

  • Influence Diagramming Influence diagramming typically shows the causal influences among project variables, the timing or time ordering of events, and the relationships among other project variables and their outcomes. Figure 5.16 shows an influence diagram for a product introduction decision.
    Diagram shows influence diagram having product introduction, weather, and revenue leading to delivery times.

    FIGURE 5.16 Influence diagram

Outputs of Perform Quantitative Risk Analysis

Like the process before it, the Perform Quantitative Risk Analysis process contains one output, project documents updates, including updates to the risk register and risk report.

The following risk register updates occur as a result of this process:

  • Probabilistic analysis of the project
  • Probability of achieving the cost and time objectives
  • Prioritized list of quantified risks
  • Trends in Perform Quantitative Risk Analysis results
  • Recommended risk responses

Probabilistic Analysis of the Project Probabilistic analysis of the project is the forecasted results of the project schedule and costs as determined by the outcomes of risk analysis. The following are characteristics of probabilistic analysis:

  • Results include projected completion dates and costs along with a confidence level associated with each.
  • The output is often expressed as a cumulative distribution.
  • Results are used along with stakeholder risk tolerances to quantify the time and cost contingency reserves.

Probability of Achieving the Cost and Time Objectives The probability of achieving the cost and time objectives of the project are documented based on the results of performing the quantitative risk analysis tools and techniques.

Prioritized List of Quantified Risks The prioritized list of risks includes the following items:

  • Risks that present the greatest threat or opportunity to the project
  • Risk impacts
  • Risks that present the greatest opportunities to the project
  • Risks that are most likely to impact the critical path
  • Risks with the largest cost contingency

Trends in Perform Quantitative Risk Analysis Results Trends in Perform Quantitative Risk Analysis appear as the process is repeated. Trends are documented for further analysis and for use in developing risk response plans.

Recommended Risk Responses As part of the risk report, recommendations may be captured on risk responses. These responses will not be formalized until the Plan Risk Responses process is performed.

Plan Risk Responses

Plan Risk Responses is a process of deciding what actions to take to reduce threats and take advantage of the opportunities discovered during the risk analysis processes. This includes assigning resources the responsibility of carrying out risk response plans outlined in this process. By the end of this process, the risk register will be updated to include a risk response plan for all risks that require some form of action.

Figure 5.17 shows the inputs, tools and techniques, and outputs of the Plan Risk Responses process.

Diagram shows plan risk response process having enterprise environmental process and data analysis leading to plan risk responses giving outputs project management plan updates, document updates, and change requests.

FIGURE 5.17 Plan Risk Responses process

Inputs of Plan Risk Responses

The Plan Risk Responses process contains four inputs that you should be familiar with. Be sure you know how they are used during the process. They are as follows:

  • Project management plan
  • Project documents
  • Enterprise environmental factors
  • Organizational process assets

Project Management Plan The following are used from within the risk management plan in carrying out this process:

  • Roles and responsibilities that pertain to risk
  • Definitions of risk analysis
  • Risk thresholds
  • Time and budget requirements allotted for risk activities

In addition to the risk management plan, the resource management plan and cost baseline are used as part of the project management plan input. The cost baseline contains information on the contingency fund that will be needed to respond to risks.

Project Documents All of the information included within the risk register to date will be used in developing risk responses. In addition to the risk register, the following documents are useful in developing risk responses:

  • Lessons learned register
  • Project schedule
  • Project team assignments
  • Resource calendars
  • Risk report
  • Stakeholder register

Enterprise Environmental Factors Enterprise environmental factors used to carry out the Plan Risk Responses process primarily include the risk appetite and risk thresholds of key stakeholders.

Organizational Process Assets Organizational process assets used to carry out this process include lessons learned from past similar projects, historical databases, and any relevant templates that can be leveraged.

Tools and Techniques of Plan Risk Responses

Tools and techniques of the Plan Risk Responses process that you should know are as follows:

  • Expert judgment
  • Data gathering
  • Interpersonal and team skills
  • Strategies for threats
  • Strategies for opportunities
  • Contingent response strategies
  • Strategies for overall project risk
  • Data analysis
  • Decision making

Expert Judgment Expert judgment is used in developing risk responses, including feedback and guidance from risk management experts and those internal to the project qualified to provide assistance in this process. Experts are key in providing feedback and information on response strategies used.

Data Gathering Interviews are a useful data-gathering technique to gain feedback and information from key stakeholders on risk response strategies in an environment that provides trust and confidentiality and protects against bias.

Interpersonal and Team Skills Facilitation is used in combination with other techniques to develop risk response strategies.

Strategies for Threats As Figure 5.18 shows, strategies for threats include escalate, avoid, transfer, mitigate, and accept.

Image described by caption and surrounding text.

FIGURE 5.18 Strategies for threats

  • Escalate Escalate is a risk response strategy used for threats when the threat goes beyond the authority level of the project manager or is outside of the project, such as within a program or portfolio. It is then up to the program or portfolio manager to lead the response strategy.

    According to the PMBOK® Guide, after a risk has been escalated, it is no longer monitored further by the project team. The project team, however, may choose to log it within the risk register as information.

  • Avoid To avoid a risk means to evade it altogether, eliminate the cause of the risk event, or change the project plan to protect the project objectives from the risk event.

    Here are some examples of avoiding risk:

    • Improving communications
    • Refining requirements
    • Assigning additional resources to project activities
    • Refining the project scope to avoid risk events
  • Transfer The purpose of risk transfer is to transfer a risk and its consequences to a third party. This strategy will impact the project budget.

    Here are some examples of transferring risk:

    • Insurance
    • Contracting
    • Warranties
    • Guarantees
    • Performance bonds
  • Mitigate To mitigate a risk means to reduce the probability of a risk event and its impacts to an acceptable level. According to the PMBOK® Guide, the purpose of mitigation is to reduce the probability that a risk will occur and reduce the impact of the risk to an acceptable level.
  • Accept The acceptance strategy is used when the project team isn’t able to eliminate all the threats to the project. Acceptance of a risk event is a strategy that can be used for risks that pose either threats or opportunities to the project. There are two forms of acceptance:
    • Passive acceptance occurs when the project team has assessed the risk as low enough in probability and/or impact that they choose to do no additional planning for that potential event at this time.
    • Active acceptance includes developing contingency reserves to deal with risks should they occur.

Strategies for Opportunities Strategies for opportunities, as shown in Figure 5.19 , include escalate, exploit, share, enhance, and accept.

Image described by caption and surrounding text.

FIGURE 5.19 Strategies for opportunities

  • Escalate As with threats, responses to opportunities that are either outside the authority level of the project manager or outside the project’s scope are escalated to the appropriate parties. If opportunities are under the jurisdiction of a program or portfolio, then the risk is escalated to the program manager or portfolio manager. respectively.
  • Exploit Exploiting a risk event is to look for opportunities for positive impacts. This is the strategy of choice when opportunities have been identified and the project team wants to make certain the risk will occur within the project. An example of exploiting a risk would be reducing the amount of time to complete the project by bringing on more qualified resources.
  • Share The share strategy is similar to transferring because risk is assigned to a third-party owner who is best able to bring about the opportunity the risk event presents. An example of sharing a risk would be a joint venture.
  • Enhance The enhance strategy involves closely watching the probability or impact of the risk event to ensure that the organization realizes the benefits. This entails watching for and emphasizing risk triggers and identifying the root causes of the risk to help enhance impacts or probability.
  • Accept This is similar to the accept strategies used for threats.

Contingent Response Strategies Contingent response strategies, also known as contingency planning, involves planning alternatives to deal with the risks should they occur. Contingency planning recognizes that risks may occur and that plans should be in place to deal with them.

The following contingency responses are common:

  • Contingency reserves, which include project funds that are held in reserve to offset any unavoidable threats that might occur to project scope, schedule, cost, or quality. Also includes reserving time and resources to account for risks.
  • Fallback plans, which are developed for risks with high impact or for risks with identified strategies that might not be the most effective at dealing with the risk.

Strategies for Overall Project Risk Strategies for addressing overall project risk are similar to those used for threats or opportunities. The only difference is that they respond to overall project risk versus individual project risks.

Risk strategies are as follows:

  • Avoid/exploit
  • Transfer/share
  • Mitigate/enhance
  • Accept

Data Analysis Data analysis techniques refer to alternative analysis and cost-benefit analysis. These techniques are used when weighing options that exist in responding to identified risks.

Decision Making Multicriteria decision analysis is a form of a decision-making technique used to develop risk responses. This type of analysis uses a decision matrix to develop criteria that is then used to prioritize risk response strategies. Sample criteria provided by the PMBOK® Guide include things such as the likely effectiveness of a response, cost of response, timing constraints, and the introduction of secondary risks.

Outputs of Plan Risk Responses

Here are the three outputs of the Plan Risk Responses process:

  • Project management plan updates
  • Project documents updates
  • Change requests

Project Management Plan Updates The following documents within the project management plan may require updates to reflect the changes in process and practice that are driven by the risk responses:

  • Any and all of the management plans, including the schedule management plan, cost management plan, quality management plan, procurement management plan, and resource management plan
  • Any and all of the project baselines, including the scope baseline, schedule baseline, and cost baseline

Project Documents Updates There are several project document updates, with the key update occurring to the risk register. Elements to the risk register can include but are not limited to the following items:

  • List of identified risks, including their descriptions, what WBS element they impact (or area of the project), categories (RBS), root causes, and how the risks impact the project objectives
  • Risk owners and their responsibility
  • Outputs from the Perform Qualitative Analysis process
  • Agreed-upon response strategies
  • Actions needed to implement response plans
  • Risk triggers
  • Cost and schedule activities needed to implement risk responses
  • Contingency plans
  • Fallback plans, which are risk response plans that are executed when the initial risk response plan proves to be ineffective
  • Contingency reserves
  • Residual risk, which is a leftover risk that remains after the risk response strategy has been implemented
  • Secondary risks, which are risks that come about as a result of implementing a risk response

Other project documents, such as the risk report, technical documentation, and the assumptions documented in the assumption log, may require an update after performing this process.

Change Requests Change requests may be required as a result of carrying out this process due to the risk responses selected, which may call for altering an approach noted within a plan, or impact a baseline.


Bringing the Processes Together

This chapter covered additional information on processes that belong to the Planning process group. Although there is a lot of material to take in within the Planning process group alone, you are nearly there! Chapter 6 will wrap up our overview of this process group.

As we have done in previous chapters, let’s go back and review what you’ve learned thus far about each of the project management Knowledge Areas covered in this chapter. Remember that activity that occurs within each Knowledge Area is connected on a high level and is structured in a logical format.

Project Resource Management Knowledge Area Review

Figure 5.20 depicts the two planning processes within the Project Resource Management Knowledge Area. Key to the first process of the Knowledge Area is developing the resource management plan, which will guide the rest of the processes relating to resources, including hiring, developing, and managing the project team. The second process, Estimate Activity Resources, which was covered in detail within Chapter 3, is key to developing the schedule.

Image described by caption and surrounding text.

FIGURE 5.20 Project Resource Management Knowledge Area process interaction

Project Communications Management Knowledge Area Review

As you learned in this chapter, meeting stakeholder needs, requirements, and expectations is essential to a successful project. Project communications play a big role in meeting these objectives. Figure 5.21 depicts the only planning-related step within the Project Communications Management Knowledge Area. This step determines how project communications will be managed and defines stakeholder communication requirements. The result is the communications management plan. To define the communication needs and requirements of stakeholders, you need the following result of the Initiating process group: stakeholder register.

Image described by caption and surrounding text.

FIGURE 5.21 Project Communications Knowledge Area process interaction

Project Risk Management Knowledge Area Review

Risk management planning begins as early as the project begins. The first step, which creates the risk management plan, is carried through early on during the planning phase of the project. Project plans, such as the cost management plan, the schedule management plan, and the communications management plan, are used to develop the risk management plan. The project scope statement is also used.

As depicted in Figure 5.22 , the steps within risk management planning are very intuitive. First, you plan how to manage, assess, and deal with risks. Then, you identify the risks and prioritize them. Analyzing the risks comes next. As you may recall, this can include qualitative risk analysis and quantitative risk analysis.

Image described by caption and surrounding text.

FIGURE 5.22 Project Risk Management Knowledge Area process interaction

With the existing information at hand, you can now plan how you will respond to risks that call for action. As you can see in Figure , the risk register is a living document, updated throughout the project as risks are identified. It documents all of the information about these risks and is therefore continuously updated as the processes are carried out.

Project Procurement Management Knowledge Area Review

Figure 5.23 shows the single procurement-planning step. Here you plan how procurements will be carried out and managed within the project. This activity also determines which products or services will be procured.

Diagram shows project procurement management knowledge area where scope and cost baselines leads to plan to carry out and manage procurements finally giving procurement management plan, make-or-buy decision, and procurement-related documents.

FIGURE 5.23 Project Procurement Management Knowledge Area process interaction

The results include the following items:

  • A plan that lays out the guidelines for carrying out procurement activities, the types of contracts that will be used, and how vendor progress and performance will be measured
  • Make-or-buy decisions
  • Several key procurement-related documents, including make-or-buy decisions, the procurement statement of work, and source selection criteria

Review Questions

  1. Rodrigo is in the Plan Communications Management process of a new systems component project. He has determined that there are 32 stakeholders in the project. How many communication channels exist?

    1. 496
    2. 512
    3. 32
    4. 31

  2. What is the purpose of the Perform Qualitative Risk Analysis process?

    1. To determine how the project team will plan for risks
    2. To identify and gather all potential risks within the project
    3. To determine the impact and probability of identified risks and prioritize them
    4. To evaluate the impact of risks prioritized and determine the risk exposure

  3. Which type of contract carries the highest risk for the buyer?

    1. Fixed-price contracts
    2. Lump-sum contracts
    3. Cost-reimbursable contracts
    4. Time and material contracts

  4. All of the following are determined by the Plan Resource Management process except:

    1. Project communication needs for stakeholders
    2. Project roles and responsibilities
    3. Reporting relationships for the project
    4. Project team resource management

  5. All of the following are outputs of the Plan Procurement Management process except:

    1. Procurement statement of work
    2. Make-or-buy analysis
    3. Procurement documents
    4. Source selection criteria

  6. All of the following define the purpose of the Identify Risks process except:

    1. Identify all risks that might impact the project.
    2. Document all risks that might impact the project.
    3. Control all risks that might impact the project.
    4. Identify all characteristics of identified risks.

  7. Hierarchical charts and matrix-based charts are what type of tool and technique?

    1. Data representation
    2. Data gathering
    3. Expert judgment
    4. Data analysis

  8. Emails, letters, and voicemails are forms of what communication method?

    1. Interactive communication
    2. Push communication
    3. Pull communication
    4. Multidirectional communication

  9. Which type of contract carries the least amount of risk for the seller?

    1. Lump-sum
    2. Cost plus
    3. Time and material
    4. Cost-reimbursable

  10. What technique allows the project manager to gather information from stakeholders in a way that encourages unbiased feedback as well as an environment of trust?

    1. Brainstorming
    2. Focus groups
    3. Interviews
    4. Checklists
..................Content has been hidden....................

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