| name | case-study |
| description | Write a customer or project case study from verified starting context, problem, constraints, intervention, evidence, outcome, tradeoffs, and lessons without turning correlation into a heroic success story. |
Case Study
Use when a real implementation or customer outcome can teach or prove something useful to an audience.
Procedure
- Define the audience, thesis, subject, timeframe, permissions, and the specific lesson or proof the case should provide.
- Establish the starting state, problem, constraints, alternatives, and why change was needed before describing the solution.
- Document what was actually implemented, by whom, in what sequence, and which contextual factors materially shaped the result.
- Gather verified outcome evidence such as measurements, before-and-after behavior, quotes, artifacts, or operational results with clear definitions and dates.
- Separate outcomes directly attributable to the intervention from broader changes that may have multiple causes.
- Include difficulties, tradeoffs, limitations, or iterations that make the case more instructive and credible.
- Obtain approval for customer-identifying facts, quotes, confidential details, and claims according to the relationship and publication process.
- End with the transferable lesson and where the case may not generalize.
Decision rules
- A case study should explain conditions and mechanism, not simply celebrate the result.
- Do not invent causal certainty from a before-and-after snapshot.
- Customer permission and factual approval matter for attributable claims.
- Specific limitations increase credibility.
Quality gate
The case study is ready when the starting state and intervention are clear, outcome evidence is verified, causality is stated proportionally, customer approvals are respected, tradeoffs and limits are visible, and readers can understand what lesson does and does not transfer.
