FRIDAY, MARCH 24, 2017
Font Size
Industries Software/IT Tailoring Six Sigma to Software Development

Tailoring Six Sigma to Software Development

As the popularity of Lean Six Sigma techniques expands into software and technology environments, the notion that these methods and tools can provide a quick fix, unrealistic results or a panacea (for all that is wrong) has been proliferated. Some of these notions are further compounded by the reality that many of these environments are at a low maturity level with regard to process stability, repeatability and even basic measurement. Software and technology processes are often the result of a start-up mentality or organization.

These dynamics complicate – and are even counterproductive to – a conventional Six Sigma deployment approach that a typical manufacturing or service organization might use successfully. This reality must be taken into consideration to develop an acceptable approach to successful implementation. By carefully studying the actions of early adopting organizations and characterizing each individual organization’s needs and culture, analysts can design and implement a deployment strategy that is more finely tuned and has a higher probability of success.

Assess and Characterize

It can be useful to quickly assess and characterize an organization prior to jumping into any scope of Lean Six Sigma implementation to minimize risk of failure. One quick way to think about this characterization is to consider:

  • Organizational history, culture and age
  • People and knowledge (especially leadership)
  • Improvement process experience (successes and failures)
  • What must be accomplished (and when)
  • Process and measurement system maturity

These guidelines, coupled with some experienced objective advice (either internal or external), can help analysts to quickly identify key considerations and a proper path for Lean Six Sigma deployment.

While some organizations are ready for full-blown deployments, others may need to do some preliminary work on process stabilization, measurement systems or project selection. Leadership may need training, and resources will need to be allocated and organized. The Lean tool set is particularly useful, especially with low process maturity levels that have never been mapped or streamlined. Even workflow organization can be a good stabilization starting point. For many organizations, laying this ground work places a solid foundation from which to build better and faster Six Sigma results for the long haul.

One Size Does Not Fit All

Examining the processes and results of two organizations can reveal some best practices and pitfalls in implementing Lean Six Sigma in software and technology environments.

The first example concerns a software development company. It started with a small wave of Black Belts, completed two significant projects (multi-millions in savings and market share), and parlayed that into a full-blown, organization-wide Six Sigma deployment. The deployment has yielded tens of millions of dollars in savings and significant market growth.

The second example concerns a medical devices company with a software development department. The company trained software engineers using a manufacturing-based Six Sigma curriculum and failed to complete a single project in one and a half years. The company is currently retraining its engineers with a software-based Six Sigma curriculum and is completing its first wave of projects.

Laying a Solid Foundation

The software development company had made several attempts at general quality improvement, in pockets, based on customer complaints and organizational pain. Some small, short-term gains were realized, but in general the efforts evaporated and were written off as another failed corporate initiative. The pain, however, persisted, and customer calls to improve were increasing.

Finally, the organization hired two key outsiders to top leadership positions, both with deep operations and Six Sigma experience (from Motorola and GE). What they saw was an organization that had a desire to improve, a reasonable historical database and very good people. The company also had a skeptical CEO who had a low tolerance for another failed initiative. For these reasons, the organization took a proof-of-concept path, training just a few Black Belts in a software-specific Six Sigma curriculum, but being sure they were the top people in their areas. They also selected highly important projects, which if successful, would make a big difference to the organization and win the CEO’s full support.

Of course, the risk to the two individuals was high if this failed. They had confidence from their previous experiences, however, and permission from the CEO to proceed. They made sure that they freed their Black Belts from all other commitments and gave them access to the resources they would need to do their jobs. Schedule flexibility was granted to allow time for proper analysis work to be done.

In one of these early projects, a simple measurement system analysis (MSA), revealed why earlier improvement attempts had failed. The data was not accurate, leading to wrong conclusions and solutions. Quick hits were realized as a result and subsequent systemic issues were revealed and resolved. The result was several million dollars realized and a master Six Sigma plan implemented. The right strategy (proof of concept) was selected to minimize risk of failure based on the situation, experience of leadership and the needs of the business.

Moving Too Fast

The medical devices company is a large, global company with a very good conventional Six Sigma program. It recognized that the software development department was continually causing schedule slips and that released software was full of bugs and missing needed features. A Six Sigma approach was mandated, and without much hesitation or planning, Black Belts were trained using the corporate-approved company Six Sigma curriculum.

Project selection was weak and suffered from scope creep because the ambitions of these projects were too big and too broad. The problem was that this curriculum was manufacturing based and did not account for the fact that the software development department’s process and measurement maturity was significantly lower than its counterpart systems in manufacturing departments. Meaning, there was very little data to work with and an unstable process.

The company also did not consider scope when selecting the initial projects, setting up the candidates for possible failure. Leadership lacked the requisite skills and experience to recognize something was wrong and continued to try to drive the process, not fully understanding why this worked everywhere else except in the software development department. Finally, after getting some objective advice and feeling the need to improve, a Master Black Belt was hired from the outside to get the process on track.

The Master Black Belt quickly realized that projects needed to be re-scoped and aligned to critical business issues, and the Six Sigma tools needed to be expanded and aligned to the software development process (requirements, design, coding, testing, and release). Some projects were scrapped and others were redefined. Additional software-specific training has been brought in, expert coaching has been provided, and projects are now nearing successful completion.

The Master Black Belt also realized that for long-term success, the process and data collection systems needed to be streamlined and organized. Using Lean principles tailored for software development, the organization has been running kaizen events, creating value stream maps and creating a stable and repeatable process with consistent measures.

This two-pronged approach of making the process Lean and creating software Black Belt competencies is starting to yield the result the organization aspired to one and a half years ago. With better upfront assessment, characterization and understanding, the organization might have avoided a lot of this rework.


While there are many factors that contribute to the success or failure of Lean Six Sigma projects, it is important to make informed deployment plans and be sure to consider some basics, even if it means delaying the training until an environment for success has been created through some of the smaller steps outlined in this article.

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

Login Form