Why Change?

When implementing improvement systems that impact business processes and require methodology and tools; you must first define the problem you are trying to solve. Often we see organizations start with possible solutions without first define the business problem they are trying to solve.

They get enamored with technology (perpetuated by software vendors) and lose sight of the desired end-state, since the end-state was never defined. In the worst cases, the end-state is defined by software vendors as the attributes of their software solution.

The ‘end-state” can also be called the “Why Statement.” Why do you need to make the change? What is not working the way you want it to now? What is the gap between the as-is and should-be? What if you didn’t make any changes, what would be the impact? The “why?” statement is also the overall goal for making the improvements in systems and processes.

Next you must define the Improvement Objectives. These are the 3-5 specific outcomes you want/can measure with the improvement intervention. We typically prioritize these objectives using a pairwise comparison of each objective to determine which objectives are the most important. This is a metric by which the improvement program can be measured to determine if it is achieving the goal. In other words;

What is not working and what would it look like when it was working right?

Once the “Why” is defined and the “Whats” are articulated, the different alternatives can be considered. These are “How” you want to achieve the objectives. There can be many ways to achieve the improvement objectives, which is why you don’t start with a single HOW and work from the bottom-up.

We see organizations start with HOW, and then get lost in the details. They never answer the most important question, “Why are we doing this?”

An example of a lateral portfolio system

This (above) is one of many possible solutions. The problem statement that provoked this possible solution looked somewhat like this:

• Marketing has significantly more requests than available capacity (in engineering)

• We need a way to structure/prioritize products and/or requirements(features and associated costs to develop)

• We have no formal method to model trade-offs or do scenario analysis (platforms, products, features, budget, resources, ROI)

• We can't see the impact of new projects on the existing projects in the pipeline

• We accepted just about every project that we look at

• Most of our projects finish late

• We are chronically under-resourced and we lack certain critical skills

• Our decision-making is ad hoc and not well organized (i.e. not clear who "owns" the decision)

One possible solution combines methods and systems as well as skills development and it also has organizational impacts. However, when this is looked at alone, it, in itself does, not make sense unless you also understand the context. In other words, what problem does this solve? A solution must be considered in the context of the problem and why that problem should be solved now. Seems obvious, but doing it top-down is rare, based on our experience.