What a Case Study Is¶

The Distinction That Changes Everything¶

Open ten student portfolios at random. You will find the same structure in most of them:

A project name. A short paragraph describing what was built. A list of technologies used. A screenshot or two. Sometimes a GitHub link. Sometimes a grade.

These are project descriptions. They are not case studies.

The distinction matters more than it might initially appear, because project descriptions and case studies serve entirely different purposes — and only one of them does what a portfolio actually needs to do.

What a Project Description Does¶

A project description answers the question: what did you make?

It communicates the existence of a piece of work. It names the technology, describes the output, and establishes that the project happened.

This is not without value. A reader who is trying to quickly scan for relevant technical skills, or confirm that you have worked in a particular domain, can extract that information from a project description efficiently.

But a project description cannot answer the questions that actually determine whether someone hires you, collaborates with you, or trusts you with complex work:

How did you think through this problem?
What would you have done differently?
When things went wrong, how did you handle it?
Why this approach and not another?

These questions require a case study.

What a Case Study Does¶

A case study answers the question: how did you think?

It communicates not just what was produced but the reasoning, decisions, difficulties, and learning that shaped the production. It gives the reader access to your professional judgement — the quality of thinking that determines whether you will be able to handle problems they have not yet shown you.

A case study treats a project as evidence of a process, not as an end in itself.

The project is not the point. The thinking behind the project is the point.

The Six Elements That Define a Case Study¶

Not every case study contains all six elements in equal proportion. Different projects, different disciplines, and different stages of development foreground different elements. But a case study that is missing several of these is likely a project description in disguise.

Ⅰ — Context¶

The reader was not there. They do not know your institution, your module, your client, your team, or the constraints you were working under.

Context is the minimum background that makes the rest of the case study intelligible: what the project was for, who it was for, when it happened, what the significant constraints were, and what your role within it was.

Context is not a full background section. It is two to four sentences that orient the reader before the more substantive material begins.

Ⅱ — The Problem or Challenge¶

Every project exists because something needs solving. The quality of a case study depends significantly on how clearly and specifically the problem is articulated.

A weak problem statement: "We needed to build a task management application."

A strong problem statement: "The client — a small logistics firm with twelve staff — was managing task allocation through a shared spreadsheet that was causing version conflicts and missed deadlines. The project required a system that was accessible on both desktop and mobile, with real-time updates and a minimal learning curve for non-technical users."

The second statement tells the reader what made this problem specific — the constraints, the user context, the competing requirements. It sets up everything that follows, because every subsequent decision can be evaluated against the stated problem.

Ⅲ — Your Decisions and the Reasoning Behind Them¶

This is the intellectual core of any case study. It is also what most project descriptions omit entirely.

Decisions worth documenting in a case study are those where:

◆ alternatives genuinely existed and were considered
◇ the choice carried a trade-off or an accepted risk
◆ the outcome of the project is different because of how you decided
◇ a reader might reasonably ask: why did you do it this way?

For each significant decision, the case study should communicate:

• what was decided
• what the alternative or alternatives were
• why this path was chosen
• what was accepted as a consequence

You do not need to document every decision. You need to document the ones that shaped the project most significantly — usually two to four, depending on the project's scope and complexity.

Ⅳ — What Was Difficult¶

Difficulty is not something to hide. In a case study, it is evidence.

A case study that describes a project with no significant difficulty, no problems, no moments of uncertainty, reads as either a very simple project or an account that has been sanitised. Experienced readers assume the latter.

What made the project difficult? What did not work the way you expected? What required you to rethink, redesign, or revise? What constraint forced a better solution than the one you would have reached without it?

Difficulty documented honestly — specifically, with an account of how it was handled — demonstrates professional resilience and genuine engagement with the problem. These are qualities that cannot be claimed directly. They can only be demonstrated through evidence of how you behaved when things were hard.

Ⅴ — The Outcome and What It Demonstrates¶

What did the project produce? What is there to point to — a deployed system, a completed design, a research finding, a published report, a delivered intervention?

The outcome section of a case study does two things:

It grounds the case study in verifiable reality. Linking to a repository, a live system, a design file, or a published document gives the reader something to check. This is not required, but it adds credibility that description alone cannot provide.

It connects the outcome to the problem stated at the beginning. Did the project solve the problem? Partially? Differently than anticipated? The most honest outcome sections acknowledge the gap between what was intended and what was achieved, where a gap exists.

Ⅵ — What Changed in Your Thinking¶

This is the reflection element — and it is what most clearly distinguishes a case study from a project report.

A project report documents what happened. A case study documents what it means — what you understand now that you did not understand before, what you would do differently with the knowledge the project produced, what the experience changed in how you approach this type of problem.

Reflection is not:

◆ "I learned a lot from this project."
◇ "This project taught me the importance of teamwork."
◆ "I improved my technical skills significantly."

Reflection is:

◆ "I assumed that OAuth integration would synchronise token lifecycle across clients automatically. It does not — each client surface requires explicit lifecycle management. I now account for this in the first week of any authentication design, not after it surfaces as a problem."

◇ "My initial problem framing focused on usability. User research revealed that usability was not the barrier to conversion — perceived value was. That distinction now shapes how I approach discovery research: I do not assume I know the problem category before testing the assumption."

Specific reflection is credible. Generic reflection is not.

What a Case Study Is Not¶

A project report
Project reports are written for markers, against criteria, in a structure prescribed by the subject. Case studies are written for professional readers, against the question of capability, in a structure determined by what best serves the story.

A tutorial or how-to guide
A case study is not a walkthrough of how the project was built. It is an account of the thinking behind how it was built. Technical readers who want the implementation details can follow the link to the repository.

A success story
A case study that only describes what went well is not honest and is not interesting. Professional readers are not looking for evidence that you can succeed under ideal conditions. They are looking for evidence that you can think under real ones.

A retrospective without a position
A case study is not a neutral description of events. It takes a position — on what mattered, what was learned, what would be done differently. Neutrality in a case study is a missed opportunity. The position you take is evidence of judgement.

Length and Depth¶

There is no correct length for a case study. There is a correct depth.

A case study is long enough to answer the six elements above with specificity and honesty. It is short enough that a professional reader can engage with it fully in a single sitting.

In practice, strong portfolio case studies tend to run between 400 and 900 words — sometimes accompanied by visuals, links, or supporting material that extends the entry without extending the prose.

A case study shorter than 300 words is almost certainly a project description. A case study longer than 1200 words has almost certainly included material that belongs in an appendix or a linked document rather than in the case study itself.

These are not rules. They are calibrations based on what serves the reader at the depth a portfolio case study requires.

The Relationship Between Case Studies and Source Material¶

The quality of a case study is directly shaped by the quality of the source material available when writing it.

Students who documented their project in real time — keeping records of decisions, problems, and reflection as the work happened — have specific, honest material to draw from. Their case studies can reach depths that retrospective reconstruction rarely achieves.

Students who are reconstructing from memory are working with a less complete and less reliable source. They can still write strong case studies, but they will encounter the limits described in Part Ⅲ — Retrospective Gathering.

For final-year students who used Vestigia: your Guide A records are the primary source material for your capstone case study. Your Guide B extraction and narrative work is the case study in draft form. What Part Ⅳ provides is the structure and the standard to complete it to.