> 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/setting-up-a-learning-oriented-meal-system/project-level-building-learning-habits-into-your-project.md). # Project level — Building learning habits into your project Learning at project level is not about adding extra activities to an already full workload. It is about **building simple, repeatable habits** into the way a project is already managed — so that what you observe, hear and learn actually informs decisions, rather than disappearing into reports that no one reads. The sections below follow the three improvement cycles introduced in the chapter overview, and show what each one looks like in practice at project level. *** ### **The continuous monitoring cycle — Staying connected to reality** The regular cycle is the frontline of adaptation. It operates at the pace of day-to-day project management and does not require dedicated resources or external expertise. It requires **intentional habits**. In practice, this means: **Listening systematically to communities.** Feedback from communities — whether through formal mechanisms or informal daily interactions — is one of the most valuable sources of learning available to a project team. > **CHS Commitment 5 is clear**: complaints and feedback are not just a compliance requirement, they are a signal. A pattern of similar complaints, a drop in participation, a rumour circulating in the community — these are all early warning signs that something needs to change. The key is having a simple mechanism to capture these signals, and a habit of actually discussing them (i.e. in weekly team meetings, monthly project reviews...) **Monitoring what matters, not just what is easy.** Too often, teams focus on tracking activities and inputs because they are easier to measure than actual changes for communities. A learning-oriented monitoring system tracks context, processes, changes and target groups together — not just delivery numbers. When monitoring data is discussed regularly as a team, it becomes a steering tool rather than a reporting obligation. *(See Toolbox - Context monitoring - coming soon)* **Monitor weak signals of change, not just actions.** Changes are generally observable only after they have occurred, and this work is typically focused on toward the end of projects. However, during the implementation phase, it is possible to gather many weak signals of changes that are underway or have already occurred. A weak signal is any piece of information that indicates a change process has been initiated. These can take many different forms and often rely on informal sources (feedback, email, quotes, discussions, observations). Continuous monitoring generally requires only a limited investment of time from teams. During structured reviews (see regular cycle below), teams can discuss the various signals gathered and interpret the collected information to support learning and adaptation of the project. *(See Toolbox - Weak signal monitoring - coming soon)* **Using sentinel indicators as early warning signals.** Sentinel indicators are a lightweight tool for detecting warning signs before they become critical — a sudden drop in attendance, community tensions, staff turnover, repeated delays. They do not replace regular monitoring but complement it by keeping attention on the signals that matter most in a given context. *(See the Sentinel indicators tool below and the other resources in the Toolbox -* [Learning](/compass/documentation/learning.md)*)* {% file src="/files/umeqfiWb6v2Fe2tskIMr" %} {% file src="/files/JxvgOB99NCItYDfG7aCu" %} **Proactively seek for community feedback.** Traditional complaints and feedback systems are sometimes ineffective in capturing qualitative feedback from communities on project's implementation, especially in complex and volatile environments. In such conditions, it could be relevant to design a structured framework for regular communication with project stakeholders, in order to better understand their needs, assess the quality of the measures implemented, and prevent potential frustrations. This method was tested the RESILAC 2 project in Lake Chad region under the activity "Feedback days". It is based on four main objectives : * Regularly engage stakeholders and enable them to play an active role in providing feedback and influencing project decisions * Ensure open, two-way dialogue between communities and RESILAC to promote transparency in the aid delivery process * Analyze and share results, and ensure that the feedback loop is effectively closed in a timely manner * Adjust the response as needed to better meet the needs of the target communities *(See Toolbox - Feedback Days - coming soon)* **Documenting decisions, not just activities.** One of the simplest and most underused learning habits is keeping a brief record of why decisions were made — particularly when adapting the project. When a team changes its approach, adjusts targeting, or modifies an activity, documenting the reasoning takes five minutes and creates an invaluable resource for the next review, the next project, or the next team member who takes over. This involves, in particular, the structured archiving of meeting minutes from the meetings during which decisions were made, and the tracking of recommendations using a management tool managed by the project manager. *(See Toolbox - PM box - coming soon)* > **Link to CHS Commitment 7** — *"Organisations use feedback and data from monitoring to guide decisions on project adaptations."* The regular cycle is how this commitment becomes a daily practice rather than an end-of-project exercise. *** ### The regular cycle - Stepping back at key milestones At project level, the regular cycle operates at specific moments such as monthly or quarterly reviews, mid-term assessments, or structured reflection moments with partners and communities. Its purpose is to step back from daily operations and ask the harder questions: **Is the project still on track? Do our initial assumptions still hold? Are there patterns in what we are observing that require a more significant adjustment?** This is where the raw material generated by the continuous monitoring cycle gets analysed and turned into decisions. **Organising a structured review.** A structured review does not need to be a formal evaluation. It can be a one or two-hour team session with a clear agenda, focused on four questions: * What have we observed since the last review? *(monitoring data, community feedback, context changes, weak signals)* * What does this tell us about whether the project is still on track? * What decisions do we need to make? * What do we need to communicate — to communities, to partners, to our organisation? **Involving communities and partners.** Structured reviews are most useful when they include perspectives beyond the project team. Communities can confirm or challenge what monitoring data is showing. Partners can flag gaps and overlaps that are invisible from within a single project. The CHS is explicit on this: adaptation should be informed by the people the project is meant to serve, not just by internal analysis. To this end, it is recommended that structured meetings be held with key stakeholders so that they can have access to the information gathered and the conclusions drawn, and participate in discussions regarding any necessary adjustments.

The Feedback Loop - Source : Groupe URD

**Using the Project Health Check.** The Project Health Check is a rapid self-assessment tool organised around the nine CHS commitments. It can be used at the start of a structured review to identify which areas of quality and accountability need attention, and focus the discussion where it matters most. *(See Toolbox — Project Health Check - coming soon)* **Managing projects in volatile contexts.** In rapidly changing environments, intermediate reviews need to be supported by scenario planning — anticipating how the context might evolve and what adaptations would be needed under different scenarios. This is not about predicting the future but about being prepared to act quickly when the situation changes. *(See Toolbox — Scenario planning and monitoring* [Adaptive management](/compass/documentation/adaptive-management.md#scenario-planning)*)* *** ### **The slow cycle — Learning that shapes the next project** The slow cycle operates at the end of a project, or at significant organisational milestones. Its purpose is not to adapt the current project — it is to ensure that what was learned **shapes the next one**. At project level, the slow cycle typically takes the form of a lessons learned exercise or workshop. The goal is to move beyond a list of recommendations that no one will read, and produce **genuinely usable knowledge** — by the next project team, by partners, by the wider organisation. **What makes a lessons learned exercise useful.** The most common failure of lessons learned processes is that they are done too late, too quickly, and without the right people in the room. A useful lessons learned exercise: * Happens while people still remember what happened and why * Involves communities and partners, not just project staff * Focuses on understanding *why* things worked or did not work, not just *what* happened * Produces outputs that are accessible and actionable — not a 40-page report **Connecting to the next programme design.** The slow cycle only has value if the lessons it produces are actually used. This means having a clear process for feeding lessons learned into the design of future projects — and a habit of checking, at the start of any new project, what previous experience in the same context or sector has to say. *(See* [Learning from experience and sharing insights](/compass/learning-and-adapting/learning-from-experience-and-sharing-insights.md)*)* > **Link to CHS Commitment 7** — *"Organisations systematically use lessons from previous experience to inform programme design."* The slow cycle is how institutional memory is built and how the sector, collectively, improves. *** ### **Quality and accountability control points** The COMPASS identifies two specific control points during project implementation that are directly relevant to learning and adaptation: **Checklist 6 — Project information needs**: Are we collecting the right information, at the right frequency, to be able to make informed decisions? Are communities involved in data collection? Are we tracking not just activities but also context changes, participation, and feedback patterns? **Checklist 7 — Project decision-making**: Are we actually using the information we collect to make decisions? Are those decisions documented and communicated? Are we informing communities about changes to the project and why they were made? These two checklists can be used as the basis for any structured review at project level. *(See Toolbox — Checklists 6 and 7* [Implementation and Monitoring](/compass/implementing/implementation-and-monitoring.md#checklist)*)* *** ### **Key points** * Learning at project level is built on three cycles operating at different speeds : daily habits, periodic reviews, and end-of-project capitalisation * The continuous monitoring cycle is the most accessible entry point for under-resourced teams : it costs little and has the highest impact on day-to-day relevance * Community feedback and complaints are a direct source of learning and should be systematically connected to adaptation decisions, with particular attention to closing the feedback loop * Documenting decisions, not just activities, is one of the simplest and most underused learning habits * The slow cycle only has value if lessons are actually used in the next project design