The Friday Roast - change management

Summary

Change management gets a bad reputation in large part because it routinely fails to address the topic of 'Why?' Addressing this through hierarchical and process maps doesn't help. 

The shame of it is that the large SIs know this only too well and have invented ways to circumvent the problem without jeopardizing their main feed source - The Technical Project.

Many organizations follow a Lemming Mentality to projects of which digital transformation is just the next iteration.

There is an alternative approach that holds considerable promise  in the form of mapping rather than box and wire representations. 

The Roast

Grab a libation of your choice, this is a long one.

Today, I'm kicking off an occasional series of stories under the moniker 'The Friday Roast.' These talk to topics that represent recurring themes in technology implementation, deployment and ongoing operations. They are aimed squarely at de-fluffing, de-cruffing, de-mystifying or just downright flaying of topics that line of business managers and IT often find annoying.

Today's 'victim' is change management, a topic inspired by a story penned by none other than a dear colleague, Vijay Vijayasankar, head honcho of channel at MongoDB, past SAP HANA wrangler and IBM'er.

Earlier in the week, Vijay penned a wee masterpiece entitled: Why am I not holding my breath on digital transformation ? which garnered a respectable 19 comments at the time of writing much of it between Estaban Kolsky and the author. Vijay notes that throughout his career, change management is a common part of many tech proposals but that it is often the first thing to get cut when budgets change. Vijay's position can be summed up as follows:

Since it is a competitive market – vendors don’t push back on it when customers choose to ignore change management , even if they know customer will probably fail .

What is lacking in my opinion is good articulation to customers on why they should invest in it . Lofty messages doesn’t help once you pass senior leadership at CXO level . Would it be too recursive to say change management needs some change management ?

[My emphasis added.]

Kolsky's argument is more nuanced:

A well reasoned post relying in an antiquated stance (“nothing ever changes”). Never thought I’d see this from you.

I have written tons. Explained it tons. And talked to many executives. The short answer to why now? Because in the past 5-7 years he amount of digital assets generated grew by magnitudes inconceivable (so large we devised a term for it – “big data”) and the ability to process it went up with it.

and...

You’re half making a point.

CRM, ERP, etc were roll ups of evolution. Digital transformation is the same. When CRM was first launched (and ERP and others) people also said we don’t need this evolutionary step. We have the technology to make the little changes we need. They were wrong then, and it took 5+ years to prove it. Look at the amount of change since the internet in late 1990s. Look at how many companies embraced all those changes somehow. How many need to do it now?

Roll up steps are what make it work by aggregating all the technology from the past 10-15 years into one consumable initiative.

Hype is always there. But ignoring the step and calling it hype when it has the markings of being an rollup step is being the old guy yelling at kids to get of the lawn! :-)

I get your point. And technology and business is iterative. But you won’t stop this rollup step from happening. Sorry.

All these arguments are sound and they make perfect sense in the context of the assumption that a project is needed and in motion. What neither participant in this discussion does though is go back to basics in an effort to understand what's really going on and why so many projects fail.

This is a topic dear to my heart as someone who has been on both the receiving end of change management projects, who has delivered successful and sometimes unsuccessful projects (batting 8/10 wins) but who has learned that nothing in life is simple although some of the underlying causes of failure are very simple to understand.

The Bell Curve is your best clue

The simple (sic) reality I see is best illustrated by the Bell Curve of technology adoption. Duncan Macleod provides us with a good starting point, for which see the image below:

 MacLeod talks about the following distribution:

1. innovators (2.5%),
2. opinion leaders or early adapters (13.5%),
3. early majority (34%),
4. late majority (34%), and
5. laggards or late adapters (16%).

In my rough and ready analysis of projects and technology adoption, I have the analysis simplified as to:

1. 20% innovators and early adopters
2. 60% 'in the middle'
3. 20% late majority/laggards

The exact percentages vary from technology type to technology type but I'm not going to disagree too much on this point. In similar vein, I am not going to disagree with those who say that adoption by the so-called mainstream doesn't really start until we're about 10 years into a technology life cycle.

What I am going to say though is that where I see technology most successfully adopted is at the extremes of the Bell Curve and often in the same time frames. In other words, while innovators and early adopters lead the adoption cycle, businesses and organizations that would typically be called laggards can also successfully adopt earlier than we might imagine. Why is this?

Innovators and laggards

Innovators and early adopters are what I term tinkerers. They play with and discard all sorts of technology and are natural hunting grounds for vendors.We can name many of these companies but examples include Coca Cola, Colgate Palmolive, BT, Morgan Stanley, GE, Wal-Mart, Harrahs...the list goes on but roughly equates to the Global 2000. Who among the vendor community doesn't have BT as a 'customer?'

Laggards on the other hand are harder to find. I say laggards in a different context to that described by the technology adoption Bell Curve. Here, I am thinking about companies in some sort of rictus inducing pain. These are companies that are failing for one reason or another and at risk of entering life support or being taken out.

Both types have one thing in common - they naturally adopt change management for one of two simple (sic) reasons. Desire or need. They rarely need armies of consultant to 'do' change management. Instead, they need people who can support the change management process which occurs naturally as a part of the adoption process in these business types. Who for example needed a bunch of change management consultants when they adopted Salesforce.com? Almost no-one. Why?

The why question?

Salesforce.com adoption is an interesting area of study. The company grew from persuading many small businesses that it had a better mousetrap to the CRM problem. Once it had established that user base, the company could market more loudly (as it frequently does)  and so attract the attention of larger businesses.

It is only recently that the company has moved more into the larger company space, in part because its portfolio of solutions has been considerably expanded in the last five years to be more complete and attractive for enterprise purposes.

So here's the really interesting thing - you rarely hear about failed Salesforce.com implementations. Why? There are many reasons but one of the principal ones I hear is that users like it. Personally, I think the UI is dated but it is still way better than the Siebel and SAP offerings it frequently replaces. And a good UI matters. Another reason is that it (mostly) gives people what they need to get the job done. So the answer to the fundamental question: 'Why are we doing this?' is often seen as self evident. And when something is obvious, then it doesn't make sense to resist.

Real life failure

So why do we hear about so many ERP failures? Again, there is a relatively simple root cause answer. While Kolsky may argue that ERP is an incremental change, it came with a big 'gotcha' in the shape of business process re-engineering. The underpinning management theory came with a huge promise.  Operational efficiency. In short, peoples jobs would disappear.

Anytime jobs are threatened outside of a period where there is obvious and significant pain translates into resistance. That's because the 'why are we doing this' question is never properly articulated or actioned upon. I recall when a System 34 was brought into my department. We smirked and joked as the programmers lurched from one crisis to another as armies of clerks dutifully and manually ticked off AR/AP listings. Eventually of course the system got running and jobs went. That was painful.

The management failure was easy to spot: they simply didn't bother to explain why we needed the new system, how it would benefit the business, what would be the consequences and how people would be managed during the inevitable transition. Result? We couldn't get anything meaningful from the system for six months. The employee purpose was simple - delay as long as possible. It worked although as is almost always the case, the best people drifted away.

What to do?

Simon Wardley has a very interesting take on what both drives change and how it can best be managed. See slideshare above. He argues that technology shifts arise out of commodification and the disruption that brings. History suggests he is right. We see it happening across broad swathes of industry. Media is a great example where today, thanks to blogs, Twitter, Facebook and other social media, pretty much everyone can be a publisher. That was unimaginable 15 years ago.

Yet time and again, we see organizations making a complete mess of their social media and content management efforts. Laura Ramos at Forrester makes a convoluted and overly wordy argument on this topic that is still worth the reading once you get past the litany of buzzwords. But the biggest problem she fails to answer is the 'why' of these new content approaches.

Unless organizations identify a clear purpose and need then they will fail.

Occasional contributor Euan Semple argues that 'bottoms up' implementations are a good way to go. He says of his consulting engagements:

Most of the time I take the view that if I can help even one person in those organisations to wake up, find their voice, and stand up to be counted then that is a good thing.

Sounds familiar? It's the Salesforce.com approach.

Yet more broadly in media we see tweaks on the ad driven business model which is so patently failing and yet media companies wrestle furiously with tweaks on the model. Why? I believe the answer is inside the Bell Curve where MacLeod describes the 'follow the herd' and 'stick with it' crowds - see above. Rather than understand the root cause for issues and address the 'why' of change, media businesses are simply trying to shore up old models. It represents institutional inertia of a kind that frequently stymies projects.

Wardley believes a part of the problem stems from the way we approach organizational problems. We kick off with what he calls 'box and wire' maps that fail to uncover why we are taking XYZ course of action. He argues (Slide 11) that once you strip out the 'what, when, how' pieces of a particular project you are left with a tiny, unanswered or vague 'why?'

He then goes on to demonstrate how, repeatedly over many years - and change management by the way is nothing new, it has a 50 plus year history as a topic of study - most businesses i.e. those in the middle of the Bell Curve, try to emulate someone else's success because they were successful. It is what some call the Herd Mentality. I prefer the Lemming Mentality. Wardley describes it as a lack of situational awareness where the why? and where? remains uncovered.

Wardley proposes that instead of using the box and wire approach to organization, we should use a mapping approach that emphasizes the value chains which exist internally and externally around ecosystems of organizations.

His argument is predicated upon the fact that organizations do not live in isolation  but in dynamic and competitive markets that can be seen as akin to a form of warfare. He says that the boxes of which we are all too familiar tell us little or nothing about the meaning that lies inside them.

I regard this as a matter of understanding context. And for those who have followed my writings over the years you'll also know that I say: content without context in process is meaningless.

Mapping people, things and processes allows management to see several things and it is at this point things get really interesting.

What next?

In Wardley's example shown above, what we see is a clear outline of where different things 'fit' inside the business as a whole. More important however, it tells us how things fit together based upon their purpose. That in turn allows us to see more clearly what needs to change and what doesn't so that you avoid the inevitable see-sawing that occurs in many change management projects to which Vijay partially alludes in his analysis.

Wardley goes on to describe additional uses for maps such as process comparison in adjacent organizations, communication and risk assessment. Crucially, he argues that maps allow organizations to learn about what works and what doesn't in their unique environment.

Critically, Wardley suggests that none of this require consultants but does require some learning around the techniques involved. In other words, Wardley believes most organizations can be self sufficient in understanding their needs provided they have the right way to view the business in the context of its environment.

Finally, Wardley helps us understand the impact of inertia (see diag above.) Here, he draws upon the experience of Kodak, which while first to discover the value of digital imaging and online photos, but which failed because inertia in its fulfillment process stood in the way. It is a superb example how leadership was plucked from Kodak's grasp as a result of a failure point that management failed to address. In short, it failed to change where it really mattered.

Verdict

1. Wardley's approach is not a panacea but it does help us start the process of addressing the 'why?' question.
2. The fact that organizations should be able to develop the maps Wardley describes is a useful first step in managing change, not because it is any easier but because it is self imposed rather than something that is done 'to' the organization.
3.  Nothing is quite as simple as it seems and therefore there is always the prospect of failure.
4. SIs should be looking hard in the mirror and asking themselves the question: 'What the heck have we been doing all these years?'

Related stories

• The Foundation Components For Digital Transformation (enterpriseirregulars.com)
• Upsetting the digital transformation apple cart (diginomica.com)
• Customer experience and digital transformation - a diginomica review (diginomica.com)