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?

And now, a dumb CIO story:

A division of a multi-billion-dollar enterprise embarked on a business redesign. Because the redesign was expected to have technical repercussions, an IS analyst was part of the team.

Among its findings, the team recommended replacing a core legacy system, so the head of internal consulting called the CIO to ask if he was comfortable with the team’s findings.

The CIO hadn’t seen the team’s recommendations, but when the head of internal consulting explained them he responded that he could not support them, explaining that his analyst really didn’t understand the system, the environment, or the situation. Further, he instructed the head of internal consulting to keep him informed of the positions his analysts took in all future projects, to prevent a recurrence of the problem.

Nice solution, don’t you think?

We’re continuing our series of columns on managing change. We’ll take a break after this one, which explores the fascinating issue of restoring IS’s reputation as a sponsor of change from its current status as grumpy change resistor.

Restoring? Yes. Back when IS was EDP (electronic data processing) and consisted of a lot of programmers and computer operators with a couple of managers to keep enough coffee, coke and pizza in stock, we wrote all the legacy systems we now can’t figure out how to replace, transforming our companies from top to bottom as we did so.

Now we have business people in charge and, obsessed with tangible returns on investment and avoidance of risk, we’re paralyzed.

Since every business change from this moment forward will require the active support of IS, we need to be better than this. How can you change your own organization from a sullen group of change resistors to an energized team of enthusiastic supporters?

Step one: Look in a mirror. Do you like the challenge of doing things differently, or are you obsessed about what will break in the process? Do you wake up with ideas on how to improve the business, or do you wake up grousing about end-users who install their own software? Do you complain that NT just isn’t as stable as the mainframe, or do you explain to your system administrators that since some data centers manage to create highly reliable server environments, you’re going to do so also?

Is your habit to say yes or to say no?

Here’s how to turn your organization into a supporter of change: In your next all-hands meeting explain that from this point forward, nobody will ever turn down a request from the business. Ever.

No matter what the request, the answer will be, “We can do that. If you’ll sign up to the cost, we’ll figure out how to make it happen.”

Need to replace a core legacy system? We can do that. It will be expensive because conversions are never cheap, but if you’ll sign up to the cost, we can do it.

Want to integrate multiple legacy systems into an integrated call center? We can do that. We’ll have to engage an outside development partner because we don’t have a lot of the expertise we’ll need, and right now our resources are stretched pretty thin, but that’s okay. There are lots of good systems integrators out there and we’ll find one to work with us to get your job done. If you’ll sign up to the cost, we can do it.

Need a Macintosh instead of an NT workstation? We’ll have to install a Mac gateway onto one of our servers, but if you’ll sign up to the cost, we can do it. Will the Mac user want help desk support? Since we don’t have Mac expertise in-house, we’ll find you outside support … if you’ll sign up to the cost, of course.

How do you embrace change instead of resisting it? Make change part of every employee’s job description, that’s how. If their job is figuring out what it will take to make change happen, they will.