Reading a generalized description of how waste was reduced or eliminated in a process is interesting but it is in the details that the true impact and challenges of process improvement are found. This article describes a DMAIC (Define, Measure, Analyze, Improve, Control) improvement project, including key deliverables, challenges and how the challenges were met.
The project discussed here focuses on the information systems (IS) change-request process in a Fortune 500 company, but may be seen in any company and industry. The problem was that the change-request cycle time was too long and did not meet the requirements of the customers, who in this case are internal to the company.
The basic steps of the change-request process are:
Many of the customer change requests were relatively simple, such as a change accomplished through a software script or repeatable action with no functionality enhancement required. Examples include creating new folders, new projects or document classification values. Still, even the simple change requests were taking too long.
The cycle time to implement a change request doubled from 10 days to 20 days when the IS position that managed the change-request process was eliminated. The interim solution included giving additional tasks to existing IS resources in the process. After four months of low customer satisfaction, the IS business analyst requested a Black Belt resource to do an improvement project to reduce the cycle time.
The first challenge to the project was that in the IS department, only a few employees were trained in Lean Six Sigma (LSS). In addition, the members of the improvement project team – subject matter experts (SMEs) of the process – were located in different geographic regions.
To increase the chances of success on the project, the Black Belt provided training on the LSS methodology and tools to be used on this project. He also held workshops for tackling project work, coordinating the time of the workshops to allow participation from members in all regions. During workshop exercises, the Black Belt utilized a “teach-example-do” structure to train the SMEs. For example, he would explain what a SIPOC (suppliers, input, process, output, customer) is, provide an easy example, and then have the team create their own SIPOC as a group.
Voice of the customer (VOC) was collected through a survey and correlated in advance of the first workshop. The survey included questions about the quality and speed of the current process. Customers provided great detail on the issues they experienced, which gave the team a clear picture of the customers’ expectations and requirements.
In addition to conducting the VOC survey, the Black Belt met with the key customers of the process. It was agreed that the critical-to-quality (CTQ) requirement was a 10-day cycle time from when a change was requested to when the change was implemented for use.
Voice of the Customer
|Our request for implementing a simple content-related change takes too long.||The cycle time has doubled and we do not care why! Get your act together.||10-day cycle time to complete the change request, from requesting the change to implementation for the end user.|
Also in the Define phase, the team completed the project charter with defined roles and responsibilities, a stakeholder analysis, a SIPOC, and a benefits graph (shown in Figure 1), which highlight the business reasons why the project was selected and what enablers are required to meet the business drivers.
Clear communications were established regarding what was expected from the participants before, during and after the workshops. In addition to the Black Belt, participants included the sponsor and SMEs involved in the process – specifically the business analyst, IS personnel, and the vendor who implemented the changes. The sponsor’s involvement helped with removing road blocks, providing resources and setting a positive tone.
The workshops were held on a weekly basis for four hours each. As the project manager, the Black Belt coordinated the meetings. In the past, holding remote workshops longer than four hours showed a quick decline in participation. The spacing of the workshops allowed enough time for the participants to gather the required information, socialize with others in their function/group and to send the information back to the Black Belt. It also gave the Black Belt time to correlate the information and to have more efficient workshops.
The scope of the project encompassed the change-request process, from the time a customer requested a change to the actual implementation.
In the existing process, two teams in the company, Development Projects Operational Excellence (DPOpEx) and Development Projects Business Partner (DPBP, a group that interfaces between internal customers and the IS department), met frequently to gather customer requirements. Examples of these requirements include a need to create electronic folders and documents used to store information that others in the customer group needed access to. Many of these changes were simple and scripted by the vendor who was responsible for implementing the change.
DPOpEx is a customer-facing role that translates customer requirements to the IS groups. DPOpEx business partners, DPOpEx support manager and DPOpEx support desk are roles within DPOpEx. The DPOpEx business partners submit changes to IS, while the DPOpEx support manager and DPOpEx support desk perform UAT testing.
DPBP gathers and implements the customers requirements. They are part of an enabling function to the business.
As Figure 2 illustrates, many handoffs and approvals were required in the as-is process. The business partner submitted the change request to the DPOpEx support manager. It was reviewed by the support manager for clarity and to compare it to other change requests to avoid duplication. The change request was reviewed by three other IS personnel prior to sending to the vendor, who then processed the change and provided estimates for completion of the requests. This information was sent to multiple people for approval. Once everyone approved the simple change, the vendor implemented into a pre-production system. Next, the vendor would send an email to two DPOpEx staff to perform user acceptance testing. Once complete, the vendor was given the go-ahead to implement the change. The customer and business partner were then notified.
Data gathered during the Measure phase showed that the average lead time for these change requests was around 20 days, with a few outliers as high as 45 days.
Based on a Pareto analysis, four key drivers for the increased cycle were identified (Figure 3):
The team identified the root causes and areas of waste associated with the key issues (shown in the table below).
During the Improve phase, the team devised solutions to reduce the waste associated with the root causes of the problem (see table below). Filling the change management position was not possible due to resource constraints. Focusing on eliminating waste and the complexity of the process revealed potential solutions for an efficient process without additional resources.
Lead Time Issue
|Lead time moved from 10 to 20 days after a staff member was removed; an interim solution was established.||Transparency of the process||The original process had changed and the SMEs involved in the process were not trained properly.||Motion: Looking for status of change||Process SMEs created new to-be VSM. This map and training were provided to all participants.|
|Lack of clear communications||Customers and customer-interfacing roles did not know where the change request was in the process. This would require the customer-facing roles to send multiple emails to determine where the change was in the process.||Waiting: Customer and business partners waiting for change and/or status of the change.
Motion: Looking for status of change
|Based on the new process map, communications were required at specific steps to keep the business informed of the status.|
|Excessive handoffs/documentation||There were too many handoffs and too much documentation created by the process staff that were not required.||Transportation: Files being emailed to too many people?
Over-processing: Too much cut/paste that was not required
Under-utilized Talent: Many IS personnel reviewing status emails and trying to determine if they need to do anything
Defects: Errors when copying information
|Reduce handoffs, especially during the identify/approve phase. Reduced the number of approvers required from five to one.|
|Excessive number of approvals required||The interim solution SME thought they needed to approve the changes.||Over-processing: Too many approvals
Under-utilized Talent: Too many non-required approvals
|Reduce the number of approvals from five to one. Asked the simple question, “Why do you need to approve it?”|
Next, the group developed a new “to-be” process that focused on the root causes defined in the Analyze phase (as shown in the table). Handoffs and approvals were reduced. By developing the solution themselves, the SMEs gained the ownership of the process – an important point when looking toward sustaining improvements.
Some additional aspects for successfully leading a continuous improvement project include developing clear plans using the DMAIC methodology but being flexible to change during a workshop, engaging the sponsor and subject manager experts with transparency and clear communications, and allowing them to develop the solution. As a BB leads more projects, their confidence in planning and executing will increase significantly. Enjoy the journey!
The new process was piloted and key cycle time metrics were captured. The control plan was provided as part of the transition plan to the DPOpEx business partner.
The project resulted in: