ArtsAutosBooksBusinessEducationEntertainmentFamilyFashionFoodGamesGenderHealthHolidaysHomeHubPagesPersonal FinancePetsPoliticsReligionSportsTechnologyTravel
  • »
  • Business and Employment»
  • Business Management & Leadership

Make a Project Risk List With Risk Identification

Updated on July 31, 2012

Risk Identification in One Word

Oops! That's the word. If you don't want to end up saying, "Oops! I didn't see that coming," when your project hits a snag that makes it run late or over-budget (or worse), then do good Risk Identification and create a great Risk List.

Why Think About What Could Go Wrong?

Many projects are launched with little planning. Even when there is a defined goal and a list of work to be done, people rarely pay attention to what could go wrong. And what they don't pay attention to what could go wrong, it comes back and bites them in the butt, delaying the project, adding to the cost, making the customer unhappy, and sometimes causing complete project failure. Over 55% of all projects fail, and good project risk management is a key step in improving your success rate. And the first step in project risk management is making a risk list, following a process that the PMI formally calls Risk Identification.

When we do Risk Identification - when we simply think about what could go wrong - we naturally think about how to prevent those events. And our written Risk List is the first of four steps in risk management that we use to ensure things go right, all the way up to on time, on budget, successful delivery of project results.

The best time to do Risk Identification is as soon as the Scope Statement, the core of the project plan, is complete.

Oops! Weren't We Going to Cross That Bridge!?!

"We'll cross that bridge when we come to it" is NOT good project risk management.
"We'll cross that bridge when we come to it" is NOT good project risk management. | Source

How to Identify Risks

There are several techniques for identifying project risks. The first one is fun - and it's often enough!

Proactive Worry - A Brainstorming Session

When the initial plan is clear, the team has a vision of what we are making, and is excited about it. Host a brainstorming session - a pizza party is a good idea - with a light positive attitude and a serious topic. The topic is, "What could go wrong?"

I love running Proactive Worry planning meetings. It is the essence of everything I do - a clear orientation towards success, optimism, and a willingness to face challenging realities right up front. Running a proactive worry session during project planning makes just as much sense as packing a first aid kit, bug spray, a flashlight, and a space blanket before a hike up a mountain!

Make sure at least two people are taking notes, and record the session as well. Present the idea that if we think about what could go wrong, we can make sure it doesn't happen this time, or at least be ready for it. Lay out some ground rules:

  • If someone mentions a past mistake, they don't say whether they did it, or someone else did, or if they just heard about it somewhere. The past doesn't matter.
  • Don't worry about the consequences of the risk. It doesn't matter if it creates a small delay, or ruins the whole project. We'll deal with that later.
  • Don't worry about the likelihood that the event will happen. It could be something that goes wrong all the time, or something that only happens once in a blue moon. We'll deal with that later, too.
  • Don't worry about what to do if the problem happens. We'll deal with that later, too.

The note-takers should catch the name of the person identifying the risk, and the risk event. Anything else that comes up - like items on the list above - it's great if you get them, and okay if you don't.

During the conversation, don't let things get bogged down on any of the above issues, or on blame for past mistakes, or on arguments over whether a certain risk could really happen. Keep things moving forward to identify new risks.

Launch the discussion by asking the question: "What went wrong on projects we did like this in the past? Let's think of as many things as we can."

If the discussion lags, here are some other questions:

  • What about other projects you've done, even at different companies or on a totally different type of work. Is there anything that went wrong there that could go wrong here?
  • Have you heard any stories of problems on this type of project?
  • Let's think of some really ridiculous, outlandish possibilities. What if space aliens abducted Jim, the lead programmer? (Oddly enough, this works. Someone might say, "I thought Jim was an alien," and everyone will laugh. Then someone says, "actually, I was on a project where the lead programmer got really sick. That could happen." And that's another item for the risk list.)

If you have a competitive group, then keep a tally of who comes up with the most ideas to put on the risk list. That will get you more items, and also keep the team members from ragging on each other.

At some point, the flow of ideas will slow down. You've probably got a pretty good list there. In fact, if Pareto's Law is right, you've probably got about 80% of what could go wrong. Have the note-takers read back what they have, a few at a time, and ask the team if hearing the list sparks any new ideas about what could go wrong. Get a few more items, and wrap up the meeting. You're done!

Analysis of Records From Past Projects

If you keep records of past projects, or, especially, if you have post-project reviews that were written up at the end of past projects, you can review them. Take these steps:

  • Look for anything that created delay, caused the project to go over-budget, or caused the project to fail.
  • Look deeper, for things that caused misunderstanding with the customer or on the team, or that made it difficult or impossible to implement desired features.
  • Whatever you find, figure out why that happened. What was the first event that caused the problem or delay?
  • Ask if that event could happen on this new project. If it could, add it to the list.

Build and Use a Comprehensive Risk List

The list you make from your brainstorming session and analysis of past projects is a great tool; you can use it more than once. Keep it, and keep adding to it, and you will create a comprehensive risk list.

Once you have a comprehensive risk list, it is very easy to make a specific risk list for any future project. You can do it in three steps:

  • Make a copy of the comprehensive list, and cross off anything that absolutely could not happen on this project. (For example, if "ice storm closes construction site" is on the list, and this project is in July in Florida, you can cross it off.) Leave everything else on.
  • Look at the work on this project that is unique. Ask what could go wrong on the unique work of this project and unique features of this project deliverable.
  • Look at anything new or different - a new team member, or a new location, or a new processing method. Ask what risks these new and different elements add to the project.

Make a List of External Dependencies

You are in charge of the project team. Yet there are sure to be some things that the project team needs that are coming from outside the team. Common items and some risks associated with them are listed in Table #1: Common External Dependencies and Risks. Note that the customer is outside the team, as are senior executives of the company.

Anything we need to do our work is something we depend on, and, in project management, we call it a dependency. Within the team, we have internal dependencies. For example, if Sally and Ibrahim are on our programming team, and Sally has to write a code module so that Ibrahim can test it, then Ibrahim's work depends on Sally's, but that is an internal dependency. On the other hand, if Ibrahim is a new employee, and the company ordered him a computer, but it hasn't arrived yet, and he can't work without a computer, then that is an external dependency.

And every external dependency goes on the risk list. We need it, or we will run late, or over budget, or be unable to do our work. And, since the source is external to the team, it is not under our control. It might, in fact, arrive late, broken, or not at all.

Adding external dependencies to our risk list will help us manage the project later on. We'll double-check those items and make sure we get them before we need them. And we'll make sure they work, too.

Positive Risk

It's good to identify positive risks, as well. These are things that could go unexpectedly right. What unexpected event could speed up progress on the project, or save money, or even make project results more valuable? Knowing these events can occur, we can work to make them more likely, and be ready to manage the change they bring to our plans.

I've Got a Risk List - What's Next?

If you've done the four steps above, you've got a great risk list. Even if you've only done one of the steps, you're off to a good start. Now that you have a risk list, what's next?

When we've made the risk list and done those two steps, we've got a Risk Plan. Don't throw it in a drawer. Put it to good use by Managing Risk to Success With Project Risk Monitoring and control.

Do You Think About Project Risk?

Pick the answer closest to the way you usually work:

See results


    0 of 8192 characters used
    Post Comment

    No comments yet.