Using Six Sigma Alumni to Support Your Program

Six Sigma – iSixSigma Forums General Forums Implementation Using Six Sigma Alumni to Support Your Program

This topic contains 7 replies, has 4 voices, and was last updated by  Mike Carnell 6 months ago.

Viewing 8 posts - 1 through 8 (of 8 total)
  • Author
  • #56017

    Hebe Alexander

    The company I work for promotes a Six Sigma culture by repatriating Black Belts back into the business in other roles after a couple of years of project work so we have a lot of Six Sigma alumni in our business. I’d like to hear from some of you in similar situations to see how you are using that talent pool (or how you’d like to use it if you had it available) to support your current Six Sigma program.



    It sounds like your company might be doing something that was pretty common when six sigma exploded as a management philosophy. Some even said “six sigma is the way we do business.” People on the management track were required to be trained and certified. Then they moved on, hopefully utilizing what they’d learned but never doing an improvement project again. My experience is that these people could be champions or sponsors but couldn’t be depended on for more than that. Others who were required to be trained/certified went back to their “regular” jobs and no longer had time to devote to it, even if they wanted to. It was pretty much a failed management philosophy although it did change the culture. That culture change supports your current program but alumni are not a talent pool.



    A couple thoughts having experienced this as well.

    Once our former BB’s move back into the business we used them as conduits to identify projects to help support them in their new (old) roles. We used them to simply identify and write basic problem statements on areas where it appeared a more structured project approach would show measurable success and enhance the business. They became the pipeline to prioritize and assign project work to the current BB candidate team.

    As Strayer stated above, they make excellent champions/sponsors as they usually had some skin in the game if they found the project. Most were enthusiastic supporters and understood what made a good project. Also as above they really didn’t have time to lead projects as they had ‘real’ jobs again.

    This mentality and ‘ask’ became a project feeder into the program and kept the new BB candidates supplied not only with projects, but in most cases also with solid support to see a project through. Win/Win.

    I can tell you though that in all cases, as the big projects dried up, each company quickly moved to either a Lean or Six Sigma Lean blended approach. The reason being is that the length of time, usually 4-12 months was too long to wait for change and leadership got tired of the waiting with minimal impact on smaller scoped work.


    Mike Carnell

    @hebe There are a lot of ways this has been done and you really need to do something that is consistent with your current company culture. There was a division of Allied Signal that required EVERY management person to teach a module in the training sessions at least one per year to avoid the issue of no visible top management support. Some companies run study halls and they have mentors in those study halls. There are no best practices that are perfect for you.

    The part I don’t understand is if I am in a management role and I was a BB why would I not still be doing projects? If a person leaves a job and improvement stops being their job then maybe there is a culture opportunity? Continuous Improvement only belongs to current BB’s. There is a silo. When we did Wave 1 in Allied Signal Safety Restraints I had a BB that was pulled right at the end to run a department. When he arrived all his direct reports informed him they knew he had just come from the BB program and they didn’t need any of that stuff. He said that was fine. During his first production meeting someone was talking about a particular defect. He asked how many they had. Nobody knew so he asked them to count them for the next days meeting. In a couple weeks everybody was counting defects and making charts, etc. Nobody ever made a big deal out of it and nobody had to go stand on a table in the cafeteria and announce they were about to begin to do a project. It was just how things were done.

    Understand if you turn project selection over to SS alumni you will tell everyone else that project selection is not their job. Look at your belts and their projects as inventory. If I want 5 projects per year per BB and I have 5 BB’s then I have an inventory of 25 projects. That should mean that management sits down together and decides which are their top 25 projects and assigns them. They are a finite resource so you manage it that way. If projects and project management gets shoved off on someone else then it begins to slide in priority. This is not a big time commitment. The leg work on what is on the list doesn’t have to be done by the C suite but the decision of what to run should be. Remember “I don’t have time” is just the adult version of “My dog ate my homework.” The whole idea that a project takes 4-12 months is nonsense. It takes that long for training. If you continue to take that long you have a poorly managed/not at all managed program. I have seen BB projects done in 48 hours.

    Just my opinion



    @mike-carnell – I have never had a real project done in 48 hours. If it was that simple it was a JDI (Just do it) and the solution and identified change was within small span of control thus not worthy of calling it a project at all. I have had many of those. My opinion.

    I completely agree 4-12 months is nonsense. In most cases on a pure hours scale it could be measured in days or weeks, from data gathering to implementation, as most needed some level of IT support for the solutions in the worlds I worked. The rest of the time was allowing folks to also manage their ‘real’ jobs so had to make allowances for their schedules. Many times I have argued if it was important enough to provide resources, it should be a priority for the teams to no avail. Culture and other initiatives have to play out at some level.

    Back to the original questions posed, Most individuals promoted to leader roles have priorities other than projects. Keeping the skill set sharp and using the tools should be encouraged, use it or lose it. Time management, mentoring and leading others, and the responsibilities of the new role, in most cases, don’t allow for good timely project leadership. I like the example of the leader asking the team to bring data and challenging them to learn to process think and use the tools. I wish it happened more often.


    Mike Carnell
    Participant It must be in the difference in the Way we see projects. For us if the solution is known, executed and confirmed that is a Just Do It project. If something goes through the steps of DMAIC then it is a Six Sigma project. I am amazed at your ability to decide a project was a JDI based only on the amount of time it took rather than the process used to resolve the problem. That sounds a lot like one of those “close your eyes and use the force” kinds of knowledge. I don’t have that super power so I just stick with the data from the process that was used.

    Using that term “real jobs” is opening the door for people to use the excuse that their real job takes to much time and Continuous Improvement is the job of someone else. We don’t allow that language so we don’t have to deal with that behavior. When the CI people use it it, is very empowering for the Passive aggressive people who are resisting change.

    I owned a manufacturing company for 9 years. We had people who could do a SS project but had no idea what SS was. We didn’t use the term. We didn’t use the term Lean. We ran on data and when people started talking they knew they needed data because unless they could support their assumptions with data Then it was an opinion. They understood the flow of logic but nobody worked to some list of tools. We had this amazing process – we talked to each other. SS has become a check list for people who don’t actually understand what SS is and are being mentored by people who aren’t putting out the effort to understand projects.

    Why do deployments fail? Sloth Leadership.

    Just my opinion.


    Hebe Alexander

    All, thanks for the good observations and discussion. A lot of it resonates. My company is mature in 6S so we do employ LEAN more often than pure 6S now. I take the point about ‘real jobs’ but the reality is many of these ex-BBs are in positions where they spend their time putting out fires. We all understand that if they integrated the discipline and methodology – and passed it along painlessly to their direct reports – there would be a lot fewer fires but it rarely seems to work that way. The biggest behavior I see is that ex-BBs are more likely to invite current BBs to the table at the beginning of project work.

    I’m processing this conversation and, again, appreciate the input!




    Mike Carnell

    @hebe If in fact your former Belts are spending their time putting out fires you probably need to learn the difference between a mature SS deployment and an old SS deployment. If your belts are spending all their time fighting fires and are not using the SS skills to get rid of problems then you need to change the way they are trained.

    Strip away all the esoteric BS around a project so it isn’t some bureaucratic nightmare and get stuff fixed. Start tracking time to complete a project and all the long project times will get shorter. You track by Phase (DMAIC) and type of project (Optimization, Control, Poor Technology Good Control, Poor Technology Poor Control).

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

You must be logged in to reply to this topic.