Using Six Sigma for IT Projects

Six Sigma wasn’t necessarily built for manufacturing environments. That was the original intended purpose, to be sure. The methodology, however, can accommodate all systems based improvement efforts that may be pursued. The other facet of the question, “How can Six Sigma work for IT projects?” rests on whether the technology-based processes are known systems.

This question has a very simple answer – IT projects and processes are systems. They do not take on the physical shape of systems as manufacturing facilities might, but the repeatable series of steps and the defined methods used to execute an IT Project are very similar to all systems.

As an example, consider the process required to implement technology components at a new building. Each of the steps required to complete the overall task are interacting with one another. Certain elements, such as electricity and data cabling, must be completed before computers and phones can be installed. Building infrastructure must be completed before the team can shake down the overall system and troubleshoot any problems before move in day. An experienced team has a process they use to implement this complex series of elements, quickly, effectively and in a repeatable manner. They may have taken the time to document the steps, how each team member interacts with one another, and so on. The process may be tribal knowledge, intuitive or in some other way known to all team members but not formally documented. In any event, there is a process.

What happens when the team executing this process is challenged to reduce the overall time to complete their task, or say another way, reduce their cycle time? One way they can go about improving their cycle time is by trying to work faster and not change any of the steps. This adjustment has its challenges. The team may make more mistakes in their effort to quicken the pace, and create rework for themselves. This, in effect, increased their cycle time.

Another method would be to use the DMAIC process – look at the cycle time and objectively measure each task and any time they spend waiting in between tasks. Once those measures are collected, review them and through that analysis look at what tasks are taking longer than expected. Which tasks are delayed? What are causing those delays? Once the answers to the root cause of the delay are in hand, the improvements will become straight forward.