This is a process for working with executive teams trying to solve transformational business problems--many of these problems are the result of recent dramatic changes in the economy.
This process was designed for multi-variable, cross-functional problems that are difficult to solve within functional silos. They usually cut across the company. They stretch the skill levels of the functional specialists with a vertical focus. The problems are lateral in nature.
Often the problems are poorly defined, not well understood, and as a result...the work to find solutions is inefficient (at best) unless organized. This presentation discusses a way of working with these teams to define and solve these problems.
In this presentation I’ll provide an overview of a process we have been deploying with executive teams working on major strategic changes to their organization. These have included restructuring to align with a changing economy to innovative breakthroughs in the way the company does business. Many companies today face major structural changes in order to adapt or some to survive. This process is an effective technique for harnessing the creative brain-power of executive teams and generate real results. We call it “structure, converge, deploy.” Normally, we bring together 5-15 senior executives in multi-week projects to define solutions and chart their deployment. It is a formal process of classroom training, independent research, and intensive group working sessions.
The broad areas include idea generation, problem definition, modeling alternatives, “managing” consensus, and then realistically planning deployment of the recommended solutions. When we say “plan,” we mean a process to seriously look at the impact of the solution recommendations in terms of barriers to implementation, and what needs to be done to remove them ahead of the changes being put in place. Moreon decision modeling.
The problems these executive teams are given cover a broad spectrum of the business from how to change the innovation process to how to gain market share in maturing or declining segment. This process was designed for multi-variable, cross-functional problems that are difficult to solve within the functional silos. They usually cut across the company. They are lateral in nature. They stretch the skill levels of the traditional functional specialists. Often the problem is poorly defined, not well understood, and as a result... the work to find solutions is inefficient, at best, unless it is organized. Let me explain...
There are usually a few alternative solutions on the table when these problems are presented to the solution team. Sponsors have some idea in mind about the solution they want and how to get it. The first challenge is to avoid being channeled into THE solution before the problem has been well enough defined. First, consider the WHAT (you are trying to achieve) rather than jumping right to HOW it will be fixed. Most want to start with the HOWs, this can be a recipe for failure.
Starting with the end-in-mind, we define the end-state condition. This helps us articulate the objectives and the specific goal that is to be achieved. It is important to cycle back to the problem sponsor to confirm your definition is right. The goal or “problem statement,” might be something like “grow market share while developing a technical eco-system where we can share the cost of innovation with a distributed development network.” Some objectives in reaching this goal might include “reducing R&D costs, becoming strategically agile, and maintaining market leadership.” These objectives are important later in the process as their weighting will influence the various solution alternatives the team generates.
Idea generation takes many forms. These include facilitated brainstorming, researching external sources, and the most important… your customers. Customers have most of your solutions, if you just ask them. This process generates lots of ideas around problem solution alternatives. This is the diverging stage of the process where all ideas are Green-lighted, regardless of their perceived quality. We seen tens and sometimes hundreds of ideas formulated at the “divergence” stage. It is important to carefully design the assessment “instruments” so the data gathering is focused and efficient.
Normalize, Organize, Structure
All these great ideas usually come in different forms or “artifacts.” For this data to be of value it needs to be normalized and made consistent. We use a number of techniques--one is to use a mind-mapping process in facilitated groups, to hierarchically structure the information around a central topic. In this case, this is the goal statement. For example, our goal might be to “double margin and create a lower cost profile.” The next level out from the central topic may be 5-10 initiatives that drive the goal, the next layer out may be the strategies to enable each initiative, and then within each strategy may be specific programs, and so on. This hierarchical metric provides a framework to normalize the information, and to identify holes and inconsistencies. Further, cross-hierarchy relationships can be drawn to see how each are connected. This visual map provides a single place to see all the information and drill into its detail or boil it up to the big picture. At this stage clients also take this map back to the sources like customers, industry thinkers, internal innovative thinkers and validate the ideas. “This is what we heard you say..,” and so on. This generates a few change iteration cycles which improves the quality of the information and the team’s understanding of the problem. We call this “getting grasp.”
The mindmap provides the structure for the decision model. Here we are trying to evaluate each solution idea or alternative in terms of how it bets meets each of our objectives, which should then drive the goal. This is facilitated, interactive and sometimes a heated discussion within the solution team, especially when the members are all executives. This dialogue and discovery is critical to understanding the problem, the objectives, and the possible solution alternatives. This provides an objective framework to focus energy on the data and away from personalities, position and/or expert power. Sometimes when the cost of the solutions are know, we can prioritize the solutions based on the ones that generate the greatest benefit at the lowest cost. We can also consider other constraints like resources and risks, but this is only when this information is available.
Potential Problem Analysis
The decision model generates a set of “winners” or winning ideas that most contribute reaching the goal. Depending on the problem, we take the top 3-4 ideas and subject them to further analysis. The first is a potential-problem-analysis or PPA. We want to explore all the potential problems we could have in implementing the idea. For each problem, we identify likely causes and preventive/contingent actions to mitigate the problem before it happens. Some times this results in a top idea being dropped down in priority. PPA forces the team to be “critical advisers” and try and find all the reasons why something “can’t work.’ If the ideas survive, they are better and the team has a fuller understanding of the future deployment issues.
Force Field Analysis
Force-Field-Analysis or FFA, developed by Lewinat MIT years ago, is a great tool to understand how to deploy an idea or solution to a problem. Lewin said there were always at least two forces acting on change, drivers and restraining forces. Most people push harder on the driving forces to cause change, while Lewin observed that by removing restraining forces, or barriers, one could move an idea forward in an organization. FFA as we use it, is a way to identify those barriers and discuss how they could be eliminated or at least neutralized to create change or advance an idea. Removing these restraining forces become part of the deployment plan.
Plan and Deploy
We’ve generated ideas, prioritized the ones that can have the greatest impact, we’ve explored barriers to implementing these new ideas, now it is time to lay out the action plan to get them implemented. This process involves defining the macro steps, duration of each stage, dependencies between high level activities, and the resources that are needed to accomplish the goal within the target solution time-frame. The trick is to identify the gap between when the solution is required and when the solution can be delivered, given time, cost, and resources constraints. This is yet another trade-off model that engages the team in defining and making trade-offs to compress the schedule to meet that target time frame. Like the decision model, this “schedule model” provides the same simulation benefits--as the flight simulator does for the pilot. The deployment schedule provides the roadmap to manage and track the implementation of the new ideas.
We generate ideas, structure the problem, model and decide, and plan the deployment. It is never the same and this process varies widely from client to client. We know from experience that it has to be adapted to the readiness and maturity of the team in order to be effective. It provides a structured and repeatable process that successive solution teams can use going forward. The tools and methods can be applied to just about any problem that can be articulated, has an impact, and has a time-frame within which it needs to be solved.