Assumptions

What Are Assumptions?

Assumptions are conditions, circumstances, or events outside the program's direct control that must remain true for the program's results chain to work as intended. If assumptions fail, the program may not achieve its goals even if it implements perfectly. Assumptions are different from inputs and activities; they're not something the program provides, but rather background conditions that must exist. In logframes, assumptions typically appear in a column beside the results chain showing which assumptions support the link between each level (from inputs to activities to outputs to outcomes).

Why It Matters

Making assumptions explicit is powerful because it forces you to think beyond your control. A health education program might assume that beneficiaries have access to the health services being promoted; if that assumption fails (clinics are too far away, too expensive), promoting those services is pointless. An agriculture program assumes beneficiaries have land to farm; in contexts of land insecurity, that assumption may not hold. By naming assumptions upfront, you can: (1) monitor whether they remain true, (2) design program activities to address critical assumptions that might fail, and (3) decide if the context is appropriate for your approach. Ignoring assumptions is risky; programs often fail not because of poor implementation but because core assumptions didn't hold.

In Practice

When developing a logframe, you work through each level and ask: "For this to happen, what must be true?" For example: "If we train health workers and they return to their communities, what must be true for them to actually use their training?" Assumptions might include: "health workers are valued in their communities," "they have time to use new practices," or "they won't be pressured to use only cheap treatments." You then identify which assumptions are critical (meaning if they fail, the whole program fails) and design monitoring around those. Some programs actively address assumptions. If the assumption is "beneficiaries can afford the improved practice," the program might include a component addressing affordability. Others simply monitor and adapt if assumptions prove false.

Assumptions Versus Risks

A risk is something that might go wrong in how the program or its M&E work is run, or in its setting, such as a tablet failing or an enumerator (a person who collects survey data) quitting. An assumption is something the program is counting on being true for its theory of change to work, such as caregivers attending sessions voluntarily. The two need different responses. Risks are reduced with operational controls. Assumptions are tested with monitoring data, and a failed one means revisiting the theory of change and possibly the program design.

Assumptions need extra attention because they are often invisible. They are written in during design, treated as self-evident and never reviewed again, while the context changes.

Test the Obvious Assumptions

The assumption that sounds most obvious is the one least likely to be tested. Healthy Futures, a fictional child nutrition program in Kasenda District, assumed that caregivers would attend its education sessions voluntarily.

Before (assumption left alone): "Attendance is 88%. Everything looks fine."

After (assumption tested): "Overall attendance is 88%, but when the data is split by zone (disaggregated), 35% of caregivers in Zone C attended at most one session. The assumption holds for willing participants and fails for the hardest-to-reach households. We are adding home visits to learn why, and we recorded the finding in our assumption tracker."

The average hid the gap. Splitting monitoring data by group is often the quickest way to see whether an assumption holds for everyone.