At least three kinds of knowledge are vital to the success of a Six Sigma project in any organization:

• Knowledge of the Six Sigma methodology – its steps, tools and techniques.
• Knowledge of the process being improved – how that process is currently implemented, what are its SIPOCs (suppliers, inputs, process, outputs and customers), what is the process flow, etc.
• Knowledge about the organization – its goals and current situation, alternative practices that could be of use in the current process, etc.

The Six Sigma community has been committed to assuring that the first type of knowledge is present, thanks to a Six Sigma infrastructure that demands thorough training, and provides a network of Black Belts and Master Black Belts to support projects. There is, however, a paucity of tools and strategies for assuring that the other two components are available.

Of course, there are tools for brainstorming, organizing ideas, and promoting ingenuity and innovation. But these tools can only help bring to the surface the knowledge and intuitions that the team already has about the process.

Is Project Team Knowledge Enough?

At its root, Six Sigma still assumes, as the re-engineering methodology did, that team knowledge and abilities are enough for improving a process and for solving the problems the team may encounter. Along these lines, knowledge is only explicitly mentioned when highlighting the need for building a knowledgeable team, particularly in regard to process knowledge, along with some measure of a broader perspective – meant to promote innovation and a fresh look at things.

However, the practical limitations on the size of a workable team impose limits on the breadth of knowledge that the team itself can have. Team membership cannot include all the specialties involved in a complex problem, all the parties that are affected by the problem and may be impacted by the solution, or all the experience gathered across different locations and organizations. Hence, in every practical instance, there is a need to look for knowledge beyond the team, with very little in terms of the specific tools that can help do it.

How to Access Corporate-wide Knowledge

Whatever is done to bring external knowledge into the project has to be:

• Effective in surfacing the knowledge needed.
• Efficient, so it does not impose significant time demands on people outside the team, or long delays to the project.
• Respectful of the contributors, as well as of the core team ownership of the project and of the proposed solutions. It cannot create undue expectations, or force the team to follow a particular path.

This is familiar terrain. Indeed, the whole dynamics of a Six Sigma team is based on facilitation techniques that assure effective, efficient and respectful team interactions. All that is needed is corresponding techniques for the specific purpose of tapping knowledge outside the team boundaries.

Fortunately, such techniques have already been developed in order to solve a similar problem in a different environment. A particularly useful one is the “peer assist,” a meeting format devised by facilitators within the BP Oil Company to address the need to share knowledge across its widely dispersed geography. The format is designed to involve peers from different locations and organizations, leading them to internalize the issues and to put themselves into the shoes of the core team for the duration of the meeting.

A typical peer assist proceeds through several stages:

• Sharing the project context and objectives
• Learning about the peers’ own context and their relation to the issue at hand
• Presenting the core team’s draft product
• Discussing possible improvements
• Providing some final feedback

(A more detailed description of these stages and the tools to support them is found in the book Learning to Fly (Capstone Press, 2005) by Chris Collison and Geoff Parcell. Implementation in the context of a Six Sigma project demands a level of customization, but the main suggestions in the book can serve as an initial guide.)

The original BP peer assists were geared toward complex problems and were meant to last for a couple of days. However, the basic structure can be adapted so the needed input can be gathered in just a few hours, leading to valuable insights for the Six Sigma team.

The abbreviated session was put to the test in a recent project. After unsuccessfully attempting to convince key stakeholders of the importance of an issue and the value of its solution, a Six Sigma project team decided to invite the stakeholders into a peer assist. Two important transformations took place during this meeting:

• The invited stakeholders developed a significant sense of ownership and commitment to the success of the project.
• The core team realized how many important issues it had missed, and understood the source of the stakeholders’ resistance.

The peer assist meeting resulted in a revised solution and follow-up conversations, which met both the original goals and the additional requirements raised by the stakeholders. While a more careful drafting of the original solution might conceivably have led to a similar end product, it would have taken significantly more time, and resulted in significantly less buy-in.

Additional Opportunities for Leveraging Knowledge

Two additional tools, also originally developed at BP, can be extremely valuable for surfacing knowledge and for enhancing project performance:

• Retrospects – Facilitated meetings to reflect on what was learned from a whole project, phase or pilot test, and to discuss what can be done to improve it for future implementations.
• Action reviews – Brief meetings aimed at learning from the execution of a short activity via a simple review of “what was supposed to happen” and “what actually happened.”

These tools were used in the pilot implementation of a new, complex process. While pilots are implemented precisely in order to learn and to improve on the proposed solution, it is surprising how lax some teams can be in documenting lessons learned through the pilot, or making sure that they are incorporated into the final solution.

In this particular instance, the team planned and performed action reviews at each pilot location at the end of every training day and every workday during the pilot. A retrospect was done on each of the locations at the end of the pilot period. These activities involved primarily the people at each site who implemented and were affected by the new process.

This structured approach allowed the collection of myriad suggestions which, when stripped of duplication, provided more than 200 suggestions for improving the process being piloted and the tool that supported the process. It was a much more extensive list than any informal recollection would have been able to provide. Moreover, the ownership that was gained through these discussions turned the stakeholders at pilot sites into advocates for the new process. The suggestions were prioritized by the project team and some key stakeholders, who decided which improvements to include in the final multi-generational plan.

Action reviews and retrospects also can be leveraged for improving Six Sigma team performance, and for continuously learning how to fine-tune the Six Sigma deployment itself.

Conclusion: Value in Formally Engaging Stakeholders

Six Sigma has proven its enormous value in harnessing data and information to improve process performance. So far, its handling of knowledge that resides in the organization beyond the team, has not benefited from the same rigor and thoroughness. The Six Sigma framework, with its proven ability to assimilate additional tools and techniques, provides an excellent platform for the inclusion of explicit tools that can tap into the wealth of corporate-wide knowledge.

Tapping other people’s knowledge enhances the Six Sigma practitioner’s respect for their experience, and it also opens them up to considering new possibilities. A significant level of engagement can be gained by humbly assuming that project teams will need to tap into stakeholders’ knowledge, and by formally including the interactions needed to accomplish this task. This also assures that project teams arrive at an effective and workable solution that can represent a significant performance improvement and minimize troublesome disruptions.