Practical Analysis: Wielding Process Like A Weapon

This issue's cover story is a topic near and dear to my heart. The chances to foster an innovative environment, whether it's for third-graders learning multiplication or an IT organization seeking to better serve the long-term needs of its business, are fleeting. And the opportunities to screw it up abound. Good IT organizations, like good teachers, never lose sight of that fact.

One challenge for those in IT organizations is not to become so enamored of your own process that you lose sight of serving the business first and foremost. I saw this happen early on in my IT career after a boss went to see Edwards Deming talk about Total Quality Management.

Deming, a process wonk, made no bones about telling his faithful (in his low, droning, authoritative voice) that they had to follow his methods to the letter or they'd surely screw it up. Miss a step, and you're no longer doing TQM-and by the way, why isn't your boss here because he needs to believe, too?

This approach has great appeal to some people, perhaps many of those who thrived in our schools, which are very good at getting kids to sit in rows and learn rote procedures, but not so good at teaching creative thinking. My boss ate it up. TQM became a religion to him. Finally, he had a formula for how to do management right. All he had to do was go apply that formula and surely he'd have the best-run IT team anyone had ever seen.

Those Little Exceptions

Of course, it didn't work that way. Certain things lent themselves to the TQM process and some didn't. In particular, there are always those little exceptions, the small jobs that IT teams need to do without running them through whatever process you've chosen, because if you did run them through your process, you'd either miss the window of useful opportunity or you'd turn that small job into a big, expensive one.

We longed for some sort of 80/20 rule. We would happily use the TQM ritual for most of what we did, if only my boss would let us quickly deal with the innovation-oriented 20% of tasks that didn't fit that model. It never happened, and rather than getting behind his TQM philosophy, we and business side peers rebelled, to the point where my boss lost his job.

The problem was that we were being asked to serve the process rather than serve our constituents in the business. Today, I see the same thing happening, often in organizations that are heavily committed to ITIL or some other definitional methodology. ITIL as a tool for helping IT define what it does and how it uses its resources is a good thing. But many organizations extend that thinking to create processes that are so rigid that business units chafe at the mere thought of using IT services. For instance, if it takes you 18 months to spin up a new server, you probably have a process problem.

It comes down to this: IT organizations can be loved, tolerated, or hated by their business-side peers. One sure way to get your team hated is to suggest that line-of-business peers change their processes because they don't fit IT's. Tack onto that attitude a nice fat IT surcharge leveled against every department and you'll send business managers scrambling for options-any options.

Art Wittmann is director of InformationWeek Analytics, a portfolio of decision-support tools and analyst reports. You can write to him at [email protected].

To find out more about Art Wittmann, please visit his page.

More than 100 major reports will be released this year. Sign up or upgrade your InformationWeek Analytics membership.