All Posts in Strategy and Tactics

|In: Leadership|Last Updated:

Several columns ago, I responded to a reader’s request for instructions on how to speak in ManagementSpeak.

I should have taken my own advice in a subsequent column. Taking business as a whole, I said, IS has a reputation for failed projects, unreliable networks, unhelpful help desks, and a derogatory attitude about end-users. My suggestion that IS won’t be invited to play in the strategy game until it gets the basics right created quite a ruckus.

Without exception, readers from outside of IS endorsed my position. Those from within IS were (ahem) less receptive. So here’s the ManagementSpeak version of the message:

“We own these problems. If you’re running IS it’s time to form a clear picture of how the rest of the company perceives you and develop a plan of action for fixing your image.”

OK, that wasn’t really ManagementSpeak. So sue me.

Imagine for a moment that I’m wrong and IS’s defenders are right — the reasons for IS’s non-delivery are unrealistic expectations by the CEO, lack of cooperation on the part of business leaders, and end-users who can’t find their lips with both hands and a mirror.

Here’s what the CEO would hear if any CIO was dumb enough to present this explanation: “It wasn’t me. It was somebody else who looked like me. And besides, they made me do it! IT’S NOT MY FAULT!!!”

That will work well.

The politics between IS and everyone else makes many companies look like Yugoslavia. All of the explanations IS’s defenders provide are exercises in affixing blame. While fun, worrying about which group started it all is, in the end, unproductive because it started when the Roman Empire fell, everyone who started it is dead, and blaming someone else just makes sure nobody fixes the problem.

If you want IS’s reputation to improve, take personal responsibility for it. If you work on or manage the Help Desk, don’t complain that end-users bypass your services. Figure out why they don’t call you (hint: Ask them) and do something about it.

If you manage application development and your project success rate is low, don’t just complain about how you can’t get what you need from business participants. Work with your company’s business leaders to figure out how you can either get the participation you need or cancel the projects where you can’t.

And don’t stop there. In fact, don’t start there. Take a hard look at where your projects are derailing, focus on the problems IS causes, and fix those first. You’ll be far more convincing when you talk about how to fix business-side issues when you start the conversation by saying, “Here’s how we in IS have been causing problems and here’s what we’re doing about it.”

If you manage the networks, keep track of what fails and fix repeating problems, one at a time. Make sure every network technician repeats the same mantra: “Downtime is abnormal.” Don’t accept OS limitations as an excuse. In a lot of data centers, gripes outnumber suggestions ten-to-one or more. Yes, it’s harder to keep NT servers running, but complaining won’t stabilize them. Make sure you’ve exhausted the possibilities for improving server reliability, then ask your friends in other companies what they do. Or, make a persuasive case for converting them to another OS that includes recognition of all conversion costs.

Then there’s attitude. Twenty years ago I heard one of my experienced colleagues describe end-users as “just parasites on the system.”

Think attitudes have changed? They have. Lots of places they’ve become worse. How are you going to fix bad attitudes? The one-word answer is “leadership”. (For the longer answer … watch this space.)

When IS starts to lose its credibility with the rest of the business, IS employees develop a siege mentality, trust disintegrates, and a downward spiral starts. The worst thing that can happen is for the company’s business leaders to take ownership of the problem, too, because once they do, they’ll have taken responsibility for technology leadership, leaving IS as nothing more than a passive order-processing department.

Sound appealing?

Comments

|In: Office Politics|Last Updated:

I love golf.

I wandered through a golf show a few weeks ago, looking at gadgets, daydreaming of long, straight drives, and pondering the game as a metaphor for managing IS (not for the first time, either — see my July 8, 1996, column on the subject).

The obsession so many of us have with long tee shots is a good example. Just as most of us would be better off playing a five iron off the tee and practicing our putting, so many CIOs worry about aligning IS strategy with the company’s goals and vision while ignoring the real big-money issue — poor project execution.

So it was that I visited a booth selling custom woods (actually metals, good persimmon being unavailable these days). The purveyors of these fine clubs had a killer sales pitch: Rather than fix my slice-prone swing, they would sell me clubs that compensate for my deficiencies.

For a significant price, of course.

These clubs provide us with a lovely two-sided metaphor. On the one side we have executives who think nothing of spending a sizable fraction of their annual bonuses on these very same custom golf clubs and a supply of titanium balls, but who cheap out when it comes to providing a reasonable set of tools for IS. They believe better tools will help their golf games, but not their businesses.

On the other side we have IS weenies who are convinced that if they just had better tools, they’d suddenly become the ultimate code warriors, able to create magical applications in periods of time so brief that quantum effects predominate.

Examples of the former are easy to find: Data center managers who lack funds to implement network management, developers whose request for source management software is denied, even project managers who aren’t given basic project management software.

Examples of the latter are just as readily found: A friend of mine bought a PC-based Cobol compiler a few years back expecting to develop and unit test mainframe applications on it. A few minor problems cropped up after the money was spent: The systems it was purchased to support ran on top of a proprietary transaction manager and used a proprietary data compression system, neither of which would run on anything other than an MVS mainframe. Oops.

Then there are the fifty-buck tools that solve five-buck problems. In the early days of Unicenter, for example, Computer Associates boasted of its ability to stop batch jobs if available storage filled up, roll off some files to tape, restart the job, and restore the files at the end of the process. The sole design flaw: For the price of the software, you could have bought enough scratch storage to run any batch job you could imagine. Sometimes, brute force can be more appealing than elegance.

Business executives often complain about our buying technology for technology’s sake. The complaints are, for the most part, groundless. The applications IS deploys and manages invariably have a business purpose.

Except for tools, that is. Let’s face it: A lot of us have a yen for the latest and greatest software tools, just like some stereotypical husband with a workshop who wants a table saw or drill press.

How to make sense of requests for expensive tools? The answer is to eschew (gesundheit!) the use of broad principles. They won’t help. The only way you get a handle on this issue is to figure out your core processes first. These usually are (in order of importance): data center operations; applications maintenance; end-user support; system selection, customization, and integration; software testing; and application development. Understand your processes first and you’ll quickly understand which tools you need and which ones may be wonderful, but just don’t fit.

Oh yeah, just one more thing: While you’re busily giving your developers killer workstations with dual overhead cams, fuel injection, and turbochargers, also give them Pentium 133s with 32 MB of RAM to test their works of art. The P-133 is an important developer’s tool.

You’ll be amazed at how much having to use one will improve a typical developer’s code.

Comments