Beating IT Risks

64	IT risk portfolio

Other details of approach need to be considered to ensure consistency and comparability across the IT risk portfolio. Key questions relating to the information management and analytical approach are posed:

•How much information needs to be captured and documented on each risk, and to what level of consistency and accuracy?

•How quantitative and accurate must assessments of IT risks be? Is qualitative good enough?21

•How is the effectiveness of IT risk management capability and risk management performance to be measured?

People and performance

IT risk management is also about people and their performance. People’s skills and knowledge in IT risk management need to be developed and maintained. This requires some combination of education and training dealing with IT risks, appropriate for the roles and responsibilities held.

The culture that supports and promotes effective IT risk management is determined by the management team’s actions. This culture needs to align individual’s efforts and embed IT risk management as part of accepted practice and develop reward systems that recognize individual contributions to risk management.

Whistle-blowing must be encouraged and managers must listen when the whistle is blown. Your two-way communication mechanisms must accommodate good, potentially bad and very bad news. Research on the willingness and reluctance of auditors to blow the whistle on failing IT projects (Keil and Robey, 2001) highlights the personal risks that the whistle-blower faces. Senior executives who fail to listen in an increasingly accountable climate can be at far greater personal risk.

Research has highlighted the importance of manager perceptions in dealing with risk (Bandyopadhyay et al., 1999; Kontio et al., 1998; Keil et al., 2000). Further research has explored the ‘hidden assumptions’ that if causes of failure can be understood then management can straightforwardly eliminate them (Sauer et al., 1997). The concepts of organizational learning – learning from your mistakes or even better, learning from others (Scott and Vessey, 2000) – also have a part to play, wherein acceptance and recognition of short-term failure is a precondition to long-term success.

Implementation and improvement

People won’t just accept a new way of managing IT risks is necessary without having been told why it is necessary. A convincing story must address both

21 NASA (2002) represents the most developed approaches to quantitative risk analysis. Rainer et al. (1991) set out both quantitative and qualitative analysis techniques and argue persuasively that a mix of both is preferable.

Implementing an IT risk management capability	65

why it is important for your organization and why it is important for the individual.

Change will then need to roll out in a particular way. Are all IT risk areas addressed at once, or is the focus first on those IT risks most recognizable as the ‘squeaky wheels’? Is the implementation of change to be rapid or drawn-out? In what order will the different areas of the business and IT be engaged?

Standard change management practices will deal with the planned change, addressing each of these elements and ensuring sufficient resources are allocated to achieve the agreed milestones.

As capability improves over time, it will be important to sustain the changes that have been achieved and redirect the IT risk management team towards further improvements.

Call to arms

We have outlined an IT risk management approach within an IT governance framework that enables your organization to get on top and stay on top of its IT risks.

To promote your implementation steps, we recap on the position you will seek to achieve against the deficiencies commonly encountered and set out in Chapter 1, some or all of which may currently apply to your organization:

•Piecemeal approaches are explicitly countered with the holistic IT risk portfolio that provides formal coverage for all of your relevant IT risks, all the time.

•Communications failures are rigorously addressed with the establishment of two-way channels flowing from and to the top of the organization.

•Surprises and reactivity, while not completely eliminated, are reduced and dealt with in an orderly fashion – IT risks won’t be pushed under the carpet to be discovered late in the day, or too late – they’ll be disclosed in a timely manner by those with clear responsibility to do so and appreciated by those whose job it is to listen and respond.

•Career damage to individuals will be minimized as the focus shifts to organizational learning and development of capability – the risk that was dealt with being welcomed as the disaster that didn’t happen.

•Evolving, moving subjects are not furtive shapes that go bump in the night – their movements are actively tracked within and across the IT risk portfolio, specialists encouraged to provide valuable look-ahead warnings to those who can redirect the course.

•Creeping goals become clear targets and objectives – the hurdles are raised clearly and explicitly, with the need for capability development to meet the new challenges being recognized and built in to the implementation program, a ‘quantum leap’ in capability is recognized as infeasible and steady improvement becomes the norm.

66	IT risk portfolio

•Consistent underperformance founded in IT failures becomes something you’ll point out in your competitors and congratulate yourselves on having avoided.

Surely that is enough encouragement to get to work! The rest of the book is designed for you to ‘jump’ to the IT risk class and chapter of most interest. If a hot topic doesn’t immediately call for your attention, start with the health checks at the end of each chapter to prioritize your reading and implementation efforts.

Health check

This section assists you consider at a macro-level the company’s requirement for an IT risk management overhaul.

Is IT risk management important to your business?

•Many types of IT risks could potentially impact the business.

•There are different views about how IT risks should be managed.

•Obtaining management airtime and funding for IT risk-related activities is difficult.

If you agree with two or more of the three statements, then IT risk management is important to your business.

Are you doing the right things?

•IT risks are regularly reviewed.

•The process for IT risk identification and analysis is repeatable, structured and consistent.

•The allocation of cost and effort for managing IT risks receives formal consideration.

•All stakeholders are involved in determining relative priorities and IT risk treatment strategies.

•Ongoing IT risk funding covers both technical aspects and management / people aspects.

•It is clear how different types of IT risks are being addressed and managed.

•IT risk management is effectively linked into wider enterprise risk management processes.

Case study: European fleet management services provider	67

•IT is managed in a proactive way.

•IT failures are examined so necessary changes to policies, procedures and approaches can be undertaken as a continuous learning process.

If you agree with these statements, then you are doing the right things in your organization. If you disagree with three or more of the nine statements, then there is significant room for improvement in your IT risk management capability

Do you have a good track record?

•The business has avoided being negatively impacted by most types of IT risks.

•IT judgments and opinions are trusted and valued by the business.

•When urgent action has been required to remedy an IT crisis the response has been effective (also answer yes if you haven’t had any significant IT crises).

•Tangible losses experienced from past IT failures have been acceptable.

If you agree with these statements, then you have a good track record of managing IT risks. If you disagree with two or more of the four statements, then there is evidence of the need to improve IT risk management capability.

Case study: European fleet management services provider

Setting up a European data centre

A world leader in fleet management and automotive services, based in Europe and employing over 7000 people, manages over 1 million vehicles with a total value of some a10 billion in over 20 countries across the globe. It has a banking licence that gives the company access to the capital markets but also places it under the supervision of a European national bank.

The company has embarked on a strategy to position itself towards its customers as a partner with a global service delivery capability for international companies as well as a cost-effective local supplier for small and medium-sized companies. IT will play a major role in this effort and

68	IT risk portfolio

international consolidation in information and communication technology (ICT) is considered a key step forward.

Both the stricter requirements from the European national bank under the Basel II agreements and the strategic imperative require a considerable strengthening of central IT governance. Unfortunately this goes contrary to the highly entrepreneurial company culture, in which local decision power is regarded as the key to business success. While all countries use the same hardware platform and share the same core application for fleet management, this application is customized by each local unit, and there is far less standardization on the hardware and the applications in other functional areas. Several attempts to strengthen central governance over the last years had met with limited success.

The company then decided to set up a European data centre that would consolidate the processing of the major applications and the management of the wide area network. The stated objectives of the project were:

•To reduce diversity in the group;

•To leverage on the global scale of the company;

•To improve security in line with the new banking regulation and with industry best practice; and

•To create a platform for the future development of ICT.

As the project moved forward further expected benefits were identified:

•The design of the European data centre and the wide area network provides the robust and common platform that will be required for making ICT a key factor in the development of the company’s strategy;

•Disaster recovery is moving from a local responsibility with mixed levels of protection against disaster towards a common solution that is designed to be fail-safe;

•Data protection and retention is also organized and monitored centrally with best practice processes imposed on all organizations; and

•The European data centre will be the key contact point to ensure that all entities comply with the security regulations of the European national bank, and will support them in implementing these.

A number of additional benefits are materializing:

•The project to create the European data centre and migrate the processing from the countries to the centre has been set up completely in compliance with PRINCE2 project management guidelines. As such it is not only the showcase for this approach within the company, but it

Case study: European fleet management services provider	69

has also provided a number of document templates and project control process descriptions that have already been used in other projects; and

•The project has generated extensive communication between the ICT management of the countries, resulting in an exchange of experience on potential application solutions and creating the first level of convergence of applications.

Printed with permission of PA Consulting Group

70	IT risk portfolio

4 Projects

All at sea

Fourteen years after legislation required the Coast Guard to develop a vessel identification system, no such system exists, and future plans for developing the system are uncertain. The Coast Guard’s early efforts to acquire VIS were unsuccessful. In the late 1980’s and early 1990’s, the Coast Guard undertook numerous activities to define requirements for such a system. In 1995, the agency contracted to develop the Marine Information for Safety and Law Enforcement (MISLE) system, of which VIS was a subcomponent. The Coast Guard accepted the contractor developed VIS in 1998 despite system performance problems, intending to resolve these problems as the system evolved. However, the Coast Guard later found that there was no viable way to correct these and other problems, and that the cost to populate the system with states’ data would be high. In retrospect, Coast Guard officials noted two factors that complicated VIS implementation: (1) not all vessels had unique identification numbers and (2) the system depended on the voluntary participation of the states, and many states were unwilling or unable to commit the funds needed to participate. Consequently, even though the Coast Guard spent about $9 million in identified costs to plan and develop VIS, it was never implemented. (GAO, 2002)

Down the drain

Sydney Water’s customer information and billing system (CIBS) project was intended to improve service to customers, to fill gaps in existing information systems and to provide business efficiencies . . .

Sydney Water had originally expected CIBS to be operational by February 2002, at a cost of $38.2 million . . .

Sydney Water terminated the CIBS project on 30 October 2002 . . .

72	Projects

Before the project was stopped, the budget had increased to $60 million, with a further revision pending and the ‘Go Live’ date had moved to March 2004 . . . most of the $61.0 million will be written off.

(NSW Auditor-General, 2003, p. 12)

The IT world abounds with horror stories about the failure rate of IT projects and the impact on business. It doesn’t matter whether it is an academic study, a consultancy report, government audits, or your own post implementation reviews – everybody agrees that IT projects commonly fail to deliver. On top of this, almost everybody comes up with a top-10 list of reasons why – they just don’t agree.

It is quite clear that implementing IT solutions to deliver business value is difficult, and there is more art to it than the numerous project delivery methodologies imply. Worse, not only do the projects have to overcome the array of hurdles, obstacles and traps inherent in the nature of difficult projects, but also fear of failure means that many organizations impose additional gates and checkpoints that often actually add risk to a project.

There are two extreme positions in the galaxy of failure capabilities:

•Your organization is inherently incapable at project delivery – even relatively simple projects go wrong.

•You have inherently high-risk projects and are not addressing the specific risks appropriately.

Most organizations wander around in the middle ground, with neither a demonstrated competency of always delivering a quality product on time and on budget, nor a workload consisting of high-risk projects. A fundamental lack of competency is an IT governance issue that was dealt with in Chapter 2. In this chapter we look at the range of challenges in delivering projects, when an effective governance structure is in place.

Whether your interest in an IT project is as the primary recipient of the solution and service, the source of funds, the manager accountable for solution delivery, a manager of another project with dependencies or as a stakeholder with a less direct interest, you are no doubt keenly aware of some risks and less aware of others. From day to day, out of necessity the management of the project is delegated. The key question remains for you: In the relatively small amount of senior management time allotted to oversee the projects in the portfolio, what needs to be done to get on top of the risks and make sure they are properly managed?

This chapter sets out the generic costs of project failure and provides a framework for you to assess both issues of individual project failure and more systemic capability issues in project delivery. An exploration of the concept of project risk factors leads to structured suggestions about how to manage projects with a ‘high degree of difficulty’ so as to reduce the likelihood and impact of project failure risks.

The impact of project failure	73

An overview of the generic IT project ‘voyage’ precedes subsequent detailed analysis of delivery assurance philosophies and considerations that should be uppermost for phase reviews of projects. Management responses, utilizing a triage model, are discussed along with considerations of alternative solution delivery lifecycle methods and the suggested risk management stance and emphasis for each.

To conclude, a project risk health check is provided and a case study reinforces some of the key lessons learned. A comprehensive checklist for those requiring immediate diagnosis or first aid is given in Appendix 1.

The impact of project failure

We have ordered the IT risk portfolio so that projects are addressed first. Research has indicated that the largest IT risks in a high-risk portfolio will be due to projects, in particular large projects (Verhoef, 2002; McFarlan, 1981).

While our focus will be on IT projects, we point to the need to consider the bigger picture, paying heed to recent advice given to UK government agencies:

Our most important message is that thinking in terms of ‘IT projects’ is itself a primary source of problems. Delivering IT is only ever part of the implementation of new, more effective ways of working.

(McCartney, 2000, p. 5)

When an IT project fails, the investment costs are typically the headline items. Certainly there is wastage – scarce resources have been working on a project that did not deliver anything of value, these people could reasonably have been working on something else – however, there are also a couple of more insidious impacts.

We’ll call the first the ‘lost benefit’ risk. If the project was worth doing, then presumably it was justified based on the business benefits to be generated from utilizing the IT product or service – it certainly should have been!

A well-structured business case for an initiative will typically explore the ‘do nothing’ or ‘maintain status quo’ option – illustrating this option as infeasible and unpalatable – before exploring, at a high level at least, some less-favoured options, and settling on the recommended course and explaining this in some detail. An idea of the impact of the project failure in ‘lost benefit’ terms can be obtained by rereading this ‘do nothing’ section of the business case and reflecting that the business is still in this state. Of course, the original business case may have strangely disappeared and the original promises made lost in the mists of time . . . but this brings us to the next impact from project failure.

We’ll call this ‘collateral damage’ risk. People involved in the project may be harmed, as individuals, teams and potentially whole organizations. At its worst,