Four Reasons Why You Struggle to Engage Stakeholders

Colin Gautrey

This is a guest post by Colin Gautrey from Learn to Influence. Colin is an author, trainer and executive coach who has specialized in the field of power and influence for over ten years. He combines solid research with deep personal experience in corporate life to offer his audiences critical yet simple insights into how to achieve results with greater influence.

Few things are possible in large or complex organisations without buy-in from stakeholders. To get that buy-in, you have to engage them. In this article, Colin shares four reasons why you struggle to engage stakeholders.

So, you diligently reach out to them to bring them up to speed, get their input and elicit their support for your initiative. Naturally, you are convinced that it is in their very best interests to engage with you, they have a great deal to gain from this exciting project.

And that is when the problems start.

Your emails go unanswered, your calls ignored. As time advances, things become desperate as you realise that you are up against a deadline. Trying harder to get them talking to you just seems to make things worse.

Should you escalate?

Well, that would indicate to your boss that your influencing skills are lacking. So, what else can you do to get things moving again?

Firstly, you’ve got to pause a moment. Instead of trying harder, start to think more deeply.

Secondly, you really need to check the attitude you have towards your stakeholder. The longer failure to engage continues, the more negative attitudes become. Although this may not be the cause of lack of engagement, it will definitely make it harder to remedy the situation.

Thirdly, get a clear appreciation for the reasons why they may be holding back. This takes some doing, but when you move beyond mere suspicion and assumptions, you are much more likely to find the winning actions to gain the engagement you need.

Fourthly, based on your reflection about the real cause, adjust your approach so that you tackle the cause head on.

To help you delve more deeply into the underlying causes, consider:

  • Time. Although you may suspect otherwise, quite often they genuinely do not have the time to give justice to your request. Think about it. You’re busy, too busy to do many of the things that you would like to do. Maybe, just maybe, they would love to talk to you but haven’t been able to find a moment to do it.
  • Interest. You’ve heard this before, if someone has sufficient motivation, they can always find the time. For many stakeholders, especially those subject to extreme time pressure, they may not yet be aware of all they can gain from engaging with you. Your first sale is the time and priority in their schedule. Your second sale is what you want them to agree to.
  • History. Is there something in the history of your relationship that may be causing them to resist your attempts to engage with them. Think hard about this one. It might be that you’ve made life difficult for them in the past, or maybe you’ve let them down badly. Alternatively, something may have happened that they feel guilty or embarrassed about. Going further, what about their history with your boss?
  • Suspicions. Do they trust you and your motives? Perhaps something else is going on that makes them a cautious. This could be as simple as your new reporting lines (hence concern about whose side you are now on) or as distant as your friendship with a political rival they have just skirmished with.

The key here is to be as accurate as possible. You may need to invest some serious time to investigate this and talk to other to other stakeholders. While this may seem expensive, what pain are you already facing while hitting your head against a brick wall?

Regardless of the time it takes, if you don’t know why they are unwilling to engage, any attempt to engage them will be based on guesswork.

Asking for Project Management Advice

I've observed scores of project managers through the years. Some manage projects with no input from others. Others are not afraid of asking for project management advice. How about you?

Have you ever been lost without a GPS or map? Not sure where you are or how to get to where you want to be? I've been there. It's nerve-racking and embarrassing, particularly if you have passengers.

project management advice

So, what's the wise thing to do? Ask for directions, right? Find the path that leads to your destination.

But some people fail to do this in projects. Are you a lone ranger? You know the guy or gal who needs no input from others.

Are You a Lone Ranger?

One response I sometimes get when I encourage project managers to seek advice is, "Well, I'm the project manager. How I manage this project is no one else's business." 

I've had some project managers tell me about their Project Management Professional (PMP) designation or about how they've started two Project Management Offices or how they've been managing projects more than 15 years. 

I'm glad for their strong backgrounds and credentials, but it concerns me when I encounter the lone ranger mindset. No matter the accomplishments or how long one has led projects, we can all benefit from wise counsel.

Furthermore, when your project goes south, it impacts other people. Your team members. Management. Customers. Your company. Vendors. Partners.

And when things go awry, you will be criticized by these same stakeholders. Since people are going to talk about you, why not invite them to talk to you before you make your project decisions.

Here's what I know. When you realize that you made poor decisions, who will you likely go to for advice? Who are you gonna call?

Answer: It's not Ghostbusters. People often seek out the very people they chose to ignore earlier in their projects.

Seeking Advice From Peers

There's another class of project managers that are a step ahead of the lone rangers. When these people get stuck, they dial a friend. 

Bill talks to his peer Linda. Bill and Linda both were hired the same year and both have two years of experience in project management. They are good friends and have relied on each other for advice.

Think about it. This is like one neighbor asking another neighbor for advice on investing when both have little knowledge and experience in the first place. It's not a bad thing. It's just not the best. 

In contrast, other project managers have discovered the gold mine of seasoned and experienced project managers.


"Never take advice from people who aren't getting the results you want to experience." -Michael Hyatt

Seeking Advice From Experienced Project Managers

Why seek advice from experienced project managers? Well, these experienced project managers have been down the road many times. They have a perspective on things that is gained only through the school of hard knocks. These seasoned individuals can answer your toughest questions.

Politics. Difficult team members. Unengaged project sponsors. Unrealistic expectations from management. They've dealt with it all. Not once, but many times.

So, when's the best time to seek advice? Yes, you can ask for help when issues occur. Better yet, get their insights earlier when planning and considering significant project decisions.

From whom should we receive advice? Seek experienced individuals in your industry as well as those who are getting the results you want. Why talk to a financial advisor who is broke? Likewise, why seek advice from a project manager who rarely completes a project on budget and on time?

Another point, consider the possibility of talking to more than one person. In some cases, I've asked two or three seasoned individuals to meet together with me. The interaction provided insights that I would not have heard otherwise.


"Without counsel plans fail, but with many advisers they succeed." Proverbs 15:22

Never Stop Learning and Teaching

Take some time today to think about your projects. What is one area where you would benefit from the input of others? Ask an experienced project manager if you may buy them a cup of coffee and get their advice concerning a challenge you've encountered. Many individuals will be flattered and happy to help.

But there's another side of this coin. No matter how long you've been managing projects, you have experience too (more than others who are just starting). Offer to share your knowledge and experience. Whenever you teach others, you reinforce what you've learned for yourself. Pay it forward!

How to Conduct a Risk Audit and a Risk Review

A life well lived life involves looking backward as well as thinking forward. The same is true of projects.

In this article, we will look at how to conduct a risk audit to evaluate the effectiveness of your risk management. Additionally, we'll also talk about how to be more forward thinking through risk reviews.


“Good Risk Management fosters vigilance in times of calm and instills discipline in times of crisis.” -Dr. Michael Ong

How to Conduct a Risk Audit

Who Performs the Risk Audits?

The project manager, the project manager and team, or a risk audit team may perform risk audits. What is the focus of the audit? It is a retrospective review where we ask “How did we do?”

  • Review the effectiveness of the responses to risks
  • Next, review the effectiveness of the risk owners
  • Another, review the effectiveness of the risk processes

How Do Risk Audits Help?

Wonder if risk audits can really help you and your team. You bet!

And it doesn’t have to be difficult or require lots of time.

The output of the risk audit is the lessons learned that enable the project manager and the team to increase the likelihood and impact of positive events and decrease the likelihood and impact of negative events.

The size of the risk audit team and the time invested should be commensurate with the size and complexity of the projects. I’ve completed small risk audits with me and a couple of team members in an hour or less.

Sounds great, but how does it really work?

Real World Example of a Risk Audit

Tom was asked to manage a project to implement an insurance company claims customer service center that would house 100 employees. He decided to have a risk audit performed when the team had completed 40% of the project. Things were going fairly well, but Tom was concerned about an increasing number of issues, particularly with two risk owners.

Tom asked an internal risk audit group — comprised of one company project manager, one IT employee, and one claims manager — to conduct the audit. The team completed the audit in two weeks and discovered the following:

  • To start with, one risk owner — John Billings — had been negligent in managing a significant risk for a critical path activity, resulting in an adverse impact to the schedule of two weeks. Why had Mr. Billings been negligent? He had lost two employees in the last two months, forcing him to pick up the slack.
  • Next, there were two major risks where no responses had been taken and there were no contingency or fallback plans.
  • Furthermore, the team missed an opportunity that could have saved the project $20,000.
  • Finally, the risk evaluation process needed improvements. The scale being used for the qualitative risk analysis was broad and prone to bias.

The findings were shared with Tom and the project sponsor. The following changes were made:

  • First, John Billings was replaced with another risk owner.
  • Second, Tom met with the risk owners who had failed to respond to their risks, shared the audit findings, and asked that response plans be developed and executed.
  • Third, Tom included specific exercises to identify opportunities going forward in the project.
  • Lastly, Tom refined the qualitative risk evaluation scale.

“Risk is like fire: If controlled it will help you; if uncontrolled it will rise up and destroy you.” -Theodore Roosevelt

How to Conduct Risk Reviews

How can project managers make better decisions and get better results in the future? Try a risk review.

Remember, the audit team focuses on "How did we do?" Were the risk management processes effective? We are looking backward.

In contrast, risk reviews are prospective and forward-looking. We ask, "How will we do?" We modify our risk response plans and risk management processes to improve our chances in the future. 

Questions to Ask in Risk Reviews

Project managers and their teams periodically review their project risks for the following:

  • What have we learned from our risk audits that we should apply going forward?
  • Are there new risks?
  • Has the probability and impact changed?
  • Are there individual risks that are merging to form a powerful set of risks?
  • Should we modify our responses including contingency and fallback plans?
  • Should we close irrelevant risks?
  • Are the residual risks increasing or decreasing?

For more helpful questions, check out my post 12 Questions For Monitoring Project Risks.

Your Turn

Pick one of your worst project, where things have been crazy. Look backward with a risk audit and forward with a risk review. You will likely gain insights and perspective as you see things with fresh eyes. Best wishes!

12 Questions for Monitoring Project Risks

Some project managers start their projects with a strong focus on risk management. However, somewhere along the way, they lose steam. They spend more time dealing with issues and implementing workarounds. In this article, I am providing questions that can help you in monitoring project risks and as a result, achieve better results.

Other project managers start out strong and stick with their risk management. When problems occur, they turn to their risk response plan. They run toward their risk management tools and techniques to aid them. Consequently, these project managers spend less time responding to issues.

In my last article, we looked at What Every Project Manager Should Know About Monitoring Risks where we reviewed the definition for Monitor Risk. The Project Management Body of Knowledge (PMBOK) 6th Edition defines Monitor Risks as “the process of monitoring the implementation of agreed-upon risk response plans, tracking identified risks, identifying and analyzing new risks, and evaluating risk process effectiveness throughout the project.”

When Should We Monitor Project Risks?

Monitoring risks is an ongoing activity, not a one-time event. The frequency varies depending on the project. Some project managers review risks with their team in their weekly project meetings, while others who manage agile projects discuss risks and obstacles in their daily standup meetings.

12 Questions for Monitoring Project Risks

Perhaps you struggle with the practicality of monitoring risks. It seems like a vague notion. Hence, here are some questions that can help you and your team on the right track.

  1. What new risks should be captured in the risk register?
  2. What risks should be closed?
  3. What has changed in the previously identified risks? Reassess the probability and impact of your risks.
  4. How effective are the current risk response plans and actions? If the risk plans are not effective, modify them for better results.
  5. Have project assumptions changed?
  6. What thresholds have been exceeded? If a threshold or trigger has been exceeded, what actions need to occur?
  7. What contingency or fallback plans should be executed?
  8. Are there common causes that are increasing multiple risks? One causal factor may increase the probability and/or impact of multiple risks. Therefore, attacking these causal factors has high leverage.
  9. Are the right risk owners assigned? If the risk owner is not performing their duties correctly, look for ways to motivate the risk owner or consider a change.
  10. Are workarounds increasing? If your manual workarounds are increasing, this is a sign of inadequate risk identification and responses earlier in the project.
  11. How are the reserves doing? Is it time to request additional reserves? Perhaps the team should consider ways to change facets of the project in order to stay within budget and schedule.
  12. What have we learned?

Question: What other questions would you add to this list?

What Project Managers Should Know About Monitoring Project Risks

Many project managers do a great job of identifying risks. Some even evaluate risks and develop response plans. However, project managers get busy as their projects progress and fail to monitor their risks, resulting in challenged or failed projects. Here are some key factors that you should know about monitoring project risks (previously referred to as controlling risks in the PMBOK 5th Edition).

Do Project Managers Really Control Risks?

I've heard countless debates about whether project manager can control risks. First of all, what does it mean to control something? Here's the Merriam-Webster dictionary defines control as:


Definition of CONTROL

a to exercise restraining or directing influence over regulate 
  • control one's anger
to have power over rule 
  • A single company controls the industry.
to reduce the incidence or severity of especially to innocuous levels 
  • control an insect population; control a disease

Can project managers really control project risks? Feels more like herding cats, doesn't it?

So, why do people push back on controlling risks? These individuals take the term control literally. They argue, "no one has absolute control over projects."

I'm not sure, but I think these issues resulted in the changes in the Project Management Body of Knowledge (PMBOK). The authors of the 6th Edition changed the Control Risks process to Monitor Risks.


PMBOK 5th Edition
Control Risks

The 5th Edition included the process called Control Risks which was defined as "The process of implementing risk response plans, tracking identified risks, monitoring residual risks, identifying new risks, and evaluating risk process effectiveness throughout the project."

PMBOK 6th Edition
Monitor Risks

The authors of the 6th Edition changed the Control Risks process to Monitor Risks"Monitor Risks is the process of monitoring the implementation of agreed-upon risk response plans, tracking identified risks, identifying and analyzing new risks, and evaluating risk process effectiveness throughout the project."

Let's move beyond the debates and talk about monitoring project risks and getting results.

Four Steps to Monitoring Project Risks

1. Monitor Agreed-Upon Risk Response Plans

For each risk or set of risks, a response should be planned. Risk owners or their assigned risk action owners execute the plans. Some risks merit immediate responses; contingent risks are responded to when trigger conditions are met. For example, if a supplier fails to meet a deadline, the supplies are ordered from another vendor.

Jim, the project manager of a key strategic project, has monitored the residual risk -- the amount of risk remaining -- for his most significant risks. One of the key risks had a 60% probability of occurring with a $22,000 impact on a $100,000 project. The risk owner took actions that decreased the residual risks -- the probability dropped to 20% with an impact of $4,000.

Jim determined that it would be too costly to reduce the risk further; therefore, he asked the risk owner to monitor the risk and to develop a contingency plan. The risk owner reported to Jim once each month on the risk.

Project managers work with the risk owners to evaluate the effectiveness of the responses. Responses are modified as needed.

2. Track Identified Risks

The project manager uses tools to track the overall project risk. Are the risk response plans ensuring that the project team delivers the project on time, on budget, and in accordance with the requirements?

Trigger conditions are defined when defining risk response plans. Project managers work with the risk owners to determine the trigger conditions and the related metrics. For example, additional resources may be added to an activity if the activity falls behind schedule for two weeks or more.

3. Identify and Analyze New Risks

New risks arise over time. For example, an insurance company was implementing a new policy administration system. A vendor delivered an update while an insurance company was testing major modifications in their interfaces. As the new code was introduced, there was the risk of breaking the interfaces.

Project managers periodically work with their project team to identify new risks. What’s new? What has changed? What have we overlooked?

Project managers should identify new risks for the following events:

  • Major changes to the project or its environment
  • Key milestones reached
  • Occurrence of a major risk
  • Unexpected risks
  • Changes in key team members or stakeholders

4. Evaluate Risk Process Effectiveness

So, you’ve implemented the risk management processes:

  1. Plan for risk management
  2. Identify risks
  3. Perform qualitative risk analysis
  4. Perform quantitative risk analysis
  5. Plan risk responses
  6. Implement risk responses
  7. Monitor risks

That’s great! Are the processes of delivering the results you expected efficiently and effectively? Are you spending too much time in certain areas and not enough time in other areas? Seek to reduce the cost of risk management while ensuring that you accomplish your project goals.

Your Turn

Think about your projects. If you compare the degree of variation from your baselines, how are you doing? Would you say your projects are staying within the expected limits? Or perhaps one project is like a car that is swerving all over the road. You wonder if you will ever get home. If so, make the necessary adjustments in monitoring project risks.

3 Reasons IT Software Projects Fail

You've heard the war stories of companies that tried to implement commercial software solutions or build new systems. Maybe you've even participated in one or two? Many of these endeavors took longer and cost more than expected. Others were outright failures, adversely impacting the company's bottom line. Let's look at 3 reasons that IT software projects may be challenged or fail.

The Standish Group conducts an annual survey to see why some IT software projects are successful and others fail. Year in and year out, the survey shows approximately one-third of the projects are successful: come in on schedule, on budget, and delivers what was promised. Most projects miss the mark—they are completed late or over budget or lack quality, or some combination of these attributes.

But, it doesn't have to be that way. We can be successful! It starts with understanding the most common causes of software project problems.

3 Biggest Factors to Challenged & Failed Projects

1. Lack of User Input

Imagine a software project where the project team delivers the project on time and under budget. But the software does NOT meet the users' needs. Why does this happen?

Project teams have their pants on fire! Everyone wants the software yesterday.

So, how do most project teams respond? They skip the critical step of collaborating with the users. These teams make assumptions about the user needs without even asking.

Oh, you wanted to have data prefill? Didn't know that.

Want your customers to be able to access their policy information online? Why didn't you say so?

Users assume that the project teams already know their needs. That's not always the case. In fact, often, the teams don't know.

More times than not, users see the software for the first time during training, not earlier in the project when requirements are being elicited or when the software is being designed and configured. Not even when the testing is being performed. The avenues for user input is limited, resulting in less-than-stellar software.


"The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is as difficult as establishing the detailed technical requirements, including all the interfaces to people, to machines, and to other software systems. No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later." —Frederick Brooks

2. Incomplete Requirements

No surprise. If the users are not engaged, the requirements—the users' needs—will not be understood. What happens in these projects whether taking a traditional or agile approach? The missed requirements are discovered later. And, the rework starts, resulting in adverse impacts to the project schedule and budget, as well as the team's morale.

3. Changing Requirements

Project teams complain that users don't know what they want and constantly change their minds. That may be true—sometimes. But, what would you expect when the users are not asked for their input earlier in the projects? Furthermore, we live in ever-changing industries that requires that we be able to handle changes.

Leading IT Software Projects

I know that you're smarter than the average Joe. You know that doing the same thing and expecting different results is insane. Let's take a powerful and decidedly different approach.

  1. Engage your users in the requirements process
  2. Progressively elaborate and refine your requirements with the users
  3. Expect (and even invite) change by using an agile, adaptive approach 

Are You Making These Risk Response Mistakes?

Some project managers make timely responses to risks, resulting in positive progress toward their project goals. Others act haphazardly, resulting in undesirable consequences. Let's look at some common risk response mistakes and how to overcome them.

So, what do I mean by risk response mistake? A mistake is an action that is misguided or wrong.


"If you treat risk management as a part-time job, you might soon find yourself looking for one." —Deloitte

Joe Cunningham once managed a project to implement a commercial-off-the-shelf (COTS) software solution for a bank. He and the team had identified the project risks, but they had failed to analyze the common causes of the most significant risks. Consequently, the team was responding to risks but missing the high-leverage responses.

Perhaps you are making mistakes like this one. But, you don't have to.

I've created a list of ten risk response mistakes. I'm sure that you aren't guilty of all. Read through them, thinking about one of your projects. Make notes where you might improve.

10 Risk Response Mistakes

  • 1
    Failure to identify risk owners. Once a risk has been identified, project managers should ask, "Who owns the risk?" A risk owner is a person responsible for developing and executing a risk response plan.
  • 2
    Failure to respond to several small, related risks. If we fail to analyze the relationships between risks, we may not understand how risks relate to one another. Individual small risks seem powerless. However, several small, related risks can have a powerful impact.
  • 3
    Failure to identify and plan for secondary risks. When risk owners are developing risk response plans, they may fail to consider secondary risks, risks that arise as a direct result of implementing a risk response. Wise project managers educate and ask their risk owners to identify and plan for significant secondary risks.
  • 4
    Failure to develop contingency plans. Some risk response plans are executed immediately; other risk response plans are contingent. That is to say; the plans will only be executed under certain predefined conditions.
  • 5
    Failure to develop fallback plans. What should a risk owner do if the contingency plan fails? Risk owners should develop and be prepared to execute a fallback plan for significant risks. The fallback plan may be used to mitigate further a threat or enhance an opportunity. A fallback plan may also be defined for cases where a risk may occur.
  • 6
    Failure to define risk triggers. Some risk owners do a great job of defining contingency plans but fail to define clearly the risk trigger such as missing a milestone. Triggers may be used to provide the warning that the risk is about to occur, providing time to implement the risk response plan.
  • 7
    Failure to respond to opportunities. Many project managers still struggle with the fact that risks include positive events or conditions, that if they occur, cause a positive impact on the project goals. Therefore, many project managers fail to identify these positive events and miss the opportunities that could save the project or enhance the project's value.
  • 8
    Failure to update project management plans including the schedule management plan, cost management plan, quality management plan, procurement management plan, human resource plan, scope baseline, schedule baseline, and cost baseline. As risk owners develop response plans, project managers should update the project management plans accordingly. For example, the project manager may add new activities to the schedule and further define how contingency reserves will be consumed.
  • 9
    Failure to update assumptions log. Project managers and team members make lots of assumptions, particularly in the early parts of a project, based on the information at hand. As the project team discovers new information, previously identified assumptions may need updating, or new assumptions may need to be added.
  • 10
    Failure to create contracts or agreements with third parties. Some risk owners may wish to leverage a third party to respond to risks. The project manager should ensure these decisions and contracts are outlined and approved as needed.

Taking Action on Risk Response Planning

Consider using this list as a checklist for one of your current projects. Keep your risk management as simple as possible while ensuring that the responses are economical and effective. Scale your response plans as needed; do more planning for larger complex projects and less for smaller projects.

It’s Easy to Miss Project Risks

It's easy to miss project risks. And, until a project manager has identified the threats and opportunities, the risks cannot be managed properly. Projects rise and fall with the project manager's ability to properly identify and manage their most significant risks.

Project managers don't want to spend an inordinate amount of time identifying risks—rightly so. 

Neither can project managers afford to miss the critical risks. Let's look at strategies to identify risks and save time when identifying project risks. You can choose and scale these strategies as needed.

Risk Identification Techniques

1. Use a risk list. A risk list is a list of potential risks for an industry, organization, or company. Ideally, the risks are listed by categories such as schedule, budget, quality, and scope. For example, you could identify schedule risks using a schedule risk list such as:

  • Schedule is missing key activities
  • Excessive schedule pressure
  • Schedule is optimistic, not realistic
  • The product or service cannot be developed to the size specified in the time allocated
  • Schedule was baselined without review by key stakeholders
  • Scope has increased with no change to the schedule
  • A delay in a critical path activity is causing cascading delays in the subsequent activities
  • A key resource has been reallocated half-time to another project, adversely impacting the work on this project
  • Estimates were created by the project manager, not the individuals doing the work
  • One activity may not provide the required information that a subsequent activity needs
  • Coordination issues are arising from the crashing of several critical path activities

2. Use risk categories. What can we do if we don't have a risk list? Try a prompt list, a generic list of categories used to "prompt" the identification of risks. Typical project risk categories include:

  • Schedule risk - schedule events or conditions, that if they occur, will cause a positive or negative impact to the project goals
  • Budget risk – budget events or conditions, that if they occur, will cause a positive or negative impact to the project goals
  • Quality risk – quality events or conditions, that if they occur, will cause a positive or negative impact to the project goals
  • Scope risk – scope events or conditions, that if they occur, will cause a positive or negative impact to the project goals

3. Identify internal and external risks. It’s obvious that we need to identify internal risks. However, project managers may fail to identify external risks. Out of sight, out of mind. For example, an organization may contract with a third party to provide products, services, and supplies. There is the temptation to forget about it.

Just because a contract exists does not mean that the project manager has washed her hands of these risks. The project manager is still responsible for overseeing the activities, making sure the contracted products and services fulfill the project’s needs and integrate properly into the project deliverables.


“The secret of getting ahead is getting started. The secret of getting started is breaking your complex overwhelming tasks into small manageable tasks, and then starting on the first one.” —Mark Twain

4. Perform top-down and bottom-up risk identification. With a top-down approach to risk management, the project sponsor (and sometimes senior management) declares which threats and opportunities matter. The benefit is that it provides a high-level perspective. The project sponsor defines the project goals and determines the business strategies to make it happen.

However, the project sponsor will not likely understand the project planning and execution risks. A bottom-up approach provides the advantage of getting the views of the team members and key stakeholders. An excellent tool for the bottom-up risk identification is the work breakdown structure (WBS). The project manager can work with team members to discuss the lowest level WBS activities in order to identify risks.

5. Perform risk reviews periodically. Remember—risks change over time. Imagine never having your vehicles checked or never having a physical exam by a doctor. Project risk reviews should be performed regularly. In addition, reviews should be performed for the following events:

  • Significant change of project goals, deliverables, assumptions, of constraints
  • Change in team members
  • Significant change in requirements
  • New or changing external requirements such as regulatory requirements or contract requirements
  • High number of issues are occurring

Risk Identification Tips

Keep in mind, we are NOT trying to identify every possible risk. We are scanning the project environment to find the most significant risks. If done properly, these strategies can help us identify the critical risks quickly. Then we can take the next step—treat the risks.

Some project managers take a different approach - it's called wait and see. It works like this: Don't invest time (i.e., waste time) identifying and treating risks. When the uncertain event or condition occurs, the project manager would fix it—translate, the project manager and affected stakeholders would put out the fires!

Responding to issues almost always require more time and cost more money than identifying and treating risks ahead of time. Being disciplined and applying an appropriate amount of time and focus on risks can reduce project expenses, promote the project schedule, reduce stress, and help a project team achieve its mission.

7 Things You Should Not Do When Identifying Project Risks

Known and unknown, internal and external, upside and downside—risks are woven into the fabric of every project. Project managers can waste a lot of time due to poor risk management. In today’s article, let’s look at seven things not to do when identifying project risks.

Don't do it. Written on white paper

1. Don’t wait.

Dan the project manager just kicked off a new project, adding stress to his life. He was already managing three projects. Now he had a new team, new goals, new challenges, and yes, new risks.

If Dan was like most project managers, he would wait until later to start the risk identification process. Why hurry? He had enough to do without jumping into the risk management stuff.

However, risk waits for no one. In fact, the project risk exposure — the level of risk due to uncertainty — is highest at the beginning of projects. Why? We know the least.

Dan is smarter than most project managers. He starts identifying and capturing risks as he initiates and plans the new project. He proactively asks his team and stakeholders to help him identify the things that may hinder or help the project. His teams benefit from his early focus on achieving the project objectives.Continue reading

How to Use NGT for Risk Identification

I conduct online surveys to get feedback from project managers on risk management topics. Here’s one of the questions, “What risk management techniques would you like to know more about?” Survey participants often respond with: Nominal Group Technique (NGT).

How to Use NGT for Risk Identification

What is the Nominal Group Technique?

The nominal group technique is an efficient means for identifying and ranking risks, as well as other items. It is brainstorming on steroids. Risks are collected from a project team. The risks are analyzed and ranked by the team.

The NGT is a powerful tool for larger groups.  The technique saves time, engages participants, and reduces groupthink—a phenomenon where people set aside their personal beliefs and adopt the opinion of a group.Continue reading

Become a more effective project risk manager.