Usually, when I’m asked to do a strategic IT plan for a client, they’re interested in what new infrastructure and applications they should adopt. Occasionally, however, I’ve found myself telling them to slow down and innovate less.

I’ve found two major areas in which the pace of innovation should be questioned. One is upgrades of existing software; the other is application development done by departments using outside consultants.

You will always be hearing recommendations to upgrade. The time to be suspicious, I think, is when these don’t come from users. Vendors and the computer trade press tend to march to the pace of product introductions. Their definition of being up to date is being in the beta program. Their definition of a smart IT manager is somebody who’s aware of and using the new stuff. Because this attitude is so pervasive, you may even have colleagues praising you for being on the bleeding edge and looking for your advice. Heady stuff.

Users, on the other hand, often hate upgrades. Let’s face it: Learning is pain. And the necessary learning during upgrades can be painful, indeed, if there’s inadequate training or if there are simply too many upgrades in a given period. It is also true that your help desk will have to learn the upgrades, and while this is going on it may take longer to help a user.

The worst case is when an upgrade goes awry. One of our clients did a SharePoint upgrade that made documents on dozens of sites simply inaccessible. It was as if they disappeared. It took weeks to get most of them back and some never returned. Thus, a major rule for upgrades is that when you do them, do them right. Make sure you can roll back to the previous version if something goes wrong. Test, and test again, before going live.

The main question is whether the advantages of the upgrade outweigh the risks. It’s rather like what physicians ask when considering a treatment. If you decide that without self-deception, you’ll probably be OK.

There is a limit to putting things off, of course. If your users are still on Windows XP or Vista, you’ve probably exceeded it. One definite signal is when the vendor stops supporting the product. It’s also true that you can irrationally avoid upgrading. Right now, every time I see the picture of a computer with the Windows 8 desktop on it, I have a completely irrational urge to scream. I’m not recommending Windows 8 now, but I have to face the fact that the time will come when it may be the best choice.

The second case is when a department hires a consultant to implement a new application. The usual problem here is that business units or programs almost never have the experience in handling vendors necessary to do the proper assessment of how likely the consultants are to execute properly. Moreover, business units rarely know how to manage software development projects. The result is too often a project that goes over budget and way beyond deadline, and it’s often the case that users tear their hair out trying to deal with all the bugs.

To mitigate this risk, IT gets put in the unenviable role of trying to hit the brakes when the program or business side, entranced by the application’s potential, wants to go full speed ahead. This is not fun, but look at it this way: It’s a chance to hone your people skills. If you don’t intervene, you, and your help desk, will deal with the issues later. So suck it up and speak your mind.

Of course, all this isn’t really procrastination; it’s self-discipline. But there are times, indeed, that the best path is to go slow.