IT Governance and Risk Management An Integrated Mu
IT Governance and Risk Management An Integrated Mu
net/publication/229041504
CITATIONS READS
12 1,090
2 authors, including:
Raymond Young
Xi'an Jiaotong-Liverpool University
22 PUBLICATIONS 760 CITATIONS
SEE PROFILE
All content following this page was uploaded by Raymond Young on 19 March 2014.
Abstract
Introduction
The recent collapses of Enron in the US and HIH, One-Tel, Ansett, and Pasminco in Australia has highlighted the
inadequacy of the current risk management regime in corporate governance. The groundswell of public opinion for
change is the first of many likely triggers to expand the current governance regime to include matters relating to IT
governance.
Boards have been guided by substantial professional practice in the area of risk management from such perspectives
as audit and control, financial management, insurance, OH&S, environmental assessments, operational continuity, crisis
and emergency management, strategic management and from the professional practice of 'risk managers'. IT
Governance and IT risk management is noticeable for its failure to contribute in any significant way.
IT: Risks & Opportunities
Inadequate IT governance exacerbates the problem by bringing high levels of risk to organizations. Clegg reports 80-
90% of IT investments do not meet their performance objectives. Many authors [9][10][11] substantiate the size of the
problem and point to the complete demise of companies because of inadequacies in IT governance. Their discussion
however tends to focus on one aspect of IT governance: project risk management, and neglects the other two
dimensions of IT governance: IT strategy and IT operations [12].
Investments in IT represent, for many businesses, their major sources of opportunities, costs and risks. The new
information technologies increasingly underpin most forms of commercial, industrial and government activity [1]. IT
investments are increasingly in areas requiring major organisational change for the full benefits to be realised [11].
Effective IT governance therefore reaches beyond the IT function and must be integrated into corporate governance as a
whole and requires resolution of the tension between risk and innovation [13].
Developing an integrated IT risk management paradigm in the context of all risk management
perspectives
Boards are very aware of IT risk [14] and project risk management has been the main approach to manage the risk
but the success rate is still very low [1]. A more integrated approach is needed but progress is hindered because a
fundamental issue has not been addressed: the many approaches to risk management have not been integrated into
rigorous theories able to facilitate cross functional decision making.
This paper proposes to address this issue by reviewing the development of risk management in all major disciplines.
It will highlight the current impasse because of the tensions between the traditional statistical quantitative approach and
the context sensitive qualitative approaches. It will then propose a way forward based on a cross functional synthesis of
the best practices. It will incorporate but not be limited by AS4360 [15] the world’s first risk management standard, the
Turnbull report [3] from the UK which sets the latest standard for higher standards of corporate governance, and the
work of March and Shapira [16] clarifying actual management approaches to risk.
The contribution of this paper is to use IT Governance as the context to lay the groundwork for an integrative view of
risk management and to propose an IT Governance framework based on this integrated view.
…No single interest group or profession can 'unlock' all the forces that currently 'conspire' to produce poor
performance. In this view the poor performance of new IT systems is the result of a complex and interacting set of
forces that will not be easy to change. A great deal of integrated effort is required. Indeed if it were easy, it would
have been done already. [1]
Literature Review
Risk Management
Risk management was recognised to be different to risk assessment in 1983 [2]. The literature in many sub-fields of
risk management (e.g. chemicals, health, environment, engineering, insurance) is conceptualised within the dominant
economic paradigm assuming decision makers make rational choices based on highest expected utility. For example,
Molak’s [17] introductory risk management textbook dedicates more than 50% to describing statistical methods to
quantify risk for decision makers. Haimes [18] more advanced text adds multi-objective statistical methods to the
standard suite of mathematical assessment tool and advances the field to emphasise the importance of multi-stakeholder
techniques to identifying risks.
Most risk management writers recognise it to be a very young field. Molak [17] expresses concern when risk
management experts are pitted against one another on controversial issues such as the environment and the nuclear
debate to show the current inadequacy of the discipline. A 1996 US National Research Council [2] on this matter
concluded that in the past we applied risk analysis “to relatively simple problems … but now that we are asking more
complex questions, we are finding risk analysis is incapable of producing adequate answers” and that “the [current]
view of risk characterization1 is seriously deficient”.
1
Risk characterization is the process to translate risk assessment information into a form usable to a decision maker.
The National Research Council report is particularly relevant because they were trying to reconcile current paradigms
with an environment with loosely formulated risk problems, multiple decision criteria and multiple decision makers;
factors which are common to almost every business decision. Their recommendations for “a more robust construction”
are particularly helpful in pointing out that perspective of all stakeholders must be incorporated.
“Adequate risk analysis and characterization thus depend on incorporating the perspectives and knowledge of
the interested and affected parties from the earliest phases of the effort to understand the risks.” [2]
Beck [19] was one of the first post-modern philosophers to understand that risk is best understood in the question:
Where and how does one draw the line between still acceptable and no longer acceptable exposures? [19]
Beck [19] does not dismiss the need for statistics and traditional scientific rational analysis, but makes the point that
we have reached the limit of what risk analysis can do.
Led by the banking sector in Basle, financial risk managers continue to set the risk management standards to lead the
corporate world. Having conquered market and credit risk, they are now pushing for operation risk measures to be
implemented internationally by 2007, and there is talk of the four major Australian banks to be compliant by 2004.
Despite this confidence, recent corporate collapses have highlighted the inadequacy of the current risk management
regime in corporate governance. The business world is faced with conflicting messages between the financial risk
management regime of the banking sector and the likely legislative fallout from the latest round of corporate collapses.
Reufli [20] reports “early empirical tests of the CAPM by Black, Jensen and Scholes (1972) and Fama and McBeth
(1973) found a positive relationship between beta [a measure of risk] and average returns in the period 1926-68” but
“more recent empirical studies (Reinganum 1981, Lakonishok and Shapiro 1986) … could not demonstrate [the same
relationship] for the period 1963-90”. Finally Fama [21] one of the major figures in the financial management literature,
revisited his early work in a major study for the entire period 1926-90 and concluded “the SLB model does not describe
the last 50 years of average stock returns”.
“This is a strong statement made by two leading researchers in a leading journal in the field. Understandably, the
response of financial economic researchers has been mixed” [20] but as early as 1987 Boyadian [22] reported the
practice in investment banking has mainly been to marginalise risk calculations as a factor in decision making.
The implication to the IS literature is compounded because it has borrowed all its risk concepts from the strategic
management and from the financial management literatures.
Promising Directions
Having established that there is something of a “crisis” in the field of risk management, it seems unwise to build an
IT risk management and governance regime solely around the current risk management paradigms. Having said that, it
needs to be remembered that the issue with IT projects is that many success factors lie outside the control of the IT
function and any framework proposed must therefore integrate with the larger risk management frameworks.
Two additional literatures should be examined before proposing any framework, the corporate governance literature
(because the Board of directors must bear the responsibility for adequate risk management) and the management
literature (because the Board relies on management advice to carry out its responsibilities).
The introduction to this paper described the corporate collapses in the 1980s, the subsequent reviews and the
worldwide acceptance of the Cadbury finding [6] that the Board of directors must bear the responsibility for adequate
risk management. In 1998 Hampel [7] reviewed the effectiveness of the Cadbury practices and concluded that risk
management should not overemphasise controls and be so prescriptive that it is perceived as a ‘box ticking exercise’.
The Turnbull Report [3] took Hampel’s findings to develop recommendations that are now a requirement of listing on
the London Stock Exchange.
Turnbull is being promoted in other countries for business reasons rather than compliance [14] but it does not provide
the specifics to manage IT related risks. Recent failures suggest that the latest risk management regimes in corporate
governance and even Turnbull may be inadequate. In particular they are showing the inadequacy of balance sheet
measures as a risk management tool [24].
Enron and Turnbull have very big implications for the auditing profession with its focus on financial controls.
IT Governance
With this background we can consider the IT Governance Institute’s [25] COBIT recommendations for IT
governance. COBIT was prepared primarily by IT auditors to bridge the gap between the overall business control
models like COSO and more focused IT control models like BS7799, AS/NZS 4444.2 [26], ISO 17799:2001 [27] and
the NIST Security handbook [28] to “provide a foundation that is more closely linked to business objectives while
focussing on IT”. Their definition of IT Governance has an emphasis on control.
A structure of relationships and processes to direct and control the enterprise in order to achieve the
enterprise’s goals by adding value while balancing risk versus return over IT and its processes.
The COBIT framework systematically groups the IT best practices that are believed to improve control of 34 IT
objectives 2 . Major risks outside the control of IT directly such as failure of the organization due to IT projects or IT
strategy are not addressed directly and in comparison to Turnbull: COBIT is more complicated, more prescriptive, less
integrated into existing business processes and therefore more difficult to implement. It does however contribute a very
valuable list of KPIs and KRIs (leading indicators of risk) and relates them to various IT processes.
2
COBIT interprets IT Governance practice as a distinct subset of Enterprise governance and specifies a framework to
report on whether 34 IT activities are meeting 34 defined IT objectives (such as alignment of IT with the business, IT
resources being used responsibly and IT related risks being managed appropriately). The IT risks described within
COBIT are security, reliability and compliance.
Management Decision Making Literature
The management literature on risk is quite diverse but two distinct streams can be recognised. Management decision
sciences is the first stream and can be considered to be normative, following the statistical tradition of all the other risk
management disciplines. Behavioural management decision-making stands in stark contrast and is focused on how
managers handle risk in practice. This stream is most easily identified with Simon, March and Shapira.
Simon [29] was a contemporary of the early 20th century economists but he did not follow the dominant paradigm of
economic rationalism. Rather he posited the notion of ‘bounded rationality’ and the ‘satisficing principle’ which
recognised that human beings do not have the capacity to assess all the risks before making a decision and their practice
is to search through a limited set of options until they find a good enough alternative. He was followed by March &
Shapira [16] who demonstrated that not only do managers not follow the statistical tradition for measuring and
managing risk; they actually reject it as a valid approach.
Shapira’s [30] findings have big implications for any IT Governance framework.
“In the world of executives, probability estimates are treated as unreliable and subject to post-decision control,
and considerations of tradeoffs are framed by attention factors … Managers look for alternatives that can be
managed to meet targets, rather than to merely assess or accept risks… [managers] believe in their ability to
control the odds. This trend is facilitated by systems of organisational controls and incentives that dictate risk
taking behaviour in significant ways.
It is conventional in discussions of management to deplore the pattern of risk taking observed in management
… In the short run, if we wish to encourage or inhibit risk taking on the part of managers, we probably need to
shape our interventions to meet the ways in which managers think. For example, it may be easier to try to
modify managerial attention patterns and conceits than to try to change their beliefs about the likelihood of
events or to try to induce preferences 3 for high variance alternatives.
Achieving change by developing a sound theory of decision-making should include the descriptive, normative
and prescriptive aspects together (Bell, Raiffa, and Tversky, 1988), as well as consideration of the larger social
context in which managers operate.
It might be preferable to have managers imagine (sometimes falsely) that they can control their fates, rather
than suffer the consequences of imagining (sometimes falsely) that they cannot. What is harder to determine …
are the details of the ways in which such managerial impulses for discovering methods to improve the odds can
be reconciled with standard, rational-calculation-based decisions to induce more sensible managerial risk
taking.”
[30, pp128-132]
Summary of literature
We conclude our literature review by tying together the common themes and highlighting problematic issues.
1. The first major theme is that all relevant literatures (with the possible exceptions of financial & engineering
risk management), recognise our current approaches to risk management are recognised not to be working
effectively enough.
2. All literatures recognise an increasing role for judgement over analysis. With complex issues, the process to
ensure multi-stakeholder perspectives is the key.
3. The biggest issue currently faced is how to define risk in terms acceptable to all stakeholders.
4. The dominant risk frameworks that need to be considered are: mainstream Risk Management [2], Turnbull [3],
Standards (COBIT [25] , BS7799 [26][27], AS4360 [15], PMBOK, Basle) and March & Shapira [16][30]
5. The outstanding issue is how to reconcile the predominant managerial practices (which reject the normative
approach.), with the predominant paradigms of understanding and managing risk (which are normative and
based on probability)
3
Shapira [30] quotes (Baker, Jensen and Murphy, 1988) to show that incentives are potentially one way of encouraging
sensible risk taking, but that the current practice is not optimal. “Rewarding and penalizing employees is not done in a
systematic way but, only if a critical level of success (or failure) is reached. These critical levels may not be defined ex
ante in a clear manner”.
A New Framework
The self reflective considerations in the risk management literature and the groundswell of feeling in the corporate
governance area is leading us into some sort of convergence of the current practices and behavioural management
decision making findings.
The schematic diagram in Figure 1 tries to show the relationships between the various Standards in the context of a
generic risk management framework (such as AS/NZS 4360:19994 ).
Agree
Turnbull
Objectives
Consult with other stakeholders
Identify COBIT
Monitor & Review
Risks
Shapira
Basle, Assess
Shapira Risks
BS7799, Treat
PMBOK Risks
4
The International Standards Organization has considered this standard for adoption as a world standard [31]
An Integrated Multi-Stakeholder Framework
Turnbull suggests that ‘many fundamentals of good risk management and internal control are already in place’ but
gives no real guidance for identifying and implementing any missing layers (in IT for example). A more complete
framework is needed because although Turnbull and most of the other dominant standards recommend a multi-
stakeholder view of risk, none address all the issues and none have provided enough guidance on how a multi-
stakeholder input should be implemented or what the common risk language could look like. The new framework needs
to be integrated with other dominant frameworks rather than compete with them and complicate the matter further.
The framework shown in Figure 2 integrates all the promising recommendations and offers a context for IT
Governance to be integrated into mainstream corporate governance practices and all other risk management practices.
The strength of the framework is that it integrates all risk management approaches and reconciles the conflicting risk
management paradigms. It does this because the multi-stakeholder perspective shifts the emphasis from analysis of risk
to judgement of what is acceptable. It follows Shapira’s iterative process of identifying and assessing risks and it can
use statistical analysis to help decision-making without any over reliance on quantitative techniques.
The most important thing is to make risk assessment transparent. The thought process that goes into evaluating
a particular hazard is more important than the application of some sophisticated mathematical technique or
formula, which may often be based on an erroneous assumptions or models of the world. [17]
s
re
su
ea
M
s
RA
n
tio
K
ga
iti
ng
M
rti
sk
po
Ri
Re
does it do what it
Are we exposed?
Risks
Management
right products /
Do we have the
Technology
is supposed to
Regulatory
Financial /
Product /
Service /
services /
channels
Legal /
KRIs
do?
Monitoring - KPIs
&
KPIs
Consequences
Environment
Community
Community
Performance
Reputation Board
Revenue
Assets
Costs
Management
People
Timing Operations
This model addresses this and fully integrates IT Governance into the scope of Corporate Governance and is
illustrated above and described below in the order it would be most logically implemented:
The starting point is to identify the key stakeholders and to list the important consequences for each stakeholder
group. Consequences are the stakeholders (business or department) objectives. Generic objectives are described in the
model and these should be updated over time when the organisational players become aware of the actual words
different stakeholders use.
It is likely there will only be 2-3 stakeholder objectives for each stakeholder group. The consequences / objectives are
grouped by stakeholder.
This multi-stakeholder view of Risks and Consequences is significant for a number of reasons:
• Risks, which could be very numerous, are assessed according to whether they affect a stakeholders
objectives to highlight 10-15 significant risks.
• The determination of the riskiness5 may follow many different approaches. It could be done quantitatively,
intuitively, through consultation or any other means the organization feels comfortable with. It is likely to
be an iterative process starting from the first person to reporting a risk and the likely discussions to assess
and reframe the risk until it is perceived to be acceptable.
• The multi-stakeholder approach is the key to effectively identify, assess, initiate treatment and maintain a
focus on only the ‘significant risks’.
• Accountability underpins the effectiveness of the framework, and all identified risks should be signed off.
As risks are identified by anyone in an organization, they will alert all the stakeholder groups they believe will be
affected. This initial assessment will be made on the basis of whether the person ‘reporting’ the risk thinks a business
objective in another stakeholder group will be affected or not. It will be the responsibility of a designated stakeholder
within the notified stakeholder group to investigate whether the alert is correct or not. If the investigator is not sure,
he/she should escalate within his/her group until the accountable person signs off on an appropriate action.
• Each stakeholder group will know what risks are likely to affect the things they care about, and they will know
which of these risks deserve more or less attention.
• The relationship between each risk and the different stakeholder groups will be clearly identified.
• The appropriate allocation for responsibility for managing the risk is more likely to be vested with the highest
relevant authority6
Although each stakeholder group will end to focus on the 10-15 risks with the biggest impact on their business
objectives, the number of total risks may be very large. Categorisation will be unique for each organization and could
follow the Basle system (Financial risks, Credit risks, Management risks), the more generic business classifications7
shown in the schematic model or some other system that reflects the major stakeholders perception of how they operate.
5
Risks are events that can affect the consequences / objectives [32].
6
For example, if an IT project has the potential to significantly improve the profitability of the business, the board may
want to sign off on the project and require the project manager to report to a senior manager who is responsible for
realising the benefits or minimising any downside. This senior manager may authorise delays to the implementation of a
project because he believes it will enhance the likelihood of achieving the desired benefit. A project manager alone is
likely to manage on the basis of on time on budget without significant regard to the expected benefits.
7
Boyadjian [22] makes a case for the category Strategic Business Risk – “If we want to know how a company will do
in the future, we should be asking what it is the company must do and do well in the future”
Risk Mitigation Measure
There are many risk mitigation measures available. The BS7799, PMBOK, NIST standards lists some recommended
IT risk mitigation measures. Risk in areas such as OH&S, the environment, legal liability, etc. all have their traditional
treatments and the proposed model integrates all the tools into one framework. The total range of mitigation measures
constitute a suite of tools the organization can implement as appropriate.
The strength of the model in this area is to show which risk(s) a particular risk mitigation measure is addressing. The
issue is that most risk mitigation measures cost either time and/or money and it is unlikely organizations want to blindly
follow all the measures in any one Standard merely for the sake of certification. The goal is to manage risks and if a
multi-stakeholder approach was followed to determine the most critical risks, then the risk mitigation measures selected
will address the most important risks. If the risks have been quantified or affect strategic goals, it may be possible to
cost justify implementation of certain measures, and if not, the funding for particular measures may still be able to be
allocated back to the stakeholder groups that benefit the most from the measure.
KRIs are forward indicators of risk and should probably be based on some measure of the effectiveness of the risk
mitigation measure. In contrast KPIs are lagging indicators of progress in meeting stakeholder objectives.
The KRIs may not8 be in the same units as the KPI of a stakeholder. Some organizations may want to determine the
correlation between KRIs and KPIs but other organizations will be satisfied to have an early warning system of
potential problems. It is incumbent on the implementer of the risk mitigation measure to agree on a relevant KRI, and
the COBIT guidelines may be used as a starting point.
The implementer of any risk mitigation measure should be responsible to provide KRI data to all stakeholders
affected by the risk being managed.
a. Each stakeholder group identifies their objectives. It is better if this is formally clarified through the
normal business planning process, but the objectives can be recognised tacitly. As risks are
identified, the importance of various tacit objectives can be clarified through consultation.
c. Affected stakeholder groups assess the risk iteratively to determine its significance.
3. New KRIs, probably based on the risk management measure, are reported to the affected stakeholders.
There is no change to the existing reporting of KPIs measuring stakeholder objectives, (although some may
be added).
8
A KRI may be number of attacks on the firewall but a KPI may be customer perception of trustworthiness as
measured by market share.
Application of the IMS Risk Management Framework to a case of IT failure
Appendix 1 details an actual case of IT failure experienced by one of the authors. The key details of the case are
summarised and compared to what would have happened if the IMS risk management framework had been followed.
The key events are listed below in tabular form and the Integrated Multi-Stakeholder (IMS) Risk Management response
is listed against each key event.
The case study was of a very common business situation, the integration of computer systems following a merger.
The IT strategy following the merger was to support the business needs by being much more cost efficient internally
and to produce crucial profitability information to manage in a very tight margin business. It was not recognised as a
priority at the time but it was also strategic to build and maintain the functionality into the computer systems to meet
customer needs in highly customised ways because that improved customer service and increased customer switching
costs.
Table 1 Application of the IMS risk management framework to the Risky Integration case
Eleven systems were being rationalised down to three systems. The choice of the three systems had been very
political, but once the decision had been made the majority of the staff resigned themselves to the decision and got to
work. The integration was planned in three stages and the first stage had been achieved without difficulty. The second
stage was technically easier than the first and was being managed by an experienced project manager. There had been
some warning signals of potential problems but to most they seemed to be matters relating to personal politics. No one
really expected any major problems.
Unfortunately all the early warning signs were missed, a last minute chance to delay the project was not followed up
with the attention it deserved and an ineffective go/no go meeting allowed the stage two to proceed and plunge the
company into major financial distress. 30% of the revenue could not be billed and a number of major customers
threatened to leave. All the financial targets were missed, none of the managers received their bonuses and 3 years later
the company received a bottom 5 rating for customer service.
The distress of the situation could be remembered vividly by one of the authors and even now, five years later he still
wondered what could have been done differently. When the case was analysed it was revealed IMS Risk Management
practices would have thrown up four different chances to intervene and is very likely to have either completely avoided
any IT project failure or at the least minimised any adverse impact on the critical business objectives. The results were
particularly surprising because there was no need to implement any complex risk management procedure to realise the
benefits, nor was there any need to use sophisticated mathematical tools to assess riskiness. The two key ingredients
were:
• To communicate in terms of the language of the stakeholder, a language which was accessible to all staff
(in this case the potential loss of 30% revenue and loss of functionality to major customers)
• To ensure a key stakeholder group is accountable for the results, and to escalate to MD and Board level if
this is not occurring. This would normally be a big ask except that the consequences of this case were so
severe that because the responsibility was not committed up front, everyone paid at the end. It required only
the effort to communicate in terms of the key objectives of a stakeholder.
Discussion
The application of the IMS risk management framework in this case has confirmed some key concepts expressed by
Clegg [1].
• Technology is driving change, but it is bringing unmanaged risk, because we are not controlling it properly.
The main language of risk is based on resolving conflicting values. (It is not mathematics)
“One of the strongest and clearest messages that emerges … concerns the levels of fragmentation within
organizations . Company functions and specialisms were described as highly differentiated and separate, often with
their own set of professional interests, agendas and specialist languages. This view of fragmented organizational life
and its associated territorial and political battles helps to explain why co-ordinated effort proves very difficult to
manage. This fragmentation is … especially germane to the domain of new technology … however … IT can be
regarded as a special case of a more general phenomenon” [1]
The multi-stakeholder approach is ideal to resolve co-ordination issues and the case showed it was not difficult to
connect a technical issue to an objective of another stakeholder. Once they can speak in the same terms, the will to
resolve the problem arises if the issue is perceived to be significant.
IT Project Management
Project managers were criticised for their lack of attention to the human and organizational aspects of the systems
that they are responsible for developing and introducing. In their defence however, it was recognised that people
working in these roles are usually not expected to address these issues, are not rewarded for doing so, are not educated
or trained in them, nor supported adequately in any endeavours that they make in these areas. [1]
The case showed that the resolution of the issue required a key stakeholder to be accountable, and for the key
stakeholder to manage the project manager. The project in the case was experiencing a great deal of passive resistance
and negativity. It is very unlikely a project manager could significantly influence this and it is difficult to see how even
the best project management methodology would have made any difference in this respect.
… project management methods and tools are in widespread use; in part this reflects the common concern that projects
run over time and over budget. Unfortunately these same techniques are widely criticized. … For example, some
reported that these methods simply do not work, that they omit too much, and that they are too technically oriented.
[1]
Currently technology is driving change, but it is bringing unmanaged risk, because we are not
controlling it properly.
Regarding the impact of new technology on the way in which work is organized and upon individual job designs, the
majority view was that this is hugely important but largely ignored in practice. Again this was seen as a topic that is
significantly under-estimated. Where it is addressed this is because the job design implications of technical change are
discovered, usually relatively late in the development process. These findings demonstrate that IT remains technology-
led … IT is not seen in an integrated way as raising sets of related business and organizational issues. [1]
The business process issues were not addressed at all by the experience project manager in the case. Her approach
was to implement the system and to fix the problems afterwards. In hindsight, this was completely irresponsible but the
business mangers allowed her to do it. The best quote from a manager in the case is “if we had known the
consequences, we wouldn’t have been so cavalier about it”, yet this same manager was clearly the one who had the
most to lose by implementing badly. He simply did not connect the IT issues with his business objectives.
Conclusion
This paper has laid the groundwork to develop an integrated approach to IT governance and risk management. It has
reviewing the development of all major traditions of risk management. It has presented the current crisis in the field
because of the recognition of the limitations of statistical approaches to risk. Finally, by synthesising the best of all
current practices, it proposed an integrated multi stakeholder risk management framework which is able to
communicate IT risk from an operational level through all decision makers to Board level and beyond.
A case study of a project failure was analysed against this framework and weaknesses in current governance practices
were revealed. The framework holds much promise for practice because it is likely the infrastructure already exists in
current business practices to rapidly implement this framework, it leads logically to an escalation procedure for
accountability, it effectively addresses the multi-stakeholder issues that confront the modern organization and reconciles
the conflict in risk management paradigms.
Further research should be conducted against more case studies of IT failure to refine the tool and then testing in an
action research environment. The testing should try to look for situations where competing risk management regimes
may be vying for managerial attention and should investigate issues with embedding the framework into organizations.
References
[1] Clegg, C., C. Axtell, et al. (1997). “Information technology: a study of performance and the role of human and
organizational factors.” Ergonomics 40(9): 851-871.
[2] Stern, P. C. and H. V. Fineberg, Eds. (1996). Understanding Risk: informing decisions in a democratic society.
Washington, D.C., National Academy Press.40(9): 851-871.
[3] Turnbull, N. (1999). Internal Control: Guidance for Directors on the Combined Code. London, The Institute of
Chartered Accountants in England & Wales.
[4] COSO: Committee of Sponsoring Organisations of the Treadway Commission (1994). Internal control - integrated
framework. New Jersey, American Institute of Certified Accountants.
[5] The Business Roundtable (1997). Statement on Corporate Governance, The Business Roundtable.
[6] Cadbury (1992). The Financial Aspects of Corporate Governance. London, Gee Publishing.
[7] Hampel, R. (1988). Committee on Corporate Governance. London, Gee Publishing.
[9] Applegate, L. M., F. W. McFarlan, et al. (1999). Corporate Information Systems Management. Boston, Irwin
McGraw-Hill.
[10] Turban, E., E. McLean, et al. (2002). Information Technology for Management. New York, John Wiley & Sons.
[11] Remenyi, D. (1999). Stop IT project failure through risk management. Oxford, Butterworth Heinemann.
[12] Sambamurthy, V and R.W. Zmud (1999) Arrangements for information technology governance: A theory of
multiple contingencies. MIS Quarterly 23(2) 261-290rr
[13] Vitale, M. (2001). The Dot.Com Legacy: Governing IT on Internet Time. Australasian Conference on Information
Systems, Coffs Harbour, Southern Cross University.
[14] Young, R. C. and E. Jordan (2002). Lifting the Game: Board views on e-commerce risk. Paper to be presented at
IFIP TG8.6 The adoption and diffusion of IT in an environment of critical change, Sydney.
[15] Standards Australia (1999). AS/NZS4360:1999 Risk Management. Sydney, Standards Association of Australia.
[16] March, J. G. and Z. Shapira (1987). “Managerial perspectives on risk and risk taking.” Management Science
33(11): 1404.
[17] Molak, V., Ed. (1997). Fundamentals of Risk Analysis and Risk Management. Boca Raton, Lewis Publishers.
[18] Haimes, Y. Y. (1998). Risk Modelling, Assessment, and Management. New York, Wiley.
[19] Beck, U. (1992). Risk Society: towards a new modernity. London, Sage.
[20] Ruefli, T. W., J. M. Collins, et al. (1999). “Risk Measures in Strategic Management Research: Auld Lang Syne?”
Strategic Management Journal 20: 167-194.
[21] Fama, E. F. and K. R. French (1992). “The cross-section of expected stock returns.” Journal of Finance 67(2): 427-
465.
[22] Boyadjian, H. J. and J. F. Warren (1987). Risks: reading corporate signals . Chichester, John Wiley & Sons.
[23] Bettis, R. A. and H. Thomas, Eds. (1990). Risk Strategy and Management. Greenwich, Connecticut, JAI Press Inc.
[26] Standards Australia (2000). AS/NZS4444:2000 Information Security Management: specification for information
security management systems. Sydney, Standards Association of Australia.
[27] Standards Australia (2001). AS/NZS / ISO 17799:2001 information technology-code of practice for informational
security management. Sydney, Standards Association of Australia.
[28] National Institute of Standards and Technology (1995). An Introduction to Computer Security: the NIST
handbook: NIST special publication 800-12. Washington, DC, U.S. Department of Commerce.
[29] Simon, H. A. (1945, 1947, 1957,1976). Administrative Behaviour. New York, The Free Press.
[30] Shapira, Z. (1995). Risk Taking: a managerial perspective. New York, Sage.
[31] Price Waterhouse Coopers (1999). Enhancing Shareholder Wealth by Better Managing Business Risk, IFAC Study
9. New York, International Federation Of Accountants - Financial and Management Accounting Committee.
[32] ISO (2000). Working Draft for ISO Guide - Risk Management Terminology. Japan, ISO/TMB Working Group on
Risk Management Terminology.
Appendix 1: Risky Integration Case
Difficulties consolidating IT systems following a merger of two computer services companies
Prologue
In 1996, XYZ merged with Mainframe Australia Ltd to form the third largest computer services company in
Australia. In order to realise the benefits of the merger, the IT systems were rationalised. The decision to select FSMS
over ASIS as the call system was political rather than technical and many difficulties were encountered in the merger.
The following case study describes the context of the key events. Names may have been changed to protect identities.
Chris Little was excited. He had just been promoted to a CIO role and it reflected the confidence senior management
had in him. He had successfully overseen the creation of an IT infrastructure for a newly merged computer services
company and he was convinced a new data warehousing initiative was the next step to use information to drive higher
levels of profitability.
Chris had not been taking the lead with the call system conversion. As far as he knew it was on track and although it
was a key operational system he felt he had bigger fish to fry. He was feeling so good that he decided that he would take
his long overdue holiday and come back to get started on what he felt was the more strategic data warehouse project.
Prior to leaving for his holiday, two ‘techies’ made him aware of a technical problem relating to the merging of the
two call systems.
“They’re decommissioning the ASIS call system but FSMS doesn’t have a flag for T&M and they don’t report
calls the way we do”
“what about John (the support services [IT & Logistics] manager)?”
“We told him first”
“OK, I’ll have a word with them. Thanks for letting me know”
In the same way that Steve Stout had been the owner of the successfully merged billing systems, Dan and John were
the owners of the to be merged call systems. Unlike Steve however, neither Dan and especially not John had fully
agreed with the choice of the new system. They had resigned themselves to the decision. In addition to this, John was
no doubt extremely unhappy to be losing control of the IT function that had previously reported him. With his
promotion, Chris as the new CIO would gain control of the IT function, but he had not yet assumed the responsibilities
of the role and did not know the significance of ‘T&M’.
“Dan, if anything goes wrong with the merger, it’s going to hurt you the most. I won’t be starting till next week,
so can you make sure all the players sign off at the ‘go/no-go’ meeting this Friday. Especially this T&M thing. If
there’s anything fishy, I’m happy to delay it till we’re 100% ready”
“yeah, me too”
The state managers were alarmed and a conference call of the senior management team was convened. The issue was
escalated to the MD of Mainframe Australia.
Later that day a crisis meeting of the technical staff was held. Chris (who had just returned from vacation) wanted to
reverse the conversion and revert back to the two separate systems. He did this with the blessing of Ed Lin the
marketing manager, but Mick Bard, Ed’s representative at the crisis meeting, did not support this option. Cindy believed
that the problems could be rectified within a month but at that stage, no one was sure what all the problems were. Dan
felt that if the problems could all be fixed within a month, the pain of fixing the problem would not be as great as the
pain of reversing the conversions. Mick agreed.
Everyone knew the decision had to be made that day because further delay would have made it impossible to reverse
the conversion.
The decision
Chris responded to the pressure by insisting that the specific problems be itemised before committing to any option.
Within hours, it was reported that 27 key fields had never been considered in the conversion and the business
processes such as T&M invoicing had not been discussed. Estimates of the time it would take to fix 21 of the crucial
fields were between one to six weeks. None of the technical staff at the crisis meeting supported a decision to reverse
the conversion, because they felt it could be fixed. The two business managers in the crisis meeting, Mike Bard from
marketing and Dan Scarlet the operations manager also strongly supported the decision to go ahead.
Mike’s boss told Chris he preferred to reverse the decision but it was apparent he had not told Mike. Chris personally
wanted to focus on the data warehouse initiative but if he were to be the lone voice wanting to reverse the conversion he
could make a lot of enemies for no reason i.e. to go back to the old system was to signal that it had not been done right
and people’s careers would be affected. The atmosphere of the meeting was very intense. Careers were on the line…
Dan was the logical owner of the system. If he wanted to go ahead Chris would do the ‘right thing’ and help fix the
problems. He committed the organization to go ahead.
Technological change however, was changing the market rapidly. The rapid improvement in the capabilities of mid-
range computers and PCs made it possible for customers to run their mission critical IT applications on lower cost
platforms. The market for mainframe computers was shrinking and it was no longer the centre of IT infrastructures. The
mainframe was now only one component of a complex IT environment where hardware was sourced from many
suppliers. The need for fast service for mission critical platforms remained, but highly cost competitive low margin PC
maintenance service providers were squeezing the fat profits.
The merged company took full advantage of the new IT environment by sourcing 2nd hand parts from the US and
breaking IBM’s monopoly on mainframe computer parts. They sourced inventory and trained staff to service most
brands of mainframe, mid-range and PC computers and they marketed themselves as a multi-vendor computer
maintenance services provider.
XYZ management’s style were more appropriate in the new business environment but the overall corporate goal was
to keep their high margin mainframe customers for as long as possible before migrating them off mainframes to more
cost effective and lower margin mid-range and PC platforms. Information was critical to managing in this business
although few in the management team apart from the MD, CIO and financial controller realised this need (eg.
profitability by customer information). Together they prepared the strategic IT plan for the future of the new company.
Extracts from company newsletters capture some of the excitement at this time:
The last newsletter dated 12 January 1997 proudly declared that “we’re not integrating anymore … we’ve gone beyond
that”. The confidence within the company was reflected in both the draft IT strategic plan below (fig 3) and the planned
consolidation of the strategic ‘Call System’ on the 20 Jan 1997.
A second major systems integration of the call systems was crucial to the business for operational reasons. The major
cost in the business were staff. The staff costs were largely driven by the business process which in turn was
underpinned by the IT system. It was necessary to have one call system before the business process could be effectively
fine tuned for efficiency.
• ASIS was largely undocumented and all the knowledge lay in the head of one talented but somewhat fickle
programmer known to have occasional ‘Prima Donna’ fits of uncooperativeness.
• AREV, the development language, was being superseded and would no longer be supported in the near future.
• Negotiations were proceeding with a software development company to overcome both these issues. The
development company could provide staff that could learn ASIS and support AREV. Despite this, the issue
remained that AREV was a dying language and programmers would be difficult to source.
• AREV had its roots on a PC platform and there were doubts as to whether it would be fully scalable to handle
the demands of the newly formed $100M pa company. Independent tests had shown that it would work, but the IT
staff in the parent company were unconvinced. One very telling sign was that whenever the lights flickered
because of power surges, the developer looked nervous and would often rush to the server to check everything
was ok. He said that once the network had been upgraded, this problem would be overcome.
• FSMS an alternative system, although not fully developed, was being sponsored by the international parent
company to be the services system of choice for all subsidiaries. It was based on Ingres: a well known
development language and there was no question that it had the potential to handle the increased demands of the
merged company.
• There were however some doubts regarding the quality of FSMS. The development group had a poor
reputation and the specifications on which it was based were sometimes based on best practice from over six years
ago. The was a rumour that the local parent maintained its profitability on the basis of software development
revenue and that it was milking its international parent for all it could get.
Organization Structure
XYZ was set up to have a separate market identity from its parent company. In practice, it had direct reporting links
to its parent, but because of profitable results, it was making significant progress in establishing its independence.
Mainframe
International
Mainframe
Australia
Douglas Hollow
XYZ
Software
Ed Lin Steve Stout Dan Scarlet John Smart Chris Little
CIO Development
Sales & Marketing Finance Operations Support Services Information
Services Group
Cindy Michael
Mick Bard Logistics I. T. FSMS FSMS Development
Implementation
Contracts &
Call System Logistics System
Billing System
Dick felt that Dan's attitude was ‘we have too, we don't have a choice’ and that John's attitude (after losing control of
the IT function) was that he didn't care any more. He was suspicious and thought they may be looking for scapegoat.
He is said to me "get a lawyer... be very careful who you talk to and what you say"
He felt that the earlier contracts systems (CFINCS, OVERSEER & SPARCS to ASIS) conversion was successful
because the people worked so closely together. “With FSMS, there were always two people between (the people who
knew how it worked). Even the development team didn't know what the operations team were doing.” His overall
feeling was that the people issues had never been adequately addressed i.e. Why should we do this?
The result
The next few months were spent rectifying the problem. As each problem was solved one by one, Chris seethed
inside because they were easily identified and he asked himself “why wasn’t this discussed and resolved before we cut
over?” He tried apologising formally to the customers but Mick Bard in marketing refused to authorise any document
acknowledging responsibility because it might open XYZ to liability claims.
By the 17th March, two months later T&M revenue was starting to be collected again but there were still a number of
major tasks to be completed. The company had lost 30% of it’s revenue during this period. No one had realised it would
be this significant. Dan Scarlet commented “if we had realised the implications, we wouldn’t have been so calvalier
about it”. Every IT system consolidation had been delayed 2-4 months.
All the financial targets were missed that year. None of the senior managers received their bonuses. Three years later
XYZ, in an independent survey of customer service, had a ‘bottom 5’ rating.
Post Script
The ASIS support staff were completely frustrated with the process and stopped cooperating. The key developer
decided that if he was not going to be listened to, he would increase his hourly rate from $60/hr to $200/hr and leave as
soon as he got another job. The other developer opted to leave the AREV support company that XYZ contracted to
overcome support difficulties. He offered to work for $120/hr and continued at this rate for the next 4 years. XYZ had
no choice but to pay and it also had to pay out the software development company to prevent legal action for taking one
of their staff. The news spread and some technical support staff for the legacy logistics system did the same thing.
Development stopped on the FSMS system after another six months of political negotiations. It was important that
the international sponsor not be seen to be at fault and the cancelling of the project had to wait until he had another
successful project to justify diverting his attention. FSMS was dropped in favour of a packaged solution. The
implementation of the packaged solution was successful only after its second attempt. Cindy, the project manager of the
failed call conversion managed both the failed and the successful packaged solution implementation.
The logistics system consolidation has been deferred indefinitely and the logistics function has been outsourced.
Key Performance Measures started to be produced from the data warehouse initiative 90 days after the call system
difficulties were resolved.