By Peter Symons, OARBIC (Part 1 of 2)
Nov. 11, 2005 – “Great Deeds are Usually Wrought at Great Risks.”
The Greek historian and traveler, Herodotus, proclaimed the above in 450BC. My guess is he wasn’t running an IT project at the time, or he would have added “Great Deeds usually succeed if Great Risks are managed.”
The question is of course, how do you manage risks?
There are thousands upon thousands of articles, sample spreadsheets, sample processes etc. all devoted to measuring and managing risk. Entering “Managing Risks” into Google returns over 31 million results!!!. Indeed, Managing Risk is one of the nine major areas of management expertise in the Project Management Institute’s PMBOK.
But, with one major exception (The Standish Group) there are very few places that discuss what could be considered to the be first essential element in Risk Management and that is to identify the difference between what could be called “Inherent Risk” and “Operational Risk.”
“Inherent risk” is the risk that a project has at the outset of the project. It is the measurement of items that will impact the likelihood of project success, even if nothing goes significantly wrong during the life cycle of the project.
“Operational Risk,” on the other hand, is the risk that things will go wrong during the life cycle of the project.
Like our Program Management article, this article is in two parts, this week we’ll look at “Inherent Risk” and next week we’ll look at “Operational Risk.”
First, we need to understand the difference between the two types of risk. Inherent Risk is very different from Operational Risk:
Operational Risks are those things that might happen as the project progresses. The management of Operational Risk is the attempt to minimize the damage if something does go wrong (and something will go wrong by the way!).
Inherent Risk has already happened before the project starts and the management of Inherent Risk is to both gain an understanding of what you face before you start the project and the attempt to mitigate the impact of those things.
A good analogy in sky-diving:
If you jump out of an airplane with all the correct sky-diving equipment, there is still an Operational Risk that your parachute won’t open. You manage that risk by A) training what to do in an emergency and B) having a backup parachute strapped to your chest
On the other hand, if you don’t have any sky diving equipment at all and you’re about to jump out of the airplane, you have an excellent idea of the Inherent Risk and, unless you’re completely void of imagination, you should have a pretty good idea about the outcome.
It is exactly the same with IT projects. The only difference is the Inherent Risks in IT projects are not as obvious as the lack of a parachute. The question then becomes what are those Inherent Risks.
The leaders in research in the understanding of Inherent Risk are The Standish Group (www.standishgroup.com). In their groundbreaking first paper in 1994 , the Standish Group surveyed 365 senior IT managers (typically IT VPs) and asked them about projects that had succeeded and projects that had failed and asked them to quantify what were the contributing factors to the success or failure of the projects. The results were startling in that the answers they received were consistent across the majority of respondents. Although there were many factors quoted, there were 10 basic themes that came through in almost all the answers. They were:
User Involvement: 15.9%
Executive Management Support: 13.9%
Clear Statement of Requirements: 13.0%
Proper Planning: 9.6%
Realistic Expectations: 8.2%
Smaller Project Milestones: 7.7%
Competent Staff: 7.2%
Clear Vision & Objectives: 2.9%
Hard-Working, Focused Staff: 2.4%
That said, it is important to put all this in perspective. Projects that do not have User Involvement do not automatically fail, it’s all question of risk. The less of the 10 success criteria a project has, the riskier the project is to undertake.
For example, if a project does not have User Involvement but has all the other factors, assuming a reasonably well managed project, the risk level is comparatively low. However if a project has 100% User Involvement but none of the other success factors the risk of failure is very high, no matter how well run the project is.
Standish refines their research on an annual basis and has, through wider experience changed both the content and the sequence of their 10 factors slightly. They have also added a points system, based on the relative importance of each item, to allow the overall measurement of the Inherent Risk Factors. This point system allows you to “rate” each of the 10 areas. For example, if you have complete Executive Support, count 18 points, if you have no Executive Support count 0 point (and look for another project!), if you have average Executive Support, count 9 points. Although Standish does not publish any criteria for allocating points, the process works well if used with some common sense. Their current success criteria and point allocation is as follows:
|3||Experienced Project Manager||14|
|4||Clear Business Objectives||12|
|6||Standard Software Infrastructure||8|
|7||Firm Basic Requirements||6|
From this points system one can develop a sliding “Success – Failure Scale” where 0 is more or less a guarantee of failure and 100 is a strong indicator of success. It is important to understand and share with your senior management where your project is on the scale as this status should be well understood.
Over and above the Scale, however, each factor also needs to be examined. A project with a total point count of 76 is a reasonably low risk project, assuming the 24 points that are missing are spread across all 10 factors. But a project with a score of 76 that scored 0 in both Executive Support and User Involvement is a much riskier undertaking.
The other advantage this analysis brings is it allows the Project Manager to understand the risk(s) that his or her project is facing, which allows the Project Manager to more aggressively manage those risk(s).
For example, if you are the Project Manager for a project that has a 70 point score but scored only a 2 on User Involvement, although the project has a reasonably good score there is one critical element (User Involvement) that is very low. A savvy Project Manager would either solicit more User Involvement or, if that were impossible, then they would consider supplementing his or her team with some highly experienced Business Analysts that fully understand the user’s business and the user’s needs.
Some items are, of course, harder to mitigate than other, for example, a project sponsor who is paying for a project should be very hesitant to invest money in a project that scored poorly in the Experience Project Manager criteria. It would be very difficult for a project sponsor to manage this risk unless they had the time and expertise to provide significant support to the not-very-experienced Project Manager.
Regardless of where the risks are, the old expression forewarned is forearmed is very true when it comes to risk management and a solid understanding of a project’s Inherent Risks is an excellent place to start a project.
Take a look at the Standish Group’s web site; it has some excellent information that, if applied, can give you a much better understanding of the risks your projects are facing and therefore give you a much better ability to mitigate those risks. Now, if Standish would only pay me a commission!!!
Continue to Part 2
OARBIC Inc. is a specialized IT consulting firm helping the property and casualty insurance industry make older systems behave like new ones – and new ones behave the way they should.
We offer an array of consulting services, plus our OSEA software solution is specifically designed to extend the life of legacy applications to allow them to keep pace with change.
Our in-depth knowledge of the property and casualty insurance industry and our access to a global network of talented, specialized IT professionals, sets us apart from other consulting companies. More at http://www.oarbic.com/