Business Technology Discipline

by Stephen J. Andriole, Fellow, Cutter Consortium

Over the past year, I've seen a lot in business technology discipline (or not). I spent a day at a large enterprise where they explained how they had implemented 11 ERP systems and multiple instances of them. When I got up off the floor and promised them huge savings by reducing the variation in their back-office environment, they told me that they really weren't interested in the savings because they would require too many meetings, too many arguments, and -- well -- just too much discipline. They really didn't like discipline (or arguments), so they planned to stay pretty much the way they were, thank you very much.

I then traveled to a company that had a lot of old applications, a lot of new applications, a lot of redundant applications, and no real standards for application deployment or support. Their solution to the problem was to build the world's largest data warehouse to which everything could connect and from which every question known to man could be answered. While they supported all of their disparate applications, they planned to invest US $250M in the data warehouse project over five years. This time I needed a defibrillator to remain conscious as I explained that if they reduced the variation in their applications environment they wouldn't need the data warehouse. But someone -- in authority -- then said that they had always wanted a data warehouse because they heard data warehouses -- and data marts -- were really cool.

Yet another company I work with thought that the project managers in their project management office (PMO) were way too mean and that they had to be disciplined. "Isn't the PMO the dispenser of PM discipline?" I asked, only to be told that they had taken their disciplinary mission way too seriously, so seriously in fact that no one liked any of the project managers any more. So the company decided to de-discipline them through a 12-step program.

What's up with discipline, anyway? Is it just something that guys like Jack Welch and Larry Bossidy write about? Does anyone actually practice what they preach? I have concluded that very few of us are disciplined. Of course there are exceptions. Engineering teams tend to be more disciplined than marketing teams. Product R&D teams are more disciplined, by and large, than finance teams. But what about information technology teams? Are they disciplined? Only when the culture supports the use of logic and evidence (instead of emotion and rhetoric). In other words, it's impossible to be disciplined when everyone around you is crazy -- or worse, just doesn't care about the benefits that accrue from more rather than less discipline.

Best practices are all about discipline, repeatability, and predictability. But who practices best practices? Do you? I only do when I expect to be rewarded for doing so, but if I expect to be harassed for being disciplined I usually pass. What's the lesson here? Discipline starts at the top, has a proud history, and is embedded in the furniture. If it's not, then it just won't stick.

So the first step is to assess the discipline quotient (DQ) at your company. If it's low, then lower your expectations. If it's high, then you're already disciplined. If you don't really know -- or the company is disciplined on Monday but never on Tuesday -- then the DQ assessment is more complicated. The question then becomes: can this dog hunt? (AKA: can this company discipline itself?) If you fall into the last category, try a few things to test the water. You might be pleasantly surprised -- or deeply disappointed. Good luck.

-- Steve Andriole, Fellow, Cutter Consortium