How to Write a Logframe (Step-by-Step)

Writing a logframe appears straightforward — define activities, list outputs, describe outcomes, add indicators. But this is exactly where most NGO projects start to break down.

The issue is not understanding what a logframe is. The issue is how it is built. Most teams follow the correct structure but apply it in the wrong order. They start with activities, adjust outputs later, and define outcomes at the end. By that point, inconsistencies are already embedded:

• Outputs do not clearly lead to outcomes
• Indicators measure delivery instead of change
• Assumptions do not reflect real risks

The logframe looks complete. But when read as a system, it does not hold together. This guide focuses on the sequence and decisions that make a logframe hold together from the first draft — not just what the sections are.

💡

Key insight: Writing a logframe is not a formatting exercise. It is a sequencing problem.

• To understand the framework structure, see the logical framework approach
• To get a format to work with, see the logframe template
• To see what a strong result looks like, see a logframe example

Why Most Logframes Are Built in the Wrong Order

The most common way NGO teams build a logframe is to start with what feels most concrete: activities. The process usually looks like this:

1. Define activities
2. Add outputs based on those activities
3. Adjust outcomes to match the outputs
4. Add indicators at the end

This feels logical because it follows how projects are discussed internally — starting from what will be done. But it reverses the logic of the results chain.

A logframe is designed to move from Change → Results → Actions. The typical workflow moves from Actions → Results → Change. This creates structural problems early:

• Activities drive the design instead of supporting it
• Outputs reflect implementation, not required results
• Outcomes are adjusted later and become vague
• Indicators are added last and often measure what is easy

The structure may appear complete. The logic is already misaligned.

What This Looks Like in Practice

A logframe built this way usually includes all expected sections. But when reviewed as a whole:

• Outputs do not clearly lead to outcomes
• Indicators measure participation instead of change
• The results chain does not hold together

Evaluators are trained to spot this immediately. They do not read logframes line by line — they assess whether the structure makes sense as a whole.

💡

Key insight: Most weak logframes are not incomplete. They are built in the wrong order.

The Correct Sequence for Writing a Logframe

A consistent logframe follows this order:

1. Outcome — define the change
2. Outputs — define what must be delivered for that change to happen
3. Activities — define what produces those outputs
4. Indicators — define how change is measured
5. Means of Verification — define where the data comes from
6. Assumptions — define the external conditions required

This creates a results chain where every output has a clear purpose, every activity contributes to a defined result, and every indicator measures something meaningful.

Step 1 — Define the Outcome

Start with the change. The outcome is not a description of work — it is the specific change the project is accountable for delivering.

The most common mistake: writing outcomes as:

• "Training delivered"
• "Workshops conducted"
• "Awareness increased"

These describe activities or outputs — not change.

What a strong outcome looks like:

The strong version defines: who changes, what changes, and how it can be measured.

💡

Key insight: If the outcome is vague, the entire logframe becomes vague. Everything else follows from this step.

Step 2 — Define Outputs That Lead to the Outcome

Once the outcome is clear, define the outputs — the direct results the project must deliver to make that change happen. Each output should have a direct and necessary contribution to the outcome.

The most common mistake: outputs written as activities:

• "Training sessions conducted"
• "Awareness campaigns delivered"

These describe what is done, not what is achieved.

What strong outputs look like:

For the outcome "300 farmers adopt agroforestry practices":

• Farmers trained and applying techniques
• Demonstration plots established and operational
• Ongoing technical support provided to target farmers

Each output is necessary, measurable, and directly contributes to the outcome.

💡

Key insight: Outputs are not deliverables. They are the conditions required for change to happen.

Step 3 — Define Activities That Produce the Outputs

Activities are defined only after outputs are clear. This step is where many logframes go wrong — by starting here instead of ending here.

Activities are the specific actions required to produce your outputs. Examples:

• Deliver structured training sessions
• Conduct field visits to demonstration sites
• Provide one-on-one technical support

Their role is simple: activities exist to produce outputs — nothing else. Before including an activity, check:

• Does it produce a specific output?
• Is it necessary, or included by habit?
• Can it be linked to a measurable result?

If it does not clearly produce an output, it creates a gap in the structure.

Step 4 — Define Indicators That Measure Real Change

This is where many logframes lose credibility. Indicators are often added last and designed around what is easy to report — not what reflects actual change.

The most common mistake:

• Number of trainings conducted
• Number of participants reached

These measure activity. They do not measure change.

What strong indicators look like:

Strong indicators are specific, measurable, time-bound, and directly linked to the outcome or output they are measuring. See logframe indicators for a full breakdown.

💡

Key insight: Indicators do not strengthen a weak logframe. They reveal where the logic is unclear.

Step 5 — Define Means of Verification

Means of verification specify how each indicator will be measured. They should be specific and credible:

• Field surveys with defined sampling methodology
• Administrative monitoring reports
• Satellite imagery or GIS data

Weak entries like "project reports" or "project data" do not show how measurement will actually happen.

Step 6 — Identify Assumptions

Assumptions identify factors outside your control that the pathway depends on. They must be relevant, realistic, and linked to specific outcomes or outputs — not generic statements.

Weak assumptions:

• "Political stability remains unchanged"
• "Stakeholders remain engaged"

Strong assumptions:

• Farmers have secure land tenure and can invest in multi-year tree planting
• Community participation is sustained through local farmer group structures

A Worked Example: How the Sequence Connects

Here is how the sequence works in practice for an agroforestry project:

Outcome (Step 1): 300 farmers adopt agroforestry practices within 24 months

Outputs (Step 2):

• 300 farmers trained in agroforestry techniques
• 20 demonstration plots established and maintained
• Technical support provided to all target farmers

Activities (Step 3):

• Deliver structured training sessions (produces Output 1)
• Establish and manage demonstration sites (produces Output 2)
• Conduct monthly field visits (produces Output 3)

Indicators (Step 4):

• % of farmers applying techniques after 12 months (outcome)
• Number of farmers trained (output)
• Demonstration plot survival rate at 6 months (output)

Assumptions (Step 6):

• Farmers have access to land suitable for agroforestry
• Participation is sustained through existing farmer group structures

Each step builds on the one before. The logframe becomes a connected system — not a collection of sections.

Why Logframes Require Rework (And How to Avoid It)

Even when the correct sequence is understood, most logframes still require revision. Not because steps are missing — but because alignment breaks as the project evolves.

• Changing an outcome requires revising outputs
• Adjusting outputs affects which activities are needed
• Refining indicators can expose gaps in the logic

This interdependence is why logframes often go through multiple drafts before submission. Most of the time is not spent writing — it is spent fixing misalignment that was introduced early in the process.

The pattern is predictable: activities are defined first, outputs are written to match those activities, outcomes are adjusted later, and indicators are added at the end. By that stage, inconsistencies are already embedded throughout the structure.

💡

Key insight: Rework is not caused by complexity. It is caused by misalignment introduced by starting in the wrong place.

Frequently Asked Questions

What is the correct order for writing a logframe? Start with the outcome, then define outputs, then activities, then indicators, means of verification, and assumptions. Starting with activities reverses the logic and produces structurally weak logframes.

What is the most common mistake when writing a logframe? Confusing outputs with outcomes. An output is something the project delivers — a training programme, a restored area, a published report. An outcome is a change that occurs as a result — farmers adopting new practices, habitat condition improving. Most weak logframes describe delivery at the outcome level.

How long should a logframe take to write? A first draft can take several hours to a few days. The challenge is not the writing — it is the thinking required to align outputs, outcomes, and indicators consistently. Most logframes require multiple iterations before the logic is coherent.

What is the difference between this guide and a logframe template? A template provides the structure — the columns and rows. This guide covers the process — the decisions and sequence that produce a coherent structure. Many NGOs have the template but struggle with the process.

Why do evaluators reject logframes that appear complete? Because structure does not guarantee logic. A logframe can be fully filled in and still fail if outputs do not support the outcome, indicators measure the wrong things, or assumptions are generic. Evaluators assess whether the logic holds together as a system — not whether every box is filled.

Related pages: Logical framework approach · Logframe template · Logframe example · Logframe indicators