All Posts in Organizational Effectiveness

|In: Industry Commentary|Last Updated:

Some economist analyzed all of the leveraged buyouts of the 1980s and made a startling discovery: In about 70 percent of the cases the companies — generally profitable when acquired — did not generate enough cash to pay off the debt taken on in financing the LBO.

Everyone involved in these transactions knew they would fail, but it didn’t matter, since they all ended up wealthier than when they started.

Why do groups of people who are individually smart seem to act stupidly so often? A group is smart when its members’ personal short-term interests coincide with the group’s long-term interests. Otherwise the group will do stupid things.

That, far more than a bunch of dumb CIOs caught off-guard when a century sneaked up on them from behind, explains why we have a huge year-2000 problem.

The year 2000 is a crisis because until it reached crisis proportions, making this year’s numbers was more important than investing resources in surviving past 1999. Understanding these dynamics should change how you set IS priorities.

I remember raising the year 2000 question back in 1994. We spent exactly one sentence discussing it. Since we lacked the resources to satisfy immediate demand, the year 2000 could wait until 1995, when with luck we would all have different jobs and it would be someone else’s problem. (No, none of us actually admitted to that thought process … maybe I was the only one that shallow.)

What problems do you have with your systems architecture or applications portfolio that you could fix with little stress if you started right now? I’ll bet you have at least one.

Maybe your particular problem is an ancient system with old, fragile code nobody really knows anymore. You can fix it by rewriting modules that require maintenance instead of simply tweaking them, even though the rewrites will take twice as long.

Or maybe you operate a batch legacy environment, and you know in your bones that the company needs to operate in real time. Figure out how to switch one class of updates at a time from the batch queue to online transaction processing and incorporate this into your overall IS strategy.

Use your year-2000 crisis as a lever to sell a long-term program of technology grooming, so you never again experience this kind of difficulty. I know that right now, if you’re a typical CIO or IT director, the year-2000 problem seems like your greatest challenge and these other projects seem distant at best. And I have almost no useful advice to give you on solving your immediate problem except for these very obvious points:

  • Make sure you have enough programmers assigned to the project. Then add a few more for good luck.
  • Assign or hire the absolute best project manager you can possibly find and afford to run the project.
  • Pay more attention to testing than to any other part of the project.

The immense cost estimates for the year 2000 fix are misleading. Yes, organizations will spend huge sums. These sums will have little adverse impact on the economy, though, because for every company that spends there are others, or individual employees, who receive.

The real impact of the year-2000 problem will be to reward far-sightedness: Competitors that have already fixed the problem can now afford to invest in projects that yield a competitive advantage.

Comments

|In: Industry Commentary|Last Updated:

All manner of experts claim to know better than people who do real work. Consultants such as myself have broader exposure to ideas and practices. Executives see the big picture more clearly. And accountants understand the financial realities far better than factory workers, who only know that without a new forklift work will stop when the old one breaks down.

Well, consultants really do have broader exposure, executives do see the big picture more clearly, and accounts do understand the numbers. And we all ask the people who do real work to respect our knowledge, expertise, and perspective.

So why do so few of us return the favor?

We’re going to spend one more week critiquing Paul Strassmann’s thesis that spending on IT hasn’t generated any economic returns. Strassmann, you’ll recall, has amassed a daunting array of financial statistics which he’s sliced and diced more ways than a Vegematic can handle potatoes, all without finding any correlation between financial improvement and IT spending.

I’ve been contending that he’s the kid looking for his lost quarter under the streetlight even though he lost it a block away, because “the light is better here”.

Here’s one place Strassmann hasn’t looked: He hasn’t talked to people who actually use computers to do their jobs. I wonder why not?

People who use computers to do their jobs aren’t misguided children or poor deluded fools. They’re smart people. If they tell you they do their jobs better with a particular technology than without it, they’re more likely to be right than a number-cruncher who’s never talked to them.

Here another problem with Strassmann’s analytical approach: He tries to correlate “IT spending” with various measures of financial return. “IT spending” is an undifferentiated blob. Let’s break it down into its components.

In typical organizations, 70% of IT spending goes to the data center and systems maintenance. These don’t deliver new value. They maintain value you’ve already gained. So by definition only 30% of IT spending has any chance of yielding further financial improvements.

It’s well-known that only 30% of all IS/IT projects are satisfactorily completed. That means while 30% of IT spending tries to create new value, only 9% has the chance. I wonder what conclusions Strassmann would reach if he re-analyzed his data using only the IT spending expected to deliver value.

Because so little spending delivers value in the end, Strassmann claims we’re aiming at the wrong targets, providing technology for technology’s sake. I’d contend the problem is with our technique, not our aim. It’s in the hard work of project management and system implementation that we goof up, not in our ability to link projects to business strategy.

Now here’s something remarkable. I re-analyzed some of Strassmann’s data, converting back to numbers as best I could a graph plotting IT spending per employee against return on equity (ROE) for 20 companies in “the food industry”. As expected, the regression analysis showed no correlation.

Then I tossed out four outliers — data points clearly outside the pack. The new regression showed a strong, statistically significant correlation between IT spending and ROE. For you statisticians, R Square equals .28 at a .033 level of significance. The slope (increase in ROE per $1,000 spent per employee) is about 1.5%.

This new analysis no more proves IT spending does provide value than Strassmann’s analysis disproves it. Since the original analysis lumps supermarkets, agribusiness conglomerates, pet food suppliers and a tobacco company together the whole analysis is just a tad dubious.

But when the inclusion or exclusion of just four companies makes the difference between no correlation and strong correlation, Strassmann’s conclusions must be taken with at least a grain of salt.

Or pepper, if you like spicier stories.

Comments