Successful It Systems Printable

Successful IT systems
About this free course

This free course is an adapted extract from the Open University course TM353 IT systems: planning for
success: www.open.ac.uk/courses/modules/tm353.
This version of the content may include video, images and interactive content that may not be optimised
for your device.
You can experience this free course as it was originally designed on OpenLearn, the home of free
learning from The Open University –
www.open.edu/openlearn/science-maths-technology/computing-and-ict/successful-it-systems/content-
section-0
There you’ll also be able to track your progress via your activity record, which you can use to
demonstrate your learning.
Copyright © 2016 The Open University
Intellectual property
Unless otherwise stated, this resource is released under the terms of the Creative Commons Licence
v4.0 http://creativecommons.org/licenses/by-nc-sa/4.0/deed.en_GB. Within that The Open University
interprets this licence in the following way:
www.open.edu/openlearn/about-openlearn/frequently-asked-questions-on-openlearn. Copyright and
rights falling outside the terms of the Creative Commons Licence are retained or controlled by The Open
University. Please read the full text before using any of the content.
We believe the primary barrier to accessing high-quality educational experiences is cost, which is why
we aim to publish as much free content as possible under an open licence. If it proves difficult to release
content under our preferred Creative Commons licence (e.g. because we can’t afford or gain the
clearances or find suitable alternatives), we will still release the materials for free under a personal end-
user licence.
This is because the learning experience will always be the same high quality offering and that should
always be seen as positive – even if at times the licensing is different to Creative Commons.
When using the content you must attribute us (The Open University) (the OU) and any identified author in
accordance with the terms of the Creative Commons Licence.
The Acknowledgements section is used to list, amongst other things, third party (Proprietary), licensed
content which is not subject to Creative Commons licensing. Proprietary content must be used (retained)
intact and in context to the content at all times.
The Acknowledgements section is also used to bring to your attention any other Special Restrictions
which may apply to the content. For example there may be times when the Creative Commons Non-
Commercial Sharealike licence does not apply to any of the content even if owned by us (The Open
University). In these instances, unless stated otherwise, the content may be used for personal and non-
commercial use.
We have also identified as Proprietary other material included in the content which is not subject to
Creative Commons Licence. These are OU logos, trading names and may extend to certain
photographic and video images and sound recordings and any other material as may be brought to your
attention.
Unauthorised use of any of the content may constitute a breach of the terms and conditions and/or
intellectual property laws.
We reserve the right to alter, amend or bring to an end any terms and conditions provided here without
notice.
All rights falling outside the terms of the Creative Commons licence are retained or controlled by The
Open University.
Head of Intellectual Property, The Open University
2 of 45 Friday 7 June 2019

Contents
Introduction 4
Learning Outcomes 5
1 Success and failure in IT systems 6
1.1 A successful system 7
1.2 A failed system 8
1.3 Reflecting on success and failure 10
2 The sociotechnical nature of IT systems 12
2.1 Approaches to systems thinking 13
2.2 Components of an IT system 15
3 Understanding success in IT systems 16
3.1 What is a successful system? 18
3.2 Criteria for judging success 19
4 Stakeholders in systems success 23
4.1 Stakeholder analysis 24
4.2 Identifying stakeholder groups 25
4.3 From stakeholder identification to analysis 27
4.4 Power versus interest 29
5 Power and success in IT systems 31
5.1 Politics and rationality 32
5.2 Identifying conflict 33
5.3 Politics of stakeholder identification 35
5.4 Stakeholder legitimacy and conflict 36
5.5 Expert stakeholder power 36
5.6 Power and system success 38
Conclusion 41
Keep on learning 42
References 43
Acknowledgements 44

Introduction
Introduction
This free course, Successful IT Systems, looks at what makes an IT system successful.
Information technology (IT) systems are a critical part of our world, in business, public
sector and voluntary sector environments, and are often highly complex and
interconnected combinations of technology, organisations and people. Yet they frequently
fail, often spectacularly.
Examples of failed IT systems are everywhere. Banks are unable to release money to
their customers – because of failed IT systems. Aircrafts fall out of the sky or are routed in
wrong directions – because of failed IT systems. The UK National Health Service (NHS),
of the largest organisations in the world, was unable to change as planned – because of
failed IT systems. Many more examples, from the private, public and voluntary sectors,
may come to your mind.
But what exactly do we mean by success or failure in an IT system? This course mostly
focuses on success, and helps you understand what we mean by a successful IT system.
This OpenLearn course is an adapted extract from the Open University course
TM353 IT systems: planning for success.

Learning Outcomes
After studying this course, you should be able to:
● understand the nature of success and failure in IT systems
● understand what makes an IT system successful
● understand the sociotechnical nature of IT systems, in that they incorporate hardware, software, organisational,
social and human components
● identify different types of stakeholders and apply techniques to elicit the main interactions of stakeholders with
systems
● analyse issues of power and conflict between stakeholder groups in IT systems.
1 Success and failure in IT systems

What makes an IT system a success and what makes it a failure? We have deliberately
referred to ‘IT systems’ here rather than a narrower term such as ‘software’, for two main
reasons. First, most technologies in use in organisations are a complex mixture of
hardware, software, networks and other infrastructure (such as data centres). Secondly,
the success of such technologies depends on factors that go well beyond the purely
technical, to include, especially, human and organisational factors, but also many others.
When we talk about IT systems we mean both more than technology and – within the
technology – more than software. Hardware technology is just as important for IT success
as software technology; and human and organisational issues are just as important as
technology. This is not to denigrate the importance of software, undoubtedly one of the
most important components of any IT system. However, since it is quite common in
computing circles to equate ‘IT’ with ‘software’, we wanted to be clear up front that we’re
not taking that view in this course.
Another question which will be explored in more detail later is what is meant by success
and failure. The answer may often depend on the stakeholders from whose perspective
the success or failure is being judged: a project manager may consider a system
successful if it comes to completion on time and in budget; a software developer may
consider it successful if it contains good-quality code that runs well; an end-user may
consider it successful if it helps them do their job effectively; and so on. We will consider
stakeholders and their role in determining IT success or failure later in this course.
You will learn much more about the nature of success and failure in IT systems later in this
course. For now, we will use the following definitions:
● a successful IT system is one that meets the needs (i.e. the goals or strategy) of an
organisation within which it is used, as well as relevant needs of other key
stakeholders related to, but external from, that organisation
● a failed IT system is one that does not meet the needs of an organisation within which
it is used and/or its other key stakeholders.

Success and failure of IT systems can be seen in many different settings. They occur in
private businesses, in the public sector and in the voluntary sector. They can be found in
very large or very small systems. The smallest implementation of an IT system in a
company can be very successful or very problematic; the largest implementation can
likewise go very well or very badly. Large public-sector failures get a lot of publicity
because they are spending public money and are subject to public audit; but private-
sector failures are perhaps equally common, even though they are not widely discussed.
If a private sector project is a success, it is widely written about in the computing press; if it
is a failure it is often forgotten.
You will now look at two short case studies: one of a successful and one of a failed IT
system. The successful project is from the private sector and the failed project is from the
public sector, but it could have equally been the other way around. After you read the
following case studies, you will be asked to reflect on what makes them a success or
failure, and then to look for examples of your own.
1.1 A successful system

We will now look at an example of an IT system that was successful.
Box 1: A successful IT system – pub chain Mitchells & Butlers’

top-to-toe IT overhaul
Graeme Burton
Running a pub is a challenging business, with perishable goods to store and sell, staff to
roster to make the most of the British summer (if it turns up) and, most important of all,
treasured customers to serve in a timely and friendly fashion. Running a pub chain,
therefore, must be an order of magnitude more challenging.
So the challenge of efficiently running the IT behind Mitchells & Butlers (M&B), one of the
UK’s largest pub companies with more than 17 different ‘brands’ – as well as one in
Germany – must be off the scale.
Partly as a result of having grown by acquisition on the one hand, while divesting itself of
non-core businesses on the other, M&B had a sprawling IT estate and, in some instances,
inadequate bandwidth into a number of sites.
‘We had a lot of legacy technology and therefore planned to go through this “advancement
of technology” process,’ says Martin Taylor, director of business change and information
technology at Mitchells & Butlers.
That is why, three years ago, the company decided to embark on a five-year, top-to-bottom
IT infrastructure refresh, taking in its data centre, its systems and network topology, the
systems it runs at its headquarters and regional offices, retail systems, the level of
bandwidth into individual outlets – the whole lot.
At the heart of M&B’s new IT infrastructure is a private-cloud-based architecture hosted by
technology partner Fujitsu, which took over from IBM as M&B’s primary technology partner
in 2011, just pipping Vodafone-owned Cable & Wireless to the contract.
In the process, IT at head office was almost entirely virtualised, while a new operational
data store (ODS), based on Oracle, was installed to take trading data from outlets on a just-
in-time basis, radically improving executive access to operational data. Everything

connects via the ODS and now head office can see how individual units are trading on an
almost minute-by-minute basis.
The project is a radical departure on the old system, whereby much of the company’s core
IT was hosted on either IBM e Server p Series (RS/6000) AIX Unix-based systems, or
System I (AS/400) mid-range servers, largely hosted in an IBM data centre. At head office,
the computer room buzzed with some 20 different servers to handle email, file and print,
and some key business applications.
In most cases, existing applications – such as the all-important labour scheduling and
supply chain management applications – could be virtualised and were ported to the new
architecture. Where applications couldn’t be virtualised, this was normally due to their age
and, therefore, a good excuse to ditch them and migrate to all-new applications.
The initial tender process was worked out with a consultancy called EquaTerra, which is
now part of KPMG.
‘We asked ourselves what we wanted to achieve,’ says Taylor. ‘What’s the output we want
to get to? Then, we worked with EquaTerra on how we would perform the benchmarks,
because the issue with benchmarking is that everyone calibrates it in some sort of way.
‘So we said, if we look at the outcome in mind, why don’t we benchmark about how those
outcomes have been achieved using EquaTerra’s databases of contracts won and
tendered for? That gave us a good feel for what could be achieved and the size of the prize
– what it would cost us to do and the likely running costs.’
Once an IT partner had been tendered for and identified, a solid plan for the migration
needed to be worked out.
‘We took all the elements of our IT and categorised it into six key areas,’ says Taylor. ‘That
meant the data centre, network, outlets, end-user computing, central services and
applications. Then we looked at the outputs that we wanted from each of those areas, the
cost base and the areas where we wanted to get our innovation from.’
Initially, the data centre and the network were prioritised as they provided the platform that
supported the rest of the business – the applications running in the data centre, while the
network supports the outlets, which in a modern hospitality business also require 24/7
logistic and IT support.
Infrastructure renewal was not the only consideration. M&B was also keen to consolidate
applications and, as far as possible, to share applications across its business units as far as
possible.
‘Our finance system, human resources, payroll and property management systems are
common throughout the organisation,’ says Taylor.
‘It doesn’t matter whether it is a Toby, Harvester or an All Bar One, we get the synergies of
having one application and streamlining our processes so that they are common
throughout. Occasionally, we will have to use something slightly different for the odd brand,
but in the majority of cases, everything is consistent.’
(Burton, 2013)
1.2 A failed system

We will move on to look at an example of what is widely viewed as a failed IT system.

Box 2: A failed IT system – the BBC Digital Media Initiative

Tara Conlan and Charles Arthur
The BBC has suspended its chief technology officer and admitted wasting nearly £100m on
a five-year project intended to make the corporation ‘tapeless’, saying that to continue with
the project would be ‘throwing good money after bad’.
The Digital Media Initiative (DMI) was supposed to create a production system linked to the
BBC’s huge broadcasting archive, but flaws in the system peaked in April when instead of
streamlining access to old video footage, it caused chaos following Margaret Thatcher’s
death.
Video editors were unable to access archive footage to use in news reports via computers
in New Broadcasting House in central London. Instead they were forced to ferry tapes there
by taxi and tube from the archive storage facility in Perivale, north-west London.
In an email to all BBC staff on Friday, director-general Tony Hall said he was halting DMI
and admitted: ‘We have a responsibility to spend licence-fee payers’ money as if it was our
own and I’m sorry to say we did not do that here.’
One insider called the DMI project ‘the axis of awful’, while another source said: ‘The scale
of the project was too big and it got out of hand.’
John Linwood, the BBC’s chief technology officer who was responsible for the running of
the project, has temporarily been replaced by BBC News head of technology Peter Coles.
Linwood was appointed in 2009 from Yahoo and had formerly worked at Microsoft. He
receives a £287,000 salary and was one of four of the organisation’s top managers to
receive a bonus last year – in his case amounting to £70,000.
BBC Trust member Anthony Fry said the project had ‘generated little or no assets’ for the
corporation. In a letter to Margaret Hodge MP, who chairs the public accounts committee,
which investigated the project, he said: ‘This is because much of the software and hardware
which has been developed could only be used by the BBC if the project were completed, a
course of action which, due to technological difficulties and changes to business needs,
would be, I fear, equivalent to throwing good money after bad.’
DMI has cost £98.4m, and was meant to bring £95.4m of benefits to the organisation by
making all the corporation’s raw and edited video footage available to staff for re-editing
and output. In 2007, when the project was conceived, making a single TV programme could
require 70 individual video-handling processes; DMI was meant to halve that.
An independent review by PricewaterhouseCoopers will investigate what went wrong in the
project management, control and governance. Some problems were significant: after just
24 months, the project was 21 months behind schedule.
Hall said off-the-shelf tools were now available that could do the same job ‘that simply didn’t
exist five years ago’, and that all the assets from the project are being written off. The BBC
declined to specify which editing tools Hall was referring to. Avid’s Pro Tools and Apple’s
Final Cut Pro software are popular with other professional sound and video editors, but both
have been available for more than a decade.
Only DMI’s ‘Fabric archive database’, first rolled out in 2012 to help staff search and
request access to tapes and other media, will be retained – although even that is
understood also to have been criticised by users as slower than existing libraries with tape
copies, and was the system that failed calamitously after Thatcher’s death.

Rob Wilson, the Conservative MP for Reading East, said: ‘The BBC spent well over £100m
experimenting with a system that it appears was highly unlikely to work. It is a disaster for
the BBC but a bigger disaster for the licence fee payer.’
The BBC initially awarded a £79m contract to Siemens in February 2008 without open
competition, a Public Accounts Select Committee report noted in April 2011, but no
technology was delivered and it was terminated in July 2009. The BBC then brought the
project in-house, clawing back £27.5m from Siemens – but was still unable to bring costs
under control, and did not deliver the software required.
The PAC in 2011 noted that instead of saving £17.9m, the DMI had cost it a net £38.2m. It
expected that the DMI would be delivered by summer – but that deadline slipped, and the
forecast benefits slipped to an overall cost to the corporation.
(Conlan and Arthur, 2013)
1.3 Reflecting on success and failure

We would now like you to work through a pair of activities to reflect on the two case
studies you have just seen, and to relate them to other examples of success and failure in
IT systems that you know from elsewhere.
Activity 1
30 minutes
Apart from one being public sector and one being private sector, what do you think are
the three main differences between these two case studies? Make notes (around half
a page in each case) on what you think made the first system a success and the
second one a failure.
Discussion
In our view (and throughout these answers we recognise that your view may be
different and just as valid), the three main differences between the case studies are as
follows:
● A clear plan was followed for Mitchells & Butlers’ system (M&B), whereas the
BBC Digital Media Initiative (DMI) appears to have changed its nature over time.
● Although both were ambitious and large-scale projects, the M&B system was
appropriate in its scale, whereas the DMI was over-ambitious.
● The M&B system was completed to plan and successfully rolled-out; the DMI was
left incomplete.
Mitchells & Butlers’ IT overhaul feels like a successful system. It is designed to draw
upon existing systems, but to work with modern technology − there is much use of
virtualisation and the cloud. It is standardised across different sites, although with
appropriate local changes if necessary. A clear plan was identified and followed, and
benchmarking with comparable organisations used to get a feel for the success of the
plan. It has to be said that most of the discussion is from the central management
perspective, and that other stakeholders within the organisation might see the success
or otherwise somewhat differently.

By contrast, the BBC Digital Media Initiative feels like a failing system. It is described
very negatively throughout the report. It was over-ambitious in terms of its scale,
significantly behind schedule and ended up being largely incomplete. A few aspects of
it were completed (notably the ‘Fabric archive database’) but most of the project
remained incomplete, which as it was conceived as an integrated whole, meant that it
was largely unusable. At the time of the report given here, reasons for the failure were
still to be investigated.
Activity 2
1 hour
a. Having read the two short case studies of success and failure, search online for
two short case studies of your own, one of a successful IT system and the other of
a failing IT system.
b. For each of your case studies, write a sentence explaining why you regard it as a
success or a failure.
Discussion
We hope you enjoyed finding these case studies. There are many rich case studies
available online, although it can sometimes be challenging to separate genuine
descriptions of an IT success story from what is basically a marketing piece by a
vendor or consultancy. Failures are easier to spot in this regard!

2 The sociotechnical nature of IT systems

The word ‘system’ means many different things in different contexts. In a computing and
IT context, it’s often taken to mean a computer system. The basic argument of this course,
as exemplified in the case studies above, is that an IT system consists of much more than
software, hardware or other technologies – it is a mixture of technology, people and
organisation.
There are many other uses of the term ‘system’ outside of computing and IT – we talk of
the financial system, the political system, the health system and ecological systems.
These may seem like quite disconnected areas, but they all share a common idea – that
there is some unified concept, some broad way of understanding parts of the world that
are all connected to each other. The discipline of systems thinking, on which many of the
ideas in the course rest, is concerned with understanding systems and their nature.
A short definition of a system, within the tradition of systems thinking that has long been
used at the Open University, is ‘a set of components interconnected for a purpose’.
This is one of those definitions where almost every word has significance! The basic
definition is usually expanded upon in the following way:
1. A system is an assembly of components connected together in an organised way.

2. The components are affected by being in the system and are changed if they leave it.
3. The assembly does something – carries out a task, fulfils a function.
4. The assembly as a whole has been identified by some observer who is interested
in it.
The last of these points is especially important. Although the loose use of phrases such as
the financial system and the health system (and even IT systems) might sound as if they
are describing real entities, for the most part the systems they describe should be
regarded as constructs because the way that the system is understood has been
constructed (either consciously or unconsciously) by a particular individual or group who

are observing a situation, and viewing aspects of it as a system. The perspective from
which the situation is viewed will shape what the viewer identifies as the ‘system of
interest’. As you will see later, where the boundaries of a system are defined – what is
considered to be part of the system, and what is considered to be outside the system –
can differ greatly according to who is defining those boundaries, the purpose they
consider the system to have, and even the time when they are considering the
boundaries.
For a non-IT example, consider ‘the healthcare system’. What could be included in this?
Groups and organisations that might be considered part of it: general practitioners,
hospitals, healthcare administrators, insurance companies, dentists, opticians, patients,
pharmaceutical companies, pharmacies, government regulators, ‘alternative’ practitioners
such as homeopaths and acupuncturists, gymnasiums … the list could go on. Which of
those are part of the healthcare system and which are not? For some purposes, it would
be appropriate to include some of the above list within the boundary of the healthcare
system, and to exclude others. Moreover, the boundary would be drawn differently in
different countries and probably by those holding different political or ideological
viewpoints. To take just one example, someone working for the NHS in the UK would
define the health system quite differently from someone working for one of the large
health insurance companies in the USA.
2.1 Approaches to systems thinking

All of this might seem somewhat abstract and philosophical. Does this mean there are no
such things as real systems existing in the world? Yes and no. This view does not suggest
that hospitals and pharmaceutical companies are unreal – rather it suggests that there are
many different ways to group together those real entities (in the form of systems), and in
the process of doing so we construct a particular model of reality at a particular time.
It is worth saying that there are many different approaches, both academic and practical,
which use the idea of a ‘system’ as a way of understanding the world. Some of them
would agree with the above definition, others would not. However something like the
above (and especially the points about the observer, systems of interest, and systems as
constructs) has become widely accepted over the past few decades. Ramage and Shipp
(2009) provide an overview of systems traditions and the different approaches to systems
thinking.
Each of these four perspectives are forms of systems thinking, in that they all look at
whole systems and seek to understand the relationship between the parts and the whole,
but they use these ideas subtly differently. This is a course about successful IT systems,
not about systems thinking as such, and so the ideas we use here are presented
pragmatically, in ways that are intended to be useful, rather than as a theoretical
discussion of ideas around systems.
Activity 3
10 minutes
Have you previously encountered systems thinking in some form? Did it match the
Open University definition of a system found on the previous page?

Discussion
Systems thinking can be found in a number of different forms in different places, and
approaches that take a holistic perspective but don’t use the term system in even more
places. Although the language is different, the ideas of interconnection between
components and of purpose will be found in many understandings of systems.
One concept missing from this definition is the idea of feedback or circularity, which
some approaches to systems thinking regard as fundamental. In our view this is an
important concept, but it is secondary to the ideas of components, interconnection and
purpose.
It is worth observing that you may come across the use of the word ‘system’ to refer
solely to technology (such as software). Although this may fall within the strict
definition of a set of components interconnected for a purpose, it wouldn’t qualify as an
IT system as discussed in this course.
Before looking at what systems thinking can tell us about the nature of IT systems, we will
introduce the concept of sociotechnical systems thinking. This is a strand of systems
thinking that dates back to the early 1950s and is highly relevant to this course. It is
framed around the idea that the social and the technical aspects of a system are
inextricably linked. This course has, at its foundation, the idea that all IT systems are
sociotechnical – they cannot be understood without a sense of the relationship between
the social aspects (organisational and people) and the technical aspects (hardware and
software) of the system.
One of the long-standing practitioners of sociotechnical systems thinking, Ken Eason, has
written of the usefulness of the ideas and its importance in making sense of IT systems, as
follows:
What is important to me about sociotechnical systems theory is that it provides

a way of understanding the complex way in which people at work co-operate
and use tools and technology to get their collective work done. It helps us
understand how the operational reality of working life achieves the goals of the
organisation. It does so by treating the collection of human and technical
resources in the organisation as a system producing work and focuses on the
interdependencies between the people in their respective work roles and the
technical artefacts they use to get the work done. Two properties of this work
system seem to me to be all-important. First, if you change one part of the
system (say bring in a new technical system) the interdependencies mean
there are knock-on effects that may be positive for performance but equally
may lead to dysfunction in the overall system. The second point is that the work
system is an open system; it is subject to changes in its environment, to the
inputs it takes in and to the market for its outputs. A successful system is one
that can adapt to the turbulence of the outside world and it is the people in their
work roles who do most of the adapting. An important question is whether the
technical systems they use are capable of supporting this adaptation; if the
technology is not flexible it can become an obstacle to adaptive behaviour.
(Eason, 2008, p. 124)

2.2 Components of an IT system

Given the above definition of a system and its related components, and given that an IT
system is necessarily sociotechnical, what might be the basic components of a core IT
system? As we have remarked above, this depends on the way the system is defined by
an observer. But we would suggest that any IT system will have three core components:
● the technology of the system: the software, hardware, networks and other
infrastructure which go to make it up. A few years ago this largely meant fixed
networks of PCs in most organisations, with large mainframes performing back-end
tasks. The rise of mobile and wireless devices, and the importance of the cloud for
information storage and processing, have changed this significantly, and there are
currently many possible combinations of hardware and software.
● the organisation where the system is used and developed. The success of a system
in use depends a lot upon how well it fits with the need of this organisation, and the
way it is organised.
● the people involved in the system: technical staff (such as developers, maintainers
and support staff); end users; managers; training staff; and many other groups.
The basic structure of an IT system with these three core components, showing their
influences on each other, might look something like Figure 1.
Technology Organisation
People
Figure 1 The main components of an IT system

This course will make the case throughout that all three of these components are
important in considering the nature of an IT system and in making it successful. It is not
sufficient to consider the technology as the core of the system and the organisational and
people aspects as secondary – they are all three interrelated.
Activity 4
10 minutes
Do you think these are sufficient components of an IT system? What other components
might you want to add? Write down these additional components.
Discussion
You may well have come up with other components as being important, but in our view
they can usually be seen as subsystems of the three main components of Technology,
Organisation and People.

3 Understanding success in IT systems

At the beginning of this course, we briefly defined success and failure before looking in
greater detail at the sociotechnical and evolutionary nature of IT systems, and at tools
from systems thinking to help you analyse IT systems. It is now time to return to a key
question introduced at the start of this course: if this is a course about the success of IT
systems, what do we mean by success? What evidence is there about IT success and
what models exist to better understand successful systems?
A consultancy firm, The Standish Group, has used surveys to monitor IT project
performance since 1994. Most of their data is not openly available but using figures
published by a number of different authors in various journals and white papers Nasir and
Sahibuddin (2011) have been able to summarise the Standish findings for 1994 to 2008.
These are shown in Table 1, where figures for 2010 and 2012, taken directly from
Standish (2013), have also been added. Succeeded is defined as ‘delivered on-time, on-
budget, with required features and functions’; challenged as ‘late, over budget, and/or with
less [sic] than the required features and functions’; and failed as ‘cancelled prior to
completion or delivered and never used’ (Standish, 2013, p. 1).
Table 1 Standish findings by year (adapted from Nasir and Sahibuddin, 2011,
p. 2175; Business Wire, 2003; and Standish, 2013, p. 1)
Year 1994 1996 1998 2000 2003 2004 2006 2008 2010 2012
Succeeded 16 27 26 28 34 29 35 32 37 39
(%)
Challenged 53 33 46 49 51 53 46 44 42 43
(%)
Failed (%) 31 40 28 23 15 18 19 24 21 18
As you can see, there are some grounds for optimism in Table 1 in that the proportion
succeeding was increasing during the period represented but nevertheless the picture
painted is not rosy.
A similar impression is created by the work of Flyvberg and Budzier (2011). They looked
at 1471 ‘large IT projects … that ran the gamut from enterprise resource planning to
management information and customer relationship management systems’ (p. 24) and
compared their budgets and estimated performance benefits with the actual costs and
results. Their conclusion was that the average cost overrun was 27%.
It is not only survey data that shows the difficulties of building successful systems. It is
true that the media prefers reporting bad news – it is claimed (see, for example,
Williams, 2010) that the ratio of bad news stories to good news stories is around 17 to 1 –
but it is also the case that where systems failure is concerned there is plenty to report. As
discussed earlier, in 2008 the BBC launched its Digital Media Initiative to build a system
that would allow all its audio and visual material (new and archived) to be made available
to staff making programmes via a desktop. Between 2010 and 2012 £98.4 million was
spent on the project and in May 2013 the initiative was cancelled. At the very same time
the media were reporting problems being experienced by the Co-operative Bank, one of
which related to its IT system:

The Manchester-based organisation’s [i.e. the Co-operative Bank’s] finances

may face extra strain in the next few months from more writedowns on a
defunct IT system, according to sources. The Co-op has already written off
£150 million on a system that it did not use. Some have warned that figure
could get much bigger.
(Griffiths, 2013)
In September 2013 the National Audit Office (NAO) reported an investigation into plans by
the Department for Work and Pensions to roll-out universal credit across the UK whereby
benefits and tax credits to people who are unemployed or on low incomes are merged
together into a single monthly payment. This is one aspect of what they found:
Over 70 per cent of the £425 million spent to date has been on IT systems. The
Department, however, has already written off £34 million of its new IT systems
and does not yet know if they will support national roll-out. The existing systems
offer limited functionality. For instance, the current IT system lacks a component
to identify potentially fraudulent claims so that the Department has to rely on
multiple manual checks on claims and payments. Such checks will not be
feasible or adequate once the system is running nationally. Problems with the
IT system have delayed national roll-out of the programme.
(NAO, 2013)
Of course, a lot of systems do work. Admittedly some need tweaking and others need
more major remedial work before they are judged to be successful but there are those that
meet the goal of ‘right first time’. Overall though, evidence suggests that ‘system design
and building’ ought to be placed in the high-risk category of endeavour. The next topic we
are going to look at lies right at the heart of this question and, indeed, the course’s title:
what do we mean by ‘a successful system’?

3.1 What is a successful system?

A succinct definition of a successful system is a system that:
achieved what was intended of it; it was operational at the time and cost that
was planned; the project team and the users are pleased with the result and
they continue to be satisfied afterwards.
(Fortune and Peters, 2005, p. 13)
On the face of it, this definition sounds straightforward, but once we start to examine it
carefully, we begin to see that it is not as clear-cut as it at first appears. Let us look at it
phrase by phrase.
achieved what was intended of it
This implies that the requirements for the system were identified accurately and translated
into stated and agreed objectives before the system was developed and that it is possible
to measure performance of the system against these objectives in order to check they
have been met.
… it was operational at the time and cost that was planned
Here it is assumed that there was an agreed and approved development plan that
included timescales and costs and that performance against this plan can be measured. It
also assumes that it is clear what ‘operational’ means and it is possible to be certain when
it has been achieved.
An important difference between these first two parts of the definition is that the first one is
about the success of the system and the second one is concerned with the success of the
project that built the system. For an individual project, judgments of success are not
necessarily the same across both aspects. A project regarded as well-managed may fail
to deliver the intended outcomes whilst a project that experiences many problems can still
be capable of delivering success, though almost always at a price. There does tend to be
a positive correlation between the quality of the project management and the quality of the
output, but there are exceptions.
… the project team and the users are pleased with the result
This is where the definition becomes even murkier with a number of potentially conflicting
judgements. First, there is the relative importance of the views of the project team and the
users. Some would regard the views of the professionals who make up a project team as
paramount but others would say that the views of the project team are largely irrelevant as
long as the users are content. The next big question it raises is ‘who are the users?’ Are
the users just the people who interact directly with the system or do they include those
who may not know it exists but are users of the services it supports? Are all users’ views
equally important, and what about the views of the client or customer? This part of the
definition also implies that ‘pleasure’ can be measured or assessed.
… and they continue to be satisfied afterwards.
This shares the problems of the previous phrase. Who are the users whose degree of
satisfaction should be considered later? Another question is how long a period of time is
covered by ‘afterwards’. They may not be the original users, however defined. Measuring
and/or assessing satisfaction is also an issue here. Should the same criteria be used as
when the system was new or might there be a different set of standards now that users
are familiar with the system? Another issue is what allowances should be made for the
passage of time. For example, the environment may have changed to such an extent that

there is now a need for the system to do things that were not envisaged when the system
was designed.
Hopefully you can see from the examination of this definition that complexity and
ambiguity surround the notion of success and, indeed, failure.
Activity 5
15 minutes
Identify three things that stand out to you in this examination of the succinct definition
of a successful system.
Discussion
The three things that stand out most for us are:
● Judgements about success and failure are usually a combination of the objective
and the subjective and can vary quite significantly from person to person. As a
consequence, the overall judgement about whether a particular system is
classified as a failure or a success will often be contested.
● It is important to know to whom you are referring when you use terms such as
‘users’, ‘customers’ and the like.
● Perceptions of success and failure can change over the life of a system.
3.2 Criteria for judging success

To some extent, failure is a mirror image of success. A simple definition of failure is
‘something that has gone wrong, or not lived up to expectations’. Moving a little way
beyond this simple statement, various types or categories of failure can be identified
such as:
● objectives not met

● undesirable side effects
● inappropriate objectives set for the system.
The first type includes systems where objectives are never met and those that work some,
or even most, of the time, but are not as reliable as they should be. An example of the
former is the BBC’s Digital Media Initiative mentioned earlier where the aim had been ‘to
create a fully integrated digital production and archiving system to help staff to develop,
create, share and manage video and audio content and programming on their desktops’
(BBC Trust, 2014). An example of the latter is the temporary collapse of NatWest’s online
banking and other services including cash withdrawals from ATMs and debit card
payments:
Millions of Natwest customers were left unable to withdraw cash or make

transactions on Wednesday [6 March 2013], less than a year after IT problems
left many unable to move money or pay bills for days. The bank said that online
and telephone banking, cash withdrawals and payments had been affected.
(Batty, 2013)

In the second type of failures the original objectives are met but there are also
consequences or side effects which are judged to be inappropriate or undesirable. For
example, a suite of programmes might work well but leave the company that has installed
them vulnerable because they create a security loophole or an unwise dependency on a
third party. Even worse, these first two categories of failure are not mutually exclusive; a
system may fail to live up to expectations and have undesirable consequences!
It can be argued that the distinction between the first and third categories of failure hinges
on whether the objective setting was carried out correctly in the first place. In the first type
the objectives are clearly taken as given and a judgement made solely about the extent to
which they are met. ‘Inappropriate objectives’ leaves open the question of whether the
original objectives were flawed. Once again, what at first appears to be a straightforward
categorisation rapidly becomes more complicated because it relies heavily on the view
taken of the original objectives which is in turn dependent on the standpoint of the
observer.
3.2.1 Surveys of IT success

A number of surveys have been conducted to see what factors people actually take into
account when judging the success of systems and the projects that produced them. For
example, Wateridge (1998, p. 6) conducted a survey among 132 project managers and
users and asked them to ‘indicate the five most important criteria for success on particular
[IS/IT] projects’. He found that the six most frequently mentioned criteria were:
● meets user requirements

● achieves purpose
● meets timescale
● meets budget
● happy users
● meets quality.
These criteria for judging project success are very similar to those implied in the simple
definition we started with. However, a more recent survey (Fortune et al., 2011) across
Australia, Canada and the UK found a broader range of criteria being used when 50
respondents in each of the three countries were asked to provide and to rank in order of
importance the success criteria they had used to make a judgement about the success of
a project they had recently worked on. In Table 2 you can see the success criteria they
provided. The criteria have been weighted according to the order of importance placed
upon them. (The criteria regarded as most important has been given a weighting of 3, the
second most important a weighting of 2 and the third a weighing of 1.) As can be seen, the
four highest scoring criteria are wholly concerned with the success of the project but after
that, aspects associated with longer-term system success start to appear in the list.
Table 2 Criteria for judging success (Source: Fortune et al., 2011, p. 560)
Criteria Australia Canada United Grand
Kingdom Total
Meets client’s requirements 96 81 102 279
Completed within schedule 68 62 48 178
Completed within budget 43 38 34 115

Meets quality and/or safety standards 28 28 14 70
Yields business and other benefits 23 8 23 54

Meets organisational objectives 14 18 5 37
Causes minimal business disruptions 6 14 9 29
Is capable of adapting to internal and/or 6 7 12 25

external changing needs
Delivers the best value possible 1 9 0 10
Provides strategic or operation learning for the 3 0 4 7

organisation
Facilitates leading the organisation into future 0 0 5 5

business/direction
Delivers return on investment 4 0 0 4
Makes only limited use of contingency funds 0 0 2 2
Delivers enhanced reputation for the 0 0 2 2

organisation
One of the consequences of broadening the criteria used to judge the success of IT
projects is that it can lead to the situation where a system can be perceived to have failed
if it misses any of the criteria and thus drag the overall judgements across all projects
downwards. It then becomes hardly surprising that some observers have argued that
most large and many small IT projects are failures.
Different people will, of course, prioritise different criteria so even when talking about one
system, not all judgements will necessarily be the same.
Activity 6
10 minutes
Which of the criteria in Table 2 is an accountant most likely to be most concerned

about?
Discussion
Unless it was a system the accountant will use, he or she is likely to be most
concerned about deviation from the budget, best value and return on investment.
Job role is often cited as a reason why different people’s judgements about success and
failure may vary but that is not the only cause of variation. Another cause is the
personalities of the people making the judgements. For any situation in which we find
ourselves, some of us tend to see the positive and some of us the negative. And to make it
even more complicated we do not necessarily see the same positives or the same
negatives! This difference in attitude works alongside other factors such as individual
motivations and cognitive styles to influence individual’s judgements.
If you look at Table 3 you will see that differences in judgements of this type are not new.
In 1978 Wedley and Ferrie reported the results of a survey conducted across 49
operations research (OR) and management science projects. They asked the analysts
working on the projects and the managers responsible for implementation to classify their
own projects according to the degree of success. As you can see, the analysts regarded

63% of the projects to be successful and implemented whereas only 20% of them were
classified thus by the managers.
Table 3 Distribution of projects by implementation status as classified by

analysts and managers (Source: Wedley and Ferrie, 1978, p. 201)
Analysts’ classification
Unsuccessful Successful but Successful and

unimplemented implemented
Managers’
classification
Unsuccessful 6% 6% 10%
Successful but 10% 14% 33%
unimplemented
Successful and 0% 0% 20%

implemented

4 Stakeholders in systems success

The point was made earlier that not all judgements about an individual system will
necessarily be the same. There is a classic model of systems success by Delone and
Mclean (2003). The only group of people this model specifically refers to is users. But who
are the users? In relation to the original version of their model they do not define users,
but it can be inferred that their definition was a narrow one. However, by their 2003 paper
the definition had widened. As they pointed out:
Within the e-commerce context, the primary system users are customers or
suppliers rather than internal users. Customers and suppliers use the system to
make buying or selling decisions and execute business transactions.
(DeLone and Mclean, 2003, p. 24)
This, however, is not an entirely satisfactory summary – what about potential customers?
Have you ever been about to buy something over the internet and then become so
irritated by the site that you have decided not to bother after all? Many people have. Were
they users of the site?
A very useful concept here is that of stakeholder. This concept is said to have been first
used in 1963 within an internal memo at the Stanford Research Institute in California to
refer to those groups without whose support the organisation would cease to exist.
Freeman (1984, p. 46) defined it as ‘any group or individual who can affect or is affected
by the achievement of the organization’s objectives’. Nowadays it is used even more
loosely to refer to people who have a vested interest in a situation.
There is a range of stakeholder analysis techniques – Bryson (2004) identifies 15 – but
here we shall be looking at just the three main aspects of stakeholder analysis. These
enable you to:
● identify stakeholders
● understand key stakeholders
● prioritise stakeholders.

4.1 Stakeholder analysis

The most commonly used way of starting to identify stakeholders is to undertake a
brainstorming session. On the face of it, brainstorming is a simple method for generating
ideas and it is likely that this apparent simplicity is the main reason for its popularity.
However, it is more effective if it is applied more formally within a set of rules such as:
● work in small, close groups of perhaps five or six, in a private, protected area away
from interference or interruption
● create an atmosphere that is safe, supportive, concerned with encouragement and
building (not criticism or dissection), fun, playful, energetic, enthusiastic, permissive,
stimulating and risk taking
● divide the time into periods of relaxed privacy for individual imagination and
contrasting periods of excited, lively, rapid-fire group interaction
● write up all the ideas as they occur where everyone can see them
● treat everyone as equal and enable everyone to contribute, although it may be useful
to appoint a ‘compère’ who discourages criticism, encourages dramatic and
outlandish ideas and maintains the pace
● continue while the excitement lasts, but stop at the first signs of staleness
● when a good stock of raw suggestions has been generated, switch into a more
controlled mode and work through the list of suggestions to look for overlaps,
omissions and possibilities for forming groupings.
Activity 7
15 minutes
Which three of the seven rules listed above would you select as being the most
important to the success of a brainstorming session and why?

Discussion
In our view, the following rules will most affect the atmosphere of the session and thus
its likely success:
● Create an atmosphere that is safe, supportive, concerned with encouragement

and building (not criticism or dissection), fun, playful, energetic, enthusiastic,
permissive, stimulating and risk taking.
● Divide the time into periods of relaxed privacy for individual imagination and
contrasting periods of excited, lively, rapid-fire group interaction.
● Treat everyone as equal and enable everyone to contribute, although it may be
useful to appoint a ‘compère’ who discourages criticism, encourages dramatic
and outlandish ideas, and maintains the pace.
In practice, it is very difficult to ensure that the rules are followed. The stifling of critical and
negative remarks, for example, requires a good deal of self-discipline. ‘Everyone is equal
and everyone contributes’ can be difficult in the face of hierarchical differences. A similar
problem concerns the level of each individual’s knowledge about the situation under
consideration.
An alternative to brainstorming is brainwriting where the participants do not talk to each
other but communicate, usually electronically, instead. For example, it is possible to set up
a wiki and add suggestions over a period of a few days. Brainwriting is attractive because
it can overcome some of the problems associated with brainstorming but another big
advantage it offers is that people can participate remotely.
4.2 Identifying stakeholder groups

In thinking about who the stakeholders might be, a good starting point is to ask:
● Who is affected positively or negatively by the project to build the system?

● Who will gain from the system and who will lose from it across a range of gains such
as material, financial, status, power, influence and the like?
● Who might want it to succeed and who might want it to fail?
● Who has the power to cause the project to succeed or to fail?
● Who controls or provides the resources and facilities that will be needed?
● Who are the key suppliers you will need to buy from?
● Who has the special skills needed to make it succeed?
● Who are the positive and negative opinion leaders?
● Who exercises influence over other stakeholders?
● Who are the less obvious stakeholders you have not considered yet?
For example, a new IT system that will automatically record and track the progress of
production jobs through a factory will have among its stakeholders:
● all those people who record, collate and distribute the data under the old system
(e.g. operatives, sales staff)
● all those people who receive data under the old system (e.g. planners, accountants
and the managers of operatives and sales staff)

● anyone who uses the data as information for decision making (e.g. production and
warehouse managers)
● those who design and implement the new system, and to some extent those involved
in the old system (e.g. information systems and IT specialists, programmers)
● suppliers
● any people who maintain the old system or who will maintain the new one
● senior managers who grant the resources needed for the project
● anyone who championed some other project that did not get resources because they
went to this project
● the customers for the factory’s products.
Trying to identify less obvious stakeholders is very important. It is all too easy to confine a
stakeholder analysis to ‘the usual suspects’ such as those listed in Table 4. Another point
to be aware of is that organisations and people can be identified as stakeholders but
ultimately you can only communicate with people so will become necessary to identify the
most appropriate individual stakeholders within a stakeholder organisation so that you
can work with them. It is also the case that changes may occur over time with new
stakeholders emerging and others ceasing to have a role.
Table 4 Commonly identified stakeholders (Source: Davis, 2013, p. 11)

Stakeholder Stakeholders
group
Senior Senior management board, director, executive, executive management,

management investor, project executive, portfolio director, programme director, owner,
senior management, sponsor, top management, project sponsor
Project core Engineer, other organisational involvement (e.g. business departments),

team project leader, project manager, project personnel, project team leader, project
team, team members
Project recipient Client, consumer, customer, end users, users
Activity 8
15 minutes
Suggest two refinements you could make to the recipient group to make it more
comprehensive.
Discussion
The two we would add are potential customers you are hoping to attract and the key
customers of customers.
In the context of IT systems, Dix et al. (2004) provide a useful distinction between
stakeholders. They identify four classes:
● Primary stakeholders − people who will actually use the system – the end-
users.
● Secondary stakeholders − people who do not directly use the system, but
receive output from it or provide input to it (for example, someone who
receives a report produced by the system).

● Tertiary stakeholders − people who do not fall into either of the first two
categories but who are directly affected by the success or failure of the
system (for example, a director whose profits increase or decrease
depending on the success of the system).
● Facilitating stakeholders − people who are involved in the design,
development and maintenance of the system.
(Dix et al., 2004, p. 459)
4.3 From stakeholder identification to analysis

Once you have identified who the stakeholders are the next step is to see whether some
of them form into groups that can usefully be considered together. For example, in the
case of a new IT system that will automatically record and track the progress of production
jobs through a factory we can distinguish those stakeholders who lie within the project
(number 4 on the list), those stakeholders who lie outside the project but within the
organisation (numbers 1, 2, 3, 6, 7 and 8) and those who are external to the project and
the organisation (numbers 5 and 9).
Activity 9
25 minutes
Now read the short description of Riverside House’s situation and try to identify five
groups of stakeholders and think about why you have selected them.
Riverside House is a large NHS general practice. For a variety of reasons they decide
to move from a paper-based patient records system to a fully computerised one, which
will store records of patients’ details and medical history, will issue prescriptions, and
share information with other institutions (such as local hospitals, NHS Trusts, and
different practices). A standard software package has been used for this purpose in
several other local practices, and Riverside House decides to use this also. They
contract with a company that has worked with many of the other practices to install
appropriate computers, software and networks, to maintain the hardware and
software, and to train staff in the system’s use. It is not correct to say that the practice
is introducing an IT system where none previously existed: the paper-based system
also held information, albeit in a different form and allowing different things to be done.
It is more useful to think of them as changing the ‘technology’ of their patient records
system from paper- to computer-based. Each ‘technology’ allows users to do some
things better and makes them do some things worse.
Discussion
The stakeholder groups that occurred to us include:
● Receptionists. With the paper system, they were the people who had the clearest
relationship with the patients’ information. They had to look it up in the files, get it
out for the doctors or nurses, make changes to address details, etc. If doctors and
nurses are able to look up details for themselves, receptionists might feel their
jobs to be threatened (especially if the system has been ‘imposed’ on them by
more senior staff). However, they will still need to enter new and changed details

on the system, and generally be the central point for the management of patient
information.
● Doctors and nurses. These groups have a similar interest in the working of the
new system. Each needs access to the records of the patients they are seeing
next. They will be working with those records in a new way in the computerised
system, but more or less carrying out the same tasks. The new system should
make it easier for them to see patients, and access their records outside of
normal working hours when receptionists might have gone home. As the system
issues prescriptions, doctors will no longer need to write these by hand.
● Patients. The new system makes it easier for patients to obtain repeat
prescriptions as the information is more readily to hand. If they go to the hospital
for treatment, their details can be printed out or sent electronically, making it less
likely that there will be errors as they are copied from one paper form to another.
The new system might mean they have greater access to their records if
requested as the records will not be written in many different styles of
handwriting; but the fact that they are stored on computer might also make
patients more nervous about asking for the information.
● Practice management. Those running the practice find that the system has
particular benefits in the collection of various statistics to be passed on to the
NHS Trust and to government departments. There is an increasing demand for
such statistics: to measure the effective spending of public money; to monitor the
success of health education campaigns; to look for trends in various conditions.
Computerised patient information makes the collation of such statistics much
easier. They may also find that planning for staff use within the practice is easier.
● Computer system retailers/maintainers. Clearly they have benefits in selling their
products and services in the first place. However, it is often the case that their
interests are rather different from those of the various user groups: changes to the
software that might benefit the users could be very difficult or expensive for the
system maintainers to carry out; and new features that developers think are a
good idea might turn out not to be used by anyone. In this example, it is very clear
that the computer people are hired by Riverside House, and so decisions rest with
Riverside; within a larger organisation (with internal computer staff), it is often not
so clear who should make decisions.
● Wider groups such as local NHS Trust, local hospitals, government, local
community, drug companies, etc. who have some interest in the effects of the IT
system at Riverside. We have seen some of the interests of local hospitals, NHS
Trusts and government already – though it is worth noting that all those groups
want to spend as little money as possible, and the computerised system may cost
more. The wider local community is affected by any change to the health of their
neighbours, friends, family or employees that might be caused by changes at
Riverside (the new system will not necessarily make such changes, but it might).
And many further groups might be thought about – to pick one example, what if
drug companies could pay to have their drug’s name appear first on the list when
doctors are creating a prescription?

4.4 Power versus interest

In terms of trying to plan for a successful system, one important step is to find out more
about the criteria a stakeholder or group of stakeholders would use to judge the system’s
success. A tool that can be used here is the power/interest grid. This grid is sometimes
referred to as Mendelow’s matrix (Mendelow, 1991) and is shown in Figure 2.
High
Keep Manage
satisfied closely
Power
Monitor Keep
(minimum effort) informed
Low
Low Interest High
Figure 2 The power/interest grid

As you can see, the grid has four cells that are labelled according to the strategy for
managing the stakeholders. Groups of stakeholders, and individual stakeholders where
necessary, are plotted against the two dimensions of this grid, power and interest, and
then treated according to the quadrant in which they fall.
‘Level of interest’ is relatively straightforward to estimate but there is the complication that
it can change over time so after initial judgements have been made they need to be
monitored carefully to look for shifts. Power is a much more slippery concept. For
example, disparate groups of stakeholders, each with very limited amounts of power
individually, can wield a surprising amount of power if they unite in common cause and it is
also possible for stakeholder power to aggregate unintentionally in a ‘bottom-up’ fashion.
For this reason we shall be considering the concept further in the next section. Before we
do that let us look at a way of presenting the results of a stakeholder analysis. This is
shown in Table 5 where a couple of sample rows of a table are presented showing
stakeholders, their goals, their past reactions to change, what can be expected of them
now, whether the change embodied within the proposed system will affect the stakeholder
in a negative, positive or mixed way and what their likely reaction is going to be. The last
column is being used to indicate ideas for managing the relationship with that stakeholder
while the system is developed and put in place.

Table 5 Results of a stakeholder analysis

Stakeholder Their goals Past Reactions Impact on Possible Ideas to
reactions expected stakeholder: future ensure
negative/ reactions support
positive
Production Keep Sceptical of Likely to be Could be Could refuse Keep them

managers production on benefits of furious if negative if to switch to abreast with
schedule change, things go things go wrong; new system if progress;
worried about wrong at should be very they remain involve them in
problems with changeover positive if things sceptical of trial runs and
new systems work well success testing of new
system
Production Remain in paid Contact Likely to be Should be Could refuse Explain

operatives employment unions if the obstructive if positive if the to operate the benefits of the
change is the change is new system new system if new system;
likely to have seen as improves they feel offer bonuses
a detrimental negative productivity and watched or for increased
effect on their brings in more their jobs are productivity
jobs customers (and threatened
jobs)

5 Power and success in IT systems

We have looked at the nature of success in IT systems, and the different ways in which
that success is understood by different stakeholders. The previous section touched briefly
on the very important concept of power, which governs the relationships between the
stakeholders of an IT system.
Power manifests itself in various ways in different settings including decision making,
agenda setting and in the shaping of felt needs: think about the role of advertising in
getting consumers to purchase particular products such as cars, and the power of media
such as newspapers, television and, increasingly, social networks such as Facebook,
YouTube and Twitter in shaping public opinion on a range of issues. But what exactly is
power?
Notwithstanding the fact that as Clegg (1989, p. xv) has argued ‘there is no such thing as
a single all-embracing concept of power per se’, it is important to get to grips with this
notion. We might begin by defining power as the ability or capacity to perform or act
effectively; alternatively, we might define it as the ability to direct or influence the
behaviour of others or the course of events in the pursuit of some goal or agenda. In his
classic study, Power: A Radical View, philosopher Steven Lukes (1974, p. 37) identifies
the most basic concept of power as follows:
A exercises power over B when A affects B in a manner contrary to B’s

interests.
Importantly, on this view, power is something that is necessarily antagonistic or

‘oppositional’, only operating at sites of conflict between individuals and groups. What this
means is that in the absence of conflict – in more technical language, where power
remains unopposed or ‘uncontested’ – there simply is no exercise of power.
Yet another way of thinking about the issue is presented by Clegg (1989, p. xv) who
identifies three family groupings of concepts of power:

1. Dispositional – power as a set of abilities.

2. Agency-based – power as the ability to bring about events or cause changes to
occur.
3. Facilitative – power as the ability to achieve goals, that is, to get things done.
The principal difference between the first of these three groupings and the other two has
to do with an understanding of power as something that can be possessed by an
individual or group in the former, as contrasted with a view of power as something that is
necessarily ‘situational’ in nature, that is, determined relative to a ‘background’ context
constituted by a network of relations between various actors – for example, stakeholders
– in an organisational setting. Another important distinction is that between the power of
agents (individuals, groups, organisations etc.) and the power of structures in which
such agents are embedded. Structural power can manifest in different domains – social,
economic, cultural, technological and so on – and take a variety of forms including legal,
financial, governmental and educational institutions.
Issues of power are central when considering the role played by different stakeholders in
planning IT systems and, as you saw at the end of the last section, stakeholders can
enhance their power by coming together, mobilising their power in pursuit of a common
goal or agenda. According to Clegg (1990, p. 349) and others, the process of mobilising
power is what is known as politics, and in the remainder of this section our focus will be
on issues of politics and stakeholder power relations within organisations.
5.1 Politics and rationality

The original meaning and idea of politics comes from Ancient Athens, where it stood for a
means by which society allowed individuals to reconcile their differences through
consultation and negotiation. Politics is usually discussed in relation to issues of
government; however, in so far as organisations (or enterprises) are comprised of
collectives of people, it is possible to view organisations as systems of government, and
therefore as political entities.
Recognising organisations as political systems is important because it exposes what has
been referred to as ‘the myth of organisational rationality’ – the view that all the members
of an organisation are committed to pursuing common goals which are both objective,
neutral and rational, that is, value-free. In reality, organisational goals may be rational for
some people (e.g. senior management, board of directors) but not for others (e.g. IT
personnel). This means that rationality is always interest-based and dependent on the
perspective from which it is viewed; in short, rationality is always political. In terms of IT
systems, this means that planning, designing and building these processes, the people
involved in them and the many activities and mechanisms they promote are by no means
neutral as they may initially seem.
Organisational politics tends to go unnoticed as long as the interplay of competing
interests within an organisation remains relatively ordered such that there is an absence
of visible conflict. This means that when conflict does start to emerge, it appears that it is
politics that is the cause of the trouble, whereas in reality politics is merely the mechanism
through which power is exercised in pursuit or defence of interests. It is important to
appreciate that the structure and culture of many organisations tend to encourage conflict
by simultaneously requiring people to compete for resources, status and remuneration
and collaborate within and between teams, departments, organisations and even
countries.

5.2 Identifying conflict

Earlier in this course, you were presented with a case study describing the failure of the
BBC’s Digital Media Initiative (DMI). This is further explored in the box below, which
reports back on the findings of a UK government tribunal charged with determining
responsibility for the failure of the project.
Activity 10
15 minutes
Read the description in the box and then try to identify those events which best
illustrate the tension between competition and collaboration. (Hint: in terms of
competition, think about the differential power relations between stakeholders
attempting to avoid taking responsibility for the failure of the project.)
Discussion
There should have been collaboration between the CTO, director of operations and
project sponsor, with the project overseen by the director general of the BBC.
However, the director of operations maintained that at a two-hour meeting on 13
May 2013, where DMI’s future was discussed, the executive board had:
● lost confidence in the CTO’s ability to act

● were concerned about the CTO’s lack of collaboration.
Nonetheless, the tribunal found no evidence of this in the notes of the meeting.
The CTO claimed that the director of operations gave him a choice: resign or go
through a disciplinary process and face dismissal; further, that the blame for the failure
of DMI was unfairly being pinned on him – a case of ‘scapegoating’. This is a case of
competing to avoid taking blame as pointed out in the report of the tribunal.
Box 3: £100m DMI omnifail – BBC managers’ emails trawled by

employment tribunal
Gavin Clarke
The BBC last week stood by its dismissal of former technology chief John Linwood over the
failed £100m digital media initiative.
The Corporation was judged to have broken the law in dismissing Linwood and reading the
tribunal’s findings makes the BBC’s defence difficult to accept.
According to the BBC, the tribunal ‘acknowledges’ the BBC has lost confidence in Linwood.
The statement proved the BBC is still fighting a war it has lost: to apportion blame for a
failed IT project somewhere, anywhere, rather than take it on the chin.
The tribunal found that the ‘culture and climate also gave rise to avoidance strategies, no
doubt including, on occasion, the steering of the spotlight of blame in other directions, on
the part of those who felt themselves to be in danger of association with a sinking ship’.
This was the writing off of a £100m IT project spanning a decade, with layer upon layer of
management, a ‘grand vision’, a failure to control suppliers, and shifting targets.

Linwood started work at the BBC on 6 April 2009, and took on a project that was already
late and over-budget. By that year, outsourced supplier Siemens was terminated and DMI
brought back in house.
What followed was supposed to be a fresh start – or at least a reboot for the project. A new
deadline was set for DMI in February 2011 for the ‘end’ of the year along with new
deliverables – or at least reduced deliverables.
But by summer 2011, the wheels were coming off and it was calculated that some £19m of
projected savings would be lost due to delays and ‘other issues’.
By May 2012, Linwood was tearing his hair out, saying there was a ‘desperate need’ for a
‘senior owner’ from the BBC’s Vision Group to deliver the project.
But by September there was a new director general – George Entwistle – and a new project
sponsor, Zarin Patel, while Linwood had a new line manager – Dominic Coles, the new
director of operations.
It was not until 4 October, ‘once the decision to stop the project had been made’, that Vision
chief creative officer Pat Younge became project sponsor.
Entwistle made it clear he planned to review the ‘relationship’ with technology but by
November, Entwistle was out – thanks to the Jimmy Savile scandal. Tony Hall was only
appointed as director general in April 2013.
By May, the big guns were firing. Former BBC trust chairman Lord Patten attended a BBC
Trust finance committee meeting on 8 May declared his ‘profound concern’ at the massive
write-off, while BBC trustee Anthony Fry promised to ‘fess up’ to the House of Commons
Public Accounts Committee that had been monitoring DMI’s chronic progress and losses.
He also promised to appoint an external consultant who would establish what had gone
wrong on project control and reporting.
A two-hour executive board meeting followed on May 13 2013, where DMI’s future was
discussed. Reviewing a one-page summary of the discussion of that event provided by
Linwood, the tribunal said it found ‘no reference whatever’ made to the embattled CTO.
Coles, however, apparently decided to ‘take stock’ of that day’s discussions and act.
‘It appeared to us, that the executive board had lost confidence in Mr. Linwood’s ability to
act as the BBC CTO and continue to run the BBC’s technology division,’ was his summary
of events that day.
He started working with BBC HR director Richard Burdon on the basis that Linwood ‘had a
case to answer for in relation to DMI’.
Coles’ notes of the board meeting talk of concern about Linwood’s lack of collaboration and
the executive board’s loss of confidence. But, according to the tribunal, he was unable to
explain why none of the content contained in his own evidence was present in the notes of
the meeting.
Coles and Burdon convened a meeting with Linwood on 14 May.
Linwood had no idea what to expect of that meeting but Coles and Burdon did. Burdon, an
HR exec of 20 years, admitted during the tribunal that he and Coles hit Linwood ‘cold’.
Linwood claimed he was given a choice of resigning or going through a disciplinary process
and facing dismissal. Coles and Burdon denied this. The tribunal seems to have sided with
Linwood.
Importantly, Linwood rejected the attempt to pin the blame for DMI on him, while calling the
pair’s actions ‘unfair’ as he had not received a written warning.

By 24 May 2013 it was all over for DMI ... and for Linwood. The BBC went public on its
cancellation of DMI and said chief techie Linwood had been suspended.
(Adapted from Clarke, 2014)
5.3 Politics of stakeholder identification

Conflict can occur when two or more social actors (individuals, groups, organisations,
etc.) interact with one another while striving to attain their goals, and can be traced to one
or more of the following causes:
● competition for a resource that is scarce between social actors pursuing the same /
similar goals or different goals
● differing expectations – and behavioural preferences – of joint action
● different attitudes, values, beliefs, and skills.
However, conflict should not be viewed as something that is necessarily bad for an
organisation – irrespective of whether such conflict takes place within the organisation or
between two separate organisations. Increasingly, organisational conflict has come to be
seen as both legitimate and inevitable; it may even be a positive indicator of effective
organisational management. Furthermore, within certain limits, conflict is essential to
productivity: conflict may result in creative solutions to problems, while little or no conflict
in organisations may lead to stagnation, poor decisions and ineffectiveness.
Activity 11
20 minutes
Given what you have learned about the biased nature of stakeholder perspectives,
spend the next few minutes thinking about why understanding stakeholder analysis in
terms of these components might be problematic, and about what goes unchallenged
– or is not subjected to ‘contestation’ – in plotting stakeholders on a power/interest
grid. (Hint: try to think about what is being obscured, albeit unintentionally, in both
situations.) Write down your answer.
Discussion
As described at the start of Section 4, the three main components of stakeholder
analysis are: identify stakeholders; understand key stakeholders; and prioritise
stakeholders. This approach might seem straightforward enough but all three of these
activities can be done in very different ways, and it is easy to miss key stakeholders
due to unconscious bias. For example, there are a variety of stories about IT systems
involving voice recognition that were designed by men who tested the system on
themselves and managed to forget that women and children typically have higher
voices. In some cases this made the first version of the system only suitable for men.
Other stakeholders were ignored. No malice or intentional bias was intended – but
groups were ignored.
The same can be said for the power/interest grid – in itself it is a useful tool, but the
perspectives of those populating the grid must not be ignored. It is not an objective
instrument by itself.

According to Clegg (1989, p. 13), ‘the drawing of political boundaries [that is, the
identification of political groupings] in the formal sense is itself always an act of politics,
representing a mobilisation of bias.’ In short, there is no ‘view from nowhere’, no neutral or
objective vantage point from which a value-free stakeholder analysis can be performed.
Put another way, any identification of stakeholders in an IT system as the stakeholders in
that system will be politically motivated and hence, biased. Given the intrinsic bias (or
subjectivity) of stakeholder identification, the issue becomes one of determining whether
such bias can be legitimised and if so, how this is achieved.
5.4 Stakeholder legitimacy and conflict

One way that stakeholders attempt to exert and maintain influence is by seeking to
legitimise their interests and demands while de-legitimising those of others. Another
strategy involves a stakeholder group (e.g. senior management, designers) using its
power to structure an organisation in such a way that it then favours its interests over that
of other groups (e.g. workers, users). At that point, power becomes institutionalised and
virtually invisible.
To ensure that goals are met requires adequate forms of formal control and it is through
control mechanisms that authority – that is, legitimised power – is exercised. Emphasis is
placed on designing and implementing formal, hierarchical methods and techniques and
mechanisms for controlling the planning and implementation of systems. Organisational
activities must be regulated so that actual performance conforms to expected
organisational standards and goals.
In addition to formal, structural, control mechanisms such as rules, regulations and
technology, informal systems such as peer pressure, tradition, convention, etc. are also at
work. However, formal and informal systems of control are often in conflict leading to the
emergence of an ‘implementation gap’ – a difference between the planned and actual
outcome of a project, e.g. technologies being designed to do one thing but when
implemented being used for another (or functions being ignored).
In mainstream views, mechanisms of domination such as leadership, culture and
structure are usually treated as neutral, inevitable, or objective, and hence unproblematic.
The separation of formulation from implementation, downplaying the importance of the
relationship between formal and informal systems of control and assumptions about the
compatibility of organisational and individual/group goals is likely to encourage ignorance
of the possibility of ‘goal incongruence’ (or mismatch of stakeholder objectives), and
therefore of the possibility of conflict between stakeholders. This situation is further
aggravated because conventional approaches to management encourage the belief that
those involved in managing the implementation process act as rational and neutral actors
when carrying out their responsibilities and actions. Consequently, power and interests
remain invisible until the point at which conflict occurs when power and politics become a
necessary resource of management to defeat conflict.
5.5 Expert stakeholder power

In addition to the role played by management in influencing the approach to IT system
implementation in an organisation, it is important to consider how power is exercised by
experts such as designers and programmers. Experts are able to exercise power through

the control of access to and accumulation of specialist knowledge and information about
technology. They wield significant power in many situations, including system design and
implementation, because they possess knowledge and skills that others do not. In
addition, experts who belong to professions are often able to limit access to the power
loop associated with system implementation shown in Figure 3. In terms of what was
stated above about the exercise of stakeholder influence through processes of
legitimisation, it should be noted that in some contexts a professional body is able to
maintain a situation where unless a person is qualified according to a set criterion they
cannot legitimately participate in any aspect of the work of that profession. (This does not
apply to the UK since there is no licence to practice in this context, although the British
Computer Society has worked hard to professionalise IT practice in the UK.)
Development and
implementation of system
Influences Shapes
Experts and professions Control of implementation

strategy
Defines
Figure 3 System implementation power loop involving experts and professions

Some professions are more powerful than others, and over time the power of professions
may well ebb and flow – consider, for example, the decline in the status of engineers in the
USA and UK. In short, although professions in particular, and stakeholders in general
(though less effectively), try to control access to, and the influence of, other groups in their
domain of influence it is crucial to appreciate that, ultimately, power relations are dynamic.
In other words, the power and/or influence that an individual or group has today might not
be the same as they had last week or will have in the future.
Finally, it is worth noting that the power of experts and stakeholders is very likely to differ
at different stages of the system life cycle in the case of systems developed using the
‘waterfall’ approach, where it is assumed one stage of the system life cycle is followed by
another, with little scope for return to earlier stages. For systems developed using
evolutionary approaches, the situation is more complex with reversals in power relations
occurring due to the presence of feedback loops between stakeholders and incremental
adaptation, which sometimes proceeds very rapidly. Stakeholder power can also change
with adoption of an approach to systems development incorporating different values. For
example, in a study conducted by McAvoy and Butler (2009) looking at the introduction of
agile methods in a software development team, it was discovered that the power
associated with the desire for cohesion and conformity within the team which required a
‘flatter’, more symmetric distribution of power between the stakeholders led to ineffective
decision-making and learning. While recognising that such outcomes might be specific to
particular deployments of such methods, it is important to appreciate that promoting
different values and pursuing different goals results in different configurations of power;
furthermore, that determining which values end up being promoted and which goals end
up being pursued depends on power relations between stakeholders.

5.6 Power and system success

In any process of system implementation, some groups will be better placed to influence
the inputs, outputs and outcomes of the process than others. Furthermore, as you have
seen, system implementation is a dynamic process, and the groups and individuals that
are involved, and their relative power, are in constant flux.
What does this mean in terms of planning for successful IT systems? In order to begin to
answer this question, we need to review the different criteria for determining what counts
as system success. These were listed earlier as:
● meets client’s requirements

● completed within schedule
● completed within budget
● meets quality and/or safety standards.
All such criteria can and should be looked at from a power perspective. This is because
the very notion of ‘the system’ implies a consensual understanding of a situation, yet this
consensus – assuming it even exists – may only reflect the view of a small number of
stakeholders who are able to exert their influence on others. The same can be said for
determination of the system’s objectives and performance measures: who gets to decide
these, when, where and how? In this connection, consider the following assertion of
Markus and Robey (1983, p. 210):
While an information system might validly fit the organization task and users’
needs and cognitive styles, it might be resisted because it causes a
redistribution of power unacceptable to those losing power. Thus, organiza-
tional validity can also be defined in terms of the distribution of power within an
organization; a system can be said to be invalid to the extent that it embodies a
power distribution at odds with that existing in the organizational context of use.
Whether a particular IT system is classified as a failure or a success will often be

contested, and it is here that power-relations and dominant/subordinate perspectives on
evaluation criteria come into play. Disputes between stakeholders, if and when they arise,
can involve the internal politics of an organisation and at times may be legal, contractual
or even academic.
Activity 12
20 minutes
In Activity 9, you were asked to read a short description of Riverside House, an NHS
general practice transitioning from a paper-based patient records system to a
computerised one. Read through the description again to refresh your memory.
a. For each of the five groups of stakeholders that you identified in that activity, try to
come up with a criterion that it might use to determine system success.
b. For those stakeholders that interact, take a pair of stakeholders and try to identify
the power relations between them in terms of which stakeholder is in a dominant
position and which is in a subordinate position.

Discussion
a. The following six stakeholder groups were listed in the answer to Activity 9 so we
will list criteria for system success for each one.
○ Receptionists: A successful IT system would be one that enables them to do
their job effectively and easily, but also to be able to keep their job.
○ Doctors and nurses: A successful IT system would allow these people to
have easy access to patient records, without going through receptionists,
both from work and home.
○ Patients: A successful IT system would be one that stores their information
correctly and allows relevant staff to access it when needed, as well as
enabling additional functionality such as repeat prescriptions.
○ Practice management: A successful IT system would enable practice
management to produce aggregate statistics, and to allow them to run the
practice more efficiently.
○ Computer system retailers/maintainers: A successful IT system for these
people is one that uses their technology but also requires them to do minimal
additional work.
○ Wider groups with some interest in the effect of the IT system at Riverside:
Success criteria for these groups is multiple and somewhat conflicted –
spending less money, but providing greater functionality in producing
management statistics while maintaining patient privacy.
b. Brief comments on power relations between stakeholder groups.
○ Receptionists are in a subordinate position to doctors and nurses, to practice
management, and somewhat to computer system retailers/maintainers; they
interact with patients but it is not clear whether they are dominant or
subordinate (in some ways both of these). They do not particularly relate to
the wider groups.
○ Doctors and nurses are in a dominant position to receptionists and probably
also to patients (in practice if not in theory). In some practices they will be
dominant to management and in others they are subordinate to it. In power
terms, they are somewhat subordinate to computer system retailers/
manufacturers (as they are users rather than buyers). They will be
subordinate to some wider groups and dominant to others.
○ Patients are in a subordinate position to doctors and nurses and to practice
management; they have a complicated relationship to receptionists. They
probably do not relate to computer retailers/manufacturers (as patients).
They may well form part of the wider groups but, as a group, don’t have a
power relation to them.
○ Practice management are in a dominant position to receptionists, patients
(probably) and computer system retailers/manufacturers. They are some-
times dominant and sometimes subordinate to doctors and nurses, and
likewise to the wider groups (though as the latter are often fund holders, they
are more likely to be subordinate to them).
○ Computer system retailers/maintainers are in a subordinate position to
practice management and in a de-facto dominant position to doctors and
nurses, and to receptionists. They do not really relate to patients or the wider
groups.

○ Wider groups are dominant to some of the above and subordinate to others,
but it varies within each group of stakeholders.

Conclusion
Conclusion
In this course you have learnt about the nature of success in IT systems. In particular you
have learnt about:
● what we mean when we say an IT system is a success or a failure

● that all IT systems are sociotechnical – a mixture of people, organisations and
technology
● how you can judge whether an IT system is successful
● ways to analyse the stakeholders in the success of an IT system
● the importance of power and conflict in the success or failure of IT systems.
We hope you have found this course helpful, and that it’s given you insight into what we
mean by IT systems success. There are many more free OpenLearn courses on aspects
of systems thinking, which expand on topics in this course, including
Systems thinking and practice and an overview of the use of Systems diagramming to
model all kind of systems.
If you would like to learn in more detail about tools for ensuring that IT systems are
successful, the Open University course TM353 IT systems: planning for success may be
for you.

Keep on learning
Keep on learning
Study another free course

There are more than 800 courses on OpenLearn for you to choose from on a range of
subjects.
Find out more about all our free courses.
Take your studies further

Find out more about studying with The Open University by visiting our online prospectus.
If you are new to university study, you may be interested in our Access Courses or
Certificates.
What’s new from OpenLearn?

Sign up to our newsletter or view a sample.
For reference, full URLs to pages listed above:

OpenLearn – www.open.edu/openlearn/free-courses
Visiting our online prospectus – www.open.ac.uk/courses
Access Courses – www.open.ac.uk/courses/do-it/access
Certificates – www.open.ac.uk/courses/certificates-he
Newsletter –
www.open.edu/openlearn/about-openlearn/subscribe-the-openlearn-newsletter

References
References
Batty, D. (2013) ‘NatWest hit by system failure less than a year after last outage’,
Guardian, 24 May [Online]. Available at http://theguardian.com/business/2013/mar/07/
natwest-bank-system-failure-outage (Accessed 5 November 2015).
BBC Trust (2014) ‘Trust publishes NAO report into BBC Digital Media Initiative’, BBC
Trust, 23 September [Online]. Available at http://bbc.co.uk/bbctrust/news/press_releases/
2014/nao_dmi.html (Accessed 13 February 2015).
Bryson, J. M. (2004) ‘What to do when stakeholders matter’, Public Management Review,
vol. 6, no. 1, pp. 21−53.
Burton, G. (2013) ‘Bottoms up: pub chain Michells & Butlers’ top-to-toe IT overhaul’,
Computing, 26 June [Online]. Available at http://computing.co.uk/ctg/feature/2277013/
bottoms-up-pub-chain-mitchells-butlers-toptotoe-it-overhaul (Accessed 5 No-
vember 2015).
Business Wire (2003) ‘Latest Standish Group CHAOS Report Shows Project Success
Rates Have Improved by 50%’, Business Wire, March 25 [Online]. Available at http://
businesswire.com/news/home/20030325005636/en/Latest-Standish-Group-CHAOS-Re-
port-Shows-Project (Accessed 5 November 2015).
Clarke, G. (2014) ‘£100m DMI omnifail: BBC managers’ emails trawled by employment
tribunal’, the register, 12 August 2014 [Online]. Available at http://theregister.co.uk/2014/
08/12/bbc_linwood_tribunal/ (Accessed 5 November 2015).
Clegg, S. R. (1989) Frameworks of Power, London, SAGE Publications Ltd.
Clegg, S .R. (1990) Modern Organizations, London, SAGE.
Conlan, T. and Arthur, C. (2013) ‘BBC suspends technology officer after Digital Media
Initiative failure’, Guardian, 24 May [Online]. Available at http://theguardian.com/media/
2013/may/24/bbc-digital-media-initiative-failure (Accessed 5 November 2015).
Davis, K. (2013) ‘Different stakeholder groups and their perceptions of project success’,
International Journal of Project Management, vol. 32, no. 2, pp. 189−201 [Online].
Available at http://dx.doi.org/10.1016/j.ijproman.2013.02.006 (Accessed 5 No-
vember 2015).
DeLone, W. H. and McLean, E. R. (2003) ‘The DeLone and McLean model of information
systems success: a ten-year update’, Journal of Management Information Systems,
vol. 19, no. 4, pp. 9−30.
Dix, A., Finlay, J., Abowd, G. D. and Beale, R. (2004) Human–Computer Interaction,
Harlow, Pearson Prentice Hall.
Eason, K. (2008) ‘Sociotechnical systems theory in the 21st century: another half-filled
glass?’, in Graves, D. (ed) Sense in Social Science: A collection of essays in honour of Dr.
Lisl Klein [Online], Broughton, Desmond Graves, pp. 123−34. Available at http://
bayswaterinst.org/storage/Sociotechnical%20systems%20theory%20in%20the%2021st
%20Century.pdf (Accessed 5 November 2015).
Flyvberg, B. and Budzier, A. (2011) ‘Why your IT project might be riskier than you think’,
Harvard Business Review, September, pp. 23−5.
Fortune, J. and Peters, G. (2005) Information Systems: Achieving Success by Avoiding
Failure, Chichester, Wiley.

Acknowledgements
Fortune, J., White, D., Jugdev, K. and Walker, D. (2011) ‘Looking again at current practice
in project management’, International Journal of Managing Projects in Business, vol. 4,
no. 4, pp. 553−72.
Freeman, R. E. (1984) Strategic Management: A Stakeholder Approach, Boston, MA,
Pitman.
Griffiths, K. (2013) ‘Co-op to sell mortgage processor’, The Times, 10 June [Online].
Available at http://thetimes.co.uk/tto/business/industries/banking/article3786949.ece
(Accessed 5 November 2015).
Lukes, S. (1974) Power: A Radical View. London, Macmillan.
Markus, L. and Robey, D. (1983) ‘The Organizational Validity of Management Information
Systems’, Human Relations, vol. 36, no. 3, pp. 203−26.
McAvoy, J. and Butler, T. (2009) ‘A failure to learn in a software development team: the
unsuccessful introduction of an agile method’, in C. Barry et al. (eds) Information Systems
Development: Challenges in Practice, Theory, and Education, Vol. 1, Berlin, Springer.
Mendelow, A. (1991) ‘Stakeholder mapping’, Proceedings of the Second International
Conference on Information Systems, Cambridge, MA, December 7−9.
NAO (2013) Universal Credit: Early Progress [Online]. Available at http://www.nao.org.uk/
report/universal-credit-early-progress/ (Accessed 5 November, 2013).
Nasir, M. H. N. and Sahibuddin, S. (2011) ‘Critical success factors for software projects: a
comparative study’, Scientific Research and Essays, vol. 6, no. 10, pp. 2174−86.
Ramage, M. and Shipp, K. (2009) Systems Thinkers, London, Springer.
Standish (2013) ‘The chaos manifesto’, The Standish Group International.
Wateridge, J. (1998) ‘How can IS/IT projects be measured for success?’, International
Journal of Project Management, vol. 16, no. 1, pp. 59−63.
Wedley, W. C. and Ferrie, A. E. J. (1978) ‘Perceptual differences and effects of
managerial participation on project implementation’, Journal of the Operational Research
Society, vol. 29, no. 3, pp. 199−204.
Williams, R. B. (2010) ‘Why we love bad news’, Psychology Today, 30 December [Online].
Available at http://psychologytoday.com/blog/wired-success/201012/why-we-love-bad-
news (Accessed 5 November 2015).
Acknowledgements
This free course was written by Magnus Ramage, Joyce Fortune, Neil Murray and
Mustafa Ali.
Except for third party materials and otherwise stated (see terms and conditions), this
content is made available under a
Creative Commons Attribution-NonCommercial-ShareAlike 4.0 Licence.
The material acknowledged below is Proprietary and used under licence (not subject to
Creative Commons Licence). Grateful acknowledgement is made to the following sources
for permission to reproduce material in this course:
Course image: © Exdez/Getty Images.
Text
Text in Box 1: Courtesy of www.incisivemedia.com.

Acknowledgements
Text in Box 2: Conlan T., Arthur C., ‘BBC Suspends Technology Officer after Digital Media
Initiative Failure’, 24th May 2014, The Guardian Newspaper.
Text in Box 3: Clarke, G. (2014) ‘£100m DMI Omni fail: BBC Managers' Emails Trawled by
Employment Tribunal’, The Register, 12 August 2014, © The Register, http://www.
theregister.co.uk/
Every effort has been made to contact copyright owners. If any have been inadvertently
overlooked, the publishers will be pleased to make the necessary arrangements at the
first opportunity.
Don’t miss out
If reading this text has inspired you to learn more, you may be interested in joining the
millions of people who discover our free learning resources and qualifications by visiting
The Open University – www.open.edu/openlearn/free-courses.

Successful It Systems Printable

Uploaded by

Copyright:

Available Formats

Successful It Systems Printable

Uploaded by

Document Information

Original Title

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

Successful It Systems Printable

Uploaded by

Copyright:

Available Formats

Successful IT systems

About this free course

2 of 45 Friday 7 June 2019

3 of 45 Friday 7 June 2019

4 of 45 Friday 7 June 2019

1 Success and failure in IT systems

6 of 45 Friday 7 June 2019

1.1 A successful system

Box 1: A successful IT system – pub chain Mitchells & Butlers’

7 of 45 Friday 7 June 2019

1.2 A failed system

8 of 45 Friday 7 June 2019

Box 2: A failed IT system – the BBC Digital Media Initiative

9 of 45 Friday 7 June 2019

1.3 Reflecting on success and failure

10 of 45 Friday 7 June 2019

11 of 45 Friday 7 June 2019

2 The sociotechnical nature of IT systems

1. A system is an assembly of components connected together in an organised way.

12 of 45 Friday 7 June 2019

2.1 Approaches to systems thinking

13 of 45 Friday 7 June 2019

What is important to me about sociotechnical systems theory is that it provides

14 of 45 Friday 7 June 2019

2.2 Components of an IT system

Figure 1 The main components of an IT system

15 of 45 Friday 7 June 2019

3 Understanding success in IT systems

16 of 45 Friday 7 June 2019

The Manchester-based organisation’s [i.e. the Co-operative Bank’s] finances

17 of 45 Friday 7 June 2019

3.1 What is a successful system?

18 of 45 Friday 7 June 2019

3.2 Criteria for judging success

● objectives not met

Millions of Natwest customers were left unable to withdraw cash or make

19 of 45 Friday 7 June 2019

3.2.1 Surveys of IT success

● meets user requirements

Meets client’s requirements 96 81 102 279

Completed within schedule 68 62 48 178

Completed within budget 43 38 34 115

20 of 45 Friday 7 June 2019

Meets quality and/or safety standards 28 28 14 70

Yields business and other benefits 23 8 23 54

Causes minimal business disruptions 6 14 9 29

Is capable of adapting to internal and/or 6 7 12 25

Delivers the best value possible 1 9 0 10

Provides strategic or operation learning for the 3 0 4 7

Facilitates leading the organisation into future 0 0 5 5

Delivers enhanced reputation for the 0 0 2 2

Which of the criteria in Table 2 is an accountant most likely to be most concerned

21 of 45 Friday 7 June 2019

Table 3 Distribution of projects by implementation status as classified by

Unsuccessful Successful but Successful and

Successful and 0% 0% 20%

22 of 45 Friday 7 June 2019

4 Stakeholders in systems success

23 of 45 Friday 7 June 2019