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.