By Amber Gravett and David Dean Tuma
Often considered an island unto itself, technology development and implementation does not really occur in a vacuum. However, the interrelated nature of managerial, quality and technological systems, and the inherent benefits of a truly integrated view are not necessarily evident to the Information Technology (IT) professional. Consequently, increasing implementation costs and an array of idiosyncratic IT methodologies plague many IT departments. Functional and procedural isolation have deprived technology companies of the quality and cost benefits enjoyed beyond the IT divide – or circuit curtain.
Six Sigma is used effectively in manufacturing, service, financial and educational settings to improve processes and achieve time and cost benefits by eliminating waste and inefficiencies. These same defects can be found in IT departments. It need not be that one side of the corporate corridor enjoys savings and cost avoidance while the other side is left floundering. Like other functional areas, IT departments are comprised of individuals working together utilizing common practices and procedures. So, ultimately, the same Six Sigma tenets employed in such traditional functions as product assembly/manufacturing/accounting and customer service can benefit IT organizations – with a little adaptation.
The system development life cycle (SDLC) is meant to bring order and procedural accountability to the creation and production of new technology offerings. It also can play a role as a unifying procedural basis for Six Sigma improvement activities in IT. A simplified deployment and implementation model (Table 1) is designed to align the SDLC with Six Sigma's DMAIC. A case study drawn from a Fortune 50 financial services firm shows how truly staggering the savings and achievements can be when these methodologies are combined.
SDLC: An Elegant Implementation Failure
According to Russell Kay in a 2002 online article, SDLC is "the overall process of developing information systems through a multi-step process from investigation of initial requirements through analysis, design, implementation and maintenance. There are many different models and methodologies, but each generally consists of a series of defined steps or stages."
While the SDLC is most readily associated with software, its facets also are often employed in hardware design. Not surprisingly, a number of SDLC models have emerged, including waterfall, rapid prototyping and synchronize/stabilize, each bringing both benefits and drawbacks. Pivotal in its potential as a complementary element to Six Sigma is that it is designed to automate process flows and to represent systems graphically, excluding the end-user beyond the requirements phase. Inherently flexible and linear, the SDLC facilitates orderly creation of products that are both highly ethereal and artistic in nature, such as software code. If programmers are artists, it is not outlandish to assume they would hate to see their efforts result in mediocrity and waste once beyond their control. As a result, well-intentioned creators frequently force implementations into the SDLC process, with inefficient results. Conversely, some coding resources abandon projects at this point, leaving implementation vulnerable.
It is at the point of implementation that both programmers and the SDLC have the potential to fail as mechanisms of quality and cost control. This failure is a result of scope and purpose, not intrinsic flaws. Recalling the purpose of the SDLC, it is evident that implementation does not belong within those confines. The underlying rationale entails that customer requirements, development methodology, testing and packaging for deployment be executed in a fashion that allows a stable deployment. Implementations, however, are impacted by a series of events external to the process itself, or which are inadvertently misaligned in the SDLC process. There is a need for a complementary process that will carry some SDLC tenets into implementation. The addition of the customer and efficiency-centric qualities of the Six Sigma DMAIC model results in a simplified implementation of technology (SIFT).
The SIFT Process
Of course, SIFT is not a new model. It is an alignment of existing SDLC phases and new implementation elements with facets of DMAIC. Ultimately, this method entwines development and implementation resulting in a simplified technology deployment. Table 1 offers a view of this partnering, a combination that is both approachable by non-technical staff, as well as readily measurable against established customer specifications and organizational investments.
| Table 1: SIFT Matrix |
DMAIC
Phase |
Action
| Change from
SDLC |
Benefit(s)
|
Define | Capture the voice of the customer (VOC), gather requirements and determine process capability. | Deployment and implementation are addressed concurrently with code and system development. | Considering implementation and deployment early in the process bridges the gap between creation and use, offering expediency, fluidity and cost avoidance benefits. |
Measure | Determine gap between existing information system capabilities and the VOC.
Review past implementation results to determine timeline for implementation of new system.
Create a SIPOC and process map.
Establish baseline capabilities and report them to the customer against stated customer specifications. | Implementation and deployment are traditionally neglected in the SDLC until later phases.
Procedural baselines are rarely established for customers.
Process capability replaces the basic timeline schedule. | Pinpointing the proper implementation juncture helps shorten deployment. Beta and user testing scenarios are more readily apparent due to attention to capability measurements.
Systemic gaps are revealed.
Customer expectations are managed to avoid unrealistic expectations and expenditures related to satisfying them. |
Analyze | Review existing information system capabilities with customers to validate requirements. Complete a Quality Function Deployment (QFD).
Examine implementation results and perform a Failure Mode and Effects Analysis (FMEA) to uncover root causes of previous deployment issues. | Existence of an additional requirements validation session following the process capability assessment. | Requirements outside of existing process capabilities are reviewed, discussed and validated, saving development time and costs. FMEA analysis helps reveal why things that go smoothly in development become complicated or fail in deployment. Also reveals gaps in failure detection allowing IT to address issues before customers are aware. |
Improve | Using process flows and FMEA analysis, create formal documentation of necessary development steps. Emphasize inputs and outputs generic to any technology system the organization may choose to undertake. Develop a version release schedule based on VOC and process capability if necessary. A Kano diagram and QFD matrix are helpful in scheduling releases. Implement and deploy code or system and begin Beta testing. | VOC input is revisited as a means of creating multiple releases if necessary.
Implementation and deployment procedures are mapped as a function of the creation process rather then an addendum.
Detailed process maps create useful templates for mapping future development projects employing SDLC tenets. | Scheduled releases based on VOC analysis allow developers and management to focus on and finance the most important features first. Staggered development helps prevent quality issues and wasteful duplication of efforts. Beta testing within the DMAIC cycle allows benchmarking of deployments against customer specifications before formal launch. |
Control | Pilot the new system or product. Revisit the FMEA to validate that new procedures, product or code is guided by the VOC. Establish control plan to ensure appropriate measurements are captured versus customer specifications on a continual basis. Deploy the new environment. | User acceptance testing and Beta are not thorough enough to be considered release worthy.
Revalidation of failure mode detection and correction is conducted before wide-scale release. Baseline reporting metrics are presented, and a reporting plan is established. | Piloting with a control group established by the customer allows validation of work before formal release. Validates new processes established in the revised FMEA, avoiding long-term costs and mitigating customer frustration. Customers have a level of comfort knowing a corrective plan is in place. Baseline and ongoing reporting practices document performance for contractual purposes and identify emerging trends before they become problems. |
SIFT in Action
Four pilot programs were undertaken in different companies to evaluate the effectiveness of combining the SDLC with Six Sigma. Did the method truly result in simplified implementations for technology-centric departments and programs? Did integrating the two models overcomplicate things? Results from the pilots revealed that SIFT removed waste during the transition from development to full deployment without creating additional expense.
In one pilot program at a Fortune 50 financial services company, the voice of the customer (VOC) was captured pertaining to a web-based, financial product. A list of 31 initial features and expectations desired by the customer were evaluated. Process measurements indicated that the host system and web-enabled framework could not deliver the entire development package to user specifications. In fact, the process scored a capability rating of 0.2 (with 6.0 being perfect). It became evident that disparity existed between those who coded and those who maintained the tool to such an extent that customer feedback was useless in the evolution of the product.
The application of SIFT in this situation resulted in multiple releases, removal of two vendors, consolidation of hosting services, creation of an expanded support team and elimination of more than $5 million in unnecessary product feature enhancements and development. As a result, a reporting facility was developed to maintain the bonds between developer, deployment staff and the customer, creating $11.7 million in hard dollar savings and $1.2 million in cost avoidance over a 22-month period. Efficiency improvements increased the process capability to 5.6.
Concludion: SIFT Reunites Business and IT
As a methodology, SIFT ultimately seeks to reunite business and information technology departments, removing the veil of mystery that shrouds coding, programming, system enhancement and deployment. Six Sigma has garnered billions in savings and earned many companies priceless customer smiles. From pickles to Porsches, Six Sigma works. The SDLC has long afforded programmers and developers a loosely defined means of addressing the rigid nature of IT development. SIFT is the bridge between end-user and developer. SIFT allows IT departments and customers to benefit from cost efficiencies, analytical scrutiny and business expertise, resulting in positive return on investment for information technology enterprises.
About the Authors: Amber Gravett has a doctorate in organizational development. She completed Black Belt training in 2003. She is employed by First Data Corporation and two universities. Dr. Gravett and her work were recently featured in online editions of Business Week and Inc., and at the Cartes Expo in South Korea. She can be reached at gravett@tconl.com. David Tuma has an MCIS with dual emphasis in technology and communication systems. He completed Green Belt training in 2003. He works as a process architect for Blue Cross Blue Shield of Nebraska. Mr. Tuma's information technology development experience includes service with Apple Computer, Cynergy Consulting and Compaq. He can be reached at david@tuma.net.
