Introduction

What You’re in for When You Read This Book

If you board the wrong train it is no use running along the corridor in the other direction.

—Dietrich Bohhoeffer

This is a book about achieving intentional business change.

It’s also a book about why your company should never again charter an IT project. The two statements are opposite sides of the same coin.

In planning this book we had two alternatives. We could have taken one or more of the various business process improvement methodologies as our starting point, incorporating information technology change into them.

Or, we could have started with the current crop of IT methodologies, enhancing them so their purpose isn’t to deliver software products anymore but to make business change happen, and happen as intended.

It was no contest. Here’s why.

First and foremost, in most businesses IT takes project management (the discipline of making tomorrow different from yesterday) far more seriously than most of the rest of the enterprise. As a result, its methodologies are more detailed and mature than those devoted to business change, as are its practitioners.

Second and almost as foremost, the largest slice of most companies’ business change investment pie chart is generally the spending needed to make the necessary changes and enhancements to the applications’ portfolio.

And third, modern IT project methodologies are all about making IT projects better at adapting to changing conditions. The current crop of business process improvement methodologies are, in contrast, mostly about making businesses more efficient at what they did yesterday and will continue to do tomorrow.

So while this book is about achieving intentional business change, it starts with information technology and works its way out from there. It’s a better place to start.

But just to start.

A Parable

IT implements and runs software. Business managers use the software to help them get their jobs done. IT supplies, the rest of the business consumes. What’s the problem?

Here’s one: by turning IT into a supplier of products and services used by the rest of the business, we create a covert conspiracy of failure. It works like this:

There’s little that enhances a business executive’s career more than envisioning and advocating bold, transformational change. And whether or not anyone wanted to admit it, most bold, transformational business change has, for the past several decades, required new or transformed information technology.*

And so the business executive becomes the project’s business sponsor for either developing or buying, integrating, and configuring the new information technology.

Or, if it’s an Agile project, the project’s product owner.

Meanwhile, on the supply side of things, there’s little that enhances IT’s reputation better than developing slick, sophisticated software, with the likely exception of IT installing, integrating, and configuring a slick, sophisticated software package.

So far, so good. IT and the rest of the business are, as the pundits like to say, in alignment.

As it turns out, they’re often in better alignment than anyone suspects, because while advocating bold transformational change is a career-enhancing move among business executives, actually pulling the trigger and making the change happen is a highly risky proposition.

Risky? Yes, risky, because every bold, transformational change constitutes a bet on what the future will look like, coupled with the hope that the analysis and design process has identified and planned for most ripple effects, and that any that were missed . . . the unintended consequences . . . won’t be overly pernicious.

Guess right and the change makes the company more profitable. Guess wrong and every penny and erg spent (depending on whether you’re tabulating time or effort) have been wasted.

The executive who’s advocated the bold, transformational change will, in many cases, turn out to be much happier if the actual change never takes place, even when the executive is the business sponsor and is a theoretical coconspirator.

So long, that is, as the executive has an ironclad not-my-fault excuse to fall back on.

How about IT? It’s like this: programmers generally like to program. Programmers writing code are like painters applying oil to canvas: it’s what they like to do, and getting paid for it is even better.

Until, that is, it’s time to put their software into production. That’s when programmer risk happens, because the software the programmers so lovingly build might not actually, for example, do anything useful.

And so it comes to pass that when programmers finish their software, the business executive explains there’s no possible way employees can get their jobs done using what the programmers have wrought.

The programmers, politely but through clenched teeth, point out that the software satisfies all documented requirements and meets all specifications. They did their job and they did it right.

“I don’t care about the requirements and specifications,” the business executive replies. “I didn’t understand them in the first place. I only signed off because I had to or IT would never have started programming.”

Both IT and its so-called customer got what they wanted: they did what they were supposed to do, and it’s the other one’s fault nothing useful came of it.

A Less Cynical View

Okay, fair is fair, and our descriptions of how business executives and programmers think aren’t. Fair, that is. Both parties deserve a bit more credit. While the conversations are often as we describe them, it’s more likely the executives in question are experiencing cold feet than expressing their inner Machiavelli.

IT’s developers, in their turn, are more often exhibiting the natural tendency all parents have when someone calls their baby ugly than coldly and analytically comparing executive complaints to the requirements and specifications documents.

And yet, the arguments we describe are more the rule than the exception. Business executives complaining that software is unusable as implemented are commonplace.

Programmers blaming the executives for not understanding their requirements, for signing off on specifications they didn’t take the time to read and comprehend before doing so are just as commonplace.

IT’s chronic failure to deliver solutions business stakeholders find delightful is very real, whether the mismatch between what they actually wanted and the requirements and specs as interpreted by the programmers was the result of intentional cynicism or honest error.

The real problem is what it is whenever the question is whose fault something is: blamestorming has taken precedence over root cause analysis.

And the root cause is right in front of everyone involved: even imputing the noblest of motives to all concerned, when it’s an IT project the goal is to get the software right.

Not that the goal should be changed to getting the software wrong, although there are cynics in many businesses who might claim that’s what’s happened.

It’s that when projects are about the information technology, what gets lost in the shuffle is the point of it all: the intended business change that will make one or more parts of the business run differently and better.

Which leads to unfortunate consequences, such as business stakeholders figuring they’re doing IT a favor by sparing some of their staff’s time and effort to serve as subject matter experts (SMEs) for a project. Which staff members’ time and effort do they spare? The ones who have the most time available, not the ones best suited to making the project a success.

Sometimes it’s even worse: because business logic is embedded in code and has been for a decade or more, it can be hard to find anyone who knows, with any level of depth, just exactly what that business logic is, and why. And yet, when deploying a replacement system, the affected business areas still need to take responsibility for the business logic to be embedded in the new system.

When there’s no such thing as an IT project—when projects are defined in terms of the business outcomes they’re supposed to bring about—here’s what’s different. It’s all good, and it’s the ground this book will cover:

•   It’s Always the Culture: Culture consists of shared assumptions, attitudes, and knowledge (we’ll provide a more precise definition when we arrive at this section). For IT projects to give way to projects that deliver intentional business change, both business management and IT culture are in for some adjustments:

   Business management culture: With IT projects, business management justifiably figures the project is Someone Else’s Problem, which is an extension of most large enterprises’ overall silo orientation. It’s a culture predicated on the proposition that the world is divided into Things That Are My Problem and Someone Else’s Problems.

To eliminate IT projects, the company’s top executives have to replace, or at least discourage, silo thinking, strongly encouraging ubiquitous collaboration in its place.

   IT culture: Talk with your average IT manager or professional about their relationship with the rest of the business. What you’ll hear . . . and even more significantly what you’ll see in the way of expression and body language . . . is defensiveness. Because so much depends on information technology, when just about anything goes wrong it’s IT that’s left holding the bag.

When IT is a supplier to internal customers, and projects are finished when it delivers the software, defensiveness reigns supreme in IT, followed closely by self-righteous aggression: “How are we supposed to deliver software they like when they don’t know what they want?”

We’ll talk about changing the business management and IT cultures in more depth in chapter 1.

•   The New Business/IT Conversation: The no-IT-projects transformation starts with a simple-sounding change: instead of asking a so-called internal customer, “What do you want the system to do?” IT’s representatives will get in the habit of asking, “How do you want your part of the business to run differently and better?”

chapter 2 investigates all the different ways this changes everything for just about everyone else in the enterprise.

•   Fixing Agile: When everyone stops defining project objectives in terms of software delivery, IT still has to either design and build or select, install, integrate, and configure business applications.

When that time comes, when it comes down to it there are two types of IT organizations: those that have embraced Agile and those with a high project failure rate.

Agile is a big honkin’ deal.

But Agile as usually practiced is still about IT product delivery, not about intentional business change. As usually practiced it has other limitations as well.

If you aren’t clear what the difference is between IT’s Agile methodologies and the business being agile, no worries. We’ll explain it all, and what to do about it, in chapter 3.

•   IT Operations: So far we’ve talked only about the application development side of the IT house. It’s time to let IT Operations in on the fun.

IT Operations projects are a lot closer to being IT projects in that their purpose is to deliver working technology. In most cases they’re more along the lines of upgrading platforms to current versions than on directly changing how parts of the business can run differently and better.

But IT Operations doesn’t generally deliver the results to business stakeholders so as to help the recipients run their parts of the business differently and better.

From a business perspective these projects are more about risk avoidance and mitigation, which means that for the most part IT can keep them out of view, except for minor matters like budgeting the time and money needed to make them happen.

But that doesn’t let IT Operations entirely off the hook. On a day-to-day basis, IT Operations and the rest of the business are tied together even more closely than the applications side of IT. chapter 4 covers this ground. Spoiler alert: the keyword is “BusOps.”

•   Business-Change Governance: When businesses have IT projects they have IT governance or IT project governance, and it’s all about making sure IT doesn’t just spend money implementing “technology for technology’s sake,” whatever that means.

With business-change projects to govern instead of IT projects, there’s clearly no longer a need for IT project governance. Instead, business-change governance will replace it. But if all that happens is assigning a new name to the same old practices . . . well, when has changing anything’s name without changing its substance ever achieved anything important?

chapter 5 explains what has to change for business-change governance to be effective.

•   IT’s Role in Business Planning: When using computers in business was new and exciting, whoever headed IT spent a lot of time working with business executives and managers explaining what automation could do for them. IT played an active role in business planning, from strategy on down to specific automation opportunities.

Then the business became IT’s customer and all of that stopped. IT became an order taker. Which was much safer but far less satisfying.

A key takeaway from the now-prevalent and, among skeptics, faddish conversations about Digital strategy and transformation is that IT needs to be more than a responder to business needs. Most new business opportunities and threats come in the form of newly available technology, much of which is information technology.* That being the case, IT should play an essential role in formulating business strategies.

Again.

That’s what chapter 6 is about.

•   The Seven Change Disciplines: Achieving intentional business change calls for seven critical disciplines: leadership, business design, technical architecture management, application development, organizational change management, implementation logistics, and project management. A business that masters these will turn its strategies into business reality.

The final chapter (7) provides a quick sketch of each of them. Business leaders who want their organizations to achieve their goals will figure out who needs to be in the lead for each of them and will make sure every business-change effort takes full advantage of their abilities.

Expectations management: We’ve written what follows as a handbook, intended for an executive audience. In the interest of brevity, and of not filling pages with content that’s readily available from other sources, you’ll find quite a few topics we introduce and provide high-level guidance for, without digging down to the level of providing detailed instruction manuals.

Our goal here is to familiarize you with the most important disciplines and techniques needed to achieve intentional business change, not to provide primers for them all.

There’s no such thing as an IT project. It’s always about business change and improvement.

It’s easy to say. And if technique were all that matters, getting rid of IT projects and replacing them with business-change projects wouldn’t be all that complicated.

But we aren’t just talking about a change in technique. We’re asking everyone who touches information technology to think about it differently.

Changing people’s attitudes? That’s much more interesting . . . not to mention more challenging . . . than just mapping out a new business process or two and asking everyone to follow them.

* Among those loathe to admit it are the practitioners of the various process optimization methodologies. Lean, Six Sigma, and Lean/Six Sigma in particular are replete with case studies (ManagementSpeak for “fairy tales”) that purport to report transformations without ever involving IT. Usually, the stories turn out to be minor tweaks, not major transformations.

* Not all, of course. A lot of product innovation, for example, depends on materials science and other technologies that aren’t information technologies. There’s already an extensive library’s worth of books devoted to product innovation. We aren’t going to add to it here.