Retrospective Gathering¶

Starting From Where You Are¶

Not every student finds Itan at the beginning of their degree.

Some readers will arrive here in their final year, with three years of completed work and no portfolio to show for it. Some will arrive mid-degree, aware that projects from earlier years are slipping out of memory. Some will arrive as professionals — with years of experience that was never documented in portfolio terms. Some will arrive as postgraduate students whose undergraduate work feels distant but whose recent research output has not yet been made publicly accessible.

All of these are recoverable positions.

Retrospective gathering is the practice of working backwards through existing work — identifying what is worth documenting, recovering what can be recovered honestly, and accepting what has been lost without reconstructing it falsely.

It is not as powerful as building a portfolio from the beginning. But it is far more powerful than waiting until the starting position feels perfect — which it rarely does, and which produces portfolios that are perpetually almost ready.

What Can Be Recovered and What Cannot¶

Honesty about what retrospective gathering can and cannot produce is where this process has to begin.

What Can Be Recovered¶

Project outcomes and artefacts
The things that were produced — code repositories, design files, reports, presentations, documentation — still exist. They can be revisited, assessed, and documented. What the project produced is almost always recoverable.

General decision patterns
Even without detailed records, you likely remember the broad shape of significant decisions — why you chose one framework over another, why the design went in a particular direction, what the major constraint was. These general patterns can be documented honestly as "as best I recall" material — which is legitimate, as long as it is presented accurately.

Outcomes and their significance
What the project achieved, what feedback it received, what grade or professional response it generated — these are recoverable and can form part of the entry's evidence base.

Growth across time
The trajectory from earlier to later work is visible even without detailed records. The quality difference between a first-year project and a final-year project is observable without remembering every decision that led to it.

What Cannot Be Recovered¶

Specific decision reasoning in the moment
What you were thinking at the moment a significant decision was made — the exact alternatives you considered, the precise concern that drove the choice — is often genuinely gone. Do not reconstruct it as if it were clear memory.

The honest account of failure
Specific failures, their causes, and what you actually learned from them in the moment are the most vulnerable to memory distortion. People naturally reframe past difficulties in more positive terms over time. A retrospective account of failure is always at risk of being neater, more resolved, and more instructive than it actually was.

The feeling of not knowing
The moment of genuine uncertainty — before a solution was found, before a decision was clear — cannot be recovered. You now know how it turned out. That knowledge shapes how you remember the uncertainty. Retrospective accounts of uncertainty are almost always less honest than real-time records.

Being clear about what cannot be recovered honestly protects the integrity of the entries you do produce.

The Retrospective Process¶

Step Ⅰ — Inventory Everything¶

Before making any selection decisions, gather everything:

◆ all project repositories, whether public or private
◇ all significant assignments and their feedback
◆ all design files, prototypes, or creative outputs
◇ all reports, essays, and research documents
◆ any documentation, meeting notes, or written records from projects
◇ any emails, messages, or feedback threads that captured decisions or outcomes
◆ any photographs, screenshots, or recordings of work in progress

Do not evaluate at this stage. Gather first. The evaluation comes next.

For students who used Vestigia during their final-year project: your Guide A records are the most valuable retrospective resource available to you. They are not retrospective at all — they are real-time. The extraction work in Guide B has already prepared much of what your portfolio entry needs. The task here is placement and framing within the wider portfolio, not reconstruction.

Step Ⅱ — Assess What You Have¶

For each piece of work in your inventory, assess it against the principles from What Belongs in a Portfolio:

◆ Can you explain what problem it was solving?
◇ Can you identify at least one significant decision and explain it specifically?
◆ Can you describe something difficult and what you took from it?
◇ Does it advance your narrative anchor?
◆ Can you defend it in conversation?

Work that passes these questions — even partially — is worth pursuing. Work that fails all of them is archive material and can be set aside.

At this stage, err toward inclusion in the assessment. It costs nothing to assess something and set it aside later. It costs the opportunity of a strong entry if you dismiss work without properly examining it.

Step Ⅲ — Identify the Gaps Between Work and Documentation¶

For work that passes the initial assessment, identify what you can document from memory versus what would require reconstruction.

Be honest about the boundary:

◆ "I remember clearly that we chose PostgreSQL over MongoDB because of the relational data model requirements and the existing team expertise — this is a defensible decision I can speak to specifically."

◇ "I remember that there was a significant debugging problem in week four, but I cannot remember the details clearly enough to document it honestly."

The first is recoverable. The second is not — and should not be fabricated.

Where there are genuine gaps, you have two options:

Document honestly around the gap — present what you can speak to specifically, and acknowledge (to yourself, not necessarily in the entry) that some detail is no longer clear. Write what you know. Do not fill in what you do not.

Use the gap as evidence of what to do differently — a project you engaged with but did not document is a reminder that the next project deserves documentation from the beginning. That lesson is itself worth noting.

Step Ⅳ — Write From What Is Solid¶

Begin each retrospective entry from its most solid ground — the things you can speak to most specifically and most honestly.

For most retrospective entries, this means starting with:

◆ what the project produced — the outcome, the artefact, the deliverable
◇ the most significant decision you remember clearly — not every decision, the one you can still explain specifically
◆ something that was difficult — even at the general level, if specific detail is no longer available
◇ what you would do differently — this is often clearer in retrospect than it was in the moment, and it demonstrates self-awareness

From this foundation, the entry grows outward. Add what you can honestly. Stop where the ground becomes uncertain.

Step Ⅴ — Let the Work Speak Where Words Cannot¶

For retrospective entries where specific decision reasoning is unavailable, the artefacts themselves can carry more weight.

A repository with a coherent commit history tells a story even without accompanying notes. A design file with iteration layers visible tells a story. A report with a well-constructed methodology section demonstrates a capacity for research design even if the in-the-moment decisions cannot be recovered.

Let these artefacts lead where memory cannot — not as substitutes for explanation, but as anchors for the explanation you can provide at a higher level of abstraction.

Retrospective Gathering for Professionals¶

For readers who are not students but professionals building or rebuilding a portfolio from existing career work, the process is the same — with two additional considerations.

Confidentiality — Professional work may be subject to agreements about what can be shown publicly. Before documenting any professional project, confirm what can be shared. Work that cannot be shown can often still be described — at a level of abstraction that communicates the problem, the decisions, and the outcomes without revealing confidential details.

The depth of older work — Work from five or ten years ago may be recoverable at the general level but genuinely too distant to document with the specificity that makes portfolio entries compelling. For very old work, consider whether its primary value is as evidence of longevity rather than as a case study. A brief chronological note — "in 2016 I led the development of X, which resulted in Y" — is more honest than a fabricated case study.

What Retrospective Gathering Cannot Replace¶

Retrospective gathering is a recovery tool. It is not an alternative to building documentation as you work.

The specific detail, the honest-in-the-moment reflection, the decision reasoning captured before the outcome was known — these produce portfolio entries that are qualitatively different from anything retrospective reconstruction can achieve.

If you are currently working on a project — whether in your first year, your final year, or in professional practice — the most useful thing Itan can tell you is this:

Document it now. Not in detail. Not in polished form. Just honestly, in the moment, as the work happens.

The retrospective gathering you will do later will then have material to work with rather than a gap to work around.

Continue to Master Portfolio and Tailored Versions →