All Posts in Office Politics

|In: Industry Commentary|Last Updated:

Bob Lewis’s IS Survival Guide (MacMillan Computer Publishing) will be on the shelves by the time this column appears. For everyone who reads this column and wonders whether it’s worth buying I have only one thing to say: My kids need new shoes.

If you do buy the book and like it, tell your friends. If you don’t like it … pretend I’m your boss. Act like it’s the greatest thing ever, even though you know better. I have plenty of reality in my life already, and lots of friends and colleagues who minimize any risk of ego-inflation.

Of everything in the book, the chapter on measurement was the hardest to write. Measurement doesn’t lend itself to lively prose under the best of circumstances, and even among IS professionals the plague of innumeracy is rampant.

Worst of all, the state of the art when it comes to IT measurement is dismal. A recent conference in which I recently participated reinforced that conclusion.

The good-news part of the story is that we know how to understand the performance of data center operations. We have well-developed measures to help us understand how reliable our systems are, how well they perform, and how much they cost to operate.

Not only do we know how to measure operations, several professional benchmarking companies have extensive performance databases, so you can compare yourself to the rest of your industry, or to business as a whole. If you’re sub-standard, you can set up improvement programs to make yourself better. If, on the other hand, you’re ahead of industry averages you can … well, you can still establish improvement programs, because you always want to improve, don’t you?

Benchmarking really doesn’t do a lot for you, unlike baselining, which does. There are only two reasons for benchmarking, both of them social. The first is to defend yourself against executive-suite attacks (“We’ve just undertaken a benchmarking exercise and are ahead of industry averages, so QUIT YOUR GRIPING, FRED!”). The second is to break through internal resistance to change. It’s as common in IS as anywhere else for employees to figure they’ve already done as much as possible, so a benchmarking study that demonstrates sub-standard performance can help break through this resistance. (So can establishing a baseline and saying to employees, “I don’t care if we’re good or bad, we’re going to be better next year than this year.”)

Internally, we know how to measure operating costs. How about our contribution to the rest of the business? Well …

We do know how to measure how much process-improvement projects increase productivity. If anyone is willing to go through the effort, they can perform a before-and-after productivity analyses of the process being improved.

This doesn’t answer the question we’re asking. Process-improvement projects include not only new technology, but also process redesign, culture change, usually a new business model, and sometimes a new philosophy of leadership. What part of the productivity increase comes from information technology? It isn’t a meaningful question — technology is integral to the new process, not a bolted-on automator of activities you’d otherwise do manually.

Assessing the contribution of technology to productivity is what we’re best at and we don’t have an adequate framework for that, only a way to measure the impact of a specific process improvement project. We have no idea at all of how to measure the value information technology creates. Instead, silly notions like the Gartner Group’s Total Cost of Ownership and weak analyses like Paul Strassmann’s The Squandered Computer (both critiqued extensively in this space) still get a lot of attention.

It’s time for us to get a handle on this issue. If measurement of the value we create is important, it’s time to get on with it. If not, it’s time to formulate a clear-headed debunking of the whole concept.

Either way, we need to do better. Next week, we’ll start exploring how.

Comments

|In: Leadership|Last Updated:

There are two kinds of people in the world, according to a tired joke: Those who divide the world into two kinds of people and those who don’t. I’m one of those who do. I divide the world into engineers and everyone else.

Being an engineer isn’t a matter of training or expertise, or at least not the way I use the term. Engineers look at every problem as a puzzle they can solve, so long as they’re smart, systematic, and ingenious enough and look at it from the right angle.

The rest of the world looks at problems as, well, as problems. Things that make their lives worse. Obstacles. Barriers. Something you call an engineer to take care of for you.

Engineers have a hard time working with non-engineers because of how much time and emotional energy the non-engineers expend bemoaning their fate and how hard it all is. Non-engineers have an even harder time working with engineers because the engineers display so little empathy.

There’s room in the world for both. For the non-engineers, I figure we should reserve the Aleutian Islands.

Correspondence from an IS Survivalist brought this to mind. Following my suggestions on how IS can improve its relationship with the rest of the business, this scarred veteran described a situation that’s all too common: End-users who are all too willing to complain, but who aren’t willing figure out what they really need.

How do we deal with them, Mr. Know-it-all Consultant?

Some problems require more extreme solutions than others. When asked how to fix the acoustics at Northrup Auditorium, for example, the great conductor Eugene Ormandy had a one-word answer: “Dynamite.” Recalcitrant end-users also call for extreme solutions, although not as extreme as Ormandy’s. Here are some possibilities:

Extreme Technique #1: Make sure you aren’t the problem. Because it’s so easy to blame the users, ask a couple of the best analysts you know to review the situation with you. See if they can offer any suggestions or point out flaws in your technique.

Extreme Technique #2: Ping pong. In every meeting tell the complainers, “Here’s what I need from you. As soon as I get it, I’ll build it into the prototype.” Every time they hit the ball back to you, put it back on their side of the table again. Use prototyping tools so you can do your part at great speed. Every time they’re late send a reminder on e-mail, copying your boss and the project’s sponsor.

Extreme Technique #3: Assign a leader. According to legend (most of which he apparently authored himself) Wyatt Earp once faced down a mob by appointing a leader, pointing a gun at him and saying, “Get these people out of here.”

Look the biggest trouble-maker in the eye and say, “It’s clear not everyone wants the same thing in this system. Fred, you seem to have strong opinions about it so I’d like you to be my point of contact.” Then, ask Fred, every step of the way, “If I build it this way will it be what you need?”

Not only will Fred will have a hard time complaining, he’ll be on the receiving end of everyone else’s complaints – after all, you built it to his specifications and he was supposed to coordinate with everyone else.

Extreme Technique #4: Escalate. There comes a time when the CIO has to explain the facts of life to his counterpart in the end-user organization. “For us to build the system you need, we need someone from your organization to take responsibility for its design, and we need you to sponsor the project so there’s someone with enough authority to resolve issues and priorities. Otherwise, we’ll just have to guess, and there’s no way we can get it right that way.”

And then there’s the last and most extreme technique: Look the complainers dead in the eye and speak the following words: “You have two choices: You can complain, or you can design. Pick one.”

Comments