--- name: brainstorming-failure-analysis description: "Facilitate a Failure Analysis session that systematically extracts lessons from past failures to prevent recurrence and improve current plans. Invoke when the user needs to learn from a project incident, a failed deliverable, a rejected milestone, or a repeated process breakdown." --- > Adapted from bmad-method:bmad-brainstorming (MIT, © 2025 BMad Code, LLC). See THIRD_PARTY_NOTICES.md. ## When to use Use this skill when a specific failure — a missed deadline, a defect escape, a stakeholder rejection, a cost overrun, or a process breakdown — has occurred and the team needs structured learning rather than a blame discussion. Typical triggers include: - A sprint deliverable was rejected at review and the reason is not fully understood - A project phase closed over budget or behind schedule and contributing causes are unresolved - A recurring defect or process error has appeared in multiple sprints - A post-implementation review revealed that a risk that was identified was not mitigated - A client or stakeholder formally escalated an issue and a structured response is required Do not invoke for future-risk ideation; use Reverse Brainstorming or the Risk Matrix skill instead. Do not invoke for exploring open possibilities or reframing a problem; use Question Storming or Assumption Reversal instead. ## Summon the SME Before facilitating, load the canonical Failure Analysis reference to ground the session in established practice. **Reading the config.** Check `.pm-kit.config.json` for the `sourcesMode` field: - If `sourcesMode` is `"online"` (opt-in): fetch the URL stored at the key `sources.failureAnalysis` in `vendor/pm-kit/sources-index.json` using your available web-fetch capability. Do not name a specific tool — use whatever your runtime provides. Ground the facilitation in what you read. Do not fabricate quotations or page numbers from any version of that page. - If `sourcesMode` is `"offline"` or the field is absent (the default): rely on your general knowledge of failure analysis as a systematic process for collecting and examining data to determine causes of failures and identify corrective actions. Cite the canonical URL from `vendor/pm-kit/sources-index.json` at key `sources.failureAnalysis` in the output. Do not fabricate quotations or page numbers. In both cases, the URL to cite is `https://en.wikipedia.org/wiki/Failure_analysis`. ## Facilitation script Walk the user through these steps in sequence. Do not skip steps or combine them. **Step 1 — Failure statement.** Ask the user to describe the failure in a single, concrete sentence that states what happened, when it happened, and what the observable impact was. Confirm the statement is bounded to a specific event before proceeding. **Step 2 — Timeline reconstruction.** Ask the user to narrate the sequence of events leading up to the failure. Prompt with: "What was the state of the project or process before this happened?" and "Walk me through what changed in the period leading up to the failure." Capture the timeline as a numbered sequence of events. **Step 3 — Contributing factors.** For each event in the timeline, ask: "Did this event contribute to the failure, and if so, how?" Identify contributing factors across at least three categories: - **Process factors** — steps that were skipped, misunderstood, or absent. - **Communication factors** — information that was not shared, was misunderstood, or arrived too late. - **Resource factors** — capacity, skill, tooling, or time constraints that created pressure. **Step 4 — Root cause identification.** Ask: "Which contributing factor, if it had been different, would most likely have prevented the failure?" Identify the primary root cause. Confirm it is a systemic condition or process gap, not an attribution of blame to an individual. **Step 5 — Impact assessment.** Document the observable impact of the failure: cost (budget deviation), schedule (days or sprints lost), quality (defects, rework, stakeholder trust), and scope (features or deliverables affected). Use measured data where available; use estimates where not. **Step 6 — Lessons extracted.** Ask: "What do we now know that we did not know or act on before this failure?" Capture at least two lessons. Each lesson is a declarative statement of a durable principle the team can apply going forward. **Step 7 — Corrective actions.** For each lesson, define at least one corrective action: a process change, a new practice, a communication protocol, or a tooling addition. Each action is assigned to a role and given a target date. Actions must target the root cause or a contributing factor, not a downstream symptom. **Step 8 — Output.** Produce the completed analysis using the structure in `TEMPLATE.md` (sibling file). Fill every section. Leave no placeholder unfilled. **Step 9 — Save the artifact.** Save the filled artifact to `docs/pm-kit/outputs/brainstorming-failure-analysis/.md`. `` is a kebab-case ASCII slug (max 40 characters) derived from the failure statement (e.g., `sprint-4-demo-rejection`). Confirm the final path with the user before writing. If the target file already exists, ask the user whether to overwrite, append a date suffix (e.g., `-2026-04-20`), or choose a different slug. The artifact must begin with the three-line provenance header below (preserved as HTML comments so they do not render): ``` ``` ## Languages The kit separates the language used for live agent–user dialogue from the language used in the saved artifact. Both values live in `.pm-kit.config.json` and are free-form strings — read each value verbatim, never infer a language from the conversation, and never select from a hardcoded list. **Facilitation dialogue.** Speak to the user during facilitation in the language at `language.communication`. Use the string verbatim. **Filled artifact (saved TEMPLATE.md output).** Produce the written artifact in the language at `language.output`. If `language.output` is absent or empty, fall back to `language.communication`. Example values either field might contain: `"en-US"`, `"es-MX"`, `"Português brasileiro"`, `"Mandarin Chinese"`. Accept any string as given. This bifurcation is the normative pattern for every skill in the kit. ## Acceptance gate When the analysis is complete, point the user to `CHECKLIST.md` (sibling file) and ask them to verify each item. Remind them that the output must be marked **PASS** or **FAIL**. On **FAIL**, invite the user to return with specific notes so the facilitation can be resumed or corrected.