We Selected the Simple Solution. The Complex Solution Became a Worldwide Standard – Part I

Does this sound familiar? You have an effective solution to a complex challenge. But when you try to get it accepted, you find that it differs too much from the way solutions are expected to look. Creating openness to the unconventional solution seems an insurmountable challenge. Here is an example that may help you.

My quest for solutions to complex challenges started around 1988 while I was working for a data centre. Management recognized that, with increasing complexity, we were losing the overview: With every change we made, and every problem we tried to solve, we were in danger of creating new problems. I was asked to investigate a solution.

At the time, we used a software tool for problem and change management. The tool worked well. It had an unused module and it looked the solution to our challenge was a matter of bringing the module in production. This created excitement at first, but our initial excitement was followed by disappointment. The module turned out to be complex and cumbersome to use. Keeping the data up to date required a bureaucratic process. Additionally, the tool’s output was difficult to understand.

We investigated another solution based on a drawing. The drawing was created with a simple text-processing tool and was easy to understand. A decrease in nightly calls for problem solving provided incentive to keep the drawing up to date. Then there was the overall cost: only 5% of that of the software tool. The decision was a no-brainer.

During the mid-1990s, we were pleased to see that problem and change management had become a best practice under the umbrella of ITIL (service management for IT departments). To our surprise, the solution approach we had rejected was also part of ITIL and, as such, a worldwide standard. It became known as Configuration Management/CMDB (Configuration Management Database). This made sense as, with a new generation of computers, the drawing-based solution no longer worked.

However, throughout the IT industry, Configuration Management projects consistently failed. It was thought to be a matter of poor implementation, and implementation projects were restarted. Yet the results remained the same. Executive-level attention didn’t help either. In 2004 and 2005, I went to a couple of conferences and asked around. Even at ITIL user-group conferences, nobody could point to a successful Configuration Management implementation in a larger environment. It was time for a closer inspection.

We discovered that Configuration Management worked well in small environments and in proof-of-concept setups. However, when it was extended to a large environment and a certain level of complexity was exceeded, maintenance became a nightmare. Adding one additional data layer into the database was sufficient to make maintenance challenges explode. Unfortunately, adding a data layer was not only easy, but also tempting for both management and the experts.

.

.

.

Lessons Learned:

1. A solution that has been designed in an environment with low levels of complexity can be the cause of failure when
   • the solution is implemented in an environment with high levels of complexity;
   • the solution itself is extended and becomes too complex; or
   • the solution remains the same but the surrounding environment exceeds a certain level of complexity.
2. Failure of Configuration Management projects could have been prevented if attention had been paid to the following:
   • Only execute a Configuration Management project when you have a solid understanding of how its operational outputs integrate into day-to-day work and how it delivers the benefits over time.
   • Never cross the line beyond which maintenance becomes a nightmare!
3. With insufficient attention to Lessons 1 and 2, projects were restarted and failed again for the same reasons.

Part II explores why Lessons 1 and 2 weren’t identified, as well as why Configuration Management projects and projects in other areas were restarted and failed again for the same reasons. The final part will explore how repeated project failure can be avoided.