Brainstorming can produce useful possibilities, but a list of suggestions does not establish what caused a problem or which response will help. A team needs a way to connect observations, explanations, choices and follow-through. The five techniques below can be combined for an ordinary operational problem or used separately when the decision requires only one of them.
This is a new original guide using the historical topic and title. It is not recovered text from the former website. The examples are fictional.
1. Define the problem through an evidence brief
Write a brief describing what happens, where it happens, who is affected and what is known. Separate those observations from the team's explanation. “Orders miss the promised dispatch date” describes a problem. “The warehouse is inefficient” assumes a cause before the work has been examined.
For an illustrative shop, the brief might say that eight of forty orders sampled last week missed the stated dispatch window, and six of those were awaiting a stock confirmation. Record how the sample was selected and what the team has not checked. The purpose is a shared question: where does confirmation stall, and why?
Keep the investigation focused on the specific event and time period. A bounded question makes relevant evidence easier to collect.
2. Collect ideas individually before discussing them
ASQ's nominal group technique combines individual idea generation, shared clarification and prioritisation. Its structure can help a team hear contributions that might otherwise disappear in a fast conversation. For a small discussion, ask each person to write possible causes or observations silently before anyone explains their preferred answer.
Take turns sharing one item at a time, allowing people to pass. Clarify what each item means before debating it. In the order-delay example, a packing colleague may mention incomplete stock codes, while support notices that customers choose similar-looking product variants. Keep both visible even if a manager initially favours a staffing explanation.
Participation does not make an idea correct. The output is a wider set of possibilities to investigate. Do not treat the most popular suggestion as a verified cause, and offer another way to contribute when the meeting format creates a barrier.
3. Trace the process and challenge causal assumptions
Draw the actual steps from order receipt to dispatch, including handoffs and waiting states. Ask which records could show where time accumulates. Then examine possible causes at that point. Repeated questions about why an event occurred can be useful, provided each answer is checked rather than accepted as a convenient story.
AHRQ's investigation guidance describes repeated “why” questions as a way to examine contributing factors and warns against stopping at labels such as human error. Its healthcare context is specialised; this ordinary-business example uses only the general inquiry principle. Significant safety or regulated incidents need appropriate specialist investigation.
In the shop example, staff may wait for confirmation because the catalogue uses different stock codes from the warehouse list. Check sample records before concluding that this mismatch explains the delays. Other orders may wait for different reasons. A problem can have several contributing causes rather than one neat chain.
4. Compare options using agreed criteria
Once the team understands the relevant uncertainty, agree how it will compare responses. ASQ describes a decision matrix as evaluating options against selected criteria. For the shop, useful criteria might be fit with the confirmed cause, time to test, customer disruption and ongoing maintenance effort.
Compare a stock-code correction, an extra confirmation step and a staffing change. Record evidence and unknowns beside any scores. A low-effort option that does not address the observed cause should not win solely because it is convenient. Keep essential safety, privacy and operational requirements as gates rather than tradeable points.
The matrix supports discussion; it does not make subjective judgments objective. If the preferred option changes when a small weight changes, examine the uncertainty and gather more evidence before a consequential commitment.
5. Test a small change and review the result
ASQ's plan-do-check-act cycle offers a structure for trying a change, examining what happened and deciding the next action. Choose a test small enough to control, with an owner and a review date. State the expected observation before starting so the team does not redefine success after seeing the result.
For the fictional shop, update a limited set of verified stock codes and review related orders for two weeks. Track dispatch-window misses and new problems, keeping the order mix visible. If fewer orders stall, that is useful evidence, but the small test may not establish performance across every product or busy period.
- Keep the problem statement distinct from its proposed cause.
- Hear individual contributions before prioritising possibilities.
- Check process records and competing explanations.
- Compare options against explicit requirements and evidence.
- Name the test owner, review date and next decision.
Finish by recording what changed, what was learned and what remains uncertain. The team's useful output is a reasoned action and a way to check it. That discipline makes problem-solving repeatable without pretending that every disagreement or complex problem has a quick, universal solution.
Sources and further reading
- ASQ: Nominal group technique
- AHRQ: System-Focused Event Investigation and Analysis Guide
- ASQ: Decision matrix
- ASQ: Plan-do-check-act cycle
This original guide was prepared with AI assistance. Examples are illustrative. The edition date is an assigned date in this 2026 catalogue. See our editorial policy and report a correction.