Category Archives for 4=Control

Why Project Managers Need Business Analysts for Project Success

project managers need business analystsThe Standish Group says three of the biggest factors that lead to failed and challenged projects are:

  1. Lack of user input
  2. Incomplete requirements
  3. Changing requirements

We should attack these threats with a vengeance. How can we do this? We add skilled requirements analysts to our teams.

When Do Project Managers Need a Business Analyst?

The role of the project manager is to achieve the project’s goals or objectives. Who performs the business analysis tasks for the projects? That depends.

For small projects, the project manager may assume many roles including but not be limited to:

  • Project manager
  • Requirements analyst
  • Tester
  • Facilitator and scribe
  • Trainer
  • Chief bottle washer (just kidding)

For larger projects, project managers must find ways to complete project tasks through others. They must not fall into the trap of doing everything themselves. Wise project managers recruit team members with the necessary skills and talents.Continue reading

Why Risk Avoidance Should Be 1 of Your 8 Risk Responses

Earlier I wrote about eights ways to treat risks. One of the risk responses is avoidance. The focus of this strategy is to ensure the risk does not occur by eliminating the cause of the risk.

Call the Fire Department

It was Fall, and I had raked the leaves in my backyard into three piles. I was trying to decide what to do with them. I knew there was a ban on burning in my area since we had been extremely dry for months.

What were my options? I could bag the leaves. I could haul the leaves into the woods. Or I could burn the leaves.

I decided to take a chance and burn the leaves. Later, I soaked the areas with water to fully extinguish the remaining embers.Continue reading

The PMBOK® Guide 6th Edition: How to Escalate Risks

The Project Management Institute added a new risk strategy in the Sixth Edition of the Project Management Body of Knowledge. Let's take a look at what it means to escalate risks and how to escalate risks, both threats and opportunities.

Escalation is one of the eight ways to treat risks.The PMBOK® Guide–Sixth Edition says: 

"Escalation is appropriate when the project team or the project sponsor agrees that a threat is outside the scope of the project or that the proposed response would exceed the project manager's authority. Escalated risks are managed at the program level, portfolio level, or other relevant part of the organization, and not on the project level. The project manager determines who should be notified about the threat and communicates the details to that person or part of the organization. It is important that ownership of escalated threats is accepted by the relevant party in the organization." 

The language for escalating opportunities is nearly identical, interchanging the term threat with opportunity.

Every organization has risks at various levels such as teams, departments, business units, and an enterprise level. Projects touch different parts of the organization. Project managers discover all kinds of risks, some that are within the scope of the project and others that are not.

What should a project manager do when a risk is identified that is outside the scope of the project? Escalate the risk. Here are three takeaways. 

Three Takeaways About Escalating Risks

  1. Risks may be managed at a project level, program level, portfolio level, or other relevant part of the organization. Per the PMBOK® Guide, a program is "defined as a group of related projects, subsidiary programs, and program activities managed in a coordinated manner to obtain benefits not available from managing them individually." How does a portfolio differ? A portfolio is "defined as projects, programs, subsidiary portfolios, and operations managed as a group to achieve strategic objectives."  Another possibility is to manage the risks in an Enterprise Risk Management (ERM) Program. The Risk Management Society (RIMS) defines Enterprise Risk Management (ERM) as “a strategic business discipline that supports the achievement of an organization’s objectives by addressing the full spectrum of its risks and managing the combined impact of those risks as an interrelated risk portfolio.”
  2. The project manager determines who should be notified. Not all project managers will know who should own the risk. Ask team members and the project sponsor to help determine the risk owner.  
  3. It's important that the ownership is accepted. Project managers often lack the authority to simply assign the risk to someone outside their projects. Project sponsors can help by engaging the appropriate people in the organization to ensure buy in. If your organization has an enterprise risk management program, the ERM Director can help with the escalation.

Escalate Your Risks

Do you have risks in your project risk register that should be escalated? Work with your project sponsor and other key stakeholders to clarify the risks, determine the true risk owners, and ensure ownership at the right level of your organization. 

8 Ways to Treat Risks

8 Ways to Treat RisksWe treat risks personally and professionally every day.

Imagine you have a large amount of credit card debt. You decide to eliminate one of the causes of your debt. So, you cut up your credit cards.

What if you had an opportunity to increase company revenue by getting a product to market a few months early? You could assign your most skilled resources to your critical path tasks.

In our projects, we face threats that may limit our ability to achieve our goals. We also see opportunities, if properly seized, that could allow us to make greater progress. Our job is to treat risks to enhance opportunities and reduce threats. We can optimize our risk responses over time.Continue reading

The 10 Risk Management Commandments You’re Breaking Every Day

I fear that many project managers live by the letter of the law and may fail to gain the true benefits of risk management. These individuals are too concerned with checking boxes and making the risk management processes overly complex. Let’s look at some common mistakes and how to overcome them.

Photo of calculator and pie chart

1. Thou shalt not make risk management complicated.

Every project is different. Wise project managers tailor their risk management plan to each project. Pick only the necessary inputs and tools and techniques. And speak in a manner that your sponsor, project team, and stakeholders understand. If you wish to introduce new terms (e.g., risk attitude, risk tolerance, Monte Carlo), be sure to define them.Continue reading

Evaluating Project Schedules Utilizing Quantitative Risk Analysis

picture of calendarDo you remember the first time you missed a project deadline? I do. I recall the embarrassment for me and my team. I promised myself I would take proactive steps to mitigate this outcome for future projects including the use of quantitative risk analysis.

Why do projects take longer than expected? Often times, risks occur and project managers lack adequate schedule reserves.

Once burned, many project managers start a bad habit – padding their project schedules. If a project is estimated at 120 days, the project manager may add a 10% pad, an additional 12 days. The project manager estimates the project duration to be 132 days.

Padding is a quick and dirty method. It provides reserves, but let’s look at a better way to estimate reserves.

Continue reading

Evaluating Risks Using Quantitative Risk Analysis

Project managers should be prepared to perform different types of risk analysis. For many projects, the quicker qualitative risk assessment is all you need. But there are occasions when you will benefit from a quantitative risk analysis.

Let’s take a look at this type of analysis: What is it? Why should we perform it? When should it be performed? And how do we quantify risks?

Quantitative Risk Analysis Bar Chart

What is Quantitative Risk Analysis?

Qualitative risk analysis is a numeric estimate of the overall effect of risk on the project objectives such as cost and schedule objectives. The results provide insight into the likelihood of project success and is used to develop contingency reserves. 

Continue reading

30 Quick Risk Evaluation Tips

genius evaluating risksWinston Churchill said, “True genius resides in the capacity for evaluation of uncertain, hazardous, and conflicting information.” In this article, I share 30 risk evaluation tips to help you tap into your genius. Enjoy!

  1. One of the top reasons for evaluating risks is to determine which risks are most significant.
  2. Always perform the qualitative risk assessment. The assessment is quick, but keep in mind –it’s also subjective.
  3. Determine if organizational assets such as a risk register template and probability/impact rating scale are available to jump-start your evaluation.
  4. Be sure to update the risk register each time you evaluate your risks.
  5. When evaluating each risk, consider the causal factors, the risk itself or uncertainty, and the impacts.
  6. Probability is the likelihood that a risk may occur.
  7. Impact is the effect or consequence on the project if the risk occurs.
  8. Multiply probability and impact to calculate a risk score (e.g., 4 x 5 = 20).
  9. Be sure to define your rating scales for probability and impact.
  10. Concerned with the velocity (e.g., time-to-impact) of your risks? Consider rating velocity along with probability and impact. Here is an example of how you can calculate a risk score using velocity: Risk Score = (Probability + Velocity) x Impact.
  11. Improve the quality of your risk information through interviews and workshops before evaluating your risks.
  12. There may be multiple causal factors for a single risk.
  13. There may be multiple impacts for a single risk.
  14. Some root causes are common to multiple risks. Responding to these root causes often provide high leverage.
  15. Look out for the high power/high influence stakeholders who wish to bias risk ratings for their own benefit.
  16. Beware – some individuals may be biased in their assessments because they lack an understanding of the risks. Educate stakeholders on the risks.
  17. Perform an assumption analysis before evaluating your risks.
  18. Not all bias is bad. For example, if the sponsor says that the budget is the most important priority, consider this factor in your ratings.
  19. Things change. Therefore, conduct periodic risk reviews.
  20. Consider evaluating your risks again when there are significant changes in the project or when you hit project milestones.
  21. Lots of small risks can create a large cumulative risk exposure.
  22. When multiple activities converge into a successor activity, the risk for the successor activity is greatly increased.
  23. Sum the individual risk scores to calculate the total project risk score. You may divide the project risk score by the number of risks to calculate the average risk score.
  24. Risks that may occur later in a project should be considered as a higher risk than the risks that may occur early in the project. Why? There is less response time, greater uncertainty, and greater impact.
  25. The same risk may occur multiple times in the same project. Should you use the same risk response? Yes, if the response plan is working. Look for ways to tweak the response for a one-two punch.
  26. Want a way to analyze risks at a higher level than the individual risks? Group risks by category (e.g., time, cost, scope, and quality). Sum and compare risk scores by category. How have the risk exposures in the categories changed from one risk review to the next risk review? Why did the exposures change?
  27. Determine high-priority risks. Define a risk threshold (e.g., risks with a risk score of X or higher).
  28. Be sure to involve appropriate stakeholders in the evaluation of your risks.
  29. Right size your risk evaluation process.
  30. Perform quantitative risk assessments when more detailed information is required for project decisions. Quantitative risk analysis is not always mandatory.

How to Actually Perform a Qualitative Risk Analysis Mini-Course. I’ve developed this course to help you quickly review the concepts of qualitative risk analysis. Click here to enroll!

How to Evaluate Risk Velocity

Life is filled with risks. Some risks occur slowly. Others strike with little warning. Let’s look at how to evaluate risk velocity and why it matters.

What is Risk Velocity?

Risk velocity is the time to impact. Think of velocity as an estimate of the time frame within which a risk may occur.

Why Risk Velocity Matters

When the velocity is low, we have more time to respond to the risks. For a threat, we may take steps to reduce the probability and impact. The risk owner has time to develop a contingency plan (i.e., a plan we will execute if the risk occurs) and a fallback plan (i.e., a plan we will execute if the contingency plan fails).

If the velocity is very high, threats strike quickly. Thus, these risks are more likely to become issues, costing more time and money. Here are some causal factors for high-velocity risks:

  • Sponsor notifies you that two critical team members need to be transitioned to another project within two weeks
  • The servers that you ordered for your test region are going to be two to three weeks late
  • Wildfires are emerging into the area of your offices

Imagine that two risks have a risk score of 20 on a scale of 25. But Risk A will likely to occur in a two to three weeks where Risk B will take at least six months. Which risk merits your attention most? See the difference?Continue reading

How to Reduce Risk Evaluation Bias

We all have biases; many are helpful. In projects, we have biases towards successful projects and motivated teams. If a project sponsor says that schedule is the top priority, the project team has a bias towards meeting the schedule.

However, some biases are harmful. Stakeholders may attempt to sway project decisions in unfair ways. These biases undermine the health of the project and breed distrust.

Let’s look at different types of biases and ways to reduce bias in the risk evaluations. These steps will help ensure the right decisions are made for the right reasons.

What are the Motives and Perception?

Stakeholders may exhibit different types of bias. PMI’s Practice Standard for Project Risk Management explains motivational bias is “where someone is trying to bias the result in one direction or another.” Cognitive biases occur as people make inferences in an illogical fashion. Cognitive biases are based on people’s perceptions.

How to Manage Bias

  1. Uncloak the bias. Project managers should watch and listen for bias. Expose the bias in one-on-one meetings or team meetings, whichever is most appropriate. Be careful – do not judge or challenge too quickly. Be slow to speak. Listen. Seek to understand.

  2. Have open conversations. When a bias is not understood, the project manager should dig deeper. If the bias is based on the wrong perceptions, provide the facts. If the bias is ill intended, ask non-threatening questions that allow the individual to understand how the bias may negatively affect the project.

  3. Reduce the subjectivity. Project managers use qualitative methods to evaluate risks quickly. Some project managers fail to understand that they may be creating greater bias. Let’s look for ways to reduce the subjectivity while keeping the convenience and speed of the qualitative methods.

How to Reduce Bias When Evaluating Risks

For small projects, I use a KISS (Keep It Super Simple) Method for qualitative risk assessments. This one-dimensional technique involves rating risks as:

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

While the KISS Method is a simple and quick way to prioritize risks, it is also subjective and open to greater bias. When I use this method, I focus on open and honest conversations about the ratings.

A more common qualitative method is the two-dimensional Probability/Impact matrix. With this method, we rate probability and impact on a scale such as 1 to 10, with 10 being the highest. This method provides a more in-depth analysis of risks as compared to the KISS Method. However, a scale of 1-10 is still highly subjective.

How can we reduce the subjectivity?

The first step is to define qualitative terms (e.g., Low – Very High) for the ratings. Here is an example:


Another step is to define ranges for the scale (e.g., 0-5% for Low). Defining the scale reduces subjectivity and drives greater consistency in the ratings.


If the probability or likelihood of a risk is approximately 15%, we assign a probability rating of 5. If the potential impact on the budget or schedule is 55%, we assign an impact rating of 9. The resulting risk score would be 45 (i.e., 5 x 9 = 45).

If stakeholders need objectivity, perform a quantitative risk analysis. Quantitative risk analysis takes more time than qualitative risk analysis. However, this method provides objective information and data for business decisions.

Read: How to Actually Perform a Qualitative Risk Analysis>>