Risk management, like nearly all project management knowledge areas, is iterative. We don’t just identify risks at the beginning of our projects. As we learn more about what we are expected to deliver, our risk registers experience progressive elaboration in the same way as does our knowledge of our customer’s requirements or our work breakdown structure.
While this iterative nature of risk management helps to increase the currency of risk information, it does have a dark side.
The risks we’ve most recently analyzed might appear to be more relevant than those identified much earlier in a project’s life. Given how busy we all are, if those older risks have not yet been realized, it can be tempting to assume that they can be safely ignored. And when our vigilance drops, that’s usually when those risks will strike.
To protect against this, we need to implement countermeasures which won’t consume much effort, but can provide us with sufficient lead time to recognize that a risk may be realized so that we can execute response plans with a higher probability of success. This is why it is important to identify risk triggers which should be as specific as the risks they are associated with.
It’s also a good reason to consider going beyond simple probability and impact-based assessments of risk severity by incorporating the failure mode effects analysis practice of estimating how easy it is to detect that a risk is about to be realized. By doing this, a moderate risk with low detectability will gain importance relative to those which we can see a mile away.
Of course, none of this matters if risk information is not reviewed regularly.
You may want to review risk triggers for your key risks at each team meeting to find out if any have been detected. You might even consider creating a “Project’s Top Ten Most Wanted” cubicle poster highlighting the triggers tied to your most critical risks.
Whatever techniques you use, regular reviews of meaningful triggers can act as a gauntlet around your project, ensuring you don’t get rear-ended by a risk Mack Truck!
(Note: this article was first seen in kbondale.wordpress.com's rear view mirror in June 2015)
Through education or experience most of us learn early in our project management careers about the dangers of using percentage complete for any activity where the work completed cannot be reliably measured. This is unfortunately the case for most knowledge-based work.
While a contractor can examine a wall being built and verify what percent of the work is complete based on how much of the wall has been finished, a development lead looking at the source code for a given function will be unable to come up with more than an educated guess as to what the true status of developing that function is. That is why we are encouraged to ask objective questions such as "How many hours of work is remaining?" or better yet, to utilize conservative reporting methods such as 0% and 100% or (for those in the agile delivery space) Not Done and Done Done.
So why wouldn't this also apply to resource availability?
Unless you are benefiting from either a project-oriented or a long lived team, chances are your team members will not be dedicated to your project.
I'm not referring to the normally expected non-project activities that everyone incurs such as department meetings, HR activities and so on. While there is an ebb and flow to those, there is usually a combination of historical data (e.g. at least 20% of the month before fiscal year end has been proven to be spent on annual performance review activities) and personal plans such as team vacation calendars to provide confidence about those estimates.
What concerns me is when a people manager gives me a percentage availability. "I can't provide Bob full-time, but I can give him to you for 50%". This occurs so frequently that we rarely challenge it unless we are sure that a staffing shortfall will critically impact our project's objectives.
But what does 50% of Bob really mean?
And what will be the impact to your timelines and other project success criteria if you made the wrong assumption?
So the next time someone gives you a percentage availability commitment for a team member, ask a few questions to really understand how much time that person will be dedicating to your project and when.
If your body temperature is average but half of you is in a freezer and the other half is in an oven you aren't likely to be too happy!
For organizations lacking standard practices in project portfolio and project management, risk management might seem like an unnecessary use of resources. I’ve even heard some executives say that with insufficient resources to deliver the expected scope on all of their “critical” projects, how can they afford to have project teams “waste” effort on risk management activities.
For those of us that have come through the PM “school of hard knocks”, such statements might appear myopic if not downright idiotic. However, this leadership perception of low value in this knowledge area often stems from poor implementation of risk management practices – an article I wrote a few years back highlights some of these issues. Buried within that article was an analogy that might help you convince your executives of the benefits that value-based risk management can offer.
Ask the nay-saying executive whether they have purchased house insurance.
If they have a mortgage on your property, their lender will probably insist on coverage for at least the value of their loan. However, once a mortgage is paid off, the home owner could elect to avoid insuring their house, but most people would likely still maintain this insurance over the duration of their home ownership. If you ask the executive why they do this, they’d likely offer some variant on the following rationale: “to protect my investment from the unknown”.
Probing deeper, if you ask the same executive how much they spend on home insurance each year, and you multiply that by twenty years, you would likely come to a figure that is at least 2% of the original purchase price of the home. Insurance is just an example of the transfer risk response approach. If we added all the costs we incur to mitigate home risks, the 2% estimate would likely be significantly higher.
So, after having led the executive through this analogy, leave them with the question “You agree that it is important to insure your home against the unknown, so why not apply the same approach to the projects you are sponsoring – surely they are as important to the organization as your home is to you?”.
Investing in the right amount of risk management “insurance” can protect your project from the catastrophic costs of fire-fighting.
(Note: this article was underwritten by me in February 2011 on my personal blog, kbondale.wordpress.com)
A LinkedIn question a while ago asked whether Murphy’s Law is inevitable on projects.
The very definition of projects favors the conditions for things to go wrong as we are striving to create a unique product, service or result.
In addition, projects (most constructive ones at least!) would appear to run counter to the second law of thermodynamics as they are an attempt to bring order to chaos or to reduce entropy.
Given these conditions, one would expect that Murphy would run rampant in projects, and in many organizations this seems to be the case. I’m not a fan of pessimistic project management as that state of mind can result in a self-fulfilling prophecy. Blind optimism isn’t an appropriate state of mind either. Instead, Murphy’s Law should validate the need for project and resource management practices:
Through consistent use of PM practices, you too can embrace Captain Kirk’s belief “I don’t believe in the no win scenario”!
(Note: this article was originally published by me in May 2011 on my personal blog, kbondale.wordpress.com)
As project managers, we may occasionally feel like secret agents having to walk the tightrope between optimism that our project objectives will be met and the educated cynicism of having lived through the impacts of Murphy’s Law on more than one project!
Nowhere does this balancing feel more precarious than when we are facing a potential delay to a key project milestone that cannot be absorbed.
Should we raise the flag early which might get us points from our team members for taking their concerns seriously but risk antagonizing our sponsor or other stakeholders who don’t share these concerns or do we remain optimistic that we’ll be lucky but alienate our team members which could in turn run the risk that their pessimism become a self-fulfilling prophecy?
While there is no fool-proof panacea, the following questions might help.
1. Have you got an independent opinion of current status? Sometimes it helps to just have a fresh pair of eyes review work remaining relative to the looming milestone date to either refute the “doom and gloom” or to suggest a creative solution that has not been considered yet.
2. If you are in a matrixed organization, do the functional managers support their resources’ concerns? Having good relationships with the resource managers enables you to engage them in either validating the concerns of the team members or supporting your efforts to meet the deadline.
3. Have you truly assessed and eliminated all viable options for meeting the dates? Fast tracking, crashing, multiple resource shifts to take full advantage of remaining days and scope reduction or deferral should all be considered.
Assuming there is no natural way in which the deadline can be met, present the grim news to your customer and key stakeholders backed up by evidence that you’ve “done your homework” and supported by options that should help to mitigate the impacts of the delay.
On the other hand, if you feel that the milestone can be met, a potentially harder task remains – how do you reinvigorate your team with the drive and optimism crucial to maintaining the productivity levels required to meet the date? This is where you’ll need to pull out every soft skill you possess.
“When a man is convinced he’s going to die tomorrow, he’ll probably find a way to make it happen. The only one who can turn this around is you.“ - Guinan, Star Trek: The Next Generation
(Note: this article was originally beamed up with me in November 2011 on my personal blog, kbondale.wordpress.com)