The Team That Voted to Skip the Pilot
A cross-functional team of nine - production, engineering, QA, scheduling, and finance - is chartered to cut changeover time on Line 4 from 95 minutes to 40 minutes in twelve weeks. At week six, no time-study data has been collected. Two engineers dominate every meeting; the scheduler has stopped attending. The facilitator is also Line 4's production supervisor, and he has been advocating a pre-staged tool cart as the answer since week one. This week the team voted 5-3, with one abstention, to skip a pilot and implement the cart plant-wide next month. The finance representative projected $60,000 in annual savings, but when asked, could not state the basis for the number. Changeover times last month ranged from 71 to 140 minutes with no recorded causes.
1. What is going wrong with this team? Use specific team and facilitation concepts.
Read the worked answer
The team is behaving like a committee, not a problem-solving team.
- No norming happened. No ground rules, no roles, no meeting discipline, so airtime went to whoever was loudest. Two members dominating and one dropping out is the classic participation failure mode; absenteeism is a form of feedback, not apathy.
- Role conflict in the facilitator. He holds process authority (facilitation) and content authority (the supervisor with a preferred solution). Members cannot challenge the idea without challenging their boss, so the idea wins by position. This is the single most important structural defect in the case.
- Solution-first behavior. The team committed to a tool cart in week one and has spent five weeks justifying it. No data was collected because data would slow the answer down.
- False consensus via voting. A 5-3-1 vote on a technical question is not a decision; it is a split that will resurface during implementation. The minority has information the majority has not heard.
- Unvalidated benefit claim. $60,000 with no basis is a number designed to make the decision feel safe. Changeover varies from 71 to 140 minutes with no recorded causes - that variation range alone says the team does not yet understand the process.
- Charter drift. Twelve weeks, week six, zero data.
2. What should the facilitator and the sponsor do at the next meeting?
Read the worked answer
Separate process from content first - before anything else is decided.
- Resolve the dual role. Either the supervisor hands facilitation to a neutral party and participates as a content expert, or he stays as facilitator and gives up advocacy on the cart. The sponsor should make this call, not the team. This is the intervention that unlocks everything else.
- Re-charter in the room. Restate the goal, the deadline (six weeks left), and what evidence a recommendation must carry. Get agreement that no implementation decision is taken without data on the current changeover.
- Set ground rules explicitly: one conversation at a time, no idea is owned by its author, dissent is recorded not resolved by vote, decisions state their basis.
- Reopen the decision properly. Do not simply overturn the vote - that teaches the team its decisions are meaningless. Instead test the vote against the charter: was the decision within the team's authority, and did it meet the evidence standard? If not, send it back with the standard named.
- Assign the missing data work with names and dates. Two members observe and video three changeovers this week, broken into internal/external and value-added/non-value-added elements. This is the actual critical path.
- Contact the scheduler directly and ask what would make attendance possible; assume a conflict, not disloyalty.
Facilitation technique for the next meeting: silent brainstorming on changeover causes, then affinity grouping, then multivoting on which causes to attack first - this structurally prevents the two engineers from anchoring the discussion.
3. How should the team handle the plant-wide implementation vote and the unsupported $60,000 savings claim?
Read the worked answer
On the vote: the issue is not whether the majority was right, it is that a majority vote is the wrong decision mode for a technical claim with implementation risk.
- Clarify decision rights. Does this team have authority to commit plant-wide capital and disruption? Usually not - that sits with the sponsor or an operations council. If the team's charter is to recommend, the vote was advisory and should be labeled as such.
- Select the mode deliberately. Use consensus for decisions the team must own in implementation; use consultative decision-making by a named owner where speed matters; use voting only for low-stakes choices. Record which mode is being used before the question is called.
- Legitimize the minority. The three dissenters likely hold the operational knowledge - night shift, tooling quirks, changeover sequence. Their objection should be captured as a testable prediction: what would we see if they are right?
On the savings claim:
- Require the finance member to state the model: minutes saved × changeovers per month × loaded labor and machine rate. If changeover averages 95 minutes and the cart saves, say, 15 minutes, the arithmetic is checkable in ten minutes.
- Cross-check against the observed 71-140 minute range. If variation is that wide, the average is not stable and a single-point savings estimate is not credible - the first improvement may be reducing variability, not the mean.
- Treat unvalidated savings as the reason to pilot, not a reason to skip it. A four-week pilot on Line 4 with before/after data costs a fraction of a plant-wide rollback.
Recommendation to the sponsor: reclassify the vote as a proposal, run the pilot with pre-defined success criteria and a decision date, and have finance validate the benefit model before any capital commitment.