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.

Blog 1 Part1 Box 1We 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.

Blog 1 Part1 Box 2However, 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.

Blog 1 Part1 Box 3

.

.

.

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.

About Eugen Oetringer

Practical, innovative, visionary. Helicopter view; going into detail when necessary. Driven to find high-impact opportunities and to solve high-impact problems once and for all.
This entry was posted in Avoiding Traps, Best Practice, Bridging the Gap, Bureaucracy, Change Management, Constructive Dialogue, Effective Solutions, Leadership, Lessons Learned, Management, Project Management, Root Cause Analysis and tagged , , , , , , , , , , , . Bookmark the permalink.

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

  1. Reblogged this on Get "fit for randomness" [with Ontonix UK] and commented:
    Add 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

    Like

  2. Max Pucher (CTO ISIS Papyrus) says:

    Your experience and the implementation problems relate to all of ITIL.
    But it is a standard, so how can it be worng?

    Like

    • Hi Max,

      I’m a strong supporter of ITIL. That’s to say the practical version of ITIL. This was in production in the data centres I worked for. Clients were more important than processes. Process descriptions were half a page. Processes, tools and people functioned as a single system. It worked really well.

      When then clients wanted compliance with the official ITIL, the practical ITIL was replaced by the formal ITIL. Apart from the bureaucracy it brought along, it worked and still works pretty well for the highly repeatable things. The official ITIL was, however, developed when IT was relatively stable. Starting in the mid 1990’s, IT environments became ever more complex and dynamic. ITIL missed the functionality for unpredictable situations. ITIL V3 came to replace the theoretical V2 (the theoretical V2 aspect was part of the marketing for V3). V3 came with the right messages. What also came with V3 was the baggage of V2. With that, V3 missed vital features for the unpredictable situations, as well as do’s and don’ts.

      How to make ITIL suited for complex environments? Agile manifesto (http://www.agilemanifesto.org) provides leading principles by which it can be implement in a more practical way.

      Like

  3. Pingback: Getting to the root cause of wicked problems | Third Coast Complexity Blog

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s