Common Misconceptions about Six Sigma for IT

The methodology is straight-forward. Heck, even the acronym, by itself tells you what you need to do. So, what's so different about applying Six Sigma to IT that makes it different from all other applications?

Here's a typical scenario. Customer wants a report from, let's call it System X. They submit a request for this report. The request sits in a queue for the IT development team that's going to work it. When the stars align, IT development team gets the budget to execute the request and moves forward. Based on the DMAIC approach (since this is considered to be process improvement), we start with DEFINE. Literally translated, the problem statement can be articulated as missing information, the MEASURE can be the existence of the report and the ANALYSIS, the conversation with the customer probing for the report requirement.

What's wrong with this picture?

Let's continue. Moving on to IMPROVE, IT creates the report based on customer specifications, within constraints of time, resource and scope and with close to perfect quality. Finally, the report is installed in production, with all the monitoring and disaster recovery required to sustain it -- great CONTROL.

Customer inspects the result of the report (as part of user acceptance), realizes that the report, though perfect in execution, had unacceptable latency. The input data was not available in time for what they had intended to use the report for, and refused to sign off the request, modifying the request altogether to fit their need.

How would this have been better using the Six Sigma approach more appropriately?
At the point IT received the request, going back to the customer to find out the value expected from the report might have brought out the latency issue. We might have had to update the requirement to something other than a report, using technology that the customer may not even know about.