Don't just say no

Saying 'no' can create extra problems for IT managers

It's an old story: A sales manager comes up with a great system for squeezing maximum results from his salespeople and uses spreadsheets to support the process. Another sales manager thinks this is a great idea and proposes scaling the whole works up to support many more salespeople. IT says no, we don't have the resources to build this, and if you do it yourself, we won't support it. Sales hires a programmer who whips up a database-driven version. The dog and pony show wows the CEO, who throws his support behind the project. But it turns out the new software breaks some existing applications and even corrupts critical data. And a year later, it's IT's job to fix the problem.

How did IT get into this mess? By just saying no.

January is when proposals to turn this or that user-created spreadsheet hack into a real application start to bubble up. Hey, it's a new year (even though it's not a new IT budget year), a time for new ways of thinking and better ways of doing things. The fact that there's no money for new projects in IT's budget doesn't dampen users' enthusiasm.

So what they propose, you dispose of with IT's favorite word: no. And you figure that by saying you won't do it and won't support it, you're off the hook.

That's naive -- almost as naive as users' ideas about how easy it will be to create those real applications.

Look, 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," they say, "So what?" and do it themselves.

But their priorities aren't IT's priorities. They're mainly concerned with getting their apps to work as quickly and cheaply as possible. You, on the other hand, have to think about corporate standards and maintainable code and bandwidth limitations and upgradability -- and, most of all, making sure the new software won't break your old software.

When you say no, you don't stop the project. You just lose your chance to make sure IT's priorities get into the mix. You cut yourself off from the project until something has broken horribly, just when fixing the problem is most expensive.

In other words, by saying an ineffective no, you maximize the cost of the fix and look like an obstructionist in the process.

But you can't say yes, either. The money just isn't there in the IT budget. The IT staff is still booked solid.

Maybe it's time to stop thinking there are only two choices. Maybe it's time to say, "We can't do it, and we won't support it, but we'd like to help."

After all, you don't have to control these projects completely. You can't afford to own them, but you don't need to. What you really want is to make them just a little more successful, so they don't cause problems with your existing apps.

That might be as simple as laying a single requirement on the table: "Must play nicely with existing applications."

Or it might mean offering to help test the new app's compatibility. Or offering suggestions, hints and tips for the project. Or doing light oversight, or even formal reviews of the work as it's done.

The key is leaving the project's cost and effort in users' hands, but participating just enough to keep the project from raining grief on IT down the line.

It won't eliminate all the problems you could get from user-generated IT projects -- users are endlessly inventive. But at least you'll have a hand in it, and you'll know a little more about what else may go wrong. If you're lucky, the users may even thank you for not just saying no.

And you'll have one less mess to deal with this time next year.

Join the newsletter!

Error: Please check your email address.

More about HIS

Show Comments

Market Place