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 Project Manager’s Cycle – Review Commitments

“Yes, Anita, your family needs you at this time of loss.  My thoughts are with you and your family.  Do what you need to do and take all the time you need.”

With this post we conclude the “behind the scenes” activities of The Project Manager’s Cycle.  You won’t find this activity in A Guide to the Project Management Body of Knowledge (PMBoK).  This activity is performed during the Managing & Controlling practices of the Software Engineering Institute’s (SEI) Capability Maturity Model Integrated (CMMI), for example, the CMMI for Development, which can be downloaded.

I often take for granted the people that make commitments enabling my project to advance and succeed.  It is humbling to be reminded of the ephemeral nature of their commitments, including:

·         The Sponsor, for committing to the all-important budget

·         Owner(s), for committing resources, for committing to the requirements and for committing to success by running political interference

·         Resource Managers, for committing team members when needed

·         Project Team Members, for committing to their estimates, schedules and deliverables

·         Vendors, for committing more than just the terms of the contract or SOW, but to committing their organization’s reputation to our project success

Commitments are universally conditional (implicitly if not explicitly).  You have money as long as market conditions are the same and you maintain the ROI;  you have political protection as long as it in your Owner’s best interest to provide it;  you have resources and team members as long as the priority is the same and project schedule is consistent.

Because commitments are conditional, they are revocable.  Therefore, the savvy project manager will track all commitments made to and for the project and regularly reassess their reliability.  This is especially important when the project deviates from plan.  Which is why this is probably the highest priority for a project manager taking on a troubled or recovery project.  After all, the commitments are not just made to the project – they are made to the Project Manager.  And when these key stakeholders lose confidence in the PM’s ability to deliver, those commitments will dry up.

Have you taken a project commitment for granted that came back to cost you?  What did you learn?

A Philosophy of Projects and Products (Part 1 of 3)

Ron, the IT Director, was meeting with his managers.  “Phil, what is the status of the SAP implementation?”  “The PWC consultants are on schedule and on budget.”  Ron, looking across the table at the manager over the imaging applications, then asked, “Allison, how is the new fax/OCR product?”  “Ron, I wish this Brand X consulting firm we selected was half as good as PWC at schedules and budgets, then it would almost be worth it to continue using them. I’m going to have to continuously monitor their progress, but we should probably plan for a 100% overrun,” she replied.  Finally, to Dave who manages the finance applications, he asked about that status.  “We’re staying ahead of the vultures, but the primary focus is keeping the lights on and responding to the support calls.  We are running about normal on resourcing for maintenance and enhancement requests,” replied Dave.

This begins a three-part blog series on a rarely discussed but rather significant split in the way to look at project management.  The first two entries will take a look at PM from two common perspectives, then the final entry will address the impact and significance of this subject.

The PM environment I’ll discuss in this entry I’ll call Product Delivery (more accurately, Product & Service Delivery).  This is the classic craftsman model where process (and people and tool) maturity is used to enhance and optimize delivery of products and services.  This model is evolved from the journeyman, for whom every new creative effort is a original challenge.  By applying knowledge from lessons learned, best practices and risk management, delivery becomes more consistent, reliable, and predictable.

The core skill of the Product & Service Delivery (P&SD) organization is managing the product or service, their priority is product and service availability, and metrics focus on the product or service (i.e., PM practices are measured to produce more products, faster, for less cost).  Other characteristics of P&SD include a preference for milestones over deliverables, generally prioritizing scope over schedule or cost, resources (including PMs) are valued for their domain knowledge, and resources are generally shared between projects (new development) and maintenance/support.

Most IT organizations, for example, operate with this model and call what they do Project Management;  after all, they use processes and methodology modeled on the Project Management Institute’s (PMI’s) A Guide to the Project Management Body of Knowledge (PMBoK).  They may even have a Project Management Office (PMO) to drive PM best practices. 

The maturity model best aligned with Product and Service Delivery is the Software Engineering Institute’s (SEI) Capability Maturity Model Integrated (CMMI).