7

The Seven Change Disciplines

We have a “strategic” plan. It’s called doing things.

—Herb Kelleher, cofounder, Southwest Airlines

Interlude: A Case of Good Intentions Not Being Good Enough

My employer, a regional storefront business, wanted to grow and transform, to emerge as a national and Digital player. Its executives wanted to expand their brand by offering new products and services beyond the company’s existing regional locations.

The company’s leadership and overall culture came from its long and successful history of transacting business in small customer-facing storefronts. Brand awareness and acceptance were consistent with the culture and solid among customers and employees. That heavily influenced internal operations, which was fully aligned with the small storefront operating model.

Which meant all of the above were badly misaligned with the vision of expanding into a new national and Digital business. The successful regional business practices, which were supposed to serve as the foundation, were, in fact, major barriers.

For example, the new business model called for centralizing product operations, bringing them in-house from external providers, and moving to a modernized internal service platform. From the outside it looked like a win all the way around—save costs, bring all serving in-house, and improve the customer experience for all consumer business products.

Some existing business products were already serviced internally, so integrating the rest didn’t look like a huge challenge.

Except that they were supported by a decade-old software application. That’s where the problems started. Operational processes were designed to cope with the limitations of the outdated application but had been “how we do things around here” for so long that few employees even recognized they were dealing with an accumulation of workarounds.

Thus, the reason why the new operations processes and supporting software were needed wasn’t obvious to the employees on the front lines who had successfully provided top-notch service over the years. The storefront environment and accumulated workarounds were baked into their unconscious assumptions of how the world was supposed to be.

That was in business operations. In IT, the new application called for a move from Waterfall development to Agile, and a move from traditional application architecture to a services-oriented approach. As anyone who’s worked in IT for any amount of time knows, these two moves are as culturally disruptive as the move from horses and buggies to automobiles.

And then . . . the transformation program teams lost the vision. Under cost and deadline pressures they turned into independent siloes of their own.

The result: what had started as an elegant federated data model ended up breaking information management and decision support. The architecture was focused on the technology modernization and not on end-to-end solutions designed with business operations and integration in mind. The siloed technology solutions were stood up with limited success, but the end-to-end integration suffered.

The rollout delays were the least of the program’s issues. Far worse was that without the end-to-end integration, the customer experience— the company’s competitive advantage when it was a regional storefront-based company—was lost in the shuffle.

In the end, the biggest missing pieces were leadership, project management, and organizational change management. The company’s leaders failed to keep the purpose of the changes in the forefront of everyone’s minds; project management allowed individual teams to turn into uncooperative siloes; and the complete lack of organizational change management led to a widespread failure to see that the vision was broader than a technology modernization effort—it was a complete change in how the company defined its marketplace and competed in it.

Eventually, the program delivered: IT figured out more than Agile and modern application design—it bought into the idea that these weren’t just IT projects. Business operations staff got the hang of providing excellent service from a remote, centralized location, and decision-makers began to value the analytics they could get from a clean and consistent information repository.

But it sure would have been easier if these were skills and capabilities developed in the beginning of the change, instead of being lessons learned at the end of it.

Close your eyes and imagine a collection of colored balls connected by springs (or keep your eyes open and look at figure 4).* That’s your organization—the one you’re trying to change in some way, shape, or form.

FIGURE 4 A metaphor for organizational change resistance.

Now imagine you grab one of the six balls and try to reposition it. Depending on how strong and tight the springs are, this shouldn’t be all that difficult a task.

Repositioning that ball represents the change you’re trying to achieve.

Now, let go of the ball. What happens? The entire organization returns to its pre-change state.

Changing an organization is hard. Not because “people just naturally resist change” (they don’t) and not because figuring out what needs to change and what it should change to is hard (although it is).

It’s hard because as someone once said, all organizations are perfectly designed to get the results they get.¹

Which is to say, organizations, like most other systems, tend to evolve toward stable configurations. And it’s the nature of stable that change gets resisted.

Most of this book has been about what needs to be done differently for intentional change to happen. But there’s more to changing an organization than figuring out what has to be done differently and what it has to change into. This final chapter discusses, at a very high level, seven disciplines organizations need to master to make the intentional change, whatever it happens to be, both real and sustained. These disciplines are, in no particular order, leadership, business design, technical architecture management, application development or integration and configuration, organizational change management, implementation logistics, and project management.

One at a time …

Discipline #1: Leadership

As the old joke has it, there once was a man who had a dog with no legs. Every morning he had to take it out for a drag.

Leadership is the art of getting others to follow. For managers and executives who haven’t mastered the art, getting the men and women in their organization to do what they’re supposed to do is a tiresome drag, day after day after tedious day.

Leadership consists of eight responsibilities: setting direction, delegating, staffing, making decisions, motivating, managing team dynamics, establishing culture, and communicating, which includes listening, informing, persuading, and facili-tating.²

In case the critical role leadership plays in achieving organizational change isn’t clear, consider this: organizations are complicated, with a lot of moving parts that have, as noted above, coalesced into a stable configuration that works.

No change fiddles with just one of the moving parts. On top of this, every change destabilizes what used to be stable and requires a lot of hard work on everyone’s part . . . not only the project team’s members, but everyone . . . to make the change successful, deal with unexpected ripple effects, show the initiative needed to make sure everything continues to work during the interim, and, in the end, coalesce into a new configuration without jeopardizing the next organizational change, whatever it happens to be.

Employees who have to be dragged along aren’t going to get the job done. “Leaders” who try to make the entire change happen without help aren’t going to get the job done either.

Leadership is what changes the metaphor. With effective leadership, employees don’t have to be dragged—they help pull the organization into its new configuration at maximum velocity without daily prompting.

And they go further, providing leadership themselves, figuring out the details and taking care of them without any need for managerial intervention.

One more point about leadership: as noted in the introduction, many organizations segregate themselves into a collection of squabbling siloes, or more accurately, castles with moats and drawbridges to control the flow of work in and out of them while maximizing the autonomy of each castle’s owner to set direction and make decisions.

If executives and managers see themselves as leaders of their siloes, the company will be able to achieve intentional change within each silo just fine.

Strategic change? Probably not. To accomplish strategic change, those responsible for the various business units and functional areas . . . and beyond this, every manager, and beyond even this, every employee . . . have to see themselves as leaders of the whole company, focused now but not forever on a particular part of it, but motivated by the success of the enterprise as a whole.

Breaking down organizational siloes and keeping them broken down calls for unceasing leadership on the part of the company’s top executives.

Discipline #2: Business Design

“Follow me!” we might imagine an inspiring leader crying to the troops.

“Where to?” we can easily envision the troops answering back.

“I don’t know!” is a very bad answer.

Business design is about creating the answer—about designing the organizational change, whatever it is, completely enough so everyone involved can understand both the change itself and their role in it.

We covered business design in some depth in chapter 2. Business design excellence is self-evidently not just one of the critical organizational competencies needed for intentional change to take place but the first: if you don’t know what the desired future state should look like, it will be awfully hard to make it happen.

Discipline #3: Technical Architecture Management

What technical architecture management is: an arcane but necessary IT function responsible for establishing the design and engineering guidelines needed so that the collection of applications, information repositories, and underlying platforms and infrastructure assemble logically and efficiently so as to support the organization’s processes and practices.

Before we get started, readers who aren’t in IT might be forgiven for thinking they can skip this section. Doing so would be a mistake. Yes, technical architecture management is an arcane discipline, some of whose practitioners make it far more arcane than necessary.

But technical architecture management, done well, greatly reduces the viscosity that’s the all-too-common result of unman-aged, accidental technical architecture. Handled poorly, it ossifies IT, turning it into a major change bottleneck instead of a facilitator.

And, as handling technical architecture well requires investment, arcane or not it’s everyone’s business, not just that of a handful of folks working in a back room churning out white papers.

Which gets us to the starting point: in our view the usual approaches for enterprise technical architecture management, built around documentation of the current state, a complete design of the desired future state, and a linear road map for moving from one to the other, share all the deficiencies associated with Waterfall application development as explained in chapter 3.

Only they impose these deficiencies on a much wider scale.

An instruction manual on how to manage technical architecture is far beyond the scope of this book and would require an entire book to do the subject justice.

For this book’s purposes, effective technical architecture management calls for IT to follow three key principles.

Principle #1: Each Application Obeys the Rules of Correct Data Design

If you aren’t educated in the ways of information technologists, you don’t need to know what this means. You just need to know that it matters, and why.

Why it matters: getting data into and out of an application with a poorly designed database can be miserably hard, and even harder to validate.

Bad data design is the problem behind a vendor being listed as, for example, “IT Catalysts, Inc.,” “IT Catalysts Inc.,” and “ITC,” depending on the transaction record and who entered it.

It’s the reason that a new address for one of your customers makes it into only some of your databases.

It’s why you receive mailings from credit card companies offering you an introductory rate of 0% APR when you already have one of their credit cards, for which you’re paying quite a bit more.

Increasingly, mining your data for meaning is critical to the success of your business. When data are inconsistent . . . when your databases disagree with each other . . . mining isn’t just difficult. It’s likely to give you an inaccurate answer to your questions.

Principle #2: Integration Engineering Is More Important Than Anything Else IT Applications Manages

As already discussed in chapter 3, most businesses, most of the time, buy or rent (that is, license or subscribe to) applications rather than building them internally.

But commercial applications come with their own databases and don’t come with clean boundaries between themselves and the other commercial applications you have in play.

As a result, more than one application often manages overlapping information. A simple example: your CRM system keeps track of your customers; so does your accounts receivable system.

So, to some extent, do your social media analytics, if your business is such that you have customers who hang out on social media and you want to know what they’re saying about you.

Now imagine your customer is a business, and it moves its headquarters. You have to make the change in two systems. Not a big deal, except that, as IT folks like to say, it doesn’t scale.

Instead, you need software to keep the two systems’ data synchronized.

Which might not seem like much of a problem. And it isn’t when you have just two systems with overlapping data. Large, modern enterprises, though, might have two thousand or more applications with lots and lots of data overlap.

This leads to what some companies call their “interface spiderweb,” others term “spaghetti,” and those with the worst architectures and most honesty describe as their “IT hairball.”

Whatever the name, we’ve seen IT shops that have more than a thousand separate custom data synchronization programs they have to run, in precise sequence, each and every night.

Imagine deploying a new application into an environment like this.

Replacing the hairball with clean and maintainable integration engineering is the most important, and strangely enough the most ignored, priority in technical architecture management. From the perspective of intentional business change it greatly reduces IT viscosity—that is, the sometimes enormous effort IT has to expend to make sure it hasn’t broken anything when deploying and integrating the new software a business change depends on.

Principle #3: Every Project That Touches the Technical Architecture Leaves It in Better Shape Than It Found It

The problem IT has in improving the technical architecture is that doing so costs money and consumes capacity. Which means any project whose sole purpose is cleaning up the technical architecture has to compete for budget and staffing with other projects that require information technology but whose purpose is to achieve immediate intentional business change and improvement.

And so, with all the best of intentions and elegance of design, closing the gap separating the current state of things from the ideal future state the technical architecture folks have designed never happens.

The solution: don’t even try to charter a separate technical architecture improvement roadmap. Instead, insist that every project that touches a company’s portfolio of applications, databases, and underlying platforms and infrastructure move things in the right direction (right as defined by the technical architecture function) instead of doing more damage.

For example, we talked about the importance of integration engineering. A project that adheres to principle #3 would retire the point-t o-point custom interfaces associated with the application being modified with connection to whatever integration engineering solution you’ve settled on.

Not your entire interface hairball. Just those interfaces the project in question has to deal with anyway.

Discipline #4: Application Development / Application Integration and Configuration

There is, we’ve all agreed, no such thing as an IT project. They’re always about business change or what’s the point? But while projects should always be about business change, it’s equally true that most business-change projects place demands on a company’s information technology, and in particular its portfolio of business applications.

At some stage of the proceedings, IT has to deliver new applications or make changes to the ones already in use so as to support the new way of doing things.

Probably tens of millions of how-to words have already been published on this subject. There would be little point in adding more. Two key points to complement them:

•   Implementing packages isn’t the same as developing applications from scratch. We covered this point in chapter 3 (Fixing Agile). Briefly, when you build from scratch you have to list the features you need and build them. When you buy a package they’re already built. You need to converge them with your business processes.

•   The benefits from handling integration well last a very long time. So does the pain of handling it wrong. We talked about this earlier in this chapter.

When it comes to achieving intentional business change, IT’s goal is to avoid being the bottleneck. That’s a key reason for mastering Agile techniques. It’s a key reason for fixing your integration architecture.

More generally, it’s a key reason for you to look at everything IT does and to remove everything you can that slows IT down.

Discipline #5: Organizational Change Management

Consider the curious case of Who Moved My Cheese,³ probably the most popular and most misguided book ever published on the subject of change resistance. Its message to employees is (plot spoiler alert!) your cheese is going to move. Get over it.

That’s to keep them from asking the logical and obvious questions: (1) Who decided to move the cheese, and (2) why are they messing with us for no good reason?

Real business changes have more moving parts to them than just a simple cheddar repositioning. With a more accurate metaphor, not only will employees find the cheese somewhere different from where they’ve learned to find it, but it’s now Gouda instead of cheddar, and oh, by the way, employees now have an entirely different labyrinth to navigate before they can nibble on it.

And one more thing: there’s a rumor going around that when someone does find the cheese, it will be nestled in the middle of a mousetrap.

People don’t just naturally resist change. As evidence, we offer the smartphone. If that isn’t evidence enough, while not everyone embraced the internet the moment the World Wide Web became real, it’s pretty clear “people” didn’t resist it.

Before that, the consumer electronics industry invented the compact disc, which was quite successful right up until streaming music services like Spotify also didn’t meet with much resistance.

What confuses many business leaders on this subject is a straightforward distinction: while people don’t just naturally resist change, they do just naturally resist change they expect will be bad for them. And as most business changes over the past four decades have had, as their centerpiece, one or more rounds of layoffs, employees’ likely response to the next business-change or transformation program is going to be the expectation they’ll be playing Whack-A-Mole once again, and they won’t be the ones with the mallet.

If you still aren’t convinced, imagine that instead of the change you’re promoting and its consequences for employees, you’re offering to give each of them a new car of their choosing, complete with five years of unlimited fuel, maintenance, and insurance. Think they’d all resist that change?

Neither do we.

To be fair, not everyone embraces every change immediately. Not everyone owns a smartphone; some of us are annoyed at the increasing number of things we used to do on personal computers that now require us to connect to the cloud; those of us with longer (but less reliable) memories often annoy those for whom our current events are taught as history in today’s high schools by insisting that their use of social media is inferior to the pen pals a few of us had when we were young.

But few people reflexively resist any and all changes. Mostly, when employees (or anyone else) resist change they do so because they expect the change to be bad for them personally. Those who don’t want smartphones might be insecure regarding their ability to figure them out; those who resist moving their data to the cloud might also be concerned about their ability to figure out how to make it all work or might have legitimate concerns about its security.

Even if the long-term result might be beneficial, the short-term transition to the changed situation might, as in knee replacement surgery, be painful enough to drive an unhappy reaction.

Which brings us to the first law of organizational change management: to the extent possible, design every business change so it leaves employees better off than they were before the change happened. That is, the individual employees, not just the organization but the men and women who do its work.

This in turn brings us to the first corollary of the first law: when you can’t design a change so it leaves employees better off than they were before, at least design the change program so employees who support the change see a path to surviving it.

And it brings us to the second corollary of the first law: if a change is good for the organization but isn’t good for anyone in the organization who’s in a position to help drive the change . . . well, good luck with that.

This isn’t the place for a complete guide to organizational change management. If you need one, check the endnote.⁴ Somewhere between the first law and a complete methodology are a few critical tricks o’ the trade:

•   Turn likely resisters into owners. Figure out which stakeholders and stakeholder groups are likely to dislike what you have in mind, and find ways to involve them as active participants, even if you expect their participation to be annoying or disruptive. As LBJ reportedly said, better to have them in the tent spitting out than outside the tent spitting in.*

•   Find the systemic barriers. Organizational resistance isn’t limited to human beings who don’t want it. Lots of structural factors can get in the way as well. Everything from facilities, to metrics, to your compensation system, to the chart of accounts Accounting uses to classify financial inflows and outflows . . . and let’s not forget the organizational chart . . . can interfere as well. Figure out what they are and figure out how to change them or otherwise minimize their impact.

•   Provide training and support. A common and reasonable reason employees resist some changes is that they’re proficient in how to do their work right now. That makes them concerned they won’t even be competent once the change takes place. The means for addressing this should be obvious.

•   You can’t communicate too much. When it comes to organizational change, ignorance isn’t bliss. Quite the opposite, it’s a source of anxiety. Let everyone know what’s going on, not only when you launch and when you finish, but all along the way.

Discipline #6: Implementation Logistics

Organizational change isn’t something you can just dump on an organization and hope those it’s dumped on can figure out how to sort it out and make it work.

The usual approach is to start implementation with a proof of concept, pilot, or both.

Our advice about proofs of concept: don’t bother.

Your average proof of concept addresses the simplest case that has to be dealt with, and that in a scaled-back fashion. It’s a case the current systems and practices most likely handle just fine without the planned change.

A good proof of concept, in contrast, affects relatively few people, but otherwise includes most of the complexity of the actual rollout, only in miniature.

Which makes good proofs of concept indistinguishable from pilot implementations.

So start every business change implementation with a well-chosen pilot, giving it a lot of attention and support. Most important, view everything that goes wrong during the pilot as a positive event, as it’s an opportunity to avoid similar problems when you start rolling out the change to the broader population.

Another recommendation: to the extent possible, turn change implementation into a machine—a team whose members know the drill because they’ve done it before and know they’ll have to do it again.

This is especially true for changes that have to be deployed to a large number of different but similar locations, but it’s also something to strive for in other implementations as well.

Whatever else, with most implementations the organization will find itself operating in a hybrid state for a significant period of time. This is usually as unavoidable as it is painful. The logistics plan has to prepare the organization so that everyone affected pitches in to make the transition work.

Discipline #7: Project Management

Projects are how change happens.

So if projects are how change happens, the critical role project management plays in achieving intentional change should be clear.

Businesses have no shortage of resources to draw on when it comes to project management methodologies.⁵ Our purpose here isn’t to provide a summary. It’s to provide some guidance outside the methodologies themselves. Here’s what you, as a change leader, need to know about project management:

•   What it is: Project management is the means through which everyone involved in a project knows what they’re supposed to do, when they’re supposed to start doing it, and when it’s due. And it deals with situations that cause deviations from the plan.

•   What it also is: Project management is the discipline of figuring out the work that has to get done in order to produce whatever the project is supposed to produce. It ensures that if everyone does what they’re supposed to do, when they’re supposed to do it, delivering the results when they’re due, the project will deliver what it was supposed to deliver.

Very important: While project management is the discipline of figuring out the work that has to be done, this doesn’t mean the project manager is the one who has to figure it all out. Quite the opposite. The project manager should, in consultation with SMEs, figure out the big blocks of work. Project team members should figure out the details, because (1) they’re better equipped to do so, and (2) the plan is now their plan and not something the project manager has foisted on them.

•   One more thing it is: Goaltending. That is, when it comes to project management, great ideas are the enemy of success. They’re the source of “scope creep”—not the creep who moved my scope, but unfunded and unscheduled additions to what a project team has to deliver.

The changes in scope themselves aren’t the problem.* They become a problem when the team is supposed to just squeeze them in. A vital part of project management is enforcing the “Nothing Is Free” rule.

A note about how Agile fits into this picture. The answer is, easily, because with most Agile variants, proposed changes in scope are expressed as features added to the project backlog. Once they’ve been added they’re incorporated into the same priority-setting practices as everything else in the backlog.

•   What it’s the opposite of: Everyone waking up in the morning trying to figure out how to move the project forward today.

•   Culture leads again: Even the best project managers can’t succeed in organizations that lack a culture of project management, which is to say a culture that recognizes the importance of disciplined planning and execution and supports it.

Some companies still view project management as a “bridge position”—a way to give promising individual contributors some management experience, following which, should they succeed, they’re promoted to management. This is a bad idea for two reasons. First, projects are led by inexperienced project managers. Second, this practice prevents the organization from ever accumulating a cadre of experienced project managers.

As project management is one of the seven critical disciplines for achieving organizational competence at intentional change, we hope it’s obvious why the project manager role is too important to be relegated to being a mere bridge to something else.

Quite the opposite: as one of the most important management roles in the organization, it warrants its own career path.

One More Thing . . .

Mastery of the seven disciplines—of leadership, business design, technical architecture management, application development or integration and configuration, organizational change management, implementation logistics, and project management—is a necessary condition for achieving organizational competence at intentional organizational change.

But there’s a risk. As with anything else that appears on the organizational chart, those who provide these capabilities to the enterprise can easily turn them into bureaucracies and organizational siloes, protective of turf and squabbling over budget and influence.

To make it all work, mastery in isolation isn’t enough—the seven disciplines have to come together as an integrated whole, whose practitioners actively collaborate to make intentional change happen.

If You Remember Nothing Else …

Businesses that have mastered the art of intentional business change have achieved competence at seven core disciplines:

•   Leadership

•   Business design

•   Technical architecture management

•   Application development or integration and configuration

•   Organizational change management

•   Implementation logistics

•   Project management

What You Can Do Right Now

•   Assess the enterprise’s overall organizational competence in each of the seven disciplines. If the objectivity and expertise for doing so don’t exist inside the company, you might need to engage an outside consultant for this purpose.

•   Give whoever is currently responsible for each of the seven disciplines a copy of this book (sorry!) to start them moving in the right direction and to encourage them to start collaborating on making the enterprise adept at intentional business change.

•   Don’t try to fix everything at once and with the same executive focus and intensity. Apply the principles of this book for instituting a business that embraces the principles of this book.

* We know, we know. If you really closed your eyes, you wouldn't be able to read the rest of the instructions. Go with it.

* LBJ’s actual quote was a bit more colorful, but this is a family book.

* The legendary example, from Defense contracting lore, has the project manager answering, “Oh, you wanted wings on that plane?”