DFSS stands for Design For Six Sigma. It is therefore an acronym made up of two parts: Design and Six Sigma.
Design is an Anglo-Saxon word expressing the idea of developing products or processes(1), whether Hardware (a tangible physical product) or Software (a computer program); and Six Sigma refers, firstly, to the scientific way of deciding whether measurements demonstrate a significant change(2) in the behaviour of a process, such as a performance improvement claimed by its author; secondly, to the assessment, through an indicator, of a process’s ability to deliver the expected results (we speak, for example, of a Capability level, such as 6 Sigma, which means that on average 3.4 ppm, or problems per million occurrences, can be expected); and finally, to the working method launched by Motorola in 1987 to continuously improve processes whose yields are insufficient. Here, the word process should be understood in its usual business sense: a sequence of programmed tasks designed to achieve a desired transformation.
DMAIC is the acronym used to describe the Motorola method: Define, Measure, Analyse, Improve, Control. This acronym represents the roadmap to be followed when applying the method. DFSS, on the other hand, follows a different roadmap and therefore uses another acronym (see IDDOV).
The DMAIC method was an enormous success, particularly after the two industrial giants General Electric and Honeywell decided to use it to improve their own processes. Today, most large companies around the world use it.
Hardware DFSS, although it has been used for around ten years by some large industrial groups, is still in its early stages. Compared with DMAIC, it is more complex because it is multidimensional(3). The use of mathematical tools such as matrices, which in this context are referred to as the House of Quality or the Causes and Effects Matrix (also known as the X/Y Matrix), becomes essential. Their complexity limits the number of practitioners and therefore the number of technological “evangelists” of the method.
That said, the method is gaining momentum and is attracting increasing interest from R&D directors and other development managers who, as a result of globalisation, are under pressure to improve performance, whether in terms of productivity, reliability, safety or performance in the broader sense.
As far as Software DFSS is concerned, it is not yet genuinely implemented. This is probably due to the fact that IT professionals are still behind the industrial world when it comes to Quality methods. This may be because IT is still a relatively young profession compared with manufacturing. In IT, the emphasis is primarily placed on the ability to make the program work, rather than on its performance.
In this context, the use of Capability indicators that measure quality is rare, if not exceptional. The difficulty of measurement in IT must also be taken into account, since measurements are most often attribute-based: it either works or it does not. Often, the only possible continuous measurement is the number of hours required to write the code. However, since this quantity is often poorly estimated, its measurement does not follow a normal behaviour (see the Normal Distribution in footnote (1)) because it is unreliable, and therefore cannot really be used to trigger improvement actions.
Nevertheless, tools do exist, such as Function Points, but they have a poor reputation. This may perhaps be due to the fact that they were poorly used in the past.
More recently, certain new standards have emerged in the software development field, such as CMMI(4), which, from Level 3 onwards (out of five levels), requires companies seeking compliance to implement performance measurement systems and control tools such as Statistical Process Control (SPC)(5) charts and other fact-based decision-making instruments, including measures based on the distance from the mean expressed in Sigma.
Furthermore, and also relatively recently (probably within the last decade), we have seen the rise of the Agile/Scrum method(6). When examined closely, what it proposes is in fact the Lean Manufacturing method developed by Toyota, applied to the IT world.
It is the Just-In-Time concept, except that here, instead of manufacturing an industrial product just in time in order to avoid keeping it in stock and therefore incurring additional costs — since the price paid by the customer at the time of purchase is deferred relative to the moment when the production cost is incurred, as well as the additional work required to adapt the product to updated customer needs — we “produce” the code just in time, that is, in short iterations (see Sprint(7)).
The product is then checked directly with the customer to verify whether the need and the product intended to meet that need are aligned, and the development is adapted to changes and other modifications that will inevitably be identified.
These immediate modifications will be much less costly than those that would otherwise have had to be made later. This is because of the interactions with other parts of the code that we do not think about and therefore do not correct, which will subsequently create bugs; also because we will have forgotten how and why the code was written and will therefore have to dive back into it; and above all because otherwise we will continue writing code that will ultimately serve no purpose.
In manufacturing industry today, Lean and Six Sigma improvement methods are no longer discussed separately but are commonly referred to together as Lean Six Sigma. There is little point in manufacturing a product quickly if it is functional but of unacceptable quality, just as there is little point in producing a high-quality product if it is not available when needed.
The software world has recognised the value of adopting Lean tools, originating in the industrial world, by embracing Agile/Scrum. Now, new standards in IT such as CMMI are pushing companies to implement measurement and control systems similar to those that already exist in other disciplines governed by processes.
It is therefore time for software solution providers to integrate the Six Sigma dimension.
Author: Thierry Mariani – Juggling Paradigms Sàrl
Lean Six Sigma / Design For Six Sigma Master Black Belt – ISSSP Scottsdale, USA
MSc. Mechanical / Automotive Engineering – CNAM Paris, France
Connect with Thierry on LinkedIn at: www.linkedin.com/in/thierrymariani
Notes
(1) From this point onwards, rather than repeatedly using the words Products and Processes, we will use only the word Process, because a product can also be considered as a process of controlled transformations of inputs (referred to as causes, inputs or Xs) into outputs (referred to as effects, consequences, outputs or Ys). “Controlled” means that these transformations are normal in the Gaussian sense of the term (see Normal Distribution).
A manufactured product is therefore responsible for the controlled transformation of inputs into outputs and falls into this category. This may be the case, for example, with a ball bearing, which transforms or controls undesirable axial or radial translations (the Xs) of a transmission shaft into a single rotation (the Y).
(2) Significant means a drastic change that can therefore be distinguished from the random and inevitable changes that are inherent in all transformations.
(3) See article: DFSS – A Complex but Worthwhile Deployment
http://www.jugglingparadigms.com/en/nos-references/dfss/
(4) Capability Maturity Model Integration (CMMI).
(5) Statistical Process Control (SPC).
(6) Some may argue, in order to distinguish these two approaches, that:
- The first refers to the philosophy of Agility, which promotes flexibility in development in order to contrast with the rigidity associated with the Waterfall method. The image conveyed by Waterfall is that, after obtaining the customer’s signature, the program is written according to the specifications, in isolation from the customer, for months or even years. In the end, the delivered product may no longer correspond to the customer’s expectations because the context has changed, because the customer had not thought of certain critical requirements, or because the specifications were misunderstood, poorly written, or poorly followed.
- The second refers to the Scrum working method, Scrum being the English word for the mêlée performed by rugby players during matches. Scrum would therefore be the way in which Agile-type development is carried out.
The metaphor of the scrum represents the idea of mixing and confronting the relationship between needs and solutions that the supplier’s team — typically composed of developers, testers and a Scrum Master — will have with the customer during the end-of-sprint meetings(7).
(7) A Sprint represents an iteration of software development between taking responsibility for a customer need and delivering a functional solution to address that need. A Sprint typically lasts one or two weeks.