Achieving organizational change | IS Survivor Publishing

Previous Post: / Next Post:

Achieving organizational change


Achieving intentional business change calls for six interlocking disciplines.

By Bob Lewis | August 1, 2016
Topics: App Dev Methodologies, Industry Commentary, Organizational Effectiveness, Process Management and Improvement, Project Management, Strategy and Tactics | Comments Off on 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:

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.

Comments are closed.

my photo

Visit our store to buy books authored by Bob Lewis.

my photoBob Lewis is a senior management consultant with Dell Services. He has published these columns once a week in one form or another since 1996.

Disclaimer: All opinions, statements, representations, allegations, images (if published) and anything else that appears here is the sole responsibility of the author. Dell has and had nothing to do with it, other than saying it's okay to continue publishing KJR.

Recent Posts