Successful IT systems

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.

1.2 A failed system

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

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.

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.

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:

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.

Figure 1 The main components of an IT system

Show description|Hide description

Consists of three oval shapes arranged in an inverted triangle formation. Reading from top left going clockwise, the labels read: Technology, Organisation and People. An arrow links Technology to Organisation, and one links Organisation back to Technology. This is repeated for the Organisation/People and People/Technology pairs.

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.

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).

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:

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:

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:

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.

Hopefully you can see from the examination of this definition that complexity and ambiguity surround the notion of success and, indeed, failure.

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:

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.

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.

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.

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:

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.

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.

In the context of IT systems, Dix et al. (2004) provide a useful distinction between stakeholders. They identify four classes:

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).

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.

Figure 2 The power/interest grid

Show description|Hide description

This is a rectangle with axes divided into four quadrants. The axes each have an arrow head on the end.

The x axis is labelled Interest. It has two further labels: one placed to the left end of the axis labelled Low; the other placed towards the right end labelled High. The y axis is labelled Power. It has a further two labels: one placed towards the bottom of the axis labelled Low; the other placed towards the top of the axis labelled High.

The two upper quadrants read left to right:

• Keep satisfied
• Manage closely.

The two lower quadrants read left to right:

• Monitor (minimum effort)
• Keep informed.

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.

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:

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.

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.

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.)

Figure 3 System implementation power loop involving experts and professions

Show description|Hide description

Three rectangles arranged in a triangular formation, and with arrows linking between each in a clockwise direction.

Reading from the apex going clockwise:

A rectangle labelled Development and implementation of system.

An arrow labelled Shapes links to a rectangle labelled Control of implementation strategy.

An arrow labelled Defines links to the third rectangle, which is labelled Experts and professions.

An arrow labelled Influences links the third rectangle to the first.

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):

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.

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.

References

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.

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.