Never say no to a customer . . .

I.T. is a service organization

©Conrad Weisert
February, 2007

NOTE: This article may be reproduced and circulated freely, as long as the copyright credit is included.


Saying no to a user request

A recent article in Computerworld warned that

IT's ability to stop a project just by saying no is long gone. Users figured out in the 1980s that they could buy their own computers and program their own spreadsheet applications. They discovered in the 1990s that they could rent space to create their own web pages and even hire freelance programmers. Today, when IT says "No," [users] say, "So what?" and do it themselves.

- Frank Hayes: "Don't Just Say No", Computerworld, January 8, 2007, p. 36.

That's true, of course, but incomplete. It was never acceptable to say no to a legitimate user request. The user community may have had fewer options 25 years ago, but they had just as much right then to expect responsive service from their internal data processing organization.

So, why did I.T. departments deny a legitimate user request for a new or enhanced application system? Three commonly cited reasons were:

Sometimes a fourth unstated factor was the real reason:

The service organization charter

Large well-managed organizations usually established a department, a division, or some other organization unit to provide computing services. Over the decades, such departments have gone by a succession of names, such as:

In some smaller or less formal organizations, IT just evolved without much planning in one of its major user organizations, commonly an accounting department.

Typical IT departments perform, or at least coordinate, these user services:

A mature IT organization has a formal foundation, consisting of:

The performance of IT and of its director (or Chief Information Officer) will be judged by measurement of meeting those service-level objectives. (IT organizations that lack explicit service-level objectives experience a high degree of perceived failure and CIO turnover.)

Who pays for all that? Chargeback and pseudo chargeback

Three approaches to funding IT are:

Strict overhead.
Upper management decides how much the company will spend on information technology, usually annually.
Negotiated allocation.
A high-level committee decides how to apportion IT costs among major user departments, based on periodic (usually annual) estimates of their needs.
Direct chargeback.
Usage of equipment and of staff are measured and charged to the requesting user organization.

Two of those approaches lead to conflicts, continuing user dissatisfaction, and irrational pressures on IT. Chargeback is the businesslike technique that identifies to upper management exactly where money is being spent and empowers user management to make decisions in their own interest.

Unfortunately, companies with a casual management style or recalcitrant executives find it hard to accept and implement a rational chargeback system. Faced with such a constraint, some enlightened IT directors have instituted pseudo chargeback. They measure services and compute their cost, but instead of actually transferring funds from the users' budgets they simply issue (usually monthly) reports showing how much money IT spent on behalf of each user and, therefore, how much each user would have paid if chargeback had been in effect. Those reports provide a rational basis for determining IT's budget, for resolving many conflicts, and for setting priorities.

Cutting the budget—What if there isn't enough money to satisfy all the users?

Organizations go through lean times. IT is a tempting target for cost cutting. All too often that takes a naive form like this:

Edict—Cut next year's IT budget 10 percent. But user departments are not told to cut their demand for IT services.

An IT manager, confronted with steady or growing demand to provide services from steady or shrinking resources, can sometimes squeeze a little more efficiency from his or her organization, but eventually such a situation means certain failure. The sensible rule for management is:

To reduce the cost of a demand-driven service organization, you first cut the budgets for the user organizations making the demands.

Coming soon

We'll continue this topic later this year with:

Meanwhile let me have your views and experiences at cweisert@acm.org.


Last modified 31 May, 2011

Return to IDI home page
Management articles