Risk Assessment vs Risk Management

Excerpt from Q3/99 TickIT International article written in 1999 – Still relevant today!

International The quarterly journal of the TickIT software quality certification scheme ISSN 1354-5884

Risk Management versus Risk Analysis Alex Petty

Risk Management is a subject that is often neglected. As with other non-life-cycle project activities or business support processes, active risk management is often one of the first casualties when an assignment is heading for failure.

Risk management, when used in conjunction with other supporting processes, is one of the best weapons in a project manager’s armoury for removing or mitigating the probability of show-stopping problems arising.

There are risks in any task, be it a project or programme, or a business activity. All risks have a solution. The solution may not always be pleasant, but even if it means abandoning a task part way through, it is better to stop if no more business benefits are likely to accrue.

The effective removal and mitigation of risks (management) provides an assignment with the opportunity to succeed in a world full of failed projects/pro- grammes. All too public are the disasters that not only waste money but also cost lives; high profile examples include the disintegration of the NASA Space Shuttle,

the Channel Tunnel Shuttle fire, Clapham rail crash and IT systems project failures which are regularly reported in the computing press.

This is why risk management is so important. Remove or reduce the risk of failures and the problems become small and manageable. The only surprises are then the risks that we have not been clever enough to imagine – these need to be captured and communicated as lessons learnt for next time!

Risk in a Business Context

There are many types of risk but these fit into four main categories of business activity; each needs a different management focus.

• Research and Development – These risks tend to be focused on long-term technical issues and future business objectives. Any risks identified need to be managed with overall business strategy in mind and are not normally associated with day-to-day risk management.

• Strategic – These relate to assignments designed to satisfy a business need and are often on a short timescale. The focus is on reducing/removing time-based risks first, then quality, then cost. There is no point in perfecting a system if it misses the business opportunity. Tactical projects can incur large costs post delivery if it is necessary to capture designs in retrospect and fix features that are manually supported during implementation.

• Key Operational – This is where you already have a business function operating, for example a billing system that requires an upgrade. Key focus should be on the quality risks followed by cost and time. The system must continue to operate at current or lower support levels after hand-over. A properly managed development project will ensure that all costs are incurred prior to hand-over and that no unnecessary costs are incurred.

• Support – These are second or third line business activities. Cost is the main focus for risks as these applications are often not revenue generating. The business should not invest in a supporting activity that does not provide sufficient return.

Nowadays, many companies have gained ISO 9001 certification and many IT areas have gone the ISO 9000- 3/TickIT route. It is surprising how many seem to be missing the preventive action clause in ISO 9001 – 4.14.3 Preventive action and TickIT Guide supporting life-cycle processes Problem Resolution, section 3.3.4.

If companies are serious about the concept of quality management then preventive action must be the main- stay of any QMS. Prevention is better than cure and risk management is one of the tools that should be used.

Risk in a Project Context

There are numerous methods and approaches to identifying risks. The key activity is the management of those risks. Risks must have a solution, an actionee and a target completion date to be considered managed, it is not enough just to identify risks. All too often risks are identified (analysis) and that is as far as it goes until the end of the assignment.

The main benefits of risk management are that surprises, nasty or otherwise, are removed. Risks are reduced or mitigated to a point where contingency planning will ensure that work continues to time, cost and quality.

But over and above the first line benefits of managing risks, there are many additional benefits that assist with the overall project management activities. By involving all assignment participants in the risk management process there is an automatic vehicle for communication, both within the team and into the business areas. Information on risk types can be made available to other project teams to reduce re-invention of the wheel and a well run risk management process can be used to demonstrate control and provides evidence for audits.

It is important to avoid making risk management a heavy, bureaucratic process with many controls and mechanisms. An over complex approach does not help a project and usually ends up by being dropped from the assignment team’s activities; or at best done only once at the start of the project and not maintained for the life of the project. Successful risk management is not rocket science, the process that is successful will be simple, effective and easy to maintain once you have the buy-in of the concept and acceptance that risks must be managed.

The key is to remember what is trying to be achieved. The level to which the process is implement- ed must be appropriate to the size and overall risks of the project. For a ten-day project the activities and effort should be scaled to match the delivery time. The focus should be to remove the risks that will stop the project achieving its goal. For a more substantial project, the risk management process will be used throughout the life-cycle, with risks reviewed at appropriate times and progress on the risk solutions monitored at regular progress meetings.

As far as projects are concerned, there are three main sources of risk.

• Project/Assignment – These are process and product based risks that a project manager is able to have a direct influence on.
• Organisational – These are cross-departmental risks that may have an impact on, or be impacted by, other projects. These require to be managed at the departmental level, as an individual project man- ager has no direct control on other teams within an organisation.
• Business – These are competitor-based risks either from outside a company or internal to a company where one business area may be unaware of actions that affect another.

Communication is the key to successfully managing the risks at all levels, especially at an organisation or business level when a business-wide risk management function is required to co-ordinate the resolution, escalation and communication of risks.

Simple Tools

The approach I have used successfully for a number of years is based on a project based risk management approach originating from the Cranfield University – the School of Management 1, 2. As its basis, this uses a questionnaire and Ed Yourdon’s approach to managing business risks. The mechanism and tools derived from this material can be used for both project and business risk management at any time in a life-cycle, or as an independent stand-alone process.

Managing Risk in IT Projects – David Bentley – 1991 Assessing and Managing the Risk of IS/IT Invest- ments – J M Wood – 199

Figure 1 – One example question from the set of 29 listed on the risk management questionnaire:

a	b	c	d	e
Low Risk	Scale	High Risk	Weighting	Total (b x d)
Full time, experienced project manager	1234	Inexperienced or part time project manager	6	18

Title of Risk:
Sponsor Support
Definition of Risk:
The Sponsor of the project will not be available to provide the support required to meet the needs of the project.
Probability of Risk:		Score: 0.7
The Sponsor has other projects to support as well as the day job.
Impact of Risk:		Score: 0.8
The project will be delayed as approval of requirements, and authorisation to proceed will be held up.
Risk Management:	Ef f e c t	Score: 0.56
The Sponsor has agreed to delegate the financial and project authority to a deputy, who will be available. Deputy Sponsor’s activities to be included in project plans. Actionee – Project Manager Target: 25/02/1999

Figure 2 – The Risk Management Record is used as part of the risk register and records the agreed actions

These two simple approaches provide a structured repeatable set of mechanisms for projects and a brainstorming process for business risks that produces maintainable risk records.

The project risk management process starts at the initiation of the project with a team risk management workshop. This assesses inward facing risks, which then receive a score based on the team perception of the scale of the risk against a weighting for that question (see Figure 1).

The perceived scale score is chosen as appropriate to the project (1 is low risk and 4 is high), for this ex- ample the score is 3 . This is multiplied by the weighting (the weighting for each question is based upon the Cranfield material, and refined over time as experience increases) which provides the score of 1 8 . The process states that any risk scoring 12 or above shall be man- aged. A solution is defined at this stage and actionee/ target date agreed. The combined score of all the risks on the questionnaire are added together and assessed against the expected score (listed in the process). This provides the project manager with a view as to the level of risk for a given project. If the risk score indicates a very high-risk assignment, the project manager would normally expect to delay the start of work until any show-stopping risks had been resolved.

For those risks assessed as requiring management, the team generates a risk management record (see figure 2) that becomes part of the risk management record set. These risks are then resolved, mitigated and reviewed throughout the life of the project.

The example Risk Management Record was derived from a business risk management workshop. The attendees included the project team, customer and sponsor. The scores are a percentage rating (0.8 = 80% probability and 0.7 = 70% Impact) and are multiplied to provide an effect score (0.56 = 56%). As a general rule, risks with a score of 50% or above are managed. Depending on how many risks are identified, it is usual to manage the top half or, if very many that appear to be minor, the top ten. The attendees of the workshop may need to agree the break point. The solution identified may not seem very exciting, but it achieved the desired results of sponsor buy-in and participation.

Business risk management uses a free format brain- storm to identify risk outside the project that may impact the successful completion of the assignment. Risks are assessed for probability and impact which, when multiplied, provide an effect score. The effect score rating indicates the level of risk and, balanced against other risks, provides a mechanism for pri- oritising which risks should be removed first. As with the project risks, the business risks require a solution that is then managed.

The Risk Management Record is used to capture both project and business risks. Project risks have already been scored and do not use the Probability/ Impact sections.

Other Approaches

There are many tools on the market offering to manage risks, but in the purest sense they can never manage risks. There are some that provide a structured ap- proach to assessment, based on a questionnaire, and those that are based on the monitoring and progress achievements. A tool is only as good the data fed into it. The real activity is in the identification of a solution, progress of the resolution and reporting the progress.

Risk Management tools are very useful for monitor- ing and recording progress and activities yet to be performed, especially for company wide risk manage- ment or large multi-function programmes. Tools can sometimes be a cumbersome burden on a medium to small sized project. It is better to manage the risks locally and deliver the project rather than spend too much time on the risks management tasks. This does not mean that risk management is forgotten, just that it is scaled to suit the requirements. Remember when monitoring, that risks may only be relevant during specific phases or time periods. During the monitoring process you will be tracking the cessation of some risks and the birth of others.

In Conclusion

It is important to make risk management a team activity, as many people have good ideas that are triggered by workshops. Try to include your customer/user/sponsor in the business risk management workshop – they are the people who are often best placed to know what the business strategies are.

Project activities often commence when there are too many show-stopping risks outstanding. Part of the benefit of risk management is to be able to appreciate and demonstrate that an assignment has too many high- risk items to be successful. It is better to get the business to decide if it wishes for a task to continue with a major risk or to stop work until the problem is resolved. Sometimes it is the sheer number of risks that make a project difficult to manage. At this point a project should be halted until the risks are at a level that is manageable and the effort captured as part of the project plan. All too often the project control activities are not built into the plan, therefore not providing any time to manage the project. This always leads to late projects and/or short-cuts that affect the quality of the work done.

Another key item in the management of risks is the commitment of staff and management alike to the resolution of risk solutions. Staff commit to the actions that will remove or mitigate risks, whilst the manage- ment and customer must commit the time and effort. Risk solutions sometimes require approval at board level. Commitment at this stage is crucial to the suc- cessful management of risks.

Many times a project manager is reluctant to state that there is a potential problem on their project – being seen as a black mark. The management must provide a culture that encourages early identification and resolution of risks rather than what is currently more commonplace, the fixing of issues (risks that have happened).

All risks can be managed, it is just that some solutions are unpalatable.

Alex Petty is IT Programme Office Manager with Sainsbury’s and has a background in engineering and telecoms. So far during a 21 year career in engineering and IT he has developed skills in TickIT auditing, programme/project management, Y2K auditing, quality management, risk management, configuration management and testing management, amongst other engineering activities/ aircraft manufacture.