Eight to Late

Sensemaking and Analytics for Organizations

Archive for August 2012

On the politics of enterprise software implementation

with 10 comments

Introduction

Project managers who have worked on enterprise system projects will know that the hardest problems to resolve are political rather than technical. Moreover, although such stories abound they remain largely untold, perhaps because those who have lived these stories are not free to speak about them. Even case studies in academic journals tend to gloss over political issues perhaps out fear of offending their hosts. Consequently there are not very many detailed case studies that focus on the politics of enterprise software customisation / implementation. In this post I summarise a paper by Christopher Bull entitled, Politics in Packaged Software Implementation, which describes a case study that highlights the complex and messy political issues that can arise in such projects.

Background

Given that IT tends to attract people with a analytical bent of mind, it is not surprising that those who plan enterprise scale system implementations focus on technical issues rather than politics. On the other hand, there is fairly rich research literature on the politics of system implementation.

In the paper, the author presents a short, selective review of the literature. The main point he makes is that the implementation of information systems is political because such systems are catalysts for organizational change.  Some stakeholders may perceive benefits from certain changes whereas others will not.  Given this, it is likely that the former group will be advocates for the system whereas the latter will not. Accordingly each side will present arguments that  support their stance and these arguments will necessarily have a social/political dimension. That is, they are about more than just the technology.

A common way in which political behaviour manifests itself is as a resistance to the proposed changes.  The author mentions that there are three theories of resistance, one each for origin / cause of resistance

  1. People-determined – in which resistance arises from a fear of change that is inherent in the human psyche.
  2. System-determined – wherein the change is resisted because the system is perceived as deficient or not useful.
  3. Interaction – where the system is seen as forcing a change in the culture and norms of the organisation. This is particularly the case for enterprise systems which tend to impose uniform work processes that are driven by the head office of an organisation, often to the detriment of efficiency in regional offices and subsidiaries.

Information systems academics tend to borrow heavily from other areas of the social sciences. It is therefore no surprise that there have been attempts to view the social aspects of information systems through the lens of Marxist theory.  The parallels are obvious. Firstly, there are several different classes of people – management, developers and users – each with their own interests. Secondly, there are obvious inequalities in the distribution of influence and status between these groups. Case studies partially support Marxist theory – but I reckon this will not be a surprise to most readers.

The author points out that there are many different theories that can be used to make sense of social and political issues in information systems implementation.  However, most of these tend to focus on one or another factor, overlooking others. In real life, political issues arise from diverse causes some of which may even counteract each other! The true value of focusing on the political aspects of system implementation is to gain an understanding of the causes of conflict and thereby develop techniques to alleviate them. It is here that case studies can be particularly useful because they allow researchers to study issues as they develop and thus developing an understanding of why they are happening and what could have been done to prevent them.

The case study

The study was carried out in a midsize, UK-based manufacturing company. The author noted the organisation had a hierarchical management structure with work organized by department.  Interestingly, although management believed that communication between departments was good, other employees did not necessarily agree. Nevertheless, staff members were loyal and the company had a very low employee turnover rate.

The company was facing increasing pressure from competitors and had recently lost some key accounts. Management realised the organisation would need to become more proactive and responsive to customer needs, and this realization prompted the decision to implement a Customer Relationship Management (CRM) system.

The first decision that needed to be made was whether to build or buy – i.e whether the system should be built in-house or purchased.  This decision has a political dimension as organisations often go down the “buy route” when they want to reduce the influence of their internal IT departments. However, building a CRM system is a huge undertaking and the IT department did not really want to be doing this.  So the decision to buy rather than build proved to be popular with both IT and business staff.

Although the decision to buy the system was not contentious, the process of implementation turned out to be messier than either party had foreseen.  Some of the problems mentioned by the author include:

  1. The project team (which was appointed by senior management) was widely thought to be unrepresentative. Groups that were not represented felt that their concerns would be ignored. Moreover, some felt genuinely threatened. For example, external sales staff (who were not included in the team or in project planning) felt that the system was intended to replace their roles.
  2. The steering committee was jointly headed by the IT and sales managers. This caused friction – the sales manager thought it undermined his authority whereas the IT manager viewed it as an unnecessary imposition on his time.
  3. Different departments had different views of what the system should do based on their respective departmental interests. Since it was difficult to achieve consensus, management engaged external consultants to assist the project team in requirements gathering and system sourcing/implementation.
  4. The consultants and IT had an adversarial relationship from the start. IT believed the consultants were biased towards a particular CRM product. There was also significant disagreement about priorities.
  5. Senior management appeared to trust the consultants more than the (internal) team members. This caused a degree of resentment and unease within the project team.
  6. Groups well represented on the steering committee (internal sales, in particular) were able to have say in how the system should work. Consequently, other groups felt that their concerns were not adequately addressed.

As a result of the above:

  1. Those who felt that their concerns were not addressed adequately indulged in delaying tactics.
  2. The project created a rift between employee groups had been homogenous in prior times. For example factions formed within the Sales Department, based on perceptions that certain groups (internal staff) would be better off after the system was implemented.

Moreover, effective use of the software entailed significant changes in existing work practices. Unsurprisingly, most of these changes were viewed negatively by employees. Quoting from the paper:

…new working practices were contentious because they were perceived to be unreasonable and unrealistic, particularly the scheduling and allocating of work for others. There were also complaints by certain sales staff that individuals who managed tasks at the beginning of the business chain would benefit considerably from those employed elsewhere because they were unaffected by internal organisational bottlenecks. Finally, the increasing number of surveillance features contained within the packaged system was resented by many sales support staff because of the pressures arising out of the increasing ability for managers to monitor and judge individual performance.

It is clear from the author’s description of the case study that those responsible for the project had not foreseen the political fallout of implementing the new system.

Lessons learned

I suspect the lessons the author draws from the case study will be depressingly familiar to many folks who have lived through a packaged software implementation.  The main points made include:

  1. Senior management failed to consider the effect that the existing political tensions within the organisation would have on the project.
  2. There was no prior analysis of potential areas of concern that front line employees may have.
  3. There was a failure to recognize that the composition of a project steering committee will have political implications. Groups under-represented on the committee will almost always be resentful.

In short: new systems will almost always reconfigure relationships between different stakeholder groups. These reconfigurations will have political implications which need to be addressed as a part of the project.

Summing up

The paper details an interesting case study on the political effects of packaged software implementation, and although the paper was written well over a decade ago, many of the observations made in it are still very relevant today. I suspect many readers will find that author’s analysis and conclusions resonate with their own experiences.

The take-home lesson in a line is as follows: those implementing a packaged software system would do well to pay attention to existing relationships between different stakeholder groups and understand how these might be affected by the new system.

Written by K

August 16, 2012 at 10:26 pm

Five blogs I read regularly

with 2 comments

I have to confess I don’t read many blogs. My excuse is that work leaves me with little time to write and even less to read. So I have to ration out my reading time, most of which  goes into making inroads into the pile of books and papers I have collected over the years.

Nevertheless, there are a handful of blogs that I make it a point to read every week. Here they are, in strictly alphabetical order:

Better Projects: Craig Brown’s short and insightful posts delve into the foundations of project management theory and practice.  My favourite posts from his blog are this one on questioning the utility of a very popular project management methodology and this one about how respect for individuals can make life easier for both employers and employees.

Cleverworkarounds: Paul Culmsee is one of those rare people who is as much at ease writing about technical matters as he is with the softer stuff. He weaves wonderfully entertaining stories as he explains and educates. If you have not read him before, head over to his blog and check out his recent series explaining the mysteries of SharePoint performance. Don’t be put off by the title, it’s a worthwhile read for anyone who has ever asked the question, “Why is that system so slow?”   Another brilliantly entertaining and educational piece is this one on Monte Carlo simulation.  (Full Disclosure: Paul is a good friend of mine and we’ve co-written a book)

Herding Cats: Glen Alleman is a highly experienced project manager who has worked on mission critical projects involving manned spaceflight (among other things). His no-nonsense posts on risk management and the use and abuse of statistics in project management have educated and inspired me to write on these topics. My favourite posts on Herding Cats include Statistics and  Misrepresentations of Knowledge and Uncertainty and Risk.

Quantmleap:  Shim Marom is a kindred spirit who writes about many things interest me and that I write about (but he does it much better than I ever can). He can pack into two paragraphs things that would take me twenty. A couple of must-read posts from his blog are: A Letter to a Young Project Manager  and  Don’t be afraid to connect with your touchy-feely side.  Shim’s posts on the softer side of project management provide a counterpoint to Glen’s process and technique oriented articles.

Tim van Gelder: A philosopher by training, Tim van Gelder helps individuals and organisations improve the quality of their thinking and decision making. I learn something from each one of his posts.  Check out this post on why opinion polls are of dubious value and this one about a serious gap in business intelligence systems.

These blogs offer terrific insights into how organisations, projects and systems work, or should work.  Each of them has influenced my thinking and given me a fresh perspective on what I do and write about.

%d bloggers like this: