How Long Should It Take to Complete Projects at Different Belt Levels?
- March 20, 2018 at 12:23 am #55963
Could you please clarify that how much time we should take for Yellow Belt Project, Green Belt Project, Black Belt Project & Lean Project. Here, I got confusion some of them saying that project completion is depends on scope.
Thiyagu NagarajMarch 20, 2018 at 9:13 pm #202375
Depends on scope, complexity of problem, and resources along with urging of the project champion.March 29, 2018 at 7:15 pm #202406
@thiyagu As Chris Seider said it really doesn’t have anything to do with which type of belt is working the project in terms of time. It is about what the project needs to resolve. Imagine a X & Y axis with the X axis being technology and the Y axis being control. This isn’t one of those matrix where you throw peoples opinions into a matrix and call it an analysis. this is data driven, If your technology scale runs from 0-6 sigma and your control runs from 0-3 sigma, A project in the 3-6 sigma technology is good technology and 0-3 is poor technology. Control is 0-1.5 sigma for good control and 1.5 -3 sigma for poor control. Any project with good technology goes fast i.e. good technology + good control are just optimization – very fast and good training projects. Good technology + poor control are control projects still fast but not as quick as optimization. Anything with a technology issue is slower. Poor technology and good control is slow but it is a pure technology issue. If it is poor technology and poor control it is a mess and is a long project.
This was all in an article I wrote in Six Sigma Forum Magazine about 10 years ago. It tells you how to do the analysis. If you can’t find it and still want to figure this out you can email me at email@example.com and I can walk you through some of it.March 30, 2018 at 7:04 pm #202412
I agree with @mike-carnell except that there is a reasonable expectation that lower belt levels should do simpler projects with less time to complete. There is no rule of thumb. It depends on how much the organization is willing to invest/risk in the project given level of expertise. There are some projects you may want experts to do, even if the estimated time to complete is short. There are others that are suitable for beginners, even if the estimated time isn’t short.March 31, 2018 at 4:32 pm #202424
@Straydog Time to completion is independent of belt level. Regardless of the belt level if I give a technology shift type problem it still takes longer than a Control or Optimization type project.
We set this thing up to operate as you said with simpler projects going to GB teams but the leadership in most SS deployments doesn’t pay that much attention or they abdicate their responsibility for project selection and send them out to find their own projects.April 1, 2018 at 4:14 pm #202429
@mike-carnell I really agree with your last statement. In my division of AlliedSignal we expected the newly-trained to select their own projects, assuming that they knew what critical problems they were seeing, and then get their projects approved after writing a convincing charter. It was definitely an abdication of management responsibility. It resulted in many projects that existed only for someone to get a belt.April 3, 2018 at 8:11 am #202434
@Straydog This is that passive aggressive behavior by middle management. Everyone has know for decades the way you get rid of a QA person is to constantly send them back for more data. The newest version of that is turning down their project ideas. Pretty basic resistance to change.
I have sat here for years and listened to all the pontification about you keep belts in their assigned areas, don’t collocate them, etc. If you have a bunch of belts collocated and they get assigned projects form the SS Program Manager who has a pipeline of suggestions from the entire company. What will happen the person that puts in good projects gets resources and very likely some of those will come from someone who had absolute crap projects. Even the dumb ones will eventually figure it out and put some effort into it.
Just my opinion.April 3, 2018 at 5:40 pm #202437
@mike-carnell From that experience back in the nineties I realized that one of the worst things management can do is make it about earning a belt. Although all salaried employees got GB training and were required to complete a project to earn a belt, it didn’t lead to the expected rapid culture change. It became about earning that belt. Maybe even worse, only a select few got BB training. The goal was to make everyone a GB and for each unit to have a prescribed (ideal) number of BB’s. For the most part people selected for BB training were on the management/promotion track, and never did a project again. Neither did the vast majority of the GB’s for that matter. Doing improvement projects wasn’t part of their regular job. On the good side, there was a core of engineers and improvement professionals who soldiered on. But, again on the bad side, these were often the people whose jobs became unnecessary when there were staff reductions.
To get back to @thiyagu, you’re asking the wrong and essentially counter-productive question. What you really care about is the culture change. Not the number of people trained, belts obtained, differences in requirements for earning belts, projects completed, or even cost/benefit (A valid criticism of SS when it first took off was that companies failed to show bottom line improvement on financial statements although they claimed millions or billions in savings from SS programs.)April 5, 2018 at 7:33 pm #202445
@thiyagu I remembered something that I thought would help reinforce the point that it’s about doing the right projects. Sure, lower belt candidates usually do simpler and shorter projects. But never do a project that doesn’t lead to better serving the customer or that doesn’t align with strategic goals and objectives. A team chose to fix unreliability problems with a payroll system. Time sheets from time clocks and supervisor input were collected then transmitted to a central hourly payroll system and there were many things that could cause failure. An IT staffer, and others, were on overtime duty to fix problems and make sure the data got to the central system before the midnight Friday deadline. The team put in a lot of work to fix this. They did, earned their belts, and were applauded. This did nothing for the customers. And what no one on the team or their managers knew was that a decision had been made at a higher level to outsource payroll processing. Shortly after the project the entire system was replaced.April 15, 2018 at 10:49 pm #202474
Thank you very much for your answer
You must be logged in to reply to this topic.