How to prepare for the PMP Exam?: Tools and Techniques

Tools and Techniques - Part 2

Every process in PMBOK(R) uses certain Tools and Techniques to process the inputs into outputs. In our second part of this Tools and Techniques, presented below are the Tools and Techniques left out in First part.

Training

Training includes all activities designed to enhance the competencies of the project team members. Training can be formal or informal. Examples of training methods include classroom, online, computer-based, on-the-job training from another project team member, mentoring, and coaching. If project team members lack the necessary management or technical skills, such skills can be developed as part of the project work. Scheduled training takes place as stated in the human resource management plan. Unplanned training takes place as a result of observation, conversation, and project performance appraisals conducted during the controlling process of managing the project team. Training costs could be included in the project budget, or supported by performing organization if the added skills may be useful for future projects. It could be performed by in-house or external trainers.

PMBoK(R) 5^th Edition, Page 275

Team-Building Activities

Team-building activities can vary from a 5-minute agenda item in a status review meeting to an off-site, professionally facilitated experience designed to improve interpersonal relationships. The objective of team-building activities is to help individual team members work together effectively. Team-building strategies are particularly valuable when team members operate from remote locations without the benefit of face-to-face contact. Informal communication and activities can help in building trust and establishing good working relationships.

As an ongoing process, team building is crucial to project success. While team building is essential during the initial stages of a project, it is a never-ending process. Changes in a project environment are inevitable, and to manage them effectively, a continued or a renewed team-building effort should be applied. The project manager should continually monitor team functionality and performance to determine if any actions are needed to prevent or correct various team problems.

One of the models used to describe team development is the Tuckman ladder (Tuckman, 1965; Tuckman & Jensen, 1977), which includes five stages of development that teams may go through. Although it’s common for these stages to occur in order, it’s not uncommon for a team to get stuck in a particular stage or slip to an earlier stage. Projects with team members who worked together in the past may skip a stage.

Forming. This phase is where the team meets and learns about the project and their formal roles and responsibilities. Team members tend to be independent and not as open in this phase.
Storming. During this phase, the team begins to address the project work, technical decisions, and the project management approach. If team members are not collaborative and open to differing ideas and perspectives, the environment can become counterproductive.
Norming. In the norming phase, team members begin to work together and adjust their work habits and behaviors to support the team. The team learns to trust each other.
Performing. Teams that reach the performing stage function as a well-organized unit. They are interdependent and work through issues smoothly and effectively.
Adjourning. In the adjourning phase, the team completes the work and moves on from the project. This typically occurs when staff is released from the project as deliverables are completed or as part of carrying out the Close Project or Phase process.

The duration of a particular stage depends upon team dynamics, team size, and team leadership. Project managers should have a good understanding of team dynamics in order to move their team members through all stages in an effective manner.

PMBoK(R) 5^th Edition, Page 276

Ground Rules

Ground rules establish clear expectations regarding acceptable behavior by project team members. Early commitment to clear guidelines decreases misunderstandings and increases productivity. Discussing ground rules in areas such as code of conduct, communication, working together, or meeting etiquette allows team members to discover values that are important to one another. All project team members share responsibility for enforcing the rules once they are established.

PMBoK(R) 5^th Edition, Page 277

Colocation

Colocation, also referred to as “tight matrix,” involves placing many or all of the most active project team members in the same physical location to enhance their ability to perform as a team. Colocation can be temporary, such as at strategically important times during the project, or for the entire project. Colocation strategies can include a team meeting room (sometimes called “war room”), places to post schedules, and other conveniences that enhance communication and a sense of community. While colocation is considered a good strategy, the use of virtual teams can bring benefits such as the use of more skilled resources, reduced costs, less travel, and relocation expenses and the proximity of team members to suppliers, customers, or other key stakeholders.

PMBoK(R) 5^th Edition, Page 277

Recognition and Rewards

Part of the team development process involves recognizing and rewarding desirable behavior. The original plans concerning ways in which to reward people are developed during the Plan Human Resource Management process.

It is important to recognize that a particular reward given to any individual will be effective only if it satisfies a need which is valued by that individual. Award decisions are made, formally or informally, during the process of managing the project team through project performance appraisals. Cultural differences should be considered when determining recognition and rewards. People are motivated if they feel they are valued in the organization and this value is demonstrated by the rewards given to them. Generally, money is viewed as a tangible aspect of any reward system, but intangible rewards could be equally or even more effective. Most project team members are motivated by an opportunity to grow, accomplish, and apply their professional skills to meet new challenges. A good strategy for project managers is to give the team recognition throughout the life cycle of the project rather than waiting until the project is completed.

PMBoK(R) 5^th Edition, Page 277

Personnel Assessment Tools

Personnel assessment tools give the project manager and the project team insight into areas of strength and weakness. These tools help project managers assess the team preferences, aspirations, how they process and organize information, how they tend to make decisions, and how they prefer to interact with people.

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

PMBoK(R) 5^th Edition, Page 278

Observation and Conversation

Observation and conversation are used to stay in touch with the work and attitudes of project team members.

The project management team monitors progress toward project deliverables, accomplishments that are a source of pride for team members, and interpersonal issues.

PMBoK(R) 5^th Edition, Page 282

Project Performance Appraisals

Objectives for conducting performance appraisals during the course of a project can include clarification of roles and responsibilities, constructive feedback to team members, discovery of unknown or unresolved issues, development of individual training plans, and the establishment of specific goals for future time periods.

The need for formal or informal project performance appraisals depends on the length of the project, complexity of the project, organizational policy, labor contract requirements, and the amount and quality of regular communication.

PMBoK(R) 5^th Edition, Page 282

Conflict Management

Conflict is inevitable in a project environment. Sources of conflict include scarce resources, scheduling priorities, and personal work styles. Team ground rules, group norms, and solid project management practices, like communication planning and role definition, reduce the amount of conflict.

Successful conflict management results in greater productivity and positive working relationships. When managed properly, differences of opinion can lead to increased creativity and better decision making. If the differences become a negative factor, project team members are initially responsible for their resolution. If conflict escalates, the project manager should help facilitate a satisfactory resolution. Conflict should be addressed early and usually in private, using a direct, collaborative approach. If disruptive conflict continues, formal procedures may be used, including disciplinary actions.

The success of project managers in managing their project teams often depends a great deal on their ability to resolve conflict. Different project managers may utilize different conflict resolution methods. Factors that influence conflict resolution methods include:

Relative importance and intensity of the conflict,
Time pressure for resolving the conflict,
Position taken by persons involved, and
Motivation to resolve conflict on a long-term or a short-term basis.

There are five general techniques for resolving conflict. As each one has its place and use, these are not given in any particular order:

Withdraw/Avoid. Retreating from an actual or potential conflict situation; postponing the issue to be better prepared or to be resolved by others.
Smooth/Accommodate. Emphasizing areas of agreement rather than areas of difference; conceding one’s position to the needs of others to maintain harmony and relationships.
Compromise/Reconcile. Searching for solutions that bring some degree of satisfaction to all parties in order to temporarily or partially resolve the conflict.
Force/Direct. Pushing one’s viewpoint at the expense of others; offering only win-lose solutions, usually enforced through a power position to resolve an emergency.
Collaborate/Problem Solve. Incorporating multiple viewpoints and insights from differing perspectives; requires a cooperative attitude and open dialogue that typically leads to consensus and commitment.

PMBoK(R) 5^th Edition, Page 282 and 283

Communication Requirements Analysis

The analysis of the communication requirements determines the information needs of the project stakeholders.

These requirements are defined by combining the type and format of information needed with an analysis of the value of that information. Project resources should be expended only on communicating information that contributes to the success of the project or where a lack of communication can lead to failure.

The project manager should also consider the number of potential communication channels or paths as an indicator of the complexity of a project’s communications. The total number of potential communication channels is n(n – 1)/2, where n represents the number of stakeholders. For example, a project with 10 stakeholders has 10(10 – 1)/2 = 45 potential communication channels. As a result, a key component of planning the project’s actual communications is to determine and limit who will communicate with whom and who will receive what information.

PMBoK(R) 5^th Edition, Page 291 and 292

Communication Technology

The methods used to transfer information among project stakeholders may vary significantly. For example, a project team may use techniques from brief conversations to extended meetings, or from simple written documents to extensive materials (e.g., schedules, databases, and websites), which are accessible online as methods of communication.

Factors that can affect the choice of communication technology include:

Urgency of the need for information. There is a need to consider the urgency, frequency, and format of the information to be communicated as they may vary from project to project and also within different stages of a project.
Availability of technology. There is a need to ensure that the technology that is required to facilitate communication is compatible, available, and accessible for all stakeholders throughout the life of the project.
Ease of Use. There is a need to ensure that the choice of communication technologies is suitable for project participants and that appropriate training events are planned for, where appropriate.
Project environment. There is a need to determine if the team will meet and operate on a face-to-face basis or in a virtual environment; whether they will be located in one or multiple time zones; whether they will use multiple languages for communication; and finally, whether there are any other project environmental factors, such as culture, which may affect communications.
Sensitivity and confidentiality of the information. There is a need to determine if the information to be communicated is sensitive or confidential and whether or not additional security measures need to be taken. Also, the most appropriate way to communicate the information should be considered.

PMBoK(R) 5^th Edition, Page 292 and 293

Communication Models

The communication models used to facilitate communications and the exchange of information may vary from project to project and also within different stages of the same project. A basic communication model, consists of two parties, defined as the sender and receiver. Medium is the technology medium and includes the mode of communication while noise includes any interference or barriers that might compromise the delivery of the message. The sequence of steps in a basic communication model is:

Encode. Thoughts or ideas are translated (encoded) into language by the sender.
Transmit Message. This information is then sent by the sender using communication channel (medium). The transmission of this message may be compromised by various factors (e.g., distance, unfamiliar technology, inadequate infrastructure, cultural difference, and lack of background information). These factors are collectively termed as noise.
Decode. The message is translated by the receiver back into meaningful thoughts or ideas.
Acknowledge. Upon receipt of a message, the receiver may signal (acknowledge) receipt of the message but this does not necessarily mean agreement with or comprehension of the message.
Feedback/Response. When the received message has been decoded and understood, the receiver encodes thoughts and ideas into a message and then transmits this message to the original sender.

PMBoK(R) 5^th Edition, Page 294

Communication Methods

There are several communication methods that are used to share information among project stakeholders.

These methods are broadly classified as follows:

Interactive communication. Between two or more parties performing a multidirectional exchange of information. It is the most efficient way to ensure a common understanding by all participants on specified topics, and includes meetings, phone calls, instant messaging, video conferencing, etc.
Push communication. Sent to specific recipients who need to receive the information. This ensures that the information is distributed but does not ensure that it actually reached or was understood by the intended audience. Push communications include letters, memos, reports, emails, faxes, voice mails, blogs, press releases, etc.
Pull communication. Used for very large volumes of information, or for very large audiences, and requires the recipients to access the communication content at their own discretion. These methods include intranet sites, e-learning, lessons learned databases, knowledge repositories, etc.

PMBoK(R) 5^th Edition, Page 295

Information Management Systems

Project information is managed and distributed using a variety of tools, including:

Hard-copy document management: letters, memos, reports, and press releases;
Electronic communications management: e-mail, fax, voice mail, telephone, video and web conferencing, websites, and web publishing; and
Electronic project management tools: web interfaces to scheduling and project management software, meeting and virtual office support software, portals, and collaborative work management tools.

PMBoK(R) 5^th Edition, Page 300

Performance Reporting

Performance reporting is the act of collecting and distributing performance information, including status reports, progress measurements, and forecasts. Performance reporting involves the periodic collection and analysis of baseline versus actual data to understand and communicate the project progress and performance as well as to forecast the project results.

Performance reporting needs to provide information at an appropriate level for each audience. The format may range from a simple status report to more elaborate reports and may be prepared regularly or on an exception basis. A simple status report might show performance information, such as percent complete or status dashboards for each area (i.e., scope, schedule, cost, and quality). More elaborate reports may include:

Analysis of past performance,
Analysis of project forecasts (including time and cost),
Current status of risks and issues,
Work completed during the period,
Work to be completed in the next period,
Summary of changes approved in the period, and
Other relevant information, which is reviewed and discussed.

PMBoK(R) 5^th Edition, Page 301

Documentation Reviews

A structured review of the project documentation may be performed, including plans, assumptions, previous project files, agreements, and other information. The quality of the plans, as well as consistency between those plans and the project requirements and assumptions, may be indicators of risk in the project.

PMBoK(R) 5^th Edition, Page 324

Information Gathering Techniques

Examples of information gathering techniques used in identifying risks can include:

Brainstorming. The goal of brainstorming is to obtain a comprehensive list of project risks. The project team usually performs brainstorming, often with a multidisciplinary set of experts who are not part of the team. Ideas about project risk are generated under the leadership of a facilitator, either in a traditional free-form brainstorm session or structured mass interviewing techniques. Categories of risk, such as in a risk breakdown structure, can be used as a framework. Risks are then identified and categorized by type of risk and their definitions are refined.
Delphi technique. The Delphi technique is a way to reach a consensus of experts. Project risk experts participate in this technique anonymously. A facilitator uses a questionnaire to solicit ideas about the important project risks. The responses are summarized and are then recirculated to the experts for further comment. Consensus may be reached in a few rounds of this process. The Delphi technique helps reduce bias in the data and keeps any one person from having undue influence on the outcome.
Interviewing. Interviewing experienced project participants, stakeholders, and subject matter experts helps to identify risks.
Root cause analysis. Root-cause analysis is a specific technique used to identify a problem, discover the underlying causes that lead to it, and develop preventive action.

PMBoK(R) 5^th Edition, Page 324 and 325

Checklist Analysis

Risk identification checklists are developed based on historical information and knowledge that has been accumulated from previous similar projects and from other sources of information. The lowest level of the RBS can also be used as a risk checklist. While a checklist may be quick and simple, it is impossible to build an exhaustive one, and care should be taken to ensure the checklist is not used to avoid the effort of proper risk identification. The team should also explore items that do not appear on the checklist. Additionally, the checklist should be pruned from time to time to remove or archive related items. The checklist should be reviewed during project closure to incorporate new lessons learned and improve it for use on future projects.

PMBoK(R) 5^th Edition, Page 325

Assumptions Analysis

Every project and its plan is conceived and developed based on a set of hypotheses, scenarios, or assumptions. Assumptions analysis explores the validity of assumptions as they apply to the project. It identifies risks to the project from inaccuracy, instability, inconsistency, or incompleteness of assumptions.

PMBoK(R) 5^th Edition, Page 325

Diagramming Techniques

Risk diagramming techniques may include:

Cause and effect diagrams. These are also known as Ishikawa or fishbone diagrams and are useful for identifying causes of risks.
System or process flow charts. These show how various elements of a system interrelate and the mechanism of causation.
Influence diagrams. These are graphical representations of situations showing causal influences, time ordering of events, and other relationships among variables and outcomes

PMBoK(R) 5^th Edition, Page 325

SWOT Analysis

This technique examines the project from each of the strengths, weaknesses, opportunities, and threats (SWOT) perspectives to increase the breadth of identified risks by including internally generated risks. The technique starts with identification of strengths and weaknesses of the organization, focusing on either the project, organization, or the business area in general. SWOT analysis then identifies any opportunities for the project that arise from organizational strengths, and any threats arising from organizational weaknesses. The analysis also examines the degree to which organizational strengths offset threats, as well as identifying opportunities that may serve to overcome weaknesses.

PMBoK(R) 5^th Edition, Page 326

Risk Probability and Impact Assessment

Risk probability assessment investigates the likelihood that each specific risk will occur. Risk impact assessment investigates the potential effect on a project objective such as schedule, cost, quality, or performance, including both negative effects for threats and positive effects for opportunities.

Probability and impact are assessed for each identified risk. Risks can be assessed in interviews or meetings with participants selected for their familiarity with the risk categories on the agenda. Project team members and knowledgeable persons external to the project are included. The level of probability for each risk and its impact on each objective is evaluated during the interview or meeting.

Explanatory detail, including assumptions justifying the levels assigned, are also recorded. Risk probabilities and impacts are rated according to the definitions given in the risk management plan. Risks with low ratings of probability and impact will be included within the risk register as part of the watch list for future monitoring.

PMBoK(R) 5^th Edition, Page 330

Probability and Impact Matrix

Risks can be prioritized for further quantitative analysis and planning risk responses based on their risk rating.

Ratings are assigned to risks based on their assessed probability and impact. Evaluation of each risk’s importance and priority for attention is typically conducted using a look-up table or a probability and impact matrix. Such a matrix specifies combinations of probability and impact that lead to rating the risks as low, moderate, or high priority. Descriptive terms or numeric values can be used depending on organizational preference.

Each risk is rated on its probability of occurrence and impact on an objective if it does occur. The organization should determine which combinations of probability and impact result in a classification of high risk, moderate risk, and low risk. In a black-and-white matrix, these conditions are denoted using different shades of gray. Usually, these risk-rating rules are specified by the organization in advance of the project and included in organizational process assets. Risk rating rules can be tailored in the Plan Risk Management process to the specific project.

PMBoK(R) 5^th Edition, Page 331

Risk Data Quality Assessment

Risk data quality assessment is a technique to evaluate the degree to which the data about risks is useful for risk management. It involves examining the degree to which the risk is understood and the accuracy, quality, reliability, and integrity of the data about the risk.

The use of low-quality risk data may lead to a qualitative risk analysis of little use to the project. If data quality is unacceptable, it may be necessary to gather better data. Often, the collection of information about risks is difficult, and consumes more time and resources than originally planned. The numbers of steps in the scale are usually established when defining the risk attitude of the organization.

PMBoK(R) 5^th Edition, Page 332

Risk Categorization

Risks to the project can be categorized by sources of risk (e.g., using the RBS), the area of the project affected (e.g., using the WBS), or other useful categories (e.g., project phase) to determine the areas of the project most exposed to the effects of uncertainty. Risks can also be categorized by common root causes. This technique helps determine work packages, activities, project phases or even roles in the project, which can lead to the development of effective risk responses.

PMBoK(R) 5^th Edition, Page 332

Risk Urgency Assessment

Risks requiring near-term responses may be considered more urgent to address. Indicators of priority may include probability of detecting the risk, time to affect a risk response, symptoms and warning signs, and the risk rating. In some qualitative analyses, the assessment of risk urgency is combined with the risk ranking that is determined from the probability and impact matrix to give a final risk severity rating.

PMBoK(R) 5^th Edition, Page 333

Data Gathering and Representation Techniques

Interviewing. Interviewing techniques draw on experience and historical data to quantify the probability and impact of risks on project objectives. The information needed depends upon the type of probability distributions that will be used. For instance, information would be gathered on the optimistic (low), pessimistic (high), and most likely scenarios for some commonly used distributions. Additional information on three-point estimates appears in Estimate Activity Durations and Estimate Costs. Documenting the rationale of the risk ranges and the assumptions behind them are important components of the risk interview because they can provide insight on the reliability and credibility of the analysis.
Probability distributions. Continuous probability distributions, which are used extensively in modeling and simulation, represent the uncertainty in values such as durations of schedule activities and costs of project components. Discrete distributions can be used to represent uncertain events, such as the outcome of a test or a possible scenario in a decision tree. These distributions depict shapes that are compatible with the data typically developed during the quantitative risk analysis. Uniform distributions can be used if there is no obvious value that is more likely than any other between specified high and low bounds, such as in the early concept stage of design.

PMBoK(R) 5^th Edition, Page 336 and 337

Quantitative Risk Analysis and Modeling Techniques

Commonly used techniques use both event-oriented and project-oriented analysis approaches, including:

Sensitivity analysis. Sensitivity analysis helps to determine which risks have the most potential impact on the project. It helps to understand how the variations in project’s objectives correlate with variations in different uncertainties. Conversely, it examines the extent to which the uncertainty of each project element affects the objective being studied when all other uncertain elements are held at their baseline values. One typical display of sensitivity analysis is the tornado diagram, which is useful for comparing relative importance and impact of variables that have a high degree of uncertainty to those that are more stable. The Tornado diagram is also helpful in analyzing risk-taking scenarios enabled on specific risks whose quantitative analysis highlights possible benefits greater than corresponding identified negative impacts. A tornado diagram is a special type of bar chart used in sensitivity analysis for comparing the relative importance of the variables. In a tornado diagram, the Y-axis contains each type of uncertainty at base values, and the X-axis contains the spread or correlation of the uncertainty to the studied output. In this figure, each uncertainty contains a horizontal bar and is ordered vertically to show uncertainties with a decreasing spread from the base values.
Expected monetary value analysis. Expected monetary value (EMV) analysis is a statistical concept that calculates the average outcome when the future includes scenarios that may or may not happen (i.e., analysis under uncertainty). The EMV of opportunities are generally expressed as positive values, while those of threats are expressed as negative values. EMV requires a risk-neutral assumption—neither risk averse nor risk seeking. EMV for a project is calculated by multiplying the value of each possible outcome by its probability of occurrence and adding the products together. A common use of this type of analysis is a decision tree analysis.
Modeling and simulation. A project simulation uses a model that translates the specified detailed uncertainties of the project into their potential impact on project objectives. Simulations are typically performed using the Monte Carlo technique. In a simulation, the project model is computed many times (iterated), with the input values (e.g., cost estimates or activity durations) chosen at random for each iteration from the probability distributions of these variables. A histogram (e.g., total cost or completion date) is calculated from the iterations. For a cost risk analysis, a simulation uses cost estimates. For a schedule risk analysis, the schedule network diagram and duration estimates are used. It illustrates the respective probability of achieving specific cost targets. Similar curves can be developed for other project objectives.

PMBoK(R) 5^th Edition, Page 338, 339 and 340

Strategies for Negative Risks or Threats

Three strategies, which typically deal with threats or risks that may have negative impacts on project objectives if they occur, are: avoid, transfer, and mitigate. The fourth strategy, accept, can be used for negative risks or threats as well as positive risks or opportunities. Each of these risk response strategies have varied and unique influence on the risk condition. These strategies should be chosen to match the risk’s probability and impact on the project’s overall objectives. Avoidance and mitigation strategies are usually good strategies for critical risks with high impact, while transference and acceptance are usually good strategies for threats that are less critical and with low overall impact. The four strategies for dealing with negative risks or threats are further described as follows:

Avoid. Risk avoidance is a risk response strategy whereby the project team acts to eliminate the threat or protect the project from its impact. It usually involves changing the project management plan to eliminate the threat entirely. The project manager may also isolate the project objectives from the risk’s impact or change the objective that is in jeopardy. Examples of this include extending the schedule, changing the strategy, or reducing scope. The most radical avoidance strategy is to shut down the project entirely. Some risks that arise early in the project can be avoided by clarifying requirements, obtaining information, improving communication, or acquiring expertise.
Transfer. Risk transference is a risk response strategy whereby the project team shifts the impact of a threat to a third party, together with ownership of the response. Transferring the risk simply gives another party responsibility for its management—it does not eliminate it. Transferring does not mean disowning the risk by transferring it to a later project or another person without his or her knowledge or agreement. Risk transference nearly always involves payment of a risk premium to the party taking on the risk. Transferring liability for risk is most effective in dealing with financial risk exposure. Transference tools can be quite diverse and include, but are not limited to, the use of insurance, performance bonds, warranties, guarantees, etc. Contracts or agreements may be used to transfer liability for specified risks to another party. For example, when a buyer has capabilities that the seller does not possess, it may be prudent to transfer some work and its concurrent risk contractually back to the buyer. In many cases, use of a cost-plus contract may transfer the cost risk to the buyer, while a fixed-price contract may transfer risk to the seller.
Mitigate. Risk mitigation is a risk response strategy whereby the project team acts to reduce the probability of occurrence or impact of a risk. It implies a reduction in the probability and/or impact of an adverse risk to be within acceptable threshold limits. Taking early action to reduce the probability and/or impact of a risk occurring on the project is often more effective than trying to repair the damage after the risk has occurred. Adopting less complex processes, conducting more tests, or choosing a more stable supplier are examples of mitigation actions. Mitigation may require prototype development to reduce the risk of scaling up from a bench-scale model of a process or product. Where it is not possible to reduce probability, a mitigation response might address the risk impact by targeting linkages that determine the severity. For example, designing redundancy into a system may reduce the impact from a failure of the original component.
Accept. Risk acceptance is a risk response strategy whereby the project team decides to acknowledge the risk and not take any action unless the risk occurs. This strategy is adopted where it is not possible or cost-effective to address a specific risk in any other way. This strategy indicates that the project team has decided not to change the project management plan to deal with a risk, or is unable to identify any other suitable response strategy. This strategy can be either passive or active. Passive acceptance requires no action except to document the strategy, leaving the project team to deal with the risks as they occur, and to periodically review the threat to ensure that it does not change significantly. The most common active acceptance strategy is to establish a contingency reserve, including amounts of time, money, or resources to handle the risks.

PMBoK(R) 5^th Edition, Page 344 and 345

Strategies for Positive Risks or Opportunities

Three of the four responses are suggested to deal with risks with potentially positive impacts on project objectives. The fourth strategy, accept, can be used for negative risks or threats as well as positive risks or opportunities. These strategies, described below, are to exploit, share, enhance, and accept.

Exploit. The exploit strategy may be selected for risks with positive impacts where the organization wishes to ensure that the opportunity is realized. This strategy seeks to eliminate the uncertainty associated with a particular upside risk by ensuring the opportunity definitely happens. Examples of directly exploiting responses include assigning an organization’s most talented resources to the project to reduce the time to completion or using new technologies or technology upgrades to reduce cost and duration required to realize project objectives.
Enhance. The enhance strategy is used to increase the probability and/or the positive impacts of an opportunity. Identifying and maximizing key drivers of these positive-impact risks may increase the probability of their occurrence. Examples of enhancing opportunities include adding more resources to an activity to finish early.
Share. Sharing a positive risk involves allocating some or all of the ownership of the opportunity to a third party who is best able to capture the opportunity for the benefit of the project. Examples of sharing actions include forming risk-sharing partnerships, teams, special-purpose companies, or joint ventures, which can be established with the express purpose of taking advantage of the opportunity so that all parties gain from their actions.
Accept. Accepting an opportunity is being willing to take advantage of the opportunity if it arises, but not actively pursuing it.

PMBoK(R) 5^th Edition, Page 345 and 346

Contingent Response Strategies

Some responses are designed for use only if certain events occur. For some risks, it is appropriate for the project team to make a response plan that will only be executed under certain predefined conditions, if it is believed that there will be sufficient warning to implement the plan. Events that trigger the contingency response, such as missing intermediate milestones or gaining higher priority with a supplier, should be defined and tracked. Risk responses identified using this technique are often called contingency plans or fallback plans and include identified triggering events that set the plans in effect.

PMBoK(R) 5^th Edition, Page 346

Risk Reassessment

Control Risks often results in identification of new risks, reassessment of current risks, and the closing of risks that are outdated. Project risk reassessments should be regularly scheduled. The amount and detail of repetition that are appropriate depends on how the project progresses relative to its objectives.

PMBoK(R) 5^th Edition, Page 351

Risk Audits

Risk audits examine and document the effectiveness of risk responses in dealing with identified risks and their root causes, as well as the effectiveness of the risk management process. The project manager is responsible for ensuring that risk audits are performed at an appropriate frequency, as defined in the project’s risk management plan. Risk audits may be included during routine project review meetings, or the team may choose to hold separate risk audit meetings. The format for the audit and its objectives should be clearly defined before the audit is conducted.

PMBoK(R) 5^th Edition, Page 351

Variance and Trend Analysis

Many control processes employ variance analysis to compare the planned results to the actual results. For the purposes of controlling risks, trends in the project’s execution should be reviewed using performance information.

Earned value analysis and other methods of project variance and trend analysis may be used for monitoring overall project performance. Outcomes from these analyses may forecast potential deviation of the project at completion from cost and schedule targets. Deviation from the baseline plan may indicate the potential impact of threats or opportunities.

PMBoK(R) 5^th Edition, Page 352

Technical Performance Measurement

Technical performance measurement compares technical accomplishments during project execution to the schedule of technical achievement. It requires the definition of objective, quantifiable measures of technical performance, which can be used to compare actual results against targets. Such technical performance measures may include weight, transaction times, number of delivered defects, storage capacity, etc. Deviation, such as demonstrating more or less functionality than planned at a milestone, can help to forecast the degree of success in achieving the project’s scope.

PMBoK(R) 5^th Edition, Page 352

Reserve Analysis

Throughout execution of the project, some risks may occur with positive or negative impacts on budget or schedule contingency reserves. Reserve analysis compares the amount of the contingency reserves remaining to the amount of risk remaining at any time in the project in order to determine if the remaining reserve is adequate.

PMBoK(R) 5^th Edition, Page 352

Make-or-Buy Analysis

A make-or-buy analysis is a general management technique used to determine whether particular work can best be accomplished by the project team or should be purchased from outside sources. Sometimes a capability may exist within the project organization, but may be committed to working on other projects, in which case, the project may need to source such effort from outside the organization in order to meet its schedule commitments.

Budget constraints may influence make-or-buy decisions. If a buy decision is to be made, then a further decision of whether to purchase or lease is also made. A make-or-buy analysis should consider all related costs—both direct costs as well as indirect support costs. For example, the buy-side of the analysis includes both the actual out-of-pocket costs to purchase the product, as well as the indirect costs of supporting the purchasing process and purchased item.

Available contract types are also considered during the buy analysis. The risk sharing between the buyer and seller determines the suitable contract types, while the specific contract terms and conditions formalize the degree of risk being assumed by the buyer and seller. Some jurisdictions have other types of contracts defined, for example, contract types based on the obligations of the seller—not the customer—and the contract parties have the obligation to identify the appropriate type of contract as soon as the applicable law has been agreed upon.

PMBoK(R) 5^th Edition, Page 365

Market Research

Market research includes examination of industry and specific vendor capabilities. Procurement teams may leverage information gained at conferences, online reviews and a variety of sources to identify market capabilities. The team may also refine particular procurement objectives to leverage maturing technologies while balancing risks associated with the breadth of vendors who can provide the materials or services desired.

PMBoK(R) 5^th Edition, Page 365

Bidder Conferences

Bidder conferences (sometimes called contractor conferences, vendor conferences, and pre-bid conferences) are meetings between the buyer and all prospective sellers prior to submittal of a bid or proposal. They are used to ensure that all prospective sellers have a clear and common understanding of the procurement requirements), and that no bidders receive preferential treatment. To be fair, buyers should take great care to ensure that all prospective sellers hear every question from any individual prospective seller and every answer from the buyer.

Typically fairness is addressed by techniques such as collecting questions from bidders or arranging field visits in advance of the bidder conference. Responses to questions can be incorporated into the procurement documents as amendments.

PMBoK(R) 5^th Edition, Page 375

Proposal Evaluation Techniques

On complex procurements, where source selection will be made based on seller responses to previously defined weighted criteria, a formal evaluation review process will be defined by the buyer’s procurement policies. The evaluation committee will make their selection for approval by management prior to the award.

PMBoK(R) 5^th Edition, Page 375

Independent Estimates

For many procurement items, the procuring organization may elect to either prepare its own independent estimate, or have an estimate of costs prepared by an outside professional estimator, to serve as a benchmark on proposed responses. Significant differences in cost estimates can be an indication that the procurement statement of work was deficient, ambiguous, and/or that the prospective sellers either misunderstood or failed to respond fully to the procurement statement of work.

PMBoK(R) 5^th Edition, Page 376

Advertising

Existing lists of potential sellers often can be expanded by placing advertisements in general circulation publications such as selected newspapers or in specialty trade publications. Some organizations use online resources to communicate solicitations to the vendor community. Some government jurisdictions require public advertising of certain types of procurement items, and most government jurisdictions require public advertising or online posting of pending government contracts.

PMBoK(R) 5^th Edition, Page 376

Procurement Negotiations

Procurement negotiations clarify the structure, requirements, and other terms of the purchases so that mutual agreement can be reached prior to signing the contract. Final contract language reflects all agreements reached. Subjects covered should include responsibilities, authority to make changes, applicable terms and governing law, technical and business management approaches, proprietary rights, contract financing, technical solutions, overall schedule, payments, and price. Negotiations conclude with a contract document that can be executed by both buyer and seller.

For complex procurement items, contract negotiation can be an independent process with inputs (e.g., issues or an open items listing) and outputs (e.g., documented decisions) of its own. For simple procurement items, the terms and conditions of the contract can be previously set and nonnegotiable, and only need to be accepted by the seller.

The project manager may not be the lead negotiator on procurements. The project manager and other members of the project management team may be present during negotiations to provide assistance, and, if needed, to add clarification of the project’s technical, quality, and management requirements.

PMBoK(R) 5^th Edition, Page 377

Contract Change Control System

A contract change control system defines the process by which the procurement can be modified. It includes the paperwork, tracking systems, dispute resolution procedures, and approval levels necessary for authorizing changes. The contract change control system is integrated with the integrated change control system.