I was trained in Six Sigma during my time working for a large, US based staffing firm. During my few years there, I complete their Black Belt certification program and went on to lead the quality department in one of their divisions. I was heavily invested in their quality program and taught several waves of Green Belts and mentored many new Black Belts through their certification projects.
When I started their certification program, I was excited about the opportunity to learn new skills and dive into the world of process improvement. Getting a well known certification was equally exciting.
Illogical from the beginning
As I went through the process, I butted heads with the program director (who was also our instructor) quite a bit. Logically, some of what we were doing didn’t make sense to me.
Completing a SIPOC was a big challenge because it was designed to be completely linear, and the process I was trying to improve was anything but linear. (read here about how I’ve modified the SIPOC over the years to be more valuable).
Another major problem I had was with the DMAIC process overall. Having gates at the end of each phase where the phase was declared as “finished” didn’t sit well with me, and caused significant grief through the project.
“What happens now that we’ve analyzed our data but want to take some additional measurements?” Challenging to do when the measure phase is “closed”. “I need to redefine scope of the project due to some of the findings in the measure phase.” Can’t do that without jumping through a bunch of hoops to reopen the already closed define phase.
Other issues arose throughout the project but I was able to complete everything to the director’s satisfaction and passed the test at the end of the project to get the certification.
Now that the certification is over…
One of the first things I did after completing that initial project was to “run a Six Sigma project on the Six Sigma project” I had just completed. My “Big Y” (the defect I was trying to reduce) was the time it took for me to execute the project.
As I went through and analyzed how my project went, I could see inefficiencies everywhere. The way some of the tools were used, a linear approach where 1 phase ended but later phases could warrant modifying a closed phase, and doing things “because Six Sigma says” even though they didn’t provide any meaningful value to the project all caused delays and rework.
There was so much waste in what I was seeing, it really caught me off guard.
I initially thought, “Oh… we must do it a different way and this isn’t real Six Sigma” but as I looked at other programs at well known organizations and through some of the big certification centers, I found that what I was taught was pretty standard.
There were no major gaps in the training that I went through (and the company I worked for was well regarded in the Six Sigma community as having a good training program).
Based on my findings, I set out to rebuild the DMAIC process in a way that made sense to me and removed the defects I had seen in running my own project.
What I initially came up with is how I ran projects for the few years after getting certified. The DMAIC process was no longer linear in my mind. In fact, Define, Measure and Analyze all started at the same time for every subsequent project I ran.
As I was defining problems, I was also hypothesizing why they were happening and immediately putting systems in place to measure and analyze appropriate data. I didn’t wait until I had defined every possible input, output, and process step before starting to measure things. I didn’t wait for gobs of data before analyzing.
Some might think this is ineffective because of spending time on issues before the size and impact are assessed. I did not find this to be the case, as I was quickly able to assess inputs, outputs, and steps, eliminating things that didn’t have significant impact.
Instead of a giant define then a giant measure then a giant analyze phase, I instead ran many micro cycles of define, measure, and analyze around individual inputs and problems.
While I had no formal understanding of Agile project management principles at this time, I was applying much of what Agile teaches today, breaking up a giant DMAIC waterfall into much smaller initiatives.
I also started the improve phase shortly after beginning the other phases which allowed me to start delivering value much sooner. I wasn’t waiting to define, measure, and analyze every single thing before starting improvements. I was delivering value within weeks instead of months that the first project took.
Control started after the first improvements were implemented, often while the define, measure, and analyze phases were still going strong.
This approach allowed me to get through projects much faster, and eliminated all of the rework that I experienced in my first project with reopening and closing phases over and over again.
It also allowed me to deliver value to the project’s customers faster, often times having the first improvements show up a few weeks after kicking off the project instead of months later after the define, measure and analyze phases were completed.
Further refinements over time
These days, I rarely run formal projects anymore. I’ve found after many years of improving processes, the formal projects are generally too big, too slow, and have too much overhead for modern business.
Because of the huge investment of time and resources, they also require “huge justification” which means spending days, if not weeks, trying to prove out how much money you saved because of the project.
While I’m all for calculating ROI where it makes sense, I find that generally, in regards to process improvement, it’s not super valuable. Calculating with fine precision the amount of money saved when the project is over doesn’t make your project more valuable.
For projects today, I recommend using a Value Stream Mapping exercise that can be completed over a day or two. Document the existing process with some additional, lightweight details around how long each step takes (I use my SIPOC 2.0 template). Relentlessly attack each step, questioning its real value to the paying customer, and remove anything you can that a customer isn’t willing to pay for.
Use Six Sigma tools where appropriate to further understanding. Kano Models, Pareto Charts, Fishbone Diagrams, 5 Whys and other tools are all very helpful in understanding different components to the process.
Even if you’re working on an internal process that doesn’t touch the paying customer, removing as much non value added steps as possible will reduce the opportunity for defects, simplify the process, and save time.
Define a future state process that is focused on reducing waste and put mechanisms in place to catch defects before your customer does. Draw out a plan to get from today’s process to the future state, then get to work in an Agile fashion, prioritizing and completing tasks in short cycles to provide value now instead of 6 months from now.
Questions or comments? Send us a message by contacting us via the Contact Us page.
For videos on how to use technology to improve your productivity, efficiency, and effectiveness, visit our partner channel, Beeline Tech Group on Youtube.