THE PROJECT LOGICAL FRAMEWORK: TECHNIQUES AND ISSUES

The use of the Logframe in the design of public projects

The European Commission adopted the Project Cycle Management (PCM) approach in 1992
as a framework to manage the projects financed under the European Development Fund
(EDF). This approach was subsequently used in other cooperation frameworks (like TACIS,
PHARE, MEDA) and is presently used in a generalised manner.

PCM brings associated with it the Project Logical Framework (or logframe), a technique that is
particularly adequate to design any kind of public intervention whatever its degree of
complexity (from small projects to large programmes), its nature (tangible or intangible) and
scope (sectoral, regional, local). In many cases, the financing proposals submitted to the
European Commission are only approved after being endorsed by the Quality Support Group,
which assesses the quality of the project proposals using the logframe methodology.

The use of this method assumes a good knowledge of the context in which the project is
designed and implemented. It is important that those involved in the elaboration of a project
are well aware of the policy objectives of the sector or region in which context the project is
to be implemented. It is also recommended that they be aware of the technical aspects
involving the use the project logframe.

Project design using the logframe

The use of the method is split in two main phases: the analytical and the planning phases.

The analytical phase unfolds in four steps:

i. Stakeholder analysis

ii. Problem analysis

iii. Analysis of objectives

iv. Analysis of strategies

As the PCM handbook points out, the analytical phase should be carried out as an iterative
learning process rather than as a simple set of linear steps. For instance, if the analytical
process starts with the stakeholder analysis, it might have to be reviewed later in light of the
issues raised during the subsequent steps of problem and objectives analysis.
In the planning phase, the outputs of the analytical stage are translated into an operational
plan envisaging the project implementation. In concrete, the planning phase includes the
following steps:

v. Elaboration of the project logical framework

vi. Setting up the activity schedule

vii. Preparation of the project budget

An iterative process is also recommended in this phase. For instance, it might be necessary to
revise the objectives setting and the activity planning if the budget constraints do not allow
meeting the initial objectives.

The following box sums up the content of each step of the analytical phase.

Table 1: Steps of the framework analytical phase

Stakeholder analysis

Stakeholder is any individual or organization that has a significant interest in the project
(target groups, beneficiaries, implementers, etc). These different groups likely have different
if not contradictory interests that need to be understood and recognized very early in the
stage of project identification. In this context, it is important to know the motivations of the
different stakeholders as regards the project and try to take them into account when
objectives are set.

A participative approach is particularly recommended to channel the different stakeholders

and to capture the different perspectives in order to form consensus when required.

Problem analysis

Problem analysis envisaged identifying the negative aspects of a given situation and setting
up the cause-effect links among the identified problems. This analysis can be supported by a
problem tree (see example below) highlighting the core problem, the cause problems and the
effect problems.

Problem analysis allows the identification of the possible constraints and issues to which a
response is required. Such problems in general reflect the perception of the relevant
stakeholders and therefore they have a higher priority in the stakeholders’ perspectives.

A well done problem analysis paves the way for a proper setting of objectives, in the sense
that they correspond to the beneficiaries expectations.

Analysis of objectives

The analysis of objectives aims at anticipating a future desired situation, which represents a

2
positive answer to the problems identified in the previous phase. The analysis is supported by
an objectives tree, which is deducted from the problem tree through the conversion of
problems (formulated as negative situations) into objectives (formulated as positive
situations).

Analysis of strategy

Before the range of possible objectives, a choice must usually be made in light of a set of
criteria like: availability of financial resources, the mandate of the implementing entity, the
complementarities with other projects, etc.

This analytical phase is, in general, the most complex one, as it involves a significant volume
of complex information that must be sorted out in order to produce a consensual and feasible
project. In practice, it implies a number of commitment in order to ensure an adequate
balance between the interests of the agents, the political demands and the available
resources.

The following figure shows an example of the relation between the structures and content of
the problem tree and the objectives tree, using the example of a project envisaging the
reduction of river pollution.

The example highlights that the definition of objectives is strictly linked to the problem
analysis. Moreover, it shows how to formulate both problems and objectives. The former as
negative present situations; the latter as future positive situations.

3
Figure 1: Example of a problem tree1

1
CE (2004), Project Cycle Management Guidelines

4
Figure 2: Example of an objectives tree2

The following table shows the main elements of a logframe. It is built on the basis of the
stakeholder analysis, the objectives and the strategy, which provide the information for the
fulfillment of the first column of the table. The second column contains the performance
indicators, which should be set in relation to each level of the objectives hierarchy. The third
column indicates the sources of information to build the indicators. Finally, the fourth column
highlights those factors that are not under the responsibility of the project management but
which are nevertheless essential to the project success.

Table 2: Logframe structure

Intervention logic Performance Sources of Assumptions
indicators verification

Overall objectives Impact indicators: Sources of

The broad socio-
economic impact to
which the project
contributes – at a
national or sector
information and
Measures the long-
methods used to
term consequences
collect and report it
of the outcomes.
(including who and
when/how

2
CE (2004), Project Cycle Management Guidelines

5
level (it provides the frequently)
link to the policy
and/or sector
programme content)

Purpose Outcome indicators: Sources of Assumptions (factors

information and outside project
The outcome at the Measure the results
methods used to management’s
end of the project – in terms of target
collect and report it control) that may
more significantly the group benefits
(including who and impact on the
expected benefits to
when/how purpose-objective
the target groups
frequently) linkage

Results Output indicators: Sources of Assumptions (factors

information and outside project
The direct and Measure the
methods used to management’s
tangible results that immediate and
collect and report it control) that may
the project delivers, concrete
(including who and impact on the result-
and which are largely consequences of the
when/how purpose linkage
under project measures taken and
frequently)
management’s resources used
control

Activities Assumptions (factors

outside project
The tasks that need
management’s
to be carried out to
control) that may
deliver the planned
impact on the
results
activity-purpose
linkage

6
Strengths and shortcoming of the use of the Logical Framework Matrix

The generalised use of the Logical Framework Matrix since the early 90’s by the European
Commission provides enough evidence to strike a balance between its benefits and
limitations. In general it can be said that the difficulties found are more related to its misuse
than to its intrinsic limitations.

The following table synthesizes the main strengths and problems related to its use. They are
grouped in three domains: problem and objective setting, performance indicators and format
and application of the logframe. As regards the shortcomings, the most relevant ones are
indicated in the first place within each domain.

Table 3: Strengths and shortcomings of the logframe

Domains Strengths Common
shortcomings/difficulties

Problem analysis and ƒ Requires systematic analysis ƒ Problems and objectives set
objective setting of problems, including cause without participation of the
and effect relationships relevant stakeholders

ƒ Provides logical links between ƒ Getting consensus on

means and ends prioritary problems

ƒ Places the project within a ƒ Getting consensus on

broader development context prioritary objectives
(overall objectives and
ƒ Reducing objectives to a
purpose)
simplistic linear chain
ƒ Encourages examinations of
ƒ Inappropriate level of detail
risks and management
accountability for results

Indicators and source of ƒ Requires analysis on how to ƒ Finding measurable and

verification measure the achievement of
objectives, in terms of both
quantity and quality
ƒ Helps improve clarity and
specificity of objectives
ƒ Establishing unrealistic
ƒ Helps establish the monitoring
practical indicators for
higher level objectives and
for projects with ‘capacity
building’ and ‘process
objectives’
targets too early in the

7
 and evaluation framework
Format and application ƒ Links problem analysis to
objective setting
ƒ Emphasizes importance of
stakeholder analysis to
determine ‘whose problems’
and ‘who benefits’
ƒ Visually accessible and
relatively easy to understand
Adapted from CE (2004), Project Cycle Management Guidelines
In conclusion, the Logic Framework Matrix provides a convenient framework to design public
projects supported by EU funds. If its analytical and planning capabilities are not convincing
enough, in many EU financed projects its use is mandatory as part of the eligibility criteria.
Alessandra Merlo, July 2005
planning process
ƒ Relying on ‘project reports’
as the main ‘source of
verification’ and not
detailing where the required
information actually comes
from, who should collect it
and how frequently
ƒ Formulated after the project
has been designed, to
comply with donors
demands, instead of being
used as a guide
ƒ Prepared mechanistically as
a bureaucratic ‘box-filling’
requirement, not linked to
problem analysis, objective
setting or strategy selection
ƒ Used as a means of top-
down control – too rigidly
applied
ƒ Can alienate staff not
familiar with the key
concepts
ƒ Becomes ‘fetish’ rather than
a help