Strategy and Tactics – Page 34 – IS Survivor Publishing

Achieving organizational change

Are ITIL change management and organizational change management two processes or one (“Battle of the change methodologies,” Keep the Joint Running, 7/25/2016)?

Answer: No, they’re not. First of all, they aren’t processes. They’re disciplines — practices — or they’d better be, because making them processes courts disaster.

You already know why that is, but just in case: If you structure these as processes and implement them as processes, everyone involved will, in just a few short months, forget the point of it all and treat the process steps as checklist items instead. You’ll have added bureaucracy instead of achieving the “process” goals.

Second of all, between them ITIL CM and OCM are only a third of what’s needed to successfully change how an organization gets things done.

To reliably achieve intentional change, organizations have to achieve mastery … or at least competence … in six change disciplines: (1) business design; (2) application development/integration; (3) IT change management; (4) organizational change preparation; (5) change orchestration; and (6) project management.

One at a time:

Business design: This is where Lean, Six Sigma, Theory of Constraints, Next Best Action, and Service-Oriented Modeling live, not that this list enumerates your only alternatives. One way or another you have to be able to describe how the future is supposed to be different from the present in a way that makes clear what has to change.
Application development/integration: Well this is clear, isn’t it? Most business change calls for new or changed application software. What’s less clear is that how a business goes about choosing, installing, and configuring commercial software isn’t just like how it goes about designing and coding in-house-developed applications. The challenges are quite different. In this day and age, businesses have to master both.
IT change management: This is ITIL’s change management or something equivalent — how IT operations goes about taking application software changes provided by application teams and puts them into production without blowing up the currently-stable production environment and also without annoying everyone to death.
Organizational change preparation: Until very recently (until, that is, I wrote last week’s KJR) I called this discipline “organizational change management.” I don’t anymore because the work involved in what’s commonly called OCM has little to do with managing organizational change and everything to do with preparing the organization for change.
Change orchestration: Business change of any size and scope has a lot of moving parts. It crosses organizational boundaries, changes employee and management responsibilities, and otherwise needs to be deployed in a carefully planned sequence so that a premature change in one area doesn’t ripple downstream in ways that prevent work from getting done.
Project management: Yes, of course project management. The previous five disciplines generate tasks that have to be undertaken and completed in some sort of planned order by specific staff to which the tasks are assigned. Project management is how organizations keep track of the tasks and make sure they’re finished when they’re supposed to finish.

Take a look at this list without first-class optics and you’ll be forgiven for thinking it looks awfully waterfallish. It’s certainly easier to explain business change in waterfall terms: Design, build, deploy, in that sequence, with some ancillary disciplines thrown in to sand off the rough edges.

Interestingly enough, while it’s easier to explain business change in waterfall terms, actually implementing business change is a lot easier when you apply Agile concepts to the challenge. That’s because waterfall’s long-standing shortcomings don’t get any better when applied to business change instead of software development.

The shortcomings? There are two. The first is the difficulty of comprehensively designing big things and getting the details right when nobody has enough experience with it to provide suitable guidance. Imagine the challenge is designing a flying car. The early generations are likely to miss important features like “What’s underneath my car! I can’t see through the floor!”

Waterfall’s second shortcoming? It’s the risk of designing anything so big that by the time it’s actually built, the situation has changed and it’s no longer fully relevant.

Iterative, incremental business change is a lot less complicated to manage. Which doesn’t make it easy by any means. In particular, just because a business design evolves in small steps, it still has to conform to an overall plan. And just because the steps are smaller you still can’t ignore the six change disciplines.

There’s another challenge too — scaling.

No, not scaling the six disciplines up. In many respects the challenge for agile business change is harder.

You have to scale them down.

Apologies at Scale

Want to be part of the Digital Transformation? You’ll need a new capability. I’ve dubbed it Apologies at Scale.

Our story starts with Wink. My wife and I bought one of its hubs and a couple of Wink-compatible light bulbs for our lakeside cottage, to create the impression the place is occupied when there’s no one around. It worked fine, until one day when it didn’t.

Astonishingly, there in my inbox was an email, letting me know Wink had goofed. It had sent out a firmware upgrade that took Wink hubs offline. And because the Wink hubs were offline it couldn’t send out a revised upgrade to fix the problem.

The email apologized and offered to send me a pre-paid shipping box to send them my hub in so they could fix it.

Wink’s mistake was pretty dumb. Its recovery, though, was brilliant.

Unlike how Sling Media handled its decision to kill the Slingcatcher.

Sling Media’s Slingbox is a gadget that sends television signals across the Internet, where you can play them on a Slingplayer app, of which there are versions for (at least) Windows, Mac OS, iOS, and Android.

Or, once upon a time, you could use a Slingcatcher instead — a closed box with a Slingplayer app inside it that could connect to a standard television. This was handy for non-technical folks like my in-laws, who want to watch the news or Antiques Roadshow on a television when they’re visiting our lakeside cottage, not on an app on a computer, tablet, or smartphone.

Then, Sling Media upgraded its system, making the Slingcatcher incompatible, not that the company let its customers know so we could avoid wasting hours of effort in pointless troubleshooting.

Enter Amazon’s Fire TV, for which Sling Media provides a Slingplayer app. We got a Fire TV Stick, plugged it into the cottage TV, ran the Slingplayer app, and everything was groovy.

Until one day when it wasn’t. Out of nowhere the Fire TV Slingplayer app just wouldn’t run, even though the Slingplayer Apps for my Android phone and Windows PC worked just fine.

After an hour of screwing around I contacted Amazon tech support, which told me Slingbox had “withdrawn support” for the Fire TV. Adrenaline in my arteries, I contacted Slingbox tech support, which told me, no, it hadn’t withdrawn support. Amazon had changed something in its system that prevented the Fire TV Slingplayer app from working, their customer service rep told me.

I’m inclined to believe Slingbox on this one, as it had a new version available within a week that worked on my Fire TV Stick, not that it let anyone know it had fixed the problem it hadn’t let anyone know about.

We in IT spend a lot of our time and creative energy thinking about scale. If you’ve read anything at all about the Internet of Things and the smart products it connects to you’ll have read about the daunting scaling challenges it represents.

And these articles aren’t wrong. Sell, say, a million smart products. Figure each of them sends out a 1 KB data packet once a minute. The 20 MBPS of bandwidth that takes isn’t completely unmanageable, but the half terabyte per year of data that one product generates might need some attention.

And that’s just technical scale.

As products become smarter, they also become more bug-prone. Not only that — modern products have more in common with the Portuguese Man of War than with the jellyfish it physically resembles, jellyfish being independent organisms where the Portuguese Man of War is a colony.

Apps are colonies — at a minimum, in addition to their own code, they’re composed of the Internet, an ISP, external data, and a host OS, any of which can fail or become incompatible.

Then there’s Wink. Its whole reason for being is that it’s a colony — it unifies control of lots of different company’s home automation devices.

Anyway, Portuguese Man of War or not, your company’s name is on the product.

I’m willing to cut Amazon some slack. As of 2015 it was selling 488 million SKUs in the U.S. alone. Knowing one of them has developed a problem and which customers bought it is a non-trivial task, which is why I call it Apologies at Scale.

I have, on the other hand, no sympathy for Sling Media. It only has 18 SKUs to manage — four devices + 14 Slingplayer apps. Managing a QA lab to spot problems and sending out emails to registered users when there is one shouldn’t be all that challenging.

And compared to the cost of handling disgruntled customers dialing into its call center, a simple proactive email would have been cheaper, too.