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.