Business Management

A risk is an uncertain event or condition that, if it occurs, will affect your IT system/project objectives (or targets, or goals) and may have a positive or a negative effect. There are usually far more things that are likely to go wrong with an IT system or project than are likely to go right, so risk management is generally the art of trying to prevent things going wrong.
For most IT systems we can identify at least four objectives:
1. Functionality: the characteristics or performance of the expected system
2. Quality: the level of excellence of the system deliverables
3. Schedule: the dates by which functionality has to be delivered
4. Cost: the budget under which the system has to be delivered
There may also be other objectives, such as:
5. Safety: The system may have to work within a safety regulatory framework, or, at minimum, must be safe to operate
6. Environmental: The system may need to work within an environmental regulatory framework, for example, in a power station or in a gas pipeline
7. Political: There may be a need for the system in avoidance of political embarrassment e.g. a new passport control system to replace a discredited one.
A risk is any future event that would cause your costs or schedule to increase, or would result in reduced functionality or quality of the project deliverables or would impact on any subsidiary deliverables you have identified.
The risk management process can be divided into six operational areas:
1. management planning
2. identification
3. assessment
4. quantification
5. response planning
6. monitoring & control
The job of a risk manager is to manage all these processes. Lets have a look at them in turn:
1. Risk Management Planning
A typical plan will define:
1.1. Activities that are to be carried out. including risk identification, assessment, documentation, customer response, tracking of responses and execution of responses
1.2. Roles and responsibilities
1.3. Timescales and work breakdown of who does what
1.4. Criteria to use when assessing risks eg are we assessing based on cost to the project, or effect on timescales, or both
1.5. Reporting method
1.6. Review timescales
2. Risk Identification
The process of identifying what might go wrong with your project. Identifying risks is a matter of accessing information that is available to you as a corporate body.
Typically this uses:
2.1. Risk Databases: a collection of information derived from experience on previous projects.
2.2. Risk Checklists: a list of areas where you might expect problems to occur.
2.3. Information Gathering Techniques: getting information from a wide range of individuals using techniques including brainstorming, Delphi technique, and interviewing.
2.4. Strengths, Weaknesses, Opportunities and Threats (SWOT) Analysis: can identify risks in the client company which might impact on the system..
2.5. Specialized Techniques: such as cause-and-effect diagrams and various forms of flowcharts.These are often used when interviewing people with specialised knowledge of the proposed systems functions eg engineers or accountants
3. Assessment
This means estimating the severity of a risk in order that you can prioritise and deal with the severe risks first.
Risk severity is usually defined in 3 quantities:
3.1 Impact: the effect if it happens
3.2 Likelihood: the possibility of it happening
3.3 Precision: the degree to which the risk is understood
4. Risk Quantification
Risk quantification is the process of measuring the probability of a risk and its impact on project objectives. Unlike risk assessment, risk quantification aims to produce verifiable numerical values. Risk quantification typically uses techniques to:
4.1. Determine how risks will effect the costs and timescales of the project
4.2. Determine probabilities of finishing on time and budget
4.3. Make appropriate amendments to project plans depending on the risk factors quantified
5. Risk Response Planning
There are four ways in which you can respond to any risk:
5.1 Avoidance: Arranging the system ( or the customers business) so the risk is no longer relevant.
5.2 Acceptance: Acceptance means deciding to live with a risk, i.e. accepting it. (Note, if you do this, you MUST document your reasons)
5.3 Mitigation: taking positive action to reduce the severity of a risk either by reducing the likelihood that the risk will occur (risk abatement) or by reducing the impact that a risk will have when it occurs (sensitivity reduction).
5.4 Transfer: the process of transferring the effects of a risk (usually the financial effects) to another party eg by outsourcing support
6. Risk Monitoring and Control
Risk monitoring and control is an on-going process which should last for the life of the project. Its chief requirements are:
6.1. An organized method of monitoring risks.. Typically this is done as a part of regular project meetings
6.2. Individual ownership of risks. Each risk must have a person who will be responsible for keeping the information about that risk up to date, and ensuring that response actions are carried out.
6.3. A risk information system. A standardized reporting system is advisable to help remove subjective interpretations of risk severity. This is usually an on-line database accessible by everybody on the project.
6.4. Periodic risk reviews. Carried out at intervals throughout projects to determine if risks have changes
6.5. Independent risk analysis.. External risk management contractors are often used to obtain an outside view and ensure the risks are being managed objectively.