iSixSigma

Project Selection in a Non-Continuous Improvement Environment

Six Sigma – iSixSigma Forums General Forums Implementation Project Selection in a Non-Continuous Improvement Environment

This topic contains 2 replies, has 3 voices, and was last updated by  Oliver Kozak 2 months, 1 week ago.

Viewing 3 posts - 1 through 3 (of 3 total)
  • Author
    Posts
  • #241706

    jfelten775
    Participant

    For a six sigma black belt in a company that does not have a lean or six sigma background; what tools or methods would you use to select worthy six sigma projects and convince ownership and management to back the effort?

    0
    #241732

    Mike Carnell
    Participant

    @jfelten775 Here is going to be your initial problem before you even get to management. Let’s say you identify a project. Now you need to approach the process owner about why you believe there is an issue in the area they are responsible for. Those conversations traditionally do not go well and without process owner support you are going to have a real issue with making a change at the end of the project. Just a note you will have to make a change at the end of the project otherwise if it does not change, then you actually have acomplished nothing.

    In your statement you said “ownership and management.” If you are in a privately held company it can be a real challenge particularly if you have the entrepreneur that started to company. Here is an exercise that can prepare you for that conversation. Go to a park and find a person pushing a baby stroller. Stop them and explain to them that their child is ugly but you know a great plastic surgeon that can help. That is pretty much the conversation you will have with the private ownership of a company. Do some planning before you approach them.

    If you ultimately want to pitch to ownership and management. They are not interested in hearing about Cpk, hypothesis testing, control charts, Gemba, etc. Management speaks the language of money. Juran told us all that in the 80’s and it is still true today. Since you are privately held getting your hands on financials will be extremely difficult. If you can, the number that is important is EBITDA. It is unfortunately a financial metric rather than and accounting metric and a large number of accountants have no clue what it is. They will recognize EBIT. If you can find a project that impacts EBIT positively then you will get their attention. The easiest way to understand where a good project comes from is using a thing called a Dupont chart. It is basically a tree diagram of financials. Start at a thing called EBIT and start chasing it backwards. It can (assuming you understand it) lead you to a project. If you find it that way you can turn right around and use that same chart to explain the financial impact to management when you finish the project.

    As I said earlier in a privately held company financials are very difficult to get to see. If that is the case you need to familiarize yourself with a document call the Income Statement. If you have to select a project without financials (which by the way is how most do it and why most work projects nobody cares about) but you can demonstrate when you present to management that you understand the business side of the business (as opposed to the technology) you will have a more successful conversation.

    Just my opinion.

    0
    #241829

    Oliver Kozak
    Participant

    I like the metaphor from @mike-carnell, it summarizes my experience very well!

     

    I have been facing this challenge that you ask for five years now. I work as an internal consultant deploying continuous improvement in this organisation. Here are a few thoughts.

    My other metaphor would be pushing water uphill.

    So in general I think this is mainly for people who love challenges, difficult tasks, and do pioneering work. I love that, so I enjoy it.

    I found it is very-very different from leading LSS projects in an environment with a strong CI culture.

     

    a) Requirements  that I found important:

    1. There must be a business urgency.

    If there is no urgency, there is no need for a lean six sigma project. It can be financial (as written above, EBIDTA EBIT), legislative, resources, different types.

    It must be a great urgency.

    If the urgency is not identified, I help doing that. Often they have so many, that is a big mess of priorities, always jumping to the latest pull of emergencies. So I help them finding out what is impacting short, medium and long term goals, and what can be let done.

    If there is no urgency, or we don’t find any, and everybody feels all is good around them, then I usually tell them that they don’t need me, and I move on.

    If there is a big business urgency, then it is a much easier way to go forward.

     

    <b>2.  Then we prioritize projects according to the business urgency KPI, and translate change to this.</b>

    If there is a KPI linked to the urgency, it is easier, but often there is not.

    If the organisation is in a style that measures things, it is better to make a KPI, but in most cases we have to implement also a measurement system first.

    Often my work involves helping leaders identify actually how to measure the important things. Very often they tell me “here it is impossible to measure it because we are different”.

     

    3. I have to convince almost everybody in the chain from top management to shop-floor employees, including middle management.

    So I have to find for each person what will be the benefit for them in the end of the project.

    The initiative can be more top-down backed, or bottom-up backed, my results vary.

    Usually what worked for me is to look for people who want to change something, who complain, who sense a real pain in the organisation, and work with them first. I tell them this is a good methodology to reach that change that they want to see.

     

    b) Tools:

    As for which tools to use… at the beginning I used what I used to use before. However, over the years, I simplified and simplified, as most of the LSS tools are a total overkill for the organisation.

    I found that a Benefit – Effort matrix makes wonders. I rarely used it before, as I found it over simplistic, and I made Excel scoring tables to identify projects along a lot of criteria. I still do this for myself, but then for selling it, or when I want really the process owners to identify the priority, we do the Benefit – Effort matrix.

    On the Benefit scale, I put the business urgency that we identified.

    I contract them that we will implement only 1 (or maximum 3) projects from the High Benefit – Low Effort corner. This is usually very difficult, because finally they have a big inventory of things to improve.

    It’s hard to do control charts with statistics, if even measuring the process is new to them.

    Usually, I don’t use the lingo at all, and if I do, I use it gradually. It took me a couple of month until didn’t find strange to say “continuous improvement”, and I started to use the term “Lean Six Sigma” only after 1-2 years. Until then they really didn’t care and it made more confusion then help.

    However, if you were brought in as an expert with a label as “Lean Six Sigma expert”, then you can maybe use the lingo to differentiate yourself and show up as an expert.

     

    c) Process style:

    Another thing I found over the years, discussing about it with some LSS colleagues, that it helps to identify if the organisation is more a “flow style” or more a “processing style”.

    If it is flow style, where things need to go through and there is a large freedom about who does what and when, I found Lean tools and objectives are more attractive.

    If it is more a processing style, there is some physical, legal, chemical, etc. codified process that has steps that cannot be changed much because it is fixed by a physical process, or legal process, then six sigma tools make more sense at the beginning.

     

    d) Traps:

    1. We found that often we first need to do two preliminary steps:

    1. Manage the process

    2. Standardize the process

    [3. Improvement process]

    Often I find that there is “no process”. People just do things. When I ask them how they do things, they don’t have it written down as a flowchart, it is a story. And it is a different story, depending whom I talk to.

    I don’t aim to be perfect with managing and standardizing, we just do some quick and dirty of these that helps us to kick into improvement. Often the LSS project is a mix of managing, standardizing, improving – so instead of really being very good in the methodology, I rather push for getting some results out through “the factory gates”.

     

    2. Going too big first and not finishing

    Another thing that was useful for me is to use an Agile – minimum viable product approach.

    First I contract for just one small improvement project, which is to create trust, buy-in, and demonstrate what this whole thing is about.

    In the selection of the first, and even the next few projects, I don’t look so much for the big benefit, but for a very high probability of finishing the project.

    Because if the first project doesn’t deliver results, it is very hard to contract for going on. If this first project brings results, then it mobilizes energy, and we can plan a little bit bigger.

    So these projects would not be selected in a proper CI culture, because they are often low effort – low benefit.

    But it builds trust that finally change is possible.

    0
Viewing 3 posts - 1 through 3 (of 3 total)

You must be logged in to reply to this topic.