Where to Find Risks

"Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so.”

                                                                                                - Douglas Adams

As I mentioned in my previous post,  Risk Buffers – An Example, this post is dedicated to identifying risks.  The only real way to find risks is by experience, and if you don’t have the experience yourself, then you must rely on the experience of others.  I’ll discuss three reliable sources for finding risks (but this is not exhaustive).

A taxonomy is a schema for classifying things.  The library’s Dewey Decimal System and the Species-Genus-Phyla (or whatever it is) system that biologists use for classifying animals are both taxonomies.  Risk taxonomies have been developed for classifying and organizing risks.  Since the taxonomy is exhaustive, the beneficial aspect of this is that you can then use these risk taxonomies to make sure you consider all areas of risk.

For IT and service projects, the Software Engineering Institute’s (SEI’s) Capability Maturity Model (CMM) developed a risk taxonomy (tr06.93.pdf – Taxonomy-based Risk Identification) twenty years ago that is still applicable.  I have Appendix page A-1 with me on every project and refer to it often.  For each entry, I ask the question:  Are there any xxx risks?  For example, for requirements stability, I ask:   Are the requirements stable?  Other industries have appropriate risk taxonomies available via the popular search engines.

These risk taxonomies are appropriate for finding product and service delivery risks, but not optimized for finding project delivery risks.  For that, PMI’s Organizational Project Management Maturity Model (OPM3) is a better source for identifying risks, though it’s cumbersome.  Basically, areas where the organization is not mature for project management are opportunities for risk.

These taxonomies and maturity models are sources from other’s experiences to help identify sources of risk projects in general.  Getting specific to your project, another useful technique for identifying risks (opportunities and threats), is work with your team or task owners and go through the WBS at a Deliverable, Activity, or Task level and ask them to estimate the Optimistic, Most Likely, and Pessimistic schedule for each.  It’s really amusing that I can ask the project team if they can identify any risks and they’ll consistently say “No.”  But they can confidently give me O, ML, and P estimates, then I follow up with:  What about the Pessimistic estimate can make this be late (or what has to happen for us to achieve the Optimistic estimate)?  Then, they can give me both threats and opportunities.  Amazing.

Finally, a reliable source of risk that you never want to miss is your assumptions.  An assumption can be defined as a risk without an owner.  Project estimating assumptions, task estimating assumptions, all assumptions need to be formalized and documented in the risk register.

In the previous post with the example risks, did you notice anything special about “risks” #3 and #4?
3.       Ice could be so bad that your office closes for the day
4.       You are low on gas and need to refill before you can make it all the way to work

Did you recognize that neither of these are risks?  I’m being somewhat pedagogical to demonstrate my point here, but to complete our task, you have to go into the office.  For “risk” #3, since the office is closed, you can’t complete the task.  Part of the definition of a risk is that you have to be able to “control” the risk (mitigate, avoid, transfer or accept).  This is why civilization-destroying asteroid collisions are not project risks.  For “risk” #4, this is not a “might happen in the future.”  It exists and must be dealt with, so it is not a risk, it is an issue. 

To summarize my comments from today’s post:
·         Use taxonomies and maturity models to identify sources of risk
·         Look for Product/ Service risks
·         Look for Project Delivery risks
·         Use your project team to identify risks (opportunities and threats)
·         Formalize assumptions into risks

Do you have suggestions or techniques for finding risks?

© 2013 Chuck Morton.  All Rights Reserved.

Risk Buffers – An Example

“President Bush has said that the economy is growing, that there are jobs out there. But you know, it's a long commute to China to get those jobs.”
                                                                                                - Tom Daschle

In The Schedule – Risk Buffers, the concluding post of a series on developing the well-formed schedule, I glossed over the complexity and details of planning project risk buffers.  I’d like to revisit the topic in more depth over the next few posts.

However, before I go into the complexities, I would like to present a very simple example, one I hope everyone can relate to, to demonstrate the concepts.  You are probably quite familiar with your commute:  you’ve driven it many times and you know what time you have to leave to generally get to work on time.  Even so, most commuters are occasionally surprised by unexpected traffic conditions – weather, wrecks, and road work, for example.  To demonstrate how to determine risk buffers, this exercise will touch on four of the six PMBoK Project Risk Management processes:  Identify Risks, Perform Qualitative Risk Analysis, Perform Quantitative Risk Analysis, and Plan Risk Responses.

For this example “project” we’ll only have one task:  Drive to work.  My next post will focus on identifying risks, so I won’t dwell on that step here.  For this exercise, let’s say you have these risks:

1.       There could be rain
2.       There could be snow or ice
3.       Ice could be so bad that your office closes for the day
4.       You are low on gas and need to refill before you can make it all the way to work
5.       There could be a wreck that causes a slow down
6.       There could be road work that causes a slow down
7.       There could be road work that causes a detour

(Do you see anything noteworthy about “risks” three and four?  I’ll have more to say about these in my next post.)

Something that is often missed or glossed over is dealing with Opportunities (the opposite of risk threats).  If your task is estimated to a 50% probability, there is as equal a chance of it coming in early as there is it coming in late, so you need to factor in and exploit (or enhance, share or accept) the opportunities.  For example:

8.       Traffic could be very light
9.       There could be a wreck in a location that causes your commute to be lighter than normal
10.   All the traffic lights could hit perfect for you today

The next step is to qualitatively assess the risks.  The objective of this step is to determine those risks you are going to seriously pay attention to – those that you will quantify, determine the risk response, and monitor.  It is generally done by assigning subjective Low, Medium and High values to probability (the likelihood that the risk event will occur) and impact (how the project is affected if the risk event occurs).  For example, if it’s August, the likelihood of snow or ice (risk #2) is Low.  From this analysis you generally then disregard the Low-Low risks (though note that these values can change over time, so you must periodically re-asses your risks).

The list is now winnowed down to the select risks that will receive attention.  Determine a specific (time, money or both) cost to the project for each remaining risk (including opportunities) if it occurs.

Most of what I read at this point talks about mitigating the risks, but there’s a lot more to risk response than just mitigation.  For example, add tasks to the project (such as check the weather or turn on the radio to get a traffic update).  In addition, risk responses can be transfer (ask a colleague to be there for you in case you can’t get there in time), avoid (reschedule to another day when it won’t rain) or accept (add the time and cost to the schedule).

Finally, and where this has all been leading up to, is to add a risk buffer to the project as part of the risk response.  For example, if there is a 25% chance that a risk will occur that will add twenty minutes to the commute, then you would add a five minute risk buffer to the project (in our example, you would plan to leave five minutes earlier).  You would sum the values for each appropriate risk and opportunity and add a buffer for the total amount.

With this step, you have again increased the probability of getting to the office on time – er, that is, of completing your project on schedule.

I’ll be delving deeper into risks over the next few posts using this example to demonstrate the concepts.  What about risks – threats and opportunities – would you like to understand better?

© 2013 Chuck Morton.  All Rights Reserved.

The Project Manager’s Cycle – Conduct Project Team Meeting

“Alright, let me take a few minutes to update everyone from the Sponsor meeting.  You got the minutes, but I’ll drive into some of the content between the lines.  Then we’ll go around and let everyone give their update.”

I like to hold my project team meetings early in the week – Monday afternoon or Tuesday morning – and focus on what will be accomplished by the end of the week.  Over the years I’ve attended many other team meetings.  Those experiences, like my own early experiences where I focused on getting a status from everyone, provided a very accurate after-the-fact picture of project slippage.

We near the end of this series on The Project Manager’s Cycle.  The project team meeting is a different animal than the Client Project Meeting.  It doesn’t need the formality.  It’s where you surface the problems and develop an action plan for responding to them, so that you can go to the client with solutions, rather than problems.

I found that meeting early in the week and asking the team members what they were going to accomplish by the end of the week was effective at focusing their energies as well as driving out issues before they occurred.  There are only a few possible responses.  For example, if a team member explained that they wouldn’t complete a task on schedule because of a blockage that I could eliminate, I could do my job, keep them productive, and avoid problems.  Or if they commit to accomplish things that aren’t in the schedule, that creates an opening for me to ask questions to understand the variance.

The best case is if they commit to complete activities that are aligned with the schedule.  For most people, that duration is short enough that they have visibility into anything that would prevent them from completing the task.  So I can be fairly confident that if they say they’ll get it done that week, they will.

There’s one more question I ask, though, that builds on the commitment.  “What can prevent you from completing this task on schedule?”  This question is subtly powerful.  The inexperienced or naïve may say “Nothing.”  But this is a trap.   If they subsequently fail to make the commitment they cannot then roll out a series of excuses.  They have already stated before their peers that the only reason they would fail to deliver is their own.

The experienced, sharp, connected team members will use this opportunity to list all of the possible causes of failure or delay, which is just what I want.  I write the list down, then go through each item one by one.  These are the detailed task risks that you don’t generally hear about until they are brought out as excuses after missing the date.  By exposing them before the due date, as a team we can qualify them, prioritize them, determine the appropriate response, and assign an owner before rather than after the fact.  If something does happen, we have evidence of anticipating the problem and proactively responding.  Further, it gives me the opportunity to ramp up client or management resources in anticipation of a problem.

Further, when team members see that I am using the information to make them successful, they become even more open and trusting.

In terms of process, the project team meeting consists of the activities publish the meeting agenda;  conduct the meeting; and publish the minutes.  Inputs are team member individual status reports, the project schedule, and minutes from the Client Project Meeting.  Outputs may include updates to the schedule, Project Status Report, risk register, and issue log.

Most team members are forthright and dependable.  The challenge, though, is recognizing and motivating the remainder.  What do you do in your project team meetings to improve success, even from the challenging members?  Do you have other best practices to share for optimizing the success of your project team?