> For the complete documentation index, see [llms.txt](https://urd.gitbook.io/compass/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://urd.gitbook.io/compass/learning-and-adapting/learning-from-experience-and-sharing-insights/structured-lessons-learning-processes.md).
# Structured lessons learning processes
### When an experience deserves more than a debrief
A **structured lessons learning process** is what you reach for when an After Action Review isn't enough. The experience spans several teams or phases, involves stakeholders beyond the project team, or is judged significant enough that turning it into a real, transferable piece of knowledge is worth dedicated time.
Unlike the immediate debrief, it doesn't happen spontaneously. It **needs to be planned**: someone decides to do it, defines what it's for, and sees it through to something written down and shared.
***
### **The four steps**
1. Framing
What experience, exactly, are you drawing lessons from? What question is it meant to answer? Who is it for (i.e. the team itself, the wider organisation, partners, the sector)? Skipping this step is the single most common reason these processes drift and never get finished.
2. Collecting
Individual or group interviews, restitution workshops with the teams involved and, where possible, the communities concerned, plus a review of existing documentation (i.e. monitoring data, AAR notes already produced, reports).
3. Analysing
Separate what is specific to this context from what could apply elsewhere. Identify what worked and what didn't, without smoothing over the failures. A process that only focuses on successes most likely misses important learning elements.
4. Formalising and restituting
Produce a short, usable output (see [Documenting and sharing: formats, dissemination and safeguards](/compass/learning-and-adapting/learning-from-experience-and-sharing-insights/documenting-and-sharing-formats-dissemination-and-safeguards.md)), and share it back with the people who contributed before circulating it any further.
> Skipping the framing step to jump straight into collecting information is the most common reason these processes stall. Without a clear question and audience, the exercise expands indefinitely and never reaches step 4.
***
### **Conducting a learning workshop**
**Two versions, depending on time and resources available.**
| Lighter version | Full version |
| ------------------------------------------- | ------------------------------------------------------------------- |
| One half-day workshop with the project team | Several sessions spread over a few weeks |
| Facilitated internally | External or dedicated facilitation, especially for sensitive topics |
| Output could be a 2-page fact sheet | Output could be a case study, guidance note, training material |
| Shared internally | Shared internally and externally (partners, coordination platforms) |
Start with the lighter version by default. Move to the full version only when the framing step has confirmed that the experience genuinely warrants it, not because a bigger process feels more legitimate.
{% file src="/files/EkkSqJ2E9F80fCm5USkt" %}
***
### **How this differs from an evaluation**
A structured lessons learning process doesn't need to be led by someone external, and it **doesn't judge performance against predefined criteria** (such as the OECD-DAC criteria used in evaluations). It starts from the **team's lived experience** and asks what meaning can be drawn from it, descriptively and reflectively rather than judgmentally. It can, however, draw on the data and findings of an existing evaluation as one of its inputs.
***
### **Key points**
* Reserve this method for experiences an AAR can't do justice to, not as the default end-of-project exercise.
* Frame before you collect: without a clear question and audience, the process drifts.
* Default to the lighter version; scale up only when the framing confirms it's warranted.
* Document failures as honestly as successes, that's where most of the transferable value sits.
* It complements evaluation; it doesn't replace it.