When it comes to defects here is a great example I suspect other readers may have experienced. But as you will see it has made me question the Six Sigma approach. I would like to ask for guidance. It’s an example I find is happening with increasing regularity and seems to be linked to the proliferation of web-only businesses and poorly skilled call centres.

How it started: – I had a problem with my broadband connection at home. I called the provider and asked if an engineer could take a look. This was agreed and a date set.

  • Defect 1: – The engineer arrives, says he is a PSTN engineer, can’t help and leaves.
  • Defect 2: – A Broadband engineer arrives a couple of days later without any notice while I am at work. Concludes there are no problem with connection so must be my equipment.
  • Defect 3: – Telephone bill includes £45 engineer call out charge, which I was not informed I would incur!
  • Defect 4: – Call the number on telephone bill to complain. Spend 20 minutes listening to “thank you for holding, your call IS important to us” before I give-up.
  • Defect 5: – Call first thing next day and get through after only 10 minutes. But its the wrong department, am immediately transferred, “thank you for holding, your call IS important to us”.
  • Defect 6: – Call the new department and get through after only 10 minutes. But again it’s the wrong department, am transferred, “thank you for holding, your call IS important to us”.
  • Defect 7: – Call the new department and get told they will take 2 weeks to review the case and make contact when they have made a decision.
Handpicked Content:   Write for!

I lose it at this pointand tried to call the CEO to complain. This has the desired affect and the £45 charge is dropped. As a customer I encountered defect after defect after defect. I felt that everything was wrong.

So lets take a look at Six Sigma.

  • What is Six Sigma?
    An approach that produces processes with 3.4 defects per million opportunities
  • What is a defect?
    A failure to meet one of the acceptance criteria of your customers

The way I have been taught is to use two methodologies, DMAIC to raise the sigma-level up to about 4 and DFSS to push onto 6.

Now when you run a DMAIC project and are in Define, a key area is the Problem statement. I have been in meetings where we have taken hours to agree a problem statement. It should be SMART, refer to a process output, not attempt to describe the solution etc…

We know that everything is a process. So I encountered the “field engineer” and the “customer billing” processes both with defects.

So here is where I need guidance.

I suspect I’m just the squeaky wheel so they probably wouldn’t. But if by chance the telecom provider decided to launch a project they may start by defining the problem e.g.

We have received over 1000 complaints of customers being charged for engineering callouts in the last 3 months.

And a few months later they would end-up with a message to the call centre to always inform staff to tell customers that they will incur a call-out charge. Great job done, problem solved. I suspect I am not giving enough credit to a potential Six Sigma team here, but it illustrates the point.

Handpicked Content:   Six Sigma 2008 - Make It Personal

But I had loads of defects of which one may be improved. So the point I am coming too is this. If we get the problem statement wrong the whole project is liable to get a poor result. So it would seem that before we can rush into any DMAIC projects we need to do considerable ground-work to thoroughly understand our customers and the sheer variety and opportunity for defects. This could be through tools like Voice of Customer, CTQ-tree, QFD, and FMEA. Its as though there is a major stage pre-DMAIC where you invest in building the infrastructure and a clear understanding of the customer and all the issues they face in doing business with you.

If so, this pre-DMAIC stage is not very well communicated in the training or literature. Please let me know what is wrong in my thinking.

Comments 7

  1. PKT

    Robin, I completely agree with your example and your statement " if you get the problem statement wrong, the whole project will give wrong result ". However, I tend to disagree when you say that we need to have a Pre DMAIC phase.

    According to what I understand and what I was thought, Define phase as such is in 3 steps

    1st step: Identifying the CTQ (Critical to Quality)
    2nd Step: develop the team charter (Problem/Goal statement, team etc)
    3rd Step: Define a process map.

    so all the pre DMAIC steps what you refer to is taken care in teh step 1 of Define. we will have to do VoC, CTQ, QFD etc in this step.

    I would also like to request all the trainers and MBB/BB who train people in Six Sigma to lay more efforts and emphasis on this step.

  2. Mike Carnell

    When Six Sigma began at Motorola it was MAIC. The D was added during the GE deployment for whatever reason. My general feeling is that the D became a step as Process Ownwers did a poorer job of selecting projects ans writing charters/problem statements. That sloppy job spilled over onto BB’s be adding a rework step called Define where the Process Owner throws out whatever they feel like and the team figures out what they meant.

    The prework you speak about does need to be done but it has nothing to do with a SS project. It is the basic rigor that should be placed into any project by a Process Owner when they decide to expend company resources. How can anyone decide to launcha SS project without a clearly defined problem statement from the Process owner and some financial assessment so that the financial implications are understood. This is basic information you use when making a business decision. Look at the Cap Ex process. When the expense is high enough we formalize the process. It should not be any different for at Lean or SS project.

    Just my opinion.

  3. Robin Barnwell

    PKT, thanks for your views here. I guess what I was saying was initial project selection can only be as good as the information available. To address this a business could invest in permanent VOC, VOB, and VOP type processes to feed opportunities into the hopper. Once a project is selected then the really focused investigation can start.

    Mike, this and your more recent post regarding process owner leadership helps. I wonder if you might consider becoming a blogger?

  4. Mike Carnell

    I agree there should be a "hopper" of sorts but not a Six Sigma hopper. There needs to be a place where ideas (all ideas) feed into and then back out to PO’s for the charter and finacial analysis. That feeds into the steering committee who send it out as a JDI, SS, Lean, etc. (their focus needs to much broaded than just a single initiative). It makes the projects turn much quicker when you take the people responsible for driving change out of the buy-in business and let them focus on improvement.

    Take your last project and calculate what it costs per day. Does it make more sense to create a system that builds buy-in up front – before it becomes a project or to have a Belt spending time at $X per day selling buy-in because the PO’s did not want to get involved? We try to generate a system on our deployments that does the former.

    Thank you for the compliment on the posts.I have had the discussion about becoming a Blogger. I find it amazing that people can write to a schedule. I don’t know how to do that and I don’t want to make a commitment I can’t keep.


  5. Sadique Salim

    I agree with both of you.

    You cannot ensure continuous or proper flow of VOC or VOB unless a useful and practical system is deployed.

    We cannot always count on customer complaints or what our management is thinking.

    but i think we are missing a point here…that is CTB: critical to business.

    Our projects should come from companies ultimate business goal : let it be revenue, cost reduction, or customer satisfaction. The projects should come from how much $ amount will it reflect in the overall company goal.

    The problem is not with six sigma, it is how we use it.

  6. Robin Barnwell

    Sadique, its moving off the main point of the post, of making VoX part of a businesses infrastructure.

    I’m going to stick my neck out on this one and say it would seem revenue enhancement and cost reduction should be side-effects of a six sigma project.

    A project should be described in terms of addressing a customer-facing issue. If you focus relentlessly on making processes always meets customer needs then you will get more customers (revenue) and reduced costs (rework/COPQ).

    Looking to cut cost from a process is more a feature of lean initiatives.

  7. Mike Carnell

    I do make an assumption in the system I described and that assumption is that Process Owners (PO) are aligned with the business through some type of instrument such as a scorecard. Let’s make the assumption that a PO is not aligned. If your system has projects selected and chartered by PO’s and they are submitted to a central steering committee, how long do you think that a PO will be allowed to wander around in the ozone before someone takes him aside and asks him what he is doing? I have no issue with Robin’s position on this. This VOX is overplayed particularly the VOC. The information on VOC should be readily available and if a PO can’t line up on it maybe you have the wrong PO.

    On your second point I am going to agree with Robin. We track benefits on everything. I intentionally use the word benefits because we do not necessarily drive cost reduction. Platinum is at $1200/oz why would we focus on cost. We have a finite resource, world wide shortage and strong market price. We want throughput and nobody needs to figure out a CTB for that.

    Our original charter from the CEO was 20% of the projects would be Safety Health Environment Community (SHEC) type projects and we frequently carry those at $0 simply because any other number lacks integrity. We do them out of a morale obligation to the workforce and I don’t have to check the VOE to make sure those projects make sense.

Leave a Reply