Comparing and contrasting the way different disciplines and tools map to one another can help lead to a better understanding of each of the things being compared. This paper reviews a methodology called IDEALSM, which was developed and evolved by members of the Software Engineering Institute (SEI), and compares it with the Six Sigma DMAIC roadmap and thought process. After a brief review of IDEAL and DMAIC individually, this article examines ways they are similar and ways that they might challenge and inform one another.
The Software Engineering Institute and IDEAL
The SEI has long fostered work in software process improvement (SPI). In response to requests for more guidance selecting among improvement alternatives and getting improvements readily adopted, a team developed the first incarnation of IDEAL in about 1993. The roadmap and substantially current model of the process took shape in about 1996 (Figure 1).
In a nutshell, the IDEAL acronym and key activities at each stage can be summarized as follows:
- Initiating
- Understand the improvement opportunity and its context and potential business value.
- Identify stakeholders and the first view of the infrastructure scope and risks that would be required for successful transition of the improvement.
- Diagnosing
- Describe the current and desired states.
- Explore the opportunities and solution alternatives.
- Develop recommendations.
- Establishing
- Identify tasks and responsibilities.
- Set priorities.
- Acting
- Pilot the improvement.
- Learn from the pilot and refine the plans.
- Implement the refined improvement.
- Learning
- Monitor and control the ongoing inputs and outputs.
- Diagnose early warning signals and adjust and control as needed.
- Learn from the ongoing process and make next recommendations.
One can see at a glance that IDEAL is constructed in a way that presumes at least an initial sense of a solution at the outset. That is likely one reason that IDEAL is often referred to as a transition process (more than a problem-solving process).
DMAIC – Quick History
For Six Sigma Belts, depending when they were trained in Six Sigma, they may or may not see DMAIC as having been a core element from the beginning. In the early days, there were the Six Steps to Six Sigma and then an evolution to MAIC as the core roadmap and methodology. As teams underlined the importance of understanding the problem and related goals and scope, a Define stage (D) was added to make DMAIC for many companies. An outline view of DMAIC is provided in Figure 2.
Strength vs. Weakness Orientation
IDEAL is strength based, meaning that it focuses on improvement ideas and an ideal state, driving the planning, piloting and ongoing control connected with bringing that improvement to reality. DMAIC, in contrast, is inherently weakness based, meaning that it focuses on reducing costs or cycle time, driving the use of facts and data to uncover causes, and only then does the focus swing to solutions and implementation.
At first, this distinction may seem a little arbitrary. After all, a strength-based project goal like “improve customer satisfaction” and a weakness-based one like “reduce complaints” are just two ways of saying the same thing. While that may be true on the surface, there are implications that the choice of one over the other can have on the way a team thinks about data and learning.
Increasing yield, which is listed in Table 1, is a good example of a strength-based goal that was popular at Motorola before Six Sigma. Since yield is the proportion of units that survive a manufacturing process ready to ship, it summarizes performance. If yields suddenly dropped from 90 percent to 70 percent, the numbers do not provide much diagnostic help to see where the problem is or what to fix. Strength-based goals encourage a team to lean toward ideas (about how to improve the strength) and the future state.
How might things be different for a team setting out to reduce defects? First, their view is more detailed. They are looking at the defects within the units. This was the most fundamental shift that Six Sigma brought to Motorola. This team would tend toward facts and data (What are the defects? Where are they happening?) instead of improvement ideas. Their metrics would be more diagnostic. When defects of a certain type move from one per week to three per week, there is some information about what is wrong and what to fix.
A last contrast to make involves the reporting climate in an environment. People know when their bosses want to hear good (strength-based) news, and they tend to put the “best face” on data being reported at all levels. This can submerge and subdue details, sometimes to the point where leaders don’t see details that could have previewed or mitigated trouble that surfaces larger and later. On the other hand, companies that see the value in weakness orientation invite the details and the gritty dirty laundry in order to get down to fundamental causes and drivers at every opportunity.
See how that distinction plays out as the discussion of IDEAL and DMAIC continues.
| Table 1: Weakness vs. Strength Orientation in Problem Solving | ||
| Weakness | Strength | |
| Example | Reducing defects
Reducing complaints Reducing delays |
Increasing capability, yield
Increasing % satisfied customers Increasing throughput |
| Use of Metrics | Diagnostic metrics
More detail: Defects within units Details support root cause analysis |
Performance metrics
Less detail: Defective units Rollups that summarize performance |
| Focus of Team | Facts, the past and present
What are the defects? Where are they being found? |
Ideas, the future
What can we do to improve customer satisfaction? |
| Impact on Reporting | Surfaces real issues
(Dirty laundry okay) Focuses on improvement |
Good news tends to filter out detail, favors the best spin |
| Table 2: Summarization of IDEAL and DMAIC Similarities and Differences | ||||
|
IDEAL |
Comparisons and Contrasts |
DMAIC |
||
| Initiating | Set context
Build sponsorship Charter infrastructure |
IDEAL begins with a stimulus for change. While IDEAL and DMAIC seek to quantify business impact and align sponsors, IDEAL may focus more on the benefits of implementing an improvement that is at least partly in view at the outset.
DMAIC discipline focuses first on understanding the problem (to avoid jumping to a solution). DMAIC emphasizes the importance of results measures and targets. |
Charter – goal statement; business case
Survey the problem and its context – processes; requirements |
Define |
| Diagnosing | Characterize current and desired states
Develop recommendations |
While nothing would stop and IDEAL team from applying some of the DMAIC rigor to identifying prospective causal factors, building trustworthy measurement systems and gathering facts and data shed light on what is going on. There is not a lot of specific guidance about that.
DMAIC brings graphical, statistical and logical tools and infrastructure for guidance in their proper use (with the Belts system). DMAIC pays strong attention to holding off on solution thinking and recommendations until there has been some real fact-based learning about the causes or drivers that can be verified to influence the project results measures. |
Identify factors and causes that may be influential.
Challenge the measurement systems that will be needed to convert raw events into useful facts and data. Gather facts and data to shed light on root causes and drivers. Use (patterns and contrasts in) the data to learn what is driving the project Ys – the critical results measures. Verify key causes and drivers. |
Measure Analyze |
| Establishing | Set priorities
Develop approach Plan actions |
DMAIC brings discipline about not jumping to a solution or even into the solution selection process by paying attention to the breadth of alternatives and the rationale used to select among them. | General solution
Alternatives |
Improve |
| Acting | Create solution
Pilot/test solution Refine solution Implement solution |
Considerable common ground here.
DMAIC brings some useful discipline and guidance about creating an effective transfer plan. |
Select best solution
Pilot the solution Refine the solution Plan to transfer control |
|
| Learning | Analyze and validate
Propose future actions |
IDEAL pays considerable attention to the ongoing learning that is possible – and necessary – during the implementation and ongoing monitor/control of a particular improvement. That broad view of learning could be helpful to supplement the DMAIC view, which is often more narrowly focused on measures-based, statistical views of control. | Track the ongoing stability and success of the transferred process.
Learn from the process – to do DMAIC better next time. |
Control |
Summing Up
IDEAL is a strength-based transition model because it focuses early on desired state and developing recommendations. From there it devotes much attention to the solution planning, piloting and learning from results.
DMAIC is more weakness based, focusing on the problem (defects, delays, etc.) and the facts connected with it. More visible emphasis is placed on using measures to really get to the bottom of the problem (root cause and Y = f(x) dynamics). Nothing would stop a team from doing this under the Diagnosing stage in the IDEAL model, but the model doesn’t draw out and enforce that data-driven problem solving as rigorously as DMAIC.
IDEAL places more emphasis on ongoing monitoring and learning, after the solution is in place. DMAIC allows for this and encourages it in the Control phase, but with a focus on transfer of control back to process owners, it leaves the ongoing monitoring problem somewhat up to the reader.
In short, DMAIC could teach IDEAL a few things about front-end/problem-solving rigor and IDEAL could teach DMAIC about ongoing monitoring and learning.
Note: Some guidance on the IDEAL model was taken from The IDEAL Transition Framework – Speeding Managed Change by Tom Kimbrough and Linda Levine.
