Adaeze Mensah spent three years as a consultant helping clients implement AI-assisted inventory forecasting. The results were consistently good; her clients reduced overstock by an average of 22% and cut emergency procurement costs in half. But when she started building her professional portfolio, she realized she had almost nothing to show for it: a few internal slide decks, some raw numbers in a spreadsheet, and her own memory of what had happened. She had delivered genuine results and left no record a future employer or client could evaluate. She decided to build three proper case studies. Learning how to do that well took longer than the projects themselves.

A well-built AI case study is one of the most durable assets in a professional portfolio. Unlike a resume, which lists experience in abstract terms, a case study demonstrates capability concretely: here is a real problem, here is how it was approached, here is what resulted, and here is what that means for someone deciding whether to hire or partner with you. It shows not just that you can implement technology, but that you can measure results and connect technical work to business outcomes.

What a Case Study Has to Do

A single well-made case study serves four audiences at once, which is why the effort compounds. As a portfolio artifact it demonstrates your specific contribution to an AI-driven outcome; as an internal knowledge asset it captures organizational learning for the teams that come after you; as a stakeholder communication it makes results legible to people who will never read a model card; and as a hiring signal it gives a hiring manager concrete evidence of your work and your judgment.

An AI case study also has to answer questions a traditional project write-up never faces. What did the AI system actually do? How confident are we that the AI, rather than something else happening at the same time, drove the outcome? What limitations or risks were managed along the way? Where did human judgment remain necessary even with AI in the loop? These questions demand a layer of epistemic honesty about the system's role. Practitioners often fear that admitting uncertainty weakens the case; it does the opposite, because readers who work with these systems know their limits, and a write-up that never mentions any is the one they stop believing.

The Problem, Solution, Result Arc

Every compelling case study follows the same underlying structure: here was the problem, here is what was done about it, here is what changed. The problem must be specific and felt. "Inefficient inventory management" is too vague. "The team was placing emergency purchase orders at 2.3× standard cost in roughly 40% of product categories, because forecast accuracy was too low to pre-order confidently" is a problem. The solution must be accurate about your actual contribution: not what the project did, or what the tool did, but what you designed, recommended, configured, implemented, or facilitated. A case study that overstates individual contribution is easy to unravel in an interview. The result must be verifiable and framed in business terms, which is the subject of its own section below.

The consulting world's SCQA framework, standing for Situation, Complication, Question and Answer, gives that arc a sharper edge because it builds narrative tension deliberately. The Situation is the organizational context before the initiative: the current state, the processes that existed, the baseline metrics. The Complication is what was not working, or what opportunity was being missed, and why the status quo was insufficient. The Question is what the initiative was designed to answer, often something close to "could AI solve this better than what we are doing now?" The Answer is the heart of the piece: your actions, the approach taken, the evidence of impact, and what it implies for anyone facing a similar situation. Of the four, the Complication is the one practitioners consistently underinvest in, and without stakes established early the Answer reads as anticlimactic no matter how good the results were.

Being Specific About Your Contribution

Strong case studies are explicit about what you personally contributed versus what the broader team or system achieved. This is not about claiming undue credit; it is about giving readers the evidence they need to assess your capability, which they cannot do if every sentence is written in an ownerless passive voice. For each major aspect of the initiative, work through the same questions: what was my specific role, what decisions did I own, what did I create, where did my judgment matter, and what would have been different without my contribution?

Then frame the answers with action verbs tied to outcomes. "Designed the evaluation framework that revealed the model's bias on edge cases" tells a reader something; "worked on model evaluation" tells them nothing. When many people contributed and singling yourself out feels awkward, be scrupulously accurate about your own role while crediting the team for collective success. A grammatical convention does most of that work: first-person singular for your actions ("I designed the evaluation framework") and first-person plural for team actions ("we ran a two-month pilot with the claims team").

Choosing the Right Metrics

Technical metrics such as model accuracy, F1 score (a measure of a model's precision and completeness) and latency belong in the appendix, not the headline. Business audiences care about metrics that connect to cost, revenue, risk, time, or quality. The translation is mechanical once you see the pattern: "forecast accuracy improved from 71% to 89%" becomes "emergency order frequency dropped from 40% to 11% of product categories"; "model inference time reduced to under 200ms" becomes "procurement recommendations are now available the same morning demand signals are received"; "reduced false positive rate by 35%" becomes "the compliance team spent 120 fewer hours per quarter reviewing flagged transactions."

Include both the technical metric, for credibility, and the business translation, for relevance, but lead with the business impact. Then be honest about what you can and cannot attribute: if other things changed during the implementation period, say so. A case study that acknowledges confounding variables is more credible, not less, than one implying every point of improvement came from the model.

The Evidence Hierarchy

Not all evidence carries the same weight, and knowing the ranking tells you what to lead with. The hierarchy below runs from strongest to weakest, with an illustrative claim at each level.

The bottom row is the one to watch. Activity counts feel like evidence because they are numbers, but with no outcome attached they say only that the system ran. Use them as texture inside a paragraph that establishes impact some other way, never as the headline claim, and structure the case study so the strongest available evidence appears early.

The Pre-Writing Interview

Before writing a single word, interview the people who lived through the initiative. Ask the business sponsor what problem they were trying to solve, whether it got solved, and what surprised them. Ask a frontline user what changed in their daily work and what could still be better. If there was a skeptic, ask what their concerns were and whether those concerns were addressed. Those short conversations yield three things you cannot get any other way: specific details you had forgotten or never knew, credible quotes you can use with permission, and a reality check on the narrative you had already half-written in your head. Practitioners who skip this step tend to produce case studies that are technically accurate and strangely detached from human experience.

Telling the Human Story

Numbers alone do not make a case study memorable; the human story does. Who was most affected by the problem, and how? What did the change mean for the people doing the work? What resistance did you encounter, and how was it worked through? What surprised you? The most persuasive line in a case study is often a direct quote from someone whose work changed, not a percentage.

Adaeze's best case study included a two-sentence description of the senior buyer who had been manually adjusting forecasts every Friday evening for six years. After the tool went live, she stopped doing the Friday sessions. That detail, specific and concrete and human, made the case study more memorable than any chart in it. You do not need to name individuals; you need to show that real people were affected, and how. Visual evidence works the same way: before-and-after process diagrams communicate workflow change in a way words struggle to match, a time-series chart of a metric across the deployment boundary replaces paragraphs of description, quotes set apart from the body supply social proof, and a worked error-analysis example showing where the system performs well and where it needs human review demonstrates real understanding of its behavior. Two or three well-chosen visuals lift engagement noticeably.

Handling Limitations Honestly

Credible AI case studies acknowledge limitations, but where and how you present them changes how they land. The reliable pattern is a sandwich. Present your strongest positive evidence first and establish credibility before introducing caveats. Then present the limitation specifically and constructively, in the form "the model's accuracy declined on edge cases involving this particular condition, which we mitigated by requiring human review for those cases." Then return to the overall value proposition: "despite these limitations, the net result was a 35% reduction in processing burden, and the edge-case handling approach produced an audit trail that improved regulatory review."

The structure acknowledges reality without letting the caveats swallow the impact narrative, and it does something subtler as well: naming a limitation precisely, along with the control you put around it, is itself evidence of judgment. Readers trust a case study that admits imperfection more than one presenting unqualified success, because they have never seen an unqualified success in their own work.

Two Versions for Two Audiences

Write every case study in two versions at the same time, because you will need both and you will need them at short notice. The full narrative version, for your portfolio, for peer sharing and for detailed stakeholder use, carries the complete structure, a methodology section, quantified outcomes and lessons learned, and typically runs 1,500 to 2,500 words. The executive abstract, for a professional profile, a resume bullet or a senior stakeholder pitch, runs 150 to 250 words covering the problem, your approach, the quantified outcome and one key insight; it leads with impact and gives just enough context to invite a follow-up question.

A portfolio case study aimed at a professional audience sits between the two, at roughly 600 to 1,000 words plus supporting visuals; longer than that signals poor editing more than depth. Having each version ready in advance prevents the commonest distribution error, which is sending the wrong document to the wrong audience and watching it fail for reasons unrelated to the quality of the work.

Internal Debrief Versus Published Case Study

The internal debrief and the publishable case study are two different documents, and conflating them produces something that serves neither. An internal debrief is a learning document: what went wrong, what was cut from scope, what the team would do differently, which assumptions turned out wrong, what the client rejected. A publishable case study is a communication document, accurate but curated; it tells the story of what worked, does not omit failures dishonestly, and emphasises insight and result over internal process detail. Write the debrief first, while memory is fresh, then draw the publishable version from it.

The same split governs what each version may contain. An internal version can carry specific financial metrics and cost data, organizational and political context, honest assessments of what did not work, and the names of teams and individuals involved. An external version needs sensitive business data de-identified into percentages and ranges, proprietary process detail omitted, the focus shifted from organization-specific context to transferable lessons, and sign-off from the organization before it goes anywhere.

Approvals and Confidentiality

Before you publish or share any case study, check what you are allowed to say. Most organizations have policies covering external publication of project results, and even if you were the consultant or contractor, the results may belong to the client. Data about cost savings, efficiency gains or operational metrics is often treated as commercially sensitive. Get written approval before publishing, and even for an internal portfolio attached to a job application, know what your non-disclosure agreement covers.

When constraints are real, and in regulated industries they usually are, a few techniques keep the substance while dropping the sensitivity. Use percentage changes instead of absolute figures, so "a 35% reduction" replaces a specific savings total. Describe the organization generically, so "a regional healthcare system" replaces the hospital's name. Use outcome categories where exact figures are restricted, so "a significant reduction in processing time" replaces the underlying hours. An anonymized case study with solid structure is worth more than no case study, and more ethical than a detailed one published without permission.

Building an Organizational Case Study Library

Organizations that accumulate a searchable, consistently formatted library of AI case studies gain a compounding advantage in AI capacity. New project teams start from documented experience instead of from scratch, leadership can assess program maturity and see which patterns are worth replicating, recruitment material can demonstrate real capability rather than assert it, and external stakeholders such as regulators, partners and investors can review documented governance and impact instead of taking a presentation on trust.

Building the library takes four unglamorous things: a consistent template so entries are comparable, a designated librarian or rotation so the job belongs to someone, a regular submission cadence such as quarterly, and a promotion mechanism that makes finding the library easier than ignoring it. The last is the one most organizations skip, and it is why so many well-intentioned repositories end up as folders no one opens.

Structure for a Portfolio Case Study

Within the 600 to 1,000 word budget, a reliable structure runs in six parts, and working through them in order surfaces the gaps in your evidence before a reader finds them.

• Context, two to three sentences: industry, organization size, and the scope of your involvement.
• The problem, one paragraph: specific, felt, with at least one concrete number.
• Your approach, one to two paragraphs: what you designed, recommended or implemented, with your role stated plainly.
• Results, one paragraph: business-impact metrics first, technical metrics in parentheses or a footnote.
• What made it work and what was hard, one paragraph: this is where insight lives, and what you would tell someone starting a similar project.
• Takeaway, one sentence: what this demonstrates about your capability.

When the Evidence Is Incomplete

Two situations derail more case studies than any other. The first is a project that succeeded while nobody measured the baseline. Recovery is possible: reconstruct the prior state from historical reports and system logs, or from colleagues who remember it; use proxy metrics, such as interviewing several users about how long the process used to take when cycle time was never recorded; and document the reconstruction explicitly, in the form "baseline reconstructed from system logs." Transparency about a measurement limitation is far more credible than silence, and the prevention is simply to add baseline measurement to every project launch checklist.

The second is work that has not finished. AI initiatives often run for years, and waiting for completion means the learning evaporates. Write milestone case studies at natural completion points instead, such as the end of a pilot or of phase one, framed explicitly: "this case study covers the pilot phase; the full program continues." Milestone versions capture learning while it is fresh, create early visibility, and usually become the skeleton of the final case study.

Anti-Patterns

• The vague problem statement. Opening with a category ("inefficient processes") rather than a felt, quantified situation. Everything downstream loses its stakes.
• Activity metrics dressed as impact. Reporting how many outputs the system produced with no outcome attached. It reads as evidence and contains none.
• The ownerless narrative. Writing entirely in team voice so a reader cannot tell what you personally did.
• Unqualified success. A write-up with no limitation, no confounder and no edge case, which experienced readers discount on sight.
• Publishing first, asking later. Sharing client outcomes or figures before written approval, which is a contractual problem rather than a stylistic one.

Practice Prompts

• Take a recent project and write only the Complication section, in one paragraph. If you cannot establish why the status quo was insufficient, you do not yet have a case study.
• List every impact claim you would make about that project and sort them into the five levels of the evidence hierarchy. Note which level your strongest claim reaches.
• Draft the pre-writing interview scripts for the sponsor, a frontline user and a skeptic, and send at least one.
• Write the executive abstract before the full narrative, and see whether the impact holds when compressed.
• Identify one limitation of the system you worked with and write the three-part sandwich around it.

Reflection

Consider the last AI initiative you contributed to and ask what record of it survives outside your own memory. If the answer is a slide deck and a spreadsheet, you are in Adaeze's position, and the reconstruction only gets harder as the people who lived through it move on. Ask which of the four purposes matters most to you right now, because a case study written mainly as a hiring signal is shaped differently from one written as an internal knowledge asset. Then consider your own relationship with limitations: if you are reluctant to name where the system fell short, ask whether that reluctance is protecting the work or costing it credibility.

Glossary

• SCQA. A narrative structure of Situation, Complication, Question and Answer, giving a case study tension rather than chronology.
• Evidence hierarchy. The ranking of impact claims from quantified outcomes with baselines down to bare activity metrics.
• Baseline. The measured state of a process before an initiative begins, without which improvement cannot be demonstrated.
• Confounding variable. Something else that changed during the same period and could also explain the result.
• Internal debrief. The unfiltered learning document written for the team, distinct from the curated publishable version.

Related Lessons

This lesson builds directly on Documenting AI Impact, which covers how to establish baselines and capture outcome measurement while a project is running, the discipline that determines whether you will have anything to write about later. It leads into Portfolio Compilation & Presentation, which covers selecting, organizing and presenting a collection of case studies for a specific audience, whether that is a hiring manager, an executive sponsor or a conference committee, and how to build the narrative that ties individual pieces into a coherent career story. The individual case study is the building block; portfolio compilation is the architecture.

Closing

Adaeze's three case studies took longer to write than she expected, and the reason is instructive. The writing was not the slow part. The slow part was reconstructing baselines nobody had recorded, chasing approvals for figures she had treated as hers, and working out which parts of a team engagement were genuinely her contribution. Every one of those difficulties was created months earlier by decisions that felt too small to matter. Practitioners who find case study writing easy set a baseline before launch, noted their own decisions as they made them, and asked about publication rights at the start of an engagement rather than the end.

Key Takeaways

• A case study serves four purposes at once: portfolio artifact, internal knowledge asset, stakeholder communication and hiring signal.
• Every case study needs three elements: a specific problem, an accurate account of your contribution, and verifiable results in business terms.
• Translate technical metrics into business metrics, and lead with the business translation while keeping the technical figure for credibility.
• Rank your evidence: quantified outcomes with baselines are strongest, bare activity metrics weakest and never fit to carry a claim alone.
• Acknowledge confounding variables and name limitations specifically; both increase credibility rather than undermining it.
• A specific human detail, one person and one changed behavior, makes a case study more memorable than any chart.
• Get written approval before sharing externally, and anonymize with percentages, generic organization descriptions and outcome categories when in doubt.
• A portfolio case study should run 600 to 1,000 words; length signals editing discipline, not depth.

Frequently Asked Questions

What if I cannot share any numbers at all? Shift the weight of the case study onto methodology and transferable lessons, and use outcome categories rather than figures. A piece explaining precisely how you approached a problem, what you would do differently, and where the system needed human judgment still demonstrates capability with every metric removed.

How do I write about a project that partly failed? Write it. A milestone or post-mortem case study that explains what did not work and why is often more persuasive than a success story, provided you are specific about the cause and what you changed as a result. Avoid only the version that presents a failure as a success and hopes no one probes.

How many case studies do I need? Fewer than you think, and better than you think. Adaeze settled on three covering different problem types, and a small set of well-built pieces demonstrates more range than a pile of thin summaries. Each one also makes the next faster, because the template and the evidence discipline carry over.