Menu Close
What are you looking for?
< All Topics

Change Management – The Impact of NOT Managing Change

Print Friendly, PDF & Email

Background Information

This case study shows the impact of not have a Change Management programme in place and how this can derail critical projects.

A major Middle-East Airline undergoing radical change undertook to implement an ERP Solution from a renowned software vendor, beginning in 2008. This Airline was in the process of reshaping in response to several market and political conditions, and many agreed that this change was indeed necessary, if not overdue. The Master plan was based on a decree by the Government to restructure the entire airline – from the top down –  over a 5 year period. At the heart of this change was an organisational unbundling of several key divisions, the final goal being to sell off portions to private investors. Suffice to say this organisation was in the throes of a major Change Undertaking.

There were a total of 12 new IT applications that were being implemented during this 5 year restructuring period. Many of the applications were being implemented simultaneously, and at times in conjunction with the overall organisational restructuring effort.  Due to the massive workload and the potential for failure, the Airline decided to contract a third party Project Management Office (PMO) to oversee implementation, management, integration and quality control. They were meant to be an autonomous body, wholly independent of the Airline or the various implementers.

At the outset there was no Change Management master plan in place for any of the IT projects. Instead it was decided that each of the application implementations would have their own Steering Committee (Steercom) that would drive the implementation from all aspects. The decision whether to initiate a Change Programme was therefore for each Steering Committee to decide. However, any Change programme that was decided upon at Steering Committee level would need the final approval of the Airlines Director General before being given the go ahead.

The ERP implementation consisted of a multi-phase, multi-national, multi-module implementation. The initial Scoping document for the implementation called for a three year multi phase project, managed through a very focused and intentional Change Management programme. In a decision to constrain costs it was decided that the complete programme would rather be implemented over an 18month cycle. The Change Management programme was largely diminished in an effort to keep costs and people-efforts under control.

The application implementer itself had undergone major organisational changes, in that it had recently been bought out by a major multinational IT company. The new entity had no experience in ERP implementations, and limited experience in mega-projects in theMiddle East.

The Proposed Change Management Intervention.

During the Project Proposal phase, the ERP application implementer proposed a basic four pronged Change Management programme. Their methodology was a blend of Prosci’s ADKAR® and PMBOK®. The roll-out framework was a template used in several similar sized projects that had successfully been completed in theMiddle East.

The four Change Initiatives were:

  1. Transition Management;
    • The process of measuring various impacts across the user groups, and proposing interventions to manage the matters that may prevent transition to the new system. The general state of individual site readiness fell into this aspect.
  2. Communication Management;
    • The entire communication programme would have been the domain of the Change Management teams. The communication programme suggested using various mediums (billboards, pamphlets, workshops, Townhalls etc) to communication the Vision, progress and impact of the ERP implementation.
  3. Risk & Issue Management;
    • Risks and Issues were to be identified by the Change Management team. This practical decision made sense in that the Change Team would have been in regular contact with all the Role Players and Stakeholders across the project spectrum. The Change team would not have been responsible to manage Issues or Risks, but rather they (the Change Team) would need to present these to the Project Management Office (PMO) for their intervention.
  4. Training;
    • The training programme proposed was a generic blended learning approach, with various phase-ins to coincide with the various project stages.

The overall Change programme was to be managed by a team of Change Practitioners, membership of the team would be a mix of external hired consultants as well as staff from various divisions within the organisation.

The Decision to proceed without Change Management.

The Change programme was not included in the overall pricing of the project implementation, it was sold as an add-on service. The cost was relatively high, and the client did not see a tangible or measurable return on investment. After much discussion it was decided to proceed without a formal change programme.

This decision was driven by the Director General who had recently moved to the Airline from another quasi-government organisation. This organisation itself had undergone a significant ERP implementation, a part of which was a very strong Change programme. The Director General had felt that the benefit had not been justified by the cost, and he did not wish to see the same project cost overruns on the current implementation. It was his decision that ultimately decided on the Change programme being cut from the implementation.

The final decision was to keep the Training and Risk and Issue Management programmes, each managed by separate teams. The implementer relented on the need to have a formal change programme, but eventually they acquiesced to the Airlines demands.

At this point the project moved into Phase 1 of the implementation, which was the implementation of the Finance and Procurement modules. The user group affected by this implementation was predominantly National, although there were three offshore offices that would be impacted by this phase of the implementation.

The outcome of the Implementation.

No formal measurements on the change impacts were made during any of the project implementation phases. As such there is no quantifiable data that indicates failure or success (moderate or otherwise). However it is safe to say that this first phase of the implementation was deemed to have had very limited success.

The Steering committee had stated unequivocally that there was no negotiating on the Cut-Over date, it was literally set in stone (a granite plaque had been made for the for the opening day ceremony).  There were numerous incidents in the 6 months leading up to Phase 1 Cut-Over that pointed to an imminent failure. At several points in time these incidents were logged and reported to the Project leadership of both the implementer and the client. All incidents were formally acknowledged but were largely ignored.

One incident in particular was the overwhelming sense that the end user populace were completely unaware of the project purpose, timing or general impact on their daily work. Further to this, the ERP project had coincided with a reduction in headcount, and so there began an overriding antagonism towards the new system. The lack of positive Key Messages did nothing to counter this pessimism.

It was only at the start of the Training programme that users began to realize to what extent they were to be engaged in the new system. This confusion and anger was exacerbated when many users were registered on ERP training courses that seemingly had nothing to do with their current job or role in the organisation; e.g. there were finance clerks registered on warehousing courses.

On the planned Cut Over date the new system was switched on, amid many concerns that the ERP system was in fact not ready for use. Several major design changes, and a user group that was under trained and misguided were the predominant causes of the application being under-utilised. In actual transacting began seven months after the Cut-Over date.

The overall perception within the organisation is that the ERP system was difficult to use, expensive to manage and of no real benefit to the organisation. Whilst this is not a quantifiable or measurable failure, it is a failure in itself; at the time of writing, most of the business processing at the Airline is being done outside of the system. A Third Party contractor has recently been brought in to the Airline to capture the extra-system processing into the ERP System. This would suggest reasonable grounds for failure.


There are many conclusions that can be speculated on. Based on the overall performance of the implementing team and the outcomes of the various phases, it is clear that even a rudimentary change programme would have lead to a better overall result. Even a simple communication plan would have brought the various stakeholders to a place of common understanding, and ultimately a united purpose.

Fortunately, many lessons were learned from the Phase 1 failure, and a Change Management team was hastily formed to ensure that the same failures were not present during the subsequent phases.

The first action undertaken by the Steering Committee was to constitute Change Teams across the organisation, and empower these teams to analyse and report back on Change Impacts. The implementers were charged with the responsibility to coach the Change Teams in their Key Responsibility Areas. Once these teams had been briefed they were dispatched across organisation to implement and manage a structured communications and impact analysis programme. Almost immediately the Project started receiving data that pointed to Change Gaps. By far the largest gap was a lack of clear communication between the Project and the Airline as a whole.

There was a limited budget for communication activities, and so the change teams had to use some simple yet creative means to put the Change Messages across.(e.g. bulletin boards, screen-savers, and mail-shots). The success rate was surprisingly high considering that the communication message itself was neither slick nor glossy. Yet the organisation as a whole responded positively to the programme. From the feedback received by the Change Teams, the Project was able to report on issues that they had picked up (e.g. Site Readiness, Training effectiveness).

The change programme as a whole was neither definitive or perfect, but by simply putting a programme of sorts in place, the organisation began to track the project in a more coordinated and effective manner. The lesson that all the stakeholders learned is that Change Management should never be a considered as a grudge purchase or an ‘unnecessary evil’. Much like publicity, even mediocre change programmes can have some positive effects.

Table of Contents