TIPS FOR LOGIC MODELS AND RESULTS FRAMEWORKS
Logic models1 and results frameworks (such as the logical framework) contain a series of
“results statements” - short descriptions of outcomes etc. - that projects, programmes or
organisations expect to achieve or contribute to. These models and frameworks
 Always include one or more levels of outcome
 Usually include an impact, goal or ultimate outcome
 Will include activities2 and outputs if they represent projects; but often not if they
represent organisations or long-term programmes.
The results statements are arranged in logical, sequential, relationships with one another.
 Results at one level (e.g. short-term outcomes) are expected to happen before those
at the next level (e.g. intermediate outcomes) - and to be necessary conditions for
them to happen.
In logic models, the results are presented two-dimensionally - horizontally and vertically
(see Figure 1).
Figure 1 Logic model
In a results framework, they are presented vertically (see Figure 2). This makes room for
further columns of information. The results column is often called the narrative summary.
Figure 2 Results framework
Results
1
Indicators
MoVs
Assumptions
Logic models are sometimes described as Theories of Change (ToCs). ToCs however – expressed either as
narrative or diagrammatically - often have wider scope than logic models and include for example the
problems that need to be addressed and a wider range of assumptions and other external factors. They are
also not always presented in a linear fashion, and may include feedback loops or be presented as systems.
2
Activities, and in some jurisdictions outputs, are not classified as “results”.
Logic models are more visual and generally easier to comprehend than results frameworks,
but they contain less information. Results frameworks contain indicators and means of
verification (data sources and data instruments), and often also baseline and target values
for the indicators (in which case they are usually called performance frameworks because
they define particular performance standards). Both logic models and results frameworks
should contain information on assumptions or risks relating to the achievement of results at
the different levels.
Tips for results statements
1. The results should be important – they should represent resolutions of significant
problems or take-up of significant opportunities.
 A sequence of situation, problem and objectives analyses is often used to
identify important results.
2. The results should be legitimate and appropriate for your organisation to pursue,
bearing in mind its mandate, experience and expertise.
 Strategy analysis often follows situation, problem and objectives analyses to
identify the particular results that your organisation should focus on.
3. Results should be expressed as results not activities, describing the expected change
or completed product or service.
 “To promote more accountability in government” → “Government more
accountable”. ”Training for accountants” → “Accountants trained”
4. They should clearly identify the people or organisation(s) that will be involved in the
change or will receive/experience the product or service.
 Avoid imprecise terms like “stakeholders” and “partners”.
5. The results should be evaluable – capable of being verified. This is usually assured by
the combination of points 3 and 4 above.
 Results statements do not however have to be directly measurable, unlike
indicators.
6. Don’t blur the line between outputs and outcomes. Outputs are what the project
itself can deliver. Outcomes are what happens as a result of a combination of what
the project delivers and external factors and conditions.
7. Results statements should be as simple as possible. Ideally there should be only one
dimension.
 The following multi-dimensional statement should probably be split into two
or even three statements “Increased accountability, transparency, and civil
society participation in decision making in local government”.
8. If there are two or more elements, they should be achievable at a similar stage of
the project or its aftermath and should not be sequential.
 Avoid statements that contain phrases like “X leading to Y”; or “Y as a result
of X”. This creates ambiguity about what the evaluable result is.
Tips for logic models or narrative summaries
1. The different levels of results should be logical and represent a clear progression.
Results at the lower level should logically happen before the higher level and
contribute to it. (See Figure 3.)
 A higher level result should be more than the sum of the results at the lower
level – it should also represent a change which builds on, and takes forward
the lower level results.
2. Progression between the levels should be plausible. Results at one level – together
with the stated assumptions – should make a convincing case for the related result
at the higher level to happen.
 If the progression from the results at one level to the next “stretches the
imagination” it may mean that you have too few levels in your model. You
may need to insert another level of outcomes. Alternatively, it may mean
that your project has unrealistic higher outcomes and you should be more
modest in you ambition, choosing outcomes at every level that you can
plausibly make some contribution to.
3. The necessary outputs should be achievable by the project, programme, etc. in the
timeframe, given the inputs (resources, expertise, partnerships, etc.) and what is
known about the operating environment.
4. Logic models, as well as performance frameworks, should ideally include key
assumptions.
Tips for assumptions
1. Assumptions can be expressed as risks if this seems more logical to you.
2. Assumptions should be beyond the direct control of your intervention.
 If they are within your field of control – such as having an adequate budget or
set of competencies in the project team - they are likely to be pre-conditions
that you need to fix or have strategies for fixing before the intervention
starts.
3. Only include significant assumptions or risks – those you need to monitor and have
contingency plans for.
 On the other hand, if you identify “killer” risks - those that are likely to
happen and which will seriously reduce your chance of success if they do you need to take your project back to the drawing board.
Tips for indicators and means of verification
1. Indicators should have a clear and precise “unit of measurement”.
 For example: % of smallholder clients of project-supported financial service
providers who perceive that new products or practices effectively meet their
financial needs
2. Indicators should represent the core characteristic(s) of the result in question and be
at the same level in the results chain.
 For example, if the result is about changed behaviour, the indicator should
not be about attitudes or intentions.
3. An indicator needs to be linked to a pre-identified data source, and a defined
instrument for collecting the data. The data need to be accessible and reliable, and
data collection needs to be timely and affordable.
4. Gender and other relevant categories of disaggregated data should be available
where needed.
5. Indicators usually need targets. But try to avoid defining targets until you have
enough of an insight to define them realistically.
 Targets often depend on the prior identification of baselines.
Patrick Spaven
October 2014