Crossing Digital Divide

The Information Society Library
G E TT I N G T H E B E S T O U T O F C Y B E R S PA C E
CROSSING THE EXECUTIVE

DIGITAL DIVIDE
A jargon-free guide to what it takes to gain value
out of expenditures in information technologies
and to sensibly manage their risks
Eduardo Gelbstein
Recent publications by the same author
• Justifying I.T. audits to executives: paper for the proceedings of the “Governance and Audit Africa”
Conference, Mombasa, Kenya, 2006. Published by the MIS Training Institute.
• Crossing the Executive Digital Divide (abriged version), 2006, published by the Diplo Foundation
• Jargon, protocols and uniforms, barriers to effective communications (with Stefano Baldi), Intercul-
tural Communication and Diplomacy, 2004, published by the Diplo Foundation, http://www.diplo-
macy.edu
• Misunderstood: The I.T. manager’s lament, Intercultural Communication and Diplomacy, 2004,
published by the Diplo Foundation, http://www.diplomacy.edu
• The Information Society Library (consisting of ten booklets) (with Stefano Baldi and Jovan Kurbali-
ja), December 2003, published by the Diplo Foundation. Details available at: http://www.diplomacy.
edu/ISL/intro.htm
• Sections on “Data vs. Information”, “End User Computing” and “Outsourcing” of the Encyclopedia of
Information Systems, Academic Press, 2003.
• Conectivity for a better world, IEEE LEOS Newsletter, Vol 17, N° 3, June 2003
• Information Insecurity (with Ambassador A. Kamal), 2nd Edition, November 2002, published by
the United Nations Information and Communications Task Force – available as a free download
from: http://www.unicttaskforce.org
ISBN
Published by DiploFoundation and Global Knowledge Partnership
DiploFoundation
Malta:4th Floor, Regional Building
Regional Rd.
Msida, MSD 13, Malta
Switzerland: DiploFoundation
Rue de Lausanne 56
CH-1202 Genève 21, Switzerland
E-mail: diplo@diplomacy.edu
Website: http://www.diplomacy.edu
Global Knowledge Partnership Secretariat
Lot L2-I-4, Enterprise 4
Technology Park Malaysia, Bukit Jalil
57000 Kuala Lumpur, Malaysia
Email: gkps@gkps.org.my
Website: http://www.globalknowledge.org
Edited by Dejan Konstantinović and Steven Slavik
Illustrations: Zoran Marčetić – Marča and Ed Gelbstein
The use the Hemera Royalty Free “Giant Box of Art” and the copyright free Microsoft
Clipart Gallery is gratefuly acknowledged
Cover Design by Nenad Došen
Layout & Prepress: Aleksandar Nedeljkov
© Copyright 2006, Eduardo Gelbstein
Introduction
When technology becomes master

We get to disaster
Faster
Grook by Piet Hein
Purpose of this book

In just a few decades, information and communications technologies
(ICT) have become ubiquitous: manufacturing and research, critical in-
frastructures, transportation, hospitals, government, diplomacy, educa-
tion, financial services and more have been transformed by ICT.
This has enabled the creation of significant value but technology is neu-
tral. It can be used to advantage and also misused and abused. Nonethe-
less, as the world becomes connected, the way in which ICT reduces the
impact of distance and time zones has resulted in the creation of an In-
formation Society.
Participation in the Information Society was a major theme of the World
Summit on the Information Society, (Geneva, December 2003 and Tunis,
November 2005). However this participation requires substantial sums
of money for investing in technologies and the supporting their day-to-
day operation. In the developed world this money is in the range of 3 to
8 percent of an organisation’s total expenditures.
In developing countries, this percentages are even higher and there may
be additional challenges: infrastructure facilities (electricity and telecom-
munications) of limited capacity and not having the same degree of ex-
perience in the management of ICT projects and operations. Both are
components of the Digital Divide, and barriers to the successful and sus-
tainable implementation of ICT.
The analogy of holding a tiger by the tail is appropriate to both the devel-
oped and developing worlds. The role executives in the governance of ICT
is to make the tiger perform to deliver value and to ensure that its asso-
ciated risks are sensibly managed. This is distinct from the technical
management of ICT, a specialist’s job that could be seen as the equivalent
of feeding the tiger and cleaning its cage.
The technical people who deal with ICT have major responsibilities but
they cannot succeed without the participation of executives: they know
what constitutes value and have the authority to drive change, take the
actions needed to contain risk and derive benefits.
As ICT should be used to improve the way organisations work, support
new are information-rich services and/or products. This has three side
effects:
One: it changes the way people and organisations work. Change is never
easy.
Two: it requires the people using these technologies to acquire new skills,
and, in particular, information literacy. This requires learning to be con-
tinuous.
Three: A new family of risks notably those of information security and
cybercrime.
Spending money on ICT is easy: take enthusiastic technical workers, add
vendors, consultants, service providers and a few other components and
that’s it. Then wait for a while (from months to years) and this will result
in new infrastructure, new or improved computer systems or facilities
such as e-mail systems or a website.
However, this is just the beginning of the story. What may actually hap-
pen is that:
• Many projects, particularly software made specially for an organisa-
tion, end up costing much more than planned, take a lot longer than
promised and often fail to meet the promises made when approval to
proceed was given. Many large projects are abandoned before com-
pletion…;
• There is a track record of unfulfilled expectations. The promises of
delivering executive information”, “decision support”, “competitive
advantage”, “superior performance”, “knowledge management” and
many other buzzwords have frequently not materialised;
• Many other investments do not produce worthwile business results,
despite the expectations held when starting to work on them. The
money could have been better spent on other things…;
• When an organisation does not have the knowledge and experience
to manage the life cycle of such investments, once the vendors and
consultants have gone, the situation becomes unsustainable and
things go from bad to worse;
• There are also systems which the workforce is unable to exploit be-
cause of the lack of skills and lack of training. In some cases there is
also an inability to adapt to new methods of working resulting from
the new technologies and systems;
All of these can be found in the private and public sectors.
Many, if not most, executives, place the responsibility (sometimes also
the blame) for the above problems on their Chief Information Officer, or
whatever other title the most senior person dealing with these technolo-
gies may have.
At the same time, many Chief Information Officers complain that their
bosses “don’t understand their problems”, that they are not allowed to
contribute to business strategy, that their budgets are insufficient, etc.
This is a sign that there is another divide: one between executives – who
have many other responsibilities to attend to – and information technol-
ogists. This book is intended to bridge this divide by taking the mystery
out of the many aspects of managing and governing ICT.
The premise for this book is that the position of an organisation in the
Information Age or Information Society – ranging from failure to lead-
ership, is strongly influenced by the degree to which the organisation is
affected by an Executive Digital Divide, where there is little or no mean-
ingful communication between executives and technologists on how to
gain the most advantage from the potential that technology has to offer.
This book, based on many years of experience and research (much of it
the hard way), consists of 17 chapters that can be read independently of
each other. Each chapter starts with a small number of key questions on
the subject it covers and a chapter summary, recognising that executives
may not always be able to find time to read books that have several hun-
dred pages.
Each chapter ends with a series of action points – activities that should
not be delegated to ICT people in order to ensure that ICT is used to ben-
efit the organisation. Whenever appropriate, the chapters include exam-
ples from the real world and Executive Dilemmas. The latter differ from
case studies in that the situations described in them rarely have a single
right answer, and the most appropriate answer for one organisation may
not be appropriate elsewhere.
C O N T E N T S
Introduction and purpose of this book�� 3

1. Setting the scene for the executive digital divide
Key questions and chapter summary�� 13
ICT is just another technical thing… but is it really? �� 13
Digital divides�� 16
The ICT Board game �� 19
Action Points �� 23
2. How well are we doing with ICT?
Why good diagnostics make a difference�� 27
Answering the six key questions �� 29
A typical toolkit for executives�� 34
Executive dilemma: The auditors’ report on ICT �� 46
Action points �� 47
3. Information assets and technology
Data, information and knowledge �� 53
How organisations use information �� 56
The role of technology �� 63
Managing information assets as a portfolio�� 64
4. Impact of ICT on organisations and on people
Observations �� 73
Should investments in ICT make a difference?�� 76
Human and organisational reactions to change�� 79
The Executive’s challenge�� 83
5. Financial aspects of ICT: expenditures
Why does ICT cost so much?�� 87
Direct and indirect costs of ICT�� 97
Executive dilemma: why don’t we know the true cost of ICT?�� 100
Can expenditures be contained?�� 101
Is outsourcing expensive?�� 103
6. Financial aspects of ICT: benefits
The ICT benefits paradox �� 108
Identifying and quantifying benefits related to ICT �� 109
Techniques for evaluating benefits�� 112
Executive Dilemma: Quick spend�� 114
The problem with ICT benefits�� 115
Another Executive Dilemma: Technology migration and technology
opportunity �� 121
7. ICT strategies that work
Setting the scene for an ICT strategy�� 127
The role and importance of an ICT strategy�� 128
Getting to grips with an ICT strategy �� 129
Factors that make an ICT strategy successful �� 130
Prerequisites and minimum contents of an ICT strategy�� 133
Executive Dilemma� �� 138
8. ICT service delivery processes: resources, quality and risk
Definition and importance of processes�� 143
The art and science of Process Management �� 145
Service delivery processes and their risks �� 148
People issues �� 155
Executive Dilemma: the chaotic data centre�� 156
9. Managing ICT projects for success, quality and reduced risk
What exactly is a project?�� 161
Facts about ICT projects �� 164
Quality: The project sponsor’s dilemma �� 170
The most common reasons why projects go wrong�� 175
The art and science of Project Management �� 178
10. Risk management
Managing risks�� 183
Murphy’s Law is alive and well �� 184
The main areas of ICT risk�� 187
What are the steps needed to manage risk?�� 190
The executive’s role in managing risk�� 194
11. Information insecurity: the external risks
Importance of information security�� 199
Issues for Executives �� 202
12. Information insecurity: the insider threat
Electronic Misconduct: abuse, fraud and crime through ICT �� 217
The motivators that drive the insider threat�� 222
Executive dilemma: Suspicion of a malicious insider�� 223
Executive Dilemma: What shall we do about Susan?�� 224
Preparing for protecting against insider threats �� 228
Issues and limitations arising from this protection �� 235
13. Contingency planning for ICT
Definitions �� 239
ICT disasters and their causes�� 240
Executive dilemma: What happened to our business continuity
arrangements!?�� 241
The four main stages of dealing with an emergency�� 241
Specific challenges of Contingency Planning and Business Continuity252
14. ICT organisations and ICT people
Roles and responsibilities of ICT organisations�� 257
Centralisation and outsourcing �� 259
The roles and responsibilities of the Chief Information Officer�� 262
Placing the ICT function within an organisation �� 264
Measuring the performance of an ICT function�� 264
ICT people: The Chief Information Officer and others �� 266
Executive dilemma: The CIO has resigned�� 269
Organisational mistakes that prevent the CIO from succeeding� �� 270
Good questions to ask ICT managers�� 271
15. Outsourcing
Setting the scene for outsourcing and offshoring�� 279
Activities that lend themselves to outsourcing�� 280
Benefits, potential problems and risks in outsourcing �� 283
Critical Success Factors (CSF)�� 288
A step-by-step guide to managing the outsourcing process�� 289
16. Legal and ethical aspects of ICT
About the law and ICT �� 297
The special nature of legislation concerning ICT�� 299
ICT related areas are covered by legislation � �� 300
ICT contracts and licences: practical issues�� 304
Ethical issues�� 308
17. Concluding remarks
A.1 Listing of all the key questions �� 323
A.2 Listing of all the action points. . . . . . . . . . . . . . . . . . . . . . . . . . 329
A.3 A short contradictionary of ICT frequently used terms. . . . . . 339
Acknowledgements �� 341
About the author�� 343
C h a p t e r
1
Setting the scene
Don’t talk to me about computers. It’s Greek to me.
Genuine statement from a Chief Executive to his

Chief Information Officer
Crossing the executive digital divide 13
Key questions and chapter summary
• Why should an executive be interested in this kind of “tekkie” thing

– information technologies are the job of the Chief Information Of-
ficer… aren’t they?
• Is there really an “executive digital divide” and if so, what is it
about?
The success of the Information and Communications Technology (ICT) industry has been
such that many organisations now have a computer in every desk, workers have their own
personal computers, personal digital assistants, smart mobile phones and more.
Many countries in the developing world are major players in ICT – such as the software de-
velopment industry in India and the manufacture of personal computers in China. Interest
in participating in the Information Society is apparent everywhere.
Many executives tend to see ICT as a purely technical matter to be delegated to a Chief In-
formation Officer or to a service providers. This chapter argues that there is another way of
looking at these technologies: as part of a “game” played by executives and the Chief In-
formation Officer, and presents several facts about ICT that require executive attention.
The ICT game is played with real money, it has flexible rules. The definitions of what it
means to win or lose varies from place to place. Moreover, once the game has started,
there is no way to leave it other than by going out of business.
Experience shows that when executives do not take an interest in the strategic role of ICT,
these systems and facilities are not seen as corporate assets but rather as an expensive lia-
bility. In these situations return on the investment is poor, and even negative.
If ICT is expected to play a strategic role in an organisation, the digital divide that exists be-
tween the executive unfamiliar with what it takes to derive benefits from these technolo-
gies and the technologists who tend to focus more on technology than on what it is used
for must be bridged.
ICT is just another technical thing…

but is it really?
Of course there is a large technical component to “Information and com-

munications technology” (ICT from now on) but technology is merely an-
other word for tool and what counts is the ability to use such tools and
there is a divide between those who know how to and those who don’t.
This is nothing new, and Mark Twain said that “the man who does not
read good books has no advantage over the man who cannot”.
Electricity and telephones have become critical utilities as it is virtually
impossible to conduct any kind of business activity without them. Exec-
14 Crossing the executive digital divide
utives do not need to know how they work to be able to use them to ad-
vantage: plug the right device into the right socket and that’s it. Some-
body else takes care to make sure that it all works properly. This is not
yet the case with computers but it is increasingly going that way.
Besides, the disruption that followed the widespread use of electricity and
telephones took place in the 19th century and the current generation has
no memory (other than by visiting a museum) of the transitions that took
place in factories and offices, in banking and commerce and also to the
providers of the services that new technologies displaced such as the sup-
ply of coal and ice to buildings, gas lighting, telephone operators and
many more.
Electronic computers are relatively new – roughly sixty years. Computer
networks are newer still and the earlier ones were limited to at best, a sin-
gle organisation. The Internet started as a multi-organisation network for
a limited community at the end of the 1960s. The World Wide Web and the
current enthusiasm for the Internet became apparent in the mid 1990s.
In the early days anyone who do anything at all with a computer was re-
ferred to as a “mathematical genius” and the role of computers was lim-
ited to automating relatively simple repeatable activities involving large
quantities of numbers, like accounting and payroll.
In these earlier days, executives never saw a computer unless they were
curious to see what this expensive monster in the basement looked like:
lots of flashing lights, many switches and surrounded by people wearing
white labcoats.
Information and communications technologies have become ubiquitous
and, at least in the developed world, financially more accessible than ever
before. Despite this much about them remains a mystery to executives
even though it is now well known that expenditures on ICT represent a
substantial proportion of operating costs and that these costs are rising.
Facts about ICT

ICT is an expanding trillion dollar plus global industry driven by inno-
vation that feeds further innovation. Dramatic cost reductions in the last
ten to fifteen years have allowed ICT to reach a growing proportion of the
world population both in the workplace and, increasingly, at home:
• At least 750 million people around the world access the Internet and
there are over 70 million websites. This number is growing fast and
is projected to exceed the number of fixed telephones around the

world (1 billion) in the near future – in addition to which there were
1.7 billion cellphones at the end of 2004.
• Cellphones can perform functions other than to enable voice messag-
es (radio, music jukeboxes, photographic camera, Internet access, e-
mail and text services);
• Personal computers, personal digital assistants and cellphones have
become commodities in a large number of countries;
• Organisations are irreversibly dependent on ICT, to the degree that a
short network outage or an interruption of a few hours of the elec-
tronic mail service causes significant disruption to large numbers of
workers;
• Total ICT expenditures in the corporate environment are typically in
the 2.5 to 10% of their total expenditure and are growing as ICT plays
an ever more important role in day-to-day operations;
• ICT accounts for substantial costs. Its true total cost which includes
several hidden components is considerably higher than the budget of
the ICT function – sometimes twice as much. The benchmark for this
cost in early 2005 is an average of 12,000 dollars per employee per
year;
• The demand for additional resources for ICT keeps growing (it is fore-
casted that in the USA corporate ICT expenditures in 2005 will be
7% higher than in 2004) even though unit costs of hardware and tele-
communications keep dropping;
• ICT has a track record of runaway projects with escalating – if not
exploding - costs and timescales and many unfulfilled promises
which led many ICT departments to lose credibility in the eyes of ex-
ecutives;
• Technology lifecycles have become short requiring substantial and
frequent investments merely to “keep up to date”;
• The value derived from ICT investments is hard to determine, let
alone measure as there are no standard techniques for ascribing val-
ue to information. In addition, value will not be found in the places
where expenditures are incurred but elsewhere in the organisation,
and this value does not arise from technology but from what people
can do with it.
As is these facts were not enough, ICTs have also brought with them man-
agement issues that have become executive headaches:
• An inability to exploit the organisation’s information assets because
of a lack of knowledge of what is available, lack of training of the
workforce and a lack of rec-

Inconsistent logic
ognition that data and infor-
mation are valuable corpo- Companies that provide a car to selected em-
ployees, make sure that those getting it have a
rate assets; driving license (which implies training and pass-
• Business risks: runaway and ing an examination). Companies that provide a
failed projects, poor quality fully configured notebook computer to selected
of ICT services, inadequate employees do not ask for the equivalent of a
driving license – i.e. evidence that the person in
contingency planning, lack question has had any kind of training and inde-
of compliance with legisla- pendent validation of their computer skills.
tion and more; However, the lifecycle costs of a small car and
• Unfulfilled ICT promises: those of a high end notebook computer, fully
still waiting for “executive configured and loaded with software are in the
same order of magnitude...
information”, “decision sup-
port”, “competitive advan-
tage”, “superior performance”, “knowledge management” and many
other buzzwords. Expectations are greater than results;
• Developing robust business cases for investments in ICT given that
value is hard to determine;
• Learning how to develop and implement ICT strategies that lead to
improved business performance and results;
• The lack of effective communications between business executives
and ICT people;
Depending on how these are handled by an organisation, ICT could be seen
by executives as either a strength or a liability – or, if things are not too bad,
a weakness. In this situation the organisation will not be likely to become
a major player in an information society or an information economy.
Digital divides
Much has been written about the Digital Divide. This term is mainly used
to describe those parts of the world that have no access to ICT at afford-
able prices or that cannot invest in the necessary infrastructures. Those
facing these problems usually also lack the skills and the software need-
ed to put ICT to productive use.
Advanced economies have digital divides too – parts of the geography
where services like broadband Internet access are not available or socio-
economic groups of people who are unable to exploit these technologies.
This book is about a different “digital divide”: that of executives who are
too busy, unfamiliar or even unaware of the impact that ICT can have on
an organisation in the Information Age and have not thought about what
it takes to deploy ICT successfully in an organisation.
There are other Digital Divides, for example in countries which for polit-
ical or cultural reasons restrict access to information from external sourc-
es such as satellite television or the World Wide Web. These aspects of the
Digital Divide fall outside the scope of this book.
The executive Digital Divide

A first diagnostic an executive can use to determine the extent of this per-
sonal divide, is the ease with which the following five questions can be
answered without having to ask someone else:
• Does my organisation know what information it has and is it treated
as an asset?
• What is this information primarily used for?
• Is the value of the organ-
isation’s information un-
derstood, managed and
measured?
• Is the organisation cul-
turally ready for the In-
formation Age and focus-
ing on information for its
own benefit and that of
its stakeholders?
• Is the organisation tech-
nically ready for the In-
formation Age?
The people responsible for ICT are very likely to enthusiastically say “yes”
to this last question. However, the full answer also requires the organisa-
tion’s workforce to be computer and information literate and to have ac-
cess to suitable training and support.
The dialog between executives and technologists, when it takes place at
all, is made difficult by different perspectives on what is important which
may differ from the executive perspective, with the result that ICT activ-
ities are not aligned with the needs and priorities of an organisation. Be-
sides, jargon perpetuates ICT’s mysteries.
As the Information Age is only just starting, most people are finding their
way learning how to gain the benefits that ICT has to offer. Treating to-
day as a transitional stage towards a new kind of literacy, and taking steps
to increase it, will have a good return for individuals and organisations.
The ICT function does not usu- Our changing times :
ally report to senior executives In the 5th Century AD, St. Ambrose, Bishop of Mi-
but is placed lower in the man- lan was described as the brainiest person in the
agement structure. Chief Infor- world: he could read without moving his lips.
mation Officers (CIO) or Direc- In 1970, only a small number of people could do
tors of ICT often work as peers of anything useful with a computer.
those responsible for other utili- In 2004, there are an estimated 750 million
ty functions. people who have access to the Internet.
Because some 50 years ago the finance function was one of the first to
adopt computer systems, it is not unusual to find the CIO reporting to the
Chief Finance Officer or to the Chief of Administration. This reflects the
significant cost and emphasis on technology of ICT as a utility. When an
organisation categorises the CIOs as a “technical expert”, thet are treat-
ed as outsiders to the business strategic planning and development pro-
cesses.
To compound the CIO’s challenge, the benefits of making good use of ICT
do not arise from technology, which is only an enabler, but from peoples’
creativity, ability to spot opportunities for changing the status quo and
to apply and use technology where it matters – having an ICT strategy
that works.
Exploiting ICT can very different from one organisation to another, de-
pending on where they are positioned on each of the lines. This can only
succeed when technical services work well enough for their intended pur-
pose, just like any other utility.
This utility aspect of ICT (as distinct of its strategic use) distances exec-
utives from the ICT function and, conversely, the ICT function finds it-
self isolated (and often unloved) by the executive.
The ICT Board game
Why not look at investing in ICT as if it were a game that has to be played
in order to participate in the information society?
This game is played with real money and it is not a game of chance (and
certainly should not be). Unlike a board game it should be a Board game
in which the governance of ICT should not be delegated (or abdicated) to
technical people in the hope that all will be well.
The game, which requires considerable sums of real money involves sev-
eral players, among them the Chief Executive Officer, the Chief Opera-
tions Officer, the Chief Finance Officer, the Chief of Human Resources,
the Internal Auditors, the Chief Information Officer and also external
parties: vendors, service providers and outsourcers.
The game has few rules:
1. Once a player has entered the game, there is no possibility to quit;
2. Each player has different objectives and different definitions of what
it means “to win”;
3. There are three strategies for playing this game: Lead, Follow or Lag
Behind;
4. Winning a round of this game does not give a player an advantage
for subsequent rounds.
There are shades of winning this game, and these are determined by how
well the player is able to perform in a number of areas:
• Like in other board (and Board) game, a wrong move can penalise a
player (for example “you have invested in the wrong computer sys-
tem and must live with it for at least five years before you can replace
it”) while an inspired move can place a player in the lead;
• Benefits are always in the future and speculative. Playing this game
to win requires an act of faith from executives, who place their or-
ganisation’s money on priorities, choices and vendors that appear
right at decision time;
• Playing the game to be a leader involves the biggest risks –by invest-
ing in technologies and products that may not be mature enough or
Highly visible and successful first movers include Amazon, the online retailer, e-Bay, online
auctions and Federal Express (document and parcel distribution). Many other winners of
the ICT game are only visible in their own field and not so well known by the general pub-
lic. These will be found in hospitals, airlines, online learning institutions, financial services,
and everywhere else.
Successful leaders breed followers – when for example a few banks started to offer online
access to their clients, other banks had really no choice but to do the same. This “me-too”
approach works well for organisations that have business strategies that do not require
them to be the top player in their market.
It is inevitable that there will be laggards – organisations that because of their culture or finan-
cial environment are unable to even keep up with the followers and end up lagging behind.
Laggards would typically have old computer systems (some possibly no longer useful) and old-
er technologies (perhaps no longer supported by their vendors). The gap between leaders and
the laggards will continue to grow creating yet another form of a digital divide which, if noth-
ing is done could make laggard organisations irrelevant in the Information Age.
developing products and services for which the market may not be
ready. Those first movers that succeed have a major competitive ad-
vantage over others in their field;
Losing the game results in one or more of the following, although this list
is not complete:
• The organisation’s ICT is a clear liability that prevents it from main-
taining a credible position in the Information Age;
• The organisation has ICT projects that failed or were completed late,
at greater cost than planned and/or with disappointing results;
• The day-to-day ICT operations of the organisation are not good
enough, information security may be inadequate and contingency
plans insufficient;
• The cost of ICT to the organisation is not well known and, if known,
higher than peer organisations.
This book proposes to executives two premises to avoid becoming a los-
er in this game:
Premise #1: Competent ICT people are very interested in the subject, en-
thusiastic, optimistic and hard working. However their focus may be
stronger on technology than on what it is used for and how well this is
done;
Premise #2: Certain decisions concerning ICT are too important for an
organisation to be left to ICT people: The governance of ICT should not
be left to the Chief Information Officer alone and should not be a rubber
stamp by the executive or the Board. Behind the jargon and acronyms,
the management practices that lead to effective results in ICT are no dif-
ferent from those in other activities.
Are we playing this game the wrong way?

Possibly, if ICT is not part of the
executive’s agenda in “playing
the Board game” in those areas
that can make a difference to the
performance of their organisa-
tion, if this is due to lack of time
or lack of interest.
ICT professionals appear to be
seldom well regarded, trusted or
admired in the organisations for which they work and rarely have a place
in management boards or other executive circles. Instead they are regard-
ed as the organisation’s plumbers, a word used by several senior ICT man-
agers at various times. They also frequently voiced the complaint that “my
boss does not understand me and is not interested in what we do”. But
then it is also true that ICT people are, by and large, not great communi-
cators.
When the working and cooperative relationship that ought to exist be-
tween business processes and ICT are not strong, the organisation as a
whole is weakened.
Discussions over many years confirmed that ICT is regarded by many ex-
ecutives (who avoided playing the Board game and detached themselves
from these matters) as an expensive headache while a smaller number of
them see ICT as a force to strengthen their organisation and enrich the
work environment when properly executed.
The utility aspect of ICT – the technologies, processes and people that:
• Make computers, networks, directories, software and other things,
function correctly seven days a week, twenty four hours a day;
• Ensure disruptions are handled quickly and effectively;
• Take steps to deliver these services at a reasonable cost
is unavoidable (it is also outsourceable). This utility represents 70 and 80
percent of the ICT budget and should only be an executive concern when
it does not perform as expected (technically, financially or organisation-
ally).
The strategic tool role of ICT implies innovation. Innovation drives
change. Given that most people desire stability and that nobody likes to
be a loser, change represents a significant executive challenge because it
is likely to be opposed.
Of course, if the ICT utility does not work well enough, it is unlikely that
ICT will be used as a strategic tool as the Chief Information Officer would
not have the credibility to be a member of the executive team.
Action Points
An old proverb states that “When there is a will there is a way”. This is
particularly true for ICT and bridging, or at least narrowing, the Execu-
tive Digital Divide is one step that should help.
Executives who take a serious interest in ICT and see it as a strategic tool
and are also prepared to lead the organisational change that follows such
implementations will be better placed to gain value out of the significant
investments involved than those who don’t.
Taking a greater interest is necessary but not sufficient. The executive
also needs a good awareness of what ICT can deliver and what it cannot
do, understand the issues that need to be addressed, be good at risk man-
agement and not least, ensure that the right people are engaged to deliv-
er results that make a difference.
C h a p t e r
2
How well are we
doing with ICT ?
Of course you are entitled to a

second opinion, but please hurry !
Advice supposedly given by a doctor to his patient

• What is the track record of the ICT function?

• What are the efficiency and effectiveness of the organisation’s ICT?
• What is the value assigned to information, knowledge work and
ICT?
• Where does the money spent on ICT go?
• What are the legacies and constraints on ICT in the organisation?
• Do we have a well articulated vision of how we should exploit ICT?
• What tools and methodologies can an executive use to find out an-
swers to these questions?
The performance of the ICT utility is well understood – technical services are invisible until
they fail, at which point the activities of an organisation are disrupted. But this is not the
only symptom of poor performance: the technology may work wonderfully but when it is
used to support poor processes, it only succeeds in speeding up the mess…
Information technologies and systems that fail to support the needs of their users are a li-
ability to any organisation. The same is true of systems that are functionally adequate but
are not matched by a workforce that has the skills to exploit them or the information they
produce.
As ICT represents a significant percentage of an organisation’s total expenditures, it is le-
gitimate to assess the contribution that ICT makes to business results. The results of this as-
sessment can then be used as an input to strategic decisions on ICT should be managed in
future.
Several approaches are presented, from simple and quick reviews to various levels of audit.
The chapter also refers to other, more sophisticated tools such as the Balanced Scorecard
that take a wider view of the role of ICT in the work of an organisation.
Why good diagnostics make a difference
In less than 60 years, ICT has become ubiquitous. This does not mean
that we are able to take full advantage of what the technologies allow:
wide ranging access to information, the ability to combine and process
data and information and the creation ofnew knowledge out of this pro-
cessing.
ICT requires significant budgets and human resources. Depending on
what an organisation does, these are in the range from around 3% to 10%
of total expenditures. Such amounts are too high to hide as overheads and
also too high to accept without question as “the cost of doing business”.
How should one determine if ICT is an organisation’s strength or a liabil-

ity and take corrective actions to gain more value out of current and fu-
ture investments?
Relying on “gut feeling” and intuition is a good start – after all if ICT is
a major strength or a serious liability, this will not be a secret to people
inside (or outside) the organisation. Beyond this, there are many useful
diagnostic tools. These are the equivalent of a person having regular med-
ical checkups to identify potential health problems before these manifest
themselves.
The question of “how well are we doing with ICT” should not be asked of
ICT people as their perspective will be focused on technology and pos-
sibly a desire to acquire more resources. It may also be unduly optimis-
tic.
A full diagnostic involves four links in a chain. The first link has to do
with the choices to be made of products and vendors. This is a very tech-
nical activity which is the responsibility of the Chief Information offi-
cer.
Typical poor choices are unsuitable products, technical architectures that
become quickly obsolete or selecting vendor that risk going out of busi-
ness.
The second link represents all the computer systems that have been
bought and developed to meet the requirements of an organisation, the
data, databases and other sources of information (for example workflow
and document management systems), Intranets, line of business systems,
administrative applications, etc.
See Chapter 14
The acronym used in ICT since its early days is GIGO – Garbage In, Gar-
bage Out: he best computer systems will not be of much use if the data
they process is of poor quality (inaccurate, outdated, incomplete). Con-
versely, in the Information Age, having quality data but no systems to
analyse it for patterns, discoveries and other non-evident features, is a
handicap.
The third link is about how well technologies and systems are delivered
to the people who use them, i.e. the quality of delivery processes, the
skills and experience of the technical personnel involved in these tasks
and the skills of database administrators and others who manage data
and information. When the quality of service delivery is not good enough,
dissatisfaction and frustration grow quickly among those condemned to
use these systems and facilities.
The final link addresses the skills and experience of the people who use
these tools, data and information sources.
The weakest link in this chain will determine whether investments in ICT
are worthwhile or a waste of money. Identifying and strengthening this
weakest link is one of the many challenges facing executives. Strength-
ening just one link may not be enough and diagnostics of how well ICT
is performing should be conducted on a regular basis.
Answering the six key questions
Seeking answers to the first six questions in the introduction is a good a

place to start. These answers should be supported by evidence and met-
rics, not just opinions. As the book explores other aspects of ICT, there
will be more questions (and answers to them – there are no definitive an-
swers that fit all situations).
Question 1: What is the track record of ICT in the organisation?
This deceptively simple question covers several aspects of “track re-
cord”:
• The direct contribution that the ICT function brings to business pro-
cesses and business results;
Chapters 8 and 9
• The ability to deliver ICT projects that are (reasonably) within the
original specifications, budgets and timescales;
• The ability to deliver ICT services (computer room operations, net-
working, information security, user support, disaster recovery and
other to an appropriate level of quality;
• The relationships between the ICT function with executives, staff and
vendors, particularly in terms of credibility and trust;
• The ICT skills of staff and management to exploit information sys-
tems, data, documents and other related facilities;
It is to be expected that executives confronted with a a poor ICT track re-
cord would have either taken action or are looking for the best way to deal
with this. Those who recognise this problem and do nothing about it are
likely to discover that this poor track record will not improve by itself and
could get steadily worse.
Question 2: What are the efficiency and effectiveness of the organisa-
tion’s ICT?
Efficiency is all about doing “ICT things” the right way – making best use
of resources, removing systematic problems and working to achieve sim-
plicity to displace complexity, the enemy of manageability.
An ICT function that is not efficient incurs expenditures greater than
necessary and at the same time is not able to deliver the required level of
service quality or to complete projects on time and within budget.
Effectiveness is doing the right things
(better still, doing the right things the
right way). An effective ICT adds value
by enabling innovation, automation,
knowledge work and by making the
best possible use of data and informa-
tion assets in support of the organisa-
tion’s business strategy and objectives.
An ICT function that is not effective
cannot make a contribution to an or-
ganisation’s work and may even be an
obstacle to its development.
Question 3: Where does the money
spent on ICT go?
One way of finding an answer to this question is to look at the budget lines
of the ICT function. This will provide answers but these may not partic-
ularly illuminating – so much spent on salaries, so much on purchases,
so much on third party contracts, and so on.
While this information may give indicators about the cost of the infra-
structure, the productivity of the ICT function, the cost-effectiveness of
the technologies, the competitiveness of charges for services from exter-
nal suppliers, etc., the executive will remain in the dark as to whether this
money is spent to support business objectives.
A different approach assigns the cost of individual components to what
computer systems and networks are used for, and the four categories of
“value creation”, “ongoing support”, “administration” and “security” are
just examples of how this approach works. Value creation is the category
most strongly linked to effectiveness and therefore the one with the high-
est impact and strategic importance.
Many support tasks are critical to the smooth operation of an organisa-
tion, ranging from effective websites, electronic mail and those functions
that are closely linked to business activities such as accounts receiv-
able).
At the other extreme, basic administration (accounts, procurement, hu-
man resources) are activities that must be carried out but which add lim-
ited business value and as such, present an opportunity for seeking cost
reductions.
Information security is an corporate function growning in importance
as a result of living and working in a networked world: cybercrime and
other forms of cyber-attack have become a fact of life.
Many cost accounting systems are not structured to provide financial
data in this format and some organisations actually know how much they
spend on ICT but not exactly how these expenditures map against these
or comparable categories. Whether or not this is a problem for an execu-
tive depends on an organisation’s governance culture.
Question 4: What is the value assigned to information, knowledge work
and ICT?
Financial and management accounting always include tangible assets
such as computing equipment and other infrastructure items. From time
Chapter 11
to time, some forms of intellectual property, such as trademarks, are also

counted as assets. In mergers and acquisitions it is usual to place a value
on information assets such as client databases and custom software. This
valuation is conducted on the basis of goodwill and mutual agreement.
The rest of an organisation’s information and data does not appear ex-
plicitly in the accounts because there are no standards for assigning val-
ue to such information. This is probably because accounting standards
evolved considerably before information and data could be regarded as
organisational assets.
This creates other executive headaches: the cost of ICT is significant and
measurable (with some difficulty), while the value of information and
of “intangible” benefits cannot be easily measured as they are intangi-
ble and speculative.
This should not preclude finding an answer to this question as executive
and managerial decisions require good information. If the ICT systems
in place provide such information, then they are indispensible and valu-
able. When they do not, the organisation may face a real problem.
Knowledge organisations are those where a substantial percentage of the
workforce searches for, analyses and makes extensive use of information.
ICT plays a critical role in enabling this work.
There are also organisations where most of the workforce does not han-
dle information as the main task of their duties. Nevertheless, ICT is im-
portant when used, for example, in the automation of industrial process-
es (from electricity generation to the robotic assembly of motorcars and
everything else).
The intellectual property that describes these processes, and of the soft-
ware used to computerise them is almost certain to be of high value. This
is confirmed by the level of industrial espionage seeking intellectual prop-
erty, a major concern and a criminal offence.
Question 5: What are the legacies and constraints on ICT in our environ-
ment?
ICT has been around for long enough to go through several cycles of tech-
nologies many of which have since disappeared. The major push to com-
puterise accounting and payroll systems goes back to the 1960s and real-
Chapter 5
Chapter 6
time tracking systems to the 1970s. Data networks linking geographical-

ly dispersed organisations also have long histories.
Until the emergence of the Internet and Open Source software (based on
public domain standards), computer systems and network used proprie-
tary designs and therefore, computer systems and software based on, say,
IBM™ products were incompatible with those from Digital™, both of them
incompatible with those from Unisys™ or any other company and so on.
This is one of the aspects of technical legacies – migrating from one tech-
nical architecture to a different one. This is expensive, complex and tech-
nically risky, as many organisations discovered when preparing to deal
with the Year 2000 problem and/or when they were encouraged by ven-
dors to believe that new architectures would give them great new bene-
fits such as user-friendliness and flexibility (true) and dramatic cost sav-
ings (not always true).
Converting data to move it from one technical architecture to another is
another legacy problem. This is a headache because “old” data is not al-
ways complete and correct and needs to be cleansed for such a move. This
presents an opportunity for unethical players to corrupt data with intent
to defraud or sabotage an organisation.
Other legacies exist in the technical skills of an organisation – program-
mers with long years of experience in COBOL or another programming
language, will face problems in migrating to a significantly different lan-
guage (such as C++ or Visual Basic) or to environments such as SAP™ or
Peoplesoft™. Retraining may not be enough if the legacy staff is unwill-
ing or unable to undergo this conversion.
Constraints represent a different class of issues and limit an organisation’s
ability to invest and/or implement change. Such constraints may in-
volve:
• organisational politics and attitudes to change;
• the willingness to take substantial risks in ICT projects;
• the cooperation of employees to acquire new skills, change the way
that work is performed
and all the side effects that these factors imply. Downsizing and outsourc-
ing are instances that bring constraints and other tensions to the fore-
ground.
Chapter 12
Lack of a good understanding of these legacies and constraints may cre-

ate unrealistic expectations about what can be achieved through technol-
ogy and lead to failed initiatives.
Question 6: Do we have a well articulated vision of how we should exploit
ICT?
This is not a trick question. It is tempting to believe that the status quo is
fine and the legacies and constraints explored in Question 5 would not
allow this status quo to change anyway.
In the changing world of the Information Age this may be a dangerous
assumption: an organisation in a networked society must work with
stakeholders (clients, regulators, suppliers and competitors in the com-
mercial sector and donors, governments, non-governmental organisa-
tions and others in the not-for-profit sector) who have quite different ex-
pectations and motivations.
A typical toolkit for executives
The above questions may tempt the reader to call for a consultant to find
the answers. This may not be in the executive’s best interest as consul-
tants come and go, leaving behind them a report which may or may not
be read in detail and for which they assume no liability. An audit may be
a better option.
In addition to audits (discussed below) there are other tools that could be
used internally requiring different degrees of effort. A companion vol-
ume to this book, the Toolkit for Executives contains a collection of such
tools as well as checklists and lists of proven practices. A few of the tools
are presented here.:
Tool 1: Audits for ICT effectiveness and efficiency metrics
Tool 2: Strengths, Weaknesses, Opportunities and Threats (SWOT) anal-
ysis
Tool 3: How agile is your ICT organisation?
Tool 4: Organisational information intelligence
Tool 5: Organisational metabolic rate
Tool 6: The balanced scorecard for ICT

Here are some brief descriptions of what these tools do.
Tool N° 1: Audits and other tools for ICT effectiveness and efficiency met-
rics
The various components of this tool need to
be invoked by an executive. These are of var-
ious degrees of complexity, and fall in three
categories: Surveys, Audits and Bench-
marks.
1.1. Surveys are used to discover what people in the organisation feel about
ICT – for example user satisfaction surveys and client or stakeholder sat-
isfaction surveys.
This can be simple questionnaires or forms placed online on an Intranet
or website or also interviews with a statistically meaningful sample. Such
surveys provide feedback on the efficiency and effectiveness of ICT as
perceived by the people for whom ICT services and facilities are intend-
ed.
The grading that can be obtained from such surveys is fairly coarse, usu-
ally five levels between “Highly satisfied” and “Highly dissatisfied” and
most people, unless assured anonymity, will be cautions rather than can-
did.
The statistics produced by the Help Desk (when they do) can also be good
indicators. These would include: average number of calls to the help desk
per day, most frequent problems, most frequent callers).
1.2 Audits (internal and external).

I.T. audits are the means through which executives can strengthen the
governance of how technology is deployed in an organization. These au-
dits provide facts-based, independent and unbiased views on what is re-
ally going on in activities such as Information quality, Risk management,
Information (in)security, Maturity of I.T. processes, Alignment and val-
ue added, Regulatory compliance and Compliance with enterprise poli-
cies.
Audits can also identify weak controls that can be abused with criminal
or malicious intent as is the case of fraud perpetrated through the use of
computer systems.
When should an organization conduct an I.T. audit that is not imposed by

external requirements or in the absence of an audit strategy? I.T. audits
should be considered when executives cannot give informed answers to the
few questions below as this suggests that I.T. governance is weak. No disre-
spect to CIOs, but they should not be the person to give the answers.
Managing expenditures and value

How trustworthy is the information created by our systems?
How good has the return on I.T. investment been over the years?
How well aligned are our expenditures on I.T. with our business priori-
ties?
Risk management
Are we complying with legislation and regulations with I.T. implica-
tions?
How much risk of data disasters or fraud do we face?
Could our organization survive an I.T. disaster and recover from it?
I.T. performance (outsourced or not)

What I.T. assets do we have and how well are they used?
Does the I.T. function deliver as promised?
What are the track records of the I.T. function and of I.T. projects?
Are we good enough at managing changes in I.T. projects and activities?
Are there weaknesses in our I.T. that we should know about?
Whether the corporate risk associated with not having good answers to
these questions is acceptable, must be determined by each organization.
Value delivered by I.T. audits

“Value” is a difficult word because it means different things to different
people. For an operations manager it could mean reducing costs while for
a shareholder it would mean an increase in the price of a company’s stock.
For this article, value to an executive means avoiding surprises. Such sur-
prises could include computer disasters that paralize the organization or
that major investments in I.T. end up not adding real business value.
A professional independent audit will deliver value in the form of an exit
meeting where the findings, observations and recommendations can be
presented and discussed, followed a few days later by a report based on
evidence (records, statements of fact and other information that can be
verified) and includes management’s response to the recommendations

made. Such reports will be effective if they recognise that:
• the target readers are busy, don’t like bad news and prefer solutions
to problems;
• its recommendations are prioritized, relevant and worthwhile;
• no action will be taken unless the reader is totally persuaded of the
need;
• nobody will remember what was in the previous audit report (which
may be so carefully filed that it cannot be found)
Audit reports can (see “Choosing the right type of audit” below) cover
risks such as weak controls, poor practices, specific areas of risk, non-
compliance issues, missing and incomplete policies and missing or in-
complete activities or focus on benefits such as demonstrating alignment,
effective procurement of I.T., benefits delivered and ROI.
These reports will provide executives with information they did not have
before and focus on big-impact items and propose realistic actions to ad-
dress them. The findings should go beyond stating what is wrong and in-
clude a discussion of why.
The audit should also give the organization pointers to good practices and
methods for self-evaluation.
In our less-than-ideal world, the following detract value from an I.T. au-
dit and should be addressed in the definition of the audit scope of the au-
dit and when selecting the auditors:
• A report that takes so long to produce that time would have been
wasted in dealing with findings of substance;
• A report that essentially contains information that was already
known prior to the audit (sometimes this is useful if it confirms that
some concerns were justified);
• Long lists of nit-picking issues and (too many) recommendations that
would not result in significant improvements;
• Using the audit as an excuse to take actions already decided such as
a decision to outsource or to replace the CIO.
Critical Success Factors (CSFs) for I.T. audits

This article focuses on four CSFs needed for a high value audit outcome
These are:
Choosing the right type of audit
Choosing the right auditors

Deciding who gets the audit report
The attitude of the CIO to I.T. audits
Choosing the “right” type of audit

Just as there are many types of medical examination, audits (internal or
external) come in several flavors, as shown in the picture. Each one will
have its specific benefits as well as associated costs and duration.
Each intersection in the figure defines a possible audit framework. The clos-
er you are to the point of origin of these lines, the less confidence you should
have on your I.T., even if you did not have any major problem so far.
The factors that influence the decision of which audit is “right” in any
given situation are:
Type
I.T. audits can be grouped into six main categories. Experienced auditors
often add one more, informal, category: the “the smell test”: there are I.T.
organizations run in a way that an experienced auditor will quickly de-
termine that they “stink”.
Common indicators include: dirty and untidy computer rooms, spaghet-
ti cabling, incomplete or no documentation, unsupported (and even un-
licensed) software, easy access to facilities and/or no fire extinguishers,
the lack of a standby generator and more of the kind.
General Controls Reviews (GCR)

These audits are the most common and provide insights on how I.T. ar-
rangements affect the applications used by an organization. Typical GCRs
use questionnaires or checklists to examine topics such as physical securi-
ty, access controls, systems development methodology, contingency plan-
ning, data integrity and authorization and authentication technologies.
GCRs are usually conducted by auditors that have a general (not special-
ized) knowledge of information technology and also by external auditors
as part of their statutory audit work: to express an opinion as to whether
the financial statements of an organization show a true and fair view of
the situation and comply with relevant legislation.
Such audits, particularly those focusing on financial systems that contain
numerous programmed procedures will also examine controls over sys-
tems implementation and maintenance, systems software, computer op-
erations, program and data file security. The “smell test” is particularly
useful when dealing with a large and complex I.T. environment that is
poorly documented and has not been recently audited.
Compliance audits
These are conducted to certify that an organization’s I.T. infrastructure, ap-
plications and controls meet the requirements of a) the law, b) relevant reg-
ulations or c) the policies and standards the organization has adopted.
Examples include: The Sarbanes-Oxley Act (USA), the Data Protection
Directive (EU), the Health and Safety Act (UK) and ISO 17799 (informa-
tion security). Compliance audits may be mandatory.
COBIT based audits
The Control Objectives for Information Technology (COBIT) of the Infor-
mation Technology Governance Institute have been widely adopted. CO-
BIT is structured in four sections: Plan and Organize (mainly concerned
with the governance of I.T.), Acquire and Implement, Deliver and Sup-
port, Monitor and evaluate.
Each of the 34 controls in COBIT has guidelines for defining sets of Key
Goal Indicators and Key Performance Indicators. COBIT also includes
the concept of maturity levels against which to examine each control.
The six levels of maturity are: 0: non-existent, 1: initial or ad-hoc, 2: re-
peatable and intuitive, 3: defined process, 4: managed and measurable,
5: optimized.
COBIT does not specify what the appropriate level of maturity for an or-
ganization should be although levels 0 and 1 are unlikely to be of much
help to anyone.
Data analysis audits
These audits are found in the grey area between audits and investiga-
tions. Audits that require auditee data to be extracted and analysed
(frequently when fraud is suspected) is supported by Computer As-
sisted Audit Techniques (CAATs) and data mining software that can
be used on huge databases to narrow down and be able to focus on
specific issues.
Technical reviews
These consist of in-depth analyses of a computing environment and in-
cludes operating systems, application systems, networks, connectivity,
internet and intranets, disaster recovery and business continuity plans,
vulnerability review, business applications, change management, IT
strategic planning, and any other I.T. issues relevant at the time of the
audit.
These reviews, carried out by specialist auditors, should provide author-
itative and objective opinions on the extent to which an organization can
rely on systems and technologies. Their detailed nature also implies that
these audits require considerable time to complete.
Implementation and post-implementation benefits audits
Pre-implementation reviews and audit participation in the development
of a computer system project are the cheapest and most effective way to
provide for systems auditability and adequacy of controls. Finding that
these are insufficient at the stage of rolling a system out or once it is up
and running implies additional programming, change controls, testing
and disruption to end users.
Post-implementation benefits audits are the least frequently performed.
Their purpose is to validate that the future benefits used to justify an I.T.
project have been achieved. These audits are an opportunity to strength-
en the evaluation of business cases for I.T. investments, for which there
is a tendency to claim that benefits are “intangible” or otherwise difficult
to quantify even though such investments can reach tens to hundreds of
millions of dollars.
While the case of post-implementation benefits audits appears strong,
these are difficult, time consuming and, by implication, costly. They are
definitely worth doing to reach better decisions in future if past imple-

mentations failed to deliver the benefits expected of them.
Frequency
“Rarely” – including “never before” and “not for a long long time” are
common situations outside the financial services industry and particu-
larly noticeable in small organizations.
“After a crisis” is a common reason for calling the auditors. A crisis can
be anything from discovering, for example, after a power cut that the
computer room has no standby power supply, that data has been lost or
disclosed, fraud, a logical bomb followed by extortion and other unpleas-
ant surprises.
“For every major project”, where “major” should be taken as a something
that has high visibility in the organization’s budget and/or is critical to
its future activities.
Depth
Audits disrupt the day-to-day activities of an I.T. organization as the CIO
and many of the staff need to meet with the auditors, provide documents,
discuss preliminary findings. It is therefore good practice to agree on the
scope of audit to be just “good enough” to meet requirements.
Besides Internal Audit units are often unable to resource extensive I.T.
audits. Contracting this work out is an additional expense and there is
merit in scoping the audit to be also quick (= less expensive).
A detailed review of controls in a major and complex application such as
a customized ERP, or for the configuration and controls of operating sys-
tems (e.g. IBM’s family of TPF, z/OS, and Linux in one data centre) re-
quires considerable expertise and time to be conducted at a depth that
produces dependable results.
Organizations for which certification is important, for example to ISO
27000 “Information security management system requirements stan-
dard”, must accept that such audits are mandated by certifying organi-
zations and that they need to be conducted at prescribed time intervals.
Financial benchmarks
These are harder to establish and, from a corporate perspective, prob-
ably the most useful. They relate to how much is spent on ICT and how
effectively. Typical benchmarks would include the Total Cost of Owner-

ship for a networked personal computer – a figure that will vary ac-
cording to the model adopted, but which in 2004, several independent
sources put at around 10,000 US dollars per year.
The book “The Squandered Computer”, remains among the best sellers
on this subject.
Other tools
A companion publication, “The executive toolkit”, contains many other
tools and provides guidelines on their use. Five of them are briefly dis-
cussed here:
Tool N° 2: Strengths, Weaknesses, Opportunities and Threats (SWOT)
analysis
Organisations are com-
plex systems that serve
no purpose working in
isolation. As complex
systems they are not
perfect and each organ-
isation, regardless of
what they do and where
they are will have
strengths and weak-
nesses.
Most organisations are
willing to recognise and
make explicit their own
strengths (sometimes
overstating them). They may be less willing to admit to their weakness-
es, legacies and constraints, and even less willing to take action to deal
with them. These are often rationalised and accepted as things that are
“too difficult” or that cannot be changed (a myth invented by people who
have an interest in maintaining the status quo).
External factors can be described as either opportunities and threats.
Chapter 5
The squandered computer, by Paul Strassman, Information Economics Press, 1998
Combining these four, Strengths, Weaknesses, Opportunities and Threats

in a single reality check, is called a SWOT analysis. This has the merit of
being quick and simple to conduct as it requires filling a simple table.
This process can be particularly useful when conducted independently
by several people, internal and external, representing different perspec-
tives or roles with regards to an organisation and consolidating the re-
sults into a final table.
Differences emerging from this consolidation merit individual discus-
sion as they will identify how a situation is perceived by various parts of
an organisation. Clarifying these differences will be a major benefit in it-
self.
Tool N° 3: How agile is your ICT organisation?
ICT organisations have their own culture and
dynamics. They range from the highly dynam-
ic, innovative and responsive to the ever chang-
ing needs of an organisation, to the lethargic
and uncaring.
The areas covered by a typical agility checklist
are:
• Relevance of agility to the organisation;
• ICT governance;
• ICT personnel and the ICT organisation;
• Technology;
• Cost structures;
• Focus.
A “perfect” ICT organisation would score the equivalent to an olympic
gold medal. A low score points to a lethargic organisation unable to meet
its stakeholders expectations.
Tool N° 4: Organisational information intelligence
This tool is used to identify the role of knowledge work in an organisa-
tion. Knowledge work includes analysis, diagnostics, evaluations, re-
search, software development, statistics and similar activities. The deter-
mination of organisational information intelligence uses two simple anal-
yses:
An assessment of the percentage of people engaged in knowledge work.
A high percentage (more than 70%) describes an organisation where
workers have considerable independence and individuality and are there-

fore not easily interchanged or replaced.
Organisations where this percentage is low, typical of those engaged in
structured and repeatable processes have substantially different ICT
needs.
The second analysis permits an assessment of the degree to which knowl-
edge workers are able to exploit the organisation’s information assets.
In their article Managing by Wire Haeckel and Nolan introduce the con-
cept of an Information Intelligence Quotient (IIQ) describing the impor-
tance of three activities in the effective use of information:
• The ability to define information needs, find this information from
internal or external sources and access the information if such access
is not restricted. This involves more than using Google as the knowl-
edge worker must validate this information prior to its intended
use.
• The ability to integrate the infor-
mation found with other sources
to create a new information prod-
uct (report, analysis, etc). When
this work is done by a team or in-
volves collaboration with other
knowledge workers, the ability to
share information, in cultural,
physical and electronic terms de-
termines the outcome of such ac-
tivities. If there is a culture of “in-
formation itself is power”, shar-
ing will be limited.
• The ability to extract meaning from data. This is vital in knowledge
work and requires a detailed understanding of the way in which data
has been defined, captured and processed. For example, distance
could be measured in miles or kilometers and errors in the interpre-
tation of such data could result in meaningless results.
Harvard Business Review, Managing by Wire, Sep-Oct 1993) Stephan Haeckel and
Richard Nolan
Tool N° 5: Organisational metabolic rate

Every organisation has its
own way of doing things, de-
fined by its history, culture,
management style and oper-
ating environment. The met-
abolic rate defines how quick-
ly it can move to accomplish
specific objectives such as
procurement and recruit-
ment.
Other of metabolic rate indicators relate to flexibility in the application
of rules and regulations and how budgets are managed.
This metabolic rate is deeply ingrained in culture and behaviour. A slow
metabolic rate will work against things that are urgent and important,
even if the end result is “saving money regardless of cost” and firefight-
ing while waiting for things to happen. At the other extreme, the expec-
tations of organisations with a very fast metabolic rate drive the pace of
work and there is a risk of burnout for those who cannot sustain the pace.
Burnout results in waste and bad decisions.
Organisational metabolism defines the practicality of plans for change
and for major projects – ambitious plans are incompatible with low met-
abolic rates and an inability to mobilise resources quickly in the ICT func-
tion is incompatible with the expectations of a fast moving organisa-
tion.
Tool N° 6: The balanced scorecard for ICT
The balanced scorecard (BSC) introduced in 1992, provides a different
perspective from traditional management reporting based on lagging in-
dicators and assumes that information about how an organisation per-
formed in the past supports a limited ability to project how it will per-
form in the future.
Besides, the authors argue, pure financial indicators used in traditional
reporting are not sufficient to understand the value of intangible assets
such as data, information, customer goodwill and others.
The Balanced Scorecard: translating strategy into action, by Robert S. Kaplan and
David P. Norton. Harvard Business Review.
Supporters of the BSC claim that it enables more rational decisions to be

taken by having a better understanding of their future impact.
The basic BSC proposes four linked perspectives, including the tradition-
al financial one and is used to examine the interactions between these
perspectives. The BSC can be made to fit circumstances where a smaller
or greater number of perspectives is required.
In addition to its role as a management tool, the BSC is also seen as a valu-
able mechanism to gain clarity regarding strategy and as a communica-
tions tool.
Executive dilemma: The auditors’ report on ICT
This, and other executive dilemmas in this book, has multiple possible
answers and no single right answer that would apply in all circumstanc-
es.
The Internal Auditors of a large multinational delivered a confidential
and sensitive report to the Chief Executive: the ICT function, which had
not been the subject of a technical audit for several years, is responsible
for several exposures for the company. The summary findings of the re-
port indicate that:
• The Chief Information Officer was unable to work effectively with
Business Units to deploy standards for technology and computer ap-
plications across the company – many Business Units had become
autonomous in ICT and were working without due regard to best
practices ignoring corporate needs for the integration of data. How-

ever, because things work quite well, both the CIO and the Business
Unit managers are comfortable with the situation.
• There is weak compliance with corporate policies concerning the use,
misuse and abuse of ICT, and these policies need updating. In addi-
tion, the company does not fully comply with some areas of recent
legislation, notably on the accuracy of financial reporting and on the
prevention of fraud and other criminal activities.
• The cost of service provision in ICT was assessed as being clearly
higher than necessary due the weakness of corporate controls on ICT
expenditures.
• The ICT function is large – 850 people distributed among several lo-
cations in different countries and is responsible for a substantial
portfolio of critical applications. However, it is not fully aware of the
ICT activities at the business units and there is no longer a compre-
hensive view of ICT across the company.
Where would you start to unravel this situation and how would you go
about it?
While now there is little point in assigning blame, what do you think
caused such a situation to develop and was there something executives
could have done to prevent it from escalating to such a level?
Action points
If your organisation’s ICT performance, business impact and value for

money seem fine: Congratulations! You are among the Winners of the
ICT Board game (not a crowded place). The challenge now is to remain at
this level.
If there appear to be doubts, concerns or problems about performance,
costs or in difficulties in assessing the value added by ICT: Things will
not get better by themselves – the reverse is more likely. In these circum-
stances, executive action is necessary to diagnose the true nature and ex-
tent of the problems in order to take appropriate corrective action.
When a SWOT analysis is insufficient and the financial data on costs and
benefits is inconclusive, incomplete or incomprehensible, it is recom-
mended to carry out a series of audits of the ICT function, specifically:
• A technical audit if there are performance problems and/or

• A financial audit if the true costs of ICT are unclear and/or
• A board level review of the benefits delivered by ICT in the last few
years, and, if these are unclear or undefined, the development of a
new strategy to change the situation.
and, in parallel, conduct an assessment of skill gaps for the people who
use the computer systems and ICT facilities of the organisation – part of
the problem could be their inability to exploit the tools put at their dis-
posal due to lack of training or other essential ICT skills.
Other audits that may prove necessary if the outcome of the previous au-
dits gives cause for concern may include:
• Compliance with national legislation relating to ICT (data protection,
privacy, cybercrime, health and safety at work, etc)
• Compliance with policies relating to the use, misuse and abuse of
ICT
• Information security audit
Supplement: The 34 areas of control of COBIT V.4 of 2005
PO Planning and Organisation

1 PO 1 Define a Strategic IT plan
2 PO 2 Define the information architecture
3 PO 3 Determine technological direction
4 PO 4 Define the IT processes, organisation and relationships
5 PO 5 Manage the IT investment
6 PO 6 Communicate management aims and direction
7 PO 7 Manage the IT Human Resources
8 PO 8 Manage Quality
9 PO 9 Assess and manage IT risks
10 PO 10 Manage projects
AI Acquisition and implementation

11 AI 1 Identify automated solutions
12 AI 2 Acquire and maintain applications software
13 AI 3 Acquire and maintain technology infrastructure
14 AI 4 Enable operation and use
15 AI 5 Procure IT resources
16 AI 6 Manage changes
17 AI 7 Install and accredit solutions and changes
DS Delivery and support

18 DS 1 Define and manage service levels
19 DS 2 Manage third party services
20 DS 3 Manage performance and capacity
21 DS 4 Ensure continuous service
22 DS 5 Ensure systems security
23 DS 6 Identify and allocate costs
24 DS 7 Educate and train users
25 DS 8 Manage service desk and incidents
26 DS 9 Manage the configuration
27 DS 10 Manage problems
28 DS 11 Manage data
29 DS 12 Manage the physical environment
30 DS 13 Manage operations
M Monitoring
31 M1 Monitor and evaluate IT performance
32 M2 Monitor and evaluate internal control
33 M3 Ensure regulatory compliance
34 M4 Provide IT governance
The full material of COBIT (CDROM, books and other material) can be obtained from
the Information Systems Audit and Control Association (http://www.isaca.org)
C h a p t e r
3
Information assets
and technology
It is not what technology can do that matters.

What counts is what you can do with it
• What are the differences between data, information and knowledge?

• Transaction and knowledge workers: what exactly do they do and why
does it matter?
• How do businesses and organisations use information and knowl-
edge?
• Why is information quality important and what determines quality?
• What is the appropriate role for technology in “Information Technolo-
gy” and what does it take to be able to exploit it?
• Asset management for information systems and technology: does it
make sense?
Organisations invest in information and communications technologies because they have a

need to process, store and disseminate information in a combination of many possible
ways.
Technology is neutral: it can be used to advantage and it can also be misused and abused.
Beyond this, when the skills needed to use of information as a resource are weak or absent,
technologies become an unproductive or wasted asset.
Making the best out of ICT that data and information be treated as assets and that the
people who use these technologies have an adequate knowledge of how the tools should
be used and the skills to assess the quality of data and information. One of the earliest say-
ings in the ICT industry was GIGO: garbage in, garbage out. This continues to be true
Data, information and knowledge
Data is no more and no less than symbols about the property of some-
thing. Data can be observed, measured and collected and then used for
reasoning or calculation. An example of data would be the number that
appears in a house’s electricity meter.
Information is obtained when data from one
A major challenge to the exploita-
or more sources is summarised and organ- tion of data is the often weak un-
ised for a purpose and in a given context. In- derstanding of the semantic
formation can be presented in multiple for- meaning of data. The Mars Cli-
matic orbiters that crashed in No-
mats (text, images, video). The invoice from vember 1999 did so because dis-
the electricity distribution company that ar- tance data was processed in met-
rives after the meter has been read, shows ric units by one system and impe-
rial units by another one.
the difference between two readings (data)
and applies a tariff to the quantity used (data) and becomes information
for the recipient. This information leads to an action, payment.
Knowledge is harder to define without getting into philosophical argu-
ments. A definition that works well is that “knowledge is the ability to
use information to do something with it”.
While information can be collected, distributed and shared, knowledge
is an individual’s attribute and, as such, hard to detach and transfer. In
most cases it is difficult to acquire.
The lowest level of knowledge is awareness: to know about something.
Visiting a website that discusses tropical birds or the origins of colour
television, will give the visitor information that can be absorbed and put
in context with what the person already had found out about a subject.
Knowing about something is not sufficient to learn how to do something.
Reading books about playing the piano will not make the reader a a pro-
ficient pianist. Knowing how to do something requires practice and a
transfer of advice and experience from somebody who already knows
how.
The highest level of knowledge is reached when a person understands why
something is the way it is – the level at which theoretical physicists, econ-
omists and other researchers operate, building frameworks and applying
analytical and systems thinking skills as well as creativity.
The pursuit of knowledge and the collection and sharing of information
have a prominent place in human history. The earliest technologies were
used some 30,000 years ago to leave paintings in caves detailing the en-
vironment of their inhabitants and these evolved some 5,000 years ago to
the point that gave us writing and devices that could store information
(clay tablets then).
• More information has been produced in the past 30 years than in the previous 5,000;
• A weekday edition of The New York Times contains more information than the average
person of the 16th century would encounter in a lifetime ;
• The amount of available information now doubles every five years.
Technology in various forms - newspapers, reports, TV, cellular phones,

websites, e-mail and more has enabled this proliferation. We are now
hooked on technology and in this overload scenario, we are all faced with
warehouses full of information that we have not yet learned how to ex-
ploit.
While organisations have a senior person with a title like Chief Informa-
tion Officer, much of their time is devoted to managing technology and
service delivery and not to managing the data and information that tech-
nologies process and store. Responsibility for data and information is
usually distributed among several functions or departments.
To complicate matters, authors, consultants and vendors talk about
knowledge management (KM). Solution sellers will say that KM will “en-
able workers to capture, manage and share information throughout their
organisations”. Consultant-speak turns this into “leveraging assets and
experiences” and other such words that fail to address the cultural bar-
riers to sharing information and the difficulties inherent in transferring
knowledge.
The cook, knowledge and experience
The fact that most accounting functions are done using computers is tak-
en for granted. In the light of recent financial misadventures, the idea of
“cooking the books” leads to the cook metaphor: the cook is an example
of how a knowledge worker operates. What does a good cook do?
1. Selects ingredients for their suitability and quality;
2. From training and experience, the cook knows how to prepare and
combine these ingredients for maximum effect – how to cut them, mix
them, how long to cook them for, what to add and in what quantities;
3. Arranges the cooked ingredients into a plate ready for serving at the
right time.
A good cook is also able to produce different dishes from essentially the
same ingredients.
A cook uses an array of
technology – knives,
blenders, whisks, pots,
pans, let alone refrigera-
tors, freezers, microwave
and conventioanl ovens.
As anyone who has tried
their hand at cooking
knows, the end result will
depend more on the ingre-
dients and preparation
than on the tools used to
prepare them.
Moving out of the kitchen into an office, (where nobody is cooking the
books!), a knowledge worker must find the right ingredients (data and in-
formation) to accomplish a given task and use experience and judgment
to combine them in the right way to create new information to meet a
particular requirement.
Does this information have value? Organisations think it does as oth-
erwise they would not employ people to work with information. Some
information has a clear commercial value, for example patents, propri-
etary processes, the ownership of a unique photograph, breaking news
and other privileged information. In many other cases, such value is
not evident. Trying to put a value on data and information is no differ-
ent from trying to measure pain because there are no common units of
measurement, and its definition involves many subjective and intangi-
ble elements.
This situation is not satisfactory from an executive’s perspective, as in-
vestments in ICT are significant and technology alone does not contrib-
ute to results – only the way technologies are used does. In a letter to the
MIT Technology Review (September 2004), Paul Strassmann writes that
… “IT is a catalyst of excellence but also an accelerator of incompe-
tence”.
How organisations use information
The different ways of working with ICT
ICT vendors have several things in common with drug dealers:

• They refer to their clients as “users”;
• Their products can become addictive (computer games, SMS on cell-
phones, etc.);
• Many products can be used without an instruction manual.
Access to ICT does not guarantee that it will be used to good effect –com-
puter games in the workplace are a good example of negative productiv-
ity. When computer games are not available, there are alternatives, such
as giving unlimited unmonitored access to the Internet to all computers
on a network.
The earliest applications of ICT in organisations (in the 1950s and 1960s)
were for the support of repeatable, structured and systematic activities
(processes) such as payroll and financial accounting.
Process support is close in concept to the use of machine tools in manufac-
turing – the machine (in this case the computer, software and other com-
ponents) does the work and the operator feeds the machine with raw ma-
terial (data). The worker does not need to have special skills or a deep un-
derstanding of what the machine does or how it does it: the systems are de-
signed to do the “thinking”, which is not really thinking but the systemat-
ic application of the steps and business rules built into the software.
Taking the examples of a supermarket cashier or an airline seat reserva-
tion, ICT is used for process support, and as each article processed or res-
ervation are individual transactions: the worker is a transaction worker.
Transaction workers are trained in the use of systems without much dif-
ficulty and are also interchangeable. Automation is used to deskill tasks,
and has social consequences – alienation and lack of mental stimula-
tion.
When process support is combined with publication – for example the
Frequently Asked Questions pages in an e-commerce website - this is
done to enable the client to operate on a self-service basis. In many cases
it takes a great deal of knowledge and skills to find a way to actually con-
tact a person at the online vendor’s organisation.
The left hand side of the chart deals with a different dimension. Here the
worker uses the machine in order to support her or his thinking and cre-
ative skills. In a book published in 1988 (In the Age of the Intelligent Ma-
chine), the author, Shoshana Zhuboff, introduced the concept of “infor-

mate” to denote the opposite of “automate”. Today, this is now referred to
as knowledge work.
Knowledge takes many forms, from statistical analysis (for example, what
is the average expenditure of a client in a supermarket) to complex oper-
ations on large amounts of data, such as data mining, pattern recognition
and discovery (for example, what is the busiest day/time for a supermar-
ket and what are the most popular items sold during that period).
Other types of knowledge work consists of remote diagnostics from com-
puter room hardware to telemedicine.
“End user computing” is another kind of knowledge work – this worker is
self-sufficient to do some computer programming and capable of creating
templates, macros, models and other programs for their personal use.
While useful End User Computing , if not well managed, can cause un-
desirable side effects – in a bad scenario information anarchy – by en-
abling inconsistent, incompatible and possibly doubtful quality applica-
tions all over the place. Another form of end user computing is the design
of web pages and departmental websites. This can also create informa-
tion anarchy.
Simulation, modeling and virtual realities are all knowledge work. Here
computer systems behave as “real” objects or processes to support re-
search, validate theories and
create environments which
do not exist in reality. The
digital imaging used in mov-
ies and other creative endeav-
ours is a related example of
the creative use of ICT.
Networking also enables on-
line collaboration, where
knowledge workers at differ-
ent locations, and possibly timezones, can work together on projects
ranging from report preparation to software development. An example
of this are projects where software development is shared in centres
across the world to give a 24 hours design capability (for example USA,
Europe and India sharing the development of a project) and other com-
plex projects sometimes involving workers from different companies
working on a joint venture.
Similarly, groups of knowledge workers can use networking facilities and

tools to create communities of practice to discuss problems of common
interest, creative solutions to such problems and foster information ex-
changes.
Contrary to transaction workers, knowledge workers are not easily inter-
changeable. Companies and organisations that realise the importance of
knowledge work and their dependence on such workers, reward them ac-
cordingly - particularly in competitive environments.
Publication vs Personalisation
Publication is a well establsihed use of information.

A recent trend enabled by knowledge work is that of personalisation. This,
instead of providing a “one size fits all” collection of information, as tra-
ditional publication does, allows the dissemination of information to be
tailored for an individual.
One example of personalisation is subscribing to alerts services that send
an e-mail every time there is an item published or posted on a website
that meets an individual’s specified profile. Another example is where an
e-commerce supplier recommends items based on a person’s past queries
and purchases as well as on what other people with similar buying pat-
terns have also bought.
Different profiles of information use

There is no “standard” way of using ICT, even though many components
of ICT have become commodities. Using the framework presented earli-
er, this chart illus-
trates the different
emphasis that differ-
ent organisations place
on the use of ICT.
While every organisa-
tion will apply these
technologies differ-
ently, the basic rules of
what it takes to suc-
ceed in this are essen-
tially the same.
Information quality
Information science and information
management are much older than ICT. A man with one watch knows the
Many aspects of it are hundreds, if not time. A man with two watches is
never sure.
thousands, years old, going back to the
oldest libraries. Unattributed statement
Returning to the cook’s metaphor, the

science of information management is the equivalent of ensuring that the
ingredients are appropriate for what will be cooked.
Data administration is the function that looks after the definitions of all
important data in an organisation – not only semantic definitions “what
is an employee” but also how these are encoded and formatted in various
databases.
Weak data administration can lead to incompatibilities – where systems
are unable to exchange information or can only do so after some kind of
conversion with the risk of confusion if the semantic meaning of differ-
ent data definitions is inconsistent. A good example for the need for data
administration can be found in a computer system for human resources
management:
In theory, it is possible that a single computer system will handle all the
functions relating to an employee as shown in the diagram. It is more
likely that several of these functions are handled by separate computer
systems, possibly owned and managed by different departments - for ex-
ample membership of the pension plan, medical insurance with a third
party, cellphone charges, IT equipment and systems access, telephone di-

rectories, etc.
Unless all of these systems have consistent definitions of “employee”, con-
fusion is certain to occur. For example, should contractors engaged for a
long period of time be included in the telephone directory? – and what
about interns and trainees?. This begs the question whether an organisa-
tion actually has a single telephone directory – it is not uncommon for
large organisations to have several directories and for these not to be syn-
chronised.
Lack of care with regards to the completeness and accuracy of data, could
result in problems, including legal ones such as failing to comply with
Data Protection and Privacy legislation.
Database administration is a function performed for one or more related
databases. One of its objectives is defining who has the right to access
what data and ensuring that data is not modified by unauthorised indi-
viduals. This is critical to avoid breaches of confidentiality (what is the
boss’s salary?) or fraud (modifying one’s annual leave record or transfer-
ring funds to a personal account).
Given the growth of cyber-crime, sound mechanisms and controls must
be in place in all database administration functions where security and
confidentiality are important.
Access rights and policies extend beyond the database administration
function, as these cover access to networks, to the Internet and other
functions. These are the responsibility of system and network adminis-
trators. The fragmentation of these responsibilities require executives to
put in place governance and oversight mechanisms as self-defence mea-
sures.
Quality Assurance
Just because data or information has

been bought, printed or obtained
through a computer it does not mean
that it is necessarily suitable for a par-
ticular need. It may not even be correct.
A “quality” information resource is one
that meets the needs of its end-user.
The quality of an information resource is determined by factors grouped

in three categories: Content, time and format.
Content quality relies on the degree to which the information resource is
accurate (if a study of weather requires temperature information to an
accuracy of one tenth of a degree, anything that is accurate to one degree
will not do), the degree to which it is complete (if such temperatures are
only available for Europe and the study is global…) and its traceability,
does it come from an authoritative source and can it be substantiated or
validated with other sources?
Time is defined by currency and timeliness:
• To state that there are 750 million people that have access to the In-
ternet may be accurate but of little use unless this information states
the date on which this was established;
• A manager that needs a report on daily operating incidents needs
such a report at the end of each day (or early the following day) not
“mañana” - some undefined future time.
Format is important to make the information resource usable. It is de-
fined by presentation, style and media: having to find just one item of
information in a 200 page report written in bureaucratese or in a foreign
language implies that the report is not the most appropriate format, par-
ticularly if it is printed. Similarly, a report in electronic form but produced
using some exotic software that cannot be easily converted to a more
common format is equally problematic.
The role of technology
The range of computing and communications technologies keeps grow-

ing. The most common technologies are:
NB: COTS stands for Conventional Off The Shelf (software)
All of these technologies should be recognised as assets and be traced

through inventory numbers, contracts, licences and other documenta-
tion.
Critical points about technology:
# 1 Technology is no more than a tool. It can be used to advantage, mis-
used and abused. U.S. President J.F. Kennedy said in 1962, “space sci-
ence, like nuclear science and all technology, has no conscience of its
own. Whether it will become a force of good or evil depends on man”;
# 2 ICT has relatively short life cycles driven by innovation and marketing;
A personal computer is considered “old” after four years, the life of
notebook computers in a corporate environment is around three
years. Servers of all kinds (including mainframe technology) have a
service life of no more than five years. The longest-lasting ICT com-
ponents are cabling (ten years) and robotic tape management systems
for storage (ten years and more).
New versions of corporate software (Peoplesoft™, SAP™ or Oracle™ ap-
plications for example) are released at relatively short intervals of less
than 5 years, followed by the withdrawal of vendor support for older
versions after another year or two. This makes upgrades to new ver-
sions mandatory or cause clients to take the risk of working without
vendor support, something some organisations choose to do.
# 3 ICTs are marketed to a wide population – many ICT items found in

an office or corporate environment are also for sale in supermarkets
and many people have such technologies in their home. Like the fash-
ion industry, it thrives on obsolescence and on creating a “need” for
bigger, faster, feature-rich gadgets which translate into high expec-
tations in the workplace. Does a transaction worker really need a high
power computer with a super-fast video card, stereo speakers a DVD
player and more when it is possible to buy a basic computer for office
use for considerably less?
# 4 These factors combine to take a substantial percentage of an organ-
isation’s ICT budget just for operations, upgrades and maintenance
– typically 70 percent of the budget, leaving only 30 percent or so for
innovative development and new applications.
Exploiting data, information and technology
Even the best technologies cannot help those who are culturally reluctant
to use them (like the technophobic executive who never sent an e-mail
and has their incoming e-mail printed by their secretaries (they do exist)
or the person who has never bought anything online.
Most critical are those employees who lack the basic skills on how to use
these technologies the corporate equivalent of the person only able to put
a frozen meal in the microwave oven. Technology will not make them a
become a better cook.
The identification of skills gaps, briefings, training and due attention to
the need for such skills during recruitment are vital factors for an organ-
isation to be able to exploit their information assets.
Managing information assets as a portfolio
Data and information, ICT hardware, software, databases, licences and

contracts should be regarded as an organisation’s assets. The purpose of
portfolio management is to ensure that the organisation knows what it
information assets has and what it knows about them. This approach of-
fers important benefits.
A key benefit is the ability to strengthen the alignment of ICT investments
with business objectives and the governance of ICT in the organisation.
Other benefits are the enhanced visibility of the organisation’s informa-

tion assets and the possibility of consolidating systems, facilities and con-
tracts.
In addition, good asset management practices lead to reduced costs and
improved risk management, notably the risks of:
1. Multiple (and incompatible) implementations of systems to perform
basic business functions such as accounting, human resource man-
agement and payroll;
2. Inconsistent data definitions used in business units and departments
that make it difficult to aggregate and compare data across the or-
ganisation as a whole;
3. A lack of knowledge about systems which are underused or not used
at all;
4. Investments in systems that do not contribute business value.
5. Loss of data – including user identities and passwords and other po-
tentially critical data as a result of theft or careless disposals of old-
er equipment (data and software on hard disks);
6. Legal exposures as a result of disposals that do not meet environmen-
tal regulations, observance of the terms and conditions of software
licences, intellectual property infringements, etc;
7. Infringements of the terms of contract of software licences, leases
and outsourcing;
8. Failure to meet regulatory requirements such as those in Data Pro-
tection Directives, Financial Services Authorities, Health and Safety
at Work, etc.;
9. Loss of reputation as a result of being seen as having suffered any of
the above.
Implementing asset management for ICT

ICT Asset Management is the collection of processes that create and
maintain an inventory of the organisation’s knowledge of their informa-
tion systems, facilities and services, including all hardware, software, li-
cences, contracts including those for services.
This information is used for managing the financial aspects of the own-
ership of such assets, their total cost of ownership, depreciation, licens-
ing, maintenance, and insurance. More importantly, a well managed
portfolio of information assets can be used to support forward planning
and strategic management of ICT. A portfolio is expected to include four

major sections:
Each of these sections may be maintained by a different organisational

unit and these individual sections integrated by one person, perhaps the
Chief Information Officer (unless the role of this person is limited to in-
frastructure and basic ICT service provision) or a senior executive respon-
sible for planning and strategy.
Skills asset management

The return on investments made in ICT systems and facilities will only
be as good as the ability of their end users to exploit them. End users can
be grouped in three categories:
• External users such as e-commerce clients or partner organisations
in virtual supply chains or joint ventures. These are outside the con-
trol of an organisation and training cannot be provided to them.
However, an effective help desk and feedback from these end-users
can be used as indicators of where to make improvements to enable
them to make good use of such facilities;
• Internal users engaged in process support (transaction workers), per-
forming structured, largely repetitive tasks with a limited number of
systems. They can be naïve users, trainees or experts.
Training, good documentation, help desk facilities and performance
monitoring are essential components of skills asset management.
There is merit in recording the ICT skills of individuals, particular-
ly those of using non-COTS (conventional off the shelf) software in

their H.R. records and conducting training needs analysis to ensure
the maximum return on training investments.
• Internal knowledge workers performing analysis, simulations, busi-
ness intelligence, design, etc. These are value creators. Ensuring that
they have and maintain an appropriate level of skills in the use of ICT
is critical to the performance of their work.
Infrastructure Asset Management

Starting with a full inventory of hardware, operating system and other
utility software, networks, infrastructure asset management provides the
information needed to manage maintenance contracts, leasing contracts,
third party contracts for services or facilities (data links, telephone lines,
Internet access, etc).
Information derived from infrastructure asset management supports:
• plans for the renewal or replacement of equipment;
• compliance with the terms and conditions of COTS software licences;
• the financial assessment of the cost of ownership;
• the operations of a help desk (by identifying exactly the type of equip-
ment, software, their location and other essential information when
dealing with problems);
Such information should be maintained in a standard format at all the
locations where an organisation has a presence. Although more complex
to manage in a multi-site organisation than at a single location, it is an
important tool for managing the cost of ICT.
Information gathered through infrastructure asset management may
identify opportunities for the consolidation and rationalisation of data
centres, networks, help desks and other features to gain economies of
scale, reduce operating and disaster recovery costs and consolidate pro-
curement activities.
When the operation of the infrastructure and basic facilities, desktop
computing, etc are being or have been outsourced, the initial inventory
will be an important component of the Request for Proposals and for the
transfer of assets to the outsourcer. The subsequent management of these
assets becomes the responsibility of the outsourcing services provider.
Applications and Facilities Asset Management

A typical medium size organisation will have tens, if not hundreds of
computer systems (applications). Such systems usually have ancilliary fa-
cilities such as off-site secure data storage, which could be application
specific, and business continuity plans.
Applications are rarely just “off the shelf”, and are customised to some de-
gree to meet the specific requirements and working style of an organisation.
A large organisation may have hundreds to thousands of such systems.
These systems are frequently linked to exchange data and the inventory
of computer systems should include a systems architecture, perhaps a di-
agram, identifying the dependencies of systems on other systems.
Applications and facilities asset management is, by definition, the cen-
tralization of detailed information about applications with the purpose
of gaining an organisation-wide picture of the portfolio of current appli-
cations, a statement of their condition and the individual plans for the fu-
ture of these applications.
A statement of the condition of applications is important. Applications
may be in any of the following conditions:
• Quality software, fully documented to an acceptable quality stan-
dard;
• Quality software, partially documented – backlog of documentation
applies to recent bug fixes and enhancements;
• Adequate software, partly documented. This applies to old applica-
tions (“legacy systems”) where their support depends on a small
number of equally “legacy staff”;
• Fragile software, partly documented or largely undocumented – a
clear problem area.
The work conducted by organisations all over the world to prepare for the
Y2K problem saw a massive reduction of fragile and adequate but undoc-
umented software.
Individual plans for applications should also be documented in the asset
management process. Such plans could be one of the following:
Retire – Freeze – Maintain - Re-engineer - Replace

“Freeze” means that there will be no further enhancements to this appli-

cation. “Maintain” means that bugs and other problems will be fixed. Re-
engineer means that the system will perform comparable functions us-
ing a different technical platform.
This information is needed to support business decisions about proposed
ICT projects, reduce diversity, cut costs and maximise the productivity
and effectiveness of applications development and support activities.
A word of caution: implementing an asset management system where one
did not previously exist may not be welcome in distributed organisations:
this will be seen as an attempt to gain control of activities where autono-
my existed previously. This is a political problem.
While the views of information assets at the departmental and business
unit level are valuable in their own right, there is a major benefit to the
executive of the headquarters/ parent organisation whenit becomes pos-
sible to gain an organisation-wide view of how ICT is structured and the
identification of the opportunities this entails.
A special aspect of asset management deals with the retention periods for
documents and financial data which are in most cases defined by legal
requirements. This raises many questions in the e-world. Must electron-
ic mail messages be kept, and if so, for how long? Is it enough to keep “old
data” in tape cartridges?
In fact the answer to this last question is that it isn’t, as the software that
was used to create this data must also be kept as all the tape cartridges
contain is a sequence of 0s and 1s that makes no sense at all. The archi-
val policy must make provision for keeping a working copy of all the soft-
ware needed to read this data as well as its documentation.
ICT projects portfolio

This is a complete catalog of all current and proposed ICT projects indi-
cating their relationship to the current portfolio (for example if a pro-
posed project is to replace an existing system) and highlight how the new
project will interface with existing applications and facilities.
The purpose of a projects portfolio is to enable the executive to gain a
comprehensive view of the future evolution of ICT in the organisation,
identify potential conflicts, overlaps and duplications and, more impor-
tantly, to be in a position to decide on priorities for the allocation of re-
sources to such initiatives.
To be of value, each entry in a projects portfolio must demonstrate align-

ment with the organisation’s overall strategy and objectives as well as pro-
vide trustworthy indications of the costs, benefits and risks of each pro-
posal, the estimated duration of the proposed project.
Action points
Recognise that data, information and software defining your organisa-

tion’s business rules and processes are valuable assets.
Prevent your organisation from drifting into information anarchy by en-
suring all information assets have an identified custodian or “owner” and
that a minimum set of standards is implemented and adhered to.
Ensure that the organisation knows what it has and what it knows.
Ensure that the workforce has the necessary capacities and skills to ex-
ploit the information assets with which they work.
C h a p t e r
4
Impact of ICT on
organisations and on
people
There is nothing more difficult or more dangerous

than to try to change the order of things
Niccolo Machiavelli (The Prince, 1515)

• What have we learned about the impact of ICT in the “real world”?
• Should ICT investments make a difference, and if so, how much?
• How do organisations and people react when confronted with disrup-
tive change?
• What are the challenges facing the non-ICT executive?
The introduction of new technology in the workplace invariably brings change with it. The
amount of change that an organisation absorb depends on its culture and environment. As
the father of Total Quality Management, W. Edwards Deming once said, “it is not neces-
sary to change. Survival is not mandatory”.
Given that change is opposed to human nature’s need for stability, is likely that many
change initiatives will be resisted and that not all the members of the workforce can adjust
to such changes, particularly if they are disruptive rather than incremental.
The managerial challenges of leading change and ensuring the successful implementation
and adoption of ICT initiatives are discussed in the context of organisational culture and fo-
cus on the executive’s challenge – not the technologist’s which are of a totally different na-
ture and are discussed in subsequent chapters.
Observations
Investing on ICT does not have a predeter-

mined outcome: it may allow an organisa- Computerising ineffective processes
tion to become a leader in its field and it only speeds up the mess.
can also result no real benefits. Becoming Anonymous IT industry statement
a leader or gaining significant benefits
does not come without facing the many
challenges of change.
Global corporate annual investment in ICT is estimated at 2 trillion US
dollars (twelve zeros after the 2!). Nevertheless, the combined efforts of
CIOs, executives, researchers, consultants and vendors cannot guarantee
that such investments are always successful and productive.
There is much literature bemoaning the difficulties in making produc-
tive ICT investments. There are also many conferences every years on
how to gain more value out of ICT. These confirm that this is not a sim-
ple matter of investing and then collecting dividends.
The consequences of myopic vision

In the early 1990s several enterpreneurs – Fidelity, Schwab, E-Trade and others moved into
online brokerage through the Internet. Merrill Lynch, a more conservative company, con-
sidered it and decided against it – too many uncertainties, too many risks and maybe the
Internet was only a fad after all.
Now, like the others, Merrill Lynch offers online trading but it missed the opportunity to be
a market leader.
There are, of course, many case studies based on companies and public
sector organisations that had tremendous successes deploying ICT. There
are many more that discuss the lessons learned from systems that worked
more or less as intended but which provided no benefits or from invest-
ments that resulted in negative productivity gains because of the inap-
propriate use of an employer’s information technology facilities as well
as misuse and abuse.
The most famous current successes include: Federal Express and UPS in
logistics, Amazon in online retailing and several e-government initiatives
(such as the ability to renew driving licenses or submitting tax returns
on line) in several countries.
Less successful ICT deployments are not talked about in polite circles un-
less they become known as the Great Computer Disasters like the infa-
mous London Ambulance Service Computer Aided Dispatch system
(LASCAD) of 1992, the Mars Climate Orbiters that crashed in 1999, the
current US Government’s Internal Revenue Service overhaul of its sys-
tems and many others. ICT managers (should) know of such situations.
Observations about ICT in the real world

Here are seven painful facts about the successful use of ICT:
Observation # 1: There is a low correlation between ICT expenditures
and business results. This is determined not by technology but by how it
is applied and exploited.
Observation # 2: ICT can make or break an organisation. An inability to
succeed may lead to irrelevance or bankruptcy.
Observation # 3: There is no universal process that ensures the success-
ful deployment of ICT (if there was everybody would be using it – wouldn’t
they?). The factors that make the difference between success and failure
are discussed in this book acknowledging that every organisation is dif-

ferent.
Observation # 4: Regardless of how good the quality of the technologies,
systems and of the information handled by them, their impact depends
on the relevance of the technical solution and the ability of the users of
these systems to do something useful with this information.
When these four first observations are fulfilled and combined, they have
a positive impact on individuals. This gives a good chance that invest-
ments in ICT will have an impact on results – profits in the business sec-
tors and whatever other metrics of success are used in the public sector
and other non-profit ventures.
Observation # 5: Reward and risk are In his 1997 book “Disruptive Technol-
linked – innovative ICT focused on in- ogy”, Clayton Christensen describes
cremental improvements and low organ- “the innovator’s dilemma” where
technological innovation can cause
isational or business risk will have mod- great companies to fail. An example
est benefits. High impact, high benefit of this was the emergence of the per-
ICT projects will be, by their very nature, sonal computer, that became a re-
spectable business tool when IBM
disruptive to an organisation and there- first produced a 16 bit PC in 1980. A
fore, high risk. few years later IBM and Wang were in
serious trouble because they did not
Observation # 6: Something like 70-80% have a monopoly on these PCs which
of all ICT expenditures go to maintain were displacing demand for other
what is already there and the remaining products. IBM managed to get out of
their bad situation in the mid 1990s
20-30% is devoted to new developments. and Wang has since gone out of busi-
Therefore, attempts to reduce the cost of ness.
ICT by cutting budgets do not work as in-
tended as they result in abandoning innovation, the impact on results
these could have and freezing the status quo.
Observation # 7: There are better ways to reduce the cost of ICT than cut-
ting its budget, and these should be led by the ICT function – such as sim-
plification, vendor management, rationalisation, adoption of best prac-
tices and outsourcing.
Should investments in ICT make a difference?
In the Information Age, it could be assumed that few executives would

say “NO”. If the answer really is “NO” – it states that In this case the best
way forward would be to spend only to maintain the status quo with ac-
ceptable technical performance – minimal upgrades, essential mainte-
nance and accept the consequences of lagging behind others.
This approach can work well enough in some environments, particular-
ly those that already work well performing functions that are relatively
stable (energy generation, industrial automation) and also in environ-
ments where innovation is known to have high technical implementation
risks and very high costs (as is the case in air traffic control). Many of the
Great Computing Disasters revolve around attempts to replace such “old”
ICT with complex innovative solutions.
However if the answer is “YES”, it means that in “making a difference”,
ICT implementations will change the status-quo within an organisation.
This becomes a challenge to executives as change will be resisted and even
opposed.
Resistance to change is not new and reflects human nature, as Nic-
colo Macchiavelli pointed out in the 16th Century and it would ex-
ist even if ICT did not. The introduction of word processing in the
late 1970s was greeted with resistance from workers and trade
unions – who insisted that nobody should work for more than two
hours in front of a screen without a half an hour break as there were
fears that electromagnetic radiation, repetitive strain injury and
looking at the screen all day would have detrimental effects on the
health of workers.
The popularity of computer games, the Internet and home computing in
general show that these concerns were exaggerated. What happened was
that the usefulness of these systems quickly overcame resistance.
Other innovations that apparently were un-

likely to change the status-quo – like the in- Disruptive e-mail
troduction of electronic mail were adopted At a diplomatic reception, a senior
with great enthusiasm by all but the most Ambassador expressed concern that
e-mail had weakened protocol and
technophobic executives who refuse to have that younger diplomats no longer re-
a computer in their office. However the im- ferred to him as “Mr. Ambassador”
pact of electronic mail turned out to be but addressed him in a casual style
and by his first name. The Ambassa-
quite disruptive by enabling quick informal dor did not believe if it would be pos-
exchanges disregarding organisational sible to return to the old protocol.
boundaries and even protocol.
Making a difference will always have unintended consequences and un-
predictable side-effects.
One of the advantages of explicitly admitting that ICT investments should
make a difference is that it provides a way to define how its benefits will
be measured. Information Economics is not a mature discipline – it has
a long way to go to catch up with the traditional economics in which land,
labour and capital are the only things that matter.
One of the leading thinkers and writers on Information Economics, Paul
Strassmann said that “investing in IT without verifiable benefits, is not
managing, it’s gambling”. While this is totally right, there is an element
of gambling in ICT investments. This is confirmed by looking at confer-
ence programs and studying ICT publications.
Is it possible and desirable to break out of a cycle where expenditures are
made simply to keep up with technology – as in
• “our personal computers are too slow and must be upgraded”;
• “we must upgrade our systems to an Enterprise Resource Planning
(ERP) system (or a Customer Relation Management (CRM) system”;
• “we need to be in Knowledge Management” and many more similar
needs.
This is possible and should be vigorously pursued. Deciding on what
should be invested in and its priorities is a governance issue that should
not be delegated to ICT people.
The many ways of making a difference
In the same way as twin brothers will drive identical cars in different w
ays, ICT hardware and software products, many of which have become
Chapter 6
commodities, will be applied and used in different ways in every organ-

isation. Some will benefit from it to a high degree while others will not
because ICT can be applied in non-creative and creative ways.
Non-creative uses of ICT
Uses of ICT that focus on process automation, increased productivity, cost

reduction or simply to replicate something that has already been done
elsewhere (for example not being among the first in establishing an In-
tranet or engaging in Business-to-Business electronic commerce) are typ-
ical situations of following the leaders rather than being creative.
Non-creative uses of ICT are rarely focused on knowledge work or on em-
powering the workforce. In most cases they deal with tightly regulated,
repeatable processes where conformity and consistency are priorities.
Many of these uses will be resisted by those who prefer the status quo over
change, unless their implementation does not challenge the assumption
that there are certain things that cannot be changed, in which case they
stand a good chance of being adopted.
The benefits of non-creative uses of ICT will generally be modest, in line
with their low risk. In most cases the outcome of such investments is
meeting some desired targets. Such benefits can be quantified without
too much difficulty.
Creative uses of ICT
These exploit information to create value to the organisation and/or its

clients. They are also high-risk, in terms of outcome and technology be-
cause their benefits, while substantial are also speculative, thus requir-
ing an Act of Faith from the project sponsor.
The factors that unlock the value of information are complex and require
appropriate technology choices, a profound understanding of the organ-
isation’s internal unique knowledge and the ability to combine this knowl-
edge with technology.
Knowledge workers focus on the creation of products and services with a high
information/ knowledge content. Current leaders in this field include:
• Producers of software, modelling tools and virtual reality tools and
products;
• Various forms of computer “art” such as in the film and entertain-

ment industries;
• Virtual organisations where work is conducted around the globe on
a continuous basis, taking advantage of skills available in different
time zones
Creative uses of ICT can be found in any area of activity and will only suc-
ceed in the right cultural environment. This needs a business model in
which knowledge workers are empowered to be creative and to share in-
formation and knowledge with their peers as is the case, for example, in
consultancy companies, in which the knowledge capital of their work-
force is a major asset.
Human and organisational reactions

to change
Change and individuals
Human reactions to change are predictable. Most people do not like

change when they cannot control it and fear its consequences, in partic-
ular that of becoming a “loser”.
A loser can take many shapes: a person who loses their job and may not
be able to find a comparable alternative, a person who loses influence in
the organisation or someone who is ill equipped to cope with new respon-
sibilites and/or the need for new skills.
Those who feel they may become losers will have a negative attitude to
change. Many will become “tree huggers” and will argue that the pro-
posed change “will not
work”. Many will not be
able to adjust to the new
environment and will end
up suffering from stress.
More harmful to an or-
ganisation seeking change
are the active resistors –
the “leg breakers”. They
will use political skills, internal networks and their organisational knowl-
edge and experience to derail the change initiative. They often succeed.
Bystanders are likely to be in the majority and will support the idea of
change “in principle” on a wait and see basis. Most but not all of them
will succeed in adapting. Those who fail to adapt will become legacy staff
for as long as they remain in the organisation.
The remaining category, the Change Agents are those who will identify,
argue for and lead initiatives. They ought to be considered as star per-
formers in organisations that think creatively about the future. They are
likely to be seen as “dangerous individuals” in those organisations that
prize bureaucratic conformity.
The distribution of such characters in an organisation depends on its cul-
ture. Change Agents may be very senior managers or leaders – as was the
case when IBM brought in Lou Gerstner to be their Chief Executive de-
spite his lack of experience in the ICT industry – or middle managers that
seize and opportunity to do something important for an organisation,
such as restructuring a whole department or business unit. From time to
time, the Change Agent will be a less senior manager who discovers a
great opportunity and is able to share the enthusiasm for pursuing it with
executives.
Organisations consist of people and assets. The collective behaviour of
people in an organisation defines its “organisational culture” through its
activities, history, values and the expectations of the organisation’s own-
ers. This book proposes four parameters to describe it. These parameters
can take any value between the two extremes and together can be used
to describe anything from a department or business unit to a major con-
glomerate, at least in broad terms.
The stakeholders’ expectations – whether they are shareholders, compa-

ny owners or the board of a not-for-profit organisation have a defining
role in how change is perceived and pursued (or resisted).
Risk averse management is a handicap in the case of an organisation fac-
ing high expectations from its stakeholders. In the private sector of many
countries this is a self-correcting situation through “separation”.
When stakeholders expectations and top management culture are
matched by a reward system where high expectations are linked to re-
ward by results (meritocracy), innovation, change and high performance
will be clear targets shared by the workforce.
At the other extreme, low expectations (the organisation talks of reform but
does not act on it because it’s “too difficult and will take a long time”) and a
politicised reward system – where it matters more who you know than what
you do, innovation and change will be only discussed (interminably).
An adventurous manager who believes in meritocracy but has been re-
cruited by an organisation that doesn’t will quickly become frustrated.
Many will leave, others will give in and adopt this culture if it offers job
security in exchange.
Finally teamwork: a mercenary workforce, where everyone competes with
everyone else is incompatible with Knowledge Work, where sharing is an
essential requirement.
Change and organisations
The owners of an organisation can be private individuals, shareholders,

government and others like the donors that support a foundation. These
owners have a major say in the or-
ganisation’s strategy and how this
transforms itself into a culture. In
the book The End of Change, the
authors argue that there are four
basic types of organisation when it
comes to reacting to change.
The authors say organisations that
change infrequently and then only
The End of Change, by Peter Scott Morgan et.al, Mc. Graw Hill, July 2000. The
diagram on this page is based on an illustration in this book.
in small ways, should be described as Pyramid organisations – the most

stable geometric shape – hard to shift or to turn on its side.
Pyramid organisations tend to have long histories and are traditional in
their outlook – to them the future will be an extrapolation of the past and
maintaining the status quo is important.
Strongly hierarchical, they promote staff from within and on the basis of
seniority and personal networks rather than on merit. They hold strong
beliefs that certain things “cannot be changed” (arguably a myth invent-
ed by bureaucrats to maintain the status quo). While more common in
the public sector than in the commercial competitive environment, pyr-
amid organisations can be found everywhere where long history and tra-
dition play a major role in their culture.
An example of a pyramid organisation that was forced to change was IBM in
the early 1990s: a highly successful company that dominated the ICT market
for many years, it did not adapt to the changes that one of its products, the
personal computer, had unleashed and lost a substantial share of its market.
Facing a crisis, IBM broke with tradition and appointed an outsider (Lou
Gerstner) to lead the company. Yhe new Chief Executive decided that the
way forward was to transform the Pyramid into a cube – another stable
geometrical shape that can be turned on its side to become stable again.
A cube organisation undergoes substantial change to overcome a crisis
or achieve a major transformation as is the case with mergers and acqui-
sitions. Such a transformation can only be achieved with effective lead-
ership. In such situations many traditions have to be abandoned to change
things that were hitherto thought as fixed and impossible to change.
Consensus is not part of the process and there are many painful decisions to
be taken. Returning to the IBM example, nearly half the workforce at that
time (over 200,000 employees) were moved out of the company. Nearly the
same amount of new staff was recruited over the years that followed.
Another commonly found type of organisation is described as a cylinder,
easy to roll with minimum effort, where small and frequent changes are
part of their day-to-day operations. Such organisations often practice To-
tal Quality Management and Continuous Process Improvement. Here
change is not seen as disruptive and is driven and implemented by the
workforce, considered to be the experts in the processes and therefore,
the best qualified to identify ways to improve them. These organisations
tend to have incentive-based reward and recognition mechanisms.
The final class of organisations discussed in the book are those rare in-
stances that face dramatic change on a frequent basis – the sphere in the
diagram. These are not found in the corporate or government worlds but
rather in innovative and creative environments where ideas and efforts
that do not appear to lead to success are abandoned and replaced by some-
thing else – for example in advertising.
One more factor influences the way in which organisations respond to change:
their metabolic rate. Those with a fast metabolic rate are well used to deal
with changing needs and act upon them promptly. Organisations in a com-
petitive environment need a fast metabolic rate to survive and thrive.
Those with slow metabolic rates, react to opportunities by creating com-
mittees, working groups or task forces in the search for consensus, and
engage in Analysis Paralysis. These tend to be pyramid organisations
with a long history, often with a strong trade union presence as well as in
the not-for-profit sector.
The Executive’s challenge
There is no magic formula for success in implementing change. Change

brings forward a collection of people issues that require careful handling
and a headache. Executive leadership is vital to the success of any change
initiative.
Change driven by the innovative, creative introduction of ICT is never
smooth as it requires considerable adaptation and learning by the work-
force. Some people will be unable to cope with these demands.
Action points
Ensure that the purpose of investing in ICT is clear and communicated

to all those who will be impacted by the changes resulting from this in-
vestment.
The factors that will unlock the benefits of investing in ICT require exec-
utive action – these are always beyond the reach of ICT managers. This
is discussed in more detail in Chapter 6.
C h a p t e r
5
Financial aspects of ICT
ICT expenditures
Not everything that counts can be counted

Not everything that can be counted counts
Albert Einstein
• Why does ICT cost so much?

• What drives the cost of ICT?
• How does an organisation know the total cost of its ICT?
• Can the cost of ICT be contained?
• Is outsourcing expensive?
Organisations spend between 2 and 10 percent of their turnover on ICT. At the same time,
it is clear that the price of a personal computer and its standard software is in the order of
1,000 US dollars or Euros and that a wireless home network can be implemented for a few
hundred more. This chapter explores where the rest of the corporate money goes.
Direct costs are linked to the complexity of ICT, the level of quality of service required, the
uniqueness of solutions. Indirect costs are often forgotten and this leads to the belief that
all ICT expenditures are represented by the budget of the ICT function. This is not true and
the direct costs incurred by other functions together with indirect costs can add to as much
as the budget of the ICT function.
When the true cost of ICT is now well known, executives will not be able to determine how
their expenditures compare with those of other organisations in the same line of business
(and this is true for the not-for-profit world. Not only this, they will not have a sound basis
on which to evaluate the potential for outsourcing some or all ICT activities.
Why does ICT cost so much?
A genuine Frequently Asked Question for at least four good reasons:

1. ICT represents a significant and visible expense – somewhere be-
tween 2 and 10 percent of an organisation’s total turnover, depend-
ing on their activity;
2. There is good evidence that ICT expenditures have little correlation
with business results. A best selling book on this topic is Paul Stras-
smann’s The Squandered Computer. Many other voices have joined
in to confirm this;
3. The true cost of ICT is greater than the budget of the ICT function as
expenditures have migrated to where they are not easily counted. For
example, shouldn’t the cost of developing sophisticated spreadsheets
in the Finance department be counted as an ICT cost or the time
spent by a marketing manager designing a departmental web page?
4. ICT project costs have a poor track record of underestimation.
The Squandered Computer, by Paul Strassmann, 1998, Information Economics
Press.
Many ICT items have become commodities – personal computers, wire-

less networks, broadband Internet access, cellular phones, colour print-
ers, scanners and more. These are widely advertised, there is strong price
competition and their cost can be determined quite accurately.
This creates a paradox: if you can buy a personal computer (PC) for less
than a thousand dollars, how can corporate ICT expenditure for a net-
worked PC be as much as 10,000 US dollars per employee per year?.
Cost drivers
In the corporate environment the cost of end-user hardware and software
represents around 15 percent of the total cost of providing ICT systems,
facilities and services. Where does the money go? The answer is that four
factors drive costs upwards. These are:
• The many components behind a computer on a desk;
• The complexity required to provide a quality service;
• The scale of ICT operations;
• Computer applications software
The many components behind a computer on a desk
The computer on a desk is only a small part

of the total cost of ownership of ICT. In a well
run organisation the elements that support
it should be as “invisible” as other utilities –
electricity, water or the telephone’s dial
tone.
The difference with these utilities is that to-
day few organisations generate their own
electricity or purify their water supply but
many continue to run their own ICT infrastructure. Over the last twen-
ty years many have decided to outsource the operational aspects of ICT
while others are “happy” to operate their ICT infrastructure.
Regardless of where operational work is carried out, substantial amounts
of facilities, equipment, software and people are required to make things
work. The table summarises the major items needed to do so (a complete
list would be much longer). Each one of these represents a non-trivial cost
component and people costs are an important element.
Facilities Hardware Software People

Computer room(s) Servers Operating systems Operations
Help desk offices Storage (all media) Utilities Support
ICT staff offices Networking Diagnostics Business Analysis
Standby generator Cabling Databases Development
Contract manage-
Battery room Security Development tools
ment
Fire extinction Racks and cabinets Applications Security
Consumables Maintenance and Data administra-
Physical security
(tapes, toner, etc) support tion
Other tools (e.g.
Off-premises Maintenance and Database adminis-
antivirus, anti-
storage support tration
spam,…)
Disaster recovery … … Projects Office
How little or how much of each of these components is needed to meet

the needs of a particular organisation depends on its sophistication in the
use of ICT, the expected quality of service and the scale of the opera-
tion.
The cost of each facility, hardware and software consists two components:
a one-time acquisition cost and recurring costs, of which maintenance is
a typical one.
All these expenditures are what would be expected to be present in a rea-
sonably transparent ICT budget. Many other cost components are often
hidden in other functional budgets such as the cost of procurement, le-
gal services, insurance, internal audit and so on. These are discussed lat-
er in this chapter.
Budget structures may not present costs in the same categories as the ta-
ble shown here. Some budgets may have a category “personnel costs” but
these not include facilities such as accommodation. Items such as stand-
by power generators may not even appear under ICT costs but rather as
“rental of property and equipment”.
ICT complexity, quality of service and scale
ICT hardware and software will, sooner or later, fail to operate. This could
be the result of a mechanical or electrical failure, software errors, poor or
incorrect configuration or any of a multitude of possible causes includ-
ing human error.
For a single user this is inconvenient. For an organisation this could rap-
idly become a major problem – this is certainly the case for anyone en-
gaged in e-commerce, financial institutions, airlines and other transac-
tion-oriented organisations.
This is just as much of a problem elsewhere – any multinational organi-
sation with employees at many locations around the world whose net-
works, e-mail systems or other facilities become inoperable for the best
part of a day will be seriously disrupted. “Quality of service” is the way
to define the degree to which ICT should be organized to avoid disrup-
tions. There is a price to pay for service quality, and a significant one at
that:
Twenty four hours a day, seven days a week, (24*7)
The Information Age has made distance and timezones
less relevant than they used to be. While many organisa-
tions continue to work in the world of “Monday to Friday,
9am to 5pm”, their ICT requirements extend beyond these
hours.
Remote access to systems and facilities by a mobile workforce, access to
electronic mail, websites and information security, etc. all require ICT
operations twenty-four hours a day, seven days a week.
This has cost implications: Regardless of the level of automation in a com-
puter room, human intervention is essential when disruptions occur and
on-site presence needs to be catered for to provide 24*7 cover.
As a typical employee works
some 7 to 8 hours a day for
220 days in a year, it takes five
people (suitably qualified,
trained and willing to work
shifts) to provide cover 365
days a year in three shifts of
eight hours.
99.9x availability
When business processes rely on ICT, downtime – the time during which
the ICT is not available to perform – means that business processes can
either not be conducted at all (electronic commerce) or can only be per-
formed in a degraded manner by doing them manually and then updat-
ing the computer systems when their operation is restored.
Service interruptions can be planned (manageable) or unplanned (dis-

ruptive). Planned interruptions are needed to implement major mainte-
nance, upgrades, equipment replacement, testing and other such activi-
ties. Well run operations plan such activities to take place in the middle
of night on weekends, public holidays and at other times when disruption
to business operations can be minimised. The average duration of planned
service interruptions reported by the Gartner Group (an ICT industry ad-
visory service) ranges between 250 hours a year (average) and less than
12 hours a year (best in class).
The remainder of this discussion focuses on availability as affected by
unplanned downtime, measured as a percentage where 100% means that
ICT systems and facilities are always operational.
• An availability of 99 % describes a total annual downtime of around
90 hours
• An availability of 99.9 % describes a total annual downtime of 9
hours
• An availability of 99.99 % describes a total annual downtime of just
under 1 hour
• An availability of 99.999 % (known in ICT jargon as “five nines” de-
scribes a total annual downtime of 5 minutes
Downtime can be re-
duced through measures
such as resilient design,
backup facilities in hot-
stand-by (i.e. ready to go
operational at very short
notice) and emergency
response teams.
Increases in availability
(reductions in downtime)
can be achieved but at a
cost, as complexity in-
creases rapidly.
The chart illustrates that to increase availability from what is considered
standard (in the range of 98 to 99%) to a “silver” level doubles the cost of
ICT operations, to a “gold” level, triples it. Moving to a “platinum” level
of very infrequent and short interruptions results in considerably higher
cost.
Therefore the specification of quality of service must be realistic – the

mindless pursuit of perfection is always too expensive.
Dealing with scale
Scale also increases complexity and costs. This can be illustrated by the
telephone extension example: Anyone with a little technical ability can
buy a telephone set, a reel of cable and, within a short time, install a sec-
ond telephone in another room at home. The total cost of doing this would
be marginally more than the telephone set (perhaps it would be neces-
sary to buy a drill as well as the reel of cable).
Given the success of this little exercise, why not install ten telephones –
one in every room and also in the garage?. Clearly this will require more
time and some planning. Even if the time required to do this work is not
costed, having so many telephones will need a more sophisticated central
telephone and possibly one or two more telephone lines with separate
numbers. The cost of this is noticeably higher than the cost of the indi-
vidual telephone units and will also incur higher recurring charges.
So far so good. The next step up would involve installing one hundred
telephones. This is a real project. The labour involved in cabling alone is
not trivial and would have to be paid or accounted for. There is a need for
a small switchboard, possibly with an operator, the need to assign exten-
sion numbers to each phone, produce a directory and keep it up-to-date.
If the telephones are fairly sophisticated, training would have to be pro-
vided to their assigned users.
Moving up to one thousand telephones becomes very complex. In this
scenario the telephone exchange becomes a critical piece of equipment
and will need to be supported by technical people. Then there will be reg-
ular requests for MACs (moves, additions and changes). At this level, day-
to-day operations require additional features such as voice mail.
Anything above ten thousand telephones is a major project, and the total
cost of such an operation divided by the number of telephones would be
much greater than the cost of a single phones. Of course, the economies
of scale of buying ten thousand identical phones would help to reduce the
total cost but not enough to compensate for the cost of scale.
The need to store documents in electronic form is

growing fast because so many documents are created
and disseminated in electronic form and meeting le-
gal requirements for the preservation and archival of
data and information.
The total volume of data and information in electron-
ic form is doubling every three to five years. However
low the cost of storing one megabyte of data, there is
a steady need for more capacity and for the resources
needed to manage all this data, including backups
and disaster recovery capabilities.
Computer applications and other software
Several classes of software are needed to meet an organisation’s ICT

needs.
There are items that are invisible other than to the ICT service providers.
These items include operating systems used in the data centre, databas-
es, monitoring and diagnostic tools, help desk support and inventory
management, development environments (the tools, utilities and librar-
ies that programmers use to build other applications software) and more.
The cost of software in this category is substantial.
Conventional, off the shelf (COTS) software, sometimes referred to as
shrink-wrapped is used mainly for desktop computing – office suites,
electronic mail and internet browsers, groupware and workflow applica-
tions and others that are installed essentially as they are.
This kind of software has a life of roughly four years (vendors produce
new versions on an almost annual basis but the “old” software remains
usable. The cost of this software is negotiable, particularly through vol-
ume.
Business applications, the software most strongly aligned with the busi-
ness processes and activities of an organisation needs tailoring to the
practices and preferences of each organisation (a process referred to as
customisation). Quite often, applications are made to measure from
scratch to meet specific requirements.
The customisation of commercial products involves substantial sums of
money – an Enterprise Resource Planning system (ERP) for an organisa-
tion with several thousand employees will have an implementation cost
in the tens of millions of US dollars/Euros. A major part of this cost will
be the fees of the experts who carry out the customisation.
Developing systems of any level of sophistication (= complexity) from
scratch is a major undertaking where costs, timescales and risks are all
significant. As in the case of customisation, the main cost component is
expertise, regardless of whether the work is done by employees in an ICT
function, a contractor or vendor or in off-shore centres where salaries are
considerably lower than in OECD countries. The management of such
projects is discussed elsewhere in this book.
A list of all the items that need to be considered to understand the cost of
a software project – from initial concept to its implementation and oper-
ation - would look like this:
Item Cost Estimator Accuracy
Project preparation costs
Concept, definition, feasibility assessment
Preparation of detailed estimates or of a Request
for Proposals (RFP) (consultancy + internal
resources)
Evaluation of responses to the RFP
Contract negotiation costs (legal fees, travel, etc)
One time costs
Project management and project team
Setting up change control processes and systems
Hardware purchases
Software licences and tools
Custom software development (in house or
external)
Item Cost Estimator Accuracy

Training of ICT staff to meet requirements of
the project
Contractors and consultants
Installation, systems integration and related
testing
Data preparation, data conversion and migra-
tion, data integrity audits
Development of disaster recovery plans and
initial testing
End user acceptance testing
Briefings and staff communications
Migration of all staff to the new systems/
facilities
Recurrent annual and lifecycle costs
Data centre operations (including backup/
restore and all other operational activities)
Systems administration and database adminis-
tration
Disaster recovery arrangements including
testing
End user support and ongoing staff training
Hardware maintenance, upgrades and replace-
ments
Software licences renewals, upgrades, migration
to new versions
Post implementation costs
Disposal of legacy systems (if this project is a
replacement)
Project review and impact analysis, lessons
learned
Post-implementation benefits audit (2 to 3 years
after completion of the project)
Tables of this kind are more useful and plausible when they indicate who
worked out the cost estimates and the accuracy to which these costs have
been estimated.
Lifecycle costs
This table shows four cost categories. Together they represent the cost of
a computer system over its service life. The desktop telephones used in
the example on scale are likely to have a substantial service life, ten years
or more and relatively low maintenance costs. This is not the case with
the majority of ICT equipment.
Many enterprises have maintenance contracts, sometimes included in the
procurement contract so that the vendor or an associated company per-
form repairs on such equipment. Larger items of equipment – from serv-
ers to enterprise storage systems and networking devices always have
maintenance contracts. It is prudent to assume that the annual cost of
maintenance for such hardware is in the order of 10% of the purchase
price.
Software licences come in many categories, ranging from a one time pay-
ment (typical for desktop software, although some vendors charge annu-
al license fees) to usage-based fees or machine-size related fees. Some of
these fees are annual, other involve a first payment followed by annual
fees.
In addition to license fees, there are other costs related to software: main-
tenance charges that entitle the licensee to obtain upgrades, patches and
fixes (additional software provided by the vendor to “cure” defects in the
licensed product). From time to time vendors package all these features
into a new release of the software. These are frequently available against
payment of an additional fee. There is a catch: while obtaining such a re-
lease is not mandatory, the vendor will not provide technical support un-
less a certain version and level of the software has been installed.
For software developed to meet the specific requirements of an organisa-
tion – either by customising a package (ORACLE™ Financials or SAP™,
for example) or by developing the application from scratch, there are also
maintenance and enhancement costs to be incurred. “Maintenance”
means correcting bugs and errors and keeping the relevant documenta-
tion up to date. “Enhancements” means the development of additional
features.
Unpleasant and expensive surprises may arise when the vendor decides
to issue a completely new version of the basic software, usually followed
by an announcement that support for existing versions will be terminat-
ed in the not so distant future (often two years). A new version of a pack-
age may not allow the migration of all the customisation work done for
the version in use and require considerable effort to achieve this.
Typical maintenance expenditures can be estimated at around 15% of the
total cost of developing the software. The cost of enhancements can vary
from zero, when the application is frozen to large amounts of money if
the enhancements are large and complex.
Expenditures to maintain and upgrade infrastructure items are hard to
justify through conventional Return On Investment (ROI) calculations
as they are merely a component in a complex network of separate com-
ponents that only add value as a whole and then only when they are put
to productive use.
Direct and indirect costs of ICT
Direct costs
These are the clearly identifiable ITC costs associated with specific re-
sources. However, budgets and accounting systems do not always capture
these expenditures in a way that identifies the purpose for which the ex-
penditure was incurred.
Prerequisites to understanding direct costs include comprehensive inven-
tories of hardware, software and personnel (including temporary staff,
consultants, contractors, trainees and others), as well as all ICT contracts
(for maintenance, services, etc).
The following (typical) questions may not have good answers unless ac-
counting systems are designed to collect data and prepare reports of this
kind:
• What is the total direct cost of developing and maintaining the soft-
ware for the payroll system?
• How much time has employee “Joe Bloggs” spent on the enhancement
of the SAP® payroll module?
Accounting practices such as Activity Based Costing (ABC) may give a
better picture. ABC is not always worth implementing because of its com-
plexity, and is primarily used where detailed cost accounting is a prime
business requirement. For example, ICT Service providers use ABC be-
cause of intense competition in the outsourcing of ICT operations. Know-
ing the exact cost of service provision can make the difference between
profit and loss.
When weak cost reporting is combined with weak governance, many ac-
tivities will increase costs:
• Diversity of solutions, technical platforms and parallel initiatives,
particularly for common tasks where standardisation might be a bet-
ter option;
• The enthusiasm of technical personnel for the newest technologies
resulting in “evaluations and pilot schemes” – these are resource-in-
tensive but may have limited business value and be subsequently
abandoned;
• The Mindless Pursuit of Perfection reflected in the over-specification
of technology and performance requirements;
• Extensive reliance on consultants.
Indirect costs
The ubiquity of ICT has caused expenditures to migrate to where they are
not easily counted, and these become indirect costs. Many will be regard-
ed as the “Cost of Doing Business” and may or may not appear as specif-
ic budget items.
Such indirect costs fall in two categories: those that could be reasonably
measured or estimated and those that are hard to monitor and should
therefore be referred to as “invisible costs”:
The first category includes the costs of
• Accommodation for ICT staff, computer rooms, their ancilliary
equipment and related services – for example building maintenance
and physical security;
• Procurement of ICT items by the purchasing department in an envi-
ronment where this is treated as a corporate service not charged in-
ternally;
• Eecruiting ICT staff – the advertising, interviewing, travel expenses,
etc of candidates when these activities are carried out the Human Re-
sources department;
• Reviewing ICT contracts by the corporate Legal Department, inter-
nal audits, etc …
Invisible costs include:

• End user ICT activities: These represent tasks taken over by individ-
uals who evolve to behave as part of the ICT support structure. Usu-
ally done on an “as requested” basis in addition to their regular job,
this may consume considerable unplanned and unmeasured time
and resources. This ranges from handling personal computer assis-
tance within a work group to designing non-corporate templates,
macros, small databases and other small applications.
• Downtime: The cost of downtime is estimated to be in the range from
50,000 US dollars an hour (in activities that do not have a critical
business impact) to several million US dollars an hour – for example
in foreign exchanges and other financial institutions. For the pur-
pose of assigning value to downtime, it is recommended that (in
2004-5) the figure of 1 US dollar or 1€ per minute per employee be
used in OECD countries.
The cost of downtime will be largely defined by the nature of the work
impacted – for example a currency trader could lose valuable deals while
an administrator could do other tasks for a while.
The Total Cost of Ownership (TCO)

The concept of TCO was developed in the late 1980s by the Gartner Group,
a research and advisory services company specialising in ICT. Their anal-
ysis focused on the cost of owning and deploying personal computers
(PC) over a lifecycle of five years. This analysis took into account all the
issues raised above.
Their findings received much public exposure and showed that a net-
worked PC could cost an enterprise nearly 10,000 US dollars a year. This
caused the technology and financial communities to gasp in surprise.
The Gartner TCO methodology was subsequently reviewed by many parties
and accepted as a robust way to evaluate total costs. In essence the TCO in-
cludes the direct and indirect costs, incurred throughout the life cycle of an as-
set, including acquisition, deployment, operation, support and retirement.
The adoption of the concept of TCO has two significant benefits for ex-
ecutives:
Benefit 1: it proves that the initial costs of hardware and software are a
small part of the true overall cost of ICT and the total cost is manageable
through executive action.
Benefit 2: it makes it possible to determine the efficiency of how ICT is

deployed in an organisation and make meaningful comparisons against
published performance data (benchmarks). This enables executives to
take informed decisions on matters such as outsourcing.
Estimated and real costs

ICT projects, particularly software development are notorious for being
consistently under-estimated. Situations such as where a “fixed-price
turnkey project” with a price tag of 10 million dollars ends up costing
over 40 million are not uncommon.
There are several books and publications that confirm that many organ-
isations invest heavily in large software projects that ultimately go wrong.
Moreover, projects that do get completed, take longer than anticipated,
cost more than budgeted for and, frequently, do not deliver the full func-
tionality initially promised.
Executive dilemma: why don’t we know

the true cost of ICT?
In government, as well as in other areas of activity, there is much empha-

sis on the control of budgets and cash flow. In such situations, a typical
budget formulation for the ICT function will contain lines for:
• Staff costs
• Non-staff costs
• Hardware and software purchases
• Maintenance contracts and consumables
• Telecommunications
• and perhaps a few other lines of this kind
Well suited to controls, this approach makes it difficult to identify expen-
ditures against specific activities – for example how much is spent in to-
tal on a particular computer system like electronic mail.
When the total true cost is not known in any detail, how does an execu-
tive know how well these expenditures compare with other departments
or comparable offices? Is it important for an organisation to benchmark
the way in which these expenditures are incurred?
Can expenditures be contained?
While cutting the budget of an ICT function does indeed contain costs,
this may prove to be no better than an SMRC approach: Saving Money
Regardless of Cost – an inefficient ICT operation risks getting worse un-
less six actions to contain costs are implemented in earnest. These six ac-
tions are:
• An emphasis on standardisation;
• Enterprise wide contracts;
• Rationalization and consolidation of ICT activities and infrastruc-
tures;
• Service levels that are “good enough” and no better;
• Effective change control;
• Outsourcing.
Standardisation and best practices
Standardising technologies and application systems software is a daunt-

ing task for a large organisation (even harder for a multinational) with
many business units and departments, but the cost of diversity is high.
Situations where individual business units develop their own computer
systems to perform roughly the same functions (accounting, human re-
sources and payroll, procurement and logistics) arise when there is au-
tonomy on ICT matters at the business unit level.
Taking for example an Enterprise Resource Planning (ERP) where typi-
cal entry costs are in the tens of millions of dollars, multiple solutions de-
veloped and implemented several times over are a major cost to the or-
ganisation. Moreover, this also makes it difficult to exchange data be-
tween Business Units or to consolidate data at the corporate level.
There are many sources for Best Practices (better referred to as proven
practices) and these are inexpensive to acquire. However, many people
working in ICT will argue that the disciplined approaches of Total Qual-
ity Management, and practices such as the Information Technology In-
frastructure Library (ITIL) and COBIT are “expensive” and should not
be adopted. Executives should consider whether how likely it is that a
First produced by the UK Government Central Computing and Telecommunica-
tions Agency (http://www.ogc.gov.uk/index.asp?id=2261)
Control Objectives for Information Technology (http://www.isaca.org)
group of technical people can really do better by reinventing these prac-

tices in their environment.
The introduction of such methodologies requires an initial investment
and much effort to achieve. Their benefits will not be immediate. The ar-
gument that they are expensive is invariably based on a reluctance to
change and a lack of awareness of the costs and risks associated with poor
processes – this will be discussed again in Chapter 8.
Enterprise wide contracts
ICT vendors produce price lists. These are usually negotiable and volume
purchases can lead to attractive discounts. These must be assiduously ne-
gotiated.
Salami-slice procurement where a few items are purchased at a time does
not benefit from such benefits and has the significant added (but rarely
counted) cost of processing purchase orders and the subsequent invoices
and payments.
Rationalization and consolidation
The proliferation of ICT facilities across an organisation (computer

rooms, telephone exchanges, communications links, etc) is commonplace
and tends to reflect the history of an organisation. In addition, many or-
ganisations have accumulated equipment and software which may not be
used by anyone and should be promptly disposed of. Good asset manage-
ment can be used to identify such situations.
Such an approach is demonstrably expensive to maintain and operate due
to the loss of economies of scale, duplication of purchases and activities,
etc.
The cost of networking has dropped dramatically in the last ten years,
and it is now feasible to rationalise such facilities and consolidate them
to a smaller number. For computer rooms, the cost reductions that can
be achieved by their consolidation are in the range 25 to 35 %, as this
makes more efficient use of space, personnel, diagnostic tools and auto-
mation. It also provides a more robust base for contingency planning and
outsourcing.
“Good enough” and no better service levels
It is human nature to want the best possible if it is affordable (and some-

times when it is extravagant). As shown earlier, the increased cost of qual-
ity of service escalates rapidly, as does that of providing continuous cov-
er on a 7*24 basis.
How does one know if the current level of service is too good for the or-
ganisation’s needs? If service levels are formally described in Service
Agreements or Service Level Agreements, these can be reviewed to deter-
mine if the cost reductions that could be achieved by lowering such ser-
vice levels are compatible with the organisation’s needs.
For example, an availability target of 99.99 (50 minutes total downtime
in a year) could be appropriate for military, intelligence, police and oth-
er emergency services but may be excessive for other government depart-
ments.
Change control
A method for ensuring that the idea of “good enough” is given more
weight than the Mindless Pursuit of Perfection, change control is a pro-
cedure for ensuring that frivolous changes to infrastructure, technology
or applications are not progressed. This is discussed in some more detail
in the chapter dealing with the operational aspects of ICT.
Is outsourcing expensive?
Fully expect ICT staff to say it is, certainly more expensive than what they
do in-house because outsourcers need to advertise and market their ser-
vices, employ lawyers and make a profit.
All of this is true but the “more expensive” statement should only be be-
lieved if there is good knowledge of the total cost of ownership support-
ed by systematic benchmarking against published information and inde-
pendent audit reports that define quality of service, process maturity and
other tangible metrics.
Outsourcing is the subject of a separate chapter in this book. It suffices
to say that ICT outsourcing is a competitive business with annual reve-
nues of around 100 billion US dollars. This shows that there are both
many providers of outsourcing services and a large number of clients who
consider that outsourcing is worthwhile.
Among the many case studies of the successful outsourcing of ICT – there have been some
unsuccessful exercises too – is that of DuPont de Nemours (http://www.dupont.com). A
large multinational with around 75,000 networked computers around the world, it signed
a contract in June 1997 to outsource is networking and computing operations to Comput-
er Science Corporation and its software development to Andersen. This represented at the
time the largest outsourcing contract of this kind: 4.2 billion US dollars over a ten year pe-
riod.
Interviews in various newspapers with the Chief Information Officer of Dupont reveal that
as a result of a programme of consolidation, rationalisation and standardisation, followed
by outsourcing, the company reduced its total cost of ICT from 1.2 billion US dollars per
year to 600 million.
Action points
Find out if there are indications that your organisation is spending more
than it needs to on ICT – but you can expect cries from the ICT function
that they are “not spending enough”.
Find out if the expenditures incurred on ICT are well aligned with the
business objectives of the organisation – what’s the value of a World Class
infrastructure if the computer systems are inadequate to support busi-
ness activities or management decisions or if the workforce does not have
skills to exploit them?
C h a p t e r
6
Financial aspects of ICT
Benefits
The value of information is hard to measure.
Only managerial competence outside the ICT function

can determine if ICT adds value.
An extract of this Chapter was published in Darwin Magazine (www.darwinmag.

com) in September 2004
• Why is it so hard to define the benefits of investing in ICT?

• How can benefits be identified and quantified?
• Are there any formal techniques for evaluating benefits?
• What are the problems surrounding benefits?
Having suggested that the cost of ICT is not always well known, benefits are even harder
to evaluate and demonstrate. This creates a difficult situation for executives, as technolo-
gists will advocate to invest in “newer, faster, better, cheaper” technologies without show-
ing specifically how the proposal to spend will contribute to the organisation’s results – re-
gardless if it is a commercial company, a not-for-profit organisation or a government de-
partment.
Executives who do not validate the benefits derived from ICT could be said to be gambling
with their company’s money, rather than making prudent investments. Such validation
should take place twice: at the time of considering a proposal for new systems or facilities
and then again, some time after the completion of the project, this time to determine
whether the promised benefits did materialise.
Assessing benefits is hard to do, as they need to be expressed in units that relate to the ac-
tivities of the organisation such as waste reduction, risk reduction, cost avoidance, etc.
The GIGA Group (ICT industry specialists) advocates an approach that works well to put a
value on such benefits
If the introduction of ICT makes something better than it was,

it’s because it makes a difference.
If it makes a difference it can be described
If it can be described, it can be observed
If it can be observed it can be measured
If it can be measured it can be quantified in financial terms
However, the assessment of benefits at the time of justifying an ICT investment is only a vi-
sion of what is expected. The factors that will unlock the benefits of investing in ICT require
executive action as these actions are always beyond the reach and authority of ICT manag-
ers.
The ICT benefits paradox
In the Information Age, knowledge work, knowledge management, intel-

lectual capital and other such topics are talked about all the time. Unlike
tangible assets such as buildings, machinery, furniture and money, data
and information do not appear as assets in financial accounts with the
result that information tends not to be treated as a resource.
Immature and senile organisations rarely treat information as a resource
and have fundamentally opposite views of the role of ICT, even though
this represents a substantial expense.
Immature Senile
organizations organizations
ICT is fun Tomorrow will be just like today

Must have the latest toy Entitled to exist “forever”
Results – what results? Resistant to change
When information is a resource (as is the case in finance, insurance, mar-

keting, situation analysis, government and others), is the situation where
the value of the resources cannot be quantified sustainable?
Measuring the value of data, information, knowledge and other not-so-
tangible items is not that different from measuring pain: there are no
agreed units of measurement or consistent tools to determine its level.
The difficulty of measuring value is real but not in-
surmountable. This chapter discusses options to as-
sess and present the benefits of investing in ICT. It
also shows that investing in ICT requires an act of
faith and that a measure of risk taking (gambling)
on the part of executives is needed to succeed.
One option, practiced in the not-for-profit sector is
to accept ICT as “the cost of doing business” where
there is little choice but to continue to invest. Stat-
ed bluntly, Return on Investment does not really
matter. Maintaining or increasing budgets does.
This may appear to be an attractive approach, but the sums of money in-
volved are large –the entry price for an Enterprise Resource Planning
(ERP) system is 10 million US dollars and it may end up costing ten times
as much (it has happened). Sooner or later somebody (a board or govern-
ing body) will ask uncomfortable questions. Unless good answers are pro-
vided this body could take dramatic action in the shape of major budget
cuts, replacing the CIO and/or their boss and possibly outsourcing the
ICT function.
Identifying and quantifying benefits

related to ICT
Benefits can arise in four distinct categories, each requiring different

methods for assessing and measuring benefits:
• Improved efficiency and improved effectiveness
• Improved levels of service
• Knowledge work
• Innovation
Improved efficiency, productivity and improved effectiveness
There is a major difference between efficiency (doing things right) and

effectiveness (doing the right things). Using ICT for processes that do not
add business value may increase efficiency but be a pointless exercise.
Example: People who had little to do in an office would play with a deck
of cards and play 12 games of Solitaire in one hour. With a computer that
includes this game (it comes with the basic software!), efficiency has im-
proved dramatically – now they can play 50 games in one hour.
Improving effectiveness implies optimising (this implies changing) work
processes to ensure that they add business value. Benefits of this kind in-
clude
• Fewer process stages, fewer staff for a given workload and lower over-
heads;
• Reduction or elimination of low value activities (for example reduced
volume of printing and copying);
• Reduction in the number of process errors requiring subsequent cor-

rective action;
• Reduced duplications and overlaps
Because these deal with essentially tangible resources (staff costs, con-
sumables, office space), these benefits are relatively easy to estimate in fi-
nancial accounting terms.
Improved levels of service
These can be dramatically changed by ICT, particularly in customer ser-

vice and in electronic commerce. ICT is used extensively to provide the
following benefits:
• Fast response to provide the right information first time round, ev-
ery time;
• Increased availability of service to clients regardless of time and dis-
tance;
• Provision of relevant diagnostics, advice and recommendations;
• Provision of customer support and communications;
Example: Online book retailer Amazon.com is totally reliant on its ICT capabilities and that
of its supply chain partners (suppliers, transport logistics, credit card handling). Their sys-
tem design and databases allow them to provide all four of the above benefits as they op-
erate 7 days a week, 24 hours a day at six global locations (USA, Canada, UK, France, Ger-
many and Japan) in a highly consistent manner.
Their search engine correlates individual queries with those of other individuals to provide
lists of recommendations “other people also bought…” and keeps track of your interests
that are used to create e-mail notices when new books or items that may be of interest to
you are available.
Their extensive self-help sections allow orders to be modified and tracked and provide lists
of how to deal with specific issues.
Some of these benefits – for example those associated with online cus-
tomer support based on ICT can be rigorously estimated because the al-
ternatives are not to provide them (zero cost, zero benefit, doubtful fu-
ture if another retailer does it) or to provide them through a call centre
(many staff, high cost).
However, putting a financial value on softer features is harder and re-
quires an act of faith on the part of executives because these benefits can
only be measured indirectly – how many more books were ultimately sold
because they were recommended after a search for another book? Intan-
gible benefits can be real eno.
When estimating such benefits, there is a risk that they will not materi-
alise, and this needs to be assessed.
Knowledge work
In the two previous categories, ICT is close to the centre of the action –
the people who do the work follow the machine. In knowledge work, the
reverse is true: people manipulating data and information to extract pre-
viously unseen meaning use ICT as a tool. Typical knowledge work appli-
cations include:
• Business Intelligence and situation analysis
• Data mining and Discovery
• Improved decisions based on relevant, timely and accurate informa-
tion
None of these are com-
modities and, the last
one has disappointed
executives who have
been promised over
the years that “Deci-
sion Support Soft-
ware” and “Executive
Information Systems”
were just around the
corner. They still are.
We intuitively know
that:
• Quality information reduces uncertainty
• Reduced uncertainty improves decisions
• Improved decisions lead to more effective actions
• Effective actions give better results.
There should be little argument that these las four points make sense.
This makes quality information a valuable resource and raises the prob-
lem of finding a way to put a financial value on knowledge-rich compo-
nents such as “thought leadership” and “creativity”.
Whatever answers are found, they will not be uniform across areas of ac-
tivity. Technology plays a minor role in the creation of value through
knowledge and many of the tools used are in fact commodities in the ICT
marketplace. It is knowledge that makes a difference.
Innovation
There are many opportunities to innovate in the Information Age – and

the “dot com bubble” of the early 2000s was an indicator of the degree to
which enterpreneurs were willing to take risks to lead in new areas of ac-
tivity and business.
New information-based products and services appear all the time and
that those who succeed do extremely well out of it – the people who es-
tablished the Google search engine became billionaires in a much short-
er time than industrial age innovators.
The evaluation of value and benefits is, like beauty, in the eye of the be-
holder. Highly speculative and uncertain, they involve an act of faith on
the part of the investor. This should not be a game of chance and while
the stakes may be high the potential rewards are simply enormous.
Which area of benefit will be the most suitable for any particular organ-
isation depends on its culture, its ability to adopt, and adapt to change,
its ability and willingness to take risks and finally, the nature of the en-
vironment in which it operates.
Techniques for evaluating benefits
Traditional processes to evaluate ICT benefits focus on tangible benefits

and are not flexible. Looking for Return on Investment in traditional fi-
nancial terms will most likely be a disappointing exercise and this ap-
proach may well prevent potentially highly valuable ICT initiatives from
getting approval.
There are several proprietary techniques developed by consultancy com-
panies working in this field. They fall in three major categories: purely
financial methods, qualitative methods and statistical methods. They are
laborious to implement and the chosen technique must fit the organisa-
tion’s culture and way of doing things. These methodologies include:
Applied Information Economics (AIE) http://www.hubbardresearch.

com developed by Hubbard Decision Research. Their website describes
AIE as a scientific and theoretically sound quantitative method for ad-
dressing the investment dilemmas of ICT by using a “Clarify, Measure,
Optimize” approach to assessing investment alternatives even when there
are “intangibles”.
AIE assigns units of measurement to intangibles such as customer satis-
faction and strategic alignment, then applies various tools from actuari-
al science, portfolio theory and statistics to calculate the value of infor-
mation.
The Balanced Scorecard (BSC) http://www.balancedscorecard.org/,
originally developed by R. Kaplan (of Harvard Business School) and D.
Norton in 1992, as a partly qualitative, partly quantitative management
and measurement system, the BSC provides descriptions of what compa-
nies should measure in order to balance a purely financial perspective.
BSC makes explicit direct links between business strategy and financial
performance by monitoring four areas of activity. Standard financial per-
formance indicators are balanced by measuring customer relationships,
operational excellence the organisation’s ability to learn and improve.
Total Economic Impact™ (TEI) http://www.forrester.com, originally
developed by the Giga Group, now part of Forrester Research, TEI brings
together costs, benefits, flexibility and risk analysis to demonstrate and
quantify the economic impact of an ICT implementation.
Economic Value Sourced (EVS) developed by the META Group, is based
on the principle that there are only four ways in which ICT creates value
for an organisation: by increasing revenue, improving productivity, de-
creasing cycle time and decreasing risk.
EVS extends the use of financial valuation tools as Economic Value Add-
ed (EVA), Internal Rate of Return (IRR) and Return on Investment (ROI)
to define the contribution of ICT in economic terms, including the value
of time and risk in the process. EVS practitioners advise that organisa-
tions take a risk-management approach to high-profile projects.
Portfolio management: This approach is designed to allow organisa-
tions to manage their ICT assets and projects as they would a portfolio of
other investments, with the CIO or another senior-level executive acting
as a fund manager. Howard Rubin (of Rubin Systems and the Meta Group)
stated that “The organisation has to be wired with the mind-set that tech-
nology is an investment that has to be worked as frequently as the finan-

cial markets”..
Looking at expected value, rather than focusing on cost, organisations
should manage its ICT portfolio, looking at the amount, size, age, perfor-
mance and risk of each investment.
Executive Dilemma: Quick spend
Government departments and other public service organisations operate

on the basis that the budget must be fully spent because their accounting
rules prevent them from carrying over funds to future years and believe
that having a budget surplus would lead to budget reductions in future.
A public service organisation had budgeted a substantial amount of mon-
ey for an infrastructure renewal project., This got delayed because of
changes to the requirements and also because the employees of the ven-
dor involved went on strike for two months.
The Chief Executive needs to find a way to get the organisation to spend
X million but do it wisely enough not to be criticised by their auditors for
having squandered the money. ICT is a convenient way to spend substan-
tial sums of money.
How do you ensure that these X million are spent sensibly rather than
wasted (as would be the case, for example, when replacing personal com-
puters that are only a year old and buying high resolution flat screens and
colour laser printers)?
The problem with ICT benefits
Twelve problems combine to make difficult the definition and assessment

of ICT benefits.
12. No post-implementation
benefit audits
11. No benefits 1. What is value?
without risk
2. Assigning value to information
10. Who is accountabile
for benefits? 3. Poor business - IT dialog
9. Benefits go outside 4. Technology is necessary

the IT function but not sufficient
8. Benefits are in the future 5. Technology alone does not
deliver benefits
7. Benefits are speculative
6. Benefits are conditional
Problem # 1: Knowing what value is in the Information Age

The traditional answer to how is value created? is …“through the value
chain”. This answer reflects the industrial age model of the production
line and may not be unsuitable for the Information Age. Besides, the con-
cept of a value chain does not fit well with much of the work of non-prof-
it and government organisations.
Traditional techniques for examining economic value look at transactions
around goods, services and revenue and leave out two important sourc-
es of value in the Information Age: knowledge and intangible value.
“Knowledge” is about exchanges of strategic information, planning, pro-
cesses and technology know-how, collaborative design, policy develop-
ment, communities of practice and other activities where most what of is
exchanged consists of information in electronic form and possibly docu-
ments.
“Intangible value” is about benefits that go beyond an actual service and
that are not accounted for in traditional financial measures – such as be-
longing to a community, enhanced reputation, happier and more moti-
vated employees. The fact that they are not accounted for does not mean
that such benefits are not real.
An extract of this section was published online by Darwinmag in September 2004

(www.darwinmag.com)
Problem # 2: Assigning value to information

Traditional accounting rarely includes data and information among re-
ported assets. This reflects the industrial age and it will become increas-
ingly important to assign value to the information held by all kinds or-
ganisations, as this takes a more important role in their activities.
There are situations where data and information are assigned a monetary
value that reflects its importance to those receiving it. News agencies have
practiced this for a long time. Some oil companies include in their bal-
ance sheets as assets survey data collected for future detailed exploration
and exploitation.
Another example is music in digital format. Traditionally, the price of a
disc included the physical carrier (CD, case, booklet). The emergence of
file sharing (Napster and Kazaa among others) violated intellectual prop-
erty and was challenged in the courts. This led to a new (and legal) mar-
ket for downloading music online. These downloads must be paid for.
More examples include online services (Britannica (the encyclopedia),
Oxford Analytica, Lexis-Nexis) all of whom charge for access to informa-
tion in electronic form. These charges reflect market pricing.
Problem # 3: There is a language problem between ICT and finance people
A further barrier to understanding the value of ICT investments arises
from the different perspectives and terminologies used by ICT people, fi-
nance and other executives.
ICT managers are content to concentrate on project schedules, technical
products, resources and budgets. This is met with incomprehension by
executives, particularly finance officers, concerned with cost, revenue,
cash flow, the cost of capital and overheads.
It is not unusual for the result to be a lack of understanding and communi-
cations that is prejudicial to the organisation. When dialog is ineffective,
executives will not have the ability to identify technology opportunities and
enhance business effectiveness. The ICT manager will be relegated to the
role of service provider with no strategic impact (and little credibility).
Problem # 4: ICT is necessary but not sufficient for business success
The word “business” is used in a generic way – commercial companies
operating for profit have no problem with this terminology while not-for-
profit, government and international organisations often feel this term is
inappropriate.
It is easy to use ICT to deal with pedestrian problems (document creation,

accounting and other structured tasks). This does not result in major ben-
efits. Focusing on these uses can turn an organisation into a pillar of salt
and an example of mediocrity or incompetence. However, it is hard to cre-
ate a new business model. The corporate graveyard is full of naïve people
who thought that it was easy to change a corporate culture.
Problem # 5: ICT does not deliver value (by itself)
Technology is neutral and can be put to good use, misused or abused.
Benefits will emerge when management and staff apply ICT to achieve
business effectiveness. This should be taken to mean conducting work
processes in a manner that leads to doing the right things and doing them
the right way. ICT can play a major role in both.
Problem # 6: The benefits of ICT are conditional
However good the technology and successful the project that puts it in
place, ICT will not deliver benefits unless other factors have been enabled
by executives:
• Managing the organisational change that ICT enables;
• Training staff and managers to exploit ICT;
• Enabling an appropriate level of creativity.
These are beyond the area of influence of the ICT function and the only
limit to what is possible is defined by an organisation’s management cul-
ture and ability to absorb change.
Vendors make benefits appear easy to achieve – colourful slides and slick
presentations describe the (nearly magical) things their technologies can
achieve. However, it is not the vendors’ business to care about their cli-
ents’ ability to derive benefits.
Problem #7: The benefits are unproven
Adopting ICT solutions and facilities that someone else has already suc-
cessfully implemented gives hope that it can be implemented successful-
ly (but the benefits remain conditional). Behaving as a follower or a lag-
gard rather than as a leader does reduce risk.
However, for those who wish to create a new business model or introduce in-
novation, can they know if this “new thing” will work? They cannot. If some-
thing is new and unproven there are risks: that the technology is immature,
that another vendor will come with a better product, that the vendor will aban-
don the product or go out of business, that a competitor will beat them to it.
There is no right answer, except perhaps the motto of the British special
operations unit, the Special Air Service: “who dares wins”. In other words,
when there is a choice, who wants to be a loser or work towards achiev-
ing mediocrity?
Problem # 8: The benefits of ICT are all in the future
This is true for most investments. ICT projects have relatively long lead
times (major projects are rarely completed within the originally estimat-
ed budget and timescale). Benefits will start to accrue when the informa-
tion systems and facilities are fully operational and everyone who uses
them is able to exploit them to good advantage. Until then, all you have
are expenditures…
Problem # 9: The benefits of ICT don’t go to those who invest
In budgetary terms, the major part of ICT expenditures is incurred by an
ICT function. If and when value is derived and benefits are gained, these
do not appear in the ICT function but elsewhere in the organisation. This
makes it difficult to put together an organisation-wide case for investing
in ICT unless there is good dialog and coordination with the potential
beneficiaries of the investments.
Experience shows that benefits do not emerge immediately after imple-
mentation. There are many instances where massive but unexpected ben-
efits emerged five or more years after the implementation of a computer
system. However this was the case only when the people working with
the system were allowed to think creatively about its potential.
In the early 1990s, the Swiss state pension organisation (AVS) embarked on an ambitious
ICT project. This project aimed at a total migration from working with paper documents
(the offices had several floors of filing systems) to working with stored images of all the
documents and no paper.
This was a major project that took several years to complete. The benefits that had been
identified for this system concentrated on the office space that would be liberated and the
improved ability to track the status of all the transactions in progress.
Several years after its implementation, other benefits became apparent, notably a reduc-
tion in personnel absences due to sickness, presumably the result of not having to work
with old, dusty and mouldy paper documents.
It was subsequently discovered that the personnel found the use of the system and the
workflow processes with other colleagues a much more stimulating work environment
than dealing with large stacks of pending paperwork and were much more motivated than
in the past.
Problem #10: Who is accountable for benefits?

A proposal for investment that does not have an owner prepared to to be
accountable for the benefits to be gained should be considered as weak,
if not suspect. It is not sufficient for a project sponsor to say that “we sim-
ply must have this or we will go out of business” and expect it to be ac-
cepted in place of a business case. It is true that benefits are conditional,
in the future and speculative, but this should not be an excuse.
While benefits may be uncertain, this uncertainty can be bounded with
lower and upper limits (a discussion of this approach can be found in the
book Waltzing with bears):
If the sponsor cannot estimate benefits in a range from worst and best
case, there is too much uncertainty and the investment becomes a gam-
ble.
However, it should not
Probability
difficult to identify
what the worst case
might be – if it is zero
benefits then the proj-
ect is doubtful in the
first place. The most
likely outcome – the Worst case Best case
peak in the curve
should have a proba-
Size of benefits ($, €, £, ¥…)
bility of at least 25% to
be achieved for a real-
istic investment.
Problem #11: Uncomfortable correlations
Research in information economics over the last twenty years has iden-
tified two facts:
#11a. There is a strong correlation between reward and risk
There are several successful case studies of “wise use of ICT” to create
new business models. All of these involved considerable investments and
high risk.
Waltzing with bears, by Tom DeMarco and Timothy Lister, 2003, Dorset House
Publishing
Online book (and more) retailer. While there are

Amazon.com other online book retailers, Amazon is a leader and
its ICT is innovative.
Online auction house. It now operates internation-
ally and has been innovative in not only online auc-
e-Bay
tion procedures but also in payments in partnership
with PayPal.
Initially an innovative and fast search engine, Google
Google developed an original advertising model that has be-
come very profitable.
UK chain of supermarkets with e-services ranging
Tesco from customer loyalty schemes (to support data
mining) to online shopping for groceries.
Online operation for private customers – computers
Dell are specified online and made to order. Dominant
player in the personal computer market
Federal Express First to introduce online tracking of consignments
The conditionality discussed in Problem #6 is critical to success and is

not related to technology.
#11b. There is a low correlation between ICT expenditures and busi-
ness results
This is the basic premise of the book “The Squandered Computer” by Paul
Strassman, first published in 1998, validated since by other researchers
and authors.
The decisions and actions needed to gain maximum value out of ICT in-
vestments are organisationally difficult to implement because they re-
quire changes to the status-quo, a political activity that potential “win-
ners” will support and “losers” will oppose.
For many people ICT is fascinating, even addictive. This is evidenced by
the way glossy magazines, akin to fashion magazines, present options for
add-on gadgets (flat panel screens, DVD players and recorders, sound
cards, wireless mouse and keyboard, video cameras, high resolution co-
lour printers) which may be great toys in the home but would not neces-
sarily contribute to business value. The opposite is often true as they be-
come distractions from the main purpose of an organisation.
ICT managers who like technology are likely to encourage their organi-
sation to indulge in the latest gadget – their individual price is usually
small and it is only when a large number of them needs to be supported
that costs are noticed.
Problem # 12: Lack of post-implementation benefit audits
The time elapsed between presenting a business case to invest in ICT, im-
plementation and subsequent digestion by an organisation is long, mea-
sured in years for any sophisticated system.
After all the money has been spent, it is good practice to validate wheth-
er the benefits that were claimed to justify the investment in the original
business case have actually been achieved, if only to serve as a “lessons
learned” exercise.
When such post-implementation benefits audits are conducted, they tend
to reveal that many benefits were not thought of at the time of preparing
the business case. However, researchers in the USA have found that less
than half the organisations making major ICT investments conduct such
benefit audits.
These emerge when the people
using these systems are allowed
to use their knowledge and expe-
rience to make creative use of the
systems’ capabilities, particular-
ly when these support knowledge
work or can be applied to areas
not initially considered.
Another Executive Dilemma: Technology

migration and technology opportunity
It’s generally accepted that information technologies evolve quickly and

that the ICT industry thrives on obsolescence. A major manufacturing
organisation has a mature, well maintained centralised inventory system
for all of their materials covering all of their plants at several world-
wide.
This system is used primarily by the foremen and procurement people at

the various plants who are “experts” in the use of the system and well
versed in the way in which information can be extracted and reports cre-
ated.
However, the system is now over 20 years old and runs on a mainframe.
The user interface is user-hostile. The annual running costs for this sys-
tem are in the order of 15 million dollars a year.
The Chief Operations Manager at headquarters has been receiving invi-
tations from vendors to be shown the latest architectures for a potential
replacement system – an “integrated and seamless web-enabled Linux-
based enterprise server” (this kind of terminology is typical). The pro-
curement cost of such a system is initially estimated at 40 million dol-
lars.
The Chief Operations Manager decides to raise this possibility with the
Chief Finance Officer and the Chief Executive – and they raised many
questions he did not expect:
• What are the business benefits of changing architectures and systems
now?
• What happens if we wait another couple of years?
• Should we wait for the next technological miracle before migrating?
• Are we capable of integrating these new technologies and methods
of work into our current framework and operations?
At roughly the same time, the marketing manager was enthused by the
latest set of products for Customer Relationship Management – a system
that would allow the company to integrate all of their customer data, in-
cluding volume of business, trends, prices paid, contracts in place, key
contacts and much more into a single system.
Moreover this system would facilitate a proactive approach to client rela-
tionships – and because the system was so new, it would give them a first
mover advantage – to be one step ahead of the competition.
The price of the new system: the vendor estimated it could be done for 7
million dollars, but the internal costs of migrating all the customer data
and populating the databases of the new system was not included in this
price.
One small wrinkle: the system was so new that there were only two in-
stallations of it in use and these were in another country.
What should the Chief Executive do? Here are some questions to consid-
er:
• What are the risks of being a first mover?
• Would the benefits of the new CRM system be large enough to take
these risks?
• What would be the consequences if their main competitor succeeds
in installing such a system before they do?
• Are there any alternatives to this particular product – and if so, have
then been explored?
Action points
Do not accept “intangible benefits” as an excuse for not developing a busi-

ness case for investments in ICT.
Similarly, do not accept statements such as:
• This project is aligned with our business objectives – without being
specific of what this alignment consists of;
• This is a long term investment – which means that there will be no
significant impact in the forseeable future and that by then the exec-
utives would have forgotten who the project champion was…;
• This project is part of corporate activity consolidation or equivalent
consultant-speak which actually means very little (if anything);
• This project will lead to optimum resource performance which could
mean that we shall know what we get out of this investment after we
have completed it.
Recognise that there are no benefits without risk and that their specula-
tive nature requires an act of faith on the part of the executive. Validate
these acts of faith by conducting post-implementation benefit audits.
Be suspicious of proposals that do not put boundaries (worst case, best
case, most likely outcome) on benefits. They may imply that the uncer-
tainty is too high or that the sponsor has not thought enough about the
business case.
C h a p t e r
7
ICT strategies
that work
What is the use of running if you are not

on the right road?
Claimed to be a German proverb

• What is the purpose of an ICT strategy, and is it important to have

one?
• What is needed for a strategy to be implemented successfully and sup-
port business results?
• What should an ICT strategy contain?
There are three possible approaches to planning its deployment

• Improvise as you go along
• An IKIWISI approach (I’ll know it when I see it)
• Develop a strategy that can be discussed and communicated, as well as revised in the
light of experience
Given the impact that ICT can have on the activities of an organisation, the sums of mon-
ey involved and the irreversible dependency that ICT creates, the last of the three is the one
that makes most sense.
If only this was enough to have a strategy that works! Assuming that the strategy is well
aligned with the business objectives of the organisation, without effective governance of
ICT and successful execution, even the best strategy will not succeed.
Governance is the responsibility of executives and should not be abdicated to the ICT func-
tion. Execution is discussed in the chapters that follow.
Setting the scene for an ICT strategy
Organisations carry out two sets of activities to meet their business ob-
jectives:
Tactical activities, to do with action and the execution of business pro-
cesses through operations, risk management and compliance with poli-
cies, regulations and legislation.
Strategic activities are focused on preparing for “tomorrow”, i.e. planning,
defining priorities, risk assessment and alignment.
A workable strategy requires asking many questions that have uncertain
answers because of the non-linear, unpredictable nature of our world.
Therefore, a strategy should be seen as the equivalent of a rough and in-
complete map of uncharted territory.
If only this was enough to have a strategy that works! Assuming that the
strategy is well aligned with the business objectives of the organisation,
without effective governance of ICT and successful execution, even the
best strategy will not succeed. Dogmatic assumptions about what can and
cannot be changed, inflexible plans and rigid budgets also work against
having an effective strategy.
The role and importance of an ICT strategy
An ICT strategy is different from a technical strategy. The latter deals

with architectures, products and computer room practices. While impor-
tant in its own right, this is the domain of the Chief Information Officer
and/or the service providers responsible for delivery.
An ICT strategy should support the objectives of a business strategy. Busi-
ness strategies consist of a mixture of four distinct business “games”:
• Cost reduction – for example through forced budget cuts or outsourc-
ing;
• Process redesign and re-engineering, adoption of Total Quality Man-
agement;
• Restructuring – as a result of acquisitions, mergers, divestitures or
leveraged buy-outs;
• Creativity – by focusing on differentiation, new products and new
services.
ICT has a part to play in all of them, but in quite different ways:
In process redesign and re-engineering mode, ICT would provide new
systems that reflect modified workflows and increased automation.
In restructuring, ICT undergoes major
changes. Following an acquisition or a
merger, it is necessary to integrate the best
features and data of the systems of the par-
ties involved – invariably a major and com-
plex project that must succeed to allow the
new structure to operate effectively.
(artwork by Gennady Obuchov)

In creative mode, the most challenging, ICT plays the role of enabler, cre-
ator and change driver by creating awareness of opportunities with a sig-
nificant technology content.
By making explicit the mix of business objectives the relationship be-
tween the business strategy and the ICT strategy can be seen as the equiv-
alent of a couple dancing tango: they are close and move in harmony –
both partners can initiate moves but one partner (business strategy)
leads.
Getting to grips with an ICT strategy
Q.1: What exactly is an ICT strategy?

A.1: It is a collection of policies and activities designed to reach defined
targets from a given starting point or baseline.
Q.2: Is an ICT strategy really necessary?
A.2: It is good to recall the Japanese proverb that “a vision without action
is only a daydream while action without a vision is a nightmare”.
However, not every organisation has an explicit ICT strategy. Some of
them rely on IKIWISI (I’ll know it when I see it) which, with luck, might
work. Others say that as technology changes all the time and expendi-
tures in ICT are inevitable (the “cost of doing business”), why bother to
go through the effort and expense of establishing a strategy?
Others engage consultants (Q.4) to produce a strategy which may be im-
plemented or perhaps only partly implemented. This allows the organi-
sation to say to its stakeholders that “of course we have an ICT strate-
gy”.
Q.3: If an ICT strategy is worth having, what should its purpose be?
A.3: The answer needs to take into account three facts about ICT:
Fact # 1: ICT can have a major impact on an organisation, its activities
and its people.
Fact # 2: ICT demands substantial sums of money.
Fact # 3: ICT investments and operations bring with them change and
risk.
Therefore the purpose of an effective ICT strategy is to document and

share the balancing act of meeting business objectives by investing in ICT
while maintaining an ability to function with acceptable levels of risk (in-
herent in the strategy) and friction (resulting from changes to the status-
quo).
Q. 4: Why not get a consultant to prepare an ICT strategy?
Consultants can bring to bear experience, methodologies and insights to
help prepare a strategy. The emphasis should be on the “help”, not on
“prepare”. Consultants will leave behind a well drafted report and move
to another assignment. They will not be responsible for the implementa-
tion of the strategy nor for its results.
Factors that make an ICT strategy successful
Putting together an ICT

Governance
strategy is a manageable and
interesting task. However,
having compiled a strategy,
publishing it and getting
Ef
ct
pa
praise for it, is not sufficient

fi
cie
Im
for its successful implemen-

nc
tation, one that will result in

y
Strategy
observable business benefits.
This will only occur if three
factors converge for this pur-
Alignment Execution pose: good execution, good
Effectiveness
alignment and good gover-
nance.
Only the first, execution, is the responsibility of the ICT function and re-
lated service providers. The other two require executive participation.
Alignment is the process through which investments in ICT are made in
areas that deliver business value. In the tango dancers analogy, alignment
represents how well the dancers match each other’s steps.
Governance is the process through which those who define policy guide
those who follow policy. Returning to the tango dancers, governance is
the process of choosing the tunes for the dancers to dance to.
Execution, the ways in which the components of the strategy are deliv-
ered to the organisation and its people. In the analogy this represents the
dancers’ ability and experience.
A valuable executive guide to strategic planning can be found in the CO-
BIT Guidelines, presented in Chapter 2.
Alignment considerations
Doing what adds value cannot be achieved without understanding:
• The strategic business objectives of the organisation;
• The baseline upon which the strategy will be developed;
• The technical, financial, organisational and cultural constraints of
the environment for which the strategy is designed;
• How the organisation determines and measures the value associated
with data and information;
This understanding must be fostered and guided by business executives.
The CIO Chief Information Officer (CIO) alone cannot be an effective
judge of what ICT investments will provide benefits and opportunities to
the organisation as a whole.
Critical Success Factors (CSF) and Key Performance Indicators (KPI)
should be used to validate alignment issues. Such CSFs and KPIs will be
specific for each organisation.
Examples of Critical Success Factors for alignment
The strategy:
1. Focuses on using ICT to enhance the organisation’s operations and
management and support its business objectives (from cost reduc-
tions to developing of new products or services);
2. Focuses on providing information resources and capabilities to meet
the identified and emerging needs of the organisation;
3. Is integrated with the organisation’s governance and leadership
mechanisms;
4. Includes policies to ensure that the organisation’s employees and oth-
ers who use the ICT systems and facilities make effective use of the
information resources provided.
Performance Indicators
These are used to monitor the effectiveness of a strategy. The following

are typical examples:
a. Increased usefulness of management information;
b. Improved stakeholder satisfaction (internal and external stakehold-
ers);
c. Increased ICT initiatives for business process improvement;
d. Improved cost-efficiency of ICT processes;
e. Improved staff morale and productivity;
Governance considerations
As in the case of alignment, granting full autonomy to the CIO for choic-
es and decisions that have major impact on an organisation gives the CIO
power that could be misused when there is a lack of executive awareness
of the potential consequences.
The practices that make ICT governance effective, include:
• Approval of strategic, business and operating plans for ICT
• Oversight of the organisation’s information assets portfolio;
• Evaluation of benefits and identification of who will be accountable
for delivering them;
• Approval of funding that enables the ICT strategy and its components
to be delivered;
• Enterprise-wide standards for technologies and applications and def-
inition of the limits of business units, departments and geographi-
cally dispersed units autonomy on ICT matters;
• Criteria for the use of outsourcing and the extent to which it is
used;
• Accountabilities for content and information management (quality,
editorial policy, definition of access rights and conditions, etc), tech-
nology assessment, cross-organisation coordination, development of
detailed policies;
• Appropriate use policies that define how the organisation’s ICT re-
sources may be used for purposes other than those directly related to
work activities (examples: personal use of e-mail, Internet access,
telephones);
• Information security policies covering the availability, confidential-
ity and integrity of the organisation’s data, documents and informa-
tion;
• Arrangements for monitoring for compliance with policies;

• Training programs to ensure that managers and staff have appropri-
ate knowledge of ICT tools and techniques to extract value from the
organisation’s data and information as well as awareness of relevant
policies;
Governance must be focused on the use of power – the ability to change
the status-quo – and not on politics - the acquisition of power.
When executives delegate governance responsibilities, the ICT gover-
nance body ends up as a large committee of limited authority. This ar-
rangement does not work because effective governance needs to decide
on what is best for the organisation and challenge the belief that certain
things cannot be changed.
Execution considerations
Execution must match the quality needs of the organisation for the de-
livery of ICT projects and operational services. Chapter 5 has shown that
a higher quality than necessary has important financial implications.
Conversely, when service quality is insufficient the result will be a degree
of inconvenience, even paralysis. For anyone engaged in e-business (eBay,
Amazon, Dell, etc.) this could be disastrous.
What is “good enough” will be different from one organisation to anoth-
er and needs to be given careful consideration.
Prerequisites and minimum contents of an ICT

strategy
There are no standards or best practices for the contents of an ICT Strat-
egy. What works well is the production of a concise document, built in-
crementally and revised on a regular basis. The minimum contents of an
ICT strategy are:
• Objectives linked to business strategy and targets;
• The baseline including known constraints and legacies;
• Assessment of the technical and business risks of the strategy;
• Assumptions underlying the strategy
• ICT initiatives and their relation to a portfolio of information assets
• Technical architectures and standards
• Sourcing
• Estimated cost of implementing the strategy (± 30% or other avail-
able figure)
• Description of expected benefits (± 30 to 50%)
• Critical Success Factors for the strategy
Targets and objectives linked to business strategy
A concise description of the purpose of proposed changes to information

systems and facilities indicating how these link to the overall business
strategy and the role these changes will play in achieving specific busi-
ness targets and objectives.
Ideally, each of the proposed changes and their related projects should
have a sponsor (or owner or champion – the terminology varies from one
place to another).
The baseline including known constraints and legacies
ICT strategies begin with a history: over the years, organisations have
built computer systems, data definitions, databases, on a variety of tech-
nical platforms. Each of them implies constraints and legacies.
Data definitions and database technologies can be migrated to new tech-
nical architectures through conversion, cleansing and other complex pro-
cesses. This often turns out to be an implementation obstacle and the
source of unplanned expenditures. Lack of knowledge of how these lega-
cies will affect the implementation of new systems is a major handicap.
The organisation’s culture and the availability of skills are non-technical
constraints to the implementation of a strategy. Resistance to change is
natural and should be expected and if the magnitude of change leads to
major changes (relocation, downsizing, the need for new skills), these
constraints need to be addressed at an early stage to avoid significant fric-
tion and other problems later on.
Assessment of the technical and business risks of the strategy
Given that there is no reward without risk, strategic decisions involving

ICT should be made after considering the risks and rewards of what is
being proposed. Risks fall in two categories:
Technical risks: These revolve around not knowing the answers to:
• Will the proposed project work?

• Will the vendor remain in business long enough to support the proj-
ect or product?
• Do we have the expertise required to implement and support this
project?
• Will the new technologies be compatible with what we already
have?
Business risks:
• Is the project truly aligned with the organisation’s needs and priori-
ties?
• Is the organisation capable of absorbing the changes that will re-
sult?
Assumptions underlying the strategy
A strategy must make explicit what the organisation “knows it does not
know” – the assumptions made in preparing the ICT strategy. Executives
should question and discuss these assumptions before committing funds
to the implementation of the strategy. Checking the validity of these as-
sumptions is part of the risk assessment and management process.
Portfolio of initiatives and how these relate to an existing portfolio of in-

formation assets
A well structured ICT strategy will group the proposed initiatives in a

number of categories, focusing on specific targets and objectives – the
following categories are typical of an ICT strategy for the early 2000s:
1. Knowledge work
This provide a perspective of the role of knowledge work in the organisa-
tion by defining how ICT will be used to allow an organisation to exploit
data and information to support business intelligence, decision support,
data mining and discovery, executive information and similar activi-
ties.
2. Process support and automation

The processes of an organisation could be grouped in a number of cate-
gories, for example:
• Mission-related processes (directly related to the organisation’s line
of business)
• Logistics support (procurement, supply chain, distribution, publica-
tion, etc.)
• Administrative support (finance and accounting, HR, etc.)
The strategy should highlight the major changes envisaged and their ra-
tionale. This section should indicate the percentage of the ICT expendi-
ture proposed for each category with appropriate explanations if these
expenditures are upside down (more on administration than on systems
related to the mission of the organisation).
3. Information Sharing and Web presence
Discussion of the proposed future use of mechanisms to share informa-
tion internally (the workforce and management) and externally (clients,
suppliers, vendors). This includes the organisation’s presence on the
World Wide Web, Intranets and Extranets. This section should also clar-
ify the ownership issues of information on the organisation’s Websites
and Intranet, including editorial controls and quality assurance.
4. Data, Documents and Information: Quality and Security
Increased emphasis on data and information places demands on the or-
ganisation to ensure that these are of appropriate quality, that they can
be accessed only by those authorised to do so, and created and modified
only with appropriate controls and authorities.
This is becoming increasingly important because of legal requirements
and increases in cybercrime and fraud. The strategy should make it clear
who is accountable for delivering the relevant policies and address com-
pliance issues.
5. Dispersed business units, global networking and country offices
Networking is critical in the operational infrastructure of most large or-
ganisations as it brings together regional offices and dispersed business
units into a knowledge network. Clear policies concerning autonomy and
accountability for ICT, development, deployment, training, support, ar-
chitectures and connectivity are a critical part of an ICT strategy.
6. ICT components of emergency response - including Business Continu-

ity
The concept of “emergency response” deals with the organisation’s abil-
ity to continue to operate if affected by an event that seriously disrupts
its operations (natural disasters, disruption to utilities such as power sup-
ply, terrorism, civil disorder at any of the organisation’s locations).
This is dealt with through comprehensive, documented and tested ar-
rangements for disaster recovery and business continuity – the strategy
should focus on the ICT component of these.
7. Technical architectures and standards
The promulgation of enterprise-wide technical architectures and stan-
dards for operating systems, applications software, configuration and
change control practices and other related items. These have a major im-
pact in the Total Cost of Ownership of ICT.
8. Resourcing operational work
When technology support is needed 24 hours a day, 7 days a week, with
disaster recovery arrangements that actually work and business continu-
ity/ crisis management plans, the strategy should review the future or-
ganisation of the ICT function and explore possible changes in structure,
staff numbers, skills profiles and the scope for hybrid arrangements mix-
ing staff, contractors and outsourcing.
9. Capacity building, awareness and training programs
The measures that an organisation deploys to ensure that the workforce
and management have the necessary skills to exploit the tools, systems
and facilities delivered through ICT. These should include the mecha-
nisms that ensure adequate awareness of ICT related policies, in partic-
ular appropriate use, privacy and confidentiality and security.
The strategy should make it clear who in the organisation is accountable
for these activities.
10. Estimated cost of implementing the strategy (± 30% or other available
figure)
Estimating the cost of future ICT implementations is fraught with inac-
curacies and unknowns, but an uncosted strategy has little business val-
ue and is little more than a wish list. Plausible estimates are important
and can be improved as decisions on implementation priorities ap-

proach.
It is prudent to validate such cost estimates through the use of ICT advi-
sory services or informal contacts with executives in other organisations.
This is only possible if the proposed implementation is not the first of its
kind, in which case the final cost will only be known after the project is
completed…
11. Description of expected benefits (± 30 to 50%)
A strategy that does not attempt to put value on the expected benefits
should be regarded as a catalog of opportunities and an invitation to gam-
ble on the outcome of investing in such opportunities.
The more speculative the proposed investment the more likely that the
estimate of the benefits will be an act of faith, but this is true for most ICT
investments. Notwithstanding, benefits should be estimated to the same
level of accuracy as costs, indicating boundaries such as worst case, best
case and most likely outcome.
12. Critical Success Factors for the strategy
The most important CSF is executive commitment to the ICT strategy.
It is not reasonable to expect that the Chief Information Officer and the
ICT function (or outsourcers) should decide on investment priorities,
their timing and also manage the impact these projects and investments
will have on the organisation, its personnel, clients, vendors and other
stakeholders.
Executive Dilemma
A well known international not-for-profit organisation engaged a consul-

tancy company to help them develop an ICT strategy. The consultant’s
report that resulted was, as expected, a well drafted professional docu-
ment which outlined a strategy that would cost close to 100 million US
dollars over a period of two years.
The report also clearly and critically described the starting point for this
strategy, albeit in delicately phrased and with statements hidden in their
lengthy report, among them:
• The fast track approach will bring disruption and budget constraints,
and there is a general lack of trust within the organisation that the
CIO can roll out effective ICT systems and on the availability of com-
petent staff to work with the new systems.
• To increase data-quality and integrity, reduce maintenance costs and
improve security, the organisation needs to abandon the present dif-
fused and uncoordinated computing and database configuration.
• There are too many applications developed by individual offices and
headquarters units, to compensate for shortcomings of existing cor-
porate systems. These software applications have been developed
over the last 10 years. Generally they have inadequate functionality,
are poorly integrated and are showing serious signs of reaching the
end of their economic and/or technical life.
• Across its network of offices, the organisation has 16 different cor-
porate systems for its resource management functions. Each of these
systems has its own history and constituency.
Would you approve the expenditure and proceed with this strategy?
NB – this dilemma is based on a real case. Three years on, the strategy is
still being implemented. One of the central components of this strategy
was an Enterprise Resource Management System using one of the major
ERP software packages. It emerged that knowledge about the strategy did
not reach everyone, as one business unit implemented their own (differ-
ent and incompatible) solution at a cost of 5 million US dollars.
As a senior executive what lessons can you draw from this situation?
Action Points
Ensure that the business objectives of your organisation are known and
understood by those responsible for ICT strategy.
Strengthen ICT governance mechanisms to enable ICT to deliver the ap-
propriate quality of projects and services with acceptable track record and
costs.
Focus the work of the ICT governance body on alignment and value issues.
Demand that ICT strategies be regularly updated and that they reflect the
input of all constitutent parts of the organisation.
C h a p t e r
8
ICT service delivery
processes:
resources, quality
and risk
If it looks simple, it is because you have

not looked close enough.
• Are ICT processes different from other processes?

• What are the typical processes that support ICT activities?
• Is process management an art or a science?
• What are the risks associated with ICT service delivery processes
ICT, like most critical infrastructures - electricity, water, telephone – becomes invisible
when everything works as intended. Disruptions to services are noticed immediately and
cause, as a minimum considerable inconvenience.
Ensuring that ICT service delivery provides a consistent level of quality requires discipline.
How much structure and discipline is required for a given organisation is determined by the
potential impact of service delivery disruptions on the operations of the organisation.
When ICT services become unavailable (downtime) organisations incur losses because of
their inability to operate. Surveys conducted in the United States identified that such loss-
es range from the tens of thousands of US dollars an hour (46% of respondents) to over
one million US dollars an hour (8% of respondents) and it is therefore not a trivial matter.
There are many best practices that can be used to manage service delivery and not putting
them into practice is a self-defeating game.
Definition and importance of processes
A process is a sequence of operations or events intended to deliver an ex-

pected outcome. Processes can be natural such as having a baby or be de-
signed, this chapter discusses designed processes.
A process may consist of a number of procedures. Procedures are activi-
ties, tasks, steps, calculations and decisions that produce a desired result
when executed in the proper sequence. Procedures deliver repeatable re-
sults if input conditions don’t change.
Process Management is the application of knowledge, skills and tools to
define, measure, control and improve processes to meet requirements in
an effective and efficient manner.
When ICT plays a critical role, services quality should be good enough
for an organisation to perform its business. Poorly managed ICT service
delivery processes may prove catastrophic in the operation of critical in-
frastructures, continuous and automated manufacturing, financial ser-
vices and e-business. Even if not catastrophic, the reputation of an organ-

isation could suffer if incidents affecting their ICT operations become
public knowledge because of fraud, sabotage or hacker attacks.
Responsibility for the implementation and management of ICT service
delivery processes rests with the Chief Information Officer regardless of
whether the services are conducted in-house or outsourced to a third par-
ty.
Are ICT processes different from non-ICT processes?

The best answer is “definitely maybe”. ICT processes combine technical
matters, contracts with several parties, managing people and other or-
ganisational issues including politics. There are at least four factors that
conspire to make them different:
Skills: Many people believe that they “know about ICT” because they
know how to use a personal computer and have some familiarity with
how it works. This is a dangerous delusion that encourages a belief that
everything in ICT is “simple” and that anyone can do it. It also creates a
belief that it can be done “quickly”. This may be true for a small network
but is not the case for corporate or enterprise-wide ICT.
Size, scale and complexity: These combine to become the enemy of man-
ageability. It is not uncommon to find wireless networks (using WiFi) in
many homes connecting two or three computers on this network. This is
no big deal (until things stop working).
Managing a corporate network with hundreds or thousands of comput-
ers is quite a different story and the consequences of not doing it well can
be very disruptive. Virus infections, for example, have shut down corpo-
rate networks, including those of some banks, for several days.
Rate of desired change: in ICT processes, changes are required all the time.
Rapid change and responding to expectations require a strong manage-
ment discipline to maintain the outputs at the right level of quality.
Timescales: in the world of ICT these are always expected to be short. Data
centre activities such as backups usually take place in the middle of night
to avoid causing disruption to day-to-day activities. The resolution of op-
erational incidents such as e-mail problems is expected to be instanta-
neous.
The number of processes involved in the management of ICT is large. For
example, the Control Objectives for Information Technology (COBIT)
guidelines propose 34 processes with over 384 functional recommenda-

tions. The four categories of processes covered by COBIT are presented at
the end of Chapter 2.
There are other guidelines for ICT processes, notably the Information
Technology Infrastructure Library (ITIL), initially produced in the late
1980s by the UK Government’s Central Computing and Telecommunica-
tions Agency. Maintained up to date and available as a series of modest-
ly priced books, they contain tried and tested recommendations for ICT
operational practices.
Both COBIT and the ITIL are conceived to minimise risk to the organi-
sation. Typical enterprise risks associated with ICT processes of insuffi-
cient maturity or quality include:
• Activities supposed to happen every day, such as data backups are
not carried out systematically and the backups may not be there when
needed;
• Hackers or other malicious characters penetrate a network to corrupt
or steal data;
• A lack of knowledge of the threats and vulnerabilities in service de-
livery processes that result in inadequate protective measures (see
also Chapter 10);
The art and science of Process Management
Just as it is generally accepted that electrical power and the telephone’s

dial tone are there every time they are needed, people using ICT should
not be concerned with what is behind their computer screen.
However, the need for high performance in ICT – systems and networks
that work all the time, effective protection against virus and worm soft-
ware, responsive and knowledgeable help desks, etc., has become ines-
capable. Downtime brings everyone out screaming immediately.
A visit to a Help Desk will reveal that problems occur all the time. Some
problems are quickly resolved but others can shut down networks and
desktops for considerable periods of time. This was the case when the
Produced by the UK government and obtainable from http://www.ogc.gov.uk/index.

asp?id=2261
worms Nimda, Blaster and SobigF infected thousands of networks world-

wide in a very short of time. Restoring things to normal requires a thor-
ough cleanup of every infected computer.
As the figure shows, the service delivery organisation may be an in-house
group and/or a provider of outsourced services. On one side of the service
delivery organisation are the end users, with whom there may be a for-
mal service delivery agreement (also known as Service Level Agreement).
On the other side are the vendors and service providers on whom the de-
livery of services depends. Good processes help to eliminate systematic
problems and also to contain the effects of problems when these arise by
identifying what needs to be done, by whom and how.
Service Agreements
It is good practice in service delivery to use formal service agreements to

define the terms and conditions under which services will be provided.
The complexity and legal strengths of such agreements are greater when
dealing with a commercial service provider than when dealing with an
in-house service provider.
Such agreements are designed to define the roles and responsibilities of
all the parties entering into the agreement (those using ICT and their ser-
vice providers), the financial arrangements for service provision (paid
for from a central budget, charged to user departments) and the mecha-
nisms for reviewing performance and amending the terms of the agree-
ment. It is usual to include sections on penalties and other arrangements
when the agreed service levels failed to be delivered.
Performance criteria include measurable parameters such as service
availability, response time and where it is measured, the definition of
maintenance windows and problem resolution targets.
These definitions should be unambiguous: a service availability of 99.8%
is quite a different matter in each of the following:
• Monday to Friday, prime
time (08:00 to 18:00)
• Seven days a week, over
two consecutive work-
ing shifts (08:00 to
24:00)
• Seven days a week, twen-
ty-four hours a day
In-house service providers
will have budgetary con-
straints and if required to deliver high quality without adequate funding
will end up diverting resources from other activities such as end user sup-
port or, most frequently, innovation and development.
Outsourcing service providers work within a contractually agreed frame-
work and changes to specifications are treated as amendments to the con-
tract.
Performance assessment
Processes, by being structured, are measurable. Executives should see

this as an opportunity to determine how ICT processes contribute to busi-
ness value, the extent to which they represent appropriate quality and
value for money and assess the organisation’s exposure to risk.
The most common techniques used for performance assessments are au-
dits and benchmarks. As discussed in Chapter 2, audits fall in various
categories:
• Management audit to determine process compliance with the COBIT

guidelines, process maturity and the degree to which key perfor-
mance indicators are used;
• In-depth management audits using the guidelines of the Institute of
Internal Auditors or equivalent professional body;
• Audits based on compliance with the international standards for To-
tal Quality Management (ISO 9001) and the Code of Practice for the
Management of Information Security (ISO 17799);
• Audits for compliance with specific national legislation, ranging for
example from the U.K.’s Health and Safety at work act to the USA’s
Sarbanes-Oxley Act;
• Investigations, including digital forensics (the equivalent of criminal
investigations in the electronic world), in the event of suspected fraud
or other criminal offence committed using ICT.
Benchmarks use comparative data compiled by any of a number of spe-
cialist services on the cost performance of specific ICT processes and ac-
tivities to determine if a particular service is delivering value for money.
The use of benchmarks encourages the ICT organisation to be cost con-
scious and to actively manage the cost of service provision. Without
benchmarking this may not always be the case…
Without formal and regular performance assessments, it is possible that
an organisation is spending more than it needs to in ICT without a worth-
while return on such expenditures.
Service delivery processes and their risks
The Information Technology Infrastructure Library mentioned earlier

discusses best practices for the processes considered most important for
service delivery. Here, the processes are listed in terms of their visibility
to end users.
The help desk should be the first point of contact for the resolution of in-
cidents with ICT services. A help desk would normally use a computer
system to record information on all incidents reported, who reported
them, how it was resolved and other such details.
Linked to an inventory system, this information can be analysed to pro-
vide insights into the most commonly reported incidents and point to
Help desk
Incident and problem management
Security management
Contingency planning
Software control
Change management
Service level management
Contract and cost management
Availability management
Storage and media management
Capacity management
software errors and faulty equipment as recurrent causes, indicate who

are the most frequent callers (this can indicate users who may not have
the skills to use the systems and facilities provided to them) and other
valuable management information.
Such reports are most valuable when shared with executives as some of
the remedial actions required may be outside the sphere of influence of
the ICT function.
The main risks associated with help desk processes of insufficient matu-
rity are:
• The inability to measure the performance of ICT as seen by those us-
ing the services and the lack of management awareness of the quali-
ty of service delivered to the organisation;
• The emergence of unofficial centres of end user support that bypass
the help desk. This peer support reduces the productivity of the peo-
ple involved, as this is not their job responsibility (however, formal-
ly assigning “experts” to business units and departments to provide
immediate support, combined with appropriate training and a pro-
active approach can work well).
Problem management is the process through which diagnosed, known or
reported incidents are dealt with. Repeated incidents that have the same
underlying cause become problems.
The risks of inadequate incident and problem management processes
are:
• Incidents that are unsatisfactorily resolved, in terms of accuracy of
solution and speed of dealing with the problem, result in consider-
able time loss to end users and lost productivity to the organisation;
• The inability to solve problems affecting critical systems and facili-

ties can prevent an organisation from conducting its business activ-
ities and need the invocation of contingency plans (discussed in a
separate chapter).
For example technical problems affecting an ambulance dispatching sys-
tem can have serious consequences, including loss of life if the problem
persists beyond a certain time limit (as was the case in the early 1990s
with the London Ambulance Service). Such time limits need to be defined
on a case-by-case basis and are one of the triggers for invoking a contin-
gency plan.
Security management implements an organisation’s security policies and
practices and its functions include the management of access rights to
computer systems and facilities, monitor compliance with security poli-
cies and maintain vigilance with regards to the potential misuse and
abuse of corporate information assets.
The main risks of inadequate security management are
• The abuse of access rights, data modification, fraud, introduction of
malicious software and sabotage.
• Lack of compliance with specific national legislation (like the EU
Data Protection Directive). Such failures may have repercusions with
regulatory bodies.
Contingency planning is the preparation, development, documentation
and testing of ICT capabilities that can be invoked in the event major
problems occur to provide an adequate level of functionality. The result
of such contingency planning is a Disaster Recovery plan for ICT systems
and facilities. How such a plan is designed is discussed in Chapter 13.
Senior management must actively participate in contingency planning,
disaster recovery and business continuity planning and also in the test-
ing and execution of these plans to increase the probability that these
plans will work when invoked. What would an insurance company say
if an organisation cannot adequately demonstrate that its contingency
planning was properly documented and tested?
The single largest risk of immature contingency planning is that such
plans will not work when they are invoked. This is usually the result of
• Not keeping the various plans up to date to reflect changes in staff,
computer systems and requirements, all of which change over time;
• Inadequate or non-existant testing;
• Insufficient training and awareness provided to key players in the

implementation of such plans.
Software controls and distribution is the process through which an organ-
isation controls the issue and maintenance of software to comply with the
terms and conditions of software licences and to avoid support and com-
patibility problems when different versions of programs are used across
the organisation.
Software releases take place at two levels – package releases are typical of
new systems and have the advantage of being followed by a period of sta-
bility. Such releases are treated as a project and are accompanied by brief-
ings and training of the end users that will be affected by such releases.
Critical releases are needed to deal with high priority problems. If these
are not installed very quickly, the exposure to risk of the organisation as
a whole could be high. Critical releases can be a vendor’s temporary so-
lution to known vulnerabilities in operating systems such as for example
Windows or database products such as Oracle. They can also be solutions
to problems found in custom-made software by a group of developers.
In both cases such releases may contain new errors – critical releases seldom
benefit from extensive testing due to the critical nature of the problem.
The risks of not managing software controls and distribution through a
mature process are:
• Lack of compliance with the terms and conditions of software licenc-
es (for example more copies in use than the license allows);
• Unsynchronised releases of new versions of software across various
parts of the organisation;
• Bypassing proper controls for critical releases for the resolution of
problems;
• Creating a bureaucracy to manage software distribution
Change control is the process through which changes are evaluated and
approved, and through which their implementation is controlled. The
need for changes in ICT arises from the need to fix known problems
(problem management), to introduce new items (hardware or software),
to upgrade components, to respond to new business or legislative require-
ments or to introduce a new service.
The key component of change management is the Request for Change
which should be followed by several stages: evaluation (impact, cost, risk,
urgency), approval, scheduling and validation.
The risks of a change management system that is not mature enough are:
• Delays in implementing changes, particularly if the change manage-
ment system is paper based and involves bottlenecks (particularly in
the approval stage);
• Failed implementations due to side effects that were not properly con-
sidered before the change;
• ICT staff may be tempted to bypass the process leading to changes
that are not documented or known to others and creating complica-
tions should the change lead to problems at a later date;
• Resistance to a unified Change Management system from different
parts of an ICT organisation due to the different views of staff.
Configuration management is a process designed to give direct control
over all ICT assets and to use this control to ensure that ICT services pro-
vide value for money.
Configuration management requires a complete inventory or portfolio of
information assets at a level of detail that balances the amount of infor-
mation collected and the resources needed to do so.
Effective configuration management requires that all information assets are
included and that these are regularly verified to ensure that these correspond
to the records held in the configuration management documentation.
The risks associated with weak configuration management are
• That staff may bypass the process either for speed of implementing
an urgent change or to deliberately cause problems (sabotage);
• Not having staff available to implement emergency changes outside
normal office hours.
Service level management is as much a discipline as it is a process, and re-
lies on having defined Service Level requirements for specific systems
and facilities. These agreements are entered into by representatives of the
service provider (in-house or outsourcer) and those of end user groups.
This requires the service provider (the ICT function or an external provid-
er) to establish a complete catalog of services and the cost of provision.
The ICT function should also have mechanisms for collecting informa-
tion on service performance, validate it against the requirements of the
agreement and take remedial action when it does not.
The risks associated with not having service level management at an ap-
propriate level of maturity are:
• Inadequate or no performance indicators related to the needs of the

organisation and an inability to review the performance of ICT ser-
vices objectively;
• The inability to manage a successful relationship between an ICT ser-
vice provider and the users of these services in an organisation.
Contract and cost management are firmly integrated in the management
of an ICT infrastructure and ensure that there is adequate contractual
cover for essential services from vendors (maintenance) and third par-
ties (telecommunications and outsourcing).
Cost management also enables executives to know the full cost of ICT
to the organisation, identify opportunities for financial improvements
and use this information to make end users aware of these costs and
how costs are affected by changes in Service Level requirements. It also
provides the basis on which these costs can be recovered from user de-
partments.
The risks of immature contract and cost management processes in-
clude:
• Failure to comply with conditions of contract;
• Failure to renew contracts before they expire;
• Lack of knowledge of the cost of ICT activities and services
Availability management involves activities and architecture designs that
enable systems and facilities to be used whenever required. Service inter-
ruptions must be infrequent (achieved through building redundancy and
resiliency into the architecture) and problems must be quickly resolved.
This may require special arrangements with vendors to ensure that
their response time to a problem is adequately fast (high availability
operations usually allow the vendors to monitor the performance of
their equipment through a telecommunications link and have contracts
specifying a one or two hour intervention time in response to critical
problems).
The risks of having immature processes to manage availability are:
• Unplanned service interruptions with unknown resolution time;
• Inability to retain good process management staff;
• Inability to respond effectively during emergencies with a tendency
to improvise;
• Inability to depend on vendors to intervene quickly enough when
problems occur.
Storage and media management is a process related to both availability

management and contingency planning. Since the entry into force of the
Sarbanes-Oxley Act, it has become part of the mechanisms required for
compliance. This operational process is also used to put into practice the
organisation’s policies for the retention of data and documents in elec-
tronic form.
The creation and maintenance of comprehensive libraries of all software,
databases and data and keeping copies on appropriate media (magnetic
memory, magnetic tapes, optical discs and other) is a fundamental step
for the support of disaster recovery plans, and is mission critical to a suc-
cessful recovery.
The risks of inadequate storage and media management are:
• Inability to recover data from backup copies ranging from a set of
files to the failure of a disaster recovery plan;
• Outdated, unreadable media (for example magnetic tapes, which have
a limited service life) and unreadable data if for any reason the appli-
cation that created it is no longer available on backup mechanisms;
• Inability to comply with legislative or corporate requirements for the
preservation of data and documents in electronic form.
Capacity management is the process through which users’ requirements
for transaction volumes, turnaround times and response times are met.
Too little capacity creates bottlenecks and an inability to deal with peak
demands while too much implies under-utilised resources and higher
cost than otherwise required.
Capacity planning should be a part of the ICT function’s overall forward
planning with adequate budget and staff provision to meet expected re-
quirements in processing power, storage and network capacity and exter-
nal telecommunications links.
The risks of poor capacity planning are:
• Under-capacity due to an inability to project future demands on net-
works and applications;
• Cost of providing capacity well in excess of what is required;
• Poor technical performance of networks, Internet access and com-
puter systems usually manifested as long response time for transac-
tions;
• End user frustration arising from poor network and system perfor-
mance;
Processes and procedures

Every process consists of a number of procedures. For example:
Process: Data backup – perform a complete backup of all the data in a
computer room at 2 am every night of the year.
Procedures for the backup/restore process in this example
• Define the rota of computer room operators (and their alternates) re-
sponsible for overseeing the backup process;
• Select the appropriate number of blank tape cartridges to be used
each day;
• When the backup is complete, label the cartridges, place them in a
container and transport them to a fire-proof room in a specific off-
site building;
• Every Saturday, select a backup tape at random and verify that it can
be read and used for restoring the data, etc., etc.
The selection of the appropriate standards and best practices is the re-
sponsibility of the service provider regardless of whether this is an out-
sourcer or a Chief Information Officer.
While the use of such standards and best practices is not mandatory,
when none of the above are applied, it would be prudent to arrange to
conduct an independent technical audit of the ICT facility in ques-
tion.
People issues
Processes and how they are deployed depend entirely on people. An en-
thusiastic technical person fascinated by trying new things may not be
the best choice to manage processes: process people need to be systemat-
ic, meticulous, patient and effective problem solvers.
Creative and curious people may get easily bored with the structured na-
ture of process management and are unsuited for long-term assignments
in process tasks. However they make terrific troubleshooters.
Good process people also need to be motivated and flexible, as in ICT such
work requires shift work and on-call availability to provide continuous
coverage (24*7) every day of the year.
Executive Dilemma: the chaotic data centre
The data centre of Organisation XYZ is run by Michael, a very clever in-
dividual whose primary skill is in computing programming and who has
spent most of his working life in the same organisation. In an effort to re-
duce operational costs, Michael devotes all of his working time and a good
part of his spare time to do things as cheaply as possible.
The photograph shows some of the results: a cheap but very fragile oper-
ation where problems were the order of the day. However, in this execu-
tive dilemma, Michael was regarded by many as a “genius” and therefore
an indispensible individual who did not accept criticism from anyone.
Moreover, Michael never saw the point of attending conferences of dis-
cussing operational performance with his peers.
Whenever the people responsible for service delivery are skeptical of the
value of standards (ISO 9001), best practices (ITIL and COBIT) and insist
that adopting such practices would be expensive and require more staff,
it would be prudent to get a second opinion.
No diagram
or records
Sticky labels
(many missing)
Ordinary twine
Spaghetti
cabling
From an operational
data centre (really)
Given that executives rarely, if ever, visit the data centre on which their
organisation relies for service delivery, what would they find if they de-
cided to conduct an unannounced visit?
Action points
If your ICT service provider, in-house or outsourced, is certified to com-

ply with ISO 9001 and is regularly audited, you are doing well.
If not ISO 9001 certified, but the performance of your systems, networks,
help desk and contingency planning is generally considered as accept-
able, you are doing well and may wish to consider conducting a process
level assessment based on the COBIT guidelines.
If your in-house ICT organisation does not use (or comply with) ISO 9001,
the Information Technology Infrastructure Library, COBIT, or equiva-
lent guidelines, ask why this is the case – is it likely that your ICT people
can do better without such established best practices than with them?
If neither of the first two situations apply and the answers to the third
question is not satisfactory, it would be appropriate for you to take action,
starting with an in-depth diagnostics followed by an action plan to avoid
unpleasant surprises in the future.
C h a p t e r
9
Managing ICT projects for
success, quality and
reduced risk
Everything takes longer and costs more

Known as the Cheops Principle
• What exactly is a project?

• What is the impact of quality requirements on projects?
• Can projects be divided into distinct stages?
• Why do projects – particularly ICT projects - go wrong?
• Is project management an art or a science?
• What can an executive do to reduce the risks inherent in ICT proj-
ects?
ICT projects have a less than brilliant track record. A cynic once said that the basic formula
for such projects is R = 2*2*½ (the Results you get take twice as long and cost twice as
much as you planned for and are only one half of what you expected). Regrettable as it is,
this formula continues to be regularly validated by experience.
Many projects are successfully completed, and this is not because of luck. The combination
of technical complexity, optimism and the lack of effective (and experienced) project man-
agement constitutes a lethal mix that will reduce the chances of success of an ICT project.
Executives are the ultimate sponsors of such projects and, as such, have a critical role to
play to ensure that projects are properly managed, that major events – changes, delays and
other disruptions – are evaluated and controlled. Equally important for executives is to be
satisfied that project risks are sensibly managed.
What exactly is a project?
Projects are one time events consisting of multiple linked tasks with well
defined objectives and quality criteria, performed by teams of people
within a desired time and budget framework. The membership of these
teams may be internal (employees), external (consultants, vendors, con-
tractors and many others) or hybrid.
Projects can be categorised in many ways. Two particularly appropriate
categories for ICT projects are
1. The nature of the project
2. The size of the project.
The nature of a computer systems project is described by a point defined
by the three parameters shown in the figure.
The degree of integration describes the degree to which a computer sys-

tem cooperates with other systems, exchanging data and being part of a
specific workflow.
Complexity is an indication of how much work it will take to build the
software. This complexity is used to estimate the resources that will be
required to develop a system (the Function Point Analysis, developed by
IBM is an example of such estimating techniques).
The type of system indicates how much readily available software or com-
ponents may be brought into the project during the development stage.
This can be virtually none (for a one-of-a-kind system) to standard soft-
ware available as Open Source or as a commercial package. The latter are
referred to as COTS (Commercial Off the Shelf) software.
The cost, timescale and risk of the project increase with the distance from
the point where the three axis converge. Project duration and cost can
also be used to categorise computer projects:
Small Medium Large Very large
Time required days-weeks < one year 1 to 3 years > 3 years
Budget range < 10,000 $ < 1 M$ 1 to 100 M$ > 100 M$
Number of people <5 5 – 25 25 - 250 small army
Small projects – quick and involving modest resources – sometimes just
one person (up to ten thousand dollars or Euro); a small number of hard-
ware and software upgrades; moves, additions and changes (MACs) that
reflect the dynamic nature of any organisation; fixes to known software
problems.
The risks associated with such small projects are mainly end-user frus-
tration as a result of not meeting their expectations and delays. Delays in
the delivery of software are a common occurrence for reasons discussed
later in this Chapter.
Medium-size projects – with timescales of less than a year and a budget
that could reach around a million dollars or Euro include cabling proj-
ects, major data centre enhancements, and the development of software
for a specific application, typically with a low degree of integration with
other enterprise or corporate systems.
The risks of medium size projects include, in addition to those of small
projects
• The creation of “information islands” using incompatible definitions
of data or technical architectures that do not fit well with that of the
organisation as a whole;
• The introduction of unauthorised functions, malicious software or
backdoor access to systems. This can lead to fraud, sabotage and/or
blackmail;
• The possibility that the product or vendor chosen may no longer be
available by the time the project is completed (mergers, acquisitions,
bankruptcy, etc should never be excluded from a project’s risk anal-
ysis);
• Causing organisational slow-down or paralysis in the event of a failed
implementation.
In mid-July 2004, the peak of the holiday season, the SNCF - French National railways com-
pleted a medium size project to implement new networking software to upgrade the con-
nection of their seat reservation system to 4,000 points of sale. This failed in service and it
took three days to restore normal operations, having inconvenienced several hundred
thousand travellers and “gained” extensive negative publicity.
Large projects – these have timescales of three to five years and a budget
up to one hundred millions of dollars or Euro. Such projects include
building a new data centre or the consolidation of a number of operation-
al data centres at this new location.
Large software projects include enterprise software for an organisation
with thousands of employees, such as an Enterprise Resource Planning
system using a package that is customised for a specific organisation.
Typical implementation times are in the 3 to 5 years range, although some

of these projects can take over ten years to complete.
In addition to the risks previously highlighted, the main risk associated
with large scale projects is that of failure leading to the abandonment of
the project and the consequential loss of large sums of money.
Very large projects are those that extend over a period of many years, any-
where between three and ten, and involve sums of money in the tens to hun-
dreds of millions (dollars or Euros) and teams of several hundred people.
Very large projects are the riskiest of all because of their scope and com-
plexity and also because there will be many changes in the requirements
and technologies during the time it takes to implement them.
It is not uncommon for products to be withdrawn or for vendors to be
taken over by another company that decides to replace the product in
question by another one. These situations have the potential of causing
considerable disruption to the project.
One of the ICT projects known to be in poor shape in 2004 is the US government’s Busi-
ness Systems Modernization program for the Internal Revenue Service (IRS) an 8 billion dol-
lar plan is running very late (one component was delivered three years behind schedule)
and costs are escalating rapidly by hundreds of millions of dollars.
Facts about ICT projects
ICT projects, particularly in software, do not enjoy a good track record –

cost and timescale overruns, unmet expectations and other problems are
common.
Fact # 1: Every project has to have a sponsor.
The project sponsor is the initiator of the project and also its advocate and
spokesperson. In many cases the project sponsor is also responsible for
funding the project. In this capacity the project sponsor believes (or hopes)
that the value of the result of the project will be worth its cost and risk.
In the perfect world, the project sponsor would also be accountable for
the delivery of the benefits that were used to justify the project.
The project sponsor should play a visible role as the project evolves, by
chairing review meetings, leading “recognition events” when major de-
liverables are completed or a member of the team has an important event

in her/his life (promotion, marriage). The project sponsor also has the ul-
timate decision authority concerning the project.
Project sponsors who abdicate responsibility for ensuring that the proj-
ect is progressing and that it will meet the sponsor’s requirements will
get what they deserve.
Projects that do not have a sponsor (or when the sponsor is not an indi-
vidual but a committee) have higher risk, their benefits may not materi-
alise and are a potential drain of resources.
Fact # 2: All projects are calculated risks.
Any project, regardless of its size, complexity or importance, can fail.
Failure to recognise this possibility creates a problem to those working
on the project as in many organisational cultures they will attempt to cov-
er up bad news.
By the time it becomes apparent that the project is in trouble, large sums
of money would have been spent and by then, any hope of recovering any
part of these expenditures would have been lost.
Risk management is a discipline that can make a difference. Many organ-
isations are nor ready (or not willing) to adopt it as risk management will
challenge certain cultural aspects (for example not allowing risks to be
made explicit or by labeling a person who has bad news about a project’s
status as “not a team player”).
Fact # 3: There are several shades of project failure. Among them:
a. Successful completion of a project but with significant cost and time
overruns;
An not-for-profit organisation of some 10,000 staff decided to implement a new ERP to re-
place a number of legacy systems. The organisation believed that its needs and operations
are unique and that no commercial package could be adapted to meet their procedures
and business rules.
When the project first started, it had been estimated that it would take two years and 8
million dollars to deliver a made-to-measure system using internal resources with some as-
sistance from a vendor.
The project was completed to great acclaim and recognition (the project manager was pro-
moted). However it took ten years and somewhere near 100 million dollars and a large ex-
ternal team to complete. This situation is by no means unique and many more examples of
this kind abound.
b. Completion of a project which, as delivered, does not meet the expec-

tations of the project sponsor. These unmet expectations may be
functional or take the form of cost and time overruns;
c. The project is abandoned before completion having incurred signif-
icant expenditures between the launch of the project and its aban-
donment. The 2003 CHAOS report published by the Standish Group
states that 15% of projects were abandoned before completion and
that only 34% of all the 15,000 projects covered by their review were
considered by their sponsors as unqualified successes. The report
also shows that the project success rate is directly related to the size
of the project (expressed in project budget):
Project budget Success rate

Less than 750,000 US Dollars 46%
Between 750,000 and 3 million US Dollars 32%
Between 3 and 6 million US Dollars 23%
Between 6 and 10 million US Dollars 11%
Over 10 million US Dollars 2%
Success is defined as completing the project on time, within budget
and delivering the expected functionality.
d. The project is completed and turns out to be a total disaster.
While this is a case that made the news, there are many others that
are quietly buried and not talked about ...
In 1999, NASA the Mars Climate Orbiter. Because of inadequate project controls and com-
munications, the Orbiter was transmitting distance data in metric units while the earth sta-
tion operations were working in imperial units. The craft approached Mars’s atmosphere
too low and too fast and was never heard of again. The cost of this misadventure: 125 mil-
lion dollars.
Fact # 4: No project ever develops as planned.

While this may be manageable for small and medium size projects, large
and very large projects are invariably complex and the plans developed
for them are never good enough to be implemented as a series of planned
tasks.
The Standish Group’s website and more information about the CHAOS report are at
http://www.standish.com
ICT projects take place in an environment with many hard to forecast

variables – changes in requirements grow in number as the duration of
the project lengthens. Other headaches are changes in the membership
of the project team, changes in vendor products and even the demise of
the vendor.
When the change in the project team is the resignation of the project
manager, this creates a major disruption. The project sponsor should con-
sider three scenarios:
a) the project manager has been made an offer that cannot be refused
and has a valid reason for leaving the project;
b) the project manager is the first to know that a major problem will hit
a project and departure from the project should be seen as self-pres-
ervation;
c) the project manager recognises that she/he does not have the skills
and experience to deliver the project and wants to disappear before
being found out.
An not-for-profit organisation of some 2000 staff decided to implement a new ERP to re-
place a number of legacy systems. A year after deciding to use product X, a recently arrived
senior executive decided to put the project on hold in order to conduct a review, dismiss-
ing the consultants working on the project and engaging new consultants. During this
time, the organisation continued to pay several million dollars in software licences for (the
unused) product X.
The project was restarted two years later with a new team of consultants. At this point the
project manager resigned and a new one had to be found. The projected budget for com-
pletion of this project has grown dramatically and the project remains years away from
completion...
The project manager and the project sponsor need to recognise the inev-
itability of change and ensure that the planning process is designed to ac-
commodate change and then work towards minimising the impact and
risk associated with such changes.
Fact # 5: Size matters
Small projects have a higher rate of successful completion than very large
projects. Various studies, including that of the Standish Group indicate
that less than 30 % of very large projects are ever completed.
The difficulties associated with very large projects are related to the num-
ber of people that must work together and to the complex inter-relation-
ships between parts of the project, the people working on them, vendors
and other suppliers and the time taken by the project.
ICT projects extending over a period of several years must be organized

to deal with two specific problems:
• People turnover, normal in the ICT industry with typical rates of 10
to 15% changing jobs every year. This requires new workers to be
briefed and integrated into a team. This can be a delicate situation
when the new person is the replacement of a previous project man-
ager;
• Changes, sometimes dramatic, in the requirements for a new system
– perhaps because of a reorganisation or as a result of mergers and
acquisitions.
Fact # 6: Estimates are rarely robust enough
The ICT industry and those who work in this field are mainly optimists.
Nothing is too difficult and in their enthusiasm to see projects started
and new technology put in place, they provide budget and time estimates
and that prove to be inadequate. There are several reasons for this:
One is that there is little dialog between ICT people and their financial
colleagues. Budgets and cost accounting tend to be seen by ICT people as
necessary evils. Concepts such as life cycle costs and the total cost of own-
ership are not understood by the financial community and as a result
project budgets are not as thought through as they ought to be.
Another reason is the widespread belief (or hope) that Fact # 4 is not true,
and therefore, there is not enough risk analysis and contingency plan-
ning.
In software projects, there is an additional problem: formal estimating
techniques are not consistently applied. Vendors are better at estimating
software projects than in-house ICT groups.
The idea that a cost and duration estimate when the system requirements
are only defined at the conceptual level are good enough to budget for a
project, persists despite the experience that proves that this is never the
case. Real costs will be at least 50% higher than this first estimate.
Similar optimism affects the estimate of timescales where there is a ten-
dency of believing that the estimate for the earliest possible delivery date
will be the actual date. One of the most respected writers on software
projects, Tom Demarco, describes this approach as Testosterone Based
Waltzing with bears, Tom DeMarco and Timothy Lister, 2003. Dorset House
Publishing Co.
Estimating. The concept of boundaries (earliest possible, latest possible

and most likely delivery dates) is not used often enough.
Fact # 7: Expectations sometimes fall in the Impossible Region
A consequence of Tes-
tosterone Base Estimat-
ing is the expectation
that major ICT projects
can be delivered “quick-
ly” – even quicker than
practically possible with-
out making concessions
for scope, quality or cost.
Similarly, when a project
is running behind sched-
ule, it is often thought
that putting more people
to work on the project
will shorten the times- Diagram from Waltzing with Bears, by
Tom DeMarco and Timothy Lister
cale for delivery.
This is sometimes true – additional resources can make all the difference
at a time when a project is running late and it is essential to bring it back
to the planned schedule. It comes at a significantly increased cost and in-
volves the headache of briefing new people and integrating them into a
functioning team.
There are however, limits to this and every project has an Impossible Re-
gion – a delivery timescale that cannot be achieved regardless of how
many resources are thrown at the project or what its final cost will be.
The analogy sometimes used in courses on the management of major
projects is that of making nine women pregnant at the same time in the
hope that this will result in a baby delivered in one month.
Fact # 8: It is cheaper and better to kill a no-longer-viable project than to
let it continue
Recognition of this fact is the driving force for the large percentage of ma-
jor projects that are abandoned before completion. Not everyone has the
courage to admit this, and vast sums of money have been spent on sys-
tems known not to meet requirements that changed since the project was
launched or projects that took so long that the technology on which they
are based is obsolete.
Quality: The project sponsor’s dilemma
Imagine if this notice, found in a shoe

repair shop were to be placed in a soft-
ware development environment…
The pressures for “quick” are always
there. In many situations a quick solu-
tion would be appropriate even if it
had some errors in it – for example a
simple database that would be used infrequently and only in the short
term by a small group of people.
The pressures for “cheap” are also always there, and increase when a proj-
ect is showing signs of running late and the project sponsor is unwilling
or unable to make more resources available (and hopes that the project
will not enter into the Impossible Region).
When there is pressure for Quick and for Cheap the loser is always Qual-
ity because there will be pressure to postpone or avoid debugging and
documenting the work, peer review and testing.
The political realities of managements’ commitment to fixed deadlines
and budgets cannot and should not be underestimated – some of these
deadlines may have been announced to the press or others and become
“political imperatives”.
When the project involves systems with a critical role in the day-to-day
work of an organisation it is not a good idea to compromise on quality.
The project manager and project sponsor will need all the possible nego-
tiating and advocacy skills to protect the organisation from itself.
The main stages in a project’s life

The experienced cynic’s view of the nine stages of a project is summarised
in the box. While not always the case, there is some truth in it.
The discipline of project man- 1. Wild enthusiasm
agement divides the lifecycle 2. Optimism
3. Cool objectivity
of a project into four phases: 4. Quiet confusion
5. Partial disengagement
• Initialisation 6. Complete disillusion or panic
• Setting-up 7. Search for the guilty
• Implementation 8. Punishment of the innocent
• Completion 9. Reward of those who were not involved
Risk management should be an inseparable discipline in all of these stages.

STAGE 1: The initialisation phase covers all the activities that must be
carried out prior to the actual start of a project and include, as a mini-
mum the preparation of a proposal which must include a feasibility as-
sessment and definitions of:
• Who sponsors the project;
• Who funds the project;
• An overall description of justification for the project;
• What to buy, what to make and what to outsource;
• All known constraints and inhibitors – the list should be comprehen-
sive and realistic and include timescales, budget, technical legacies,
people issues (expertise, track record), organisation, and infrastruc-
ture matters;
• Dependencies that may impact on the proposed project such as oth-
er current projects, culture, communication, partners, contractors;
• Risk factors related to the proposed project (peoples’ skills, experi-
ence, the organisation’s decision making style and process, the de-
gree to which there is a common understanding of the project
goals)
• Critical success factors for the project;
• Legal matters such as the ownership of intellectual property (for cus-
tom software), need for confidentiality and non-disclosure during
the project development;
• Technical and economic feasibility
• and any other information that will make the difference between suc-
cess and failure.
At this stage it is appropriate to issue a Request for Information (RFI) to
determine how many vendors have products that appear to meet this gen-
eral specification of requirements or a Request for Proposals (RFP) if a
reasonably detailed specification of requirements can be produced.
Producing a good RFP is itself a substantial project and must be done in
such a way that it avoids the waste of time, effort and resources that might
arise from an unclear, incomplete or incorrect specification. For a vendor
a formal response to an RFP also represents a significant project undertak-
en in the knowledge that only one vendor can end up getting a contract.
Dealing with a vendor’s proposal in response to an RFP requires the def-
inition of clear evaluation criteria and a methodology that reduces bias
in decision making. The technique of Weighted Ranking by Levels
(WRBL). This and other tools have been compiled in a companion vol-
ume to this book entitled “The Executive Toolkit”.
The final part of this stage is the negotiation and signing of contracts and
the development of detailed project plan that identifies the activities to
be performed by the vendor and by the client(s).
STAGE 2: Setting up a project follows executive approval to go ahead and
starts with the signature of a contract to deliver the project or being giv-
en the “GO” if the project will be resourced internally.
Best practices include formalising several component parts of the project
to ensure clarity of purpose and communications. These include as top
level activities:
• Project Organisation
Making the appointment of a project manager and the project team
and assigning the percentage of time that they shall devote to the
project (from 20% for a small, non-critical project that can be done
concurrently with other activities to 100% for any substantial or crit-
ical project). In addition, suitable arrangements for accommodation,
tools and related facilities need to made at this time.
For large and very large projects and for projects of any size that have
a major impact on an organisation, a Project Review Board (or group,
task force, committee if these names are more appropriate in a given
environment) should be established.
• Decision making process and delegated authorities
Defining the scope of authority of the project manager and the proj-
ect team members concerning expenditures, changes of scope, tech-
nologies, products, etc., and defining who can authorise changes (and
how) other than those delegated. Such definitions should cater for ar-
rangements that enable urgent decisions in non-delegated areas to be
handled effectively.
The project manager remains responsible for all activities of the proj-
ect, including those delegated to members of the project team or con-
tracted with external parties
• Review Management
Defining how, who and how frequently the Project Review Board or
equivalent body will meet with the project manager /project team to
The Executive Toolkit by Ed Gelbstein and Elöd Polgar, Diplo publications, 2005
(www.diplomacy.edu)
review the progress of the project as well as the authorities of this per-
son or group.
Particularly important for major projects, this group should have the
authority to decide whether a project should be terminated or, at the
very least, be responsible for requesting such a decision from the Ex-
ecutive.
STAGE 3: Project implementation is the collection of activities and re-
sources that transform a plan into deliverables. Almost entirely the re-
sponsibility of the project team and any vendors, contractors or other par-
ties involved, project management activities include:
• Progress management (tracking and recording the evolution of the
work against a project plan). This is a key the main purpose of which
is to identify early signs of trouble in a project and deal with devia-
tions from the plan by managing changes to it through a formal
Change Control process and maintaining the project plan up to
date.
Project plans must be kept up to date to show all changes to the proj-
ect and be shared among the project team, the sponsor and other ex-
ecutives, notably those members of a project review group to be of
real value.
It is acknowledged that there are organisational cultures where voic-
ing bad news, whether slippages or technical problems, is considered
akin to treason. This goes against the principles of risk management
and does not help project success.
• Change management
The need for changes to a project plan will be driven by many differ-
ent factors – for example:
- Changes in requirements identified during the development of the
project;
- Changes in technical products (versions of software, new hardware,
vendors going out of business or ceasing to support a product);
- Changes in the constitution of the project team and the need to
brief new members and integrate them into the team;
- Delay in completing a task that prevents another from being start-
ed;
- Lack of funds that obliges the project to be put in suspense during
its execution;
- and a multitude of other reasons
A Change Control process is used to formalise, document and keep

a record of the approval of all changes that take place during the im-
plementation of a project. This can be paper based or electronic and
at the very least it should document.
- Who has the authority to request changes;
- Who requested the change;
- The purpose of the change;
- An analysis of the impact of the change;
- An analysis of the risk associated with the proposed change;
- The likely cost and duration of implementing the proposed
change;
- Who can authorise (or deny) the change;
- How the proposed change will be implemented and validated
The project manager should have the authority to decide on proposed
changes (Yes, No, Not now). In case of disagreement between the re-
quester and the project manager, the matter should be raised to the
Project Review Board which would be chaired by the project spon-
sor.
Overriding the project manager’s decisions on a frequent basis is a
recipe for trouble as it implies that there is no confidence in her/his
ability to conduct and deliver the project or to safeguard the interests
of the organisation.
• Project reviews
These are essential and can be either scheduled events or called at the
initiative of the sponsor or the project manager. The purpose of these
project reviews is to
- Share the project schedule and its evolving versions
- Report on the actual vs planned status and actions to be taken if
they diverge
- Identify all changes to the project environment since the last re-
view – and emerging risks or situations that need to be addressed
- Ensure there is agreement on the purpose of the tasks that need to
be carried out and how they should be done – documented with re-
sources, timescales, deliverables
STAGE 4: Project completion is the time when all the project activities
have been done and the outcome is ready to be included in the portfolio
of information assets in use by an organisation.
Typical tasks associated with a project’s completion are extensive testing:
technical testing for performance, security features, data exchanges, in-
tegration with other technologies and systems and end user testing to val-
idate that the ergonomics of the system are consistent with the skills and
ability of the people who will use it.
When the project relates to a computer system that will involve confiden-
tial and financial transactions, it is also good practice to conduct an au-
dit that the appropriate controls have been correctly implemented.
Introducing a new system into operation can be done in two ways - Big
Bang or phased:
The concept of the Big Bang is a courageous approach to the implemen-
tation of large, complex software systems – waiting until all the develop-
ment has been completed before releasing the system to an operational
environment. This requires massive efforts in testing, transferring data
to the new system from older systems, training, preparing for the sup-
port of the people who will use it and a critical period of transition from
the old to the new.
The opposite approach of phased implementations is favoured by a sub-
stantial majority of the people working in the software industry, who ad-
vocate that systems should be broken down into usable portions that can
be implemented in no more than two years.
Moreover, when the new system is a replacement of an old system, paral-
lel running - keeping the old system operational until there is a sufficient
level of confidence that the new system is performing well, is a way to re-
duce risk. Like all risk management activities (except hoping for good
luck), it involves additional costs.
The most common reasons

why projects go wrong
One difference between ICT projects and other projects, such as the con-
struction of a bridge or the launching of a satellite is that in the event of
failure the latter projects are investigated and a report on the cause of fail-
ure is produced. In the computer industry some failures get public atten-
tion because of their impact and visibility but it is not unusual to cover
up failures whenever possible, minimise them and when this is not pos-
sible, provide “rational explanations”. The most common reasons for proj-
ects to go wrong can be grouped in two categories of different natures:
Complexity Optimism
Complexity
Complexity can be easily understood

to be a cause for project failure. This
does not need to be the case, as many
complex projects are successfully com-
pleted and measures that can be taken
to reduce the risk of project failure are
discussed here.
Complexity is the enemy of manage-
ability and simplicity a virtue that
characterises most creative and effective inventions. The KISS principle
(Keep It Short and Simple) is as well known as it is ignored.
Some of the many things that conspire against simplicity in ICT projects
are:
a) A lack of understanding of the requirements of the end product (this
could be as much on the part of the sponsor as on the part of the peo-
ple responsible for implementing the project);
b) Changing requirements, inevitable as a project evolves, can lead to
increased complexity if their impact on the remainder of the project
is not evaluated as part of a Change Control process. The number of
changes will be greater when the project lasts a long time and many
such changes will be essential. The project sponsor and the project
manager should be aware that such changes are loved by vendors,
consultants and programmers;
c) The Mindless Pursuit of Perfection, where developers and imple-
menters seek to build an ICT system that caters for every conceivable
situation, however rare they might be.
d) Creativity over practicality: relates to the pursuit of technical perfec-
tion, seeking the most elegant solution to a particular problem after
an adequate solution has been found, regardless of the time and ef-
fort it takes;
e) Love of experimenting. ICT is an innovative industry and new prod-
ucts, silver bullets and magic solutions are annonunced all the time.
Known as the bleeding edge, technical people are tempted to be

among the first to try. Of course, if it does not work as promised, or
the vendor withdraws the product, or the vendor goes out of business,
it’s just bad luck…
f) Sloppy implementation, justified by the need to meet tight timescales,
with the promise that “it can be fixed in the next project stage”. While
most things can be fixed later, the cost and added complexity of fix-
ing sloppy implementations some time in the future are potentially
large. For example placing a door in the wrong place in a house un-
der construction is much easier to correct before the walls around it
are built than after the wall has been built, plastered and painted.
g) Going for a Big Bang approach with a large new system or upgrade.
While often there is no choice but to go for a big bang approach, this
requires superior planning and coordination for hundreds, if not
thousands of activities and is therefore a higher risk approach than
that of implementing things in more manageable packages that are
integrated one by one.
Optimism
While it is wonderful to work in a stimulating and

optimistic environment there are situations where
too much optimism is a liability. Large projects are
well served by balancing optimism with experi-
ence.
Optimistic approaches to the following situations
may occasionally work out but, as a rule, they
don’t:
i) Appointing a project manager for a large and complex project who
does not have solid experience of managing comparable, albeit small-
er, projects. This is, not uncommon as the convenience of having
someone who is readily available but inexperienced displaces risk to
some future time. Learning on the job puts the whole project at risk
and the learning curve is steep;
ii) Accepting the view that certain tasks are of the “easy – no problem!”
kind without having first requested time to think about the issue;
iii) Implausible estimates based on enthusiasm and optimism which in-
variably lead to missed deadlines, cost overruns and inadequate test-
ing;
iv) Belief in Magic: whenever a project gets to the situation that this “new
tool”, “team member”, “product” will fix the problems that the proj-
ect is facing and put it back on course. Anything of this kind should
ring loud alarm bells in the sponsor’s mind.
The art and science of Project Management
Project Management has been treated as a science for many years. There
are many courses, books, software programs and tools to train people in
project management methodologies and in methods for measuring prog-
ress (and also measure deviations from the targets set for the project).
No two projects are ever the same and project managers can expect to be
confronted with situations that require experience, common sense, intu-
ition, creativity and negotiation skills to resolve – which make project
management an art as well as a science.
Formal project management aims to maximise the probability of the suc-
cessful completion of the project, meeting the planned targets for results,
timescales and costs. When done properly, it also includes the identifica-
tion, mitigating and management of the risks to which a project is ex-
posed. Chapter 10 is dedicated to this topic.
The Central Computing and Telecommunications Agency of the UK Government (CCTA)

produced “CRAMM” methodology (CCTA’s Risk Assessment and Management Methodol-
ogy) which has been widely adopted as a tool for software projects. This tool, now avail-
able in several languages is available from www.cramm.com
The skills needed to be successful in projects are many and include

• Business management;
• Risk assessment and management;
• Project management practices and tools including documentation;
• Issue management and change management;
• Quality management;
• Contract management and related payments;
• People management (including project teams, vendors, contractors
and clients);
• Financial management;
• Review and meeting management;
Successful “project people” need to be good organisers, effective decision

makers, good communicators and have superior interpersonal skills.
They must also be able to deal with change.
Action points
Nobody wishes to be associated with a failed project, particularly one in-

volving large sums of money and risk to their organisation. What can ex-
ecutives do to manage and contain risk to avoid the pain and embarrass-
ment of a failed project?
A good approach is to think of a project as if it was a patient in an inten-
sive care - continuous monitoring of vital signs is required to increase the
chances of survival.
This requires a consolidated view of the project through its lifecycle by
all the parties concerned – the sponsor, senior management, project
teams, end users and others. Consistency, good communications, even
when it is a matter of conveying bad news make a big difference.
Here are a few approaches known to work well. These may well help both
before and during the project implementation:
1. Avoid overambitious or unrealistic project goals and objectives and
remember there is always a choice to be made between Quick, Qual-
ity and Cheap;
2. Resource the project sensibly, starting with the right kind of project
manager, project team and other parties involved. The “right kind”
must be, as a very minimum competent, experienced and empow-
ered;
3. Ensure that formal project management methodologies are used and
that all changes to the project are documented as it goes forward;
4. Make certain that the project sponsor and other executives are in-
volved and informed on the evolution of the project;
5. Help the project manager keep a tight control on changes in require-
ments and discourage frequent changes altogether;
6. Recognise that project delays and cost overruns are likely and help
the project team to keep both of these to a minimum;
7. Ensure that, if your organisational culture allows for it, risk manage-
ment is applied to all projects. If your organisation does not believe
in the value of risk management or it is contrary to its culture and

behaviour, you will have to rely on luck.
8. When things go wrong with a project, blamestorming is unhelpful.
Executives should be sensitive to warning signs and take appropriate
action before it is too late even if such action may cause distress if it
involves replacing one or more members of the project team or even
the project manager.
delivery processes may prove catastrophic in the operation of critical in-
frastructures, continuous and automated manufacturing, financial ser
C h a p t e r
10
Understanding and
managing ICT risks
Risk management prepares you against a problem that has not yet happened
Problem management is what you do when the problem occurs
Crisis management is what you have to do when you cannot solve the problem
• What exactly is risk and what are the factors that determine it?
• What is the scope of risks associated with ICT?
• Why should an executive be concerned with ICT-related risk manage-
ment?
• What are the steps needed to manage risk?
Living and working in an imperfect world, things never work as planned. Risk management
is the discipline through which the effects of unplanned events can be mitigated.
ICT bring with them additional components of risk: threats and vulnerabilities that can
have a certain impact on the activities of an organisation. Countermeasures are put in
place to remove or reduce these threats and vulnerabilities, and what remains is a residual
risk, i.e. that the countermeasures are not sufficient to remove a threat or a vulnerability,
or that an unexpected (even unthinkable) event occurs.
Understanding threats and vulnerabilities and implementing good countermeasures are es-
sential components of risk management strategies. These strategies start with risk evasion,
a “do nothing” approach in which an organisation relies only on good luck and extend to
complex arrangements of risk containment, mitigation and transfer involving other parties
such as insurance companies and outsourcing service providers.
Managing risks
Risk is part of daily life and most people recognise that harm, loss and
danger are real and could actually happen to them.
Cautious people buy health and property insurance and also wisely hes-
itate to undertake activities involving long ladders and climbing on roofs
or tall trees and make arrangements to look after their children should
something bad happen to them. In addition, cautious people do not at-
tempt to fix things they do not understand, like plumbing (those who
have a go, must accept the consequences).
Then, there are thrill seekers who go bungee jumping, parachute from
planes, go mountain climbing and other activities that they believe can
be achieved without harm. Finally, there are those who do things with-
out thinking about risk. Statistics are not in favour of poor preparation.
Many of those who don’t succeed get mentioned in books such as the Dar-
win Awards and the Chronicles of Human Stupidity.
How many of the people in these categories behave the same way in their
workplace? When it comes to ICT it would appear that the cautious group
may be in a minority and the rest may just be unaware of their role in
managing enterprise risk.
Murphy’s Law is alive and well
Edward Murphy, an U.S. Air Force captain, said in 1949 that
ANYTHING THAN CAN GO WRONG WILL DO SO
This is now known as “Murphy’s Law” and various versions of itcan be

found on notice boards all over the world, in hospitals, police stations,
garages and offices. Its many variants and corollaries, as well as its long
lasting popularity indicate that it is felt to be true. Among its corollaries,
the following are popular and, so far, also valid:
Corollary #1: Anything that could not possibly go wrong is only waiting
for the opportunity.
Corollary #2: When things go wrong, they do it in such a way that it
causes the maximum damage.
Corollary #3: There is nothing ever so bad that it could not possibly get
worse.
Murphy’s Law and its corollaries provide a good background for a defi-
nition of risk
Risk is the possibility of something harmful
that has not yet happened.
The difference between risk, a problem and a crisis can be illustrated with
an example:
Risk Losing key staff to a competitor
Problem There is a shortage of qualified staff and much competition
for them
Crisis Despite every effort made, a suitable replacement could not
be found
When nothing is done about risks, the result is a surprise. Surprises are
NEVER good news.
The three components of risk and the role of countermeasures

Risk is determined by three components: Threats, Vulnerabilities and
Impact.
A threat is a potentially adverse event with a non-zero probability of oc-
currence. In the case of a computer centre located in the basement of a
building close to a river, flooding is a threat. An A to Z of typical threats
found in ICT systems and facilities includes the following – and there is
scope for expanding the list…
A vulnerability is anything that could be exploited by a threat to cause

damage. Vulnerabilities are always under the control of the organisation
facing the risk. In the example of the computer centre, the vulnerability
consists of having the computer room in a basement, as this will be the
first place to flood should the river break its banks.
There are many types of vulnerabilities – technical, human, operational,
things that have not been properly tested and more. These will be dis-
cussed in more detail below.
Impact is the outcome of a threat and a vulnerability coming together,
expressed in terms of disruption and cost.
Countermeasures
These are all the actions that are taken to avoid or reduce threats, vulner-
abilities and impact. In terms of the example of the computer room and
the river, one possible countermeasure would be to relocate the facility to
a place where the threat of flooding is much lower – away from rivers and
the sea.
However, some threats are much harder to deal with by an individual or-
ganisation, for example that of civil disorder or that of a terrorist attack
in a particular city.
Vulnerabilities are much more manageable in terms of finding and im-
plementing countermeasures, but on condition that appropriate effort is
put into identifying these vulnerabilities and reviewing the situation on
a regular basis.
A computer room without access controls that can be monitored is a typ-
ical example of a vulnerability. Another example would be Antivirus soft-
ware not kept up to date. The countermeasures needed to address these
vulnerabilities are relatively simple but require action to be implement-
ed.
The potential impact of
an event is of prime im-
portance in deciding the
extent to which counter-
measures will be put in
place – very few counter-
measures can be imple-
mented without cost.
Exposure or residual risk

When all is said and done, and countermeasures designed and applied,
there will remain a residual risk, also described as an exposure.
This exposure will always have a non-zero probability and the degree of
residual risk that can be accepted depends on the criticality of the facili-
ties to be protected and the impact of an undesirable event occurring.
The main areas of ICT risk
Six distinct areas of risk will be considered in this chapter. Four of them are
derived from the Control Objectives for Information Technology (COBIT):
Weak governance (COBIT Planning and Organisation)
Projects (COBIT Acquisition and implementation)
Operations (COBIT Service delivery)
Lack of audit (COBIT Monitoring)
and the remaining two are: non-compliance (with legislation, contracts
and policies) and people issues.
Risks related to weak governance

A typical list of such risks would include, as a minimum:
• Unrealistic ICT strategies, poorly aligned with business needs;
• Inadequate policies relating to the use and protection of information
assets;
• Duplication of activities resulting in diverse and incompatible solu-
tions;
• Inadequate organisational knowledge of ICT costs and benefits;
• Inability of the workforce to properly exploit the systems and facili-
ties;
• Inadequate budgets to implement and operate ICT with adequate
countermeasures.
Each one of these can lead to unproductive expenditures, systems that
fail to meet the information needs of the organisation and in underfund-
ed and under-resourced ICT services which may be unsustainable. The
latter syndrome is called SMRC - “Saving Money Regardless of Cost”.
While it is important to contain the cost of ICT, there are better ways of
doing this than to resort to budgetary anorexia.
Risks related to ICT projects

A previous chapter discussed the poor track record of ICT project deliv-
ery. The areas of risk that contribute to this include:
• Insufficient or inaccurate specification of requirements;
• Poor estimates of project duration, project cost and expected benefits;
• Runaway projects as a result of ineffective Change Control;
• Projects that are abandoned before completion;

• Insufficient controls built into the software that fail to meet audit re-
quirements;
• Inability to detect unwanted or undocumented functionality (e.g. a
logical bomb);
• Immature technologies or vendors that do not survive in the market-
place;
• Weak controls during systems tests as well as during data conversion
and transfer;
• Incomplete documentation and insufficient testing.
Failure to address these items invariably results in increased costs, inad-
equate computer systems and, in the case of systems testing and data con-
version a prime opportunity to commit fraud. Logical bombs are also
used to sabotage and blackmail organisations.
Risks related to ICT operations

Even the best technologies from the finest vendors will be at risk if the
day-to-day activities required to operate them are not carried out with-
out due care and attention being given to risk management. A list of typ-
ical activities that create exposures include:
• Service levels that are not high enough to meet the organisation’s
needs;
• Weaknesses in the physical security of the computer room/ data centre;
• Weaknesses in the logical security for providing access to systems
and networks, including identity management and authentication;
• Data centre processes that are not mature enough (see COBIT, Chapter 2);
• Lack of proper planning and change management for major up-
grades;
• Insufficient technical capacity (not enough processing power, stor-
age capacity, bandwidth);
• Technologies and software that are not supported by their vendors (a
typical situation when they are fairly old and have not been upgrad-
ed to current versions);
• Incomplete, untested or non-existent contingency plans;
• Untrained or incompetent data centre and technical support personnel;
• Ineffective help desk and end user support facilities.
A complete list would be quite a bit longer. These exposures are not un-
common and are the main cause of service disruption and for the invo-
cation of disaster recovery and other contingency plans.
Risks related to the lack of ICT audits

Audits can provide an independent assessment of the ICT related expo-
sures facing an organisation and validate the controls put in place to re-
duce such risks. In the absence of appropriate ICT audits, the following
exposures may be significant:
• No clear understanding of ICT expenditures;
• Inability to benchmark ICT performance and costs;
• Persistence of systematic errors and problems;
• Inability to detect unusual transactions (likely indicators of fraud);
• Inability to identify ICT misuse and abuse by individuals with priv-
ileged rights (e.g. System administrators, Database administrators);
Non-compliance risks
Organisations must comply with national and regional legislation on
many matters, including privacy, data protection, health and safety and
work, the accuracy of financial reports and more. They also need to take
steps that their workforce complies with internal policies and codes of
conduct.
In addition, organisations have responsibilities to third parties and these
require compliance with the terms and conditions of contracts and licenc-
es and to all situations where third parties may have recourse to the law
to seek compensation or damages for the misuse of data.
People-related risks
People play a key role in any organisation. The main areas of risk relat-
ing to them include:
• The provision of access rights to computer systems and networks to
non-employees, including vendors, customers, maintenance person-
nel, consultants, contractors, interns;
• Dishonest, malicious or disgruntled employees;
• Industrial espionage;
• Infiltration by organised crime;
• Abuse through social engineering;
• Lack of awareness of essential information security and related is-
sues.
Chapter 2
What are the steps needed to manage risk?
There are two distinct stages in dealing with risk:

• Understanding the possible risks;
• Doing something about them: identifying and implementing coun-
termeasures;
Understanding risks
Things that we can think of as potentially harmful may never happen (in
plain language this is called luck) but luck cannot be counted on as sta-
tistics are against it.
While the previous section listed some areas of potential exposure, the
process for understanding risks needs to be customised for every organ-
isation. The process involves two steps: discovery (or identification) and
evaluation.
Discovery requires being open minded and candid about the things that
can occur to harm a process, project or activity.
There are many techniques that can be used to identify risks and brain-
storming is a favourite one. Successful brainstorming requires a mixture
of experience (after all, risk is managed by people), good communications
that allow risk to be discussed openly as some risks require saying things
that may conflict with organisational culture, for example:
• “Tony is incompetent – the project will fail is he is made project man-
ager” when Tony happens to be the Chief Executive’s nephew;
• “There is no way that this project can be completed by the end of this
year and besides the budget is totally inadequate”;
To populate the list of risks, it is good to assume that every problem ex-
perienced in the past is a future risk. In addition, the brainstorming
group should look for what they don’t know – the subject of every ques-
tion to which the answer is “I don’t know” is a risk.
Similarly, the assumptions being made in looking for risks should be
challenged – for example “there is no way that one of our employees could
act dishonestly” may not be valid.
There are tools that can be used to support and extend the brainstorm-
ing process. The “Five Whys” technique is an extension of the natural cu-
riosity of a three year old in which questions are asked to identify the root
cause of potential events, problems or risks. By asking “why” – five times

is usually enough – layers of symptoms can be removed to arrive at the
root cause of a problem.
Another useful technique is the “fishbone diagram”, originally created
to support quality management.
The example illustrates the early stage of development of a diagram trac-
ing back all the factors that might enable fraud using ICT to take place.
Used to complement brainstorming, these diagrams provide a good ba-
sis for group discussion and interaction allowing these diagrams to be
developed and completed and lead to the establishment of a comprehen-
sive list of risks that can lead to particular outcomes.
Following a couple of branches of this tree, first the policy branch: if the
organisation does not have a policy to limit data access on a need to know
basis as part of its appropriate use policy, if there is no policy for moni-
toring access to systems and keeping appropriate logs for critical trans-
actions and there is no policy specifying what action will be taken in the
event of non-compliance, the possibility of fraud has been facilitated.
Looking at the process branch, if the process for terminating access rights
for a person leaving the organisation (on retirement or to another job else-
where) is not properly carried out, there will be people who have legiti-
mate user IDs, passwords and whatever other mechanisms to ensure
identity management while no longer being entitled to such rights. An-
other factor that makes fraud possible and not-so-difficult.
Once identified, risks should be evaluated, i.e. the estimation of the prob-
ability of a risk manifesting itself. Those not convinced of the value of risk
management will, at this point, argue that the probabilities of risks can-
not be determined.
While these numbers cannot be accurately known, boundaries and rea-
sonable estimates can be derived by looking at history, statistics and
trends and then discussing best and worst case numbers and agreeing on
a “most likely” value.
If someone says that “the project office could be hit by a meteorite”, this
is possible and global statistics can be used to show that the probability
of such an event is several orders of magnitude lower that the probabili-
ty that the project manager will resign midway through a project.
For every activity there are one or more events that can be described as
showstoppers. If this event occurs it will result in an undesirable outcome
which could include events with disastrous consequences.
For example, an organisation that is working on an innovative product
or service and planning to be the first in the marketplace discovers, two
thirds of the way through the project, that a competitor has beaten them
to it with a superior product. The best choice left to them is to abandon
the project and write off the expenditures incurred this far.
The root cause of this risk was the incorrect assumption that they could
be the first in the marketplace and ignoring possible competition. The
owner of this assumption, usually the project sponsor, may have not been
thorough enough in the risk discovery stage.
Unthinkable risks – those that could have fatal consequences for an or-
ganisation – may be unthinkable but are not impossible. Organisations
where cultural issues prevent such risks from being articulated make risk
management very hard, if not impossible.
Doing something about risks

Having identified and prioritised risks, their management in practice
calls for two sets of activities: risk management strategies and risk mon-
itoring.
Risk management strategies
Worrying about a problem does not solve it. Doing something about it
might. This statement is the basis of the five possible risk management
strategies: avoid, contain, mitigate, evasion, transfer.
Risk avoidance implies not pursuing an activity – a person will avoid the
risks involved in parachute jumping simply by not jumping. This strate-
gy also foregoes any benefits that pursuing the activity may have deliv-
ered – thrill and pride in the case of the parachute, business benefits in
pursuing innovative projects to be first in the marketplace.
Risk containment is about having sufficient reserves of money, time and
people to cover the outcome of the combined risks should these materi-
alise. This is what organisations do when they cover, from their reserves,
the cost of an undesirable event – credit card fraud, for example.
Risk mitigation is the collection of measures taken to reduce the emer-
gence of a risk and reduce the cost of containment. All the activities re-
lating to risk mitigation are carried out in advance of the materialisation
of a potential risk factor – examples include:
• Implementation of security policies and measures, background
checks on employees;
• Preparation and testing of contingency plans;
• etc.
Risk evasion consists of crossing your fingers and hope the risk factors
don’t materialise and in practice they don’t. The success of this strategy,
although much used, is not supported by statistics.
Risk transfer occurs when one or more risks are contractually shared be-
tween two or more parties, insurance and outsourcing being typical ex-
amples of risk transfer. This works well if there is complete clarity in the
roles and responsibilities of the parties involved and a formal agreement
on the consequences of failing to meet the contractual obligations.
Risk containment, mitigation and transfer all cost money and this should
be taken into account in the budget preparation process.
Monitoring for transitions
Each risk factor will have one or more indicators that it is materialising
or has occurred – for example an intrusion detection system in the net-
work security perimeter is an indicator that one or more people are test-
ing the electronic defences of the organisation.
The earlier such transition indicators are seen, the greater the opportu-
nity to implement problem resolution and mitigation activities. The only
problem with this is that early indicators may be full of “false positives”,
i.e. not a manifestation of the risk occurring but something that looked
as if it might.
The manifestation of a risk leads to a problem, and while some problems
can be solved and closed without too much difficulty – for example, the
project manager for a large software development was suddenly taken ill
at a time critical to the project. Fortunately, the second in command in
the development team is fully briefed and quite capable of taking over for
an indefinite period of time as the team has sufficient resilience to be re-
configured to take care of this.
Other problems rapidly escalate into a crisis – they cannot be solved and
become highly disruptive and visible.
The executive’s role in managing risk

The purpose of taking risks in the corporate world is to extend an organ-
isation’s capabilities and build an advantage. Are any other risks worth
taking?
In today’s dynamics uncertainty
dominates all activities and oppor-
tunities abound for those who are
able to spot them. There are no
benefits without risk – as if that
was the case, they would have been
delivered long ago.
The success or failure of pursuing
an opportunity depends on its tim-
ing and whether or not it will be
successful will be defined by the degree of risk taking and the ability to
manage these risks of those who go forward.
Avoiding risk is of course possible but at the expense of giving up oppor-
tunities and the benefits they may bring.
Risk management, when treated as a discipline, brings forward three ben-

efits:
• It makes exposures to risk and other uncertainties explicit;
• It can be used to put limits on uncertainties but focusing on the worst
case, best case and most likely outcomes for events and projects;
• It increases the probability of success in exploiting opportunities.
These benefits are underpinned by two underlying assumptions: One,
that keeping quiet about risks and uncertainties will not make them go
away and two, that the alternative to risk management is to rely on “luck”.
Murphy’s law is definitely against anyone wishing to pursue this path.
The deep integration of ICT in the activities of
organisations prevents the Chief Information
Officer and other ICT people from managing
all the risks associated with ICT by themselves
– for example:
• Policies on what constitutes misuse and
abuse of ICT resources must have the ap-
proval of the Human Resources function
and possibly the Legal department;
• Business Continuity planning involves all functions of an organisa-
tion;
• Projects for new computer systems require a business sponsor – nor-
mally the person who will be the beneficiary of the outcome and, ide-
ally, accountable for achieving the benefits on which the case for in-
vesting was made;
• A senior person in the organisation, perhaps the Chief Executive who
made a statement to the media about a specific deadline which is un-
likely to be achieved and everyone else in the organisation needs to
engage in a best effort to avoid embarrassment (even if the project
fails, as was the case with the London Ambulance Service LASCAS
system some years ago).
Risk management may not always be compatible with certain organisa-
tional cultures:
Organisations that thrive on a “can do” attitude are stimulating environ-
ments to work in, particularly when there is a good dose of common sense
to balance enthusiasm and optimism with experience. Where this is
achieved, it is OK to be uncertain.
Where this balance does not exist, being uncertain is not acceptable (al-
though being wrong often is). These organisations will promote a loser
by stating that “Joe Bloggs made a superhuman effort to deliver” even
when proper risk analysis would have shown that Joe Bloggs never had a
chance to deliver because of the risks involved in whatever he had to
do…
In other organisations, there is a tendency to shoot the messenger if bad
news need to be delivered. Here the person raising concerns about risks
will be told things such as:
Why must you always be so negative?
Don’t say something is a problem unless you can prove it…
Don’t’ say something is a problem unless you have a solution for it…
Don’t say something is a problem unless you want it to become your re-
sponsibility…
In organisations that are unduly “careful” and risk averse, risk manage-
ment is largely irrelevant because the policy of risk avoidance is the most
likely to be pursued and it is politically incorrect to voice concerns about
risks.
Action points
Brainstorm potential risks to identify them, assess them and take appro-
priate actions.
If risk has not been well managed, consider applying the benevolent rule
that “Once is a mistake. Twice is a coincidence. Thrice is either careless-
ness or incompetence”, then act accordingly. Clearly there will be situa-
tions where a mistake should be dealt with before a “coincidence” oc-
curs.
Recognise that there is a real risk of loss of business and money as a re-
sult of shortcomings in information systems and the internal controls
built into them.
C h a p t e r
11
Information insecurity:
external risks
Fidarsi è bene. Non fidarsi è meglio.

(It is good to trust. It is better not to trust.)
Roman proverb
• What makes information security a hot topic that requires executive

attention?
• What are the specific non-technical issues of information security?
• Can information security be outsourced?
• Is your organisation adequately prepared to deal with abuse and crime
through ICT?
The need to protect information assets from unauthorised use, misuse and abuse has
grown as a result of reliance on interconnected networks, mainly the Internet to carry out
transactions with customers, vendors, partners, and with an increasingly mobile work-
force.
Cyberspace – the world of software and data – brings many opportunities to people intent
on stealing, copying or modifying data or simply disrupt the operation of networks, sys-
tems, websites and other electronic facilities. Hackers, crackers, scammers and organised
crime are all known to be active in these activities and, without managing the security of
its information assets, an organisation is exposed not only to loss but also to operational
disruption.
There are many tools and products to strengthen information security and there is an inter-
national standard – the ISO 17799 “Code of Practice for the management of information
security”. These are however, not enough. Executive action is needed to create an organi-
sational environment where these can be deployed and used effectively.
Importance of information security
Why should executives be concerned with information security? After all

this is a technical issue and the ICT department is taking care of this.
Right?
In the not too distant past, all of these questions would have had a sim-
ple answer: security was not a major issue dealt with by technical people.
What has changed in the last few years to require executive awareness
and support are:
• The sharp increase in the number of security incidents;
• the proliferation of devices connected to networks – notebook com-
puters and personal digital assistants with wireless connections
owned by the organisation but used away from its premises;
• product vulnerabilities, exploited by hackers and others with mali-

cious intent;
• working from home connected to corporate networks which can be
shared with family members and others;
• the many people other than staff given access to corporate networks
and systems: contractors, consultants, vendors, clients and other
stakeholders;
• providers of outsourced services, particularly software development
done in another country (“offshoring”)
What is a security incident? Anything that affects the availability, confi-
dentiality and integrity of information. This may be the result of mali-
cious code (virus, worm, trojan horse, logical bomb), coordinated attacks
(Denial of Service and e-mail avalanches), vulnerabilities in software,
weaknesses in the defences put in place and the Insider Threat: deliber-
ate action by people with legitimate access rights to computer systems
and to data.
The results of a security incident could lead to data and information be-
ing:
• Disclosed to unauthorized parties (insider trading and market ma-
nipulation)
• Stolen (theft of intellectual property and subsequent exploitation)
• Modified with intent to commit fraud, embarrass or paralyse an or-
ganisation
• Forged – impersonating an employee in e-mail or other transactions,
spoof websites
Computer networks and systems may be:
• Poisoned by injecting malicious software (virus, worm)
• Hijacked and misused by a remote individual (trojan horse, superus-
er rights)
• Sabotaged (logical bomb)
Availability is the ability to access information systems and facilities when so required;
Integrity is the degree to which it can be assured that when data (including software) is
created or modified, this is done by a person who has a legitimate right and the proper au-
thorisation to do so;
Confidentiality is the requirement that data is made available only to those who have the
right to access it.
Depending on their intent and severity, the outcome of a security inci-

dent can range from a nuisance such as the infection of hundreds or thou-
sands of computers that will take time and effort to restore to a clean
state, to the modification, disclosure or theft of information, fraud, black-
mail, sabotage and organisational paralysis.
Some of the nasty things against which protection is needed
Information security nasties Ease of protection
Virus and worms Easy

Trojan horse Easy to medium
Back doors Hard
Logical bomb Hard
Denial of service attacks and e-mail deluge Hard
Sniffing/breaking user ID and passwords Medium
Abuse of superuser rights Hard
Social engineering Medium to hard
When security is
not good enough
information assets
are at risk. This
matters because in
the Information
Age money is just
another informa-
tion asset – interbank transfers take place through electronic messages.
Treasury and accounting functions handle information, not cash.
Not all attackers are teenagers hacking for fun and not all hackers may
be outsiders. From a corporate perspective, the potential attackers to con-
sider are many:
Malicious insiders, the enemy within. They are particularly dangerous
because they have knowledge, legitimate access rights and possibly the
motivation to act. See Chapter 12.
External attackers who exploit the tools and techniques provided to staff
with remote access to systems and facilities. The chart shows how the so-
phistication of attack mechanisms and tools has grown over the years.
Becoming a com-
petent hacker is
easier than ever
before as the tools
and know-how
are readily avail-
able either free of
charge or for a
small charge.
It should be a
matter of concern
that major hacker conferences count their participants by the thousands,
while conferences for information security professionals conferences at-
tract, at best, a few hundred. This imbalance suggests that hackers are
better at sharing experiences and information (usually about their suc-
cesses) than corporate defenders (who would be disclosing their fail-
ures).
Hacktivists, people with a “cause” who use information security attacks
to gain visibility and the attention of the media;
Organised crime, with vast resources to put to play and operate for finan-
cial gain and there is no doubt that computer crime pays. The Associa-
tion of Fraud Examiners of the USA estimates that the average computer
crime involves sums in excess of 2 million dollars;
Industrial and other spies, who also have vast resources to put to play;
Military, intelligence services (from anywhere in the world) and cyber-ter-
rorists (assumed to exist). In an attack situation they may favour targets
such as critical infrastructures such as electricity, water, air traffic con-
trol, fuel distribution, central banks and emergency services. However,
the possibility that other organisations could be attacked cannot be ex-
cluded.
Issues for Executives
The ICT function is responsible for implementing measures to implement

suitable tools (such as firewalls, virus detection and intrusion detection
tools, authentication, etc) and ensure that the vulnerabilities of comput-
er systems are known, understood and dealt with accordingly. A good

CIO will focus on the implementation of technical protective measures
but this is not enough.
Every ICT vulnerability is the equivalent of an unlocked door waiting for
somebody to try to open it. It should be noted that while a Finance Direc-
tor is expected to sign the financial statements of an organisation and
have them audited, the CIO and other senior ICT people do not have to
sign anything, for example a statement regarding the security of comput-
er systems, networks and data and ICT audits.
The Gartner Group, an ICT industry research and advice company, re-
ported in 2004 that the combination of the number of security breaches
and the need to protect data has put security at the top of the list of issues
of concern to business executives.
Many aspects of preparation, re-
sponse and validation require ex-
ecutive participation to be effec-
tive as the security chain needs to
be strong – this chain is meant as
a reminder of the importance of
all the parties exercising their ar-
eas of responsibility.
Preparation
Issue # 1: How much security?
Security must never be an afterthought. A fact of corporate life is that se-
curity implies costs and inconvenience. Because of this the question of
“How much security should be put in place and how much cost and in-
convenience are appropriate” in a specific environment is entirely legiti-
mate.
The answer should be given by executives and not the Chief Information
Officer or other technical person: the result of delegation will be either
an incomplete answer and, possibly, inappropriate solutions based on a
“mindless pursuit of perfection”.
Costs need to be incurred to acquire equipment, software, facilities and
employ people to manage them. It is possible to outsource the operation-
al aspects of security in the same way that physical security is outsourced
to companies who specialise in this. The lifecycle costs of security also
include those of validation tests (usually involving third parties), consul-

tancy and audits.
Each security measure results in inconvenience – physical and logical ac-
cess controls, the need to remember multiple passwords and/or carry a
special device (e.g. a smart card), restrictions on what can and cannot be
done (sending or receiving attachments to an e-mail).
When the inconvenience associated with such measures becomes too
much, people will seek shortcuts to make life easier. This is why it is com-
mon to find Post-It™ notes on computer screens showing passwords, a
practice that makes security measures useless.
The identification of security needs, the definition of what information
assets to protect and to what degree must be driven by the activities of an
organisation and the impact that an incident could have on its operations,
performance and reputation.
The sophistication of the protective measures (always reflected in their
cost and complexity) needs to be balanced against the residual risk that
an organisation is able to consider acceptable as 100% security cannot be
achieved.
Residual risk is a measure of the extent to which
- the value of the infor-
mation assets
- the threats against
them
- the vulnerabilities of
the systems, networks,
etc through which they
can be accessed
- the effectiveness of
countermeasures put
in place
combine to increase the ro-
bustness with which a security incident can be dealt with.
There are no absolute scales for ranking residual risk. However, taking
an arbitrary scale from zero to ten (zero = absolute minimum residual
risk), emergency services, the military organisations involved in e-com-
merce, financial institutions, etc would normally be expected to seek lev-
els of residual risk between just over zero to no more than three.
Critical infrastructures would be found at the three to five level while gov-
ernment departments and others where continuous operations are less
critical can accept higher levels of residual risk. The process through
which the parameters that determine the level of protection to be sought
is known as Business Impact Analysis (BIA). Such analysis is a compo-
nent of a disaster recovery and business continuity planning (Chapter
13).
Many steps have been taken in the last few years to facilitate the manage-
ment of information security, notably the international standard ISO
17799, “Code of Practice for the Management of information security”.
This short and readily understandable code of practice confirms that
technology plays a partial but important, role in the management of se-
curity.
The ten sections of ISO 17799: “Code of Practice for the Manage-
ment of Information Security
1. Develop and implement security policies
2. Put in place a security organisation
3. Maintain an information asset classification
4. Address personnel issues of security
5. Implement physical and environmental security
6. Ensure adequate network and computer operations
7. Implement system and network access controls
8. Build security into systems development
9. Have disaster recovery and resumption plans
10. Comply with legislation and best practices
Issue # 2: Security policies and awareness programs

Policies and the awareness programs designed to support them remove
“I did not know” as an excuse for breaching security. Security policy tem-
plates are available from many sources and can be readily adapted to meet
any specific needs. A typical list of the topics covered in a good security
policy includes:
• Acceptable personal use of corporate resources (equipment, systems,
data);
• Rules for downloads and for the installation of software;
• Rules for the corporate and personal use of electronic mail including
attachments;
• Rules for the corporate use of mobile computing and networking;
• Creation, change and management of passwords or other authenti-

cation mechanisms;
• Rules for granting access to computer systems, data and other re-
sources;
• Database administration, superuser rights and related activity logs;
• Segregation of duties for critical activities relating to systems, data-
bases and data;
• Employer’s right to monitor the activities of individuals with access
to systems and data;
These policies must be written in a concise and easy to understand style.
They must comply with national legislation and be communicated to all
parties involved. It is usual practice to ask individuals to sign a statement
that they have received the policies, understood them and agree to com-
ply with them.
Information security policies will only be as good as the degree to which
people comply with them. It is good practice to include a statement in the
policies concerning the right of the employer to monitor activities and the
actions that might be taken in the event of non- compliance.
Building awareness of security issues across an organisation is the only
way to overcome the misuse of social engineering.
“Social Engineering” is often used to bypass security. This involves the abuse of good will
that some people will exhibit when asked nicely to be helpful and the unaware will happi-
ly lend access to a networked computer to a complete stranger, provide a password over
the phone to somebody pretending to call from the help desk, and provide other informa-
tion in response to a question.
Issue # 3: Clear accountability for information security

There is the story about a job that had to be done. Four characters were
around, their names: Anybody, Somebody, Everybody and Nobody. What
happened was that… “Everybody knew that the job had to be done and
thought that Somebody would do it. Anybody could have done it but in
the end, Nobody did it.”
To avoid this situation, ISO 17799 recommends having a security organ-
isation in which responsibilities are clearly assigned. One person with the
title of “security officer” will not be enough other than in very small or-
ganisations as the responsibilities for information security are large and
distributed an organisation:
Security of the ICT infrastructure – including physical and logical access,

anti-virus and similar software, installation of patches to address known
vulnerabilities, authentication mechanisms, firewall configuration and
other technical activities. These may be the responsibility of an in-house
ICT function (centralised or not) or that of an external service provider
when operational ICT activities are outsourced.
Security of data and databases – against the corruption or unauthorised
modification of data, against misuse of data by individuals not be enti-
tled to access certain types of data, etc. This should be the responsibility
of data and database administrators who may report outside the ICT
function.
Access rights to computer systems and facilities – to ensure that these are
used on a “need to do” and “need to know” basis. Such access rights would
normally be assigned by the systems’ owners and include a definition of
which system functions and data may be granted to an employee, depend-
ing on the latter’s role in the organisation. For example in a bank, an em-
ployee may only have access to the account information of clients at a par-
ticular branch assigned to this particular employee.
Identity management – complements the access rights in the previous
paragraph by establishing the means to ensure that the people who ac-
cess a computer system are in fact who they claim to be and not some-
body else who has acquired a valid ID/ password or other access mecha-
nisms.
Equally important is the assignment of “superuser rights” – such as a se-
nior level system administrator, as these rights give unlimited access to
functionality and data and can represent a major exposure if misman-
aged or abused. The assignment of such rights and their subsequent man-
agement should be the responsibility of a very senior functional manag-
er (HR, Finance, etc) and most definitely not reside in the ICT function
or with an outsourcer.
Issue # 4: Malicious insiders (see also Chapter 12)
There are two types of malicious insider: the electronic type, consisting
of software installed by a hacker, vendor, contractor, consultant, employ-
ee or anyone else who at some time had something to do with a comput-
er system or network and who built in a facility to gain access at a later
time. This can take the form of a backdoor, a trojan horse, a user ID and
password not known to or controlled by a system administrator, an un-
known superuser and other creative means.
Combating this type of insider requires much effort, including indepen-

dent reviews of computer programs, specialised audits and systematic
testing to uncover such features. Not easy and not always successful when
these elements are planted by experts.
The other type of malicious insider is a person with access to computer sys-
tems, networks and facilities. The definition of an “insider” has become
more complex than it used to be as it now includes interns, consultants,
contractors, outsourcers and sometimes clients or other stakeholders.
An often forgotten “insider” is the person who has left the organisation
but whose access rights have not been removed. This happens when the
separation procedures of the HR department do not include notification
and instructions to the ICT function and other system access rights own-
ers to remove these people rights at a given date or when the ICT func-
tion is busy and postpones these tasks until “mañana”.
As insiders already work within the security perimeter, firewalls and oth-
er such techniques are not relevant amd a malicious insider will act with
premeditation. A smart insider will not give obvious signs that an attack
is planned and there are many instances of fraud where such activity took
place over a considerable period of time. Others, behaving with anger, ar-
rogance or stupidity will give ample indications that should be taken as
a warning.
Such warnings could be dissatisfaction or poor morale evidenced in con-
versations or e-mail messages and also access (or attempted access) to da-
tabases or computer systems they are not supposed to have access to. The
UK government’s national security agency, MI5, provided a set of guide-
lines for managing the “insider” threat – these are at http://mi5.gov.uk/
print/Page58.html
Implementation and response

Issue # 5: The organisation’s metabolic rate
Information security incidents, external or internal, take place dynami-
cally. Malicious code such as the BigF or Blaster worms, infected millions
of computers in just one day. Denial of Service attacks, even when an-
nounced in advance, happen quickly and do not always follow a predict-
able pattern.
Some attacks are the result of known problems for which preventive mea-
sures exist, for example vulnerabilities in products for which the vendor
provides the mechanism to remove such vulnerability. Prevention is al-

ways better than such cure but cannot always be implemented quickly
enough. Sophisticated attackers perform attacks in novel ways, creating
an unknown problem.
In these situations, if the attack is slow as evidenced by intrusion detec-
tions showing attempts to penetrate a network or a system, an organisa-
tion may be able to respond to the attack through technical measures.
When the attack is fast and its techniques constitute an unknown prob-
lem, there is a real threat to the target organisation. How well it is able to
respond depends on its culture’s metabolic rate.
An organisation with a fast metabolic rate is able to deploy additional
staff or expert advice at short notice, purchase and install additional
equipment and software with minimal delay and generally allow individ-
uals to act with a good level of empowerment.
Organisations with a slow metabolic rate cannot do any of these things quick-
ly. Purchase orders may require approval by a contracts committee, engag-
ing a consultant may only be done with the formal approval of the Chief Ex-
ecutive, there may not be budgetary flexibility to engage in unplanned ex-
penditures, etc. These are barriers to good information security.
Issue # 6: Ability to act when the worst happens
The proverb “expect the worst and you will never be disappointed” is not
always practiced in corporate life for any of many reasons – not enough
time, not enough staff, not a sufficiently high priority, too expensive and
organisational culture.
There are organisations for which the risk of becoming paralysed by a
natural disaster, civil disorder or terrorism or by an ICT disaster, is not
considered serious enough to invest in appropriate measures to ensure

continuity. An ability to act effectively and mitigate the risk of such events
contains three major components:
• A disaster recovery plan
• A business continuity plan
• A crisis management plan
The disaster recovery is the responsibility of the CIO. Such a plan should
be documented, kept up to date to reflect changes in the ICT infrastruc-
ture and facilities and regularly tested to be of any value the day it needs
to be invoked.
One important part of such a disaster recovery plan is the existence of an
Emergency Response Team and its appropriate backup. This team should
be contactable at all times and be fully versed in their roles and respon-
sibilities whenever the disaster recovery plan is invoked.
Disaster recovery plans aim to restore at least partial ICT facilities in a
short period of time that can range from an hour or less in the case of
highly critical systems to a few days. The shorter the recovery period, the
higher the cost of implementing disaster recovery capabilities. In extreme
cases, when the recovery period is very short, it requires a fully duplicat-
ed ICT facility at a different location operating in hot standby.
The executive’s role in disaster recovery is to ensure that adequate re-
sources (financial and human) are made available for this activity and
that such plans and their tests are independently audited.
Business Continuity builds upon a disaster recovery plan to enable an or-
ganisation to continue its activities after a disaster of any kind. This in-
volves having suitable arrangements for alternative office accommoda-
tion, the nomination of critical functions that must be recovered first and
the individuals responsible for doing so. An inability to provide adequate
business continuity may prove catastrophic for an organisation, not only
commercially but also in terms of its reputation and public image.
Crisis management is an executive responsibility that cannot be delegat-
ed to the ICT function which is primarily about communications with
staff and other stakeholders in a “war room” environment, as well as deal-
ing with the media.
Validation
Security arrangements that are not tested or validated may turn out to be
less effective than hoped for and independent validation is the mecha-
nism that executives can adopt to increase their confidence that their in-
formation assets are adequately protected.
Issue # 7: How far should validation be taken?
A scenario where there is no validation relies on the CIO (or most senior
security person) stating that “everything is fine”. This is a courageous ap-
proach as it may prove untrue when the time comes. An improvement
can be obtained when the CIO and other computer system owners pro-
duce a signed statement recording all known vulnerabilities and their as-
sessment of the threats faced by these systems, although this is not yet
common practice.
The introduction of the Sarbanes - 0xley Act in the USA, making direc-
tors personally responsible for the accuracy of corporate information, is
likely to increase the need for transparency and accountability for infor-
mation.
Ethical hackers are information security specialists with a reputation for
integrity and who work for respectable, well established companies. Eth-
ical hackers can test the security arrangements of an organisation, or at
least specific computer systems. Such tests usually involve breaking into
systems to retrieve an agreed data file. There are informal claims that
ethical hackers are successful in more than 80% of cases but companies
engaged in this kind of work favour non-disclosure.
Security consultants are engaged to review the arrangements made for in-
formation security. They can be expected to be familiar with best prac-
tices across many organisations and to provide advice on opportunities
for improvement.
By the time they concluded their activities, ethical hackers and security
consultants are likely to know more about the security arrangements of
an organisations that the people working in it, and therefore trust be-
comes a fundamental issue.
Certification of Information Security professionals and practitioners.
There is a growing trend towards certification schemes such as those pro-
vided by the International Information Systems Security Certification
Consortium (ISC)2 (www.isc2.org) a not-for-profit organisation that pro-
vides two levels of certification: CISSP, for information systems [IS] se-
curity professionals; and SSCP, for information systems security practi-

tioners.
Other organisations, usually commercial, offer certification schemes for
compliance with ISO 17799, based on comprehensive audits of the imple-
mentation of the ten sections of this Code of Practice and on the British
Standard BS 7799 Part II.
Issue # 8: Digital forensics
Security incidents are common events, but most of them tend to have lit-
tle impact on the operational activities of an organisation. They include
intercepted viruses and worms, multiple attempts to logon to a system
using an incorrect ID or password, etc. From time to time, such incidents
will cause real disruption or result in unauthorised activities or fraud.
Investigating such events requires knowledge of digital forensics which,
being relatively new and influenced by national legislation as to what con-
stitutes acceptable evidence, does not yet have many practitioners.
Organisations can invest in specialised software to monitor and track ac-
tivities in information systems to provide material for review after an in-
cident and to collect evidence. Such products are complex and hard to use
effectively without extensive training.
The use of such software raises an ethical question – should the people
working in the organisation be advised that their use of systems and fa-
cilities is monitored?
The current choice for such investigations remains working with consul-
tants and, when appropriate calling on law enforcement agencies, in or-
der to ensure that the evidence acquired can be used as evidence in a
court of law.
Issue # 9: Dialog between executives, technical staff and the auditors
Although last in this list, but important, is the need for effective dialog
between executives, technical staff and auditors on matters concerning
information security before something goes wrong.
The absence of such dialog, will result in a lack of clarity as to who is re-
sponsible for what, what could be interpreted as dereliction of duty and
a focus on blamestorming.
Action points
The successful management of information security requires components

that only executives can put in place: policies, monitoring and compli-
ance. The ICT function will be handicapped if these are not in place or
are not effective and will be unable to protect the organisation’s informa-
tion assets.
Encourage the ICT function to adopt the international standard ISO
17799 and to seek independent validation of their information security
arrangements through audits and ethical hacks. Also ensure that the
skills available within the ICT function are appropriate and up to date to
successfully manage information security.
Information security should be everybody’s concern and executives
should ensure there is adequate awareness of these issues across the or-
ganisation as a whole.
C h a p t e r
12
Information Insecurity:
The insider threat
Hiding in plain view:
Place a tree in a forest – it becomes invisible.

Place a rock in a quarry – it becomes invisible.
Place a dishonest person within an organisation…becomes invisible.
• Which abusive, fraudulent and criminal activities that could affect an

organisation would be easier to commit from the inside?
• How difficult is it to acquire the knowledge needed to perform fraud-
ulent and criminal activities using information systems and technolo-
gy?
• Who is an insider in a modern corporation and what could motivate an
insider to act in a fraudulent or criminal manner?
• What steps can an organisation take to protect itself from such acts?
• What are the problems and limitations that such protection needs to
address?
The answer to the question, “Which abusive, fraudulent and criminal activities that could
adversely affect an organisation would be easier to commit from the inside?” is an easy
one: ALL OF THEM.
The Association of Chartered Fraud Examiners and many other bodies have highlighted the
fact that fraud and other forms of electronic misconduct are taking place in organisations
and are often undetected.
While most forms of electronic misconduct are variants of well established schemes, the
combination of access rights to computer systems, knowledge and opportunity, coupled
with the perception that computer crime is hard to detect, there are grounds to deal with
these matters in a stricter manner than hitherto, particularly in financial institutions and in
critical infrastructures (electricity, water, air traffic control, etc) due to the risks of infiltra-
tion by organised crime or by agents of terrorist organisations.
Electronic Misconduct:
abuse, fraud and crime through ICT
Abuse of IT resources in the workplace arises when these are used for pur-
poses unrelated to an individual’s work. Such abuse ranges from using
corporate e-mail for personal matters to producing during working hours
translations or developing software unrelated to the employer.
Abuse is most likely to occur where there are no formal, clear policies on
what constitutes appropriate personal use and where employees know
that there is little or no monitoring and no sanctions if the policies are
breached.
Computer crime, which includes fraud, involves breaking one or more

laws through the use of ICT. This is commonplace, not difficult to com-
mit, hard to trace and harder to prove. Activities that can be described as
computer crime can be grouped in three categories limited by the creativ-
ity of the perpetrators. The lists here are not comprehensive:
Theft and espionage
• Financial gain through improper manipulation of systems (payroll, pen-
sion, annual leave, procurement, treasury, non-legitimate invoices);
• Gaining access to networks and/or systems without authorization to
extract information;
• Intercepting data flowing through a network (also known as network
sniffing);
• Unauthorised transmission of data or information to a third party
that has no right to it;
• Unauthorised disclosure of information (documents, data, software
code, etc);
Sabotage
• Unauthorised modification, theft or corruption of data and soft-
ware;
• Damage to ICT infrastructures and software;
• Introduction of malicious code into computer systems and networks
(spyware, virus, worm, logical bomb, trojan horse and other such
programs);
• Facilitating or organising a denial of service attack;
Deception
• Abuse of social engineering to obtain access to networks and sys-
tems;
• Impersonation, including e-mail and website spoofing;
• Aiding and abetting fraud or illegal activities;
• The introduction of undocumented functions in system software that
could be used to provide access to systems bypassing normal access
controls or cause the system to malfunction at a desired time;
• Taking over control of a computer assigned to (or owned by) a per-
son with legitimate access rights.
While the above may appear difficult to the uninitiated, the truth is that
the skills and tools needed to do them are easy to learn and acquire. The
community of hackers and other players is organised to share informa-
tion and tools and many websites specialise in this. They are available in
many countries and in many languages.
Not all hackers have criminal intent and many work as security experts
and consultants. To learn the tools and techniques to be a hacker, there
are also books, articles, CDROMs and software on how to act like a hack-
er. Knowing how to be a hacker is not an offence. Only being caught do-
ing something illegal is, and then only if it can be proven in a court of
law.
Less easy is learning how to think like a hacker, as this requires creativ-
ity (which can be learned) and a certain willingness to take risks by dis-
regarding policies, rules, regulations and legislation. The expression that
“you need a thief to catch a thief” also applies to cyberspace.
In addition, hacker conferences bring together large numbers of like-
minded people, ranging from the anti-social element to the intelligence,
defence and police community who go there to learn and recruit. One of
the largest and best established of such conferences is the annual Defcon
event in Las Vegas.
The digital world makes many things “invisible” and many forms of cyber-
crime, if done subtly, can be committed over long periods of time without
anyone being aware of them. The Association of Certified Fraud Examin-
ers estimates that 85% of such crimes are committed by insiders – and con-
firms that these insiders are well informed and smart individuals.
Who is an insider?
Clearly the employees of an organisation are insiders. But this is the be-
ginning of a long list of people who, for various reasons, are given access
to networks, data and systems:
Temporary employees – sometimes supplied by an agency, interns (such
as university students doing summer work related to their studies), con-
tractors working on a project for the organisation, consultants and exter-
nal auditors engaged for specific tasks that require them to spend time
within the organisation.
Then, there are security personnel, building maintenance and cleaners

who have access to the organisation’s premises at various times and main-
tenance technicians from various ICT vendors who have access to com-
puter rooms.
Another challenge to organisations with valuable information assets
(such as financial transactions) is that of organized crime: Computer
crime is easier and less risky than going into a bank with machine guns.
Organized crime is aware of this and also of the fact that the security de-
fences of an organisation are more effective from outside than from the
inside.
A plausible scenario would identify smart young people, whose studies
in a prestigious academic establishment are sponsored (such studies
would include computer science) and encouraged to join target organisa-
tions. Once on the inside, this person becomes the equivalent of the Illi-
ad’s Trojan horse, waiting for the right opportunity.
The final category are visitors with good social engineering skills. In the-
ory, such visitors are somebody’s responsibility in the organisation, but
some are willingly taken to visit a computer room and, depending on the
security culture of an organisation, they may be allowed unescorted ac-
cess to office buildings. A polite, suitably dressed person can take advan-
tage of the basic human inclination to be helpful to gain a considerable
amount of confidential information through friendly dialog and sharp
observation.
Experience shows that it is not difficult to persuade an office worker to
lend their computer to such a visitor on the grounds of some “urgent
need” and when the level of security awareness is low, the worker will not
log out of the systems being used and thus give a stranger access to the
network from within the security perimeter.
How is extrusion done?

In a series of articles published in Computerworld in
the early part of 2004, Danny Lieberman, of the com-
pany OSI-Open Solutions, Israel, introduced the con-
cept of “extrusion” as the counterpart to intrusion.
In the first of these articles he retells the old joke about
the cement factory from which every day, a worker
leaves at closing time with a wheelbarrow of sand. Af-
ter a month of this, the guard finally says to the work-
er, “I know you’re stealing something; I just can’t figure out what it is.”
The worker replies, “I’m stealing wheelbarrows.” Extrusion is the unau-
thorized transfer of your assets in broad daylight.
Doing this could be as easy as 123… and the stages involved are shown
below:
Infiltration is not always difficult – it is determined by the extent to

which checks about individuals are conducted prior to employing them
and giving them access rights to networks and computer systems.
Several activities relating to infiltration should be seen as cause for con-
cern, in particular:
• Background checks and references are not carried out uniformly –
they may be quite extensive for the appointment of a new employee
but minimal or even non-existent for getting temporary assistance
from an agency, from a vendor or from an outsourcer;
• Lack of awareness by insiders of the need for confidentiality with re-
gards to network and systems access, systems documentation, pass-
words and other tools. This includes the practice of logging out of all
systems and locking a workstation before leaving the office – even if
for a very short break;
• The practice of allowing visitors unescorted access to offices and
computer rooms.
Exploration can also be simple to conduct through social engineering.
Its objective is to gain a good understanding of what systems exist, who
has access to them, how they are secured, who has documentation on
them and gather other information that would in due course allow a per-
son with intent to access and/or take control of such systems.
The practice of allowing remote access to systems to certain people cre-
ates an opportunity for a hacker to gain access to these systems by tak-
ing over control of the mobile or home computer of a targeted authorised
user – this is basic.
While the computers on the corporate network may be adequately pro-
tected by software and hardware, this is not always the case for home
computers which may not have the latest version of all corrections (patch-
es) to software, not fully uptodate antivirus software and more impor-
tantly no tools to detect spy code (that could capture the key strokes need-
ed to log in to a system) or trojan horse software that allows a hacker to
use the computer as their own without the knowledge of the owner.
Once a hacker has established a base of operations within the network
(which could be from outside the premises), it becomes possible to plan
and covertly execute any of the activities listed in this section, with a good
chance that such activities will remain invisible unless discovered by
chance or by a whistle blower.
Exporting data out of an organisation has become easier because of the
ever decreasing size of media – a memory stick with a capacity of up to 1
gigabyte measures roughly 6 cm in length, 1 cm in width and 6 mm in
thickness (and is inexpensive). In organisations where insiders can access
the internet, it is also possible to exploit what is known as a “reverse HTTP
channel” in which the insider’s computer is acting as a server instead of
as a client, and this can be used to transfer substantial amounts of data
invisibly.
The motivators that drive the insider threat
Lack of awareness (or stupidity)
The most common and dangerous insider threat comes from people with
good intentions but no understanding of the consequences of their ac-
tions.
Common instances of their actions are password sharing, giving some-
one else the information needed to access a network and one or more
computer systems. A frequently found form of password sharing consists

of writing this information on a Post-It™ note and placing it in a visible
place, such as the edge of the screen. This makes it easy for an opportun-
ist to impersonate them. Social engineering, already discussed, exploits
peoples’ willingness to be helpful.
Emotion
In a living organism such as an organisation not every worker will be hap-

py all the time. Well adjusted individuals accept this as the rougher side
of one’s working life. Others, however, may be driven to “punish” those
who make them unhappy, and the potential invisibility that can be gained
through ICT, makes it attractive.
With a minimal amount of technical skill it is possible to send anony-
mous e-mail messages (by creating a fictitious name on a free web-based
service such as Yahoo mail) with the intention to harass, offend or ma-
lign a target. If a person is able to gain access to a colleague’s computer
left logged on and not locked, this can be used to cause trouble for the in-
dividual by sending messages that would appear to come from this indi-
vidual.
More technically skilled people will be able to introduce software into a
network or computer application (and ICT personnel are in an excellent
position to do so) to disrupt the network and/or corrupt data. Such soft-
ware is referred to as a logical bomb. There are many other possible forms
of sabotage…
Executive dilemma:
Suspicion of a malicious insider
A highly successful company in the financial sector conducted studies to-

wards the re-engineering of their business operations. This would result in
streamlined services with a reduction in the workforce and therefore cost.
The re-engineering would involve the outsourcing of the ICT function.
At about the some time, the Chief Finance Officer had a feeling (but no
evidence) that someone in the organisation was acting to commit (or had
committed) fraud.
Because of the proposed re-engineering there were many disgruntled em-

ployees that could cause damage to the company through sabotage and
using this to create a crisis of confidence by alerting the press, leading to
a loss of reputation from its high level position in the marketplace.
In the absence of evidence, how should an executive approach the situa-
tion and, if the company does not have the appropriate level of expertise
in e-fraud, what options do they have?
Gain
The assumption that every organisation has a (small) percentage of dis-
honest staff is confirmed by experience. It is generally hard to tell where
appropriate use of corporate resources ends and dishonesty begins. For
the purpose of this discussion, “gain” is meant to represent substantial
financial amounts. All categories of fraud fall in this category, and collu-
sion with third parties is not uncommon.
Examples of malicious insider actions

There are hundreds of recent examples of malicious insider actions. The following three are
fairly typical of such activities:
A 24 year old employee of America Online Inc., was arrested in the United States of Amer-
ica on federal charges of stealing 92 million e-mail addresses that were sold to spammers.
An employee of Teledata Communications (Long Island, NY, United States of America)
stole 30,000 consumer credit reports listing mortgage information, credit card numbers
and many other personal details.
A disgruntled employee of the Queensland (Australia) Water Authority released 1 million
litres of raw sewage into the grounds of the Marriott Resort. Tried and sentenced on 46
charges of hacking, the person was given a sentence of two years in prison.
Executive Dilemma:
What shall we do about Susan?
Susan, a trusted employee who has been with a major healthcare servic-
es firm for 15 years had an argument with a supervisor and was forced to
leave the company under less than pleasant circumstances.
Shortly afterwards, her former colleagues and others complain that their
passwords on certain corporate systems, including the e-mail system are
no longer working. It is known that Susan had knowledge of those sys-
tems, including default or known passwords, and there are suspicions
that she has used that knowledge to access components of those sys-
tems.
In an effort to resolve the situation, IT management issues an urgent re-
quest for employees to change their system passwords. Some respond ap-
propriately and change their passwords; others ignore the request. So far,
three issues have emerged:
• The organisation’s policy regarding removing employees’ access rights
to systems when they leave is not being followed. The same is true for
the policy requiring employees to change passwords regularly;
• The organisation appears to allow the use of corporate applications
that rely on default or hard-coded passwords at the system level. This
means that critical application functionality will fail if the passwords
are changed and this is a major vulnerability. Should there be a pol-
icy restricting systems from using hard-coded passwords or requir-
ing implementation teams to change default passwords prior to go-
ing live with systems. What should such a policy look like?
• The decision to shut down compromised systems or disconnect them
from the Internet must be considered. Who should be the party re-
sponsible for making that decision, and does it address the impact of
that decision on business?
Because Susan had gained illicit access to the e-mail system, the poten-
tial exists that other applications may have also been compromised, for
example the firm’s online subscriber information database. Some of these
applications may have default passwords that are crucial to their opera-
tions.
If Susan knows these default passwords, she also may know other em-
ployees’ passwords to these applications.
As a response to this potential issue, programmers and vendors for the
potentially compromised applications are contacted. They report that
changing certain passwords on some systems is possible; however, it will
take a month or more to make necessary programming changes and con-
duct remedial testing. The one-month time frame will affect the avail-
ability of the applications—perhaps even requiring that they be taken of-
fline, which would necessitate a public explanation. This time frame will
require adjusting the priorities of the current IT staff, thereby affecting
the timeline of other projects currently underway.
Meanwhile, system and security administrators have put extra resourc-
es into determining how Susan is accessing Internet systems, but have lit-
tle to show for their efforts. Some of the organisation’s information sys-
tems are configured to log activity; others are not. However, even those
systems that log information are only logging certain events, for exam-
ple, failed logins.
They offer nothing in this situation because the ex-employee is not fail-
ing to log in; she knows passwords and she knows the system’s “back
doors.” She knows where the system’s holes are, which means she could
change security configurations on the systems and no one would know.
This raises the following additional issues:
• There are no implemented policies for logging security events on all
systems or for accountability with regard to monitoring those sys-
tems.
• Without knowing which systems have been compromised, the organ-
isation cannot learn whether data has been modified, stolen or delet-
ed, or whether sensitive or critical information, such as customer
data or information regarding business partners, has been compro-
mised.
Five days have elapsed since the first security breach was discovered. Su-
san is still accessing corporate systems and changing employee pass-
words. She has hijacked the e-mail account of a current employee and uses
it to send an internal e-mail to management. This e-mail, appearing to
come from a current employee, complains that the ex-employee was “let
go” unfairly and “did nothing wrong.”
The issues under discussion have become broader in tone, and more ur-
gent:
Activating the business continuity or disaster recovery plans is consid-
ered. The decision to contact law enforcement is considered, as well as the
public relations ramifications of taking that step. What might these be?
Susan sends another e-mail to selected company managers, this one con-
taining an agenda. It reveals that for some time she was frustrated by the
firm’s lack of security and that “no one listened” to her attempts to ad-
dress it. Now, she has their attention. The e-mail further reveals that she
is in possession of patient healthcare histories and intends to disclose the
information to the public, just to show how insecure the company’s envi-
ronment is.
At this juncture, the scenario could move in several directions. However,
the point has been made that the well-being of the organisation has been
placed in grave jeopardy by the actions of one person who may have lim-
ited but critical knowledge of the system and perhaps only ordinary com-
puter skills. This scenario is genuine (the names of the parties and the in-
dustry have been changed) and it could be played again anywhere and
anytime.
Key issues arising from this dilemma:
• Would the digital security program currently in place have the re-
sources to find the necessary answers, and do so in a timely and or-
ganized fashion?
• Would prior decisions made by executive management about digital
security empower or hinder those responsible for digital security as
they sought to find solutions?
• What would it cost to address this scenario?
• What would shutting down a busy website for 24 hours cost in terms
of lost revenue, not to mention the damage to the organisation’s pub-
lic image?
• What are the legal ramifications of having sensitive private informa-
tion publicly released?
• What would it cost to have system administrators spend hundreds of
hours investigating the incident and rebuilding compromised sys-
tems?
• What would it cost to have administrators and senior management
spend dozens or hundreds of hours in meetings during and after the
incident?
• What would it cost to have the public, government and media rela-
tions departments spend hundreds of hours working on damage con-
trol plans and collateral materials intended to restore decreased cus-
tomer and shareholder confidence?
• How much will the stock price drop, and how long will it take to re-
bound?
• Worst of all, what if such an attack happens again before the organ-
isation has a new program in place?
Preparing for protecting

against insider threats
What can an organisation do to manage the risk of computer crime?

There are four stages of action that come under different areas of man-
agement.
Stage 1: CULTURE AND DETERRENCE: policies and compliance

Organisational culture defines the level of deterrence. Organisations that
accept that appropriate personal use can be taken to mean generous, and
those where there is a high degree of tolerance for “flexibility and initia-
tive” when these are used to benefit the person rather than the organisa-
tion, will find it difficult to establish credible policies and compliance
rules.
Ideally, every organisation should have clearly formulated and widely
communicated policies on at least the following:
1. Appropriate official and personal use of the organisation’s ICT as-
sets:
Covering the computer systems of the organisation and facilities such
as office software, internet access, electronic mail (corporate and per-
sonal), telephones, etc., these policies must make it clear what is per-
mitted and what is considered to be inappropriate, indicating the
owner’s right to monitor activities and the actions that might be tak-
en if such policies are breached.
It is common practice to require employees, contractors and others
given access to ICT assets to acknowledge receipt of the policy and to
agree to abide by its terms.
2. Authentication
These are the mechanisms through which an end user is identified
and accepted by computer systems. The most common practice re-
quires users to provide something they know: a “user name” and a
“password”. Other, stronger, mechanisms may include something
they have (like an USB key or smart card) or something they are (fin-
gerprint or eye scan).
Authentication policies specify the level of protection given to sys-
tems and data. These are implemented through one or more tech-
niques in order to prevent the disclosure and/or sharing of anything
that may facilitate access to systems by unauthorised persons.
When passwords are used, there is a need for password rules (mini-
mum length, composition, not to be written down or disclosed to oth-
ers, frequency of change). Passwords should also be regularly changed
without cycling or repeating passwords.
3. Access rights to organisation’s systems and data
This policy defines an organisation’s philosophy to access to systems
and data. The two most common positions are: “Limited access to
specific systems, otherwise access to everything else” and “Access on
a Need to Know basis and to nothing else”.
The first is typical of organisations with relaxed attitudes to securi-
ty. The second is found in security conscious organisations. The need
to know approach has implications on the design of systems and da-
tabases by requiring classification (into public, restricted, confiden-
tial, etc) and segregation of data to ensure people only have access to
the data strictly required to perform a particular function.
Organisations should also make distinctions between access rights
for staff, employees with temporary contracts, interns, contractors
and consultants. If these distinctions are not made, the protection of
systems and data may be considerably weakened.
4. Fraud and impropriety
A formal policy that specifies what is considered to be appropriate
use of the data, computer systems and facilities of an organisation.
This policy describes in appropriate detail activities that are consid-
ered to be an offence and as such be the subject of investigation and
disciplinary action. For example:
Is an unauthorised alteration of an annual leave record fraud?
Is removing a CDROM with copies of the organisation’s data an of-
fence?
Is allowing unauthorised access to personnel data an offence?
The preparation of such a policy can be assisted by consulting recent

legislation ranging from the UK’s Computer Misuse Act to the Coun-
cil of Europe Convention on Cybercrime and the European Union Di-
rective on Data Protection.
5. Recognition of computer crime in audit strategies and methodolo-
gies
Computer crime has become a major concern to most organisations.
Organisations that do not have audit strategies and methodologies
that cover computer crime, in particular expertise and tools in digi-
tal forensics, will be in a weak position to detect and investigate fraud,
let alone ensuring that business processes contain the necessary con-
trols to prevent it.
6. Monitoring for compliance with policies
In the absence of monitoring and compliance, the value of policies is
reduced to removing the excuse “nobody told me” when someone
commits an infraction.
Monitoring and compliance policies are delicate matters as they come
into conflict with employees’ rights to privacy and confidentiality.
Such policies will differ significantly from one organisation to anoth-
er, ranging from “do nothing” to very tight monitoring of all.
7. Personal references and validation of credentials
In the modern enterprise, employees represent just a proportion of
the workforce with growing reliance on temporary staff, agency staff
and contractors, consultants and vendors all of whom are provided
with access to computer.
Having provided a person with a valid user ID and access rights, it is
possible to work on the assumption that everyone is a well inten-
tioned person who would not consider harming the organisation or
acting improperly for personal gain or satisfaction. This is unduly
optimistic.
The UK Government’s MI5 (Security Service) provides some useful
guidelines in their website on dealing with “Managing Staff Secure-
ly – The “Insider” threat”.
Moreover, in some areas of activity regulations require that all staff,
regardless of whether they are permanent or temporary, be verified
to be “fit and proper” to perform their assigned role in the organisa-
tion. Such regulations need to be researched and complied with for
every sector for which such regulations have been formulated.
Stage 2: PREVENTION - Building protection features into systems

The best time to include system features to prevent abuse, fraud and oth-
er computer crimes is at their design stage. Admittedly, many systems
consist of commercial, off the shelf software (COTS) or packages that are
customised for a specific organisation.
Here there is less that can be done to prevent the introduction of undoc-
umented functions, but there is much that can be done to ensure these
products are correctly configured and have suitable safeguards against
misuse and abuse.
In the case of one-of-a-kind software, specifically designed for one organ-
isation, it is particularly important to ensure that adequate attention has
been given to this aspect of design and that the implementation of pro-
tection features has been independently validated.
Computer operations (at the desktop, server and computer room level)
need to cater for facilities to prevent computer crime. The following are
the main areas to address to prevent computer crime through design:
a. System design safeguards and controls
System specifications focus on what a computer system should do.
Well developed specifications also include definitions of functions
and processes that are not allowed, particularly to prevent fraudulent
transactions, and requirements for transaction logs that identify
what records where changed, when and by whom.
b. Back doors, logical bombs
Malicious code can be introduced in computer systems at the design
stage and also through subsequent maintenance, enhancements and
upgrades. The problem grows when this work is done by other than
staff, such as contractors perhaps off-shore, as the usual measures of
validation cannot be easily applied.
c. Secure logical partitions of data to support Need to Know
The software used for databases must allow for data partition in a
manner that supports providing data on a Need to Know basis. While
the database software may include this capability, it is up to the da-
tabase administrator and the system owner to define access rights by
employee function and level.
d. Inappropriate storage and maintenance of electronic records
While safeguards may be in place for online systems, databases and
data, there should also be safeguards for the copies of the data and
software kept as backups and for disaster recovery purposes.
These may not contain the latest online updates but are available as
media (disks, tapes, CD or other carrier) and their unauthorised copy
or removal could enable others to recreate the system and read all the
data. It could also allow for the corruption or destruction of backup
data and software to prevent successful recovery.
Stage 3. OPERATIONS: systems administration and monitoring

The measures put in place during policy preparation and system and in-
frastructure design will only be as good as their operational administra-
tion on a day-to-day basis.
i) Access rights (definition, maintenance, termination)
Every person with access to information systems and facilities needs
to be granted specific access rights, in line with the organisation’s
policy. These would normally include:
• Access to the data network (fixed and/or wireless)
• Definition of a software profile (all applications that will be enabled
for this person)
• Inability to modify the computer configuration and install soft-
ware
• Provision of a corporate e-mail account (if appropriate)
Such access rights need to be documented and related to identity
management and authentication. They should be updated immedi-
ately upon transfer to another job and terminated when a person
leaves the organisation.
ii) Segregation of duties
There should be clear procedures to ensure that no one person has
the ability to authorise a change (for example the creation of a new
user account), implement the change and also test the change. In or-
der to maintain adequate security, such functions should be under-
taken by different people and these should be rotated on a regular ba-
sis to avoid the risk of collusion.
iii) Superuser rights
System administrators and database administrators are granted spe-
cial access rights to systems in order to exercise their function (up-
dates, backups, reconfiguration, etc). This is a critical process as if
these rights are unlimited and unmonitored they provide exception-
al opportunities to these individuals.
It is also not unusual for systems developers and testers to have ex-
tensive access rights to software, including databases and when there
is no separate and controlled test environment people other than au-

thorised employees may have access to live operational data. This sit-
uation represents a serious risk to any organisation.
This presents several complications in environments where owner-
ship and responsibility for systems is fragmented across departments
or business units without a common policy and potentially widely
different control arrangements.
iv) Password disclosures and social engineering
When access control and authentication rely only on the use of user
IDs and passwords, and particularly when there are no strict pass-
word construction rules there are several exposures, in particular
those of:
• Passwords that are (difficult to remember) written and visibly post-
ed in office areas;
• Passwords that are shared among employees (to cover during un-
authorised absences for example) and to access systems if an em-
ployee is on vacation or on sick leave;
• Passwords that are trivial and therefore easy to guess or to break
using hacking software such as password breaker (these are easily
available);
• Repeated passwords – where the system allows the user to use the
same password over and over again.
A more insidious problem is that of “social engineering” where a
plausible individual requests to be given access to a computer for a
few minutes. Other instances of social engineering involve people
pretending to be maintenance personnel requesting access to com-
puter rooms, or obtaining User ID and passwords from naïve, un-
aware employees.
v) Data rights (C, U, R)
Authorisations for the use of data can be at any on of three levels,
higher levels implicitly containing the lower ones:
Top level: Creation of data – an individual can create a new record in
a database (for example a new employee or a new purchase order).
(This differs from superuser access insofar that the rights apply only
to data, not to the software).
Intermediate level: Update of data – an individual cannot create a
new record but can update existing records (modifying entitlements
for an existing employee or modifying a purchase order before its fi-
nal processing).
Low level: Read access only – where individuals can only access data,
view it, print it and possibly copy it for separate processing (statistics,
etc).
Such authorisations need to be granted by the systems owner and im-
plemented by the system administrator and/or database administra-
tor. All such authorisations should be on a “need to know” basis, be
formally logged and be the subject of formal change control.
Stage 4. DETECTION: Investigations, digital forensics and further

actions
An organisation would have to be extremely lucky not to have to conduct
an investigation of their computer systems and infrastructure after a se-
curity incident, misuse, abuse or cyber-crime.
The activities needed to be prepared to conduct such work require:
vi) Determining the point of access and containment
The discovery of a problem of this kind can be evident in cases such
as malicious code, sabotage, blackmail or unauthorised disclosures.
It can also be accidental as is the case in most instances of smartly
conducted fraud.
Determining the point of access and containment of the problem is
the essential first step in managing the situation and this requires
good logs and monitoring tools. These range from firewall intrusion
detection logs designed to identify external attacks and system ac-
cess logs for internal users (where these exist, are kept and anal-
ysed).
The number of tools available for such monitoring is growing and
they range from the fairly cheap and simple to complex and sophis-
ticated tools such as for example Zephon, from Intrusic Inc., specif-
ically designed to deal with insider threats or eTrust 20/20 from Com-
puter Associates specifically designed for high security environments
(NB mention of these products does not constitute an endorse-
ment).
The introduction of such systems needs to comply with employee pol-
icies and appropriate legislation on the right to privacy of employ-
ees.
Having located the point of access and a suspect, the next step is the
containment of the problem for which there is no general answer –
the organisation may wish to develop a more elaborate monitoring
system to collect more evidence or take action immediately – the lat-
ter course of action is vital for external attacks but not always suit-
able for internal ones.
vii) Evidence preservation and custody chain
Digital forensics is a relatively new discipline and there are many
tools that support this work. The problem here is a legal one: how to
seize, preserve and analyse evidence of abuse or crime that will be
accepted in a court of law. Knowledge of the appropriate applicable
legislation is a pre-requisite.
There are several sources of best practices concerning the seizure and
custody of evidence and recommended techniques for the analysis of
information from computer systems. If these are not followed, legal
action against an offender will not be possible.
Legal action is not always the best recourse as it involves public dis-
closures and adverse publicity, particularly when the actions were the
result of inadequate internal measures.
viii) Evidence analysis and forensic tools
Having seized and preserved evidence, analysis provides an under-
standing of exactly how the offences were committed and provides
the material on which to prosecute or take disciplinary action.
Issues and limitations arising

from this protection
Digital forensics – the investigation of computer crime – is a complex dis-

cipline. The most important issues arising from it relate to:
• Acquiring evidence of a cybercrime in such a way that such evidence
would be admitted as evidence in a court of law, and national legis-
lation varies significantly;
• Ethical issues of whether a digital forensic investigation should be
carried out with the knowledge and consent of the party suspected
of being involved in some form of cybercrime;
• Who is allowed to conduct such an investigation – should this be car-
ried out by the audit department, a law enforcement officer or a mem-
ber of the I.T. department?
• How quickly should an investigation be conducted? It does not take
an expert much time to remove traces from any improper or illegal
activity, making the work of a forensic investigator that much more
complex. Organisations with slow metabolic rates that spend much
time considering the pros and cons of such actions are handicapped
by design.
Action points
Executives should ensure that there are clear and well disseminated pol-
icies, supported by consistent organisational behaviour with regards to
all forms of cybercrime. This behaviour should extend from formulation
of deterrence policies to sanctions and redress.
Those responsible for information security should be required to learn
how “bad guys” think and operate and incorporate appropriate defences
against external and internal threats.
Cybercrimes committed by an expert will be essentially undetectable.
The role of tests, audits and security certification must be seriously con-
sidered if the organisation’s information assets are valuable.
C h a p t e r
13
Contingency planning
for ICT
“There seems to be little enthusiasm at board level

to spend the relatively small sums of money needed
to head off disaster”
The Financial Times, March 9, 2004
Special Report on Business Continuity

• What can cause an organisation to have an ICT disaster?
• What are the steps needed to reduce the impact of such a disaster?
• What are the options to consider?
• How much will this cost?
• What are the most likely problems to be encountered?
What happens to an organisation when its networks and computer systems become inop-
erable for a significant period of time – hours or days if it is merely a computing problem,
weeks or months if the cause also affected buildings or a town?
The last few years have seen many tragic events, some natural, others man-made. Lack of
adequate contingency plans to deal with such disruptions can have catastrophic impact on
an organisation ranging from a loss of credibility to going out of business.
Surveys from ICT research organisations such as the Gartner Group and professional asso-
ciations – for example the Business Continuity Institute – indicate that there are still many
organisations in all areas of activity that do not have adequate contingency plans.
For such plans to be effective at a time of crisis, it is vital that they should be kept up to
date, that they are regularly tested and that everyone concerned should be fully aware of
their roles and responsibilities when such plans need to be invoked.
Definitions
Contingency plan: the collection of processes, procedures and activities
that define what to do in response to an emergency.
Disaster recovery: the processes, procedures and activities that are ap-
plied to restore computing and telecommunications services after they
have been (severely) disrupted.
Business continuity: the processes, procedures and activities that define
how an organisation will operate after an event that disrupts it.
Although strictly speaking this may fall outside the field of ICT, corporate
contingency plans should give particular attention to the preservation of
vital records that will be needed in the reconstruction of corporate assets,
including contracts, ownership rights, inventories of company assets, etc.
A situation that causes an emergency may cause considerably more dam-
age to an organisation than just financial losses due to an inability to con-
duct its business, including legal liabilities for being unable to meet con-
tractual obligations, lost business, lost credibility, the possibility of in-
creased fraud while working under emergency conditions, the costs of re-
covery that are not covered by insurance and many more.
Disaster Recovery plans are focused on ICT while Business Continuity

plans address the need to contact all employees and other parties, having
a place for employees to continue their work, describe how they will be
doing their jobs until normal working facilities have been restored, how
to deal with employees, vendors and customers, etc.
The purpose of developing contingency and business continuity plans is
to protect an organisation from disruptions by reducing vulnerabilities,
managing risks, putting in place the essential elements for survivability
and the preservation of the organisation’s reputation.
ICT disasters and their causes

The cause and effect or fishbone diagram presented in the chapter on Risk
Management can be used to advantage to describe the events that can
cause a complete loss of ICT services as shown below (the events in the
figure are not an exhaustive listing).
How long does it take to have a major problem? It all depends on what an
organisation does – emergency services must recover quickly as the con-
sequences of an inability to respond to an emergency can be catastroph-
ic. Similarly an airline depends very heavily on its seat reservation, crew
scheduling and aircraft maintenance systems and cannot tolerate a long
disruption and economic damage. At the other extreme, small, low-tech
manufacturing enterprises could probably manage to wait several days
to restore their systems without too much pain.
Studies by vendors and researchers on the cost of downtime (the time
during which computer systems and facilities are inoperable) indicate
that this can be significant for many types of organisation and be in the
range from tens of thousands to millions of dollars an hour.
Executive dilemma: What happened to our

business continuity arrangements!?
A multinational financial institution with a branch in the City of London

with its own trading room handled a large volume of money transfers and
currency trades for its international clients.
It had a small IT department which had invested in proven products from
a reputable vendor. It also had fully developed and regularly tested busi-
ness continuity plans.
One morning, just as the working day was starting, the fire brigade
came to the building to advise that there was a gas leak in the street out-
side the offices and that it was necessary to evacuate the building im-
mediately.
Key staff made their way to their backup offices and trading room a few
hundred meters away. When they arrived they discovered that the IT sys-
tems and facilities – including fax machines – were not operational be-
cause the software upgrade that the vendor had scheduled for the night
before had been postponed until that particular morning.
By being unable to trade, the bank incurred significant financial losses,
seriously inconvenienced several major clients and the branch office lost
much of its reputation as this became more widely known through the fi-
nancial services grapevine.
Although business continuity was definitely part of their responsibilities,
both the IT manager and the Operations manager claimed they were un-
aware of this change of schedule.
Assume that you are the Managing Director of the branch and that the
Chairman at headquarters has just phoned you to demand what actions
you are going to take to remedy the situation and avoid a repetition.
The four main stages of dealing

with an emergency
When an ICT incident becomes a problem that cannot be solved quickly

enough to meet the operational needs of an organisation, there are few
choices available to executives:
• Wait until the problem has been fixed, although some times it will
be obvious that this will take a long time – like dealing with the dam-
age caused by a fire and the subsequent intervention of a fire brigade
in a computer room;
• Invoke the contingency plans prepared to deal with such situations
– although the Executive Dilemma just presented shows that the con-
tingency plans may not always work as intended.
This chapter dis-
cusses the main el-
ements of the four
stages of dealing
with an incident
that has migrated
through the stages
of “problem” to
that of an emer-
gency.
The relationship between the four stages is shown in the figure. Clearly,
planning is a pre-requisite as, without good contingency plans, the only
alternative would be to improvise and this does not work well during
emergencies.
Stage 1: Contingency and Business Continuity planning

Good contingency plans reflect the KISS principle: Keep It Short and Sim-
ple. The development of such a plan requires four activities:
1. Prepare for contingency planning;
2. Business Impact Analysis (BIA) and its related risk analysis;
3. Evaluating the recovery options that are aligned with the BIA;
4. Developing a contingency plan (disaster recovery/ business continu-
ity)
Supported by two subsequent activities:
5. Testing the plan;
6. Maintaining the plan.
Taking as an example disruption to ICT services, organisations cater for
this through two sets of measures: a Disaster Recovery plan for its ICT
and a Business Continuity Plan for the critical activities that depend on
ICT.
Stage 1 – activity 1: Prepare for contingency planning

The Business Continuity Institute (http://www.thebci.org) recommends
that the following actions should precede the development of a workable
contingency plan.
• Identify a person to be the focal point for a Business Continuity Plan
feasibility study and its subsequent implementation – this person
should preferably not be the CIO but a business manager which broad
knowledge of the organisation as a whole;
• Develop a concise and agreed inventory of the main processes that
support the operation of the organisation (such as line of business
systems, key administrative processes, communications);
Stage 1 – activity 2.1: Conduct a Business Impact Analysis
A Business Impact Analysis (BIA) is used to define the criticality of the
business processes identified during activity 1 and aims to obtain specif-
ic answers to five questions:
Q.1 What business processes are vital to operations;
Q.2 What are the key resources (people, systems, etc) needed for these
processes;
Q.3 How quickly must these activities be restored to avoid serious busi-
ness disruption;
Q.4 Are there alternative methods to conduct these processes during a
period of disruption;
Q.5 What happens if data related to these processes is lost.
A BIA is compiled through a combination of questionnaires and inter-
views. Prior to such interviews, it is advisable to build awareness among
business unit and department managers of the critical importance of es-
tablishing and maintaining a comprehensive and uptodate record of Busi-
ness Impact Analyses.
The consolidated findings of a BIA will result in a list of business process-
es ranked by criticality to the operations of an organisation and in indi-
cations of the timing by which a disruption will have significant impact
on these operations.
The final steps at this stage require the collaboration of executives and
the CIO and other ICT managers to determine which ICT facilities are
most critical to the organisation.
Stage 1 – activity 2.2: Conduct a Risk Analysis

Risk analysis essentially calls for the identification of vulnerabilities and
threats, an understanding of the impact these could have on an organi-
sation and the frequency with which the threat could manifest itself.
Example 1: In January 1989, a British Midland Airways aircraft on route
from London to Belfast developed technical problems and it was divert-
ed to East Midlands airport. The power in one of the engines decreased
on the approach and the aircraft struck trees at a relatively high speed
and impacted on the M1 motorway, 900 meters from the runway. In do-
ing so, it narrowly missed crashing on the data centre of a major UK
bank.
Here, the vulnerability is being located on the flight path to an important
airport. The threat is that of an aircraft failing to make it to the runway.
In this case, the accident occurred once, many years ago. The probabili-
ty that an accident of this kind can occur again should not be assumed to
be zero.
In this particular example, the bank had accepted the risk. After the ac-
cident however, it took steps to mitigate the risk by splitting the data cen-
tre operations between two locations each of which could act as a back-
up for the other.
Example 2: On 14 July 2003 a group of Greenpeace activists drove through
London with a truck containing a two and a half tonne “sculpture” con-
sisting of scrap metal from old ships being dismantled and deposited it
without difficulty in front of the International Maritime Organisation’s
building, close to the Houses of Parliament… It could have just as easily
been a bomb.
In order to conduct a risk analysis, it is necessary to define an agreed
range of threats and vulnerabilities that the contingency plan should ca-
ter for and define what level of residual risk and speed of response are ac-
ceptable to the organisation. These decisions will drive the cost and com-
plexity of any recovery plan.
The list of threats would normally contain between 25 to 50 entries – the
detail of which depends on each organisation and its physical location.
The table below illustrates the type of threat that can disrupt an organi-
sation’s activities through destruction, modification or loss of the use of
assets.
Source: http://www.contingencyplanningresearch.com, and Eagle Rock Company

Each threat to be considered can be assigned a value ranging from likely
(something that happens more than once a week – hackers or computer
viruses, for instance) to remote (where the event would occur once every
ten years or more as would be the case for an earthquake in central Lon-
don, UK).
Stage 1 – Activity 3 - Evaluate recovery options
Having thus identified what needs to be protected and recovered, the next
issue to consider is the degree of urgency with which this recovery must
take place.
The cost of downtime, already mentioned, is a good indicator but not the
only one as non-financial impact can also be severe, in particular if it af-
fects confidence in the organisation. A Cost of Downtime survey conduct-
ed in 2001 by Eagle Rock Alliance, Ltd., indicates that of those compa-
nies that participated in the survey,
• 46 % said each hour of downtime would cost their companies up to
50,000 US dollars
• 28 % said each hour would cost between 51,000 and 250,000 US dol-
lars
• 18 % said each hour would cost between 251,000 and 1 million US
dollars
• 8% said it would cost their companies more than 1 million US dol-
lars an hour.
With good contingency plans, organisations can resume their activities

quickly after a major disruption. For example after the collapse of the
twin towers of the World Trade Centre on 11 September 2001, many fi-
nancial institutions were able to continue normal operations after an in-
terruption of around 24 hours, while many others simply went out of busi-
ness due to their inability to do so.
To achieve full business continuity, arrangements are complex as they in-
clude moving people, documents, and computer systems to another loca-
tion at a time of major disruption, such as arising from fire, natural di-
sasters, civil disorder or terrorist activities. Besides, at such times, staff
will be very concerned with their own security and that of their families
while expected to perform complex activities in often very difficult cir-
cumstances.
The range of recovery options for implementing business continuity ar-
rangements begins with “Do Nothing”, the cheapest and simplest of the
arrangements, but also the most likely to lead to going out of business
should disaster strike.
There may be circumstances where the use of manual backup procedures

are sufficient to maintain adequate business continuities if the disaster
in question does not preclude the use of an organisation’s offices or prem-
ises.
Next up in sophistication and cost is the concept of a “fortress” where the
premises of an organisation are highly protected against most thinkable
events. An approach favoured by military and emergency services organ-
isations, the last decade has shown that this is not always a practical prop-
osition.
Reciprocal arrangements for business continuity rely on mutual agree-
ment between business units, departments at different locations, busi-
ness partners or associates, etc., to make available office space, logistics

support, access to telecommunications and computing services, etc.
These are not really viable as it implies that someone is keeping empty
data centre, communications capacity and possibly more in case it’s need-
ed.
A cold site is a business continuity (also used in Disaster Recovery) facil-
ity which is usually owned by a third party specialising in this kind of
service, and is basically an empty office facility with some kind of basic
facilities if fixed or an empty, transportable building, if mobile. It can also
include a data centre with the capabilities to replicate the infrastructure
of the organisation that needs to recover its facilities. Cold facilities are
available through a contract that provides “on call” availability of the fa-
cilities.
Hot sites are reasonable “copies” of the facilities that require recovery, at
another location and ready to become operational very quickly. Fully
equipped offices with complete copies of data, software and critical doc-
uments, a fully equipped duplicated data centre where critical systems
can run without significant loss of data, etc. The time required to relo-
cate critical personnel is the main factor that will limit the speed of re-
covery. It is also one of the most expensive mechanisms for business con-
tinuity. The hot site may be internal, i.e. owned by the organisation or ex-
ternal, typically when an outsourcing services provider is engaged to pro-
vide ICT services or other business process outsourcing.
Disaster recovery is the subset of activities concerned with ICT systems
and facilities. Responsibility for having adequate disaster recovery plans
and facilities rests with the ICT service provider – an in-house ICT func-
tion or an outsourcer. Disaster Recovery deals with the activities required
to restore ICT services in the event of disruptions extending beyond a cer-
tain time.
Disaster recovery plans are also complex and must be kept uptodate with
records of essential personnel, their contact numbers, alternative person-
nel should they be on holiday, sick or out of town for whatever other rea-
son, full inventories and many more details. Such plans must reflect all
changes to infrastructure and software as failure to do so will mean that
the plan will not work when required.
The cost of disaster recovery arrangements increases rapidly as the tar-

get time to recovery gets smaller.
At their minimum, basic recovery arrangements may take 24 hours or
more and involve physically transporting a complete set of media con-
taining data and software as well as a team of technical and operations
staff to a DR facility specially contracted for this purpose.
At the other extreme, a fully equipped facility at another location may be op-
erating in hot stand-by with a complete copy of all data and software, a full
technical team and the ability to restore operations in hours, if not minutes.
Once the basic decisions have been taken, it is possible to prepare outline bud-
gets for various levels of response (an estimate with a ± 30% margin should
be good enough to decide on which options are not financially justifiable).
Stage 1 – Activity 4 – Develop the detailed contingency/ disaster/ continu-
ity plans
This is the most laborious part of planning as it requires the preparation
of well written documents containing detailed processes and procedures,
detailed inventories, contact lists, authorities, priorities, etc.
The writing itself can be helped by the use of templates that can be cus-
tomised for a specific organisation, and there are many such templates
available in the market.
The possibility of using consultants specialising in contingency planning,

business continuity and disaster recovery should be considered because
they can contribute their experience in working with other organisations
to prepare such plans and will be able to identify threats and vulnerabil-
ities that may not be immediately apparent to employees who may have
become “prisoners of the familiar”.
The really hard part of developing good plans is collecting all the infor-
mation needed for the plans to be viable and ensuring that the contingen-
cy plans themselves become part of the vital records that must be acces-
sible at all times – having a copy of the plans in an office building that is
on fire is of little help.
A critical part of these plans is the complete listing of all the people who
need to be contacted in an emergency – name, function, telephone num-
bers, address (even if the person is on holiday), a list that must absolute-
ly be kept up to date and accessible from remote locations in case the or-
ganisation’s premises cannot be accessed.
This list and the associated documentation must also indicate the author-
ities delegated to these people throughout the duration of the emergency
up to and including the recovery from it.
However well it may be written, such plans are of little value if they are
not tested. Such tests are complex, expensive and involve a substantial
number of people but it is the only way to discover what has been forgot-
ten, unclearly written or communicated or who has failed to understand
their specific responsibilities when the plans are invoked.
Stage 1 – Activity 5 – Consider Business Interruption Insurance

Many insurance companies offer products for business interruption in-
surance. This is designed to indemnify the insured party against the loss-
es that would arise from not being able to operate as a result of an emer-
gency or disaster.
Such policies provide cover for the time needed to rebuild, repair or re-
place the damaged elements (which could include property or simply
computer systems).
Stage 2: Recognition – who can initiate the implementation of con-

tingency plans?
Executives, the CIO and other ICT managers should agree and decide on
who should be responsible for declaring a situation to be an emergency
that requires invoking measures that could dramatically disrupt the work
of an organisation, as these may involve the presence of emergency ser-
vices, the evacuation of buildings, moving key people to temporary office
facilities, calling on the services of disaster recovery services providers
and more.
Once there are indications that the organisation is facing a disruptive sit-
uation, the Emergency Coordinator, in consultation with the parties
agreed in the contingency plan should decide which parts of the plan are
needed and their priorities. At this point it becomes essential to commu-
nicate these actions to all parties involved (see Stage 3 below).
One of the critical elements of Stage 2 is that of notifying those parties
who have vital roles to play – ranging from emergency services (fire, am-
bulance, police) to the providers of alternative facilities such as accom-
modation, communications, computer systems and services, transport,
catering and more.
To put the ICT component of such measures in perspective, disaster recov-
ery service providers report that in an year without exceptional events (such
as the destruction of the twin towers of the World Trade Centre in New York
on 11 September 2001) approximately 1% of their clients will notify them
of their intention to invoke the use of the facilities and that roughly one half
of these notifications end up actually using the facilities.
In the absence of clear definitions of authorities, responsibilities, who
needs to be consulted and who needs to be informed, the most likely re-
sult is chaos at the least appropriate time.
Stage 3: Response – taking the actions needed to deal with the emer-
gency
When the emergency is so real that contingency plans must be invoked,
everyone is working under considerable stress. Nevertheless, discipline
and order are vital to ensure that the planned arrangements will work as
intended.
The Emergency Coordinator and her/his Emergency Response team have
many critical tasks to address to implement the appropriate measures of
the plan – it may be necessary to implement only a part of the plan – for
example it would not be necessary to evacuate the building if the emer-
gency is due to fire damage to a computer room when this fire has not
spread to other parts of the building and when it has been contained/ ex-
tinguished but has severely damaged the ICT facilities.
Working through an emergency may require special measures that over-
rule security and other policies, record keeping and other administrative
procedures. It is important that the people involved make a best effort to
preserve whatever records are possible to ensure that the measures tak-
en and the working processes implemented during the emergency can be
subsequently audited to ensure that the occasion was not used to commit
fraud or otherwise abuse the organisation.
Communications also play a vital role during the response phase. Such
communications include, in particular:
• Status reporting to executives and other key stakeholders, including
the workforce;
• Informing relatives of members of the workforce who may not be able
to communicate with them directly;
• Dealing with the media should the event become public.
Executives should ensure that suitably qualified and experienced people
are assigned to these tasks.
Stage 4: Recovery – restoring normal service and operations

Recovering from an emergency is in itself a major project, and this proj-
ect will last until all parties concerned can agree that the organisation is
back to “business as usual”. This could be a matter of hours or days when
the emergency relates to ICT matters and nothing else, it could take
months if not years if it is the result of a catastrophic event.
During the time of response, when the organisation is making best ef-
forts to maintain critical operational tasks, large amounts of transactions
will be performed that may not be recorded in the usual way. Catching
up with these transactions is a significant task which must be conducted
in a manner such that it provides adequate audit trails.
In many situations, data and documents will be damaged by fire and wa-
ter – there are many companies that specialise in recovery, and their ser-
vices are quite expensive but essential if vital documents or data have
been affected.
How much will this cost?

There are several cost components to contingency planning, business
continuity and disaster recovery, and not all of them can be covered by
insurance. The main components are:
• Preparation of a Business Impact Analysis and its associated risk
analysis (it is good practice to review this analysis on a regular basis,
the frequency of which will be determined by the rate of change of
business processes and the computer systems that support them;
• Production of the contingency plans;
• Provision of appropriate recovery options;
• Maintenance of the contingency plans to reflect changes in person-
nel, inventory, recovery options and, most importantly, lessons
learned from the tests of such plans;
• Business Interruption Insurance;
• Testing the plan on a regular basis – in situations where there is crit-
ical dependency on the effectiveness of contingency plans two tests
a year would be appropriate;
• Recovering from the emergency.
From the perspective of ICT, i.e. the provision of effective disaster recov-
ery capabilities against the non-insurable costs are in the range of 2 to 4
percent of the ICT budget.
Specific challenges of Contingency Planning

and Business Continuity
Contingency planning, disaster recovery and business continuity are crit-

ical activities of considerable complexity. This gives rise to three major
management challenges:
Amount of effort required to develop effective plans: This is very signifi-
cant the first time contingency plans are prepared and requires not only
major effort on the part of those preparing the plans but also from all the
parties that need to be interviewed during the Business Impact Assess-
ment phase and the communications required to brief all parties about
the plans and how they will be put to work.
Details are built on assumptions: Contingency plans must make assump-
tions about threats and their probabilities. There is always a possibility
that these were not correctly assessed. Constant revision of the plan in
the light of improved knowledge about the threats is essential.
Management commitment: All the activities described in this section re-
quire considerable time and decision making from executives. When
there is a feeling that such arrangements are not likely to be needed (op-
timism) or that they can be delegated lower down the organisation (ab-
dication of responsibility), the processes are likely to be implemented
half-heartedly and not work when required.
Funding: The perennial question of containing costs and budgetary pres-
sures work against contingency planning, disaster recovery and business
continuity, and the cost of these processes should be seen as the equiva-
lent of buying insurance.
Testing: You can never be sure of what you have not tested. Testing these
plans is complex, time consuming and disruptive. However the acronym
TINA is appropriate: There Is No Alternative.
Action points
Appoint a person to be in charge of contingency planning – a typical ti-

tle is Emergency Coordinator – and ensure that this person has adequate
backup, after all, an emergency necessitating immediate response may
arise while the Emergency Coordinator is on holiday…;
Actively participate in the process of Business Impact Analysis and also
in the decisions that define recovery priorities and the speed with which
recovery is to be achieved;
Monitor the results of the tests of contingency plans and ensure that the
lessons learned during these tests are discussed and reflected in the
plans;
Make available the financial and human resources needed to make con-
tingency planning workable and sustainable. This is often a major issue
for organisations;
Recognise the importance of communications during an emergency –
with the workforce, with their relatives and close ones, with vendors, cli-
ents, the media, etc., and act accordingly to ensure that poor communi-
cations do not lead to a loss of image and reputation.
C h a p t e r
14
ICT organisations and
ICT people
I always wanted to work in computing because in

this job I don’t have to talk to people
Genuine quote from a former colleague

• What do ICT organisations do (or are supposed to)?

• What activities lends themselves to centralisation and to outsourcing?
• What are the roles and responsibilities of a Chief Information Officer
– are there different kinds of CIO?
• Where should the ICT function fit in the organisation?
• How does one measure the performance of the ICT function?
• Are ICT people really “different” from other employees?
• What factors prevent CIOs from succeeding in their job?
• What are the questions that executives should ask of their CIOs?
There are many tasks that need to be performed to transform commercial products and tailor
made software into useful business tools. ICT organisations and their people exist to do this.
While much of they do is straightforward (at least in principle) and has been discussed in
previous chapters, ICT is probably the least understood by executives.
Although in general ICT people are dedicated and hard working and enjoy their profession,
they often complain that they are misunderstood and not given a chance to contribute to
the success of the organisation, and feel they are treated as “plumbers” looking after the
organisation’s nervous system but not seen as capable to contribute to strategy.
There are many types of ICT people and unless they are a good fit in the corporate culture and
understand the needs and constraints of a given organisations, there will be a poor relationship
between them and other executives, to the detriment of the organisation as a whole.
Roles and responsibilities of ICT organisations
What do ICT organisations ac-

tually do? The simple answer is
that they tend to work very hard.
However, not all ICT organisa-
tions perform the same activi-
ties. The things that need to be
done are shown in the figure.
The extent to which these ac-
tivities are performed and if
so, whether they are per-
formed by the ICT function,
depends on what the organisa-
tion does and one the role that
ICT plays in supporting it.
Visioning
These are the activities where ICT adds to “tomorrow’s organisation” by

bringing an understanding of how innovative uses of technology can
make a difference. Visioning, needs to be shared between business units,
departments and the ICT function to make a real contribution to strate-
gic planning.
Innovation and development
This group of activities is really the world of projects. These fall in two
categories: assessments and the development of new ICT systems and fa-
cilities.
Assessment is the evaluation of technologies to determine their relevance
and maturity. This may include a pilot project to gain a better under-
standing of its capabilities and demonstrate its potential.
Technology assessment is most appropriate for early adopters of emerg-
ing technologies who are willing to take the risk to invest in them to gain
advantage. Elsewhere this kind of technology assessment could become
the equivalent of an enthusiast’s toy shop.
Can technology assessment be outsourced? Yes, but only to a degree: In-
dustry analysts study new technologies and report on their capabilities,
maturity, market prospects and vendor stability. Good analysts also com-
pare products from several vendors. However, their reports cannot re-
place pilot projects or the demonstration of what these technologies or
products can do.
Development groups the activities needed to transform a concept into
working systems and facilities. Large projects are handled by dedicated
teams and are progressed in a structured, formal environment. Such proj-
ects can be, and often are, outsourced.
Service delivery and support operations
The heart of the activities that support the day-to-day ICT activities of an
organisation, this is the world of processes, total quality management and
measurable performance. This activities usually represent 70 to 80% of
the total ICT expenditures and, when performed with internal resourc-
es, are likely to demand a substantial amount of the CIO’s time – at the
expense of visioning activities.
The activities performed to achieve service delivery and support are dis-
cussed in Chapter 8. ICT service delivery can also be outsourced and rep-
resents the oldest and largest part of the outsourcing business. Informa-
tion security (Chapter 11) is part of the activities involved in service de-
livery and support but is not the exclusive responsibility of the ICT func-
tion.
Information management
Often performed outside the ICT function, these are the activities where
value is added by the creation and maintenance of information assets,
ranging from databases to websites.
When information management is dispersed across the organisation it is
important to ensure that there are appropriate mechanisms to prevent
information anarchy. As a minimum these should include:
• Data administration and data standards to ensure the semantic and
digital compatibility of data held and processed in various systems;
• Quality assurance mechanisms to protect the organisation from us-
ing data which is inaccurate, outdated or incomplete.
The way in which these tasks are carried out make the difference between
success, mediocrity and failure in an organisation’s ability to derive ben-
efits from their investments in ICT.
Centralisation and outsourcing
It is possible to organize the tasks of an ICT function in several different

ways and there is no single “best” way of doing this.
In extreme cases, centralisation led by a strong manager becomes a dic-
tatorship. While this is a good way to ensure that standards and policies
are applied across the organisation, it can also inhibit innovation and cre-
ativity, thus causing opportunities to exploit ICT to gain business bene-
fits to be missed.
Decentralisation with good ICT governance enables business units and

departments to focus their ICT developments and investments on core
activities and enable creative thinking by those closest to these activities
to create value.
When decentralisation is not balanced with effective governance, the re-
sult is anarchy. This is manifested by multiple implementations of sys-
tems that perform essentially the same function, such as ending up with
different accounting and personnel systems for each business unit or de-
partment. Implausible as this may sound, it does happen in the private
sector as much as it does in the not-for-profit sector.
In addition to the large extra risks and costs of working this way, the in-
compatible data definitions and variations in functionality that result
make it difficult to aggregate data from such systems to provide an or-
ganisation-wide view.
Another manifestation of anarchy occurs when the ICT function is dys-
functional and is unable to meet the expectations of the organisation.
This results in the emergence of “unofficial” ICT groups working outside
the organisation’s ICT governance mechanisms. These groups believe that
they can work “faster, cheaper and better” than the official ICT func-
tion.
These kind of situations require an assessment of how good the ICT func-
tion is at meeting the organisation’s needs and often a combination of
first impressions, and track record is sufficient to have an adequate diag-
nostic. These can be complemented by another useful indicator: ICT staff
turnover.
Good ICT staff are hard working and career conscious. They rate job sat-
isfaction as critical to their working life. They are also mobile and rarely
hesitate to leave an organisation they judge to be at the lower end of the
ICT organisation thermometer.
A high turnover of recent re-
cruits considered bright and
with high potential is a bad
sign, particularly when the
turnover of staff with many
years of tenure on the job is
zero (other than through re-
tirements or death).
A study of organisations acknowledged to make superior use of ICT shows
that they have centralised specific activities, in particular:
• Establishment of organisation-wide policies and compliance with
these policies;
• Definition of standards for the whole organisation for critical hard-
ware, software platforms, desktop and groupware applications and
administrative systems;
• Major ICT procurement, licensing and contracts.
Besides this centralisation, it is good practice to enable business units
and/or functional departments to exercise a degree of autonomy for ap-
plications directly related to their core activities, encouraging sharing
and reuse of solutions across other units or departments.
Besides these centralised activities, many others that lend themselves to
outsourcing, notably day-to-day operations of data centres, networks, end
user support and other structured activities and also applications devel-
opment.
The decision whether to outsource such activities or not should not be left
to the Chief Information Officer as this creates a serious conflict of inter-
est as discussed in the next section of this chapter.
There are two other activities that should also not be outsourced:
• Business analysis, in particular the definition of information system
requirements and how these are aligned with the activities of an or-
ganisation;
• The preparation of strategic plans for ICT – although the employ-

ment of consultants to assist with this task is not unusual. Emphasis
is placed on the word “assist”.
Employing consultants to develop such strategies implies that a) there is
no in-house capability to think strategically about ICT and b) that nobody
will be the true owner of such a strategy;
The roles and responsibilities of

the Chief Information Officer
Titles can sometimes be misleading. Managers responsible for informa-

tion systems and technologies are known under various titles such as
Chief/ Director of Information Technology or Director of Information
Systems and Technology or Chief Technology Officer or Chief Informa-
tion Officer (CIO).
Whatever the title, a “real” CIO will fulfil the following roles:
• Ensure that ICT projects and services are delivered with the required
quality and value for money – regardless of whether these are per-
formed in-house or by a third party (an outsourcer or service provid-
er);
• Evaluate information technologies and proposals, validate estimates
for the costs of ICT services and facilities, ensure that project spon-
sors assume responsibility for defining expected benefits;
• Ensure that the information assets of an organisation are protected
against misuse, abuse, theft, sabotage and other damage, including
being the “owner” of suitable disaster recovery arrangements;
• Maintain a portfolio of information assets and systems and data ar-
chitectures;
• Provide internal consultancy services on ICT related matters and pro-
vide support to business analysis activities conducted across the or-
ganisation;
• Brief executives on ICT related issues such as security, technology-
based opportunities and their potential value to the organisation;
• Manage a suitable ICT organisation in order to meet all of the above
and other tasks assigned to the ICT function.
Each of the roles and responsibilities listed above that remains unful-
filled, wholly or in part represents a risk, if not a problem, to the organi-
sation. This may happen simply because CIOs are not created equal.
A good proportion of CIOs are best described as Level III CIOs – they op-
erate the infrastructure and look after service delivery with a minimal
role in major ICT projects, particularly software ones. These CIOs will be
found on the left side of the chart and could be unkindly referred to as
Techies. Level III CIOs are largely invisible to the executive until things
go wrong and they should be aware that what they do is easily outsource-
able.
Level II CIOs are much more involved with major projects and work to
maximise the alignment between ICT and business objectives and will
be found on the right hand side of the chart. When they focus on busi-
ness processes, their visibility to the executive is reasonably high and al-
lows them to operate as a senior partner in the overall management of the
organisation.
Level I CIOs are fewer in number and are found at the right hand side of
the distribution in the figure. They are always close to the executive, who
relies on them to:
• Protect the organisation against expensive mistakes, useless systems
and missed opportunities;
• Recommend innovative business solutions that exploit the opportu-
nities created by technology.
Placing the ICT function within

an organisation
There is no right answer to the question as to where the ICT function

should be placed in an organisation. This depends on the role expected
of ICT:
An organisation that uses ICT to
achieve high impact and its conse-
quential change needs the ICT
function to have extensive dialog
and build partnerships with exec-
utives and business units and de-
partments.
Those that use technologies pri-
marily for support functions and
look for limited strategic impact on
the organisation as a whole, are
usually best served by a technical department that, when things work well
is as good invisible. Such departments report several levels below the
Chief Executive.
Many ICT managers, some with the title of “Chief Information Officer” lament
that they are relegated to the latter situation and, in the words of one such man-
ager “treated as a plumber”. In fact this manager was wrong – plumbers are
always welcome when they turn up to fix a problem – ICT managers tend to
be treated as if they were the problem (and sometimes they are).
Measuring the performance of an ICT function
At the most basic level, the ICT function will be seen as performing if
things simply work well enough for problems not to be seen as a major
corporate issue.
Depending on the nature of the organisation, this may range from having
few disruptions during working hours to a high level of order fulfilment in
an e-commerce environment and no (or very few) customer complaints.
While this represents a crude approach to measuring performance, the
emergence of visible issues at this level of analysis is an indicator that
there are problems that require executive attention, as otherwise there is

a good chance that things will get worse.
More formal techniques for measuring the performance of an ICT organ-
isation are:
• Service quality against specified Service Levels
• Project delivery track record (functionality, budget, timescale)
• Audits, certifications and benchmarks (financial and technical)
• End user and customer satisfaction surveys
• Ability to demonstrate value added by ICT
The first two of these metrics have been discussed, and a formal tech-
nique of evaluation is to be preferred over subjective views on perfor-
mance in order to take whatever corrective action is required. When op-
erational services and/or projects have been outsourced, such metrics are
part of the contract defining deliverables, conditions of payment and pen-
alties.
Audits, are an established mechanism for executives to have an assess-
ment of organisational risk arising from the use of ICT. As the impor-
tance of ICT to an organisation grows, such audits add considerable val-
ue. The limited availability of experienced ICT auditors should not be
used as an excuse for avoiding such this activity as the business risk in-
troduced by ICT can be significant, thus justifying independent valida-
tion that these risks are being sensible managed.
Certifications – whether to ISO 9001 for Total Quality Management or to
ISO 17799 for the management of information security – or any other ap-
propriate standard is a good mechanism for executives to have another
independent assessment of how well the ICT function is performing.
Benchmarks – comparative analyses of the cost of providing ICT as well
as of technical performance are also useful indicators of the effective-
ness and efficiency with which ICT is managed in an organisation.
While many ICT managers will insist that it is not possible to conduct
such comparisons because of differences that could lead to misleading
results, such benchmarks are well established and can be found from
many sources.
End user satisfaction surveys are subjective and will be useful only if the
method used to poll the user community is unbiased. It is however a valu-
able indicator of the way in which ICT is regarded by the people who use
these services. A good result may not be meaningful but a wide sense of
frustration should be taken as an indication that executive action is re-

quired.
The value added by the ICT function is not always easy to determine as
the benefits of using ICT emerge elsewhere in the organisation. One meth-
od for identifying such value when this is not apparent is conducting post-
implementation benefit audits to validate whether the case made for in-
vesting in new systems and facilities was sound and, in particular, to de-
termine if the expected benefits actually materialised.
ICT people: The Chief Information Officer

and others
Organisations expect a lot from their CIOs. They should ideally have the
combined skills of Peter the Great, Saint Peter, Macchiavelli and Houdi-
ni. The table summarises what is expected from a CIO and it has been
constructed from job requirements found over the years in recruitment
announcements:
Expertise in Continuous ICT operations (7*24), security, fi-

nance, cost control, resource allocation, product de-
velopment, marketing, administration, process
management, project management, people man-
agement, vendor management.
Personal skills Strategy formulation, persuasion and negotiation,
writing, speaking and presentations.
Contribution Value generation, enabling teamwork, creating im-
pact, partnerships with other executives, develop
new managers.
Character traits Leadership, integrity, insight and vision, sensitivi-
ty, commitment, intelligence, courage, tenacity,
high ethical standards.
Other Friend, mentor, advocate for the organisation
It is doubtful that such a person - if she or he existed - would make a good
CIO just anywhere: organisations should be seen as the battleground
where people fight for influence and, sometimes, status.
In any case, organisations respond to change to reflect their organisational cul-

tures. The job of the CIO is challenging because of the barriers to change. Some
are technical, but the hard ones relate to organisational culture and politics.
Even the best qualified and experienced CIO may fail in the absence of a
good match between
• The organisational culture, politics and expectations of ICT
• The CIO’s values, motivation and personal skills
This may be one of the reasons why turnover among CIOs is high. ICT
professionals jokingly say that CIO stands for “career is over”.
Bureaucrats tend to make simple things complicated and incomprehen-
sible and acquire power through exercising their knowledge of the laby-
rinthine procedures they create. It is unlikely that bureaucrats care for
impact analyses, side-effects or value added. They do care about main-
taining the status-quo and their political influence.
Technocrats – technical people given the power to change the status-quo –
can make complex things simple and easy to use, even if the end users do
not understand how they work. A technocrat is quite different from a te-
chie: techies are interested in technology per-se and are not interested in
organisational issues or prepared to argue for a change in the status-quo.
Who would make a “good CIO” for a pyramid-style organisation?
A good technocrat would not do well in a pyramid organi-
sation. Instead, a person who is a good administrator rath-
er than an innovator, with good political skills and able to
introduce gradual change without challenging the organi-
sation’s culture or alter the status-quo dramatically would
be more likely to succeed and survive.
Moreover this CIO will have to be willing to accept rigid rules, an inflex-
ible reward system and “legacy staff” – those who as a result of life-long
job security have become unemployable elsewhere.
Who would make a “good CIO” for a cube organisation?
In this situation there is an accepted need that substantial
change is the only option. This CIO is a person who can lead
and take hard decisions, is willing to take measured risks
and has past experience of turn-around situations and of
managing large projects. Strong communications and nego-
tiation skills are absolutely essential.
Who would make a “good CIO” for a cylinder organisa-

tion?
An open minded person, good at spotting opportunities,
able to network and collaborate with people in all parts of
the organisation, with a focus on Total Quality Manage-
ment, metrics and an emphasis on process maturity.
However, nothing is that simple. There are other factors that influence
this choice as there are at least four distinct types of CIO:
The Tech enthusiast: This is a person whose background is not in ICT
but who enjoys dabbling with technology and ends up in charge of ICT.
When aware of what they don’t know, they operate effectively by build-
ing a team of technically good people. They become dangerous to an or-
ganisation when they start believing that they know enough to be a CIO
and behave accordingly.
In these situations the ICT staff, vendors and other ICT professionals will
not take this CIO seriously and many critical tasks will not be done, or
done poorly. Such situations can be found in pyramid-style organisa-
tions.
The Tech person: The ICT person primarily interested in technology and
probably the most frequently found. They tend to know several technol-
ogies and like to roll up their sleeves, get their toolkit and get involved
with complex technical problems.
These people are less interested in the purpose of “their” ICT systems and
facilities. Because of this, they are happy to change jobs if they perceive a
greater technical challenge elsewhere. In most cases they have an intense
dislike for the administrative and H.R. aspects of their work.
The Tech person with good knowledge about business: likely to con-
centrate on business analysis, technical opportunity, strategic thinking
and risk management rather than on technology for its own sake.
Not the most commonly found type of CIO, when the value they contrib-
ute to the organisation is recognised, they are accepted as partners by the
members of the executive team.
The business person with good technical knowledge: substantially dif-
ferent from the enthusiast, this is a person who has had training and ex-
perience in business systems and is primarily focused on using ICT to
implement a business vision and drive innovative uses of ICT. Most like-
ly of the four types in this list to have an effective dialog with the Chief
Financial Officer. Almost certainly a member of the executive team.
Making the choice when a new CIO needs to be appointed requires, in the
ideal world, all of the above considerations to be taken into account. If the
target appointee must be a technical person, this creates an additional
complication for an organisation as the selection process must include
the competencies needed to judge the technical capabilities of the candi-
dates.
Executive dilemma: The CIO has resigned
The perfume and scents manufacturer “Smells Nice” is a medium size

family company. Jerry, the owner’s nephew, was appointed Chief Tech-
nology Officer and over the years it became apparent that his real inter-
est was to play with technology, modifying things to improve their per-
formance and not taking much interest in the business.
To remedy the situation, it was decided to recruit a Chief Information Of-
ficer who would need to be very knowledgeable about technology because
Jerry would not agree to work with anyone who knew less about techni-
cal matters than he did. Peter was selected as he had both a business back-
ground and technical knowledge.
Within a few weeks, Jerry and Peter were at war as they disagreed on ev-
ery technical decision that had to be taken, and Jerry kept complaining
to his uncle that Peter was going to prove a disastrous choice. Before the
end of his first year Peter resigned, leaving “Smells Nice” in the hands of
Jerry who promptly invested large sums of money in his favorite technol-
ogies.
What should the owner do now that it is recognised that that Jerry is a li-
ability to the organisation. Unfortunately, Jerry’s mother holds 35% of the
voting rights at the board. If you were to select a new CIO, how would you
go about it to avoid a repetition of this situation?
Other ICT people
These come in two categories – those working in the ICT function and
knowledge workers who are able to perform some technical work such as
“End User Computing”.
Those working in the ICT function are the responsibility of the CIO and
the majority of them will be largely invisible in the organisation, partly
because of the work they perform which requires limited contact with
end users and their managers (there are exceptions such as the help desk
and installers).
ICT seems to attract people fascinated by technology, usually knowledge-
able and hard working. They are also happy not to have to talk to non-
ICT people and who, without the benefit of a good manager, will engage
in the mindless pursuit of perfection even when this does not add value
(but it is a great source of job satisfaction).
People engaged in End User Computing use their skills to create tem-
plates, complex spreadsheets, database queries, design web pages and,
sometimes, write small to medium size programs.
These skills can add value to an organisation and is part of the way in
which ICT is used by organisations. From an executive perspective the
only caveat to this work is that it should not and cannot replace a corpo-
rate ICT function in areas such as information security and quality as-
surance. To gain maximum advantage of End User Computing, there
should be a good working relationship between its practitioners and the
formal ICT function.
The risk of an out-of-control End User Computing environment is that of
creating islands of information where the use of non-standardised data
and inconsistent models delivers inconsistent results in different parts of
the organisation.
Organisational mistakes that prevent

the CIO from succeeding
A CIO faces many challenges and their success cannot be guaranteed.

Sometimes, organisations make it harder for them to succeed. CIOs wide-
ly agree that the two most common problems created by their organisa-
tions are executive detachment and arbitrary budget cuts.
Executive detachment is more acute where the CIO reports several levels
below the executive level and may have never met the executive team or
the Board members. Working in a policy and business strategy vacuum
the CIO, however good, will not be able to contribute business value.
Budget cuts are a fact of corporate life. When the budget cut however is
not targeted at specific elements but is a blanket percentage without dis-
cussion or explanation it strengthens the perception in the ICT function
that it is not seen as a contributor to the organisation.
Another self-imposed difficulty is choosing the “wrong” CIO. While in
the private sector this is usually resolved by the CIO leaving willingly or
otherwise, in the public sector and in organisations where political cor-
rectness is a major factor, the suffering and frustration can last for a con-
siderable time as the CIO will not be fired and may not wish to leave.
Good questions to ask ICT managers
The article entitled “Six IT decisions your IT people shouldn’t make” has
the subtitle “If your IT investments aren’t paying off, don’t blame IT”.
This article advises non-ICT executives to ensure that a) there is align-
ment between their organisations’ technology investments and corporate
strategy and that b) part of the way to achieve this, consists of not dele-
gating certain decisions to technical people or departments – hence the
six decisions in the title.
The article groups these six IT decisions in two categories: Strategy deci-
sions and Execution decisions. These six decisions are:
Strategy decisions Execution decisions

How much should we spend on How good do our IT services need
IT? to be?
Which business processes should What security and privacy risks
receive our IT dollars? will we accept?
Which IT capabilities should be Whom do we blame if an IT initia-
firmwide? tive fails?
The following list of questions is designed to supplement the above arti-
cle with an approach that could improve the dialog between executives
and ICT managers.
Six IT decisions your IT people shouldn’t make by Jeanne W. Ross and Peter Weill
published by Harvard Business School OnPoint, 2002
Questions on alignment
1. When proposing new investments in ICT systems and facilities, can
you show how these will contribute to business results and business
performance?
Rationale: To ensure that investments are not driven by technolo-
gies that are just “nice to have” or exercises in “me too” which may
give much joy to technical staff but are almost irrelevant from a per-
spective of providing some kind of return on investment.
2. What innovative and aligned projects or facilities have you initiated
in the last 12 months?
Rationale: To gain an insight into the ability of the CIO and the ICT
function to be innovative, aware of business needs and able to spot
opportunities to contribute to the effectiveness of the organisation at
what it does.
3. How often do you meet with Business unit (Department) managers
to discuss IT directions and issues, and what was the outcome?
Rationale: To ensure that the ICT function is not operating in isola-
tion from the rest of the organisation as this often leads to multiple
parallel initiatives in departments and business units. This can re-
sult in information anarchy because of independent and incompati-
ble initiatives. It can also lead to runaway expenditures.
Alternatively, this question may reveal that the CIO is concerned pri-
marily with running the infrastructure (which must of course run
properly) and has no time or interest to get involved with business
needs.
4. Do you maintain a formal and complete portfolio management ap-
proach for the organisation’s systems and technologies – does it in-
clude everything, including the work of departments, business units
and informal or “shadow” ICT groups?
Rationale: To ensure that ICT is actually “managed” in the organi-
sation and that strategic planning is supported by factual informa-
tion from across the organisation. If the CIO is unaware of the ICT
work done in other parts of the organisation, this should be taken as
a bad sign.
When the answers to these four questions are unsatisfactory, the
term CIO can be made to mean “Career Is Over”.
Questions on execution
5. When did you last procure an ICT audit (security/ technical)?
Rationale: In the absence of regular formal audits, technical, secu-
rity, compliance, or other, there is a risk that exposures to risk remain
unknown and unmanaged. A CIO’s self-perception of the quality of
their operations may be unduly optimistic and any shortcomings that
become visible will lead to a request for additional resources which
may not be the right answer to the problem.
6. How well is the IT work outside the ICT function/ outsourcer carried
out?
Rationale: If the CIO does not know – who does? In the case of out-
sourcing, monitoring what is delivered against what was specified is
critical.
7. Can you formally certify the security of our systems and infrastruc-
ture?
Rationale: The Chief Finance Officer is responsible for signing the
organisation’s accounts and submit them to independent audit. This
is rarely the practice in the ICT function where the CIO does not have
to sign anything (other than perhaps contracts). In the absence of for-
mal certification, particularly with regards to security, the organisa-
tion is facing a risk for which nobody is actually accountable. Recent
legislation (for example the Sarbanes-Oxley Act in the USA) is likely
to change this situation.
8. Who is responsible for information security and who is responsible
for monitoring and assessing these activities (qui custodiat custo-
dies)?
Rationale: Information security is a major area of concern for all ICT
operations and while many organisations have appointed Chief Se-
curity Officers, there needs to be clarity the lines of accountability
for security. If the CIO is not the person to whom the Information Se-
curity person reports, how can the CIO certify the security of systems
and infrastructure. And how does the CIO validate the performance
of the security person?
Questions on the financial aspects of ICT

9. What percentage of our organisation’s ICT expenditure goes to
a) operations and security,

b) applications maintenance and enhancements and
c) new systems for value creation?
and what are the trends in this area over the last three years ?
Rationale: It is not unusual for 70 to 80% of an organisation’s ICT
expenditures to be incurred to maintain the status quo, i.e. a) and b)
above. When the percentage is higher than this, the organisation is
at risk of lagging behind in their ability to exploit new technologies.
When the CIO does not actually know the answer to these questions
with reasonable accuracy, there may be a problem.
10. What percentage of our IT expenditure goes to
a) infrastructure and support and
b) core business activities?
and how do you project this to evolve over the next three to five
years?
Rationale: If the CIO has a strategic role in the organisation, the an-
swer to these questions should demonstrate a focus on alignment:
spending money to support core activities rather than having a world-
class infrastructure and good administrative and office automation
facilities. As in Question 9, when the CIO does not have good answers
to these questions, there may be a problem.
11. What comparative benchmarks have you carried out in the last 18
months? How well is the ICT function doing against comparable or-
ganisations, and what steps do you propose to take to contain costs?
Rationale: The amount of money that can be spent on technology
for its own sake is colossal – upgrading equipment too soon, over-
specifying capacity and performance, building a technical empire of
technical staff and many other such areas are easily drifted into.
Benchmarks against published information from reliable sources are
good indicators of the efficiency of an ICT organisation.
Not conducting such comparative benchmarks may indicate a “could
not care less” attitude with regards to expenditure management and/
or an attitude that the pursuit of perfection justifies spending more
than necessary, or at least more than other comparable organisations
do.
12. On the basis of these benchmarks, have you explored with outsourc-
ing companies the case for outsourcing our organisations operation-
al and/or project work – when was this and what was the outcome?
Rationale: CIOs that willingly consider outsourcing separate them-
selves from the technically focused crowd, as the latter see running
technology operations as the purpose of their life and are most reluc-
tant to consider outsourcing, seeing it as “giving their jobs away”. A
lack of interest in what the outsourcing industry can offer, evidenced
by an answer that shows such a possibility has not been actively pur-
sued claiming it would be “too expensive”, confirms such technical
focus.
Action Points
Be aware of the nature of your organisation before selecting and appoint-

ing a CIO. A poor choice may have consequences that will last years.
Establish a regular dialog with the CIO – the supplement to this Chapter
contains 12 questions that should be asked of CIOs. Some of the questions
may not be well received but are critical to the successful deployment of
ICT in an organisation.
C h a p t e r
15
Outsourcing
“Divorcing your outsourcer - Divorce &

Reconciliation Strategies in Outsourcing”
Title of a report by B.J. Dooley published in 2003

by the Cutter Consortium
• What activities lend themselves to outsourcing?

• What are the benefits, disbenefits and risks of outsourcing?
• What is needed to be successful in outsourcing?
• What are the steps involved in doing an outsourcing deal?
Outsourcing and offshoring have been hailed as a great way to gain access to specialists,
benefit from economies of scale and contain the cost of ICT. These activities have also been
demonised by politicians and the media as job-destroying practices that cause considerable
suffering to the individuals affected by outsourcing.
Like with everything else, both perspectives have their element of truth and the decision to
outsource is never a simple matter. Well thought out strategies to outsource ICT activities
implemented with companies that can deliver the expected results can make a major dif-
ference – DuPont de Nemours (discussed here) is a good example.
There are also instances where poorly planned and poorly negotiated outsourcing con-
tracts resulted in both high cost and dissatisfaction with service quality. Good preparation
and an understanding of the long term nature of outsourcing contracts and the many trad-
eoffs to be made are essential.
Offshoring (outsourcing to a country with low labour costs) brings with it the factor of in-
ter-cultural communications which, if not properly understood and managed, could have
disastrous results.
Setting the scene for outsourcing

and offshoring
Outsourcing is the mechanism through which technology services are

bought from an external specialist party on a contractual basis instead
of performing those tasks with internal resources. Offshoring is outsourc-
ing where the service provider is in another country, typically with con-
siderably lower labour costs.
By early 2004, global I.T. outsourcing has become a robust industry reach-
ing an annual volume of business in excess of 100 billion dollars. The
choice of services has expanded to include in addition to facilities man-
agement and infrastructure operations:
• network management and operations

• maintenance of legacy applications
• development of client server applications
• customisation and implementation of Enterprise Resource Planning
(ERP) systems
• development of e-commerce and e-business applications
• application service providers
• web and e-commerce hosting
In addition, business process outsourcing is on the increase handling ac-
tivities such as order fulfilment and warehousing to support e-business-
es.
Outsourcing thrives because organisations recognise they cannot be ex-
pert in everything, and that when you are not expert you risk unneces-
sary expenditures and mediocrity.
The decision to outsource is never simple and the answer is not always
obvious and the decision to outsource should not be delegated to ICT peo-
ple who have a significant vested interest in maintaining the status quo.
Activities that lend themselves to outsourcing

Processes
Process work includes activities that can be standardized, systematized,
documented and automated. Such processes are monitored with perfor-
mance metrics relatively easy to acquire and track. Examples of out-
sourceable ICT processes include
• Data centre operations;
• Operations of distributed systems, including desktops, Local Area
Networks, end user support, etc.;
• Operations of Wide Area Networks and the corresponding network
management;
• Information security;
• Applications Service Providers (ASP);
• Services for e-commerce and e-business;
Data centre operations
The oldest ICT outsourcing activity. Here, the hardware, software, staff
and other components of a data centre are transferred to a specialist third
party. These services are usually provided from the vendor’s premises.
The vendor undertakes to deliver services to a contractually defined ser-
vice level.
Distributed systems and desktop operations and support
Here the large number and nature of the items involved requires the ven-
dor to be present at the client’s premises. It is usual for the outsourcer to
have a major, often total, say in technology choices, management tools
and all other items that have an impact on service delivery;.
Information security
The operational aspects of security (provision and management of fire-

walls, antivirus and anti-spam tools, intrusion detection, etc) are all based
on structured processes and require the same amount of trust and verifi-
cation as needed for other operational processes where the outsourcer be-
comes the custodian of data and other forms of intellectual property.
Wide Area Networks
The deregulation of the telecommunication industry has led to competi-

tion, lower charges and the wider availability of global connectivity. This
created a market for the provision of managed wide area network servic-
es. Telecommunications operators have also entered the outsourcing mar-
ket for distributed systems.
Application Service Providers (ASP)
A relatively new outsourcing business, it was initially targeted at small

and medium size enterprises. An ASP deploys, hosts and provides all the
activities and expertise required for a set of applications (for example En-
terprise Resource Planning) through the Internet.
The client buys access to a managed application and the ASP provides the
software licenses and the infrastructure to host, operate and support
these applications.
The main characteristic of the current ASP market is that their offerings
are standardized or have minimal customisation.
e-commerce and other Internet Age outsourcing models and practices
The dynamics of e-commerce have highlighted the importance of infor-

mation security - the need to guarantee to clients and consumers that
their data (e.g. proprietary processes, payroll information, customer de-
tails and credit card numbers) will remain confidential and not be mis-
used or modified without due authorisation.
Software projects
No two projects are the same. Software projects are invariably non-stan-
dard and often not very structured even when packaged products and
standard methodologies are used. They also require considerable creative
input. Their metrics are more complex to define, collect and manage than
for processes.
Outsourceable software projects include the maintenance of legacy appli-
cations, the customisation of Enterprise Resource Planning (ERP) pack-
ages, the design of totally custom software for a single client and the de-
sign of websites.
The skills required for this work are in short supply and many companies
across the world that have built large software factories employing 500 or
more employees, using Rapid Application Development tools, are Total
Quality Management certified.
Outsourcing the maintenance of legacy applications
The maintenance of legacy application software is mainly outsourced be-

cause of the need to free up staff for new projects. As such software is of-
ten poorly structured and documented, this requires many exchanges be-
tween the client and the outsourcer’s personnel.
Outsourcing the development of computer applications and website design
For large new systems, the requirements defined at the outset of the proj-
ect will change many times as the development work progresses. This will
require intensive interaction between client and vendor, likely to include
a physical presence at the client’s premises.
Outsourcing system customisation, integration and operations
Such projects are always complex. In the case of Enterprise Resource

Planning systems (ERP), their customisation requires expertise in spe-
cific products (such as SAP™, Oracle™ or Peoplesoft™).
It is customary for specialists to work closely with the customer as chang-
es to requirements will emerge at each stage of the project as familiarity
with the capabilities of the system and an understanding of what it can
deliver are built in the client organisation
Benefits, potential problems and risks

in outsourcing
Benefit # 1: Cost reductions

In process outsourcing, these are delivered by the out-
sourcer’s economies of scale and ability to leverage the
procurement of hardware and software and also the
transfer of personnel to the outsourcer, leading to low-
er overheads.
As outsourcing also moves assets off the client’s balance sheet and avoids
capital expenditures, it can show an improved return on investment.
In project outsourcing, cost reductions arise from:
• the vendor’s ability to reuse code libraries developed for other proj-
ects;
• developing software on an assembly-line basis;
• the use of Rapid Applications Development and other specialized
tools;
• lower salaries, particularly in offshoring.
Benefit 2: Improved quality of service

These are achieved by having access to the industry’s best practices and
through access to skills that are in short supply. This is particularly true
when the in-house service provision has a poor track record.
Benefit 3: Ability to obtain resources and capacity on demand
The client transfers to the vendor the responsibility for providing capac-
ity as and when required, as well as for finding qualified personnel to cov-
er the unavailability of a person assigned to a process or project or to meet
changing needs.
Benefit 4: Reduced managerial distractions
The outsourcer takes over responsibility for many managerial and ad-
ministrative tasks such as staff recruitment, administration, training,
technology assessment and procurement. Besides, the contractual nature
of the outsourcing relationship simplifies the I.T. budgeting process.
Mini-case study: DuPont de Nemours

In 1990, DuPont, an international advanced materials and chemicals company with
over 1,000 offices around the world and with some 75,000 networked computers,
became aware of the extensive diversity of information systems among business
units and of the multiple data centres providing ICT services to the company.
The Chief Information Officer at the time, Mrs. Cinda Hallman, estimated that the
total cost of ICT to the company was 1.2 billion US dollars per year and began a pro-
gram of rationalisation, standardisation and consolidation (and was recognised as
“CIO of the Year 1995” by CIO Magazine) in order to prepare the ground for the
outsourcing of all of DuPont’s computer systems development and day-to-day oper-
ations – from data centres to help desks.
In 1996, an outsourcing contract was signed with a consortium of Computer Sci-
ence Corporation (CSC) and Andersen Consulting (now Accenture). This contract
was worth 4 billion US dollars over 10 years and involved the transfer of 2,600 Du-
Pont employees to the outsourcing consortium.
In an article in the Financial Times in 2002, the CIO of DuPont stated that the com-
pany’s ICT expenditures had been reduced to 600 million US dollars a year – 50% of
what they were spending ten years while the ubiquity and use of ICT had grown rap-
idly during this period.
However, every outsourcing project also has potential disbenefits.

Disbenefit I: Management costs
While an outsourcing vendor can deliver services at lower costs, the cli-
ent needs to incur costs that did not arise prior to deciding to outsource.
Examples of these are:
• The legal costs of contracting;
• Higher costs of changes: every new requirement, changes in scope of
services, technology, charges, etc., will be treated as a contract
amendment and may be premium-priced;
• The cost of monitoring performance. This is needed to validate that
services are delivered to the agreed quality level, that issues arising
in the execution of the contract are logged and raised, etc. Where
services are provided by an in-house organisation this activity is fre-
quently seen as not required.
Disbenefit II: Potential lock-in to an outsourcer
Once a client has transferred its information technology assets and intel-
lectual property to a vendor, and divested itself of personnel and their ex-
pertise, it is hard to reverse the decision to outsource
Disbenefit III: Underperformance by the outsourcing vendor
A considerable amount of senior management time may be needed to deal
with an outsourcing vendor that consistently under-performs. Situations
that would qualify as “underperformance” include:
• Failure to deliver the agreed service level;
• Replacing staff originally assigned to the client by less qualified or
less experienced personnel;
• Giving a lower priority to the client than that given to a larger cli-
ent.
Disbenefit IV: Outsourcer abuse
Although not a good business strategy, it sometimes happens that the in-
terest of the vendor takes precedence over the client’s interest. Such situ-
ations may include:
• Improper billing, particularly in project work, where more man-
hours are charged than are incurred;
• Exploitation of the client’s intellectual property in software for the

vendor’s gain without the consent or participation of the client, as in
the case of reusing code in a project for a different client;
• Outsourcing contracts must be flexible to accommodate the inevita-
ble changes in requirements that will occur during the duration of
the contract. Instances of premium level re-pricing of contract exten-
sions and modifications, applied to take unfair advantage of a lock-
in situation have occurred...
Other areas of outsourcing risk
• The risk that a small vendor will be taken over by a big vendor or that
it will go out of business;
• Selecting the “right” vendor at a time when the outsourcing industry
has become complex, with a growing number of players, domestic
and international;
• The complexity of service level management in the Internet Age and
the many parameters that an outsourcer cannot control;
• Potential loss of data confidentiality and other security issues
Making the decision to outsource
Outsourcing decisions are driven by factors such as poor quality of ser-
vice, an inability to recruit and retain qualified and experienced person-
nel and/or a policy to concentrate or core activities. The decision is com-
plicated by a perception that outsourcing may be “expensive” when in re-
ality the true costs of in-house ICT activities may not be particularly well
known.
The initiative to consider outsourcing should be taken by the Chief Exec-
utive or the Board of Management. While a CIO may propose such a
move, ICT in general have a vested interest to retain their jobs and are
unlikely to recommend outsourcing unless they know something the ex-
ecutive does not…
Side effects of outsourcing
In every successful outsourcing case study, the transfer of responsibili-
ties to a third party removes many time-consuming activities from the
daily agenda of the CIO, in particular, participation in technology-buy-
ing decisions. This releases time to deal with strategic information sys-
tems issues, policies and strategies which should not be outsourced.
Regardless of whether activities are outsourced or not, the CIO remains
accountable when something goes wrong. In a situation where outsourc-
ing does not work well, the CIO needs to quickly find out the reasons for
this and act accordingly. Otherwise, a problem can become a crisis that
paralyses the organisation.
There are many variants of “people issues” in outsourcing and these can
cause outsourcing to fail.
To the staff affected by a decision to outsource, this is a political and emo-
tional issue, as it will change their employment, their terms and condi-
tions, the location where they work and more.
As the language associated with process outsourcing often uses expres-
sions such as “non-core activities”, “zero added value”, “lean and mean”
when referring to jobs to be transferred to the outsourcing vendor, the
people doing these jobs will find it difficult to avoid making value judge-
ments and can be expected to be critical of the whole issue.
There is a risk that some unrecognised or undervalued skills will only be-
come apparent when they are withdrawn, such as in the case of unique
knowledge relating to a “legacy” application. This is a common situation
and it can also arise with downsizing and early retirement programs.
Additional complications in offshoring or international outsourcing

Software maintenance and development, the usual target for offshoring,
requires good communications. English is the generally accepted busi-
ness language for international software projects. When English is a sec-
ond language for the outsourcer or for both parties, effective communi-
cations becomes an issue, because of the combination of language mas-
tery and cross-cultural differences.
Cross-cultural differences include the use of spoken and written lan-
guage, body language, decision making styles, negotiating, conflict res-
olution, respect for hierarchy and age, the need to save face and many oth-
ers that may be totally unknown or misunderstood by both parties.
Examples of situations commonly occurring in such situations include:
• People from another culture who would prefer to stay silent rather
than “lose face” by asking for clarification;
• People from another culture who will not volunteer information
about problems they have encountered;
• People from another culture who have a different concept of time. In
such situations “by close of business today” is more precise than “as
soon as possible”;
Critical Success Factors (CSF)
Once the decision to outsource has been taken, it must succeed.

CSF # 1: Viability of the outsourcing option
The objectives of the client, whatever they may be, must be realistic,
achievable and clearly understood by all parties.
The client must understand the consequences of outsourcing, in partic-
ular how it will impact on personnel and on its financial, taxation and le-
gal implications.
Outsourcing processes that do not work well will not make things better.
The client should fix such shortcomings before outsourcing or engage a
third party, possibly the chosen vendor to address these shortcomings be-
fore outsourcing.
When outsourcing software projects, the most successful situations in-
volve clients who have the capability of developing the software them-
selves and opted instead to outsource in order to use their personnel for
other projects with higher business value.
CSF # 2: Thorough understanding of the scope of outsourcing, and real-
istic expectations.
The client must ensure when preparing to outsource, certain responsibil-
ities are not ignored. These include:
• The definition of the scope of services to be provided;
• The definition of current service levels (which should be validated by
the selected outsourcer);
• The definition of the target service levels expected from the outsourc-
er;
• The definition of the division of responsibilities between client and
outsourcer;
• The definition of management controls, including the right to audit
the outsourcer;
• The identification of personnel that will remain with the client and
those that will be transferred to the outsourcer;
• The management of organisational and other changes required as a
result of outsourcing;
• For project work, definition of performance metrics;
• The definition of measures to be taken to protect the client’s intellec-
tual property, confidentiality, data integrity etc.
CSF # 3: Legal support

A legal team with knowledge and experience of outsourcing contracts
should be involved from the preparation of the Request for Proposals un-
til the contract is signed. The same applies to all amendments to the con-
tract.
CSF # 4: Relationship management
The client should identify a vendor well suited to meet the overall objec-
tives of the particular outsourcing and in particular, a trustworthy and well
managed vendor whose prime objective is to maintain its reputation.
The relationship between client and vendor begins at the time of contract
negotiation, and will be a key component of service delivery for the du-
ration of the contract. Success in this area requires the existence of good
communications arrangements, frequent contact and the goodwill nec-
essary to build an effective relationship. Success in outsourcing is there-
fore a joint venture where there are no winners and losers; either every-
one succeeds or everyone fails.
A step-by-step guide to managing

the outsourcing process
Step 1: Selecting a vendor

Because of the critical role that ICT play in an organisation the process of
selecting one or more vendors must be focused on finding a vendor who
will take responsibility for success.
The best way to prepare includes at three components:
• The preparation of a Request for Information and a Request for Pro-
posals;
• The definition of the criteria and techniques that will be used to se-
lect a vendor;
• The decision whether to employ external advisors or to rely exclu-
sively on in-house staff to perform the selection.
Step 2: Preparing a Request for Information
Having identified the costs, benefits and risks of outsourcing and of al-
ternatives (which include the “do nothing” option, it is useful to issue a
Request for Information (RFI).
Here, an outline of what is intended is distributed to potential vendors.

Their replies will indicate their interest and provide information about
their capabilities and client base. An RFI can and should include a sec-
tion where potential vendors are invited to propose ideas on other value
added services they could provide if awarded the contract. Replies to an
RFI are non-binding.
It is also good practice to obtain additional information about potential
vendors such as their companies annual report, independent financial
assessments and client references.
Step 3: Preparing a Request for Proposals
A Request for Proposals (RFP) is a record of the potential client’s require-
ments. This is a complex and resource-intensive task. It may be appropri-
ate to employ the services of an experienced consultant to prepare this
document. It would be frustrating to discover during the evaluation phase
that a critical requirement was omitted. Before releasing a proposal, it is
prudent to consider seeking a legal review by a lawyer familiar with the
outsourcing industry.
Step 4: Proposal evaluation
It cannot be assumed that all the proposals received will match exactly the
scope of services described in the RFP. Attention needs to be given to:
• Services and/or features which are excluded from the offer;
• Proposed performance levels that differ from those requested;
• Schedules that do not meet the clients’ requirements;
• All other differences from the client’s original requirements;
Step 5: Vendor selection criteria
These would usually include the vendors’ technological capabilities, track
record and reputation, the existence of a prior working relationship, their
viability and stability, price, knowledge of the client’s business, ISO 9000
and equivalent qualifications, and location (including language and cul-
ture), and, of course, price.
However, some of these criteria are “soft” and comparisons between ven-
dors may include subjective elements and because of this, the evaluation
may be influenced by the evaluator’s knowledge or familiarity with a par-
ticular vendor.
Moreover, to demonstrate their track record, vendors are likely to provide
as references clients who are their greatest successes. Evaluators should
ask vendors to provide information about dissatisfied clients, and these

references must be followed up.
An independent assessment of a vendor’s financial viability is particular-
ly important when dealing with smaller or more recently established ven-
dors. This can highlight potential financial problems that could inhibit
their ability to deliver.
There are techniques to minimise bias from complex decisions involving
many people and many factors. One such technique is that of Weighted
Ranking by Levels (WRBL), and is particularly suitable when:
• There is a need to choose among several alternatives
• The decision needs to be objective
• The decision should be agreed upon by a group
Step 6: Preparing for an outsourcing contract
Finalising an outsourcing contract is a specialised task. The biggest risk
in outsourcing is that of being contractually committed to an unsatisfac-
tory arrangement.
A formal agreement may consist of several contracts including a portfo-
lio of service agreements with the detailed definition of the scope of ser-
vices and performance for each service.
Negotiating an outsourcing contract is hard to do when the buyer may be ne-
gotiating his/her first outsourcing contract with a company that has hun-
dreds of such contracts in place. Good preparation is vital, as the contract will
be the foundation for the working relationship between of the two parties.
The contracts should make clear:
1. The process for transferring personnel, intellectual property, licences,
hardware and other assets from the client to the outsourcer, including:
• Definition of the ownership and valuation of all assets to be trans-
ferred;
• Ownership and reassignment of leases, licences, etc.;
• Proprietary software: Who retains ownership, who has access to
the source; code, exploitation rights of the outsourcer, terms of sup-
ply of documentation;
• Knowledge transfer (what, when and how);
• Identification of the personnel to be transferred;
• Involvement of third parties (vendors, lessors and other financial
institutions, disaster recovery operators, etc.);
• Disaster-recovery services, documentation, test results, etc.;

• Issues related to premises, etc.
Unless the selected outsourcer is thoroughly familiar with the activ-
ities and organisational culture of the client, the transition period
should be used to refine and validate such matters as objectives, mea-
surement procedures, and reporting arrangements.
The transfer process should be approached as a major project by both
parties. High-level project management must be in place to deal with
all supplier contracts and documentation, and appropriate controls
must be in place. Milestones and the schedule of payments should be
clearly defined.
2. What and when will be provided to the client after completion of the
transfer:
• Start date;
• Items that can be shared with other clients of the outsourcer and
items that must be dedicated to the client;
• Disaster recovery arrangements;
• Right to audit the outsourcer;
• Pricing arrangements (fixed cost, cost plus, benchmarks, benefits
sharing, etc.);
• Copyright, intellectual property, confidentiality and data protec-
tion (licensing patents and trademarks to the outsourcer);
• Compliance with legislation and regulations;
• Change control procedures;
• Client rights to audit the services, charges and other vendor activ-
ities pertinent to the contract;
• Warranties, liabilities and indemnities (service levels, consequen-
tial losses, extra costs);
• Management of the relationship (appointed representatives, regu-
lar meetings, right to audit);
• schedule of payments, etc.
Vendors will invariably propose their own standard terms and condi-
tions. These are designed to be biased in their favour. A well-negotiat-
ed variant of such contracts or individually tailored contract should be
the preferred option to maintain a balance between the parties. This
is a major undertaking involving the lawyers from both parties.
While discussions relating to the contract should be treated as con-
fidential and subject to incorporation in the final contract, promis-
es made by sales people during negotiations should be obtained in

writing to avoid subsequent disputes.
3. The process of retuning assets, personnel, intellectual property, etc.,
to the client should the contract be terminated or other circumstanc-
es so require.
• Every contract is different in this respect and this topic should be
the subject of individual study for each specific situation, but the
possibility of divorcing the outsourcer must be given due to con-
sideration before the contract is signed.
• The contract should specify the procedures for amendment (change
of scope or deliverables) and termination (including definitions of
the period of agreement, notice of termination, special instances
(insolvency/breach of contract)) and, in the latter case, the detail
arrangements for returning all appropriate items to the client.
Contract negotiations must specifically focus on liabilities. Vendors will
strive to keep their liabilities to a minimum. This is not unreasonable giv-
en that the price of the contract must include the cost of insurance and/or
the risk of failure, which could be significant in unusual or complex situ-
ations. Other clauses concerning liabilities are those of consequential loss
(for example, of profit or of goodwill), are particularly hard to quantify.
The possibility of obtaining liability insurance should be investigated.
Copies of the contract should be distributed to all parties who may need
them, and the production of a plain language summary may be a valu-
able supplementary document.
The contract should specify mechanisms for the resolution of disputes
and arbitration, including definition of legal framework that will apply
(country or place of resolution).
Action points
Be clear about the objectives for seeking an outsourcing option. The over-
all track record of ICT outsourcing is pretty good and reducing costs is
not the only reason for pursuing this path.
Remember that the people carrying out activities suitable for outsourc-
ing have a vital interest in preventing this from happening and that their
views are likely to be biased.
C h a p t e r
16
Legal and ethical
aspects of ITC
Laws are like sausages. It is better not to see them being made.
Statement attributed to Otto von Bismarck (1815-1898)

• What is so different about ICT legislation?

• What is covered by legislation directly related to ICT?
• Are ICT contracts really that different from other contracts?
• How do I know my organisation is not breaking the law?
• Ethical issues in the workplace – what exactly is this all about?
The good old days when the Chief Legal Counsel looked after legislative matters, the Chief
Information Officer ensured ICT worked properly and the Chief Executive could delegate
these matters are, in many countries, over. Recent legislation on Data Protection and on re-
porting financial results (such as Sarbanes-Oxley in the United States of America), makes
directors personally liable and penalties, under criminal law, can be severe.
There is a substantial amount of legislation relating to ICT, and this is evolving rapidly, but
not as fast as technology or cybercrime. There is also significant disparity between legal de-
velopments across countries and what may be an offence in one country is not considered
so elsewhere. This is being taken advantage of by cyber-criminals and also by various ac-
tors in marketing (namely spammers) who move their actual technical operations to coun-
tries that do not legislate against such activities.
In addition to cybercrime, there are laws concerning the workforce’s health and safety at
work, computer misuse and abuse, national security and, most recently, the need to en-
sure that computer systems cannot be exploited to create misleading or fraudulent finan-
cial statements and reports. There are also important legal issues of protection of intellec-
tual property.
Contract law, particularly that relating to computer contracts, is another potential mine-
field for the unaware and the Romans’ Caveat Emptor remains good advice.
Finally, there are many issues of human rights and freedom of expression that need to be
meshed with an organisation’s code of conduct, in particular concerning what represents
appropriate personal use of the organisation’s ICT resources by a member of the workforce
and the extent to which the employer may monitor an individual’s activities, examine the
contents of their computer and conduct investigations on the basis of perceived unusual
activities.
About the law and ICT
Legal matters
Societies have formulated laws codifying their behaviour in terms of what

they considered to be permitted and what is not. An example of such ear-
ly legislation is the Code of Hammurabi (the ruler that created the great-
ness of Babylon (1795-1750 BC).
Today there are several legal codes covering virtual-

ly all areas of activity. While laws have largely the
same intent, there are substantial variations between
countries.
Non-compliance with legal matters may result in
prosecution and punishment if the party being pros-
ecuted is found guilty.
Because law develops at a slower pace than creative
innovation, there are gaps – for example the issue of
undesired electronic mail (spam) is only recently be-
ing addressed by lawmakers and countries are not all
at the same stage of development.
While such gaps exist they are a license for individ-
uals and organized crime to exploit them, and this is
the current situation in many areas of the informa-
tion society. When apprehended and tried individu-
als may be judged by courts that make a best effort
to adapt existing legislation. Some are released be-
Code of Hammuarabi. cause the courts consider that in the absence of leg-
The Louvre, Paris
islation their actions did not constitute an offence.
An example can illustrate this situation: a young student of computer programming in the
Philippines, Onel de Guzman, was accused in May 2000 of creating and disseminating the
“I love you virus” which was sent as an e-mail attachment and infected a large number of
computers and deleted certain types of files (mp3 and jpeg among them).
After being traced, arrested and charged, the Department of Justice in Manila dropped all
charges against de Guzman in August 2000 despite the fact that this virus had affected
tens of millions of computers. California-based IT consultancy Computer Economics esti-
mated worldwide damage to be $2.6bn by the end of its first week of circulation.
National legislation can have considerable impact when it affects multi-

national organisations as compliance becomes an important issue. The
joint efforts of executives, legal officers, internal and external auditors
and ICT managers to ensure diligence and compliance are essential.
The special nature of legislation concerning ICT
Old laws, those that predate the information age, are primarily concerned
with tangible objects. The major exception to this are laws dealing with
defamation and libel, focusing on an individual’s reputation.
Data and information are incorporeal – their only physical manifestation
is the package in which they are contained regardless of its form (disk,
CD or DVD, newspaper, book). Their proliferation has created new re-
quirements to provide a legal framework for the correctness and integri-
ty of data and for protecting individuals about the misuse or abuse of data
about them in electronic form.
Additional “old law” problems still exist in some countries where for ex-
ample legislation on theft, larceny and embezzlement requires the offend-
er to take an item of another person’s property which could be interpret-
ed to be limited to tangible objects.
Similarly, under some legislation, fraud requires the deception of a per-
son and therefore it would not cater for a situation where the one defraud-
ed is a computer and its software.
Facts about the law
Fact # 1: There are thousands of laws, by-laws and other codified state-
ments around the world. These evolved when the need for amendments
or new legislation became apparent because existing laws could not be
satisfactorily interpreted or modified to apply in a new situation.
Interpreting existing laws in
a new context does not re-
sult in consistent results as
analogies are not always ap-
propriate and are challenged
on appeal.
As a result, legislation always lags behind technology. For example in
2004 there is no international legislation on transnational cyber-crime
or on several other areas of contemporary concern such as genetically
modified foods. The Council of Europe Convention on Cybercrime en-
tered into force in 2004 but has only been signed by 33 countries, many
of which have not yet ratified it.
Fact # 2: Legislation is often a lengthy process. The OECD had discussed
the criminalization of computer abuse in 1983 to 1985 and the Council of
Europe initiated work towards the convention shortly after that. It was
only in November 2001 that the Council of Europe got 33 countries to sign
its Convention on Cybercrime. The convention finally entered into force
in 2004 after being ratified by the required five countries.
There are exceptions, particularly in national legislation. The Sarbanes-
Oxley Act of the USA was passed in a relatively short time to reflect the
need to regulate accounting in the light of scandals arising from overly
creative statements of financial results.
Fact # 3: The absence of legislation is a time of opportunity – just like the
“Wild West” of the United States of America in the 19th century attract-
ed adventurers and risk takers, cyberspace, the world of data and soft-
ware, has many parallels in particular the knowledge that when some-
thing goes wrong the legal framework might not be there and that the re-
sources available to “police” cyberspace are very limited.
Fact # 4: People with malicious intent – from fraud to theft of intellectu-
al property, including identity theft, unsolicited e-mail (spam), virus and
worm writing, do so in the knowledge that even if they are caught the
chances of a successful prosecution against them are small.
Fact # 5: Even when legislation, conventions, agree-
ments do exist, not all countries in the world respect
them to the same degree – the business of pirated
software, DVDs and other counterfeit products (in-
fringing copyrights) represents billions of dollar of
trade outside such agreements.
Fact # 6: Ignorance of the law is no excuse. This is
particularly true in a corporate context.
ICT related areas are covered by

legislation
The amount of legislation both civil and criminal re-

lating to ICT is substantial and covers areas such as:
Health and safety in the workplace
Computer misuse
Regulations governing specific activities (e.g. finan-
cial accounting)
Privacy
Rights of access to personal information held by third parties
Defamation and libel in cyberspace
Data protection
Software copyrights and patents
Contractual obligations of ICT vendors, including ISPs
Electronic contracts
Digital signatures
Taxation of e-commerce
Censorship
Obscene publications
Protection of minors
Consumer protection
Gambling in cyberspace
Money laundering through electronic means
Telecommunications interception
National security and anti-terrorism
Search and seizure of ICT material to be used as evidence
And indeed much more.
For the purpose of illustration, the main legislative instruments in Great
Britain relevant to ICT include:
The Data Protection Act (1998)
The Regulation of Investigatory Powers Act (2000)
The Copyright, Designs and Patents Act (1988)
The Computer Misuse Act (1990)
The Operating and Financial Review Regulations (2005)
The Privacy and Electronic Communications Regulations (2003)
and many more…
As another example, France introduced the law 2004-575 “Loi our la con-
fiance en l’economie digital” – the Law for trusting the digital economy”.
Organisations that operate in many countries need to know that varia-
tions in the application of such laws varies greatly, particularly when
these laws interpret the requirements of regional legislation (such as Eu-
ropean Union Directives) in different ways.
To make matters more complex, companies listed in the United States of
America also need to comply with the Sarbanes-Oxley Act, passed to deal
with irregularities in financial reporting following a number of situations

where creative accounting exceeded the boundaries of what was tolera-
ble. Sarbanes-Oxley’s Section 404 has a profound impact on the ICT ar-
rangements, controls and operations of organisations.
Other regulations – for example Basel II for financial implications create
their own needs for ICT systems and facility to comply with them.
Several surveys of the status of ICT-related legislation have been conduct-
ed by various researchers. One example of such collections of references
available online can be found at:
http://www.ll.georgetown.edu/intl/guides/cyberspace/cyber_3.html
This is an academic institution that provides a guide to topical areas of
legislation, notably electronic commerce and computer crime, and pro-
vides links to related information sources and discussions.
National legislation is often in advance of regional and international law
and as a result, there are significant variations in national legislation and
many areas of ambiguity.
The joint efforts of executives, legal officers, internal and external audi-
tors and ICT managers are needed to ensure that appropriate diligence
and compliance are part of the work environment.
The slow adoption of the Council of Europe’s Convention of Cybercrime
confirms the disparity in legal provisions and indicates that there are
problems of jurisdiction and international cooperation to deal with such
situations.
There is some international legislation dealing with data, computers and
software, for example the United Nations Convention On Contracts For
The International Sale Of Goods (1980, ratified 1988). This convention is
of a general nature and deals with the sale of goods. As such it includes
computers and other ICT hardware.
However, the term “goods” is not defined. Whether software is covered by
the Convention is contentious, as under most national sale of goods legis-
lation, package software supplied on a physical carrier (such as a disc) is
more likely to be considered goods than bespoke software, as the latter is
treated as a service. When the software is downloaded across borders, as is
increasingly the case, the applicability of the Convention is unclear.
Complex situations arise when it is necessary to exchange data, particu-
larly personal data across borders between countries that have dissimi-
lar legal frameworks: as part of its measures to strengthen security, the

Homeland Security department of the United States of America signed
an agreement with the European Commission to provide advance pas-
senger information (API) on travelers on planes and ships with destina-
tions in the USA.
The USA does not have legislation equivalent to the Data Protection Di-
rective and the European Commission found that the measures in the
agreement gave “adequate protection” to the information transferred.
However, in May 2004, the European Parlament decided that the agree-
ment does not offer adequate protection. The subject was still under dis-
cussion at the time of writing this Chapter.
Two pointers towards the way international cooperation and legislation
can evolve can be found in the United Nations past initiatives, both cur-
rently operational:
• The Law of the Seas (http://www.un.org/Depts/los/index.htm)
• The Office for Outer Space Affairs (http://www.oosa.unvienna.org/)
These initiatives have good analogies with the world of data, software and
information systems, particularly with regards to areas such as common
and individual ownership, rights of shared use, military use and many
other.
The World Summit on the Information Society (WSIS) held in Geneva in
December 2003 discussed some of the legal issues around Internet Gov-
ernance. The subject continues to be discussed in multilateral interna-
tional organisations such as the World Intellectual Property Organisa-
tion (WIPO), the International Telecommunications Union (ITU), the
United Nations (UN), the World Trade Organisation (WTO) and the Or-
ganisation for Economic Cooperation and Development (OECD) and oth-
ers, including non-governmental organisations – for example the Inter-
national Chamber of Commerce.
Some legislation, regardless of where it first enters into force, can have a
major impact on information technology practices and operations as well
as on related audits and security measures elsewhere.
One current example arises from the Sarbanes-Oxley Act (United States,
2002) that introduced requirements for the retention of documents in
electronic form and appropriate monitoring mechanisms that include:
centralized e-mail system, hard drive data and backup tapes, employee
floppy disks and home computers, company laptops, cellphone and per-
sonal digital assistant logs, cookie files and personal history files, Instant
Messaging (IM). The possibility of similar requirements being introduced
into the legislation of other countries cannot be excluded.
ICT contracts and licences: practical issues
Hardware
Buying and leasing hardware is well established, well legislated and in
principle unproblematic. These are goods that are traded in a fairly com-
petitive market. The word “fairly” is used because not all ICT hardware
consists of commodities available from several vendors. Proprietary
equipment continues to be manufactured for specialised applications and
migrating from one set of proprietary “standards” to another is usually a
complex project with significant risks and costs.
Software
Software is quite a different story, as it does not consist of tangible goods oth-
er than the storage device on which it is stored in electronic form (a diskette,
CDROM, tape or similar carrier) and when the software is in fact download-
ed from one server to another computer, it has no tangible form.
This is one part of the problem. The other is the ownership of the intel-
lectual property of the software. The two most common situations are
those of obtaining a license to use a product and that of developing cus-
tom software for use by a particular organisation or company.
Product licenses for software are no more than permission to use a par-
ticular set of programs, and the software itself remains the property of
the supplier at all times.
Product licenses for software come in three distinct models: Proprietary
software supplied by a commercial company against a license fee; Share-
ware, where the owner of the intellectual property is not necessarily a
company and offers a license against a modest payment which is often
left to the discretion of the end user and Freeware which can be obtained
free of charge.
In the case of shareware and freeware, the end user acknowledges to use
the software “as is” and accepts that it does not have warranties and that
the provider will not accept any liability for situations arising from the
use of such software.
The legal status of software product licences is somewhat ambiguous and
depends on the type of software in question and on the countries where
the transactions take place.
(NB Open Source software is a form of shareware increasingly being dis-

tributed by commercial companies who charge a fee to provide product
support, documentation and related services).
Starting with the contracts generally known as “shrink-wrap licenses”
typical of software packages for personal computers, software produced
in the USA makes use of the provisions of the Uniform Computer Infor-
mation Transactions Act (UCITA), developed by the National Conference
of Commissioners on Uniform State Laws and approved for use in all the
States of the USA.
UCITA is a contract law statute applicable to computer software, multi-
media products, computer data, computer databases, online information,
and other similar products. It was designed to create a uniform commer-
cial contract law for these products and is described as “a cyberspace
commercial statute.”
UCITA has been criticised because it appears to allow software publishers to:
• Change the terms of the contract after purchase;
• Deliver products that contain “back door” entrances, potentially
making systems using this software vulnerable to infiltration by un-
authorized parties, including hackers;
• Sell their products “as is” and to disclaim liability for product short-
comings.
In addition, UCITA allows restrictions that prohibit users from crit-
icizing or publicly commenting on software they purchased. Most
software that makes use of one or more of the provisions of UCITA
requires the installer to accept the conditions before the software can
be installed.
For software other than shrink-wrap licences, such as that used for serv-
ers and larger computers, system management utilities, databases, enter-
prise resource planning systems and other applications, their vendors re-
quire the acceptance of their standard conditions of contract.
Such standard conditions describe the type of license that applies to a par-
ticular product in at least two distinct categories of definitions:
• One dealing with the type of licensing arrangement – for example a
perpetual license, a periodic license (for N years) and whether it is
exclusive – the licensee owns the intellectual property if the software
or any particular features were developed at the initiative of the buy-
er – or non-exclusive, which means that the software may be made
available to other interested parties.
• The second set of definitions describe the rights of use of the soft-
ware. In the case of large systems software such rights may be limit-
ed to a specific machine – the price of the license may differ for dif-
ferent size processors – at a particular location, and it may include
clauses giving the vendor the right to conduct an audit for compli-
ance with these conditions. All such contracts include a multitude of
disclaimers and waivers of the vendor’s liability.
Well drafted software contracts make provision for changes to such rights
of use and the charges involved in doing so. One instance where such
changes may be needed is when computer centre operations are out-
sourced and this involves the relocation and resizing of the computer(s)
involved.
In practice, “standard” contracts are negotiable. To succeed, this requires
the involvement of the procurement and legal departments (if necessary
with additional support from a lawyer specialising in software contracts)
and consulting ICT industry advisory services.
The contractual and legal issues of custom software developed by a third
party are discussed in the next section.
Services contracts
Outsourced and third party services
The issues relating to outsourcing contracts for operational services are

discussed in Chapter 12. It should be fairly obvious that outsourcing con-
tracts are complex because of the risks associated with being committed
to an unsatisfactory arrangement covering activities critical to an organ-
isation.
Such a contract may in practice consist of several contracts and invari-
ably includes Service Level Agreements (SLA). These define the terms un-
der which a vendor will provide a service. As the main purpose of an SLA
is to protect the technology services that are important to an organisa-
tion, the vendor must be held responsible for delivering services to the re-
quired level of quality or better.
A good SLA is best prepared by a team consisting of business unit man-
agers, legal advisors and information technologists.
For the outsourcing of existing processes, the client should be able to de-
fine current service levels in the appropriate metrics, and notify the se-
lected vendor, who would normally require time to validate and verify
these.
Performance measurement criteria for processes usually include:
• service availability and how it is defined
• response time and where it is measured
• definition of maintenance windows
• problem resolution targets
Such Service Level Agreements must also be entered into with all critical
third party service providers – telecommunications links, Internet Ser-
vice with particular attention being given to the relevant penalty clauses
should the service level not be delivered.
Software development
When software intended for the exclusive use of an organisation (for ex-
ample a tailor made system or facility – like the one click button in Am-
azon or a “made-to-measure” payroll system) is operated by a third par-
ty such as an outsourcer, a consultancy organisation or contractors it is
essential to ensure that the contract for these services makes adequate
provision for each of the following matters:
Ownership of the intellectual property of the specification and of the
source code (the program as developed by the provider of the service) and
relevant documentation;
Rights and conditions of use for the service provider to reuse part or all
of the software code created for a particular client;
Quality assurance and security audit of the code (to ensure that the de-
velopers did not include facilities not specified by the client such as back
doors, logical bombs and other forms of undesired software).
When buying software developed specifically for one organisation, the
contract should include provisions for:
• Obtaining a copy of the source code (the listing of the computer pro-
gram in a language that is understandable to others);
• Exclusive ownership – a clause to prevent the vendor from selling the
same software to another client. In situations when this cannot be
agreed, the contract should define limitations on when the software
could be sold to others;
• The buyer’s right to sell the computer program and code (source and
object) to a third party, with provision to pay royalties to the devel-
oper for each copy sold;
Conversely, a professional software developer would be likely to ask that the
license be non-exclusive and that the contract includes a limit on the num-
ber of copies that the buyer can make (for example limited to backup pur-
poses) and forbid reverse engineering or disassembly (mechanisms through
which the buyer could discover how the software is constructed).
Ethical issues
Ethical matters
There is a difference between our values and ethics in the work environ-
ment. Our values, part of our culture define what we think is right, good,
fair, and just. It is not up to an employer to define what the personal val-
ues of an individual should be – these are part and parcel of the person
that joins the employer.
However, it is very much the employer’s responsibility to set behavioral

standards and also its obligation to communicate these standards to all
people working with this employer (employees, temporary staff, interns,
consultants and others). This is usually done through a Code of Conduct,
Employee’s Handbook or similarly named document and where appro-
priate, training sessions.
Ethical issues include such matters as conflict of interest, truthfulness in
reporting, non-discriminatory policies, permitted personal use of the
employer’s resources,
right to privacy in the workplace, and many more that may or may note
be legally mandated.
Non-compliance with ethical issues not covered by legislation is, at best,
antisocial behaviour. Regrettably history teaches us that human nature
does allow for antisocial behaviour (regardless of whether it is illegal or
merely unethical) and this behaviour manifests itself in very inspired acts
of creativity (from virus writers to fraudsters in all manner of operation).
An appropriate standard of conduct for individuals working in an organ-
isation that works with information would include the protection of the
privacy and confidentiality of information (legally required where data
protection legislation exists), not misrepresenting information (now made
illegal in the USA by the Sarbanes-Oxley Act of 2002, following a num-
ber of major accounting scandals), not exploiting weaknesses in systems
or misusing the information resources of an organisation.
Conversely, the organisation, through its executives also has several eth-
ical responsibilities towards its employees, temporary staff, contractors
and others who use their information systems and data. Ethical issues di-
rectly related to ICT include the four dimensions pictured here.
Chapter 4 discussed the impact of ICT on organisations and on individ-

uals. When this impact manifests itself in innovation, growth, knowledge
work and a multiplicity of opportunities, the ethical issues of enabling
creativity, providing adequate training and working conditions are an
important contributor to the success of such initiatives.
ICT implementations that lead to business process re-engineering, sig-
nificant organisational change such as downsizing, outsourcing of activ-
ities, offshoring, etc also create ethical issues in organisations and require
that these be treated not only within the law but also with due regard to
the emotional well being of those affected.
Not all countries have legislation that describes the responsibilities of em-
ployers with regards to the health and safety conditions in the workplace
in terms of office furniture, lighting, exposed cables and electrical con-
nections. When these are not regulated by law they become ethical issues
with potentially significant side-effects.
Finally, the issue of the right to privacy at work deserves to be formally
handled. What constitutes “reasonable personal use” of an employer’s ICT
resources will vary from one organisation to another, depending on the
nature of their activities. Compliance with such policies may require
matching monitoring measures. The ethical question is whether such
monitoring should be disclosed to the workforce or should be conducted
without such disclosure.
There are no simple answers to any of these issues. In the case of an in-
vestigation into improper or illegal behaviour, prior notification may be
inappropriate if evidence needs to be collected and safeguarded to be used
in a court of law. The rules of admissibility vary from one country to an-
other and should be part of the background against which such monitor-
ing practices and policies are implemented.
NB: the technology needed for the comprehensive and detailed monitor-
ing of the activities of people working in an organisation has been avail-
able for some time and has become highly sophisticated.
Many countries have legislation concerning health and safety at work and
this requires not only that the equipment should be safe to operate – no
risk of electric shocks, no wires or other obstacles that could cause a per-
son to trip or otherwise hurt themselves, suitable lighting, ergonomic fur-
niture and more of the kind.
Action points
Executives must work with their Chief Information Officer, Legal Coun-
sel and Internal auditors to ensure that the organisation is fully aware of
its legal obligations and that suitable programs of work are put in place
to ensure compliance.
Policies concerning all aspects of compliance with legislation must be de-
veloped, circulated to all relevant personnel and acted upon in terms of
implementation of appropriate measures, monitoring for compliance and
action to ensure compliance is achieved.
Monitor developments in legislation that have an impact on the need to
retain documents and databases in electronic form, as these have an im-
pact on the organisation’s disaster recovery and business continuity ar-
rangements and its overall ICT expenditures.
C h a p t e r
17
Concluding remarks
We won’t know where we are going until we get there.
18th Century British soldiers’ song

Key assumption: We already are in the early stages of an Information Society. Those who
adapt and adjust to its challenges and learn how to get the best out of their information
assets will be among the Winners. Those who don’t will join the Losers.
Here are some indicators that the Information Society is developing

• In 2004 there are an estimated 1 billion fixed telephones and a fur-
ther 1.3 billion cellular telephones, and any two such telephones can
connect to each other – this represents a very large “machine” that
actually works very well;
• Since their adoption as business tools about 25 years ago, the num-
ber of personal computers has continued to grow to the point that in
OECD countries they have become commodities, despite the predic-
tions made years ago by the leaders of the computing industry;
In 1943, Thomas Watson, then Chairman of International Business Machines (IBM)

stated that he thought that “there was a world market for five computers”
In 1977, Kenneth Olsen, Chief Executive Officer of Digital Equipment Corporation
said at the Convention of the World Future Society in Boston that “he did not see
why anyone would want to have a computer at home” and subsequently stopped
projects in his company intended to develop a personal computer.
While the total number of personal computers in use around the

world cannot be known with any accuracy, it will be greater than the
number of computers connected to the Internet. The growing popu-
lation of smart cellular telephones, digital personal assistants and
other gadgets that have e-mail and some kind of internet access ca-
pabilities should be added to this number;
• A reputable source for information on Internet use (http://www.nua.
com) publishes statistics – the latest published figures, dated Septem-
ber 2002 state that there were 605 million people with access to the
Internet. Current estimates are that this number has grown to at least
750 million. Another source (http://www.netcraft.com) indicates that
in March 2006 they had catalogued over over 70 million websites
around the world;
• By 2004, data traffic over global networks has exceeded the volume
of voice traffic;
• The business use of ICT continues to grow steadily – the global ICT
industry turns over at least a trillion US dollars a year and a single
company, IBM is close to having an annual turnover of 100 billion.
The ICT services outsourcing business is also worth over 100 billion
dollars a year;
• Electronic bank transfers are currently running at 5 trillion US dol-
lars a day;
• ICT is finding its way into areas other than the office and the home.
A car built in the year 2000 has more of these technologies than the
NASA Lunar Module of 1969, and this is growing as systems such as
Global Positioning by Satellite also become commodities;
• Online learning is growing fast, providing education and training on
an “anywhere, anytime” basis to millions of people who would oth-
erwise not have access to the education needed to operate effectively
in the Information Society;
• Many governments around the world are embracing the online soci-
ety and it is now possible to make enquiries from government depart-
ments, download forms, renew driving licences, complete tax returns
and pay taxes online through the Internet.
If is safe to assume that the Information Society being created will be
very different from past societies.
Alvin Toffler, in his series of books (Future Shock (1970), The Third Wave
(1980) and Power Shift (1990)) made a powerful case for expecting the fu-
ture to be different and challenging, particularly for those who are un-
prepared.
During the first wave of civilisation that started some 10,000 years ago
with the first towns, organized farming and the domestication of animals
– both of which led to the production of food surpluses and, indirectly,
to the invention of writing to record the ownership of these surpluses,
time was measured through the seasons and the height of the sun in the
sky, and change was slow – major discoveries and inventions were sepa-
rated by hundreds, even thousands of years. Knowledge and goods moved
with the speed of the caravans.
The second wave was triggered by the growing interest in science and
mathematics that followed the Renaissance and the Age of Enlighten-
ment, some five hundred years ago and led to the Industrial Revolution.
At this point change started to accelerate driven by the growing body of
knowledge and major shifts in the way people live (increasingly in towns
and cities) and fulfil their material needs (dual role of producers (in fac-
tories) and consumers – no longer reliant on self-sufficiency).
As technologies became mature, there were major shifts in all areas of
endeavour – sailing ships were displaced by steamships, canal barges by
railways and the physical delivery of information by the electric telegraph
(around 1860), the transoceanic liner by the airlines and more. Each of
these shifts resulted in Winners and Losers.
The telegraph is a major landmark of the Information Age as it enabled
information to move faster than the fastest means of transport and pro-
vided the instantaneous transmission of beyond the line of sight.
While ICT has a long history: a mechanical programmable computer had
been developed in 1833 by Charles Babbage – and Lady Ada Byron, Count-
ess of Lovelace became the first programmer by working on this “Ana-
lytical Engine”. Punched cards, tabulators and other electromechanical
sorting machines go back to the 19th Century and the first electronic pro-
grammable computer (ENIAC) was used in 1943.
The last sixty years of information and communications technologies
have produced changes that exceed the expectations of most people work-
ing in this industry.
The challenges of making good use of information and the technologies
that enable us to exploit it remain many and complex as it seems that the
one thing that is constant in the Information Age is rapid change.
The inability to adapt and capitalise on this change will divide organisa-
tions into Winners, Losers and those that stay outside the Information
Age. This will create a new digital divide distinguishing those who can-
not from those who will not.
Mark Twain said that “the man who does not read good books has no advantage over the
man who cannot”. This statement holds true when extended to the “literacy” needed to
exploit the tools of the Information Age.
The Winners will be those who learn how to create and extract value from
the opportunities provided by innovative information technologies. In-
formation is there – in fact today we have access to so much of it that we
don’t really know how to come to terms with it.
What can be expected over the next few years – and what opportunities
does this open to those aspiring to be Winners?
Electronics and various forms of ICT will find their way into an increas-
ing number of devices and activities. Enormous amounts of research are
taking place in the ICT industry and in academic circles on new materi-
als for ICT, on new concepts (for example quantum and microbiological
computing) and on new applications and uses for ICT.
Three things we can expect with reasonable confidence are:
• The further development of electronic commerce in all its forms,
Business to consumer (B2C), Business to Business (B2B), Business to
Government (B2G), Consumer to Consumer (C2C), as well as the
growth of tailor made products for individual customers as it is al-
ready possible to order and purchase made-to-measure clothing over
the Internet as well as to create custom music compilations that are
downloaded or burnt into a custom CD.
• “Deep computing” to bring about the computing power to make sense
of all the data. Progress has been made in creating supercomputers
with a power never before achieved (the GRID project) and using this
power to solve highly complex problems, such as weather forecast-
ing. In future, it is likely that such deep computing will be used to
analyse, aggregate and explore other massive databases – for exam-
ple how much information does a government hold about its popula-
tion? Tax records, driving licences and car ownership, property own-
ership, health records, criminal records and so much more. Current-
ly these are in separate databases, often incompatible, but “big broth-
er” may well be coming thanks to ICT developments.
• Quality content for sale. The growing popularity of the World Wide
Web in the mid 1990s created a thinking model that information is
and should be free. While nobody denies the wonderful freedom of
speech which exists on the Internet, information providers – publish-
ers, news agencies, researchers, artists and many others are seeing
their copyright and intellectual property being appropriated and
misused without recompense. When a simple mechanism for collect-
ing money in small amounts (smaller than credit card companies are
prepared to accept) become established, it is likely that more and
more of the quality content available on the Internet and its World
Wide Web will no longer be free.
What are the barriers to becoming a winner?
The two main barriers are a lack of awareness that:

• Continuous creative thinking and ongoing learning will become es-
sential for both individuals and organisations;
• Rapid change will be an inevitable outcome of such thinking and
learning being applied in the work environment, with destabilisation
and discontinuity as side-effects.
Besides, many people are held back from creative thinking and ongoing
learning by factors such as:
• The thinking skills currently fostered and developed by educational
establishments – more focused on analysis than on systems think-
ing and on creativity;
• An inability to ask “the right questions” when confronted with mass-
es of information, thus not being able of seeing or hearing weak sig-
nals in the overall noise;
• An inability to use anything other than a very small amount of in-
formation at a time;
• A mental model of the world which contains many assumptions that
may no longer be valid.
Success in the Information Age will need a higher level of creativity, lead-
ership and courage than today’s environment. It also needs a close work-
ing relationship between those who understand business opportunities
and those who have knowledge of technology and its capabilities.
To get there, many things need to change. Many organisations are still
struggling with questions on how and where to invest in technology, with
a general inability to determine the value of information, knowledge and
the contribution that ICT makes to business results.
The relative complexity of technology operations can demand 80 to 90%
of a Chief Information Officer’s time to maintain a focus on service de-
livery. This inhibits the CIO’s ability to participate fully in working with
business units and departments to unlock the opportunities that tech-
nology can enable.
This is not helped by those executives who regard ICT primarily as a util-
ity and are unfamiliar with its nature and requirements and who end up
delegating (abdicating) responsibility for ICT to the technical communi-
ty who may or may not be sufficiently familiar with the business objec-
tives to make a valuable contribution.
It is essential to narrow the gap (another digital divide) between technol-

ogists and executives to bring the management of ICT to the same level
of visibility and comprehension as financial and human resource man-
agement. If this book has succeeded in dispelling some of the mysteries
of ICT, its purpose has been fulfilled.
When you go into the future, take plenty of money with you
Appendix
1
Key questions
A listing of all the questions raised at
the beginning of each chapter
The only stupid question is the one

that doesn’t get asked
Key questions
This appendix lists all the key questions at the beginning of each chapter.
Chapter 1: Setting the scene
• Why should an executive be interested in this kind of “tekkie” thing

– information technologies are the job of the Chief Information Of-
ficer… aren’t they?
• Is there really an “executive digital divide” and if so, what is it
about?
Chapter 2: How well are we doing with ICT?
• What is the track record of the ICT function?

• What are the efficiency and effectiveness of the organisation’s ICT?
• What is the value assigned to information, knowledge work and
ICT?
• Where does the money spent on ICT go?
• What are the legacies and constraints on ICT in the organisation?
• Do we have a well articulated vision of how we should exploit ICT?
• What tools and methodologies can an executive use to find out an-
swers to these questions?
Chapter 3: Technology and information or information and technology?
• What are the differences between data, information and knowl-

edge?
• Transaction and knowledge workers what exactly do they do and why
does it matter?
• How do businesses and organisations use information and knowl-
edge?
• Why is information quality important and what determines quali-
ty?
• What is the appropriate role for technology in “Information Technol-
ogy” and what does it take to be able to exploit it?
• Asset management for information systems and technology: does it
make sense?
Chapter 4: Impact of ICT on organisations and on people
• What have we learned about the impact of ICT in the “real world”?
• Should ICT investments make a difference, and if so, how much?
• How do organisations and people react when confronted with dis-
ruptive change?
• What are the challenges facing the non-ICT executive?
Chapter 5: Financial aspects of ICT: costs
• Why does ICT cost so much?

• What drives the cost of ICT?
• How does an organisation know the total cost of its ICT?
• Can the cost of ICT be contained?
• Is outsourcing expensive?
Chapter 6: Financial aspects of ICT: benefits
• Why is it so hard to define the benefits of investing in ICT?

• How can benefits be identified and quantified?
• Are there any formal techniques for evaluating benefits?
Chapter 7: Workable ICT strategies
• What is the purpose of an ICT strategy, and is it important to have

one?
• What is needed for a strategy to be implemented successfully and
support business results?
• What should an ICT strategy contain?
Chapter 8: ICT service delivery processes: resources, quality and risk
• Are ICT processes different from other processes?

• What are the typical processes that support ICT activities?
• Is process management an art or a science?
• What are the risks associated with ICT service delivery processes
Chapter 9: Managing ICT projects for success, quality and reduced risk
• What exactly is a project?

• What is the impact of quality requirements on projects?
• Can projects be divided into distinct stages?
• Why do projects – particularly ICT projects - go wrong?
• Is project management an art or a science?
• What can an executive do to reduce the risks inherent in ICT proj-
ects?
Chapter 10: Understanding and managing ICT risks
• What exactly is risk and what are the factors that determine it?
• What is the scope of risks associated with ICT?
• Why should an executive be concerned with ICT-related risk man-
agement?
• What are the steps needed to manage risk?
Chapter 11: Information insecurity: external risks
• What makes information security a hot topic that requires executive

attention?
• What are the specific non-technical issues of information security?
• Can information security be outsourced?
• Is your organisation adequately prepared to deal with abuse and
crime through ICT?
Chapter 12: Information insecurity: the insider threat
• Which abusive, fraudulent and criminal activities that could affect

an organisation would be easier to commit from the inside?
• How difficult is it to acquire the knowledge needed to perform fraudu-
lent and criminal activities using information systems and technology?
• Who is an insider in a modern corporation and what could motivate
an insider to act in a fraudulent or criminal manner?
• What steps can an organisation take to protect itself from such
acts?
• What are the problems and limitations that such protection needs to
address?
Chapter 13: Contingency planning
• What can cause an organisation to have an ICT disaster?

• What are the steps needed to reduce the impact of such a disaster?
• What are the options to consider?
• How much will this cost?
• What are the most likely problems to be encountered?
Chapter 14: ICT organisations and ICT people
• What do ICT organisations do (or are supposed to)?

• What lends itself to centralisation and to outsourcing?
• What are the roles and responsibilities of a Chief Information Offi-
cer – are there different kinds of CIO?
• Where should the ICT function fit in the organisation?
• How does one measure the performance of the ICT function?
• Are ICT people really “different” from other employees?
• What factors prevent CIOs from succeeding in their job?
• What are the questions that executives should ask of their CIOs?
Chapter 15: Outsourcing
• What activities lend themselves to outsourcing?

• What are the benefits, disbenefits and risks of outsourcing?
• What is needed to be successful in outsourcing?
• What are the steps involved in doing an outsourcing deal?
Chapter 16: Legal and ethical aspects of ITC
• What is so different about ICT legislation?

• What is covered by legislation directly related to ICT?
• Are ICT contracts really that different from other contracts?
• How do I know my organisation is not breaking the law?
• Ethical issues in the workplace – what exactly is this all about?
Chapter 17: Concluding remarks
• What distinguishes winners from losers of the ICT Board game?

Appendix
2
Action points
A listing of all the action points given at
the end of each chapter
A vision without action is only a daydream.

Action without a vision is a nightmare.
Japanese proverb
Action points
This appendix presents a complete list of all the action points given at the
end of each chapter.
Chapter 1: Setting the scene
An old proverb states that “When there is a will there is a way”. This is
particularly true for ICT and bridging, or at least narrowing, the Execu-
tive Digital Divide is one step that should help.
Executives who take a serious interest in ICT and see it as a strategic tool
and are also prepared to lead the organisational change that follows such
implementations will be better equipped to gain value out of the signifi-
cant investments involved than those who don’t.
Taking a greater interest is necessary but not sufficient. The executive
also needs a good awareness of what ICT can deliver and what it cannot
yet do, understand the issues that need to be addressed, be good at risk
management and not least, ensure that the right people are engaged to
deliver results that make a difference.
Chapter 2: How well are we doing with ICT?
If your organisation’s ICT performance, business impact and value for mon-
ey seem fine: Congratulations! You are among the Winners of the ICT Board
game (not a crowded place). The challenge now is to remain at this level.
If there appear to be doubts, concerns or problems about performance,
costs or in difficulties in assessing the value added by ICT: Things will
not get better by themselves – the reverse is more likely. In these circum-
stances, executive action is necessary to diagnose the true nature and ex-
tent of the problems in order to take appropriate corrective action.
When a SWOT analysis is insufficient and the financial data on costs and
benefits is inconclusive, incomplete or incomprehensible, it is recom-
mended to carry out a series of audits of the ICT function, specifically:
• A technical audit if there are performance problems and/or
• A financial audit if the true costs of ICT are unclear and/or
• A board level review of the benefits delivered by ICT in the last few
years, and, if these are unclear or undefined, the development of a
new strategy to change the situation.
and, in parallel, conduct an assessment of skill gaps for the people who
use the computer systems and ICT facilities of the organisation – part of
the problem could be their inability to exploit the tools put at their dis-
posal due to lack of training or other essential ICT skills.
Other audits that may prove necessary if the outcome of the previous au-
dits gives cause for concern may include:
• Compliance with national legislation relating to ICT (data protection,
privacy, cybercrime, health and safety at work, etc)
• Compliance with policies relating to the use, misuse and abuse of
ICT
• Information security audit
Chapter 3: Technology and information or information and technology?
Recognise that data, information and software defining your organisa-

tion’s business rules and processes are valuable assets.
Prevent your organisation from drifting into information anarchy by en-
suring all information assets have an identified custodian or “owner” and
that a minimum set of standards is implemented and adhered to.
Ensure that the organisation knows what it has and what it knows.
Ensure that the workforce has the necessary capacities and skills to ex-
ploit the information assets with which they work.
Chapter 4: Impact of ICT on organisations and on people
Ensure that the purpose of investing in ICT is clear and communicated

to all those who will be impacted by the changes resulting from this in-
vestment.
The factors that will unlock the benefits of investing in ICT require exec-
utive action – these are always beyond the reach of ICT managers.
Chapter 5: Financial aspects of ICT: costs
Find out if there are indications that your organisation is spending more
than it needs to on ICT – despite cries from the ICT function that they
are “not spending enough”.
Find out if the expenditures incurred on ICT are well aligned with the
business objectives of the organisation – what’s the value of a World Class
infrastructure if the computer systems are inadequate to support busi-
ness activities or management decisions?
Chapter 6: Financial aspects of ICT: benefits
Do not accept “intangible benefits” as an excuse for not developing a busi-

ness case for investments in ICT.
Similarly, do not accept statements such as:
• This project is aligned with our business objectives - without being
specific of how this alignment consists of;
• This is a long term investment – which means that there will be no
significant impact in the forseeable future and that by then the exec-
utives would have forgotten who the project champion was…;
• This project is part of corporate activity consolidation or equivalent
consultant-speak which actually does not mean significant;
• This project will lead to optimum resource performance which could
mean that we shall know what we get out of this investment after we
have completed it.
Recognise that there are no benefits without risk and that their specula-
tive nature requires an act of faith on the part of the executive. Validate
these acts of faith by conducting post-implementation benefit audits.
Be suspicious of proposals that do not put boundaries (worst case, best
case, most likely outcome) on benefits. They may imply that the uncer-
tainty is too high or that the sponsor has not thought enough about the
business case.
Chapter 7: Workable ICT strategies
Ensure that the business objectives of your organisation are known and
understood by those responsible for ICT strategy.
Strengthen ICT governance mechanisms to enable ICT to deliver the ap-
propriate quality of projects and services with acceptable track record and
costs.
Focus the work of the ICT governance body on alignment and value is-
sues.
Demand that ICT strategies be regularly updated and that they reflect the
input of all constitutent parts of the organisation.
Chapter 8: ICT service delivery processes: resources, quality and risk
If your in-house ICT organisation does not use (or comply with) ISO 9001,
the Information Technology Infrastructure Library, COBIT, or equiva-
lent guidelines, ask why this is the case – is it likely that your ICT people
can do better without such established best practices than with them?
If your ICT service provider, in-house or outsourced, is certified to com-
ply with ISO 9001 and is regularly audited, you are doing well.
If not ISO 9001 certified, but the performance of your systems, networks,
help desk and contingency planning is generally considered as accept-
able, you are doing well and may wish to consider conducting a process
level assessment based on the COBIT guidelines.
If neither of the above two situations apply, it would be appropriate for
you to take action, starting with an in-depth diagnostic (Chapter 2) fol-
lowed by an action plan to avoid unpleasant surprises in the future.
Chapter 9: Managing ICT projects for success, quality and reduced risk
Nobody wishes to be associated with a failed project, particularly one in-

volving large sums of money and risk to their organisation. What can ex-
ecutives do to manage and contain risk to avoid the pain and embarrass-
ment of a failed project?
A good approach is to think of a project as if it was a patient in an inten-
sive care - continuous monitoring of vital signs is required to increase the
chances of survival.
This requires a consolidated view of the project through its lifecycle by
all the parties concerned – the sponsor, senior management, project
teams, end users and others. Consistency, good communications, even
when it is a matter of conveying bad news make a big difference.
Here are a few approaches known to work well. These may well help both
before and during the project implementation:
9. Avoid overambitious or unrealistic project goals and objectives and

remember there is always a choice to be made between Quick, Qual-
ity and Cheap;
10. Resource the project sensibly, starting with the right kind of project
manager, project team and other parties involved. The “right kind”
must be, as a very minimum competent, experienced and empow-
ered);
11. Ensure that formal project management methodologies are used and
that all changes to the project are documented as it goes forward;
12. Make certain that the project sponsor and other executives are in-
volved and informed on the evolution of the project;
13. Help the project manager keep a tight control on changes in require-
ments and discourage frequent changes altogether;
14. Recognise that project delays and cost overruns are likely and help
the project team to keep both of these to a minimum;
15. Ensure that, if your organisational culture allows for it, risk manage-
ment is applied to all projects. If your organisation does not believe
in the value of risk management or it is contrary to its culture and
behaviour, you will have to rely on luck.
16. When things go wrong with a project, blamestorming is unhelpful.
Executives should be sensitive to warning signs and take appropriate
action before it is too late even if such action may cause distress if it
involves replacing one or more members of the project team or even
the project manager.
Chapter 10: Understanding and managing ICT risks
Brainstorm potential risks to identify them, assess them and take appro-
priate actions.
If risk has not been well managed, consider applying the benevolent rule
that “Once is a mistake. Twice is a coincidence. Thrice is either careless-
ness or incompetence”, then act accordingly. Clearly there will be situa-
tions where a mistake should be dealt with before a “coincidence” oc-
curs.
Recognise that there is a real risk of loss of business and money as a re-
sult of shortcomings in information systems and the internal controls
built into them.
Chapter 11: Information insecurity: external risks
The successful management of information security requires components

that only executives can put in place: policies, monitoring and compli-
ance. The ICT function will be handicapped if these are not in place or
are not effective and will be unable to protect the organisation’s informa-
tion assets.
Information security should be everybody’s concern and executives
should ensure there is adequate awareness of these issues across the or-
ganisation as a whole.
Insider threats are real and serious. Dealing with this threat requires
more than the technical measures put in place to prevent virus infections,
and the capabilities to detect, investigate and prosecute offenders do not
belong in the ICT function.
Chapter 12: Information insecurity: the insider threat
Executives should ensure that there are clear and well disseminated pol-
icies, supported by consistent organisational behaviour with regards to
all forms of cybercrime. This behaviour should extend from formulation
of deterrence policies to sanctions and redress.
Those responsible for information security should be required to learn
how “bad guys” think and operate and incorporate appropriate defences
against external and internal threats.
Cybercrimes committed by an expert will be essentially undetectable.
The role of tests, audits and security certification must be seriously con-
sidered if the organisation’s information assets are valuable.
Chapter 13: Contingency planning
Appoint a person to be in charge of contingency planning – a typical ti-

tle is Emergency Coordinator – and ensure that this person has adequate
backup, after all, an emergency necessitating immediate response may
arise while the Emergency Coordinator is on holiday…;
Actively participate in the process of Business Impact Analysis and also
in the decisions that define recovery priorities and the speed with which
recovery is to be achieved;
Monitor the results of the tests of contingency plans and ensure that the
lessons learned during these tests are discussed and reflected in the
plans;
Make available the financial and human resources needed to make con-
tingency planning workable and sustainable. This is often a major issue
for organisations;
Recognise the importance of communications during an emergency –
with the workforce, with their relatives and close ones, with vendors, cli-
ents, the media, etc., and act accordingly to ensure that poor communi-
cations do not lead to a loss of image and reputation
Chapter 14: ICT organisations and ICT people
Be aware of the nature of your organisation before selecting and appoint-

ing a CIO. A poor choice may have consequences that will last years.
Establish a regular dialog with the CIO – the supplement to this Chapter
contains 12 questions that should be asked of CIOs. Some of the questions
may not be well received but are critical to the successful deployment of
ICT in an organisation.
Chapter 15: Outsourcing
Be clear about the objectives for seeking an outsourcing option. The over-
all track record of ICT outsourcing is pretty good and reducing costs is
not the only reason for pursuing this path.
Remember that the people carrying out activities suitable for outsourc-
ing have a vital interest in preventing this from happening and that their
views are likely to be biased.
Chapter 16: Legal and ethical aspects of ICT
Executives must work with their Chief Information Officer, Legal Coun-
sel and Internal auditors to ensure that the organisation is fully aware of
its legal obligations and that suitable programs of work are put in place
to ensure compliance.
Policies concerning all aspects of compliance with legislation must be de-
veloped, circulated to all relevant personnel and acted upon in terms of
implementation of appropriate measures, monitoring for compliance and

action to ensure compliance is achieved.
Monitor developments in legislation that have an impact on the need to
retain documents and databases in electronic form, as these have an im-
pact on the organisation’s disaster recovery and business continuity ar-
rangements and its overall ICT expenditures.
Chapter 17: Concluding remarks
When you go to the future, take plenty of money with you.

Appendix
3
A short contradictionary of ICT
frequently used terms
You should have printed what he meant, not what he said

Earl Bush, press aide to Major Daley of Chicago
A short contradictionary of definitions and

terminology related to the governance of ICT
First letters of the German expression “Alles Ganz

Anders Bei Uns”, which roughly translates as “We
AGABU
do everything differently here”. A significant cost
and risk driver when applied to ICT.
The process through which investments in ICT are
Alignment
made in those areas that deliver business value.
An independent assessment of compliance with
policies, standards, proven practices and/or an in-
Audit
dependent assessment of an organisation’s expo-
sures to risk.
Objective, often independent, mechanism for com-
paring the performance of an activity with infor-
Benchmarking
mation about equivalent activities carried out else-
where.
First letters of Critical Success Factors – these are
CSF the actions that need to be achieved in order to al-
low an event (or a strategy) to be delivered.
Also referred to as Residual Risk, the probability
that an undesired situation could arise as a result
Exposure
of the combination of threats, vulnerabilities and
countermeasures taken to protect against them.
The process through which those who decide poli-
Governance
cy guide those who implement policy.
First letters of the expression “I’ll Know It When I
IKIWISI See It” and an approach to strategic thinking that
cannot be recommended.
First letters of the expression “Mindeless Pursuit of
Perfection” – the opposite of Pareto’s principle of
MPP
80/20. When applied to ICT projects guaranteed to
cause significant delays and cost increases.
Having work done in a country with much lower la-
Offshoring bour costs. Much used in the development and
maintenance of software.
Contractual relationship with a company for the

Outsourcing provision of services. These can be limited to ICT
operations or involve entire business processes.
Documents that describe guidelines for an organi-
sation. Ranging from a Code of Conduct to techni-
Policies cal matters such as information security, they
should include a statement of the actions that will
be taken if the policies are not complied with.
The process through which power is acquired in an
Politics
organisation.
What it takes to change the status-quo in an organ-
Power isation. It is misued and abused when it’s only used
to stop initiatives.
Risk The probabilty of an undersired situation arising.
Persons who lure the unaware to part with their
Scammer money by making promises of instant wealth (the
deals are always too good to be true)
Persons whose business is to send large amounts of
Spammer
unsolicited (junk) e-mail.
First letters of the expression “Saving Money Re-
gardless of Cost”, a game indulged by the unin-
SMRC
formed ro cut budgets without fully understanding
the consequences of such actions.
Acknowledgements
The preparation of this book was greatly helped by the many people who
willingly gave their thoughts, time, candid comments and material help
at the many stages of preparation of this book. I particularly wish to
thank my friends, listed in alphabetical order:
Stefano Baldi, Italian career diplomat, currently in New York, with
whom I had the pleasure of co-authoring several publications and con-
ference papers
Keith Inight, UK Technical Directorate, Atos Origin, Nottingham, U.K.
Andreas Christoforides, Director, United Nations International Com-
puting Centre, Geneva, Switzerland
Paul Dooley, Chief Information Officer, United Nations System Joint
Staff Pension Fund, New York, U.S.A.
Jovan Kurbalija, Director of the de Diplo foundation and his teams in
Geneva and Belgrade for their assistance with graphic design, typeset-
ting and the general business of getting the book published
Guido Maccari, Head of Information Technology and Network Services,
Organization for Economic Cooperation and Development (OECD), Par-
is, France. It was his suggestion that there should be a version of the book
“Crossing the Executive Digital Divide” that was short enough for a busy
executive to read while travelling.
Dr. Elöd Polgar, Chief Executive of Critical Skills Consulting, Adjunct
Professor at Webster University, both in Geneva, Switzerland
I also with to thank the following for agreement to use copyrighted ma-
terial
Elsevier, Chapter 15, on Outsourcing, is a shortened version of the arti-
cle on outsourcing written by the author for the Academic Press Encyclo-
pedia of Information Systems, published in 2003.
MISTI (UK) – Chapter 10, on Risk Management, is largely based on a pa-
per presented at their AudIT 2005 Conference, in London, May 2005.
Gennadi Obukhov, for permission to use his graphic of the tango danc-
ers in Chapter 7, Strategies that work. More of his work can be found at
http://propro.ru/go/gallery/ html/us2000.html.
About the author
Eduardo Gelbstein has worked in the field of electronics and information

technologies since the early 1960s and worked in development, technol-
ogy assessment, project management, ICT operations and ICT strategy.
This work was done in several countries and in the private and public sec-
tors.
Between 1993 and 2002, he was the
Director of the United Nations In-
ternational Computing Centre, lo-
cated in Geneva, Switzerland, an
organisation that provides ICT ser-
vices to a large number of Interna-
tional Organisations.
Since 2002 he has been active as an
advisor to the United Nations
Board of Auditors, a Senior Fellow
of the Diplo Foundation and a Se-
nior Special Fellow of the United
Nations Institute for Training and
Research.
Ed has published many papers
over the years and is a regular
Photograph (2005) by Biljana Scott
speaker on various topics relating (www.biscott.co.uk)
to the management of ICT at inter-
national conferences.
Ed was born in Buenos Aires, Argentina and has an electronics engineer-
ing degree from Buenos Aires University and a a Ph.D. from Loughbor-
ough Univerisity, England. His other interests include the history of sci-
ence and technology, the mechanisms of thinking and creativity and
playing the piano.

Crossing Digital Divide

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Crossing Digital Divide

Uploaded by

Copyright:

Available Formats

The Information Society Library

CROSSING THE EXECUTIVE

When technology becomes master

Purpose of this book

Introduction and purpose of this book�� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �3

Don’t talk to me about computers. It’s Greek to me.

Genuine statement from a Chief Executive to his

Key questions and chapter summary

• Why should an executive be interested in this kind of “tekkie” thing

ICT is just another technical thing…

Of course there is a large technical component to “Information and com-

Facts about ICT

is projected to exceed the number of fixed telephones around the

workforce and a lack of rec-

The executive Digital Divide

The ICT Board game

Are we playing this game the wrong way?

Of course you are entitled to a

Advice supposedly given by a doctor to his patient

Key questions and chapter summary

• What is the track record of the ICT function?

Why good diagnostics make a difference

How should one determine if ICT is an organisation’s strength or a liabil-

Answering the six key questions

Seeking answers to the first six questions in the introduction is a good a

to time, some forms of intellectual property, such as trademarks, are also

time tracking systems to the 1970s. Data networks linking geographical-

Lack of a good understanding of these legacies and constraints may cre-

A typical toolkit for executives

Tool 6: The balanced scorecard for ICT

1.2 Audits (internal and external).

When should an organization conduct an I.T. audit that is not imposed by

Managing expenditures and value

I.T. performance (outsourced or not)

Value delivered by I.T. audits

verified) and includes management’s response to the recommendations

Critical Success Factors (CSFs) for I.T. audits

Choosing the right auditors

Choosing the “right” type of audit

General Controls Reviews (GCR)

definitely worth doing to reach better decisions in future if past imple-

effectively. Typical benchmarks would include the Total Cost of Owner-

Combining these four, Strengths, Weaknesses, Opportunities and Threats

workers have considerable independence and individuality and are there-

Tool N° 5: Organisational metabolic rate

Supporters of the BSC claim that it enables more rational decisions to be

Executive dilemma: The auditors’ report on ICT

practices ignoring corporate needs for the integration of data. How-

If your organisation’s ICT performance, business impact and value for

• A technical audit if there are performance problems and/or

Supplement: The 34 areas of control of COBIT V.4 of 2005

PO Planning and Organisation

AI Acquisition and implementation

DS Delivery and support

It is not what technology can do that matters.

Key questions and chapter summary

• What are the differences between data, information and knowledge?

Organisations invest in information and communications technologies because they have a

Data, information and knowledge

Technology in various forms - newspapers, reports, TV, cellular phones,

How organisations use information

The different ways of working with ICT

ICT vendors have several things in common with drug dealers:

chine), the author, Shoshana Zhuboff, introduced the concept of “infor-

Introduction and purpose of this book�� 3