Showing posts with label Six Sigma problem statement; Defining a problem. Show all posts
Showing posts with label Six Sigma problem statement; Defining a problem. Show all posts

Monday, July 20, 2009

Responding to Genna's Question: How does one align the customer experience to the process improvement?

Process improvement is undertaken by an organization for the purpose of realizing benefits that will ultimately impact a customer’s bottom line goal. Alignment of customer experience with the improvement takes a back seat to the primary goal for which the improvement is being undertaken. Not that it is to be ignored, but, recognize that the process improvement must deliver the value for which it is being undertaken to the customer first. Given that, it is important to articulate that impact since it could potentially be included by the customer as part of the value of the process improvement. If so, the conventional tools can be used to elicit the requirement for the alignment of customer experience: stakeholder analysis (to determine all customers), VOC (to determine customer desires and priority), maybe QFD (to help the prioritization process for the improvements)

A case study is presented on this specific subject in a full article the following link:
http://www.sixsigmaiq.com/article.cfm?externalID=1138

Saturday, April 11, 2009

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.