|
containing uncertainty |
| we offer | our approach | material | links | ||
| consultancy
training presentations |
Nothing ventured, nothing gained.
The higher the level of risk you are prepared to take, the higher the rewards
that may be achieved. If you invest in the stock market, you will know
that it is usually the riskiest ventures that promise the highest returns.
And the same is often true in technology projects: the greatest potential
benefits may come from using the newest, and therefore most uncertain,
tools and methods.
Thus risk management is not about avoiding risks altogether. It is about facing risks deliberately and systematically, avoiding taking unnecessary risks, and carefully managing the risks that you have decided to take. Recently, one of the largest perceived risks for many software organizations has been related to the year 2000. Many organizations have conducted specific risk assessments of their millennium compliance programmes. However, our approach to risk management is applicable to any large project or programme. Veryard Projects carries out risk management assignments using the SCIMITAR risk management methodology, in association with Antelope Projects. |
concepts of risk
observations
contingency
|
|
|
|
The project increases its probability of satisfying its stakeholders. This should yield job satisfaction and career benefits to the individual project team members, especially the project manager. It also improves the team's collective identity, morale and spirit, which will be of benefit if the same team goes on to tackle other, perhaps even more challenging tasks.
Furthermore, since the risk management system allows risks to be openly spoken of, it allows project team members to share their worries openly, rather than feel obliged to suppress any mention of the negative. This makes it easier for the project to manage stress levels.
And for the stakeholders, the existence of a proper risk management system reduces the chance of unpleasant surprises.
| Let us suppose a large project or programme, involving some technological developments and some organizational changes, perhaps some changes in business practices. There are several interested parties, which we can refer to as stakeholders. | The word 'stakeholder' provokes the question: have we left anyone out? |
| Each stakeholder has a set of things that he/she expects the project to achieve. Let's call these objectives. | I'm not going to distinguish here between positive objectives (=creating new things of value to the stakeholder) and negative objectives (=not reducing the value of things the stakeholder already has). |
| The stakeholder may also have a set of expectations about the way in which the project is to achieve these objectives. Let's call these strategies. | In practice, objectives and strategies often get mixed up. Some people get very worried about this, but I think there are usually much more important things to worry about. |
| A risk is then anything that might get in the way of achieving an objective, following a strategy, or in any other way disappointing a reasonable expectation of any stakeholder. | Don't make too much of the word 'reasonable'. You can only discount an expectation as unreasonable after you've gone through a proper process of negotiating stakeholder expectations. If you haven't bothered to talk to a stakeholder, then any expectations - however ridiculous they seem to you - are reasonable. |
| To be manageable, a risk needs to be detectable. A risk indicator is an observable event or measure that indicates either that the unwanted event has occurred, is occurring or that its probability has significantly increased. | Sometimes known as triggers. |
| We then distinguish between internal risk and external risk. An internal risk is one which can be completely contained by the project, and does not need to be exposed to external stakeholders. | Example: We are planning to conduct volume tests this week. If the network goes down, or there is some other problem outside our control, we'll have to get a few people to come in at the weekend and do the tests then. Fortunately, there is a small allocation in the project budget for paying overtime, so we don't have to get approval for this, we can just go ahead and do it. |
| An external risk is one which cannot be contained by the project. If the unwanted event occurs, the project will be forced to renegotiate its terms of reference, either demanding additional resources or adjusting stakeholder expectations. | Example: We are assuming that the software vendors will supply a bug-free millennium-compliant version of the software by Easter 1998. If they don't, we will either have to switch to a rival software product, which will completely blow the budget, or we will have to slip our delivery dates. |
|
Ownership: Singular or Pluralveryard projects > programme management > risk management > ownership |
Example: Successful implementation of the systems we are developing assumes that all our major suppliers install a web service interface by Easter 2002. If this doesn't occur, we shall need to develop an additional suite of programs, at a cost of £xxx. Ownership of this risk belongs to the Purchasing Director, Mr yyy, and he has agreed to allocate the necessary funds for the additional development if it is required.
There are two basic ways of handling the ownership of a risk.
One way is to assign ownership of the risk to a given stakeholder. That stakeholder then "bears" the risk, which means taking responsibility for containing the risk and protecting other stakeholders from any unwanted consequences. The risk owner may carry out actions to reduce the probability of the risk and/or to reduce the impact of the risk, but these are, in a sense, "private" to the risk owner.
(Of course, we may want to audit the risk owner, to get assurance that the risk owner can in fact bear the allocated risks, and that the risk owner has adequate risk management provision.)
The other way is to take joint action to reduce uncertainty. This means shared actions to reduce the probability of the risk, and joint contingency plans to be carried out if the risk event occurs.
Contingency planning is about achieving flexibility of response, especially where several people or groups have to respond in a coordinated way to emerging circumstances.
(This is the basic difference between contingency
planning and disaster recovery. The latter is not about flexibility of
response but about a pre- programmed survival reflex.)
 |
Three Notions of Contingency
Crisis Management |
|
Bearing Limitveryard projects > programme management > risk management > bearing limit |
In some cases, the bearing limit can be determined fairly precisely. This is particularly true in cases that are covered by various forms of indemnity insurance, since the bearing limit can be taken to be equal to the level of insurance cover. In other cases, the bearing limit is itself a matter for negotiation.
Within a hierarchical organization, there
is a bearing limit at each level of the management hierarchy. In other
words, there is a maximum level of responsibility that can be delegated
downwards. Above this limit, the responsibility remains with upper management.
(For example, if a trading bank loses half a billion dollars, this cannot
be blamed solely on a rogue trader with an authorization limit of 50 million
dollars. To pretend otherwise is either foolish or corrupt.)
|
Bearing Limit also links to notions of Containment and Encapsulation. |
|
Calculating riskveryard projects > programme management > risk management > calculating risk |
Some project management standards (such as Prince) demand that the project manager create a Risk Log. However, compliance with this demand is often minimal and bureaucratic. It is done briefly (and inadequately) and the start of the project, and then never revisited. Worse, it often only includes risks that are internal to a single project. Where there is a large programme of supposedly coordinated projects, the most important risks are likely to reside in the interfaces and gaps between projects.
One of the reasons why risks are not managed well is that it raises all sorts of anxieties to talk about risks at all. Furthermore, certain categories of risk are experienced as more threatening than others, and there is a strong temptation to concentrate energies on a small set of highly technical risks and to dismiss other, softer but perhaps more serious risks. There is also a temptation to attach hypothetical blame to risks and to think of risks in unhelpful negative terms: these are the ways that Other People can harm Our Project, these are the ways that They (or even We) can expose Our incompetence.
The process described here needs experienced and sensitive consultancy to help people bring all types of risk out into the open and discuss the options sensibly.
Risk Identification. What are the risks? What are the events (risk indicators) that provide early warning of a risk?
Establish Ownership. Where is the best place to locate the responsibility for this risk?
Establish Risk Strategy. Can/should this risk be removed altogether or reduced? Should a contingency plan be defined?
Establish Mechanisms. How are the risk indicators to be monitored? How are the contingency plans to be activated?
Monitor Risk. What is the current probability of a given risk? Is it increasing or decreasing? Are any new risks emerging? What is the total project risk? Is it increasing or decreasing?
Review Risk Management System. Is the risk management system working effectively and cost-efficiently?
The initial stages are best performed
in a workshop with key project staff and stakeholders. The later stages
are typically carried out by the project manager, or by a person reporting
to the project manager, with regular summary reports to the project steering
committee. Consultancy support is usually required mainly in the initial
stages, with mentoring and other support available throughout the project.
One of the reasons why risks are not managed well is that it raises all sorts of anxieties to talk about risks at all. Furthermore, certain categories of risk are experienced as more threatening than others, and there is a strong temptation to concentrate energies on a small set of highly technical risks and to dismiss other, softer but perhaps more serious risks. There is also a temptation to attach hypothetical blame to risks and to think of risks in unhelpful negative terms: these are the ways that Other People can harm Our Project, these are the ways that We can prove our incompetence. The process described here needs experienced and sensitive consultancy to help people bring all types of risk out into the open and discuss the options sensibly.
|
Distribution of Costs, Benefits and Risksveryard projects > programme management > risk management > distribution |
So what is the business equivalent of the cell membranes that prevent the body from drying up or bursting? The structure and viability of the enterprise are maintained by its interfaces: the commercial contracts and intra-organizational agreements that control the inward and outward flow of benefits, costs and risks.
We need modelling techniques for understanding and managing the distribution of benefits, costs and risks in large federated business situations.
(If the parties are parts of a single large corporation, these agreements may be relatively informal, and enforced/adjudicated by senior management. If the parties are legally independent entities, then the contracts may be legally binding documents,enforced/adjudicated by the public legal system.)
|
|
|
|
| 1 | They are more or less likely to occur. (In other words, they are distributed in 'probability space'.) | Various (more or less mathematical) techniques are used to reduce the complexity of many different possible futures down to a single expected outcome. |
| 2 | They are likely to occur at different times. (In other words, they are chronologically distributed.) | To compare costs and benefits occurring at different times, accountants use the techniques of discounted cashflow (DCF) to reduce all cashflow to its net present value (NPV). |
| 3 | They affect different people, in different organizations, units, locations, enterprises. (They are distributed in 'stakeholder space'.) | Various (more or less political) stratagems are used to reduce the complexity of many different stakeholders with competing perceptions and preferences. These include power politics (where a single stakeholder dominates the decisions), compromise, log-rolling, consensus-seeking and various forms of voting. |
In any case, if the procurement decisions are also distributed, there is little point in artificially centralizing the costs and benefits (and risks). Instead, each stakeholder needs to develop a business and risk case from his/her/its own perspective, while considering the likely procurement behaviour and risk management strategies of the other stakeholders. Thus in a federated world, it is not enough to do a business case and risk management strategy from your own perspective. You have to work out ways of making a system or process profitable and safe for each of the participants, as well as making services attractive and affordable to the customer. This means that you need to have an estimate of the likely business case from the other stakeholders' perspective. You need to have some appreciation of each stakeholder's intentions. An indication of intentions can be based on an analysis of responsibilities.
|
 |