BrainstormingToolsPrevent problems before they grow
Reverse brainstorming: make failure informative.
Ask how a situation could get worse, then reverse those answers into practical ways to prevent or correct it.
Build a reverse brainstorming promptWhen to use it
Use reverse brainstorming when a team already knows what success looks like but keeps running into obstacles: project delays, confusing handoffs, poor onboarding, or recurring service problems. A hypothetical “how would we make this worse?” question can reveal mechanisms that a generic request for solutions misses.
Keep the exercise about systems and choices rather than blaming individuals. For improving an existing offer, SCAMPER may give a wider range of changes.
A four-stage session
- Name success and its opposite. Define a specific unwanted outcome that everyone understands.
- Generate failure mechanisms. Imagine deliberate mistakes in communication, timing, resources, incentives, or procedures. Do not carry them out.
- Group and reverse. Look for the common cause behind several failures, then propose a prevention or recovery action.
- Prioritize and monitor. Pick a few actions the team can actually own, along with early warning signs.
Worked example: a small team’s project delays
A five-person remote team wants to deliver a client project in four weeks, using its existing tools. The unwanted outcome is late delivery with avoidable rework. These are illustrative planning notes.
| Make it worse | Underlying mechanism | Reverse it |
|---|---|---|
| Let two people assume the other owns each task. | Unclear responsibility | Assign one owner and a due date to each milestone. |
| Promise a delivery date before estimating the work. | Unrealistic planning | Estimate key tasks and add an explicit review buffer. |
| Hide blockers until the weekly meeting. | Slow escalation | Flag blockers in the existing team channel the same day. |
| Accept every scope change without changing the plan. | Uncontrolled scope | Record new requests with their time cost and agree a tradeoff. |
| Wait until the final day for client feedback. | Late validation | Show an early draft with specific feedback questions. |
| Schedule dependent tasks as though they were independent. | Missing dependencies | Mark prerequisite tasks before assigning dates. |
| Keep decisions in private chats. | Lost context | Put decisions and changed requirements in one shared document. |
| Start everything at once. | Too much work in progress | Limit simultaneous tasks and finish the next critical milestone. |
From eight failures to three actions
Group the mechanisms into ownership, planning and scope, and feedback timing. Against feasibility and impact, prioritize clear milestone owners, a visible blocker rule, and an early client review. A new software platform is outside the budget and is not required for these actions.
Watch for milestones with no owner, blockers unresolved for more than a day, and new requests without an agreed tradeoff. Try the three actions for one week. At the next review, count ownerless milestones and delayed blockers, and ask whether the early draft exposed rework sooner. Use the result to adjust the process.
Common mistakes
- Turning the session into a complaint list. Convert a complaint into a mechanism: what specific choice or missing step creates the problem?
- Reversing too literally. “Never have delays” is an aspiration. “Flag dependency blockers the same day” is an action.
- Choosing only prevention. Some failures cannot be prevented completely. Include a recovery plan and warning signal.