SATURDAY, DECEMBER 20, 2014
Font Size
New to Six Sigma DMAIC Continuous Improvement Should Apply to DMAIC Itself

Continuous Improvement Should Apply to DMAIC Itself

All practitioners of Six Sigma – even those new to the methodology – are aware of the basic DMAIC roadmap. The starting point for every Six Sigma program is to explain the acronym and to teach the common principles of DMAIC. “Define, Measure, Analyze, Improve and Control” becomes the mantra for new Green Belts and Black Belts.

  • Define is the documentation of the opportunity from both a business and customer perspective.
  • Measure is the way data is utilized to understand the process and its current performance.
  • Analyze is the search for key factors or the critical data that has the biggest impact on the process performance and helps determine the root causes of problems.
  • Improvement is the development of solutions for those critical data points that eliminate or mitigate the root causes of problems.
  • Control is implementing solutions and a control plan for maintaining the improvements.

DMAIC is a process unto itself that can be – and should be – improved in each organization that uses Six Sigma as a critical component of continuous improvement and quality initiatives. The tenets of DMAIC provide context for executing continuous improvement and are not meant to be rigid or used exactly the same way each time. There are many tools and deliverables that fall under the umbrella of DMAIC, and not every one of them is used in every single project.

Nuances that are found in every company’s culture influence how Six Sigma, and DMAIC in particular, is executed. For example, both financial services and manufacturing companies may have processes that need to be improved, yet a given tool may be more appropriate in one environment than in the other. And, all service organizations are not the same in that each has its own history and philosophy about how change should occur.

What is true for each organization is that the DMAIC process will evolve as a company becomes more sophisticated in its use and more knowledgeable about what does and does not work in its own environment. Thus, the DMAIC process itself can be improved by capturing and sharing “lessons learned” and “best practices” from each initiative to be passed on to future initiatives. Formalizing the capture of lessons learned and best practices and integrating them into the company’s DMAIC documentation and training is a tremendous value-added step for any Six Sigma program.

Capturing Lessons Learned and Best Practices

Lessons learned are, by definition, additional information discovered during the work effort – something that was not known before. These may be either actions that had positive results, and thus should be repeated (and perhaps considered as best practices); or they may be actions that had negative results and indicate areas for improvement. Lessons also may be learned from accidental or intentional innovations – trying something new or different. A best practice is a lesson learned or innovation that produces results so positive, and which is so widely applicable, that the action should be considered a model for others. Enough analysis needs to be done on the positive results to be able to demonstrate that the results were due only to that action, and not to some other external cause or influence.

When capturing lessons leaned and best practices, the Green Belt or Black Belt project leader should consider the scope of the recommendation as well as any assumptions made in order to perform the evaluation. Since lessons learned and best practices can be identified at any point in the DMAIC process, it is important to clearly state the scope of work for which the lesson learned or best practice was evaluated. The scope may be as simple as a single phase (e.g., Analyze), a set of phases (e.g., Define through Analyze), or an entire project cycle. Assumptions that are made to perform a valid evaluation of the submitted best practice or lesson learned should be documented as well. These assumptions usually fall into the categories of people, process or technology – which happen to be the three aspects to consider of any improvement process.

It may seem like overkill, but having a team of Six Sigma leaders evaluate formally submitted lessons learned or best practices is something to consider. Communicating these lessons learned and best practices by word of mouth may cause more harm than good. A single focal point of evaluation and integration into the adopted DMAIC toolkit for a given institution makes the dissemination of that information more consistent and more accessible to a wider audience. The power of the lesson learned and best practice is found in the ability to speed up the DMAIC process by eliminating steps that have already been proven to be wasteful, and by reducing variance in the selection of tools by already understanding which ones have worked in the past. It sounds a lot like the basic principles of Lean and Six Sigma itself.

Documenting the Lessons Learned

In the Six Sigma philosophy, data forms the basis for improvements. So it is important to describe the data which indicates whether a lesson learned is valid and whether it might be considered as a best practice. The documentation of a potential best practice or lesson learned is supported in large part by the data collection and measurement plan (DCMP), which is provided for the data upon which recommendations can be made. If lessons learned are based on data collected under that plan, it may be as simple as referring to the appropriate section of the DCMP. However, some information specific to lessons learned (e.g., personal/anecdotal feedback, suggestions, etc.) may not be included in the DCMP. This additional data needs to be described by the Belts using common sense language.

Project measurements also are vital to documenting a potential best practice or lesson learned. Project measurements are observations that can be applied only and specifically to a single project, or a single execution of a process. If, over time, project measurements are shown to represent a trend, then the entire set of data can be considered a process measurement. In addition, if the project measure represents multiple executions of a process in a single project (e.g., a project gate review), then the measure may also be considered a process measure. Normally, project measurements do not necessarily indicate anything (good or bad) by themselves. There can be many contributing factors that must be taken into account before a systematic change is made or lesson learned/best practice designated. However, project measurements provide a valuable starting point for later detailed investigation.

There are three components that must be provided for each project measure – name, description and data collection. A name identifies the measure, e.g., “phase cycle time.” The description explains what the measure represents (why it is important) and provides its current values or the measurement (e.g., the number of calendar days between start and end of phase). Finally, the question of how the data was collected (e.g., by using the project tools, customer/staff survey, anecdotal feedback, interviews, etc.) must be answered.

Process measurements also are valuable when describing a lesson learned /best practice candidate for the DMAIC process. Process measurements are observations about a process that has been executed multiple times (e.g., by many projects or many times in a single project). These measurements may show consistent trends or even high variability that needs to be corrected by systematic changes. Similar to project measures, the same three components – name, description and data collection – must be included for process measurement.

Critical-to-quality metrics can be invaluable in the documentation of a lesson learned/ best practice. These metrics come from the analysis and comparison of two or more measurements to add meaning to raw data. For example, if one person provides a certain feedback comment, it is only a single measurement and does not have any significance attached to it. Another example would be lines of code. By itself, the number of lines of code produced does not mean much. However, lines of code per day is an important productivity measurement. When documenting key customer or process metrics and their role in a lesson learned/best practice, it is important to describe the analysis that was done on the project and process metrics in order to develop an ultimate recommendation. This description might include how the data was prioritized, categorized, validated, and how they compare to previous or benchmark metrics.

Conclusion: Description and Recommendations

The actual buy-in of a recommended lesson learned/best practice from a Green Belt or Black Belt to the owner of the overall formal DMAIC process in a Six Sigma program ultimately comes down to the description of the conclusions that were reached as a result of the analysis, and any recommendations about what should be done. That is why it is extremely important to indicate any next steps or action plans. This information can then be used if the recommendation in the form of a lesson learned should be considered for a best practice and/or leveraged to other project teams and integrated into the effort of continuously improving the organization’s current DMAIC process.

Register Now

  • Stop this in-your-face notice
  • Reserve your username
  • Follow people you like, learn from
  • Extend your profile
  • Gain reputation for your contributions
  • No annoying captchas across site
And much more! C'mon, register now.

Leave a Comment



Comments

JB

Good 6-sigma article regarding best practice and KM

Reply

Login Form