iSixSigma

Standard Work in LSS

Reading Robin Barnwell’slastest post, I was reminded of a conversation I had recently regardingstandard work in our own projects. When our Black Belts share their experiences, it’s really interesting to seehow parts of the project structure are valued differently by each individual.

Let me give you an example. We have a guideline for rapid improvement (kaizen) events that says we should be doing a risk assessment of the new (future state) process on Day 4 of the 5-day event. Some BBs are doing this and say it works fine at that point. Other BBs say that’s too late – you should do a risk assessment on Day 2 when you’re creating the solution – so you can foresee problems and address them as you’re creating your new standard work. Also, the guideline says we should do an FMEA – Failure Mode Effects Analysis – but some BBs say that’s too complicated for most teams when you’re dealing with over 100 process steps. One team in a past project spent almost 8 hours trying faithfully to complete the FMEA as directed, for every process step, since they thought that’s what they needed to do. So some BBs are using a simplified risk assessment form or other contingency planning tool that worked for them in a previous life.

I’d be very interested in anyone’s opinion on how far is too far, when “adapting” project methodology standards or guidelines to a particular situation. Should a strict standard be enforced – we’re supposed to be modeling standard work, after all – or would this result in such an inflexible approach that we mightjeopardize the result of a particular project? Would we be hampering the BB’s ability to use his/her own judgment in a situation that calls for compromise?

Handpicked Content:   Speeding Cameras: A Zero Sum Gain in the World of Six Sigma

I’d love to hear your thoughts on this.

Comments 4

  1. Mike Carnell

    It depends on what you want from your Kaizen events. If the idea of a common process or receipe is important then be prescriptive. If results is the metric then you will probably be less prescriptive. I have two different people who deliver Kaizen events and they are complete opposites in terms of personality. A completely prescriptive process would probably marginalize both. Kazens are very dependant on the personality of the facilitator. A person who is very methodical and is just going through the steps will deliver that way and in the end will frequently capture a groups heads(minds). A very charismatic facilitator may make on the fly judgements about tasks when and where but they typically deliver the groups hearts.

    If I have to choose as a customer of a Kaizen I want the peoples hearts. That takes care of the sustainabolity issue or at least reduces it as an issue.

    If you have a copy of the January 2004 issue of Quality Progress I wrote an article called "Six Sigma Mambo" that addresses this issue. The natural salsa dancers (of which I am not one) listen to the timbales for the rhythm of the music before they begin to dance. They feel the music. I want someone running Kaizens that has that feel for the group and understands where they need to go rather than mindlessly executing steps. Six Sigma is the same thing.

    Just my opinion

  2. Sue Kozlowski

    Valuable comments – thanks Mike.

  3. Paul Lacusky

    Many time trying to maintain standard paths to follow it becomes too rigid and chokes out flexibility or/and creative hinking.

    I agree on the heart method and following a standard method hat is a guide rather than being in lock steps.

    The Army (military) has been good for having a standard 5 paragraph order to follow, and flexible to add/delete or modify the subparagraphs. Based on need and experience.

    This is what I see Six Sigma does for us, a basic set of tools where some apply and some do not . When you use the DMAIC path it leads us to succesful accomplishment and highr quality.

  4. London MBB

    I would agree that we have a toolset that we dip into and use tools as appropriate.
    However, beware encouraging flexibility around the basic methodology in inexperienced practitioners.
    I have been called in to rescue projects where, for example, they had ’trimmed’ their Define phase and found themselves in a pickle in "Improve" because they hadn’t articulated their CTQs! They had thought they were in the home straight. However, we re-visited their Define work, only for them to find they had spent 2 months collecting data unrelated to their CTQs. It was a tough lesson for them.
    Until you have experience, you may misjudge the implications of being selective of your use of the methodology. For example, I agree, you wont use a Fishbone on every project, but you must have Problem Statement, Goal Statement, CTQs and Business Case.

Leave a Reply