Q: Which is the right way to deploy Six Sigma initiatives:
- Set up a separate Six Sigma department headed by a newly created Six Sigma manager or site deployment manager, with all Black Belts (BB) being a part of this department.
- Keep all BBs in their original departments, and have them report to their department managers, as well as Six Sigma leadership, which is not a newly created position, but instead is an existing manager who takes this task as an additional responsibility. This way, management can leverage BB resources organizationwide based on need.
A: Six Sigma deployment models vary depending on the organization’s goals, available resources, number of employees, geographic distribution, process maturity and culture. Each has its own advantages and risks. Sometimes, it helps to think about where your organization is in its deployment life cycle—launch, growth, expansion or mature—when selecting the appropriate deployment model.
For larger, more geographically dispersed organizations that are just embarking on their Six Sigma journey, I would recommend a centralized or "federal" model that has a corporate program management office (PMO) responsible for designing the curriculum and training program, selecting projects, and executing and managing those projects with its own dedicated BBs.
In this case, there’s a need to generate widespread transformational change, prove the business case, build credibility and gain momentum by tackling highly visible projects and getting some quick wins. This model requires a strong corporate PMO to enforce relentless consistency, adherence to common process, discipline, execution cadence and a common language.
While the centralized model offers more control over deployment decisions, timing and outcomes, it does require significant management oversight.
Over time, however, the model runs the risk of never fully integrating the Six Sigma method, skills and mindset into the rest of the organization’s business units, preventing them from becoming more self-sufficient. This, in turn, can create a certain level of alienation between the PMO and the business units, even leading to a perception of elitism—corporate BBs vs. all others.
A decentralized or "state" model is characterized by a smaller PMO with more BBs embedded in the business units. The PMO continues to provide the basic infrastructure—tools, training, project tracking and reporting—but leverages the BBs in the business units for identifying and executing the projects.
Accountability at the business unit level is paramount. The decentralized model provides a more flexible approach for addressing the needs of the business units, particularly as the deployment progresses, and more creativity and ownership is required. In that evolution, the organization moves from smaller, standalone projects to larger initiatives that cross business units, or shifts from traditional existing process improvement projects to designing new processes or new products.
With this model, the PMO offers strategic support in terms of coordinating with other business units, helping build the business case, and guidance or expertise in using methods such as design for Six Sigma. This model promotes self-sufficiency among the business units and fosters a more seamless cultural integration of the BBs.
Decentralized deployment models generally do not work well until the organization has reached a certain level of process maturity, moving from initial launch to scale, replication and sustainment.
For organizations without the resources to staff a team of full-time BBs to support all the business units, there is a third alternative: a hybrid approach in which the PMO maintains only a small cadre of BBs or Master BBs. While working on larger, more strategic initiatives, the BBs also train and mentor internal, part-time Green Belts (GB) supplied by the business units. These internal GBs work on projects sponsored by their business units.
This model allows the PMO to effectively distribute resources and works well in smaller organizations during the early stages of a Six Sigma deployment. This is the model we currently use at my organization.
Some possible limitations of this model are an overwhelmingly unbalanced ratio of GBs to BBs—10-to-1 is a good ratio—and the reliance on smaller, low-hanging projects that can be driven by part-time GBs.
Regardless of the model, I would stress one guiding principle: Form should follow function. In other words, strive to understand your organization’s strategic goals and objectives before designing the structure of the deployment.
Director, process excellence
For More Information
West, A.H. "Jack," "Critical Stage," Quality Progress, September 2009, pp. 22-27.
Q: In my internal auditing activities, I have occasionally worked with auditees who unilaterally close nonconformity reports in response to audit corrective action requests without any corrective action being taken. Usually, the auditee cites as justification their disagreement with the auditor’s nonconformity finding.
This does not seem to be supported by logic, research or any training I’ve had, but I also haven’t seen it expressly prohibited. Assuming there’s proper documentation of the requirement and evidence of the nonconformance, is there any justification for an auditee proceeding in this manner?
San Ramon, CA
A: There is no justification for an auditee unilaterally closing a nonconformance report without taking corrective action just because the auditee does not agree with the nonconformance cited. If and when this happens, it’s up to the lead auditor, team leader or general auditor to raise this matter to the next level of management—preferably, to the client.
The client is the person who originally authorized the audit and thus has a vested interest in an audit outcome; otherwise, the client would not have authorized the audit, even in the case of an internal audit. Every audit has a client, whether the audit is internal or external, and it’s up to this client to officially accept or not accept the closure of any nonconforming items. Therefore, the key is to figure out who the client is.
In the case you detailed, it may be that the auditee is able to convince the client that the nonconformance cited in the internal audit does not matter much, and therefore no corrective action is required.
In this case, I would highly recommend that auditors—either by themselves or through their boss—bring the client up to date about the incidents in which the auditee closed an incident of nonconformance without any corrective actions simply because the auditee did not agree with the nonconformance.
Mehta Consulting LLC