> 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/choosing-the-right-method-at-the-right-time.md). # Choosing the right method at the right time It is often assumed that knowledge capture occurs only at the end of a project, to document the lessons learned from that project. Once documented, these lessons are generally recorded in a report and properly archived. That’s fine, but it is not very useful. To avoid this common pitfall, it is important to understand that **lessons learning is a range of methods that should be tailored to the specific learning cycle** (see [Setting up a learning-oriented MEAL system](/compass/learning-and-adapting/setting-up-a-learning-oriented-meal-system.md)).
CycleTypical TriggerMethodInvestment
ContinuousEnd of an activity, a short assignment, or an incidentImmediate debrief / After-Action ReviewLow — 30 to 60 min
RegularEnd of a phase in the project cycle; quarterly reviewCollective review of lessons learnedModerate — half a day
SlowProject/program completion; experience deemed highly valuable; cross-functional topicStructured capitalization processMost important — several days, spread out over time
*** ### How to select the most appropriate method for capturing lessons? Example of simple decision tree to select the right method:
Is the experience still fresh and localized (one team, one event)? → **An immediate debrief is enough.** See [After Action Reviews: light, frequent debriefs](/compass/learning-and-adapting/learning-from-experience-and-sharing-insights/after-action-reviews-light-frequent-debriefs.md).
Does the experience involve several teams, phases or stakeholders, and is it worth formalising for future use? The experience matters beyond the moment it happened, and a written record would genuinely change how the next phase is approached. → **Plan a structured learning process.** See [Structured lessons learning processes](/compass/learning-and-adapting/learning-from-experience-and-sharing-insights/structured-lessons-learning-processes.md).
Does the knowledge generated extend beyond the scope of the project itself (useful to other projects, other organisations or the sector as a whole)? → **Design the output for dissemination from the start**, not as an afterthought. 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).
These questions are not mutually exclusive. An immediate debrief can later feed into a structured learning process; a structured process can produce something worth sharing externally. The point is to decide **at the outset** what level of effort the experience actually warrants, rather than defaulting to whatever format is most familiar. *** ### What tends to go wrong: common pitfalls to avoid **Waiting for "enough" to capitalise** Teams often postpone reflection, assuming there will be a better moment once the project is further along or finished. In practice, the details fade fast: a debrief held two weeks after the fact is already noticeably less precise than one held the same day. **Reaching for a workshop by default** A structured learning process demands facilitation time, participants' availability, and a clear question to investigate. Used for something a 45-minute debrief could have captured just as well, it consumes resources that would have been better spent capitalising more often, on more things. As explained in the section about [Learning and adapting](/compass/learning-and-adapting/learning-and-adapting.md): do not apply the most resource-intensive method by default. A poorly scaled structured review does more harm than good. A regular and honest debrief is better than an ambitious review that is never completed or used. **Under-resourcing what deserves more** The opposite failure also happens: a genuinely significant experience (i.e. a major course correction, a serious incident, an approach that could reshape how future projects are designed) gets reduced to a bullet point in a routine report because no one paused to recognise its weight. **Choosing the method before naming the audience** A lesson intended only for the project team can stay informal. A lesson intended for a donor, a partner, or the wider sector needs a method that produces something shareable from the outset. Retrofitting a private debrief note into a public-facing document rarely works well. > #### A quick tip to help you get started > > Start with a single, simple and regular practice: set aside 15 minutes at the end of each weekly team meeting to note down *“What have we learnt this week that the next team should know?”*, and record this in a single shared document. It may not seem like much, but it forms the foundation upon which a more structured knowledge-sharing process can be built later on. *** ### Key points * Lessons learning is a spectrum of methods, not one exercise reserved for the end of a project. * Match the method to the learning cycle it belongs to: continuous, regular, or slow. * Ask who the lesson is for before choosing how to capture it. * A method that never gets finished is worse than a lighter one that actually gets used. * For organisations starting from scratch, one recurring 15-minute habit is more valuable than an ambitious method never attempted.