|
Home Our Company Public Workshop Schedule In-house Delivery and Consulting Workshop Descriptions Site Map Articles |
Risk - The Complete Tool Set
Getting Our Language Right
Fig. 2 - Risk? I hear you clearly
Surprisingly, the most important step in adopting a more professional, consistent and transparent approach to risk management is to agree on terminology. For example, if you talk to business people about risk then depending on whether they have a bank, insurance, defense or marketing background, they will be thinking of a completely different set of risks from the ones that a software project manager would be considering.
In fact, many books on and models of risk completely confuse people by attempting to include all types of risk into one model1. Simply using the term "risk" opens the risk of miscommunication (see Figure 2).
In the business and project environment, our group has identified five different but completely related risk groups or categories:
|
the exposure the organisation faces upon project failure; |
|
the factors which could cause a project to fail; |
|
the risks the organisation faces in continuing support of the system, product and business processes delivered by the project; |
|
the factors which could lead to a lack of benefits realisation; and |
|
the impact on your personal career and life if the project fails (or succeeds). |
As indicated in Figure 3, these five risk groups are different but often they are related. It is common that the higher the Project Risk, the higher the probability that the project will fail and that the organisation will be exposed to the Business Risks. In addition, the higher the Project Risk, the higher the Benefits Realisation Risks would be as well as the Production Support Risks2.
Fig. 3 - Different but related risks
While the inter-relationship between the different categories of risk is very project specific, the one relationship that is fixed is the one between Project Risk and Business Risk. Put simply, the higher the risk of the project the higher the probability of failure and exposure to Business Risk.
For example, a bank may be undertaking a project to implement new credit controls demanded by government legislation. The Project Risk is assessed by the project manager as being high, as the new legislation involves complex changes to sophisticated existing information systems and business processes. The Business Risk is also assessed as high because, if the bank does not implement the new credit controls by the deadline, it will face possible fines, loss of trading license and substantial public scrutiny in the media. However, the resulting changes to existing systems and processes are relatively easy to support so the Production Risk is assessed as low. Given that the legislation is externally enforced, the Benefit Realisation Risk is assessed as medium. Finally, the Project Manager has no experience with similar projects, the long hours required for implementation and lack of organisation buy-in (typical for many mandatory legislative projects), the Project Manager assesses the Personal Risk as high.
The assessment of all risk categories requires consideration of different risk factors [see attached risk assessment tools], though the control and management of risks is similar for all categories.
Subjective verses Objective Risk Assessment
Given that there are at least 100 plus factors which can be included in a risk model, it is difficult to gather objective measures for many of these factors. In the subjective approach, the complexity of the software is determined as Simple, Average and Complex depending on the group discussion.
False Science
Most approaches to "measuring" risk include the use of probability and impact weighting factors. For example, the probability of requirement changes is guessed as 0.6 and the impact on the project is guessed as 0.8. Theses two guesses are then multiplied together to give a risk weight of 0.48 (in reality, a guess).
We prefer a simpler and more easily understood technique that puts the probability into the risk question.
"The requirements are unstable".
For many business project areas, there is little or no consistent measuring of the impact of the various risk factors. For example, what is the productivity difference of an expert Marketing specialist versus and inexperienced Marketing person in developing a new television marketing campaign?
In software development, there are a number of systemic studies (see Capers Jones [1992, 1996], Barry Boehm, [1981]) that provide generic measures for a number of Project Risk factors. For example, the use of Function Points can provide an objective measure of software complexity/risk where there is an agreement that Simple means <100 AFP, Average means 100 - 1000 AFP and Complex is >1000 AFP.
Unfortunately, many of the risk factors are not practically measurable. For example, the risks associated with developing software for four different client or stakeholder groups who are engaged in advanced political warfare over the project are clearly much higher than those associated with a product for one supportive client. To quantify such factors and their impact is beyond the practical limit for most organisations.
A sensible approach is to quantify which factors are easily measured and use subjective group agreements for the remaining factors.
- In addition, most people (including me) are confused by the proliferation of technical risk jargon. At the 2003 Global Association of Risk Professionals Conference in New York it was noted that professional risk managers must learn to communicate in English to their clients (Fast Company, May 2003, pp 38).
- The relationship between the various risk groups is project specific so it is possible to have a high Project Risk but a low Benefits Realisation Risk and so on. However, the relationships described above are more common.