How good Change Management can still sink ships

RMS Titanic departing Southampton on 10 April 1912

The sinking of the Titanic has become synonymous with epic failure, brought on by ego and arrogance.

But if you look at the immediate actions of the crew, you’ll find a fairly rapid and well orchestrated response to a (Emergency) Request for Change.

The Titanic Story (in short)

The lookouts were perched high in the crow’s nest scanning for danger. History has it they were without binoculars, doing their best to fulfil their duty as early warning. Captain Edward Smith was a well seasoned and decorated captain with the right experience and background to captain such a mighty ship. Though other ships had reported icebergs in the area, and it’s irrefutable that he was aware of the dangers, his orders were full steam ahead.

When the lookouts first spotted the infamous iceberg, they immediately sounded the bell and notified the bridge. First Officer Murdoch order “hard astarboard!”, signaled full stop, and then full reverse. All executed with speed and practiced precision.

And then they waited anxiously to see if the helm responds in time – if the changes will turn this mighty ship in time to avert disaster. Less than a minute later; impact, and the rest, of course, is history.

The parallels to IT Service Management are helpful in understanding the difference between Change Management and Change Enablement.

Change Management

Traditionally, Change Management focused on quickly and effectively implementing business-required changes without producing negative business impact. (“screw it in, not up”)

Much of the focus of Change Management is on risk analysis and management to avoid adverse impact – “protecting the business”. Change Management typically views success as implementing the requested technical feature or service (application updates, new IT services) without problems.

ITIL defines Change management:

The goal of the change management process is to ensure that standardized methods and procedures are used for efficient and prompt handling of all changes, in order to minimize the impact of change-related incidents upon service quality, and consequently improve the day-to-day operations of the organization.

Let’s take an example we’re all familiar with. I’d hazard a guess that most IT organizations have upgraded their mail servers recently. In the process, most of us defined the desired result of the change to be successfully upgrading to Exchange xx with minimal user impact. It was most likely justified by increased security, supportability, and new features.

How many upgrade efforts were driven and measured by the enhanced capability and improved productivity of business users? Would we even know how to measure that, and if we did, would we see that as our responsibility, as a Critical Success Factor for Change Management. Or are we more likely to view that as “their concern”. Ours being the successful implementation of the technical requirements, leaving the business with some-assembly-required to produce value.

In the case of the Titanic, there was an immediate need to change course. Using established systems and processes, they quickly implemented the needed change. It was implemented with precision, and the change was, by traditional measure, successful.

But the outcome was far from successful, by any reasonable measure. And yet, IT organizations the world over defend their contribution by declaring they have successfully implemented the technical part of the change, as requested, with no negative impact. Success.

Change Enablement

But we all know the end of the Titanic story. Disaster. Failure. Even though the ship’s Change Management processes quickly and effectively implemented the desired change, the result was catastrophic. It didn’t achieve the desired outcome.

Change Enablement, by contrast, seeks to ensure the business actually realizes the desired outcomes – the results the business envisioned when changes are requested of IT. It evaluates and identifies additional success parameters, and establishes transition plans to ensure the desired outcomes are achieved.

Change Enablement includes organizational Management of Change required to achieve the desired business result.

Senior leadership (including IT) is charged with ensuring the resources under their care are aligned with the business objectives of the organization. If they are not, leadership is not fulfilling it’s obligation to the stakeholders, for which they will be held accountable. (Governance)

Implementation of needed changes is but a minor component. Change Enablement focuses on the entire organization’s capability to achieve outcomes. It includes people (the right skills, knowledge and experience), processes (working together as a system to maximize effectiveness, and directly aligned with the business), technology, relationships and organizational structures required for success. Everything from viability of the business’s long range planning strategy, the formation of effective tactical plans to achieve, and the organizational capability to deliver.

Change Enablement needs traditional Change Management, but is laser focused on the larger whole. And in the end, it’s the business results that count. Like the Titanic, the IT crew is on the same ship, and if the ship sinks, it’s bad for us all. It’s not like we’re safely on another (IT) ship. We are, quite literally, all in the same boat together.

For Titanic, Change Enablement would include investments in better early warning systems – night vision, radar, GPS, etc. Improvements in real time analysis and controls for determining appropriate speed for given conditions. Analyzing the ship’s design and engineer improvements to the ship’s ability to more quickly change course.

The road ahead for IT organizations is an even greater role in enabling the business to meet the ever increasing demands on their organization. ‘Change Enablement’ is no longer the high minded double speak of elite management consultants. IT can no longer faithfully implement changes in isolation and declare success.

If you think about it, Change management, as described, is essentially playing to not-fail. Whereas Change Enablement is playing to win. Business requires an IT who can help them win the larger battle – Change Enablers who help deliver meaningful business results.

What a great time for IT Service Management!

Image credit

4 thoughts on “How good Change Management can still sink ships”

  1. I see many similarities in the way we traditionally define success for Project Management: On time and on budget. The reality, of course, is that no one remembers whether the implementation project was on time or on budget 6 months after implementation. I always advocate for there to be a defined business objective for any project management effort, and that the primary measure is whether the defined benefit was achieved. You might think of that as scope, but even scope usually just defines what should happen by the end of the project (Exchange server is upgraded) rather than a business benefit.

    I managed my previous employer’s transition from Office 2003 to Office 2007. My defined goal was that business users should experience at worst neutral impact on productivity 1 month after the upgrade, and overall improved productivity 3 months after the upgrade. I was measuring by surveys of randomly sampled employees. Not a perfect measure, but far better than just “on time, on budget”.

    That being said, it’s a bit unfair to dump the sinking of the Titanic on ineffective change management. Change management did not cause the sinking, it just didn’t avoid it. Change management isn’t supposed to be about determining the best time to make a change. If I wait to get an oil change until my car has passed 20,000 miles since the last change, when the car breaks down just after leaving the repair shop, it’s not the fault of the change management process. ITIL does address this already within the Service Transition processes, just not with Change Management. The scenarios you describe sound like bad Asset & Configuration management, and bad Service Portfolio management.

    Isn’t Change Enablement just another term for Service Transition, and more specifically Release Management within Service Transition?

  2. I agree change management is playing ‘not to fail’ though with the concept of Change Evaluation in ITILv3-2011, where value is looked at before and after the change, perhaps ITIL at least is moving towards leveraging the change process to help drive value also. Change Enablement as you describe is typically driven through programme approvals from Service Portfolio Management through Service Design and Transition. The Programme approvals board is really a CAB for project/programme/strategic changes so a ‘play to win’ CAB is perhaps already catered for in ITIL, maybe just not articulated clearly enough.

    That all said, I don’t agree that the Titanic is a robust example of ‘good change management sinking ships.’ The emergency process was invoked too late to prevent a major incident; early warning systems (iceberg reports) had been repeatedly ignored; the major incident / crisis management procedure was not proven (a test scheduled had been cancelled) and a nearby ship failed to follow correct practice to come to the rescue. There were also design flaws (water tight sections not water tight or high enough, faulty rivets which prematurely tore, literally ‘unzipping’ the hull) which change management wouldn’t realistically have been able to spot – change is more concerned that testing has been done per the plan, not second guessing the test strategy.

  3. Thanks for the great comments; you bring up excellent points!

    The origin of this article is my long term challenge with helping IT organizations start seeing the bigger picture. I started with the image of the Engine Order Telegraph (EOT) – the round indicator a ship’s bridge uses to communicate changes to the engine room below.

    The EOT in this most elemental form, is little more than an effective way to quickly communicate enumerated changes. Titanic was equipped with an EOT, and I envision the swift response to ‘all stop”, the ‘ching ching’ to call attention to the change, and the immediate response from below.

    I certainly have no intention of blaming Change Management for the sinking. That’s missing the point. The point I want to make is that effective Change Management (especially as classically defined and widely practised) alone is insufficient.

    I agree with Dan completely (Service Transition/Release and Deployment Mgmt). Unfortunately, far fewer organizations have effective Release processes than have (traditional) Change Management.

    Meanwhile, especially at the C level, companies are facing incredible pressure to align every resource toward delivering the business outcomes they require. The outcomes with which the Board is concerned are large and very strategic – new markets, increased profitability, enhanced product development, etc).

    Outside ITSM, “Change Enablement” is emerging as a growing consulting trend to help organizations achieve and maintain these outcomes.

    Accenture has an excellent article at:

    (Definitely not an endorsement of Accenture)

Comments are closed.