Project Practitioners > Crystal Ball, Anyone? (Risk Management, Part 1)

Crystal Ball, Anyone? (Risk Management, Part 1)

By Sinikka Waugh

Once upon a time…I encountered a project that was in rather a bit of trouble.  It was clear that the project was not going to make it on time, on budget, or on scope.  The nature of the project was around implementing a new vendor solution that would involve process changes and data conversion in a highly visible and highly complex business.  The implementation date was just about a month away, but there were still several months’ worth of work to be done, and at every turn, things were getting worse.  The team consisted of very talented individuals, all with a strong desire to make the project successful.  Why then, had things gone so awry? An in-depth study would reveal a couple of root causes, but there was one in particular that had multiple, devastating symptoms.  In point of fact, the risks associated with the project had not been properly managed.  Many things that could have been anticipated on such a complex project had caught the team off guard, and they were spending more time reacting than doing what they had planned.

Sure, hindsight is 20/20, and it’s easy to look back now and see things more clearly than they were at the beginning of Chapter One, but I would argue that there’s more to it than that.  Even without the benefit of an omniscient narrator or a crystal ball, I do believe we can – and should – anticipate the things that might happen, and plan accordingly.

To my question to the team, “how have you been managing your risks?” I received resounding affirmation that they had a risk log.  So I took a look.  Sure enough, there was a list of things that could go wrong, but that’s all there was; and that’s where I believe things went wrong.

First of all, the list was not nearly comprehensive enough for a project of that magnitude.  Several of the more obvious ones were there (vendor delay, resource constraints, etc.), but the list did not include many of the things that had already gone wrong in the project, several of which could have and should have been anticipated.

Second, the list was not current.  It had not been updated in several months.  It appeared as if the risk list had been made some time near the start of the project, then filed away and not touched again.  As the project progressed, the team didn’t pay close attention to the changes in the risks associated with the project.

And third, the list told only half of the story.  If a risk is statement of what could possibly go wrong, then the “rest of the story” (as Paul Harvey would say) is what we’re going to do about it.  The risk list I uncovered had almost no definition of what the team was planning to do about any of the risks.

Quick side note here:  PMBOK experts everywhere will likely point out that risks can be opportunities as well:  there are risks with positive consequences, not just negative ones.  I’ll agree with the statement, but my experience has led me to believe that the latter are more common than the former.  Additionally, any political fallout from project changes resulting from the former are much easier to manage than those resulting from the latter.  Case in point:  I’ve never had to go in front of a project review board to justify why a project finished two months early or didn’t spend all of its budget, but you can bet I’ve had to account for project changes that pushed the date out by two months or increased the costs.

So, back to our topic, how do you manage the things that could go wrong, if they haven’t happened yet?  If we’re unable to predict the future (as most of us are), how do we successfully manage those obstacles we don’t even know about, to prevent negative outcomes?  Here’s the approach I take:

First, I start with a good list of things to worry about.  A good list of bad things may sound like an oxymoron, but it’s not:  the more prepared you are for obstacles, the better off you’ll be.

Make sure the list is comprehensive enough.  To identify sources of risk, think through your own experiences, and then think through the stories you’ve heard or get input from others.  Where do things often go wrong? Start with the obvious topics like resource availability, budget shortfalls, prioritization, vendor management, technical complexity, and calendar constraints.  Then look at the specifics of the current situation (the project, the team, the environment, etc.). 

Once you’ve got a starting point, ask the team, “What are all of the things that could possibly go wrong with the project?” or “What are all of the things standing in our way?” or “What could prevent us from delivering this project on time, on budget, and on scope?”  Don’t just ask the question one time or one way.  Ask it over and over, in multiple different ways; ask every stakeholder you can think of; and then go back and ask it again. 

Second, I make a plan for how we’re going to deal with the obstacles.  With the team, (or a representative subset) we review the list of risks: categorize them, prioritize them, and make a plan for the highest priority risks.

Why categorize? Many of the stated risks likely have a similar root cause, a similar impact to the project, or could be addressed with a single response strategy.  Sorting them into groups helps manage them more efficiently.  For example, if there are several risks all tied to the quality of the data, or several that could be mitigated through certain communication activities, or several that involve the vendor, it’s easier to manage them in risk “groups”.

Why prioritize? Not all risks require the same amount of attention.  Determine which ones, if they do occur, can do the most harm to the project, and pay more attention to those.  Determine which ones are most likely to occur, and pay more attention to those.  If there are some that are pretty certain to occur, plan immediate action to reduce their impact.

Why as a team?  Collectively, you’ll generate better ideas, and the team will feel more ownership in the risk management overall.  Create opportunities for the team to problem-solve collectively and make a plan for the risks. If a risk was stated as If the vendor doesn’t deliver within the desired time frames, then the project may be delayed then reframe the question to the team as What can we do to make sure the vendor delivers within the desired time frames? or What can we do to prevent the whole project from being late if the vendor delivers late? And then, write down what the team decides.

What to document?  For each of the highest priority risks, document an approach that solves the right problem.  Document the level of detail that you need to remember the solution, but not so much that when things change down the road, you have a lot of rework to do. 

  • Are you going to take action now to prevent the risk from occurring?  If so, who will take what action? 
  • Are you going to wait and see if it starts to come true before taking action?  If so, who is watching for what, and what’s the planned action?

Third, I keep the project risks in the forefront, and “manage to the risks”.

Keep the risks in front of you, in front of the team, in front of the sponsors.  Keep the highest priority risks listed on your standing meeting agendas, or on a poster in the project team room. 

As the project progresses, continually monitor the risks, close those that can be closed, adjust priorities as probabilities and impacts change, and add new risks as they are identified. 

And here’s the key: if it looks like an anticipated risk is becoming a reality, then take action.  Review the action plan you had documented to ensure it’s still the right approach, and put it into motion.

There are plenty of folks out there anxiously waiting for the chance to itemize all the things they think will go wrong (usually accompanied with all the things they think are already going wrong), so the first step above is usually not that much of a stretch.  But I believe we have to go further than the basics of step one. Effective risk management involves thinking through what could go wrong, making a plan as a team for how you’ll deal with the risks, and then actually living out that plan.  Skipping the first step is like going into battle unarmed.  Skipping the second or third steps just sets you up, when things go wrong, to have that same group of people shaking their heads at you, saying “I told you so.”

Read more from Sinikka's 4-part series:
Part 1: Crystal Ball, Anyone?
Part 2: What Could Possibly Go Wrong?
Part 3: The Project Manager and the Glass
Part 4: Told Ya So

Related Links
A comprehensive risk list can help you document not just the risks, but also what you'll do to avoid or combat them. Safety sensitive projects like medical product development demand more thorough documentation. Keep executives appraised of project and risk status with a short, easy-to-review form.

Not all comments are posted. Posted comments are subject to editing for clarity and length.

The comments to this entry are closed.

©Copyright 2000-2017 Emprend, Inc. All Rights Reserved.
About us   Site Map   View current sponsorship opportunities (PDF)
Contact us for more information or e-mail
Terms of Service and Privacy Policy

Stay Connected
Get our latest content delivered to your inbox, every other week. New case studies, articles, templates, online courses, and more. Check out our Newsletter Archive for past issues. Sign Up Now

Follow Us!
Linked In Facebook Twitter RSS Feeds

Got a Question?
Drop us an email or call us toll free:
7am-5pm Pacific
Monday - Friday
We'd love to talk to you.

Learn more about ProjectConnections and who writes our content. Want to learn more? Compare our membership levels.