The Logical Framework Approach

1
The Logical Framework Approach

• Chris Lyal
• The Natural History Museum

2
What is the Logical Framework approach?

• A set of open-ended management tools
• Practiced differently by different organizations,
  although principles the same
• Flexible and can be updated

3
Why should we use logframes?

• Donors require it
• bilateral agencies such as
• USAID, CIDA, GTZ, DFID, DANIDA, SIDA,
• multilateral agencies such as
• EU, UNDP, UNEP, GEF, FAO, ADB
• And, of course, the DARWIN INITIATIVE

4
Why should we use logframes?

• They help to
• organise your thinking
• relate activities to expected results
• set performance indicators
• allocate responsibilities
• communicate project information concisely

5
The Project Cycle
Objectives Country / donor requirements
Identification
Stakeholder analysis Problem tree Risk
analysis Logical framework ToR Project Format
Evaluation
Design / appraisal
lessons
Completion
Reporting
Implementation
Reporting, Monitoring
6
Project design

• Analysis Phase
• Stakeholder analysis
• Problem tree
• Risk analysis
• Planning Phase
• Logical Framework
• Terms of reference
• Project format

7
Stakeholders

• People affected by the impact of an activity
• People who can influence the impact

8
Stakeholders

• user groups - people who use the resources or
  area
• interest groups - have an interest or opinion or
  who can affect the use of a resource or area
• winners and losers
• beneficiaries
• intermediaries
• those involved in or excluded from the
  decision-making process

9
Stakeholders

• Primary stakeholders
• benefit from or are adversely affected by
  activity. Usually wholly dependent on resource
  or area for survival. Few options when faced
  with change.
• Secondary stakeholders
• all other people and institutions with a stake or
  interest or intermediary role in resource or area.

10
Stakeholder analysis

• Construct stakeholder table
• list all stakeholders
• list their interests (hidden or open) in relation
  to project
• make preliminary assessment of likely impact of
  project on each stakeholders interests (, -,
  /-, ?)
• indicate relative priority which project should
  give to each stakeholder in meeting their
  interest (e.g. 1-5 with 1 as highest)

11
Stakeholder analysis table
Importance
Influence
12
Stakeholder analysis table
13
Levels of participation

• 1. Action FOR - being informed or set tasks.
  Others set the agenda and direct the process.
• 2. Action FOR/WITH - being consulted others
  analyse and decide course of action

• 3. Action WITH - partnership work with others to
  set priorities and course of action.
• 4. Action BY - control little or no input by
  others.

14
Participation matrix
15
Risk Assessment

• Potential for unwanted happenings or consequences
• Can result in project failure
• Risk assessment and management must be built into
  project design

16
Risk Assessment

• Identification What are the risks?
• Estimation What is their likely probability?
• Evaluation What is their likely impact?

17
Risks
18
Risks
19
Risk analysis table
20
Risk analysis table
21
Risk Management

• Planning
• Monitoring
• Resourcing
• Controlling
• What measures can be put into place?

22
Problem Analysis

• To crystallise the overall issue addressed into
  individual problems
• Negative aspects of situation analyzed
• Causal relationships established
• Information gathered through stakeholder
  consultation etc etc

23
Problem Analysis

• Identify key problems
• Select starter problem and place centrally
• problems directly causing starter problem placed
  below it
• problems which are direct effects of starter
  problem are placed above it
• problems that are neither a cause or effect are
  placed at the same level

24
The Problem Tree
Effect
Effect
Effect
Effect
Effect
Effect
Starting problem
Causal problem
Causal problem
Causal problem
Causal problem
Causal problem
Causal problem
Causal problem
25
(No Transcript)
26
The Logical Framework
27
Goal

• Higher-order objective
• Programme or sector
• Outside control of project team
• May require several projects

28
Purpose

• Why the project is being done
• Summarises expected impact of project
• How user will benefit
• Often described change of behaviour
• e.g. New method used / New system implemented
• One purpose per project
• Outside control of project team

29
Outputs

• Describe what the project is to deliver
  (measurable end results)
• Should be necessary and sufficient for the
  Puropse to be met
• Likely to be more than one
• Often described in Terms of Reference
• If resources provided, project team can be held
  responsible for Output delivery
• (might include management objective Project
  management system installed and operational)

30
Activities

• Define how team will carry out project
• Should be necessary and sufficient for the
  Outputs to be achieved
• Provide brief summary of 3-7 activities for each
  output
• Supply enough detail to outline strategy
• Include management activities

31
Vertical Logic the If/Then test

• Structure is based on cause and effect
• If something is achieved, then something else
  will result
• So, if certain Activities are carried out, then
  one can expect certain Outputs
• Same relationship between Output and Purpose, and
  Purpose and Goal

32
Narrative summary checklist

• Do they answer
• goal Greater why?
• Purpose Why?
• Outputs What?
• Activities How?
• Does the vertical logic work?
• Then
• If
• Is it necessary and sufficient?

• Where are the boundaries of the project?
• Is there only one purpose?
• Is the purpose too remote from the outputs?
• Is the purpose assessable?
• Are there process as well as product
  objectives?
• Are Outputs and Activities linked /
  cross-numbered?

33
Assumptions

• May be clear logical link between statements in
  Narrative Summary column
• Possibility that other factors may break links
• Assumptions are statements about the uncertainty
  factors
• external factors you cannot control
• factors you choose not to control

34
Risks and Assumptions

• Have all the risks been identified?
• Stakeholder analysis?
• Problem trees?
• Are the risks specific? Or too generalised?
• Are the risks/assumptions at the right level?
• Does the diagonal logic between columns 1 4
  work?
• Then
• If And

• Is the logic necessary and sufficient?
• Where risks are manageable, have they been
  managed?
• Where possible, have they been turned into
  Activities and Outputs?
• (i.e. moved to Column 1)
• What are the pre-conditions?
• Should the project proceed in view of the
  remaining assumptions/risks?

35
Objectively Verifiable Indicators

• If you can measure it, you can manage it
• Demonstrate results
• Tell us how to recognise accomplishment of
  objectives
• No cause and effect relationship
• Define in measurable detail the performance
  levels required by objectives in Narrative
  Summary column

36
OVIs

• Begin at Goal, then purpose, then outputs, then
  activities
• State Indicators in terms of Quantity, Quality,
  Time
• e.g. 4 staff trained to PhD level by year 5
• Use only as many indicators as necessary

37
Goal Level Indicators

• May include targets beyond scope of project

38
Purpose level Indicators

• Gaining clarity at this level helps setting
  Output Indicators
• Try to set Purpose OVI to be motivating
• Cost/effectiveness assessment will compare the
  Purpose level OVI to cost

39
Output Level Indicators

• Establish terms of reference for project
• Indicate deliverables for which project team is
  accountable

40
Activity Level Indicators

• Often Inputs (resources) or Budgets

41
Means of verification

• Sources of information to demonstrate what has
  been accomplished
• May lead to additions to Activities (e.g. survey)
• Indicators chosen must be verifiable

42
Indicators and Verification Checklist

• Are the Indicators QQTed?
• Are the Indicators and Means of Verification
• Relevant
• Valid
• Reliable
• Measurable / Verifiable
• Cost-effective
• Are the Indicators necessary and sufficient?
• Who has set the indicators? How will they be
  owned?

• Are the Indicators varied enough?
• Product and process
• Direct and indirect
• Qualitative and quantitative
• Cross-sectoral
• Are the data collection / means of verification
• already available?
• Set up where necessary within the project?
• Is there a need for baseline measurement?

43
Summary

• The logical framework approach depends on
• clarity
• honesty
• recognition of all salient factors
• flexibilty
• rigour

44
Further reading

• Inter-American Development Bank The Logical
  Framework Approach (LFA) A Structured Approach
  to Project Planning.
• http//www.iadb.org/exr/english/policies/participa
  te/sec7.htm
• Bill Jackson Designing Projects and Project
  Evaluations Using The Logical Framework Approach
• http//www.iucn.org/themes/eval/english/lfa.htm
• UNDP-GEF Introduction to the Logical Framework
  Approach
• http//www.undp.org/gef/me/main.htm