Taking A Chance: Risk/Reward In Financial Systems Projects

You can barely open a paper or a trade magazine today without being confronted by the term "risk management". In order to attract the reader to the news item or feature, the piece is usually smattered with eye-catching phrases such as "Barings collapse", "Sumitomo fiasco" or "Canary Wharf bomb".

"Risk Management" is used to cover a variety of activities, from managing financial risks to operational risk management, such as business continuity planning and health and safety. Recently, the term "business risk management" has started to become widely used to cover the management of all risks which a business might face. The Cadbury Committee's Report on Corporate Governance says that a key element of an effective control system is to have a process to identify major business risks. And the Institute of Chartered Accountants in England and Wales has recently published an excellent summary of business risk management which says "All businesses take risks in order to make profits, but those risks need to be managed sensibly in order to ensure commercial survival. To be successful an organisation needs to maximise profits for a given level of risk". (Technical Focus: Business Risk Management, Judith Shackleton BSc ACA, January 1997, ISBN 1 85355 640 8)

Business system implementation is a key area of activity which is inherently risky.

A 1996 study by The University of Sheffield Institute of Work Psychology indicates that more than 80% of business systems projects are late to a material extent. According to a 1995 Standish Group report, over 31% of business systems projects are cancelled before they are completed and 52.7% of projects cost at least 189% of their original budgets. Only 9% come in on time and on budget. (Standish Group reported by Erin English, Edittech International, Computer, 1995)

To counter these problems, the concept of risk/reward can be applied to financial systems projects - to ensure they are better planned, implemented and evaluated:

• Planning. The use of risk/reward analysis (rather than mere cost/benefit analysis and checklists) in the feasibility phase through to selection of solutions would prevent many projects which are destined to fail from getting off the ground;
• Implementation. A risk/reward approach to project management (rather than mere blob charts or Gantt charts) increases the chances of steering implementation work towards meeting the project goals and therefore towards project success;
• Evaluation. A risk/reward assessment of completed and abandoned projects evaluates the outcome of the project (e.g. objectives met and yet to be met, user satisfaction with solutions) and produces learning points which should help identify further needs and help improve the success rate in future IT projects.

Fans of cost/benefit, checklists and Gantt charts are probably unjustifiably smarting at this point. But we are not rejecting these tools - indeed, we advocate using them where appropriate. Our propositions reflect an evident truth based on the recognised rate of failure; these tools alone are not sufficient to handle the complexities of the decisions and tasks at hand.

It is astonishing how many financial systems projects are attempted without any feasibility stage at all. For larger financial systems projects - say 20 or more concurrent users of the financial system - the feasibility stage alone is likely to be a mini project in itself.

Even for smaller projects, there is a minimum requirement to define the objectives of the project and attempt to quantify the benefits, or rewards sought from the project.

To start with, ask the simple question: "Can we achieve our strategic objectives with our current systems?". If you can, you might still choose to change system simply to improve economy and efficiency.

More commonly, you do need new systems to meet those strategic objectives, as proposed financial system changes very often stem from a strategic business need. You then outline the project objectives in terms of the strategic objectives you are setting out to meet.

The analysis should also include estimated quantification of potential rewards, estimated costs and a risk-based assessment for each objective and for the project overall.

Don't forget to take risk factors into account: e.g. have you discounted the cash flows of this project with an appropriate risk-adjusted discount factor? How sure are you about your cost estimates and how sure are you that you will achieve the efficiency gains? What is the likelihood that the project fails completely and how much might it have cost you by the time you bail out?

Many projects which easily make the cut on simple cost/benefit analysis do not make it past the feasibility hurdle once a reasonable analysis of risk is included.

Many financial systems projects proceed with little or no definition of project objectives and without clearly defined benefits. Lack of definition might make the selection phase quite difficult.

But never mind. You've established the feasibility of proceeding with the evaluation and selection of systems. Kill-joys like Z/Yen probably try to bully you into specifying your requirements in a bit more detail than you had done in the feasibility phase but primarily you are getting to the fun part.

You get out of the office to see some exciting-looking new systems. Software salesmen are being nice to you. Most of them will compliment you on your fine specification document or your wisdom in neglecting to produce one and just looking at good systems like theirs. Some will serve good coffee, sandwiches and biscuits. Few will mention risk very much, if at all.

Selection and procurement of financial systems is still about risk and reward analysis - only now you can compare several possible choices with different risk/reward profiles, including the rarely used option to reject the lot because none of the systems evaluated provides sufficient rewards compared with the risks of proceeding.

Don't let fancy features and fast talk make you lose sight of your objectives and the potential rewards . If none of the solutions will help you to achieve your defined objectives and reap those potential rewards, you need a serious rethink. Have your objectives and/or the potential rewards changed? Is there still a business case for proceeding? Figure 1 shows a decision model for this process.

The first phases of your financial systems project, discussed above, should have identified several of these areas of risk: product risks, supplier services risks, project organisation risks, inhouse resources risks, and the question of objectives, rewards and user satisfaction. Table 2 shows an appropriate format for setting out those issues.

Table 2: Implementation Risk/Reward Management Issues

By directing financial systems projects towards their potential rewards and minimising the risks along the way, you can vastly increase the likelihood of project success. But the risk/reward management approach to project management requires clear thinking, the ability to make decisions (sometimes tough ones) in a rigorous approach to achieving the objectives and rewards that led to the financial systems project in the first place.

Few systems are evaluated post-project. Exhausted, demoralised and late starting the next project, there often just isn't time. This is a pity. A post-project review can produce substantial benefits, including:

• Assessing whether objectives have been met and rewards gained. This enables you to decide what additional activities, if any, are required to meet those objectives and gain those rewards;
• Appraising user satisfaction, or lack of it. Often, some early follow-up with users can identify issues which can be relatively easily addressed, improving the users' longer-term perception of the success of the project and of their satisfaction;
• Identifying learning points for future projects. Given the consistently high rates of IT project failures, it seems a shame that organisations are clearly not learning much from their past mistakes. Solid risk/reward assessment post-project would go some way to improving the track record for IT projects.

For larger projects, the post-project review is a small project in itself, but for smaller projects a brief assessment addressing the above points would achieve many of the benefits

Table 3 shows a sensible pattern of risk/reward activity divided between the phases of a financial systems project. It is not exhaustive, but should illustrate the principles involved:

• Cost/benefit analysis should be risk/reward analysis
• Project management should be risk/reward management
• Post-project review should be risk/reward assessment

Table 3: Pattern of Risk/Reward Activity

Z/Yen Group is a risk/reward management firm working to improve business performance through better decisions. Z/Yen undertakes strategy, finance, systems, marketing and organisational projects in a wide variety of fields, such as recent projects managing development of a client profitability system or the benchmarking of transaction costs across 25 European investment banks. Michael and Ian's humorous risk/reward management novel, "Clean Business Cuisine: Now and Z/Yen", was published in 2000; it was a Sunday Times Book of the Week and even Accountancy Age described it as "surprisingly funny considering it is written by a couple of accountants".

[This article originally appeared as "Taking a Chance - Risk/Reward in Financial Systems Projects", Conspectus, Prime Marketing Publications Ltd (April 1997) pages 38-39.]