Process Management and Improvement – Page 12

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.

Battle of the change methodologies

If you want technology changes to be successful you need an effective change management process. If you want a business change to be successful you need organizational change management.

For years, this similarity of names for very different processes was confusing.

Now it’s a good idea.

ITIL, in case you’ve never run across it, provides a comprehensive framework for understanding IT’s moving parts, how they fit together, and how IT management should handle them.

In the land of ITIL, change management is how IT operations takes the finished modules produced by dev teams and moves them to the test environment where software quality assurance can have its way with them, and from there into production.

Meanwhile, in another part of town, the folks responsible for OCM have been making sure the business areas that will be affected by the new software are properly prepared and ready to embrace the coming change.

The point of ITIL change management is to make sure software changes don’t blow up the IT production environment. The point of organizational change management is to make sure process changes that are the reason for software changes don’t blow up the business production environment.

They’re different things. One is about IT. The other is about the business. What could possibly go wrong?

Once upon a time, the answer was, not all that much. So long as the end-user training schedule coordinated so it preceded software’s move into production but not by much, there wasn’t much harm in considering these to be independent responsibilities.

But now we have DevOps, with its delivery model of continuous integration and continuous delivery — in some cases dozens of changes every day. As applied to a company’s internal systems, we’re talking about a potential mess, and not a small one.

The core of the problem is that DevOps as usually described is only appropriate for software companies and B2C eCommerce systems. These are the situations where software delivery is the same thing as business change.

For software companies it’s the same as business change because the direct result is an improved product, and the desired business change is the improved product.

Software delivery is the business change for B2C eCommerce systems, too. The purpose is to get the cash register to go ching more often and with more in the shopping cart. Yes, shoppers might get a slightly different experience each time they visit Amazon, ThinkGeek, or pick-your-shopping-site, but so what? On-line shoppers expect this and don’t get thrown by it.

The rest of the time, software delivery enables but doesn’t accomplish the desired business change. It’s a necessary but not sufficient condition for the change to happen.

If the difference isn’t clear, imagine you’re a sales rep. IT in your company has embraced DevOps, including continuous integration and delivery throughout the applications portfolio.

You use the company’s CRM system to keep track of which customers you need to contact, when, and about what. Only with DevOps everywhere, every time you open the CRM system you see a different screen layout.

Not what you’d call a dynamite productivity enhancer. Also not something you’ll find discussed very often in the DevOps literature. (I haven’t seen it discussed at all, but I’m sure I just missed it.)

The fact of the matter is, different business areas have different natural change cadences. All aspects of business change have to be orchestrated to match that cadence, from process redesign, to metrics redefinition, to deploying new equipment, to training, and to putting new and changed software into production.

And oh, by the way, even what sounds like the same old stuff really isn’t, because back when the theory for all this was being developed, work was performed by employees sitting at desks in cubicles at a company facility.

In the increasingly permeable enterprise, some affected employees work remotely, some remote and on-site workers aren’t employees at all, and some work has been shifted out of the business entirely. It’s been turned into customer self-service processes, and believe me, the folks who work in what used to be called Purchasing but is now Supply Chain Management aren’t going to have a lot of patience when the screens they use change without warning or preparation.

And so, a modest proposal: Get rid of most of the superstructure. Define projects and initiatives in terms of the desired business change, include coordinated work streams that cover all aspects of putting the change in question into production, and instead of yet another committee to speed things up (yes, the irony was intentional) just incorporate whatever the Change Advisory Board would otherwise do into project governance instead.

Simpler is, after all, usually better.