> 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/programme-level-learning-across-projects.md).

# Programme level — Learning across projects

**Program-level learning** is not simply a matter of aggregating project data\
It involves identifying patterns, fostering consistency across teams, and collectively managing a portfolio of initiatives. 

This section is intended for program coordinators, Heads of Missions and consortium managers.

***

### <mark style="color:orange;">The regular cycle — Maintaining a cross-functional perspective</mark>

The continuous cycle at the program level draws on what is happening at the project level. By definition, its pace is aligned with that of the projects and is therefore slightly slower. It is designed to enable those responsible for overseeing a portfolio of projects to access real-time information on the status of the projects and to inform their decisions regarding necessary adjustments to the projects. In principle, the continuous cycle should enable managers to understand and defend decisions made at the project level, and to contribute to broader strategic thinking at the portfolio level. For example, if a project decides to adjust the methodology for its monitoring survey because the quality of the data was unsatisfactory, this should prompt the person in charge to examine how monitoring surveys are conducted in other projects and to adjust the approach as well if necessary.

#### **What information actually matters at programme level**

The first challenge of programme-level monitoring is resisting the temptation to aggregate everything. More data does not mean better oversight. A programme-level monitoring system should be designed around a small set of questions that cannot be answered at project level alone:

* Are there patterns across projects — in context changes, in community feedback, in implementation challenges — that signal a need for strategic adjustment?
* Are projects collectively covering the needs of the target population, or are there significant gaps or overlaps?
* Are the assumptions that underpinned the programme strategy still valid?
* Are resources — human, financial, logistical — distributed across projects in a way that reflects current priorities and risks?

These questions require a different kind of information than project-level monitoring produces. They require **synthesis, comparison and interpretation** — not just aggregation.

#### **Building a lightweight programme monitoring system**

A programme monitoring system does not need to be sophisticated to be useful. The most common failure is over-engineering: deploying dashboards and data platforms before the underlying processes and habits are in place.&#x20;

**A shared set of sentinel indicators across projects.** Adapting the sentinel indicator approach to programme level means identifying a small number of warning signs that are relevant across the portfolio — signals that, if observed in multiple projects simultaneously, would indicate a systemic issue rather than a project-specific one. Staff turnover, drop in community participation, repeated delays, or a pattern of similar complaints across sites are examples of programme-level signals. *(See Toolbox — Sentinel indicators in the section* [Project level — Building learning habits into your project](/compass/learning-and-adapting/setting-up-a-learning-oriented-meal-system/project-level-building-learning-habits-into-your-project.md#the-regular-cycle-stepping-back-at-key-milestones)*)*

**A simple portfolio tracking tool.** A shared tracking tool, which can be as simple as a regularly updated spreadsheet, allows programme managers to compare the status of projects against key indicators, flag projects that need attention, and identify where lessons from one project might be relevant to others. The goal is not to monitor every detail but to maintain a helicopter view that complements the ground-level perspective of project teams.

**Regular, structured communication between project teams.** One of the most underused sources of programme-level learning is the knowledge that project teams already hold. A short, structured check-in (monthly or bi-monthly) where project managers share what they are observing, what adaptations they have made, and what questions they are wrestling with can surface learning that no monitoring system would capture. The role of the programme manager in these exchanges is to listen, connect the dots, and facilitate problem-solving, but not to report upward.

#### **The MEAL team as a learning facilitator, not just a data collector**

At programme level, the MEAL function needs to play a different role than at project level. Its primary value is not in collecting and processing data, project teams do that. Its value is in **facilitating the flow of learning across the portfolio**: identifying patterns that individual project teams cannot see, connecting teams facing similar challenges, translating monitoring findings into strategic questions for programme management, and ensuring that adaptations made in one project inform the others.

This requires a MEAL team that is embedded in programme management decisions, not isolated in a reporting function. It also requires programme managers who actively use MEAL insights to steer, not just to comply.

> **Link to CHS Commitment 6** — coordination and complementarity are not only about external actors. At programme level, ensuring that projects complement rather than duplicate each other is a direct expression of this commitment and one that requires active, ongoing monitoring.

#### **Managing information responsibly across the portfolio**

Programme-level monitoring raises specific questions about data responsibility that project-level systems do not always address:

* Who has access to project-level data at programme level, and for what purpose?
* How is sensitive data (community feedback, complaints, protection incidents) handled when it flows upward from project to programme level?
* When projects are implemented by different partners, what data sharing agreements are in place, and do they reflect the principles of data minimisation and informed consent?

These questions are particularly acute in consortium settings, where data governance across organisations adds a layer of complexity.

> **Link to CHS Commitment 4** — communities should know what data is collected about them, by whom, and how it is used. This applies not just at project level but across the full chain of data management up to programme level.

***

### <mark style="color:orange;">**The slow cycle — Drawing lesssons across the portfolio**</mark>

The slow cycle at programme level operates at the rhythm of significant milestones (i.e. the end of a funding phase, a major strategic review, the closure of several projects in the same context, or a significant shift in the operational environment). Its purpose is not to adjust what is currently happening but to **extract durable learning from the experience of the portfolio** and ensure it shapes what comes next.

This is where the raw material accumulated through the regular and intermediate cycles gets processed into knowledge that can travel to the next programme design, to other contexts within the organisation, to partners and coordination structures, and to the communities the programme has been serving.

#### **Learning lessons at programme level**

Learning lessons at programme level goes beyond collecting lessons from individual projects. It involves a deliberate process of **cross-project analysis** — looking at the portfolio as a whole and asking what patterns emerge across projects, contexts and time periods.

This typically involves:

**A cross-project synthesis.** Bringing together the lessons learned from individual projects to identify what holds across the portfolio (i.e. recurring challenges, consistent good practices, adaptations that proved effective in multiple contexts). This is most useful when it is done with the project teams themselves, not just by a MEAL or programme management team working from reports.

**A structured cross-cutting learning workshop.** A workshop at programme level brings together multiple project teams, partners, and (when feasible and relevant) community representatives to collectively analyse projects' respective and collective experience. This workshop is about collective sense-making: what each project brings to the collective knowledge, what is shared among different projects, why it matters for other projects, and how the organisation can adapt its ways of working at the organisational level.

**A good practice documentation process.** When a particular approach, tool or method has proven effective across multiple projects, it is worth documenting it in a format that makes it transferable — not just internally, but to peer organisations and the wider sector. A good practice note is not a success story: it is a careful account of what worked, under what conditions, with what limitations.

***

**Feeding learning back into programme and institutional strategy**

The slow cycle at programme level only has value if it connects upward to institutional decision-making. This means having a clear process for:

* Feeding programme-level lessons into the design of future funding proposals and programme strategies
* Informing organisational policies and operational frameworks — particularly where the programme experience has revealed gaps or inconsistencies
* Contributing to sector-level learning through coordination structures, peer exchanges and published documentation

This connection between programme and institutional learning is one of the most frequently broken links in organisational learning systems. Lessons are produced at programme level and then do not travel. Addressing this requires deliberate investment — not just in documentation, but in the processes and relationships that allow knowledge to flow across levels. *(See* [Institutional level — Building an organisation that learns](/compass/learning-and-adapting/setting-up-a-learning-oriented-meal-system/institutional-level-building-an-organisation-that-learns.md)*)*

***

#### <mark style="color:orange;">**Key points**</mark>

* The slow cycle at programme level transforms accumulated experience into durable, transferable knowledge but only if it is designed around decisions, not deliverables
* Three audiences need different things from programme-level learning: internal teams, communities and local partners, and the wider sector
* Lessons learning at programme level requires cross-project analysis, not just a collection of individual lessons learned
* The connection between programme-level learning and institutional strategy is one of the most frequently broken links, and one of the most important to address
* Responsible data management questions become particularly visible at the point of synthesis and dissemination (*See Cartong Learning Corner - Toolbox on* [*Responsible Data Management*](https://cartong.pages.gitlab.cartong.org/resources-center/en/learning-corner/toolboxes?content=10\&chapter=0\&section=0) *)*&#x20;