A discussion about an ideal IT system often centers on user friendliness, system reliability, and implementation on time and on budget. These discussions should also include how to create more business value through the development of systems following a disciplined, fact based approach with a clear customer focus.

For example, consider a telecom provider who wanted to reduce the cycle time of the repair process. Call center agents received calls from customers and forwarded problem descriptions to the field service agents who then solved the problems. Management identified inefficiencies at the call center – operators spent too much time conversing with clients, with some calls lasting more than 10 minutes. Management implemented a new IT system that kept track of calls and alerted operators when they approached the system-wide goal of six minutes. If operators met their goal of reducing the time per call, they received a bonus.

After two months, the bonuses for operators increased sharply. Executives, however, were astonished to see the cycle time of the average repair also increased.

Why Did the Cycle Time Increase?

Managers invested in IT to improve the process, yet the process worsened, as shown in Figure 1.

Figure 1: Average Call Time and Average Repair Time
Figure 1: Average Call Time and Average Repair Time

When management consulted the repair manager, he explained that the repair time increased because information previously collected at the call center was no longer available to the repairmen. The repairmen called the customers themselves to get the necessary information, adding an additional 15 minutes to each job. The IT project was implemented from purely a functional perspective, and no thought was given to how it might affect other aspects of the organization such as repair times. Management should have done an end-to-end process view, and included all stakeholders. If that had been done, the customer services manager could have shared the importance of the call center gathering all information.

Avoid Isolated Process Changes

Management could have avoided the problem if they had used a bit more common sense, process orientation and cross-functional thinking to understand how lowering the quality performance of the call center agents might impact the field service activities. Process orientation and cross-functional thinking would have ensured the key performance indicators (KPIs) for the call center were better aligned between the two teams.

Use a Methodology to Focus on IT and Business

Using a methodology could help prevent management from focusing solely on IT solutions and assist them in sustaining their business focus. The first step is to identify the problem. Many IT systems are a technical success but an organizational failure. A workable methodology must guide the organization in making the best decision on whether the problem being solved is the correct problem. In this case, the higher-level problem was that the overall repair times were too long. The decision, however, to focus on the call time was made too quickly and with a limited view. A more solid root cause analysis of the problem and a better understanding of drivers of long versus short repair times may have revealed a more comprehensive picture. At a minimum, such analysis would have shown that the quality of the collected customer data has a significant impact on the overall repair time and should not be compromised.

Second, assuming that the right problem is being solved, a quality solution must be created following a well-defined phased and rigorous approach (i.e., a systems development life cycle). This solution is then passed to the customers. In this case, the drivers of long repair cycle times were missing information. Call center agents spent a lot of time on the phone with the customers and often did not know what information to collect. In a later stage of this project, an optimized data entry record was created that guided the right questions (and only these questions) and ensured that important information was not missed. Additionally, a frequently asked questions (FAQ) database was installed to help call center agents solve specific problems on the phone without involving the field service.

Third, assess the impact of the solution in the field and provide a way of closing the loop with the original proposal. Follow through and measure the actual benefits, so that project managers can have a true measure of the value to the organization. In this case, KPIs were now defined for both the overall repair cycle time and the first call resolution rate. These KPIs were tracked with a dashboard after the project’s closure and reflected good performance results for the call center agents and the field service.

Integrate Design for Six Sigma (DFSS) and System Development Life Cycle (SDLC)

Integrating the DFSS roadmap in the system development methodology can strengthen the business focus of IT system delivery. The following steps describe the generic system development process:

  • User requirements analysis
  • Conceptual design
  • Detailed design and development
  • Test and validation
  • Implementation
  • Maintenance

As Figure 2 shows, these steps can be easily aligned with the identify, design, optimize, validate (IDOV) roadmap. If a company wants to get the full benefit of DFSS, however, it is important to bridge the gap between business and IT with additional steps at the beginning and the end of the system development cycle. DFSS will then support the better understanding of the business process and the customer requirements involved, and allow the organization to realize proven business results as well as continuously monitor process metrics.

Figure 2: Integration of System Development
Figure 2: Integration of System Development

Adoption of DFSS Tools

DFSS tools drive a stronger alignment between IT and business and should be integrated in any existing software development roadmap:

  • Suppliers, inputs, process, outputs, customers (SIPOC) to help understand the project scope and processes
  • Fishbone to identify the root causes of the problem and to better scope the project
  • The voice of the customer to map customer needs and wants into specific, measurable internal process attributes that are critical to quality (CTQ)
  • Quality functional deployment to connect CTQ with user requirement specifications, functional specifications and design specifications and prioritize user requirements according to business needs
  • Failure modes and effects analysis to mitigate risk during the project execution
  • Dashboards to help monitor the KPIs of the system after the go-live (operational phase)

Tollgate review (checkpoints and checklists) is an important DFSS stage that helps move between project phases. Here, the sponsors and steering committee are actively involved in deciding whether the project should proceed to the next stage and recommend corrective action where needed. For example, the phase review at the end of “identify” might discover that the right problem is not being solved. The project can be terminated or re-scoped, saving valuable resources. Figure 3 shows where in the IDOV roadmap selected DFSS and SDLC tools can be integrated. Which deliverables should be integrated in a businesses SDLC methodology depends on the business and its IT needs and must be carefully determined.

Figure 3: Framework for Selected Tools
Figure 3: Framework for Selected Tools

Paradigm Shift Through DFSS and SDLC Integration

Integrating DFSS and SDLC will bring a paradigm shift within IT in three ways:

  1. From IT system to business process: System development using DFSS helps managers understand the business process before developing an IT solution. In some cases, this may mean that a software solution is not needed at all since process optimization itself would solve the issues.
  2. From system requirements to customer needs: It is important to understand the real customer need before the specific user or system requirements are determined: “How should the business environment and process change once the system is successfully implemented?” Not sufficiently understanding business expectations from a software solution puts your project at risk of not meeting its business case.
  3. From general business objectives and benefits to metrics-driven objectives: Six Sigma uses facts and data to achieve significant and predictable business results. Once customer requirements are identified, they should be systematically translated into metrics such as process time, availability, man-hours and costs. When the IT system is implemented, DFSS tools like dashboards ensure that process and business indicators are measured over time. A successful IT project is therefore not only providing a user friendly and reliable system, developed on time and in budget, but also one that adds true value to the business by achieving its business case.
About the Author