Six Sigma or not, it's still Six Sigma

Did a lot of networking and in the course of all that, mentioned my podcast at sixsigmaiq.com. Most folks just recognize the buzz word -- SIX SIGMA. Most don't realize that it is not so much a literal translation of the methodology into IT. (It almost seems logical to do so. After all, DMAIC, which is 'Define, Measure, Analyze, Improve and Control' do mean something in IT terms.)

I talk more about this in my podcast:
http://www.sixsigmaiq.com/video.cfm?id=122

The reason I do this is to indicate that most best practices that work are actually part of the correct application of the Six Sigma methodology. There is no contradiction. Six Sigma or not, if it works, it's still Six Sigma --whether you agree to call it that or not.

How does one use Six Sigma to Initiate Change in IT?

Change is always difficult to initiate anyway. But, a good recipe for championing change is to bring out the pain that will be mitigated by the change. Present this pain in terms of the metric that is currently being negatively moved and make sure that this is the voice of the customer, i.e., the voice of a stakeholder who is the right customer for problem.

So, the overall advise does not vary. Identify the right customer. Make sure it is a complete list of customers. Find out their stake in the game. Find out the metric that can impact their stake positively. At this stage, you would have gotten sponsorship for your change. You're ready to move your change to execution.

In my opinion, execution is very rarely the source of the challenge. It is at problem definition and identifying the project objective that change gets hung up.

Business Value! Business Contribution!

There is an emergence of the mindset of providing value to business. I guess we want to address the age-old problem of IT being viewed as overhead.

I have always said that we should treat out IT projects as if we were a small business. In that world, everything we procure for the business needs to provide a tangible bottom-line value....or, we don't acquire it. If we did this to our IT projects, despite kicking and screaming customers, we would stop being just an expense in organizations.

I say this principle is the essence of Six Sigma.

Now, having said that, I am running into ITIL V3 -- pretty much an evolution of ITIL into the same business value mindset. Basically, it is the same principles from ITIL V2 except, instead of focusing on process, it starts with Strategy, which is really defining value to the business.

Overcoming the Six Sigma Stigma

As part of my creating my PODCAST presentation, I discuss my material with Reinhold, who is in engineering and is not a big fan of the general idea of Six Sigma. I've mentioned, time and again, that Six Sigma is really just the formalization of a methodology that advocates performing work based on real value to the relevant customer. This is the premise I develop in my presentation. This idea has evolved from the beginnings of the methodology from back in the days when it was applicable only to manufacturing environments.

Reinhold further challenges me with the ultimate point of my presentation. I contend that I am campaigning to correct the misconception that Six Sigma is only for the bureaucratic big corporations. It is, in fact, innate to the smaller corporate organization, who is highly intolerant of inefficiency in its struggle to keep itself viable, especially in a volatile economy.

How this is so is, I am saying we should stop doing IT projects for the sake of doing them because they are in the budget. We should reach out to the customer and identify how it will make their lives better. If we continue on this track, we, IT, will cease to be a cost center. Companies will have money for us, since we will start to represent recaptured revenue.

How can the Six Sigma mindset positively impact the floundering business?

We all complain about our floundering economy and 'blamestorm' on whose fault it is. We all need to inspect our microcosm to find the root cause of the problem. At work, I often observed that we generally conduct business like we had no stake in the result. Not true of everyone, but a good majority.


If we all conducted our jobs as if we were asked for the value to the organization of every piece of work we do, so we can actually quantify it. And, if this actually meant something to the organization at the end of the day, we would end up with a culture of caring corporate citizens. After all, whatever we do that pulls the organization down is collectively what has pulled our economy down.


One can argue that it starts from the top. True. But, this massive problem would not be such if it was not collective failure.


So, use the Six Sigma mentality of doing something if it provides value. Value is quantifiable. Identify what that is and be accountable for the result. Be corporately responsible.

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.

Six Sigma: To be or not to be. That is the question.

Calling it Six Sigma may not be the best approach for a non-Six Sigma shop. It's happened a few times now.

I explain the mindset to people all the time. Six Sigma always carries with it the insinuation that it is purely Statistics. This is not valid. Statistical tools sure play a big role in accomplishing the tasks in Analysis and Measure phases of either the DMAIC or DMADV approach. But, this is not the essence of Six Sigma. Of course, I say that in the IT context. To me, when one says Six Sigma approach, it is defining a problem by using measurable criteria, and solving the problem by moving that metric defined by the problem. This is completely different from living in the pure world of Statistics.

Hence, it is absolutely valid to use the Six Sigma approach without referring to it as such, especially to an untrained audience that assumes that we Black Belts are using high-falluting terminology to alienate argument.