Earned Value Management Formulas

Earned Value Management

Earned value management (EVM) is a methodology that combines scope, schedule, and resource measurements to assess project performance and progress. It is a commonly used method of performance measurement for projects. It integrates the scope baseline with the cost baseline, along with the schedule baseline, to form the performance baseline, which helps the project management team assess and measure project performance and progress. It is a project management technique that requires the formation of an integrated baseline against which performance can be measured for the duration of the project. The principles of EVM can be applied to all projects in any industry. 

Earned Value Management Formulas

Dimension	Meaning	Formula	Interpretation
Schedule Variance (SV)	Schedule variance (SV) is a measure of schedule performance expressed as the difference between the earned value and the planned value	SV = EV – PV	-ve: Behind schedule 0: On schedule +ve: Ahead of schedule
Cost Vairance (CV)	Cost variance (CV) is the amount of budget deficit or surplus at a given point in time, expressed as the difference between earned value and the actual cost.	CV = EV - AC	-ve: under budget 0: On budget +ve: over budget
Schedule Performance Index (SPI)	The schedule performance index (SPI) is a measure of schedule efficiency expressed as the ratio of earned value to planned value. It measures how efficiently the project team is using its time.	SPI = EV / PV	<1: Behind schedule 0: On schedule >1: Ahead of Schedule
Cost Peformance Index (CPI)	The cost performance index (CPI) is a measure of the cost efficiency of budgeted resources, expressed as a ratio of earned value to actual cost. It is considered the most critical EVM metric and measures the cost efficiency for the work completed.	CPI = EV / AC	< 1: under cost 0: on cost >1: over cost
Estimate At Completion (EAC)	If the CPI is expected to be the same for the remainder of the project,	EAC = BAC/CPI
	If future work will be accomplished at the planned rate	EAC = AC + BAC – EV
	If both the CPI and SPI influence the remaining work	,EAC = AC + [(BAC – EV)/(CPI x SPI)]
To Complete Performance Index (TCPI)	The efficiency that must be maintained in order to complete on plan.	TCPI = (BAC – EV)/(BAC – AC)	< 1: easier to complete 0: same to complete >1: harder to complete
	The efficiency that must be maintained in order to complete the current EAC	TCPI = (BAC – EV)/(EAC – AC)

Tools and Techniques - Part 2

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.

PMBoK(R) 5^th Edition, Page 383

Procurement Performance Reviews

A procurement performance review is a structured review of the seller’s progress to deliver project scope and quality, within cost and on schedule, as compared to the contract. It can include a review of seller-prepared documentation and buyer inspections, as well as quality audits conducted during seller’s execution of the work.

The objective of a performance review is to identify performance successes or failures, progress with respect to the procurement statement of work, and contract noncompliance, which allow the buyer to quantify the seller’s demonstrated ability or inability to perform work. Such reviews may take place as a part of project status reviews, which would include key suppliers.

PMBoK(R) 5^th Edition, Page 383

Inspections and Audits

Inspections and audits required by the buyer and supported by the seller, as specified in the procurement contract, can be conducted during execution of the project to verify compliance in the seller’s work processes or deliverables. If authorized by contract, some inspection and audit teams can include buyer procurement personnel.

PMBoK(R) 5^th Edition, Page 383

Performance Reporting

Work performance data and reports supplied by sellers are evaluated against the agreement requirements. Work performance information from this evaluation is then reported as appropriate. Performance reporting provides management with information about how effectively the seller is achieving the contractual objectives.

PMBoK(R) 5^th Edition, Page 383

Payment Systems

Payments to the seller are typically processed by the accounts payable system of the buyer after certification of satisfactory work by an authorized person on the project team. All payments should be made and documented in strict accordance with the terms of the contract.

PMBoK(R) 5^th Edition, Page 383

Claims Administration

Contested changes and potential constructive changes are those requested changes where the buyer and seller cannot reach an agreement on compensation for the change or cannot agree that a change has occurred. These contested changes are variously called claims, disputes, or appeals. Claims are documented, processed, monitored, and managed throughout the contract life cycle, usually in accordance with the terms of the contract. If the parties themselves do not resolve a claim, it may have to be handled in accordance with alternative dispute resolution (ADR) typically following procedures established in the contract. Settlement of all claims and disputes through negotiation is the preferred method.

PMBoK(R) 5^th Edition, Page 384

Records Management System

A records management system is used by the project manager to manage contract and procurement documentation and records. It consists of a specific set of processes, related control functions, and automation tools that are consolidated and combined as part of the project management information system (Section 4.4.2.3). The system contains a retrievable archive of contract documents and correspondence.

PMBoK(R) 5^th Edition, Page 384

Procurement Audits

A procurement audit is a structured review of the procurement process originating from the Plan Procurement Management process through Control Procurements. The objective of a procurement audit is to identify successes and failures that warrant recognition in the preparation or administration of other procurement contracts on the project, or on other projects within the performing organization.

PMBoK(R) 5^th Edition, Page 388

Procurement Negotiations

In all procurement relationships, the final equitable settlement of all outstanding issues, claims, and disputes by negotiation is a primary goal. Whenever settlement cannot be achieved through direct negotiation, some form of alternative dispute resolution (ADR) including mediation or arbitration may be explored. When all else fails, litigation in the courts is the least desirable option.

PMBoK(R) 5^th Edition, Page 388

Stakeholder Analysis

Stakeholder analysis is a technique of systematically gathering and analyzing quantitative and qualitative information to determine whose interests should be taken into account throughout the project. It identifies the interests, expectations, and influence of the stakeholders and relates them to the purpose of the project. It also helps to identify stakeholder relationships (with the project and with other stakeholders) that can be leveraged to build coalitions and potential partnerships to enhance the project’s chance of success, along with stakeholder relationships that need to be influenced differently at different stages of the project or phase.

Stakeholder analysis generally follows the steps described below:

• Identify all potential project stakeholders and relevant information, such as their roles, departments, interests, knowledge, expectations, and influence levels. Key stakeholders are usually easy to identify. They include anyone in a decision-making or management role who is impacted by the project outcome, such as the sponsor, the project manager, and the primary customer. Identifying other stakeholders is usually done by interviewing identified stakeholders and expanding the list until all potential stakeholders are included.
• Analyze the potential impact or support each stakeholder could generate, and classify them so as to define an approach strategy. In large stakeholder communities, it is important to prioritize the stakeholders to ensure the efficient use of effort to communicate and manage their expectations. Assess how key stakeholders are likely to react or respond in various situations, in order to plan how to influence them to enhance their support and mitigate potential negative impacts.

There are multiple classification models used for stakeholders analysis, such as:

• Power/interest grid, grouping the stakeholders based on their level of authority (“power”) and their level or concern (“interest”) regarding the project outcomes;
• Power/influence grid, grouping the stakeholders based on their level of authority (“power”) and their active involvement (“influence”) in the project;
• Influence/impact grid, grouping the stakeholders based on their active involvement (“influence”) in the project and their ability to effect changes to the project’s planning or execution (“impact”); and
• Salience model, describing classes of stakeholders based on their power (ability to impose their will), urgency (need for immediate attention), and legitimacy (their involvement is appropriate).

PMBoK(R) 5^th Edition, Page 395 and 396

Analytical Techniques

The current engagement level of all stakeholders needs to be compared to the planned engagement levels required for successful project completion. Stakeholder engagement throughout the life cycle of the project is critical to project success.

The engagement level of the stakeholders can be classified as follows:

• Unaware. Unaware of project and potential impacts.
• Resistant. Aware of project and potential impacts and resistant to change.
• Neutral. Aware of project yet neither supportive nor resistant.
• Supportive. Aware of project and potential impacts and supportive to change.
• Leading. Aware of project and potential impacts and actively engaged in ensuring the project is a success.

PMBoK(R) 5^th Edition, Page 402

Interpersonal Skills

The project manager applies interpersonal skills to manage stakeholders’ expectations. For example:

• Building trust,
• Resolving conflict,
• Active listening, and
• Overcoming resistance to change.

PMBoK(R) 5^th Edition, Page 407

Management Skills

The project manager applies management skills to coordinate and harmonize the group toward accomplishing the project objectives. For example:

• Facilitate consensus toward project objectives,
• Influence people to support the project,
• Negotiate agreements to satisfy the project needs, and
• Modify organizational behavior to accept the project outcomes.

PMBoK(R) 5^th Edition, Page 408

Tools and Techniques - Part 1

Tools and Techniques - Part 1

Every process in PMBOK(R) uses certain Tools and Techniques to process the inputs into outputs. Please find below the detailed descriptions about each and every tools and techniques used by the 47 processes. I have presented them together, so you can easily prepare for the exam about which tool uses what diagram, what methods are used etc.

For Part 2, click here.

Facilitation Techniques

• Brainstorming
• Conflict Resolution
• Problem Solving
• Meeting Management

Project Management Information Systems

The project management information system, which is part of the environmental factors, provides access to tools, such as a scheduling tool, a work authorization system, a configuration management system, an information collection and distribution system, or interfaces to other online automated systems. Automated gathering and reporting on key performance indicators (KPI) can be part of this system.

Meetings

• Information Exchange
• Brainstorming
• Decision Making

Analytical Techniques

• Regression Analysis
• Grouping Methods
• Causal Analysis
• Root cause analysis
• Forecasting methods
• Failure mode and effect analysis
• Fault Tree analysis
• Trend analysis
• Earned Value Management
• Variance Analysis

Change Control Tools

In order to facilitate configuration and change management, manual or automated tools may be used. Tool selection should be based on the needs of the project stakeholders including organizational and environmental considerations and/or constraints.

Tools are used to manage the change requests and the resulting decisions. Additional considerations should be made for communication to assist the CCB members in their duties as well as distribute the decisions to the appropriate stakeholders. PMBoK(R) 5^th Edition, Page 99

Group Creativity Techniques

Several group activities can be organized to identify project and product requirements. Some of the group creativity techniques that can be used are:

• Brainstorming. A technique used to generate and collect multiple ideas related to project and product requirements. Although brainstorming by itself does not include voting or prioritization, it is often used with other group creativity techniques that do.
• Nominal group technique. A technique that enhances brainstorming with a voting process used to rank the most useful ideas for further brainstorming or for prioritization.
• Idea/mind mapping. A technique in which ideas created through individual brainstorming sessions are consolidated into a single map to reflect commonality and differences in understanding, and generate new ideas.
• Affinity diagram. A technique that allows large numbers of ideas to be classified into groups for review and analysis.
• Multicriteria decision analysis. A technique that utilizes a decision matrix to provide a systematic analytical approach for establishing criteria, such as risk levels, uncertainty, and valuation, to evaluate and rank many ideas. PMBoK(R) 5^th Edition, Page 115

Group Decision-Making Techniques

A group decision-making technique is an assessment process having multiple alternatives with an expected outcome in the form of future actions. These techniques can be used to generate, classify, and prioritize product requirements.

There are various methods of reaching a group decision, such as:

• Unanimity. A decision that is reached whereby everyone agrees on a single course of action. One way to reach unanimity is the Delphi technique, in which a selected group of experts answers questionnaires and provides feedback regarding the responses from each round of requirements gathering. The responses are only available to the facilitator to maintain anonymity.
• Majority. A decision that is reached with support obtained from more than 50 % of the members of the group. Having a group size with an uneven number of participants can ensure that a decision will be reached, rather than resulting in a tie.
• Plurality. A decision that is reached whereby the largest block in a group decides, even if a majority is not achieved. This method is generally used when the number of options nominated is more than two.
• Dictatorship. In this method, one individual makes the decision for the group.
  PMBoK(R) 5^th Edition, Page 115

Product Analysis

For projects that have a product as a deliverable, as opposed to a service or result, product analysis can be an effective tool. Each application area has one or more generally accepted methods for translating high-level product descriptions into tangible deliverables. Product analysis includes techniques such as product breakdown, systems analysis, requirements analysis, systems engineering, value engineering, and value analysis.

PMBoK(R) 5^th Edition, Page 122

Alternatives Generation

Alternatives generation is a technique used to develop as many potential options as possible in order to identify different approaches to execute and perform the work of the project. A variety of general management techniques can be used, such as brainstorming, lateral thinking, analysis of alternatives, etc.

PMBoK(R) 5^th Edition, Page 123

Decomposition

Decomposition is a technique used for dividing and subdividing the project scope and project deliverables into smaller, more manageable parts. The work package is the work defined at the lowest level of the WBS for which cost and duration can be estimated and managed. The level of decomposition is often guided by the degree of control needed to effectively manage the project. The level of detail for work packages will vary with the size and complexity of the project.

PMBoK(R) 5^th Edition, Page 128

100% Rule

The WBS represents all product and project work, including the project management work. The total of the work at the lowest levels should roll up to the higher levels so that nothing is left out and no extra work is performed. This is sometimes called the 100 percent rule.

PMBoK(R) 5^th Edition, Page 131

Inspection

Inspection includes activities such as measuring, examining, and validating to determine whether work and deliverables meet requirements and product acceptance criteria. Inspections are sometimes called reviews, product reviews, audits, and walkthroughs. In some application areas, these different terms have unique and specific meanings.

PMBoK(R) 5^th Edition, Page 135

Variance Analysis

Variance analysis is a technique for determining the cause and degree of difference between the baseline and actual performance. Project performance measurements are used to assess the magnitude of variation from the original scope baseline.

PMBoK(R) 5^th Edition, Page 139

Rolling Wave Planning

Rolling wave planning is an iterative planning technique in which the work to be accomplished in the near term is planned in detail, while the work in the future is planned at a higher level. It is a form of progressive elaboration. Therefore, work can exist at various levels of detail depending on where it is in the project life cycle. During early strategic planning, when information is less defined, work packages may be decomposed to the known level of detail. As more is known about the upcoming events in the near term, work packages can be decomposed into activities.

PMBoK(R) 5^th Edition, Page 152

Precedence Diagramming Method

The precedence diagramming method (PDM) is a technique used for constructing a schedule model in which activities are represented by nodes and are graphically linked by one or more logical relationships to show the sequence in which the activities are to be performed. Activity-on-node (AON) is one method of representing a precedence diagram. This is the method used by most project management software packages.

PDM includes four types of dependencies or logical relationships. A predecessor activity is an activity that logically comes before a dependent activity in a schedule. A successor activity is a dependent activity that logically comes after another activity in a schedule. These relationships are defined below:

• Finish-to-start (FS). A logical relationship in which a successor activity cannot start until a predecessor activity has finished. Example: The awards ceremony (successor) cannot start until the race (predecessor) has finished.
• Finish-to-finish (FF). A logical relationship in which a successor activity cannot finish until a predecessor activity has finished. Example: Writing a document (predecessor) is required to finish before editing the document (successor) can finish.
• Start-to-start (SS). A logical relationship in which a successor activity cannot start until a predecessor activity has started. Example: Level concrete (successor) cannot begin until pour foundation (predecessor) begins.
• Start-to-finish (SF). A logical relationship in which a successor activity cannot finish until a predecessor activity has started. Example: The first security guard shift (successor) cannot finish until the second security guard shift (predecessor) starts.

PMBoK(R) 5^th Edition, Page 156

Dependency Determination

Dependencies may be characterized by the following attributes: mandatory or discretionary, internal or external, as described below. Dependency has four attributes, but two can be applicable at the same time in following ways: mandatory external dependencies, mandatory internal dependencies, discretionary external dependencies, or discretionary internal dependencies.

• Mandatory dependencies. Mandatory dependencies are those that are legally or contractually required or inherent in the nature of the work. Mandatory dependencies often involve physical limitations, such as on a construction project, where it is impossible to erect the superstructure until after the foundation has been built, or on an electronics project, where a prototype has to be built before it can be tested. Mandatory dependencies are also sometimes referred to as hard logic or hard dependencies. Technical dependencies may not be mandatory. The project team determines which dependencies are mandatory during the process of sequencing the activities. Mandatory dependencies should not be confused with assigning schedule constraints in the scheduling tool.
• Discretionary dependencies. Discretionary dependencies are sometimes referred to as preferred logic, preferential logic, or soft logic. Discretionary dependencies are established based on knowledge of best practices within a particular application area or some unusual aspect of the project where a specific sequence is desired, even though there may be other acceptable sequences. Discretionary dependencies should be fully documented since they can create arbitrary total float values and can limit later scheduling options. When fast tracking techniques are employed, these discretionary dependencies should be reviewed and considered for modification or removal. The project team determines which dependencies are discretionary during the process of sequencing the activities.
• External dependencies. External dependencies involve a relationship between project activities and non-project activities. These dependencies are usually outside the project team’s control. For example, the testing activity in a software project may be dependent on the delivery of hardware from an external source, or governmental environmental hearings may need to be held before site preparation can begin on a construction project. The project management team determines which dependencies are external during the process of sequencing the activities.
• Internal dependencies. Internal dependencies involve a precedence relationship between project activities and are generally inside the project team’s control. For example, if the team cannot test a machine until they assemble it, this is an internal mandatory dependency. The project management team determines which dependencies are internal during the process of sequencing the activities.

PMBoK(R) 5^th Edition, Page 158

Leads and Lags

• A lead is the amount of time whereby a successor activity can be advanced with respect to a predecessor activity.
• A lag is the amount of time whereby a successor activity will be delayed with respect to a predecessor activity.

PMBoK(R) 5^th Edition, Page 158 and 159

Published Estimating Data

Several organizations routinely publish updated production rates and unit costs of resources for an extensive array of labor trades, material, and equipment for different countries and geographical locations within countries.

PMBoK(R) 5^th Edition, Page 164

Bottom-Up Estimating

Bottom-up estimating is a method of estimating project duration or cost by aggregating the estimates of the lower-level components of the WBS. When an activity cannot be estimated with a reasonable degree of confidence, the work within the activity is decomposed into more detail. The resource needs are estimated. These estimates are then aggregated into a total quantity for each of the activity’s resources. Activities may or may not have dependencies between them that can affect the application and use of resources. If there are dependencies, this pattern of resource usage is reflected and documented in the estimated requirements of the activity.

PMBoK(R) 5^th Edition, Page 164

Analogous Estimating

Analogous estimating is a technique for estimating the duration or cost of an activity or a project using historical data from a similar activity or project. Analogous estimating uses parameters from a previous, similar project, such as duration, budget, size, weight, and complexity, as the basis for estimating the same parameter or measure for a future project. When estimating durations, this technique relies on the actual duration of previous, similar projects as the basis for estimating the duration of the current project. It is a gross value estimating approach, sometimes adjusted for known differences in project complexity. Analogous duration estimating is frequently used to estimate project duration when there is a limited amount of detailed information about the project.

Analogous estimating is generally less costly and less time consuming than other techniques, but it is also less accurate. Analogous duration estimates can be applied to a total project or to segments of a project and may be used in conjunction with other estimating methods. Analogous estimating is most reliable when the previous activities are similar in fact and not just in appearance, and the project team members preparing the estimates have the needed expertise.

PMBoK(R) 5^th Edition, Page 169 and 170

Parametric Estimating

Parametric estimating is an estimating technique in which an algorithm is used to calculate cost or duration based on historical data and project parameters. Parametric estimating uses a statistical relationship between historical data and other variables (e.g., square footage in construction) to calculate an estimate for activity parameters, such as cost, budget, and duration.

Activity durations can be quantitatively determined by multiplying the quantity of work to be performed by labor hours per unit of work. For example, activity duration on a design project is estimated by the number of drawings multiplied by the number of labor hours per drawing, or on a cable installation, the meters of cable multiplied by the number of labor hours per meter. For example, if the assigned resource is capable of installing 25 meters of cable per hour, the duration required to install 1,000 meters is 40 hours. (1,000 meters divided by 25 meters per hour).

This technique can produce higher levels of accuracy depending upon the sophistication and underlying data built into the model. Parametric time estimates can be applied to a total project or to segments of a project, in conjunction with other estimating methods.

PMBoK(R) 5^th Edition, Page 170

Three-Point Estimating

The accuracy of single-point activity duration estimates may be improved by considering estimation uncertainty and risk. This concept originated with the program evaluation and review technique (PERT). PERT uses three estimates to define an approximate range for an activity’s duration:

• Most likely (tM). This estimate is based on the duration of the activity, given the resources likely to be assigned, their productivity, realistic expectations of availability for the activity, dependencies on other participants, and interruptions.
• Optimistic (tO). The activity duration based on analysis of the best-case scenario for the activity.
• Pessimistic (tP). The activity duration based on analysis of the worst-case scenario for the activity.

Depending on the assumed distribution of values within the range of the three estimates the expected duration, tE, can be calculated using a formula. Two commonly used formulas are triangular and beta distributions. The formulas are:

• Triangular Distribution. tE = (tO + tM + tP) / 3
• Beta Distribution (from the traditional PERT technique). tE = (tO + 4tM + tP) / 6

Duration estimates based on three points with an assumed distribution provide an expected duration and clarify the range of uncertainty around the expected duration.

PMBoK(R) 5^th Edition, Page 170 and 171

Reserve Analysis

Duration estimates may include contingency reserves, sometimes referred to as time reserves or buffers, into the project schedule to account for schedule uncertainty. Contingency reserves are the estimated duration within the schedule baseline, which is allocated for identified risks that are accepted and for which contingent or mitigation responses are developed. Contingency reserves are associated with the “known-unknowns,” which may be estimated to account for this unknown amount of rework. The contingency reserve may be a percentage of the estimated activity duration, a fixed number of work periods, or may be developed by using quantitative analysis methods such as Monte Carlo simulation. Contingency reserves may be separated from the individual activities and aggregated into buffers.

Management reserves are intended to address the “unknown-unknowns” that can affect a project. Management reserve is not included in the schedule baseline, but it is part of the overall project duration requirements. Depending on contract terms, use of management reserves may require a change to the schedule baseline.

PMBoK(R) 5^th Edition, Page 171

Schedule Network Analysis

Schedule network analysis is a technique that generates the project schedule model. It employs various analytical techniques, such as critical path method, critical chain method, what-if analysis, and resource optimization techniques to calculate the early and late start and finish dates for the uncompleted portions of project activities.

Some network paths may have points of path convergence or path divergence that can be identified and used in schedule compression analysis or other analyses.

PMBoK(R) 5^th Edition, Page 176

Critical Path Method

The critical path method, which is a method used to estimate the minimum project duration and determine the amount of scheduling flexibility on the logical network paths within the schedule model. This schedule network analysis technique calculates the early start, early finish, late start, and late finish dates for all activities without regard for any resource limitations by performing a forward and backward pass analysis through the schedule network. The critical path is the sequence of activities that represents the longest path through a project, which determines the shortest possible project duration. The resulting early and late start and finish dates are not necessarily the project schedule, rather they indicate the time periods within which the activity could be executed, using the parameters entered in the schedule model for activity durations, logical relationships, leads, lags, and other known constraints. The critical path method is used to calculate the amount of scheduling flexibility on the logical network paths within the schedule model.

PMBoK(R) 5^th Edition, Page 176

Critical Chain Method

The critical chain method (CCM) is a schedule method that allows the project team to place buffers on any project schedule path to account for limited resources and project uncertainties. It is developed from the critical path method approach and considers the effects of resource allocation, resource optimization, resource leveling, and activity duration uncertainty on the critical path determined using the critical path method. To do so, the critical chain method introduces the concept of buffers and buffer management. The critical chain method uses activities with durations that do not include safety margins, logical relationships, and resource availability with statistically determined buffers composed of the aggregated safety margins of activities at specified points on the project schedule path to account for limited resources and project uncertainties. The resource-constrained critical path is known as the critical chain.

The critical chain method adds duration buffers that are non-work schedule activities to manage uncertainty.

One buffer, placed at the end of the critical chain, is known as the project buffer and protects the target finish date from slippage along the critical chain. Additional buffers, known as feeding buffers, are placed at each point where a chain of dependent activities that are not on the critical chain feeds into the critical chain. Feeding buffers thus protect the critical chain from slippage along the feeding chains. The size of each buffer should account for the uncertainty in the duration of the chain of dependent activities leading up to that buffer. Once the buffer schedule activities are determined, the planned activities are scheduled to their latest possible planned start and finish dates. Consequently, instead of managing the total float of network paths, the critical chain method focuses on managing the remaining buffer durations against the remaining durations of chains of activities.

PMBoK(R) 5^th Edition, Page 178

Resource Optimization Techniques

Examples of resource optimization techniques that can be used to adjust the schedule model due to demand

and supply of resources include, but are not limited to:

• Resource leveling. A technique in which start and finish dates are adjusted based on resource constraints with the goal of balancing demand for resources with the available supply. Resource leveling can be used when shared or critically required resources are only available at certain times, or in limited quantities, or over-allocated, such as when a resource has been assigned to two or more activities during the same time period, or to keep resource usage at a constant level. Resource leveling can often cause the original critical path to change, usually to increase.
• Resource Smoothing. A technique that adjusts the activities of a schedule model such that the requirements for resources on the project do not exceed certain predefined resource limits. In resource smoothing, as opposed to resource leveling, the project’s critical path is not changed and the completion date may not be delayed. In other words, activities may only be delayed within their free and total float. Thus resource smoothing may not be able to optimize all resources.

PMBoK(R) 5^th Edition, Page 179 and 180

Modeling Techniques

Examples of modeling techniques include, but are not limited to:

• What-If Scenario Analysis. What-if scenario analysis is the process of evaluating scenarios in order to predict their effect, positively or negatively, on project objectives. This is an analysis of the question, “What if the situation represented by scenario ‘X’ happens?” A schedule network analysis is performed using the schedule to compute the different scenarios, such as delaying a major component delivery, extending specific engineering durations, or introducing external factors, such as a strike or a change in the permitting process. The outcome of the what-if scenario analysis can be used to assess the feasibility of the project schedule under adverse conditions, and in preparing contingency and response plans to overcome or mitigate the impact of unexpected situations.
• Simulation. Simulation involves calculating multiple project durations with different sets of activity assumptions, usually using probability distributions constructed from the three-point estimates to account for uncertainty. The most common simulation technique is Monte Carlo analysis, in which a distribution of possible activity durations is defined for each activity and used to calculate a distribution of possible outcomes for the total project.

PMBoK(R) 5^th Edition, Page 180

Schedule Compression

Schedule compression techniques are used to shorten the schedule duration without reducing the project scope, in order to meet schedule constraints, imposed dates, or other schedule objectives. Schedule compression techniques include, but are not limited to:

• Crashing. A technique used to shorten the schedule duration for the least incremental cost by adding resources. Examples of crashing include approving overtime, bringing in additional resources, or paying to expedite delivery to activities on the critical path. Crashing works only for activities on the critical path where additional resources will shorten the activity’s duration. Crashing does not always produce a viable alternative and may result in increased risk and/or cost.
• Fast tracking. A schedule compression technique in which activities or phases normally done in sequence are performed in parallel for at least a portion of their duration. An example is constructing the foundation for a building before completing all of the architectural drawings. Fast tracking may result in rework and increased risk. Fast tracking only works if activities can be overlapped to shorten the project duration.

PMBoK(R) 5^th Edition, Page 181

Scheduling Tool

Automated scheduling tools contain the schedule model and expedite the scheduling process by generating start and finish dates based on the inputs of activities, network diagrams, resources and activity durations using schedule network analysis. A scheduling tool can be used in conjunction with other project management software applications as well as manual methods.

PMBoK(R) 5^th Edition, Page 181

Performance Reviews

Performance reviews measure, compare, and analyze schedule performance such as actual start and finish dates, percent complete, and remaining duration for work in progress. Various techniques may be used, among them:

• Trend analysis. Trend analysis examines project performance over time to determine whether performance is improving or deteriorating. Graphical analysis techniques are valuable for understanding performance to date and for comparison to future performance goals in the form of completion dates.
• Critical path method. Comparing the progress along the critical path can help determine schedule status. The variance on the critical path will have a direct impact on the project end date. Evaluating the progress of activities on near critical paths can identify schedule risk.
• Critical chain method . Comparing the amount of buffer remaining to the amount of buffer needed to protect the delivery date can help determine schedule status. The difference between the buffer needed and the buffer remaining can determine whether corrective action is appropriate.
• Earned value management . Schedule performance measurements such as schedule variance (SV) and schedule performance index (SPI), are used to assess the magnitude of variation to the original schedule baseline. The total float and early finish variances are also essential planning components to evaluate project time performance. Important aspects of schedule control include determining the cause and degree of variance relative to the schedule baseline, estimating the implications of those variances for future work to completion, and deciding whether corrective or preventive action is required. For example, a major delay on any activity not on the critical path may have little effect on the overall project schedule, while a much shorter delay on a critical or near-critical activity may require immediate action. For projects not using earned value management, similar variance analysis can be performed by comparing planned activity start or finish dates against actual start or finish dates to identify variances between the schedule baseline and actual project performance. Further analysis can be performed to determine the cause and degree of variance relative to the schedule baseline and any corrective or preventative actions needed

PMBoK(R) 5^th Edition, Page 189

Vendor Bid Analysis

Cost estimating methods may include analysis of what the project should cost, based on the responsive bids from qualified vendors. When projects are awarded to a vendor under competitive processes, additional cost estimating work may be required of the project team to examine the price of individual deliverables and to derive a cost that supports the final total project cost.

PMBoK(R) 5^th Edition, Page 207

Cost Aggregation

Cost estimates are aggregated by work packages in accordance with the WBS. The work package cost estimates are then aggregated for the higher component levels of the WBS (such as control accounts) and ultimately for the entire project.

PMBoK(R) 5^th Edition, Page 211

Historical Relationships

Any historical relationships that result in parametric estimates or analogous estimates involve the use of project characteristics (parameters) to develop mathematical models to predict total project costs. Such models may be simple (e.g., residential home construction is based on a certain cost per square foot of space) or complex (e.g., one model of software development costing uses multiple separate adjustment factors, each of which has numerous points within it).

Both the cost and accuracy of analogous and parametric models can vary widely. They are most likely to be

reliable when:

• Historical information used to develop the model is accurate,
• Parameters used in the model are readily quantifiable, and
• Models are scalable, such that they work for large projects, small projects, and phases of a project.

PMBoK(R) 5^th Edition, Page 212

Funding Limit Reconciliation

The expenditure of funds should be reconciled with any funding limits on the commitment of funds for the project. A variance between the funding limits and the planned expenditures will sometimes necessitate the rescheduling of work to level out the rate of expenditures. This is accomplished by placing imposed date constraints for work into the project schedule.

PMBoK(R) 5^th Edition, Page 212

Earned Value Management

Earned value management (EVM) is a methodology that combines scope, schedule, and resource measurements to assess project performance and progress. It is a commonly used method of performance measurement for projects. It integrates the scope baseline with the cost baseline, along with the schedule baseline, to form the performance baseline, which helps the project management team assess and measure project performance and progress. It is a project management technique that requires the formation of an integrated baseline against which performance can be measured for the duration of the project. The principles of EVM can be applied to all projects in any industry. EVM develops and monitors three key dimensions for each work package and control account:

• Planned value. Planned value (PV) is the authorized budget assigned to scheduled work. It is the authorized budget planned for the work to be accomplished for an activity or work breakdown structure component, not including management reserve. This budget is allocated by phase over the life of the project, but at a given moment, planned value defines the physical work that should have been accomplished. The total of the PV is sometimes referred to as the performance measurement baseline (PMB). The total planned value for the project is also known as budget at completion (BAC).
• Earned value. Earned value (EV) is a measure of work performed expressed in terms of the budget authorized for that work. It is the budget associated with the authorized work that has been completed. The EV being measured needs to be related to the PMB, and the EV measured cannot be greater than the authorized PV budget for a component. The EV is often used to calculate the percent complete of a project. Progress measurement criteria should be established for each WBS component to measure work in progress. Project managers monitor EV, both incrementally to determine current status and cumulatively to determine the long-term performance trends.
• Actual cost. Actual cost (AC) is the realized cost incurred for the work performed on an activity during a specific time period. It is the total cost incurred in accomplishing the work that the EV measured. The AC needs to correspond in definition to what was budgeted in the PV and measured in the EV (e.g., direct hours only, direct costs only, or all costs including indirect costs). The AC will have no upper limit; whatever is spent to achieve the EV will be measured.

Variances from the approved baseline will also be monitored:

• Schedule variance. Schedule variance (SV) is a measure of schedule performance expressed as the difference between the earned value and the planned value. It is the amount by which the project is ahead or behind the planned delivery date, at a given point in time. It is a measure of schedule performance on a project. It is equal to the earned value (EV) minus the planned value (PV). The EVM schedule variance is a useful metric in that it can indicate when a project is falling behind or is ahead of its baseline schedule. The EVM schedule variance will ultimately equal zero when the project is completed because all of the planned values will have been earned. Schedule variance is best used in conjunction with critical path methodology (CPM) scheduling and risk management. Equation: SV = EV – PV
• Cost variance. Cost variance (CV) is the amount of budget deficit or surplus at a given point in time, expressed as the difference between earned value and the actual cost. It is a measure of cost performance on a project. It is equal to the earned value (EV) minus the actual cost (AC). The cost variance at the end of the project will be the difference between the budget at completion (BAC) and the actual amount spent. The CV is particularly critical because it indicates the relationship of physical performance to the costs spent. Negative CV is often difficult for the project to recover. Equation: CV= EV − AC.

The SV and CV values can be converted to efficiency indicators to reflect the cost and schedule performance of any project for comparison against all other projects or within a portfolio of projects. The variances are useful for determining project status.

• Schedule performance index. The schedule performance index (SPI) is a measure of schedule efficiency expressed as the ratio of earned value to planned value. It measures how efficiently the project team is using its time. It is sometimes used in conjunction with the cost performance index (CPI) to forecast the final project completion estimates. An SPI value less than 1.0 indicates less work was completed than was planned. An SPI greater than 1.0 indicates that more work was completed than was planned. Since the SPI measures all project work, the performance on the critical path also needs to be analyzed to determine whether the project will finish ahead of or behind its planned finish date. The SPI is equal to the ratio of the EV to the PV. Equation: SPI = EV/PV
• Cost performance index. The cost performance index (CPI) is a measure of the cost efficiency of budgeted resources, expressed as a ratio of earned value to actual cost. It is considered the most critical EVM metric and measures the cost efficiency for the work completed. A CPI value of less than 1.0 indicates a cost overrun for work completed. A CPI value greater than 1.0 indicates a cost underrun of performance to date. The CPI is equal to the ratio of the EV to the AC. The indices are useful for determining project status and providing a basis for estimating project cost and schedule outcome. Equation: CPI = EV/AC

The three parameters of planned value, earned value, and actual cost can be monitored and reported on both a period-by-period basis (typically weekly or monthly) and on a cumulative basis.

PMBoK(R) 5^th Edition, Page 219

Forecasting

As the project progresses, the project team may develop a forecast for the estimate at completion (EAC) that may differ from the budget at completion (BAC) based on the project performance. If it becomes obvious that the BAC is no longer viable, the project manager should consider the forecasted EAC. Forecasting the EAC involves making projections of conditions and events in the project’s future based on current performance information and other knowledge available at the time of the forecast. Forecasts are generated, updated, and reissued based on work performance data that is provided as the project is executed. The work performance information covers the project’s past performance and any information that could impact the project in the future. EACs are typically based on the actual costs incurred for work completed, plus an estimate to complete (ETC) the remaining work. It is incumbent on the project team to predict what it may encounter to perform the ETC, based on its experience to date. The EVM method works well in conjunction with manual forecasts of the required EAC costs. The most common EAC forecasting approach is a manual, bottom-up summation by the project manager and project team.

The project manager’s bottom-up EAC method builds upon the actual costs and experience incurred for the work completed, and requires a new estimate to complete the remaining project work. 
Equation: EAC = AC + Bottom-up ETC.

The project manager’s manual EAC is quickly compared with a range of calculated EACs representing various risk scenarios. When calculating EAC values, the cumulative CPI and SPI values are typically used. While EVM data quickly provide many statistical EACs, only three of the more common methods are described as follows:

EAC forecast for ETC work performed at the budgeted rate. This EAC method accepts the actual project performance to date (whether favorable or unfavorable) as represented by the actual costs, and predicts that all future ETC work will be accomplished at the budgeted rate. When actual performance is unfavorable, the assumption that future performance will improve should be accepted only when supported by project risk analysis. 
Equation: EAC = AC + (BAC – EV)

• EAC forecast for ETC work performed at the present CPI. This method assumes what the project has experienced to date can be expected to continue in the future. The ETC work is assumed to be performed at the same cumulative cost performance index (CPI) as that incurred by the project to date. Equation: EAC = BAC / CPI
• EAC forecast for ETC work considering both SPI and CPI factors. In this forecast, the ETC work will be performed at an efficiency rate that considers both the cost and schedule performance indices. This method is most useful when the project schedule is a factor impacting the ETC effort. Variations of this method weight the CPI and SPI at different values (e.g., 80/20, 50/50, or some other ratio) according to the project manager’s judgment.Equation: EAC = AC + [(BAC – EV) / (CPI × SPI)]

Each of these approaches is applicable for any given project and will provide the project management team with an “early warning” signal if the EAC forecasts are not within acceptable tolerances.

PMBoK(R) 5^th Edition, Page 221

To-Complete Performance Index (TCPI)

The to-complete performance index (TCPI) is a measure of the cost performance that is required to be achieved with the remaining resources in order to meet a specified management goal, expressed as the ratio of the cost to finish the outstanding work to the remaining budget. TCPI is the calculated cost performance index that is achieved on the remaining work to meet a specified management goal, such as the BAC or the EAC. If it becomes obvious that the BAC is no longer viable, the project manager should consider the forecasted EAC. Once approved, the EAC may replace the BAC in the TCPI calculation. The equation for the TCPI based on the BAC: (BAC – EV) / (BAC – AC).

If the cumulative CPI falls below the baseline, all future work of the project will need to be performed immediately in the range of the TCPI (BAC) to stay within the authorized BAC. Whether this level of performance is achievable is a judgment call based on a number of considerations, including risk, schedule, and technical performance. This level of performance is displayed as the TCPI (EAC) line. The equation for the TCPI based on the 
EAC: (BAC – EV) / (EAC – AC).

PMBoK(R) 5^th Edition, Page 221

Cost-Benefit Analysis

The primary benefits of meeting quality requirements include less rework, higher productivity, lower costs, increased stakeholder satisfaction, and increased profitability. A cost-benefit analysis for each quality activity compares the cost of the quality step to the expected benefit.

PMBoK(R) 5^th Edition, Page 235

Seven Basic Quality Tools

The seven basic quality tools, also known in the industry as 7QC Tools, are used within the context of the PDCA Cycle to solve quality-related problems. The seven basic quality tools are:

• Cause-and-effect diagrams, which are also known as fishbone diagrams or as Ishikawa diagrams. The problem statement placed at the head of the fishbone is used as a starting point to trace the problem’s source back to its actionable root cause. The problem statement typically describes the problem as a gap to be closed or as an objective to be achieved. The causes are found by looking at the problem statement and asking “why” until the actionable root cause has been identified or until the reasonable possibilities on each fishbone have been exhausted. Fishbone diagrams often prove useful in linking the undesirable effects seen as special variation to the assignable cause upon which project teams should implement corrective actions to eliminate the special variation detected in a control chart.
• Flowcharts, which are also referred to as process maps because they display the sequence of steps and the branching possibilities that exist for a process that transforms one or more inputs into one or more outputs. Flowcharts show the activities, decision points, branching loops, parallel paths, and the overall order of processing by mapping the operational details of procedures that exist within a horizontal value chain of a SIPOC model. Flowcharts may prove useful in understanding and estimating the cost of quality in a process. This is obtained by using the workflow branching logic and associated relative frequencies to estimate expected monetary value for the conformance and nonconformance work required to deliver the expected conforming output.
• Checksheets, which are also known as tally sheets and may be used as a checklist when gathering data. Checksheets are used to organize facts in a manner that will facilitate the effective collection of useful data about a potential quality problem. They are especially useful for gathering attributes data while performing inspections to identify defects. For example, data about the frequencies or consequences of defects collected in checksheets are often displayed using Pareto diagrams.
• Pareto diagrams, exist as a special form of vertical bar chart and are used to identify the vital few sources that are responsible for causing most of a problem’s effects. The categories shown on the horizontal axis exist as a valid probability distribution that accounts for 100% of the possible observations. The relative frequencies of each specified cause listed on the horizontal axis decrease in magnitude until the default source named “other” accounts for any nonspecified causes. Typically, the Pareto diagram will be organized into categories that measure either frequencies or consequences.
• Histograms, are a special form of bar chart and are used to describe the central tendency, dispersion, and shape of a statistical distribution. Unlike the control chart, the histogram does not consider the influence of time on the variation that exists within a distribution.
• Control charts, are used to determine whether or not a process is stable or has predictable performance. Upper and lower specification limits are based on requirements of the agreement. They reflect the maximum and minimum values allowed. There may be penalties associated with exceeding the specification limits. Upper and lower control limits are different from specification limits. The control limits are determined using standard statistical calculations and principles to ultimately establish the natural capability for a stable process. The project manager and appropriate stakeholders may use the statistically calculated control limits to identify the points at which corrective action will be taken to prevent unnatural performance. The corrective action typically seeks to maintain the natural stability of a stable and capable process. For repetitive processes, the control limits are generally set at ―3 s around a process mean that has been set at 0 s. A process is considered out of control when: (1) a data point exceeds a control limit; (2) seven consecutive plot points are above the mean; or (3) seven consecutive plot points are below the mean. Control charts can be used to monitor various types of output variables. Although used most frequently to track repetitive activities required for producing manufactured lots, control charts may also be used to monitor cost and schedule variances, volume, and frequency of scope changes, or other management results to help determine if the project management processes are in control.
• Scatter diagrams, plot ordered pairs (X, Y) and are sometimes called correlation charts because they seek to explain a change in the dependent variable, Y, in relationship to a change observed in the corresponding independent variable, X. The direction of correlation may be proportional (positive correlation), inverse (negative correlation), or a pattern of correlation may not exist (zero correlation). If correlation can be established, a regression line can be calculated and used to estimate how a change to the independent variable will influence the value of the dependent variable.

PMBoK(R) 5^th Edition, Page 238

Design of Experiments

Design of experiments (DOE) is a statistical method for identifying which factors may influence specific variables of a product or process under development or in production. DOE may be used during the Plan Quality Management process to determine the number and type of tests and their impact on cost of quality.

PMBoK(R) 5^th Edition, Page 239

Statistical Sampling

Statistical sampling involves choosing part of a population of interest for inspection (for example, selecting ten engineering drawings at random from a list of seventy-five). Sample frequency and sizes should be determined during the Plan Quality Management process so the cost of quality will include the number of tests, expected scrap, etc. There is a substantial body of knowledge on statistical sampling. In some application areas, it may be necessary for the project management team to be familiar with a variety of sampling techniques to assure the sample selected represents the population of interest.

PMBoK(R) 5^th Edition, Page 240

Additional Quality Planning Tools

Other quality planning tools are used to define the quality requirements and to plan effective quality management activities. These include, but are not limited to:

• Brainstorming. This technique is used to generate ideas.
• Force field analysis. These are diagrams of the forces for and against change.
• Nominal group technique. This technique is used to allow ideas to be brainstormed in small groups and then reviewed by a larger group.
• Quality management and control tools. These tools are used to link and sequence the activities identified.

PMBoK(R) 5^th Edition, Page 240

Quality Management and Control Tools

The Perform Quality Assurance process uses the tools and techniques of the Plan Quality Management and Control Quality processes. In addition, other tools that are available include:

• Affinity diagrams. The affinity diagram is similar to mind-mapping techniques in that they are used to generate ideas that can be linked to form organized patterns of thought about a problem. In project management, the creation of the WBS may be enhanced by using the affinity diagram to give structure to the decomposition of scope.
• Process decision program charts (PDPC). Used to understand a goal in relation to the steps for getting to the goal. The PDPC is useful as a method for contingency planning because it aids teams in anticipating intermediate steps that could derail achievement of the goal.
• Interrelationship digraphs. An adaptation of relationship diagrams. The interrelationship digraphs provide a process for creative problem solving in moderately complex scenarios that possess intertwined logical relationships for up to 50 relevant items. The interrelationship digraph may be developed from data generated in other tools such as the affinity diagram, the tree diagram, or the fishbone diagram.
• Tree diagrams. Also known as systematic diagrams and may be used to represent decomposition hierarchies such as the WBS, RBS (risk breakdown structure), and OBS (organizational breakdown structure). In project management, tree diagrams are useful in visualizing the parent-to-child relationships in any decomposition hierarchy that uses a systematic set of rules that define a nesting relationship. Tree diagrams can be depicted horizontally (such as a risk breakdown structure) or vertically (such as a team hierarchy or OBS). Because tree diagrams permit the creation of nested branches that terminate into a single decision point, they are useful as decision trees for establishing an expected value for a limited number of dependent relationships that have been diagramed systematically.
• Prioritization matrices. Identify the key issues and the suitable alternatives to be prioritized as a set of decisions for implementation. Criteria are prioritized and weighted before being applied to all available alternatives to obtain a mathematical score that ranks the options.
• Activity network diagrams. Previously known as arrow diagrams. They include both the AOA (Activity on Arrow) and, most commonly used, AON (Activity on Node) formats of a network diagram. Activity network diagrams are used with project scheduling methodologies such as program evaluation and review technique (PERT), critical path method (CPM), and precedence diagramming method (PDM).
• Matrix diagrams. A quality management and control tool used to perform data analysis within the organizational structure created in the matrix. The matrix diagram seeks to show the strength of relationships between factors, causes, and objectives that exist between the rows and columns that form the matrix.

PMBoK(R) 5^th Edition, Page 246

Quality Audits

A quality audit is a structured, independent process to determine if project activities comply with organizational and project policies, processes, and procedures. The objectives of a quality audit may include:

• Identify all good and best practices being implemented;
• Identify all nonconformity, gaps, and shortcomings;
• Share good practices introduced or implemented in similar projects in the organization and/or industry;
• Proactively offer assistance in a positive manner to improve implementation of processes to help the team raise productivity; and
• Highlight contributions of each audit in the lessons learned repository of the organization.

The subsequent effort to correct any deficiencies should result in a reduced cost of quality and an increase in sponsor or customer acceptance of the project’s product. Quality audits may be scheduled or random, and may be conducted by internal or external auditors.

Quality audits can confirm the implementation of approved change requests including updates, corrective actions, defect repairs, and preventive actions.

PMBoK(R) 5^th Edition, Page 247

Process Analysis

Process analysis follows the steps outlined in the process improvement plan to identify needed improvements. This analysis also examines problems experienced, constraints experienced, and non-value-added activities identified during process operation. Process analysis includes root cause analysis—a specific technique used to identify a problem, discover the underlying causes that lead to it, and develop preventive actions.

PMBoK(R) 5^th Edition, Page 247

Organization Charts and Position Descriptions

Various formats exist to document team member roles and responsibilities. Most of the formats fall into one of three types: hierarchical, matrix, and text-oriented. Additionally, some project assignments are listed in subsidiary plans, such as the risk, quality, or communications management plans. Regardless of the method utilized, the objective is to ensure that each work package has an unambiguous owner and that all team members have a clear understanding of their roles and responsibilities. For example, a hierarchical format may be used to represent high-level roles, while a text-based format may be better suited to document the detailed responsibilities.

• Hierarchical-type charts. The traditional organization chart structure can be used to show positions and relationships in a graphical, top-down format. Work breakdown structures (WBS) designed to show how project deliverables are broken down into work packages provide a way of showing high-level areas of responsibility. While the WBS shows a breakdown of project deliverables, the organizational breakdown structure (OBS) is arranged according to an organization’s existing departments, units, or teams with the project activities or work packages listed under each department. An operational department such as information technology or purchasing can see all of its project responsibilities by looking at its portion of the OBS. The resource breakdown structure (RBS) is a hierarchical list of resources related by category and resource type that is used to facilitate planning and controlling of project work. Each descending (lower) level represents an increasingly detailed description of the resource until small enough to be used in conjunction with the work breakdown structure (WBS) to allow the work to be planned, monitored and controlled. The resource breakdown structure is helpful in tracking project costs and can be aligned with the organization’s accounting system. It can contain resource categories other than human resources.
• Matrix-based charts. A responsibility assignment matrix (RAM) is a grid that shows the project resources assigned to each work package. It is used to illustrate the connections between work packages or activities and project team members. On larger projects, RAMs can be developed at various levels. For example, a high-level RAM can define what a project team group or unit is responsible for within each component of the WBS, while lower-level RAMs are used within the group to designate roles, responsibilities, and levels of authority for specific activities. The matrix format shows all activities associated with one person and all people associated with one activity. This also ensures that there is only one person accountable for any one task to avoid confusion of responsibility. One example of a RAM is a RACI (responsible, accountable, consult, and inform) chart. The sample chart shows the work to be done in the left column as activities. The assigned resources can be shown as individuals or groups. The project manager can select other options such as “lead” and “resource” designations or others, as appropriate for the project. A RACI chart is a useful tool to use when the team consists of internal and external resources in order to ensure clear divisions of roles and expectations.
• Text-oriented formats. Team member responsibilities that require detailed descriptions can be specified in text-oriented formats. Usually in outline form, the documents provide information such as responsibilities, authority, competencies, and qualifications. The documents are known by various names including position descriptions and role-responsibility-authority forms. These documents can be used as templates for future projects, especially when the information is updated throughout the current project by applying lessons learned.

PMBoK(R) 5^th Edition, Page 261 and 262

Networking

Networking is the formal and informal interaction with others in an organization, industry, or professional environment. It is a constructive way to understand political and interpersonal factors that will impact the effectiveness of various staffing management options. Human resource management benefits from successful networking by improving knowledge of and access to human resource assets such as strong competencies, specialized experience, and external partnership opportunities. Examples of human resources networking activities include proactive correspondence, luncheon meetings, informal conversations including meetings and events, trade conferences, and symposia. Networking can be a useful technique at the beginning of a project. It can also be an effective way to enhance project management professional development during the project and after the project ends.

PMBoK(R) 5^th Edition, Page 262

Organizational Theory

Organizational theory provides information regarding the way in which people, teams, and organizational units behave. Effective use of common themes identified in organizational theory can shorten the amount of time, cost, and effort needed to create the Plan Human Resource Management process outputs and improve planning efficiency. It is important to recognize that different organizational structures have different individual response, individual performance, and personal relationship characteristics. Also, applicable organizational theories may recommend exercising a flexible leadership style that adapts to the changes in a team’s maturity level throughout the project life cycle.

PMBoK(R) 5^th Edition, Page 262

Pre-assignment

When project team members are selected in advance, they are considered pre-assigned. This situation can occur if the project is the result of specific people being identified as part of a competitive proposal, if the project is dependent upon the expertise of particular persons, or if some staff assignments are defined within the project charter.

PMBoK(R) 5^th Edition, Page 270

Negotiation

Staff assignments are negotiated on many projects. For example, the project management team may need to negotiate with:

• Functional managers, to ensure that the project receives appropriately competent staff in the required time frame and that the project team members will be able, willing, and authorized to work on the project until their responsibilities are completed;
• Other project management teams within the performing organization, to appropriately assign scarce or specialized human resources; and
• External organizations, vendors, suppliers, contractors, etc., for appropriate, scarce, specialized, qualified, certified, or other such specified human resources. Special consideration should be given to external negotiating policies, practices, processes, guidelines, legal, and other such criteria.

The project management team’s ability to influence others plays an important role in negotiating staffassignments, as do the politics of the organizations involved. For example, a functional manager will weigh the benefits and visibility of competing projects when determining where to assign exceptional performers requested by various project teams.

PMBoK(R) 5^th Edition, Page 270

Acquisition

When the performing organization is unable to provide the staff needed to complete a project, the required services may be acquired from outside sources. This can involve hiring individual consultants or subcontracting work to another organization.

PMBoK(R) 5^th Edition, Page 270

Virtual Teams

The use of virtual teams creates new possibilities when acquiring project team members. Virtual teams can be defined as groups of people with a shared goal who fulfill their roles with little or no time spent meeting face to face. The availability of communication technology such as e-mail, audio conferencing, social media, web-based meetings and video conferencing has made virtual teams feasible. The virtual team model makes it possible to:

• Form teams of people from the same organization who live in widespread geographic areas;
• Add special expertise to a project team even though the expert is not in the same geographic area;
• Incorporate employees who work from home offices;
• Form teams of people who work different shifts, hours, or days;
• Include people with mobility limitations or disabilities; and
• Move forward with projects that would have been ignored due to travel expenses.

There are some disadvantages related to virtual teams, such as possibility for misunderstandings, feeling

of isolation, difficulties in sharing knowledge and experience between team members, and cost of appropriate technology. Communication planning becomes increasingly important in a virtual team environment. Additional time may be needed to set clear expectations, facilitate communications, develop protocols for resolving conflict, include people in decision making, understand cultural differences, and share credit in successes.

PMBoK(R) 5^th Edition, Page 271

Multi-Criteria Decision Analysis

Selection criteria are often used as a part of acquiring the project team. By use of a multi-criteria decision analysis tool, criteria are developed and used to rate or score potential team members. The criteria are weighted according to the relative importance of the needs within the team. Some examples of selection criteria that can be used to score team members are shown as follows:

• Availability. Identify whether the team member is available to work on the project within the time period needed. If there are there any concerns for availability during the project timeline.
• Cost. Verify if the cost of adding the team member is within the prescribed budget.
• Experience. Verify that the team member has the relevant experience that will contribute to the project success.
• Ability. Verify that the team member has the competencies needed by the project.
• Knowledge. Consider if the team member has relevant knowledge of the customer, similar implemented projects, and nuances of the project environment.
• Skills. Determine whether the member has the relevant skills to use a project tool, implementation, or training.
• Attitude. Determine whether the member has the ability to work with others as a cohesive team.
• International factors. Consider team member location, time zone and communication capabilities.

PMBoK(R) 5^th Edition, Page 272

Interpersonal Skills

Interpersonal skills, sometimes known as “soft skills,” are behavioral competencies that include proficiencies such as communication skills, emotional intelligence, conflict resolution, negotiation, influence, team building, and group facilitation. These soft skills are valuable assets when developing the project team. For example, the project management team can use emotional intelligence to reduce tension and increase cooperation by identifying, assessing, and controlling the sentiments of project team members, anticipating their actions, acknowledging their concerns, and following up on their issues.

Examples of interpersonal skills that a project manager uses most often include:

• Leadership. Successful projects require strong leadership skills. Leadership is important through all
• phases of the project life cycle. There are multiple leadership theories defining leadership styles that
• should be used as needed for each situation or team. It is especially important to communicate the vision and inspire the project team to achieve high performance.
• Influencing. Because project managers often have little or no direct authority over team members in a matrix environment, their ability to influence stakeholders on a timely basis is critical to project success.
• Key influencing skills include:
• Ability to be persuasive and clearly articulate points and positions;
• High levels of active and effective listening skills;
• Awareness of, and consideration for, the various perspectives in any situation; and
• Gathering relevant and critical information to address important issues and reach agreements while maintaining mutual trust.
• Effective decision making. This involves the ability to negotiate and influence the organization and the project management team. Some guidelines for decision making include:
• Focus on goals to be served,
• Follow a decision-making process,
• Study the environmental factors,
• Analyze available information,
• Develop personal qualities of the team members,
• Stimulate team creativity, and
• Manage risk.

PMBoK(R) 5^th Edition, Page 275 and 284