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.

The WBS - Intermediate

Two (or six) months into your project, you and your business owner disagree about whether a particular feature or component is included in the project.  You, of course, consider this controversial item obscure and expensive to include;  the business owner, in contrast, asserts that it is absolutely essential, the whole project is value-less without this item, and, further, that since it is in the original scope it shouldn’t cost more or take more time.  How do you resolve this dilemma?

Project Management success is determined by delivering both the project (what you promised) and customer/owner/stakeholder satisfaction (what they expected).  Failure at either of these is failure.  Even if you deliver the greatest technical solution imaginable, if the customer is not happy, you are not going to stay around long or get that next job.

Our success as project managers, then, is to get agreement up front for what we’re going to do, do it, and then get acceptance that we did it.  How then do we get agreement on scope up front?  How do we avoid the dilemma described in the opening paragraph?

The Work Breakdown Structure, which I’ve been discussing in the past several posts, is not an academic exercise.  It, along with the Task Dictionary, defines the scope of your project.  A well constructed WBS/ Task Dictionary agreed to at the start of the project by the key stakeholders will greatly reduce the kind of disagreements described above.  That is, the WBS becomes the basis for determining Project Change Management, and without the WBS it is just “I say – They say,” which ultimately leads to project failure.

Agreement on the WBS is more than just sending an email and asking for approval.  Sit down with your stakeholders, walk through each Deliverable and The Activities and The Tasks that comprise each deliverable.  Discuss what is included.  You’ll be amazed at the results.  Many misunderstandings will be cleared up here, early enough to easily resolve them and prevent acrimony later;  they will find that you’ve included activities that they disagree with;  they will identify missing activities;  and, most importantly, they will begin to take ownership of the mutual delivery of the project.

I’ll have more to say about Project Change Management in a future post, but the other essential value of the WBS is that it becomes the foundation for building the project schedule.  In the next series of posts, we’ll discuss what is needed to build a well-formed project schedule.

When was the last time you conducted a WBS walkthrough with your stakeholders?  How did it turn out?

The Task

“Is the PaRC Coding task complete?” asked Evelyn, the PM.  “Yes,” responded Jeff, one of the best programmers, who then continued “I completed all of the coding yesterday.”  “But what about the unit
testing?” Evelyn followed up.  “No, I’ll get to that tomorrow,” replied Jeff.  “But the task includes coding and unit testing,” Evelyn noted exasperatedly.  “It isn’t done until both are done and it’s ready for turnover to the test group.  You know that.  Why do you tell me it’s done?”

I’m trying to build some of the context for presenting best practices, but PM best practices are difficult to document, in this case, because everything is so integrated.  You can’t really discuss one thing being a “best practice” until you have a context for that practice to be best in.  For example, you can’t comprehensively discuss estimating without also including risk management.  You can’t discuss reporting best practices without addressing stakeholder management.  You can’t address acceptance management without addressing scope management, which also has to involve change management.

So I’m going to start with a fundamental and see if I can build a base sufficient to start expanding into more complex topics.  The Work Breakdown Structure (WBS) is a core project management document and the task is the atomic element of the WBS.

Typically a task should be a single component of work delivered by one person.  This would generally be a best practice.  I have frequently made exceptions to this practice, but that doesn’t prevent this from being a best practice.  And knowing when to make exceptions is part of the pragmatic, flexible responsibility of the good PM.

The task should have clear transitions.  The inputs, outputs, and hand-offs (in- and out-bound) should be clearly understood.  This is one of the main areas where I frequently experience problems, when I assume that team members clearly understand their tasks, including Done.

I’ve developed some techniques to address this problem.  PMBoK v4 references the WBS Dictionary, what used to be called the task dictionary.  The WBS dictionary is without question the appropriate reference for this situation.  But who has the time and budget to include one in the project?  What I’ve found that I can do for key project tasks is sit down with the task owner (Owner A) and the owner of the next (successor) task (Owner B).  In this facilitated discussion with Owner A and Owner B, we discuss what is included in the task, what is expected as inputs and outputs, and what constitutes done.  This often identifies differences in expectations by the owners which, without the conversation, would’ve left  some ball dropped.

The key point I make sure to include in the discussion:  Owner B has to accept the results before the task can be closed for Owner A.  Universally the task owners know more about their jobs than I do, so I don’t have to impose the general task scope, all I have to do is make sure each successive owner is clear about the task boundaries.  It’s amazing how many problems this little discussion has prevented.

Call it a dynamic WBS Dictionary, maybe.

Do you have any experience with a WBS Dictionary, or problems with not having one?