Six Sigma is a mantra that many of the most successful organizations in the world swear by and the trend is getting hotter by the day. So much so that corporations like GE insist that every project be a Six Sigma project. The Six Sigma methodology has indeed made a tangible difference to the bottom lines of many corporations and they have the numbers to prove it because Six Sigma requires constant and consistent measurement.
While the Six Sigma body of knowledge provides great tools for improving product and process quality (DMAIC) and even for developing new products (DFSS and DMADV), some work is still needed for managing software projects. The fit between Six Sigma and software project management methodology is not always obvious. Some of the common Six Sigma tools don’t easily lend themselves to software projects. Part of the reason is possibly that engineering and manufacturing have evolved over hundreds of years, software development is only a few decades old. Also, software development tends to teeter between an art form and an inexact science. Practitioners in the software development arena are not always comfortable or adept with rigorous quantitative analysis.
Six Sigma emphasizes quality from the beginning. Most often conventional Software Development Life Cycle (SDLC) methodologies introduce the quality processes towards the end of the project cycle, just before implementation. Some commonly used terms are unit testing, system testing, integration testing, etc. Some of the better methodologies emphasize design reviews and code reviews, but these too come in after the fact in that there is already a deliverable. Six Sigma rectifies that by introducing tollgates for every stage of the project life. Thus the concept, requirements gathering, systems specification, software development, software testing, rollout, and maintenance phases of the SDLC translate into corresponding tollgates. The introduction of tollgates from the very beginning of a software project improves the chance that it will be successful project.
The Six Sigma approach is most helpful in a software development project in the concept and requirements gathering phase. Problem definition and stakeholder analysis provide great tools for developing the project concept. CTQ analysis helps in clearly identifying the requirements. This approach also ensures that the primary project focus is on the deliverables and not the technology. Process mapping plays an important part in any Six Sigma project. Mapping the process helps in understanding the problem space and boundaries.
Most Six Sigma tools are suited for discovering data relationships by quantitative or physical methods. Such relationships are typically represented as algebraic or other forms of equations. These equations define the relationships between the goal (Y) and the variables affecting it (Xs). In software development, data relationships are generally easily discovered via interviewing and process mapping. Data flow diagrams, entity relationship diagrams, and object models are commonly used tools to represent data in software projects. These diagrams represent the data that the software will manage, whereas the Six Sigma approach tries to find the data that defines the problem.
The one software development area where Six Sigma methodology falls short is in measuring a system architecture for quality. Peer reviews and simulations provide a way to review the quality of an architecture design with respect to the CTQs. However, these tend to be subjective in their approach and are not easily transferable from one project to the next. These approaches also do not ensure optimization.
Six Sigma is a sound methodology for managing projects. It will continue to evolve to address the specific needs of software projects. SDLC methodologies will borrow even more from Six Sigma as the benefits continue to grow. Be on the look out for the “Six Sigma for SDLC” methodology, as I’m sure it is around the corner.