Eight to Late

Sensemaking and Analytics for Organizations

On the politics of enterprise software implementation

with 10 comments


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.


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

10 Responses

Subscribe to comments with RSS.

  1. Great article Kailash, the lessons are so appropriate for any large change initiative. Stakeholders want to be involved and feel that their input has been listened to.



    August 17, 2012 at 1:00 pm

    • Hi Ken,

      Thanks for taking the time to read and comment. I think you have summed up, in one line, the essential message of the paper.





      August 17, 2012 at 8:11 pm

  2. Hi Kailash,

    Loved reading this. Thanks.

    I have spent about 7 years working with clients implementing enterprise wide project management systems, within the 10 years since the paper was written…and I can tell you that nothing has changed significantly, except maybe the functionality of systems.

    From my perspective I related very well to the points made in the paper. I would add a few practical and hard learned extras for anyone that reads this blog with the view of implementing a similar system.

    1) Culture Change
    I agree with the paper. The chief point is that an enterprise implementation is about cultural change, not technology change. Software can be installed usually in less than a day and configured from vanilla very quickly if the design has been thought about. If it hasn’t, its still pretty easy to create a frankenstein that will lurch along resembling a useful system (Serious Risk). Focus on the culture change, and the configuration requirements will flow from this.

    2) Take your Time
    Whilst the technology might be quick to install, the roll-out cannot be big bang. I mean cannot, not should not. This is from experience. Even with good change management, and solid training, acceptance and seeing the new system as ‘a normal, everyday part of my working life’ takes a while…because people take a while to change generally. Plan a road-map of functionality releases based on the understanding of the change you are undertaking. Expect that this road-map will change as a result of people learning more about the system as you implement more functionality. They will most likely start very uneducated about what the system can fully do, so initial responses to inform your roadmap will be based on shaky knowledge.

    3) Finance milestones aren’t project milestones
    Following from point 2. Plan that you might need to invest over financial year boundaries. Just because you have funds to spend before the end of FY, doesn’t have any correlation to project success!

    4)Long Term Sponsorship
    Related to 2 and 3 – If you want an enterprise implementation to be successful and you are going to take the time to do it, ensure that whatever senior management are sponsoring the implementation are either there for the long haul, or committed to handing over to their successor fully to give continuity of both support and more importantly….understanding.


    Hope this saves someone somewhere some pain.

    All the very best



    Ross Andren

    August 22, 2012 at 1:52 pm

  3. Hi Ross,

    Thanks so much for reading and for your insightful comment.

    IMO some of the blame for the neglect of cultural/political issues associated with implementing enterprise software lies with vendors who are less than honest about the challenges involved. On the other hand, some of the responsibility also rests with decision-makers in organisations that purchase these products. These folks are sometimes (often?) all too ready to “outsource their thinking” to vendors, consultants and implementation partners who claim to be implementing “best practices.”

    Your points about time, money and commitment are also worth noting because they are often forgotten in the hurly-burly of an implementation.

    Thanks again for reading and taking the time to comment- I truly appreciate it.





    August 22, 2012 at 9:13 pm

  4. The larger the organization the more red tape there seems to be. Major enterprise software implementations impact so many different departments with different expectations that’s is practically impossible to please everyone. Someone almost always feel like they got the short end of the deal. There will always be internal politics, the question is how does your team overcome them!?


    Nancy Beckman

    August 31, 2012 at 2:54 am

  5. Hi Nancy,

    Thanks for your comment. You are absolutely right – it is impossible to please everyone on enterprise software projects. Indeed, politics is a consequence of the fact that such projects have a social dimension because they affect diverse stakeholder groups who have different (and possibly conflicting) interests. These projects, therefore, share many of the characteristics of wicked problems that are common in areas relating to social planning. For example, I have written a post describing how datawarehousing projects are wicked in many respects.

    In recent years it has been recognised that many organisational problems (other than those relating to Enterprise IT) are wicked. Such problems cannot be solved in the conventional sense, but they can be managed. The key to managing these problems is to get all stakeholder groups to a shared understanding of the problem prior to embarking on a solution. This addresses the issue of politics upfront. There are techniques that can be used to achieve this, but unfortunately they are not so well known in the world of enterprise software or indeed, in mainstream management.

    I hope you will forgive me for indulging in a bit of a plug here…Paul Culmsee and I have written a book that delves into some of the reasons why software projects are wicked and why conventional methods of handling them exacerbate these issues instead of addressing them. More importantly, we also present a bunch of techniques that can be used to manage such problems, backed by case studies covering projects ranging from town planning to organisation-wide knowledge management initiatives. In case you are interested, sample chapters are available on the book website and on Amazon.

    Thanks again for reading this post and for taking the time to comment.





    August 31, 2012 at 10:53 am

  6. These posts are fantastic (just came over here from a link on CleverWorkarounds…)
    I’m in the middle of my first major enterprise system implementation at a medium-sized manufacturing company, and am having a difficult time geting to any kind of shared understanding of what the problems really are.
    The issue here is the tech is out of date and no longer supported (in most cases), so that seems to be blinding everyone to the real meat of the problems.
    There is an everpresent response of “the system can’t support X yet, so why change Y?” to every attempt to start changing the culture to prepare people for what is to come (this change is on the order of a rotary phone to an iphone).
    What are some tricks for peons to make sure management does not fall into these traps?



    September 20, 2012 at 11:12 pm

  7. Hi Chris,

    Thanks so much for reading and your kind remarks. Also, my apologies for the delay in responding.

    I understand exactly the frustration and pain you are going through, as I suspect many others will too. Getting to a shared understanding across an entire organisation is extremely difficult – it is hard to get a C-level executive to see the world from the perspective of a front line employee.

    That said, there are some nice techniques to get people to alter the “lens” through which they see their world. Most of these techniques consist of asking questions that get people thinking about the wider consequences of the initiative being considered, be it an enterprise software implementation or an organisational restructuring. Some examples of such techniques include, Soft Systems Methodology, Breakthrough Thinking and Dialogue Mapping.

    I hope you’ll forgive a plug here: Paul Culmsee and I have discussed some of these problem structuring techniques (and the conditions required to use them successfully) in our book. Of course, many of the techniques are also described at length in other books, papers and web sites.

    Thanks again for reading and for your comment…and all the best with your project! Do stop by again when you get a chance.





    September 22, 2012 at 9:58 am

  8. Thanks for this article, I stumbled here from Linkedin and have found it very intersting, I am looking at some potential research into the management and development of projects within ever changing legislative and regulatory compliance environments – one of teh thngs I want to look at is the impact on the management of risk and think that you and others in subsequent posts have given me some food for thought.



    October 16, 2013 at 9:22 pm

    • Hi Julia,

      Thanks for reading and for your feedback. IMO, the ever-changing list of rules and regulations increase risk rather than decreasing it, primarily because risk managers focus on complying with the rules rather than actually managing risk. Michael Power’s work (which I’m sure you’re aware of) explores this point. I have summarised one of his papers here.

      Thanks again for stopping by. All the best with your research!





      October 17, 2013 at 6:53 am

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: