Can Variance Reduction Be a Product Metric?

Six Sigma – iSixSigma Forums General Forums Implementation Can Variance Reduction Be a Product Metric?

This topic contains 4 replies, has 3 voices, and was last updated by  Alex Pamatat 3 years, 6 months ago.

Viewing 5 posts - 1 through 5 (of 5 total)
  • Author
  • #55235


    I have business problem where certain client files need to be loaded to the system after doing some testing. When the test fails, the IT specialist sends the file back to the vendor(supplier) for correction. this can get into a loop and we’ve seen that the average no. if iterations required before the file moves to production is 7 and median is 6. The sponsor has asked for a way to get the clients move to production faster( reducing the no. of iterations or overall cycle time are some options I am thinking of right now)
    But I am trying to be a little inventive with the project metric instead of choosing the tried and average reduction, cycle time reduction.
    Can I choose Variance reduction as a project metric? or Standard Deviation even? If so, please share what should be the acceptable % reduction of var/std dev.



    Shelby Jarvis


    The proper judge of your question is your stakeholders. However, it looks as if you need to shift your process time through reduction of rework.

    As you have stated it, the time to process is extended as a result of rework (7 mean / 6 median). I can not speak for your team, but reducing variation is good, but I would expect both (cycle time and variation).

    You may have this, but if not you may benefit from measuring the types and frequencies of errors which lead to the rework. By eliminating the errors; you will reduce the number of rework iterations. This will impact cycle time and variation around the cycle time.

    Your long term goal should be zero rework.

    As a project metric and target improvement, work with your stakeholders to define the expectation.


    Arun sathish RS

    Yes we can set as a primary metric



    You can considet using overall equipment effectiveness as a metric. This technique encapsulates availability, throughput and rejects as one metric.


    Alex Pamatat

    @arunsathishrs, I have to agree with Shelby Jarvis on this one, I think he did a good job summing it up. I also think you may be overcomplicating the metric. Certainly reduction in variance is good but I think that even if you use the # of iterations as your metric you’re going to discover what’s driving the variation in cycle time and # of iterations.

    I know I don’t fully understand your “Iterations” metric but it sounds as if, between each iteration, there could be some delay in someone reporting the need for a correction in the code and the code actually being corrected. Could the issue be reported but sit in a programmers/developers queue for several days waiting to be worked on while some other requests only wait a few hours? If this is the case then I’d recommend using total cycle time as your metric and not iterations; iterations will hide this queue time effect. You may use cycle time as the primary metric and evaluate why some corrections take longer than others but in the end your goal should be to get the defects to zero.

    One last comment, if you do use cycle time as your primary goal make sure you are smart about defining your goal around this. For example, your goal may be 0 defects and then a month into your project you have a week with zero defects…..are you done? Does the team disband now? No, of course not, you likely reached 0 defects by chance. Consider using a trailing 4 week average of cycle time, perhaps when this rolling average metric is under the goal for 4-8 weeks then you can say you’re done. Be smart about setting your goals, I see a lot of people mess this up.

Viewing 5 posts - 1 through 5 (of 5 total)

You must be logged in to reply to this topic.