CIOs and CTOs are faced with a plethora of issues ranging from corporate realignment to growth to shrinking budgets. Many have heard about Lean Six Sigma but given their busy state of mind, it is difficult for them to dedicate the time required to translate Lean Six Sigma successes in top manufacturing company’s to its application in their information technology (IT) and software groups (i.e., the way their organizations undertake, manage and measure their processes and work output).

These executives often hear – and sometimes accept – some common excuses for not engaging in a Lean Six Sigma effort in their organization. Many of the reasons for these excuses rely on traditional views and conventional wisdom, and are not fact-based. Providing CIOs, CTOs, Lean Six Sigma professionals and other managers some insight into these reasons and some practical ways Lean Six Sigma has helped others can only benefit these executives.

First, a Little Background

In the world of product, process and service improvement, a new critical component was introduced during the 1970s, information technology, (i.e., the ability to cost effectively use computers and software to acquire, store, process, control and even optimize basic business actions and transactions).

In parallel with this evolution was the increasing presence of mini/micro-controllers and other computing capability (driven by a variety of software programs) in products ranging from wristwatches to the space shuttle. In the early stages of this evolution, basic quality control and quality assurance practices were absent in software/IT. During the same time period, manufacturing, service, transactional and process/product design processes were being heavily scrutinized, measured and improved under the banners of total quality control (TQC) and total quality management (TQM). These processes and functions eventually began achieving performance breakthroughs as described by Dr. Joseph M. Juran in 1952 and institutionalized using the Lean Six Sigma methodology developed at Motorola in the 1980s.

It is interesting to note that while all of this was going on, software development and IT were left out of the mainstream quality effort of the period. Only recently, and at very low adoption rates, have quality assurance/quality control standards, performance metrics, control processes, analytical tools and management strategies become an important part of the software/IT mainstream.

According to the 2006 Mid-Year Update of the Carnegie Mellon, Software Engineering Institute, Process Maturity Profile for CMMi^® SCAMPI ™ V1.1, Class A appraisal results, which note the adoption rates and assessment levels on organizations that subscribe to the SEI/CMMi^® process standards, only 18 percent of assessed companies (4.8 percent in the United States) have achieved Level 5 (optimizing). And of those who have used the process at all, 63.8 percent are non-USA companies. Perhaps a more alarming statistic is that less than 1 percent of U.S.-assessed companies are Level 4 (quantitatively managed). This means that one of the most core fundamentals to driving improvement (measurement) is absent in U.S. software organizations. Web searches of major software and IT publications and organizations yield little information about the systematic improvement of these processes (using a quantitative approach) with many articles on the topic being years outdated and obsolete.

Many other articles have been written about why this has occurred. But there is a new wave emerging to apply the Lean Six Sigma methodology to software development and IT. Despite some well-documented early successes, many in the management ranks of software/IT disciplines – either through their own inexperience or just stubbornness – have developed a set of common excuses as to why Lean Six Sigma is not appropriate or likely to gain results in these domains. Here are four of the most common excuses, their associated organizational characteristics, and how the fact-and-data-based world of Lean Six Sigma helps software and IT organizations overcome them.

Excuse No. 1

“We do not have the budget or the time to support Lean Six Sigma.…We can’t afford it….We’re already working 60 hours a week.”

Attributes: What this really says is that these executives plan and manage so poorly that they probably over promise and their project will either be very late or will sub-optimize functionality. They have a history of finishing projects way over budget and then have the budget shutdown, so they are forced to cutback delivered features and functionality. In about 25 percent of these cases the client will cancel the project. Even in cases where an organization has a purported and robust quality assurance process, it is so laden with non-value-added (check-off) activity that it becomes a time sink. The real truth here is that this project or organizations cannot afford not to change. There is high risk that, if this is the excuse du jour for not improving, the project or even organization is already in the death spiral. Consider the outcomes of the continued behaviors described in Excuse No. 2. They drive a behavior of heroics, reactive actions, poor schedule accuracy and project risk. Eventually leading to project and organizational failure.

How Six Sigma Helps: Six Sigma, over time (six to12 months) and with management reinforcement, will change the way management and the organization in general, sizes, initiates and values a project. From a Lean perspective, development of process efficiency, elimination of non-value-added work, improved process flow and cycle time (not schedule compliance) will become key behavior drivers. Most Lean Six Sigma practitioners will only accept balanced business value measures as the true measure of project success. They will dismiss subjective or contrived project descriptions, metrics and preconceived solutions. Through an efficient and iterative chartering process, clients, stakeholders and the business will create a balanced view of a solution-free problem description. From that problem description (and some of the steps below) the project can now flow through an iterative process driven by facts and data until scope, budget and timing baselines are reliably determined, documented, measured and continuously improved.

Excuse No. 2

“If the going gets tough our experience dictates, more resources and heroics will get it done on time. Lean Six Sigma will get in the way.”

Attributes: This situation is most often predicated by poor planning of resources, lack of a quantitative understanding of project requirements and size, an inadequate review of design trade-offs and an artificial deadline based on experience, not data (sometimes referred to as schedule compression). The key notion here is experience. The industry experience in software/IT is horrible. As previously reported by many research experts, large projects have greater than a 25 percent failure rate. As much as 70 percent of this failure rate is attributed to requirements and planning failures. Does anyone really want to base decisions on that kind of experience?

How Lean Six Sigma Helps: Utilizing a common roadmap and approach such as Lean tools, Design for Six Sigma’s DMADV or IDOV, an organization is guided to consistently:

1. Explore requirements thoroughly (including often missed and important language data) to search for latent requirements, market differentiators and possible measures of performance. Tools include, KJ analyses, language data distillation, discussion guides and voice of the customer (VOC) data transcripts.
2. Convert requirements to data and performance measures to assure that design performance outcomes are measurable downstream. This will help to create short cycle quantitative feedback loops to optimize performance and reduce long-term risk.
3. Create a quantitative base of data relative to project scope, size, quality, resources and design trade-offs. Use this data to determine and negotiate schedule and deliverables expectations with the client so that more realistic and reliable schedules and resource allocation is executed.
4. Create concise project tollgates to serve as an efficient data driven review of project deliverables and roadmap guidance.

Excuse No. 3

“Software and IT can’t be measured… measurement is the basis of Lean Six Sigma…So it doesn’t apply here.”

Attributes: This is an old cop-out and the one of the least supportable excuses. But still it is often used. It is usually supported by the notion that software/IT is art as opposed to process-driven work. The basis of all work (yes, even art) is that, it is completed by following a process and using tools. An artist must select and prepare colors, brushes drive textures, timing of brush strokes creates desired effects and so on. A musician must maintain an instrument, calibrate it by tuning to a standard, document it through musical scores, etc. Once these processes are enabled art can be initialized and fulfilled.

Similarly, software development and IT should follow a process and may have hundreds of measurable performance characteristics. Companies just need to prioritize their importance, select the value-added ones and agree that these will drive the desired outcomes. In a 2002 NIST report, at least 50 key metrics for software/IT were identified and many more have been successfully used. So metrics and cases of their value-added use are there.

Many times this excuse is further perpetrated by previous experience with non-value-added metrics. These are usually activity-based or compliance-based metrics as opposed to operational or results-based metrics. These experiences leave a bad taste in the mouths of people who were required to keep track of data and activities when it was widely known the data was never used.

How Lean Six Sigma Helps: Six Sigma assures that only value-added metrics are used and that the rationale for those data collection activities are clearly communicated. Six Sigma begins all project work at the business level, quickly moves it to a process level and then systematically determines the key metrics and drivers of success. An age-old statistical notion Y=f (X1, X2, X3…) helps to convert a process problem into a statistical problem so that tools may be applied to determine critical Xs (root causes). This moves companies from a “shotgun blast” approach to problem solving to a highly targeted “rifle shot.”

Once data is assimilated, the data is often made visual through a variety of tools as simple as Pareto diagrams, scatter plots and histograms, allowing a prioritized method of drilling through the data to understand systemic root causes of failure. The bottom line is that the organization or project becomes more predictable with risk of failure managed.

Excuse No. 4

“There is no magic…we know the solution…it is just a simple matter of implementing it with good project management”

Attributes: This is a classic scenario brought on by the organization’s hungry for a quick fix and a preconceived solution. These organizations usually buy into the “tool of the month” or the “solution of the year.” They have many integration problems created by the lack of a strategic roadmap for product or process integration, platforms and other critical business parameters. Many ill-fated projects start as the implementation of preconceived solutions without measures of performance or success. If an organization really knows the solution, and it is completely obvious, they should simply implement it. However, most solutions are born in search of a problem, as opposed to created to solve a particular problem. This hit-or-miss philosophy is behind many software/IT project failures.

How Lean Six Sigma Helps: Lean Six Sigma provides simple tools and disciplines that drive pratitioners from the problem space to the solution space and eventually to measurable business results. When properly followed, the use of the process and tools help to mitigate both financial and market risk.

Consider this example of a client whose project was to implement an expensive and intelligent system to help increase sales in branch outlets. The preconceived notion was that if frontline employees had (at their finger tips), every bit of information about customers and the available products likely to fit their profile, they could increase sales. The problem was that the employees were never consulted or asked for their knowledge about the topic. This was management’s idea and the management did not really know the day-to-day operation of the branches. When the project began meeting resistance, an objective analysis and viewpoint was sought. It was quickly realized that nobody had solicited the branch employee perspective on the problem (how to increase sales of new offerings) or possible barriers to achieving that goal.

After assembling a representative and demographically diverse sample of branch employees, a structured dialog was created utilizing a KJ tool, and a distillation and prioritization exercise was conducted. What resulted was a primary requirement for a better contact management system (a rather inexpensive solution compared to the original project and not part of the original project’s scope). It turns out the frontline employees knew their customers well and were familiar with the new products from other communications and systems. However, they had no way to proactively contact them to discuss their needs related to new products. In the end, a Lean Six Sigma project stopped the development of an expensive and unnecessary system (major cost avoidance) and initiated the creation of an effective solution needed by the frontline employees to increase business.

Conclusion: Happy Customers, More Sales, Lower Costs

Lean Six Sigma can and does help software development and IT organizations “Lean out” their processes, introduce appropriate value-added measurements and continuously improve their processes and end results. Much the way Lean helped manufacturing to achieve quick gains through process streamlining, elimination of non-value-added work and shorter cycle times, Agile and iterative approaches are being embodied in the Lean Six Sigma methods of major software engineering companies. Once these processes are “Leaned out” and low-hanging fruit is gathered, more robust and data-based tools associated with Six Sigma, help to solve complex process problems and minimize failure risks on specific projects. Wrapped around all of this is the benefit of common approaches, behaviors and the language of facts and data. In the end, the early adopters are rapidly proving the skeptics wrong and benefiting with happier customers, improved market share and lower costs.