Browse

All Posts in Strategy and Tactics

|In: Industry Commentary|Last Updated:

What’s the future of information technology? Everything will be faster, development will be easier, and integration will be as simple as building something out of Tinkertoys. In fact, development and integration will converge into the same set of activities — finding the functionality you need and connecting it into a functioning application.

Sure it will. Of course, building something useful out of Tinkertoys still requires a design and a plan, and taking two somethings built out of Tinkertoys and sticking them together will still require consistent designs, but no matter. That isn’t what this column is about anyway.

This column is about the future of information technology organizations, not the technology itself. That future, as stated here many times before, is to be a collaborator with the rest of the enterprise in designing and achieving useful business change.

Imagine you’re convinced and ready to go. What happens next? Do you add an agenda item to the next executive staff meeting to make the announcement? Sure — you’ll stand up, say, “Ladies and gentlemen, the IT division has officially redefined its role in the enterprise. We’ve been a service provider that strove to exceed your expectations. Now we’re a collaborator in designing and achieving useful business change,” and sit down.

That will work. Not on this planet, mind you, but in an infinite universe there must be a world circling some other star where it would.

Here on earth you need to be a bit more subtle than that, because of three dark little secrets most in business don’t want to admit.

The first is that advocating change is a whole lot safer for a business manager’s career than actually implementing change. Advocating change is fine and noble, making it clear you’re firmly focused on achieving great things for the enterprise through visionary programs fraught with exciting opportunities. Actually implementing change, on the other hand, involves quite a bit of risk and more than quite a bit of roll-up-your-sleeves-and-sweat hard work.

Advocating change while avoiding its reality is, fortunately, quite simple: Blame IT. Business change requires new information technology. Most IT projects are less than successful, so the odds favor nothing happening. And if IT does deliver working software that meets the specifications, that doesn’t mean anything anyway — the software might run, but it’s always easy to find reasons it doesn’t support the business.

That’s the first secret — perhaps overstated, but present at some level more often than not. The second? IT likes advocating change more than it likes implementing it, too. Proclaiming that we’re change agents makes us sound like a potent force in the enterprise, and creates work for analysts and programmers besides. Building software that meets the specifications is hard but straightforward work. But if anyone tries to actually use it, we all might discover a flaw in the premise, and that’s even worse for our reputation than building software that never gets used. We can always blame the business for the bad specifications.

Okay, so I’m still overstating things. There’s enough truth in all of this to make everyone uncomfortable, as it should. The third secret, though, I’m not overstating at all: Most businesses have killed their ability to adapt to changing conditions. They call it “lean and mean.” If they’d called it emaciated and unpleasant — the more apt description — even Wall Street might have understood the fallacy.

The IT division you lead is embedded in an enterprise accustomed to treating IT as an internal supplier, and to IT treating everyone in the enterprise as internal customers. Most people like it that way. And there aren’t enough employees left in the business to work on a large business change initiative anyway — at best, there are barely enough to keep the place going. IT should collaborate with the business to achieve change? How’s that going to happen?

That’s a great question, which means, as everyone knows, that I don’t have a great answer.

I do have a half-decent one. It will have to wait until next week, though, because we’re out of space and I have to finish getting ready for our two upcoming seminars.

Comments

|In: Leadership|Last Updated:

One of the most powerful tools at a developer’s disposal is recursion. Whether the job at hand is defining a bill of materials or the management hierarchy, recursion is the only tool for the job. (If you aren’t familiar with the term, the GAWK manual defines it thusly: “When a function calls itself, either directly or indirectly. If this isn’t clear, refer to the entry for ‘recursion’.”)

Few CIOs design data structures or write code anymore, but those undertaking the coming transformation of information technology will be hip deep in recursion themselves. The coming IT transformation is a radical change in mission, from delivering working software to collaborating in business change. The recursion: This transformation is a business change itself, requiring all the same techniques as the business changes in which IT will collaborate if it happens.

So let’s talk about the nature of business change.

Many business leaders think it’s enough to state the change, evangelize it, and “hold people accountable,” whatever that means. If that’s your strategy, good luck, because you’re going to need it. It’s a strategy that counts on luck and lots of it. The likely outcome is that you’ll get lip service from executives, business users and IT staff who, when you aren’t looking, ignore your ideas completely. The lip service does have some value, of course: It gives you the ammunition you need to blame someone else when the change fails.

To successfully lead change you need much more: Consensus among all stakeholder communities that the change is necessary and important, a plan, and a way of determining whether you’re making progress.

You need the consensus because this has to become how the enterprise does business, and it won’t do business that way if its leaders and staff don’t want to. Building this consensus is hard, because what’s good for the enterprise as a whole won’t be particularly popular among those most affected. Under the best of circumstances, those in the middle experience the invalidation of hard-won skills, a requirement that they acquire new ones, and extra work as they figure out how to make the new way of doing business, which always looks phenomenal in PowerPoint, work in the realities of their cubicles. A frequent concomitant is having to cover both their work and the work of those employees laid off in anticipation of promised efficiencies.

In a well-designed business change program, employees who support the change can see a path to personal success. All too often, though, there isn’t even a connection between their support of the change and mere survival. In fact, some companies manage change so badly that the sole benefit of participation, received by supporters, resisters, and agnostics alike, is a free copy of Who Moved My Cheese, provided by helpful managers so employees will understand that their discomfort is the result of their being stubborn and irrational, too ignorant to understand that all change is good.

Consensus isn’t enough, of course. You also need a plan, because if you don’t have one, nobody knows what they have to do to make the change happen. It’s astonishing, by the way, how many otherwise savvy business leaders think that if they just explain the nature of the change and build consensus, it will happen all by itself through the magic of everyone behaving in ways that are consistent with the intent. If you’re one of them … imagine a program manager responsible for implementing an ERP system working this way. There’s no chance of it succeeding. To achieve major business change, someone needs to manage it, and that includes defining the tasks that need to be undertaken and their schedule.

Then there’s knowing what constitutes progress. This is harder than it sounds, especially because in most cases a major change makes the organization less effective for awhile. It has to: You’re invalidating old skills, requiring new ones that have to be learned, and blowing up the old way of getting things done. It will take awhile for everyone to get in the groove.

This is all true of any business change. Any IT organization that wants to collaborate in business change will have to master these disciplines, as will its collaborators in the rest of the business. That won’t happen through wishful thinking: As an IT leader, you have to practice them yourself so as to get the rest of the enterprise to move to this new way of doing business.

It’s recursion at its finest.

Comments