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 Activity

In my previous post, The WBS Basics, we developed a simple Work Breakdown Structure (WBS).  In previous posts related to this foundations series, I’ve discussed TheTask and Deliverables.  A WBS is, as previously noted, a hierarchical representation of the complete project scope.  (A list of all tasks without any organization structure would be more confusing that beneficial.)

But with a moment of consideration about the hierarchical nature of this representation, we realize that if we just have tasks at the bottom and deliverables at the top, we really haven’t improved the situation meaningfully.  With no hierarchy, a Deliverable with hundreds of tasks would be just as confusing as a project with hundreds of tasks.

Therefore, it’s easy to determine that for large projects, there could be several layers between the Deliverable and the Task, as represented by this diagram with arbitrary names for the intermediate levels.

A work breakdown structure is like an assembly Bill of Materials – it lists all of the components in the final product and shows graphically how they fit together from individual parts (Tasks), through subassemblies (Activities), to the top level assemblies (Deliverables).  And the WBS developed for project management much like the Bill of Materials developed for assembly and they serve much the same purpose.  Complex BoMs with randomly arranged layers are normal.  Likewise, there is nothing wrong with (defective about) a WBS like this and I’ve certainly seen many PMs comfortable with this (un)structure.

 

As already mentioned, large projects have many (thousands of) tasks and the hierarchical structure is needed to organize the work.  The intuitive choice for organizing the work, as a box is examined and decomposed, is to build the structure into progressively more levels, as shown above.  This is evident to most practitioners and quite obvious.

But this blog is for presenting Best Practices and I’m going to explain why an alternative, not necessarily as intuitive, is the Best Practice.  Let’s say you have a project template that you use that has four deliverables and usually takes a couple of months.  Thus, you produce a deliverable every couple of weeks.  Then you get a request for a really BIG version of this same project that will take two years.  The intuitive approach, as discussed, would be to build out detail within each box (for assemblies, what they would call exploding the BoM).  You would then have your familiar project structure with possibly several additional levels.

But do you really want to have only four deliverables over a two year period?  Do you want to “go dark” for six months at a time?  This is not a Best Practice.  All projects need frequent deliverables to get meaningful feedback on the quality of the work.  Consultancy PMs in particular benefit from frequent deliverables so that they can book the revenue.

As more deliverables are added to the WBS, it naturally flattens out so that a PM only needs a limited number of levels.  Gone are the Assemblies, Subassemblies, and Hemi-Demi-Semi-assemblies.  You can even deduce that a WBS with many layers would be a red flag to review the frequency and distribution of the deliverables.

I have run many large projects with only three hierarchies within the project:  Deliverable, Activity, and Task.  Further, unlike the example above that appears to have evolved randomly, a planned, well-structured WBS is the sign of an organized project.

Have you run a project where you didn’t have control over the WBS?  How did it turn out?

The WBS Basics

In the WBS, use nouns for deliverables and work packages;  use verbs to name tasks.

-          Danu M. Kothari, Managing Successful IT Projects with the basic “Tools of the Trade,” PMI ISSIG Webinar, July 20, 2006

I have talked about TheTask and Deliverables.  We now have the background to drill into the Work Breakdown Structure (WBS).  The WBS is a “deliverable- oriented hierarchical decomposition of the work to be executed by the project team to accomplish the project objectives and create the required deliverables.  It organizes and defines the total scope of the project.”  (PMBoK v4, p452).  Other than being a circular definition, this is consistent with what I said in “Deliverables as Revenue Agents.”  The stars of this definition are “hierarchical” and “deliverables.”   “Decomposition” and “scope” are supporting cast members.

Since Deliverables define the total scope, the structure starts like this:

Project WBS Example

·         Deliverable 1

·         Deliverable 2

·         Deliverable 3

We now have a decomposition of the total scope for a three deliverable project.  Is this a WBS?  No, the work (each Deliverable) has to be decomposed to the lowest level of work.  As I described in The Task, that level of decomposition is the task.  A well-formed task has one owner and one work product.  We can now show our example project structure as:

Project WBS Example

·         Deliverable 1

o   D1 Task 1

o   D1 Task 2

·         Deliverable 2

o   D2 Task 1

·         Deliverable 3

o   D3 Task 1

o   D3 Task n

This, in fact, is a simple well-formed WBS.  It has a hierarchical structure, is decomposed to the individual task, all tasks are contained within deliverables, and the deliverables (and tasks) define the total project scope.

In my next post, we’ll build on this foundation to explore variations on the basic WBS structure.

Are you ready for more advanced WBS concepts?

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?