Some authors say at least 60% of change efforts fail to achieve lasting results.
In “Why Process Improvement Projects Go Wrong,” Professor Satya Chokravorty shares how and why a majority of Six Sigma implementations fail.
Professor Chokravorty found:
…that when confronted with increasing stress over time, these programs react in much the same way a metal spring does when it is pulled with increasing force—that is, they progress though “stretching” and “yielding” phases before failing entirely. In engineering, this is known as the “stress-strain curve,” and the length of each stage varies widely by material.
After explaining a typical story of stretching, yielding and failing, Professor Chokravorty provides four actions managers or executives could take to eliminate the failure of the change initiative.
- Keep an expert embedded in the change longer.
- Tie all team member pay to the success of the change effort.
- Teams should have no more than six to nine members and project timelines must be no longer than six to nine weeks.
- Executives need to directly participate in team projects not just “support” them.
While, as an engineer who studied stress-strain curves, I’m entertained to read a business article applying the curves to change management, Professor Chokravorty’s suggested steps to eliminate Six Sigma failures leave me disappointed.
All the actions offered are versions of coercion (e.g., orders, fear of negative consequences, removal of positive consequences) to externally compel someone to change. I’ve previously defined these as driving people actions.
Why not try driving change instead?
Driving change is choosing a change for yourself and clearing the obstacles for others to internally choose the change too.
Read below the fold for how I’d translate the four actions above into driving change actions.
Here’s how I would transfer the driving people actions into driving change actions, making the actions about assisting team members in applying their internal motivation to improving their job for the sake of themselves and their company.
- Instead of keeping an expert embedded in the change longer, offer teams the use of an expert as long as they thought they needed one, not to exceed some amount of time. Within the time allowed to have the expert, the company could offer a range of professional or on-the-job training opportunities for the manager to choose to work toward competence in Six Sigma processes.
- Instead of tying the change to their performance appraisal, try recognizing small and large wins and rewarding team efforts to embed the changes in their culture. Provide access to larger amounts of support funding or greater training options for the team the more they achieve. Reward the team with greater trust and greater investment for every accomplishment they create.
- Instead of arbitrarily limiting teams to nine people with nine weeks to work, why not create teams of “get to” people, by asking for initial volunteers, then build disciplined plan of action reporting into their structure (e.g., a bi-weekly meeting with reporting of accomplishments and challenges) requiring teams to choose when they plan to be done with their implementation and what their teams success will look like when it is done (i.e., set and share their vision or picture of the future)? I’ve found this method works more than 60% of the time. With that step alone you’ve gained more than 20% more success.
- Instead of forcing your way onto the teams, executives should actively show their support by listening to team reports, responding to a team’s legitimate obstacles, and assisting the team with removing the obstacles. This “support” forms a bond of trust between the executive and the team, leading to both project success and secondary non-Six Sigma related work improvements.
My bottom line: When managers or executives stop trying to figure out ways to better order people not to fail and turn their executive attention to unleashing the potential in their teams, they’ll actually find themselves succeeding (notice I didn’t say “not failing”) more often. Why not try?