Zombie Solutions — An Enterprise Nightmare

John’s team has been chosen for greatness. The opportunity: to facilitate their client’s customer service modernisation.

The problem to solve: the customer service department needs to be able to “see what their customers see” in order to maintain a high level of quality.

They explain that their old content platform had a mirror platform customer service agents could use to click through all the screens — to “see what the customer sees,” but with the new system, that feature is gone. John and his team jump right in — eager to slay a dragon — and quickly learn the initiative has actually been running for a while. In fact, three separate attempts over the course of 18 months, all under the same project name — Adviser View — have been made to address the need within the new system:

• First came an idea to give customer service advisors permission to log in as the customer. This turned out to be too expensive an architecture change, and created many security and governance issues.
• Next was the purchase of an extremely costly screen sharing platform from an enterprise vendor. Besides integration and reliability issues, trials were not able to find sufficient need or engagement from customers to justify the cost and effort of full integration.
• Finally, a customisation to the platform was considered that would generate screen flows which, again, faltered due to cost.

For a short while, it seemed that the project would be shelved, and everyone breathed a sigh of relief at not having to deal with the nagging problem. But customer service problems persisted, and the rising costs were now creating an alarming sense of urgency. Hence the great “opportunity”.

The original excitement at getting to be a bit of a hero was turning to dread. John asked himself and eventually, everyone around him the obvious and highly taboo question we all ask ourselves sometimes: “Why, exactly, are we doing this?”

No one seemed to have a good answer, despite the fact that everyone was sure that the thing definitely, absolutely, had to be done. John’s team agreed — this surge to greatness was becoming a nightmare. The thing just wouldn’t die, nobody knew where it came from, and didn’t have the power to kill it. But it was now his problem. Sound familiar? We see this time after time in big enterprises. Technology efforts can often persist so long that the original problem or circumstance has either changed or gone away. Sometimes the original problem wasn’t even validated. Now there’s no way to trace it back, and the project’s taken on a life of its own. We call it a Zombie Solution.

How to spot a potential zombie solution

Zombie solutions often rear their heads when we’re given ownership of an already existing programme or project, especially one that’s had problems in the past. You start working on a project and you may soon begin to get an uneasy feeling. Perhaps you think it’s a shortcoming on your part — that you don’t “get” what’s going on — and give those already involved the benefit of the doubt. But when you start to dig, you may find some of the following:

• The project is named after a technology or system, rather than the problem it’s meant to address, for example: “Provide the New Technology Project”
• The project is named in relation to some legacy system, such as “Old System Replacement”
• The effort has been going on for a long time, and probably changed names or teams and leadership more than once
• The people who the effort is supposed to be helping haven’t been consulted
• Worse, the people who the effort is supposed to be helping don’t want to be involved, they only want the product of your work. They are definitely sure it’s the right thing, and it’s definitely urgent

How do zombie solutions happen, and why?

It’s important to understand how zombie solutions happen in the first place, so that you can identify them and move on from the confusion. You have to start at the top. In very large enterprises, decision-making is often one or two layers of management from the “facts on the ground”, so there can be problems at the executive level:

• Time and pressure to perform will nudge executives toward “quick” fixes
• They tend to rely on what’s worked in the past
• Enterprise-wide solutions are preferable to looking into details because doing so might seem like fighting many small fires or taking on risk
• Executives can confuse their abilities as experienced decision-makers and managers with having technical expertise.

At the director and middle-management layer, the problems carry over, but manifest differently:

• The effort it takes to get C-level buy-in creates momentum that someone must take responsibility for, and players may not want to put their personal reputation on the line to stand behind their decisions to take a project in a new direction.
• Decisions can be a one-way street, so new information that contradicts executive decisions is often minimised.
• Players may become trapped in the notion that it’s important to be a team player — it’s more important for things to move forward collectively than to solve problems or do the right thing.

So, leaders are doing what they are meant to do, providing direction based on their experience, and middle managers are doing what they’re meant to do, implementing based on their abilities. Add to the mix that enterprises can have a slow pace of change, and now you have a dynamic where new information is likely to come in, but more likely to be discounted because the cost to the individual may be the risk of social ostracism. Amplify this scenario across a big enough group and now you’ve got a shambling Zombie Solution that’s taken on a life of its own. Run, John, Run!

But what can you do?

• Recognizing that there is an underlying problem is always the first step.
• Identifying the underlying problems, following the power dynamic, and framing those issues in terms that matter to executives, is the next step.
• Start by corralling your leadership and getting them to agree on what problem is being solved, and the expected benefits. If they can’t agree on the problem, you shouldn’t be on the hook for delivering the benefits.

One of three things happens at this point:

• The benefits to solving the problem are agreed upon, but there’s no clear path to attaining them. In other words, the exact problem needs to be worked out so that a solution can be put in place.
• The benefits and problem are agreed upon, but can’t be measured. In this case, you re-focus the effort on ensuring that the cause and benefits are measurable. Providing the ability to measure is often an improvement to the entire organisation.
• Alternatively, the benefits and problem can’t be agreed upon. Here again, you’ve provided value because you’ve identified the root issue, that the problem has not been properly defined. Rather than trying to deliver something with no foreseeable end, you can move to defining the problem.

Back to our hero, John. After pursuing Zombie Solutions for well over a year, something had to change. John knew he needed to address the issues methodically to get clarity on what problem(s) his team should put their efforts into solving. He managed to get enough C-level buy-in to do some research. What John’s team found in their research was that there were in fact several problems that could be solved by different interpretations of “seeing what the customer sees,” but most often they could be solved without actually “seeing what the customer sees.”

• A great majority of the problems were related to authentication, and that once customers were registered or logged in, everything was fine. Many of those problems could be solved through improved UX.
• Because of pressures to service clients at a certain rate, time for training had been cut down to almost nothing, preventing the advisors from having sufficient time to understand the new system.
• In some cases, it was true, that it would help to see what the customer sees, but these instances were spread across the system and difficult to pinpoint in any one customer area.

John now understood how this initiative’s Zombie Solution came to be. Looked at as a whole, under pressure to perform, customer service agents with insufficient training and understanding of the new platform were asked what the problem was, and their response was naturally the most obvious thing that had changed, that they could no longer could “see what the customer sees.” The failures were systemic

• Given a problem, the people closest to the problem communicated a narrow solution, based on their understanding, in a narrow context.
• Middle and upper management didn’t verify that the proposed solution was matched to the problem at hand; they accepted it because it had worked in the past.
• The technology team charged with implementing the solution was just doing their job, providing a technology solution to a problem put in front of them.

John succeeded where others failed because he was able to approach the issue from the ground up and logically investigate and verify the sources of the problem, rather than blindly embark on a Zombie Solution journey. Remember — it’s never too late to verify why you’re doing the thing you’re doing. If you feel you may have a Zombie Solution on your hands, consider tackling the problem by doing the following:

• Do research to investigate what problem the solution is meant to address
• Break the effort down into component problems
• Go after each problem on its own – this requires cross-organisational effort.
• If it’s an enterprise problem, give it that level of support and attention, but make sure you’re addressing it in the narrowest context first, to prove the case.

Being a good Zombie Solution spotter won’t save your life, but it will save you and everybody around you a lot of pain.