I was back at my alma mater last week speaking to the computer programming class about making a living as a consultant. It’s a presentation that I do every year, and I thoroughly enjoy it. At one point, though, one of the students said that I came across as “anti-management.” I certainly didn’t intend to— although, with the popularity of “Dilbert,” it’s almost politically correct these days to make fun of managers. I don’t think it’s right, myself. First off, it’s wrong to work with stereotypes. And second, I do like managers. After all, they give me all of this lovely money.
Having said that I’m opposed to stereotypes, I do have to admit that the system that most managers operate in does force them to act alike. For instance, managers don’t understand the concept of maintenance, and it’s almost impossible to educate them. Managers are always committed to the next system that’s going in. The next system is always going to solve all of their problems (make a ton of money, give the company a sustainable competitive advantage, get them a date on Saturday night, and so forth). You have to admire that kind of faith—none of the previous systems they’ve implemented has ever done all that, yet they keep on implementing new systems and hoping for heaven.
That faith in new systems shows up in a number of ways. A lot of companies expect a payback within three years of implementation. In other words, a $100,000 project is supposed to return $100,000 to the company within 36 months of implementation. If you invested $100,000 with the intention of doubling your money in three years, you’d be looking for an investment with a return rate of 24 percent. Investments with higher returns are always more risky than investments with lower returns. For instance, there’s a special term for debt instruments that pay rates as high as 24 percent— they’re called “junk bonds.” Yet managers insist that’s the only kind of investment that they’re willing to make.
On the other hand, you should be able to calculate the actual rate of return for any existing system. It should be possible to calculate exactly how much money it would cost to run a company without any particular system. With that number in hand, it should be possible to calculate how much money you’re willing to spend on maintenance to get any particular rate of return (I’m ignoring the original cost to build the system, which is a sunk cost and can’t beecovered). For instance, if a system is saving the company $30,000, you’d think that spending $15,000 a year to maintain it would be a reasonable thing to do. After all, if someone invited me to a game where I could have two dollars for every dollar that I spent, I’d want to play. Yet no one seems to want to calculate those numbers or adjust their maintenance spending appropriately.
Two attitudes seem to control management’s thinking on how spending is handled for existing systems. One is that maintenance “costs what it costs.” The frame of mind here seems to be that maintenance is an unavoidable burden that you just have to pay. In fact, it quite often turns out that specific changes to a system can often dramatically reduce the maintenance costs for a system.
My favorite example of this is a non-IS one. For many years, hotel chains simply put as many people on their front desk as they needed to handle all requests while not making their customers wait too long. Someone had the bright idea of tracking the requests that were handled at the front desk and discovered that the single biggest demand was for ironing boards. For a one-time cost of $20 per room, hotels put an ironing board in each room, reduced their calls, and reduced the number of people at the front desk (an ongoing cost).
The second attitude toward the cost of existing systems is that the cost is (or should be) zero. The feeling is that bug fixes drive most maintenance costs, and “if only those darn programmers would build the systems right,” there would be no maintenance costs. The fact is that bug fixes typically drive less than 10 percent of any system’s maintenance costs (adaptive and required changes, support, and enhancements account for another 80 percent). This belief, by the way, allows managers to implement new systems without hiring new employees to handle the increased maintenance burden that the new system will generate.
The great thing is that most managers seem to hold both attitudes. To borrow a term from George Orwell’s novel 1984, managers indulge in doublethink. They simultaneously believe that maintenance costs are unavoidable and that they should be zero. As Orwell points out in his book, this is an essential requirement of many faith-based systems.
The result is that I’m always brought in to work on new development but never on maintenance projects. I don’t mind. Maintenance is a much more difficult job than development, requiring the combined skills of programmer, system architect, historian, detective, and psychologist. The stakes are also higher in maintenance than in development. As one contractor I worked with put it, “No one cares if the development system crashes.” But if you do something that crashes a production system, you get phone calls from people whom you’ve never heard of before.
Still, I keep hoping that the managers who decide how to spend consulting dollars will wake up to the benefits of investing in their existing systems. I believe that someday the legacy work that so many programmers invested their time and energy in will get the attention that it deserves. You just have to have faith.
