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.

What's the problem with defining the problem using the Six Sigma approach?

In a previous blog, I alluded to going back to the actual customer and exploring what their actual use for the project deliverable was. I also mentioned that this was for the purpose of helping them see other possible solution options that they may not have seen when they articulated the problem.

The issue I've had with doing this was a customer that responded to me saying I was going beyond the scope of what I was being asked. In other words, Mr. Customer wanted me to 'just do it' and felt that I was going beyond the scope of my work to ask him what he was going to use it for.

This response is typical. Customers do not want to feel that you are questioning their knowledge or ability to understand technology (even when, at their hierarchical organizational level, it should be inconsequential). At this stage, it all boils down to communication style and phrasing. The customer will always be the customer (and, the customer is always right). Create your business case for asking the question. Show them how understanding their purpose might help you come up with an even more cost-effective solution. A cheaper solution is always a value proposition.

Defining an IT problem using the Six Sigma Approach

The traditional approach for defining an IT problem is usually based on what is literally asked for by the customer. This is making the assumption that the customer is technologically savvy and has weighed the solution options. This is hardly true.

It is our job as IT professionals to go back to our customer to find out the result they are trying to achieve and validate that the solution being asked for will yield that result.

A good example to support this is a customer I once had that wanted a report. I did my due diligence to document how he wanted the report, what information he wanted on it and all that relevant information. Unfortunately, I fell short. I did not ask him what he wanted to use it for. When I delivered the report based on the documented need, it did not serve his purpose, a purpose I knew nothing about. It was not timely for his need. I did not know that this timing requirement was even relevant and Mr. Customer did not realize it was even a consideration.

Lesson learned: I should have asked Mr. Customer what he was going to use the report for. If I did, the other relevant questions like timing, or, if there was other information needed would have come up. I could have helped him define what problem he was trying to solve using something tangible to base the result on.

Defining an IT problem is identifying that tangible metric that will have to move a particular direction to give my customer his desired result. If done correctly, the successful completion of the project will not only mean my successful completion of the project, but, a satisfied customer, as well.

How do you determine a measure for your IT Project?

As is true for any Six Sigma project, what do you measure and how do you determine if it is a good thing to measure? The essence of this question is determining what problem one is trying to fix and applying the Six Sigma principles to it.

The goal of measuring is to establish an objective baseline so that when the project is completed, the success criteria is clearly established as satisfied. So, the key is defining the problem well.

For IT, candidate measures are time (to derive a discrete result), effort (maybe, in terms of rework), when quanitifiable, ideally, dollars expended/saved, quality (when a standard objective measure for it can be established); all these, nothing different from the dimensions of project management. So, what's different? The operating word here is finding that objective measure that can be the basis of determining success of the project.

What is the business case for an IT project?

The IT mindset has traditionally been one of entitlement: a budget is provided and a project executed within that budget. The project execution within that constraint is the only completion goal. The project justification is often left to the customer requesting the work. And, even then, it is assumed they know what the solution options are for their problem and can articulate a clear objective.

Let me share with you how this can be counter productive. Let refer to the Ford quote about requirements for the car: If the people were asked about it, they would have said they wanted a faster horse. The people then did not know about the technology for a car. Their perspective was confined to what they knew, the horse as a means of transportation. This is no different for a customer for an IT project. They do not necessarily know all the solution options.

We as IT professionals need to guide them. We need to understand the problem they are attempting to solve so we can help articulate a clear objective and achieve measurable success.
We need to be able to state what it is they will gain from the successful completion of the IT project (even if it means changing the project itself).

Is there such a thing as a cookie cutter recipe for the Six Sigma for IT?

I have had an opportunity for an interview where an interviewer asked me whether I could come up with a recipe for the Six Sigma approach in IT. Another individual even asked if this is valid.



The response is, generally, yes. But, the approach will not hold for 100% of the cases. It will, however, hold for a good majority. When I talk about what it is that will not hold, I am referring to the specific tools in the toolkit.



I created such a process for a client and went through the template with them on my last day with them. I think they'll do fine with most of the material. Where I anticipate they would run into ambiguity is identifying the measures (to create the baseline). This, by the way, is a very crucial part of the project definition as it determines the success factor for completion of the effort. There is a generic list of metrics one can use in IT. What I proceeded to do was to list these and indicated that if this list did not contain what was required for this specific application, that a more specialized inspection might be required.

Again, for the most part, the formula will work for a good number of applications, just not every one. Well, that's why there's people like me.......

How does Six Sigma translate to IT Program Management?

It's all too common to find opportunities in the market for Six Sigma Black Belts for Manufacturing environments. Oftentimes, an IT-experienced Black Belt would be discounted for such an opportunity. In the experience maturity timeline, it shouldn't matter. The fact that Six Sigma identifies a problem using statistical measures, coupled with the myth that IT problems may be difficult to quantify and statistically measure contributes further to this perception.



The Six Sigma methodology translates very well to IT. The difficulty of use is up front, at the point of applying rigor to problem definition. Since gathering statistics to measure a baseline often entails proportionally significant cost, it is often foregone for a nebulous problem definition that can sometimes even be ambiguous.