Six Sigma Teamwork: Roles and Communication on a Project Team

A common myth says a Six Sigma project belongs to the Black Belt, and everyone else simply hands over data when asked. In practice a project moves at the speed of its slowest conversation: the sponsor who releases budget, the process owner who opens the line for measurement, the Green Belt who gathers samples, and the operator who knows why the numbers look odd. This guide shows how those roles work and talk to each other on one project.

Who sits on a Six Sigma project team, and what does each person own?

Job titles differ between companies, but most programmes use the same cast. The table below puts each role beside the thing it owns and the thing it needs from the others, because a project stalls at the second column far more often than at the first.

Role	Owns on the project	Needs from the others
Sponsor	The business case, the budget and the final go or stop decision	A plain statement of the problem and bad news early
Champion	Clearing cross-department obstacles that the team cannot clear itself	A short list of blockers, with names attached
Process owner	The process that will be changed and its results after the project closes	Notice before any trial, and a say in the chosen solution
Master Black Belt	Method coaching and the quality of analysis across several projects	Early sight of the data plan, not just the finished slides
Black Belt	Running the project: plan, analysis, team and reporting	Protected hours, access to data and decisions made on time
Green Belt	Data collection and analysis in a familiar area, often one part of a larger problem	Agreed time from the line manager and a coach who answers
Yellow Belt	Process knowledge, basic data capture and help with tests	A short briefing in plain language
Team member	Knowledge of how the work is really done on a normal Tuesday	To hear why the project exists and what will change for them

Sponsor and champion

Some organisations use the two words for the same person. Others split them: the sponsor puts a name to the result and funds it, while the champion is a senior advocate who spends influence in other departments on the project's behalf. Whichever way your company draws the line, one named person must be able to say yes to resources and one must be able to say stop. A sponsor who delegates both to a project manager has not sponsored anything.

Process owner

The process owner is the only role that is still there after the team disbands. That makes the owner the most important audience for every finding, and the person most likely to be overlooked in a team list. When the owner first hears the proposed new method at the closing review, the project has already failed at communication, however good the analysis.

Master Black Belt, Black Belt and Green Belt

These three describe depth of method and not rank on the project. The Black Belt is usually the day-to-day leader. A Master Black Belt coaches the Black Belt, checks the statistics and helps decide whether a project needs more rigour or less. A Green Belt often runs a smaller project alone or owns one workstream inside a Black Belt's project. What matters for communication is that each belt knows whose analysis they are accountable for and who reviews it before anyone outside the team sees it.

Yellow Belt and team members

Yellow Belts and ordinary team members carry knowledge that no data set holds: the workaround people use when the system is slow, the shift on which errors cluster, the reason a form is filled in twice. Treat them as sources of evidence, not as labour. A team member who is asked "what did you see?" and then sees the answer on the chart will argue for the change later.

Core, ad hoc and resource members

Not everyone attends every meeting, and good teams say so openly. A common split has three groups. Core members attend all meetings and join all team activities. Ad hoc members join only when the team needs their expertise, for example an engineer during a root cause session. Resource members attend at the team leader's discretion and mainly supply information, coaching or resources such as time and money. Writing each person's group into the charter stops two opposite problems: the specialist who is invited to everything and resents it, and the one who is never told a decision affects them.

What does a project charter settle before the first meeting?

The charter is the first piece of communication on every project, and the one people refer back to when they disagree. Its headings are familiar: problem statement, business case, goal, scope, timeline, team and sign-off. Used well, each heading answers a question that would otherwise become an argument in week six.

• Problem statement. What is going wrong, where, since when and how often, without a solution hidden inside it. "We need a new order system" is a solution. "One in six urgent orders is shipped late" is a problem.
• Goal. A measure, a baseline and a target date. If the sponsor and the process owner would read the goal differently, rewrite it now.
• Scope. What is in and what is out, including the parts of the process that belong to other departments. Edges are where teams quarrel, so draw them early.
• Team and time. Names, roles, the core, ad hoc or resource status of each person, and the hours per week their managers have agreed to release.
• Sign-off. The sponsor and the process owner both sign. A charter that only the sponsor has signed is a request, not an agreement.

Ask each signatory one question

Before the kickoff, ask the sponsor, the process owner and each line manager the same question: "What would you need to see to believe this project worked?" The answers are often different. If the sponsor wants lower cost and the process owner wants fewer complaints, you have found a conflict in the goal while it is still cheap to fix. Record the agreed answer in the charter, in a sentence rather than a paragraph.

Treat changes as news, not as drift

Scope and goals sometimes have to change, and that is fine. What is not fine is a change that only the Black Belt knows about. Keep a short change log at the back of the charter with the date, what changed, why and who agreed. When the sponsor is asked at the closing review why the project covered less than the original wording, the log answers without anyone having to remember.

How should information travel between the team and everyone around it?

A project communicates in two directions at once. Inside the team, people need to know what is decided and what is next. Outside it, the people who control resources or who will live with the result need enough information to stay supportive and not enough to micro-manage. The mistake is to design for one direction only. This table maps the main flows.

Message	From	To	Usual rhythm
Progress, next steps, blockers	Black Belt or Green Belt	Sponsor, champion	Short written update every one to two weeks
Data plan and analysis draft	Black Belt or Green Belt	Master Black Belt	Before each phase review
Findings that touch daily work	Team	Process owner and the people who run the process	As found, before any slide is made
Trial dates and what will change	Black Belt	Process owner, operators, adjacent departments	Days ahead of each trial
Savings estimates	Black Belt	Finance, sponsor	At the improve and control reviews
Decisions and actions	Whoever chaired	The whole team	Same day as the meeting

One line for every audience

Each audience reads for something different. The sponsor looks for risk to the date and the budget. The process owner looks for risk to daily operations. Operators look for what changes on Monday. A Green Belt who writes one update and sends it to all three will please none of them. Write the three-line core once, then add a sentence for each audience: what it means for you and what we need from you.

Keep a single place for decisions

Teams lose weeks to a quiet problem: the decision was made in a corridor, three people remember it differently and nobody wrote it down. Keep one shared decisions-and-actions log, updated the same day, with an owner and a date on every action. It is dull and it is the single most effective communication habit on this list, because every later argument starts with "let's look at what we agreed."

Remote and shift-based teams

When members work different shifts or sites, the meeting is no longer the main channel, so the written record becomes the project. Post the log and the latest chart where every shift can see it, ask each shift lead to confirm they have read it, and rotate the meeting time so the same people are not always on the edge of the conversation.

What rhythm of meetings keeps a DMAIC project moving?

Teams meet too often, too rarely, or at random. A steadier pattern has four layers, each with its own purpose and audience. The wording DMAIC stands for Define, Measure, Analyze, Improve and Control, the five phases most Six Sigma projects follow.

1. Working session, weekly. The core team, 45 to 60 minutes. Review actions, look at the latest data, agree the next week. No presentations.
2. Coaching review, every two weeks. The Black Belt or Green Belt and a Master Black Belt, or an experienced Black Belt where there is no Master Black Belt. The purpose is to challenge the method: sample size, measurement system, whether the test fits the data.
3. Sponsor check-in, monthly or at a milestone. The sponsor, the champion and the project lead for 20 to 30 minutes. Progress against the goal, risks, decisions needed.
4. Phase review at the end of each DMAIC phase. Sponsor, process owner, champion, finance where savings are claimed, and the team. This is a decision meeting, covered in the next section.

A small example

Ravi is a Black Belt in a hospital laboratory. His project aims to shorten the time from collection to result for urgent samples. His charter names the laboratory manager as process owner, the head of diagnostics as sponsor and a Green Belt from the emergency department as a core member. The porters, who bring the samples, are resource members and the information systems analyst is ad hoc. Ravi runs a Tuesday working session, a fortnightly review with a Master Black Belt from another site and a monthly check-in with the sponsor. Because the porters are resource members, he visits their handover on Thursdays instead of asking them to attend the Tuesday session. Nobody has to attend a meeting that does not need them, and nobody learns about a change in a corridor.

Cancel gracefully

A weekly session with nothing to decide should be shortened or cancelled, and the decisions log should say so. A team that attends pointless meetings learns that meetings do not matter, and then misses the one that does. The coaching review is the opposite: do not skip it when the analysis is going well, because that is when untested assumptions get through.

What should each role bring into a phase review?

A phase review is where the roles meet face to face, and it goes badly when everyone arrives expecting a presentation. Think of it as a conversation with an agreed input from each person. The deployment article on this site covers how a programme designs its reviews overall; here the question is narrower: how one project's roles prepare for the room.

• The project lead brings the evidence for the phase, the open risks and a clear request: proceed, proceed with a change, or stop. Send a one-page summary two working days ahead so nobody reads it for the first time in the meeting.
• The process owner brings the operational reality check. Does the map match what happens? Will the proposed trial disturb a busy period? The owner should have seen the findings before the room does.
• The Master Black Belt brings an opinion on the analysis: whether the sample was big enough, whether the data support the claim and what would change the conclusion.
• Finance brings the agreed definition of a saving, and checks any figure on the improve and control reviews against it.
• The champion brings the obstacle list: what the project needs from other departments and who has agreed to provide it.
• The sponsor brings the decision. A review that ends with "we will think about it" is a failed review; the sponsor should leave having said proceed, change or stop.

Prepare the two hard conversations

Two conversations decide whether a project survives its middle phases. The first is when the data show that the problem is not where the sponsor thought. The second is when the process owner disagrees with the proposed solution. Both are far easier in a private talk the day before than in front of eight people. A Black Belt who takes a surprising finding to the sponsor on Monday and the process owner on Tuesday arrives at Thursday's review with allies and not with a shock.

What does a hand-off failure look like in real projects?

Poor team communication rarely looks like open conflict. It looks like a series of small gaps, each reasonable and none of them noticed. Three shapes recur.

The finding that nobody carried

A Green Belt discovers that most late deliveries start at a single approval step. She mentions it in the weekly session, the Black Belt agrees it matters, and the action is "raise with the process owner". Nobody writes down who will do that, so six weeks later the owner learns it from the draft final report and feels ambushed. The fix is mechanical: every finding that touches someone outside the team gets an owner and a date in the decisions log.

The sponsor who heard a different project

The sponsor remembers a project to cut costs. The team has been working on a project to cut errors, because the data said errors were the cost driver. Both statements are true and nobody told the sponsor how the goal moved. At the review, a perfectly good result is received as a disappointment. The fix is the charter change log and the sponsor check-in: every shift in goal or scope is stated in a sentence and agreed.

The team member who stopped coming

A resource member stops attending because their manager has given them urgent work. The Black Belt takes silence for agreement and carries on. When the trial runs, that person's part is not done. The fix is to put the line manager in the loop at the charter stage and to ask directly, at the weekly session, "is anyone's time at risk this week?" It is easier to answer yes in the room than to explain a missed trial later.

The sign that something is wrong

If the same question is asked at three separate meetings, the answer is not reaching the people who need it. Treat a repeated question as a communication defect and apply the project's own method: find the cause, change the channel, check that it worked.

How do you share work and decisions when members are only part-time?

Almost every team member has another job. That is normal, and it is the main reason projects slow down, so a team has to plan for it as it would for any other constraint.

Agree hours, then protect them

The charter should state the hours each person gives per week, signed by their line manager. Ask the champion to raise it if a manager pulls someone away. Without that agreement, a team member who is told to choose between a customer problem and a project meeting will choose the customer every time, correctly.

Divide work by what each person knows

Give data collection to people who already walk through the process. Give statistical analysis to the belt, with the Master Black Belt reviewing. Give process maps to the people who do the work, then walk the map with someone else for a second view. This matches the work to the knowledge, and it also spreads understanding of the project through the team.

Keep the team's size honest

A team of five or six core members with a wider ring of ad hoc and resource members usually works better than fifteen people on an invitation list. A larger group is harder to schedule, quieter in meetings and more likely to produce a vague outcome. If a department wants representation, offer a place in the resource group first.

Close the project with the same care

At the end, hand the control plan to the process owner in person, thank the team members by name to their line managers, and tell everyone who gave information what happened to it. People who see their input used volunteer again. That is how a company builds the next project team.

How does the IASSC Black Belt exam treat team roles, charters and communication?

The IASSC Certified Lean Six Sigma Black Belt (ICBB) exam tests team topics as part of the Define phase and the Control phase and not as a separate "teams" section. IASSC's Body of Knowledge lists Six Sigma roles and responsibilities, the voice of the customer, business and employee, building a business case and project charter, and financial evaluation and benefits capture under Define. It lists the elements of the control plan and the response plan under Control. IASSC says each of the five main sections contributes approximately 30 questions to the exam.

Team topic in this article	Where it sits in the IASSC Black Belt Body of Knowledge
Who does what on a project	1.1.6 Six Sigma Roles and Responsibilities
Listening to customers, the business and employees	1.1.5 Voice of the Customer, Business and Employee
The charter and business case	1.3.1 Building a Business Case and Project Charter
Savings that finance accepts	1.3.3 Financial Evaluation and Benefits Capture
Handing over to the process owner	5.3.2 and 5.3.3 Elements of the Control Plan and of the Response Plan

The exam is mostly about methods and statistics, and the roles questions are a small part of the Define section. They are still worth securing, because they are the questions that reward plain reasoning and are easy to lose through careless reading. Questions of this kind usually describe a situation, such as a charter without a process owner signature, and ask which role should act or what should happen next.

Exam fact	Detail
Exam code	ICBB
Certification	IASSC Certified Lean Six Sigma Black Belt (ICBB)
Vendor	IASSC
Questions	150
Duration	240 minutes
Passing score	70%
Price	USD 450

IASSC's exam page adds that some forms include up to 15 extra questions that are not graded, and that there are no prerequisites to sit the exam. Read IASSC's own Black Belt certification page and its Body of Knowledge before you book, because the vendor's wording is what the exam follows. For the topics in the order a candidate meets them, see the ICBB syllabus. For background on the method behind all of this, Wikipedia's Six Sigma entry gives a neutral overview.

Anyone who wants to see how role and charter questions are worded before the voucher is bought can start with the ICBB practice exam, then return to the Define section of the Body of Knowledge to fill gaps.

Frequently Asked Questions

What roles make up a Six Sigma project team?

Most teams include a sponsor, a champion, a process owner, a Black Belt or Green Belt who leads the work, a Master Black Belt as coach, and team members from the process. Yellow Belts help with data and process knowledge. Titles vary, but each project needs a named person for each decision.

Who approves a Six Sigma project charter?

The sponsor approves the charter, and the process owner should sign it too, because that person lives with the result. Line managers who release team members should also agree the hours. A charter signed only by the project lead is a plan, not an agreement.

How often should a Six Sigma project team meet?

A common pattern is a weekly working session, a fortnightly coaching review, a monthly sponsor check-in and a review at the end of each DMAIC phase. No rule fixes the rhythm. Shorten or cancel meetings with nothing to decide, and never skip the phase review.

How many questions and how much time does the ICBB exam give?

The IASSC Certified Lean Six Sigma Black Belt exam has 150 questions with 240 minutes allowed. The passing score is 70% and the exam voucher costs USD 450. IASSC says some forms add up to 15 extra questions that are not graded.

Does the IASSC Black Belt exam test team roles and charters?

Yes. The Define section of IASSC's Body of Knowledge covers Six Sigma roles and responsibilities, the voice of the customer, business and employee, and building a business case and project charter. The Control section covers the control plan and the response plan.

Select ratingPoorOkayGoodGreatAwesome

Rating: 5 / 5 (80 votes)