The dangers of unintended consequences

Sometimes IT, with its tendency to build rules and validations, can also generate inflexible systems that leave users ill-equipped to do their jobs.

I recently read a fascinating article about a law in a major U.S. city requiring that fast-food restaurants prominently post caloric information at all their outlets. While many fast-food restaurants do this as a matter of course, the information might be in a pamphlet behind the counter, or on a poster in a disused corner of the restaurant, in the tiniest of fonts. This law specified that the information be front and center, with the reasoning that people would make healthier food choices once equipped with easy-to-spot nutritional information.

A few years after the law was implemented, an interesting thing happened: Calorie consumption went up on average, especially in low-income areas where it was assumed the reduction would be most dramatic once this information was easily accessible, especially as these areas also had a high incidence of obesity. As the causes for this increase were investigated, it was discovered that people were most certainly using the nutritional information, but rather than making a decision to eat healthier foods, were making a somewhat sophisticated cost-benefit decision, and purchasing the most calories for the least cost. The noble intentions behind the law missed some critical facets of human nature, and the rather basic concept that most people buying food at fast-food outlets don't do so for nutritional value. In areas where time and money are in tight supply, speed and "bang for the buck" obviously trump caloric concerns.

Similar situations happen daily in enterprise IT. As a junior developer I was often encouraged to make systems "idiot proof," building rules and validations that would presumably help users navigate complex screens and transactions. However, these rules and validations also generated inflexible systems, or worse yet, created a "just push the button" attitude among IT and training staff that left users ill-equipped to perform their jobs. Nearly everyone in a corporate job has heard the local IT representative ask "Have you created a help desk ticket?", a well-intentioned way to track work that's become the brunt of Dilbert-esque jokes about IT around the world.

In IT management, we're even more exposed to unintended consequences. I've worked with several IT organizations that carefully craft a program management process that is a thing of beauty, mapping out the entire project delivery process from conception, to business case development, implementation, and value capture. However, the process is so unwieldy or poorly "marketed" internally that business colleagues perceive IT as obstructionist and a necessary evil, rather than a strategic partner.

The best weapon against unintended consequences is to spend anywhere from a few moments to a few days in your constituents' shoes. It's not too far a mental stretch to picture someone trying to grab food for their family while working two jobs, and going for the most calories for the buck as they try to make ends meet. It's similarly easy to understand frustrations with IT when you call your help desk and spend 30 minutes on hold, or receive a 16-page form when you call someone to talk about a potential collaboration with IT. For better and worse, most IT departments do not have the force of law behind their edicts, although we can be equally inconsiderate of what our constituents face when we create requirements without considering the impacted parties. While we generally don't have to face voters for reelection, in most cases our jobs are less secure than the politicians who passed the fast-food law without considering the risks of unintended consequences.