The Change Equation

Chapter 1 : Introduction, cont...

You can download and print this chapter from here

Background to INPACT

Are you old enough to remember the London Ambulance Service computer fiasco? They introduced a new computer system in the early 90's which was going to really speed up the despatch of ambulances. The new system turned out to be so inefficient that response times actually got worse. In fact, shortly after its introduction, the system failed completely and the service reverted to the previous manual system.

Or were you, like me, forced to change your holiday plans in 1999, because your new passport never arrived? The Home Office permanent secretary was forced to admit that computer problems meant that targets for handling cases would not be met. He said that the introduction of new technology had been expected to lead to cost-reducing staff cuts but had led to such a "set of disasters" that 300 extra officials were now being taken on.

Only last year, the government admitted that while the NHS National Programme for IT had achieved some successes, taken as a whole, it had failed, with only “ three wheels still on”. Putting it back on track would take “ the next decade ” , not just the next year.

And I have just read the Commons Public Accounts Committee report that called the prison service's C-Nomis programme “a spectacular failure – in a class of its own”. This was supposed to give prison and probation officers real-time access to offenders' records but it got so complicated that it never got finished.

These are only the cases that make the headlines. My neighbour's MFI kitchen failed to arrive a few years ago because the company's new inventory system crashed. The £50m system was supposed to improve things for the company but they ended up paying a £30m bill to sort out problems with customer orders and fix the system. They never really recovered from that disaster. Or another example from the private sector: my insurance company failed to send me the documents I needed because their merger with another company had left their systems in a total mess. It took them 3 months to catch up – I didn't ask how much that had cost them.

Why is it that IT-based change projects so often fail to deliver the expected benefits? And what is needed for them to succeed?

This was the puzzle that I needed to solve two years ago, while working as a management consultant in the UK public sector. I was aware that many of the modernisation and change projects that I was involved with were not achieving their goals. Take-up of the new processes in the departments was agonisingly slow, the promised efficiency benefits could rarely be proved to have been realised, lots of money was being spent - with often very little to show for it.

This came to a head when, at a meeting to review the status of e-procurement in the public sector, I found that there was widespread agreement among procurement managers that the promised revolution had still not been realised, and that was four years after the first systems had been launched. I wondered why. The usual excuses (lack of time and money) didn't seem to be sufficient. What were the real reasons for this failure? And were they particular to the sector and the type of project?

Apparently not:

• In 2008, a McKinsey survey [1] of 3,199 executives around the world found that only one transformation in three succeeds, confirming what John Kotter found back in 1999 when he did the research for his book “Leading Change”. And when Harvard Business School tracked the impact of change projects among the Fortune 100 companies, they also found that only 30% of projects produced a positive bottom-line improvement.
• Standish Group , an IT industry market research company, carries out an annual survey of project outcomes [2] . Their findings show that project success is rare. In 2009 only 32% of projects succeeded and this was DOWN from previous years (it was 35% in 2004). Their data showed that 24% of projects failed and 44% partially succeeded (“challenged”). Projects over-ran their budgets on average by 45%, their projected delivery times by 63% and they only delivered 67% of the expected functionality.

Digging around for further evidence I came across a recent survey of change programmes in over 400 European organisations quoted by Prof. John Oakland , Emeritus Professor at Leeds University Business School . He also found that 90% of change programmes faced major implementation problems and only 30% delivered measurable business improvements.

This was worse than I had expected. Surely, if the IT industry and management consultancy companies were aware of these high levels of change project failure, they would be doing everything they could to improve their performance, but when I quoted these statistics to a number of people responsible for project management and efficiency improvement in public and private sector organisations, they only nodded and agreed.

So I started asking people for their take on the problem. I thought I had some of the answers already. My background includes 17 years as a manager in BT and 13 years as an independent consultant, including 8 years running a best practice experience-sharing group where major UK companies shared their knowledge and ideas about e-procurement and e-business.

These companies knew that problems arise when there is too much of a focus on the technology, instead of on the business benefits. It's called “technology push”. They knew that projects often failed due to poor specification of the systems or the lack of sufficient due diligence on supplier capability. They could quote examples (privately!) of the lack of senior management championship of the project or project managers leaving half-way through an implementation. And they could all point to the inability of system users – that's you and me - to articulate what they need. (Well, how can we, if we don't really understand what the new systems do?)

There was no shortage of reasons for IT-based change projects to fail, or at least to fall short of delivering the expected benefits. But I was not satisfied that these answers were sufficient. Something more was going on, to block change and undermine these projects. After all, we have known about these ‘standard' answers for a long time…

I started to read anything and everything published about project failure and uncovered some other common factors in my research:

• Unclear objectives and lack of recognition of the complexity of the project, leading to allocation of inadequate resources to deliver it. So the IT Director thinks he has consulted, but ask anyone outside his department, and they will give you a different answer.
• Not enough attention paid to process detail. That can be a killer if, as happened in a large London hospital, the new prescription system didn't have a field on the form for ‘possible allergic counter-indications'.
• Old manual processes continuing to be carried out in parallel with the automated ones. Think about it. What is easier: to learn how to input the job request online while dealing with all the non-standard requests that the new system can't handle, or just to carry on doing it all on paper as you always did?
• Lack of attention to training and not enough support for fine-tuning of the new processes and systems to enable realisation of the full benefits. When was the last time you got enough time and support to really learn how a new system worked?

And finally:

• A culture of non-compliance – that's usually the show-stopper!

None of these were ‘rocket science', but, together with the ‘standard' responses, they came up time and time again. And it didn't seem to matter whether the projects were in the public or private sectors. What they had in common was that the projects were attempting to bring new IT-based systems and modified processes into large, complex and devolved organisations, to improve efficiency and quality of performance.

I looked for a pattern - how did these factors stack up to give me a coherent picture?

I went back to look at all the management science I had acquired over the years, the best practice guides I had researched and written, the models and tools I had come across, inherited, created or adapted along the way, to see whether I could find some answers…

…and what emerged was an underlying idea and a set of models and tools that seemed to fit together and began to answer some of the questions.

I labelled this INPACT , which stands for:

Integrated Process and Culture Transformation

‘Integrated', because it became clear that the underlying reasons why change and transformation projects do not deliver the expected benefits have to do with how organisations handle both Process and Culture. Often the problem is that too much attention is given to the first (Process) and insufficient attention is given to the second (Culture).

Bob Garratt , the management consultant, creates a useful distinction in his book: ‘The Twelve Organizational Capabilities ' [3] .

Here's how he puts it:

“There is a ‘soft' side to organisations, which comprises human energies, emotions and learning which…are rarely measured. Yet they affect dramatically organisational effectiveness – the external perception of the organisation by its customers, suppliers and other stakeholders. These ‘soft' aspects are the missing key determinants of short-term and long-term organisational capability and performance.”

So an organisation's efficiency relies on its systems and processes whereas its effectiveness comes from its people.

There is an inherent tension between the demands of the organisation's focus on efficiency through systems and processes, and the needs of the individual, the ‘culture' or ‘people' focus. I propose to label these: EXTERNAL and INTERNAL. They form two axes, between which a pendulum swings.

The point of balance should be mid-way between EXTERNAL and INTERNAL, between ‘Process' and ‘Culture', between the organisation, its systems and processes; and the individual, their attitudes, motivations and aspirations.

Because there is an inherent tension between the demands of the organisation and the needs of the individual, between a ‘process' view of the world and a ‘culture' or ‘people' focus, the pendulum swings to the left and right, depending on which force is stronger. It rarely remains for long at the ‘point of balance' required to achieve excellent performance. Maintaining balance takes effort and skill. It is fragile and easily disturbed.

One of the main causes of imbalance is change. It requires new systems and processes, new skills and often new people. I will return to the concept of the pendulum. It is a useful way to describe the underlying philosophy behind INPACT, which is that an integrated and balanced focus on people and process throughout a change or transformation project is essential for success.

As I started to work with the INPACT models and tools, I noticed something interesting: I was able to use them to carry out quite accurate assessments of an organisation's capability to manage a change project and get the planned results. These assessments didn't take long – just a few days, sometimes only a few hours. INPACT turned out to provide a useful set of insights into the underlying areas of potential failure and the barriers to success.

For example, working with a Business School MBA course to research potential causes of project failure last summer, a simple questionnaire based on the INPACT approach quickly identified real disparities between what project managers were telling us about their projects and what other stakeholders thought about them.

And as part of a post-implementation review of a new system for an NHS Trust, I used INPACT tools to demonstrate that the lack of take-up of the new system was due to an almost complete lack of trust between the clinical and IT people in the organisation.

So I spent some time developing and refining the assessment approach, until I had narrowed it down to just a few key aspects. In an INPACT assessment, each is considered in turn:

First, I look at the organisation's capability , including:

• The strength of its organisational culture – attitudes and personal relationships, motivations and habits, aspirations – on the internal axis
• The business process capability maturity of the organisation – that's jargon for how consistently and well the organisation manages its routine work – on the external axis.

Then, having assessed the organisation's capability, I look at the project – what they are trying to do. This might be a specific change project or an enterprise-wide transformation programme. I look at four aspects:

• Clarity of objectives – as I found out in my work with the Business School MBA course, that is often a stumbling block, right at the start.
• Complexity. So you think your project is simple? Think again. This is often a real eye-opener for even experienced managers.
• The effect of distrust – I didn't believe how absolutely it blocked progress in that NHS Trust.
• The pull dynamics of benefits realisation. No, I'm not going to explain this – you'll just have to wait and see!

Finally, I include any other factors that may have a significant impact, such as suitability of an IT system or the relationship with partners and other external stakeholders.

So: an organisation's organisational culture + management of its processes = its Capability. What it is trying to do = the Project.

Think of these forming an inverted triangle:     

Focusing on the elements in each of these in turn enables me to simplify the task of identifying the factors that really made a difference to project success. I can then integrate them to quantify the barriers and understand their potential impact on the bottom-line benefits of the project. So the large red blob in the illustration represents the gap between success and failure – a gap that can now be measured.

And that's the Change Equation - the ‘big idea' that this book is about.

Read on...Objectivising the risks

[1] ‘Creating organizational transformations: McKinsey Global Survey Results', The McKinsey Quarterly journal, August 2008

[2] Extreme Chaos, The Standish Group International, Inc 2009

[3] The Twelve Organizational Capabilities: Valuing People at Work – Bob Garratt 1999