|Resources > Application of LFA
The Logical Framework Approach (LFA)
The Logical Framework Approach is a systematic method of developing
a Project Concept and selecting a Project Strategy.
1. Structure of the Logical Framework
The Logical Framework Approach consists of a number of modules
or steps which lead to the final module called "Project Planning
Matrix" (PPM). The PPM, which should not normally be more than
three or four pages shows exactly what the project proposes to
do, how the project will determine whether the objectives were
successfully achieved, and what risks are involved.
The sequence of steps is:
- Stakeholder Analysis
- Problem Analysis
- Alternatives Analysis
- Objectives Analysis
- Development of Project Planning Matrix (PPM)
The Project Planning Matrix (PPM) rolls out the hierarchy of
objectives with Objectively Verifiable Indicators for each Objective,
Means of Verification and Important Assumptions and External Factors.
In the PPM, the hierarchy of objectives appears from highest
level to lowest level as follows:
- Project Output
Other terms used for these three levels of objectives by various
|| Project Outputs
LFA is a Quality Assurance System, which follows the maxim, "Say
what you do… Do what you say". Quality Assurance emerged as an
important business management discipline during the 1980's. The
complexity of projects such as Polaris and Apollo demanded management
systems to assure safety and reliability. Japanese competition
and product liability legislation ensured that adequate attention
would be paid to quality in production and service sectors.
1.1. Where are we today?
Many donor agencies in India have begun to use LFA today. Between
1993 and 2002, we ran 32 LFA workshops for most of the big donors
in India, in locations as far apart as Delhi, Trivandrum, Jaipur,
Nagaland, Bangalore and Hyderabad.
Some of the NGOs we have worked with were at first cynical about
what they perceived to be a donor driven control mechanism. Some
felt that this was another esoteric technique like PRA, which
was just another name for rural research. Yet others found LFA
an empowering process and said that when proposals were developed
using a logical system such as this, the scope for arbitrary judgements
based on donor power is reduced.
DFID, NORAD, SIDA and the UNDP are some of the agencies which
require the use of LFA in aid projects.
LFA is ideal for developing a project concept with inputs from
all the stakeholders. It is also an excellent tool for determining
how project success shall be evaluated. Power users of LFA know
that the technique can also be used for assessing risk and uncertainty.
In actual practice, many of the LFA workshops we worked on were
commissioned after a project was sanctioned, and the Goal and
Purpose are taken as given. The LFA workshop in such cases is
actually intended for developing the Project Outputs and the Action
Unfortunately, the development of Project Outputs and the Action
Plan requires another set of tools and skills, which are often
left to Project Managers without adequate training or experience.
Thus we find that the maximum resources are allocated to the
planning and formulation of objectives, resulting in Action Plans
which are not often under optimum control.
1.2. Need for Systematic Review and Control
The feedback and control system is based on periodic review and
assessment of progress based on both quantitative and qualitative
indicators which were selected and agreed at the LFA workshop.
Very few of the projects we have worked with have staff trained
in performance mesurement and Management Information Systems (MIS).
These functions subsume a working knowledge of computers, data
analysis using elementary statistical procedures, and activity
analysis using PERT/CPM.
As a result, after having gone through an elaborate planning
procedure, we find that the projects revert to traditional methods
of programming and scheduling the activities for the project,
with little or no documentation based on systematic monitoring.
Casually made Action Plans could result in failure due to inaccurate
estimations. To cite an admittedly unusual case, one project in
the area of Community Health committed itself to regular visits
to every family in the project area by it's Health Team. On working
out the details of the visits based on average productivity, it
was seen that it would take the team four years to complete just
one round of visits, by which time the project would have to be
Another commom problem is the reluctance to invest money in Baseline
and Indicators Research. Macro-level indicators are chosen at
the time of the LFA Workshop, and brave targets are chosen without
benefit of data analysis.
2. Process Management
Each Project Output is essentially a Process, or a complex set
of sub-processes, activities and tasks.
The Project Outputs of an LFA Objectives Tree corresponds to
the Core Business Processes of the Project. These are the processes
that must be successfully implemented in order that the Project
Purpose may be achieved. How many Project Outputs would an Objectives
Tree have? Since the achievement of the Project Purpose depends
on the successful simultaneous execution of Project Outputs, the
probability of success is greater when the project outputs are
An analysis of different sets of probabilities would show that
the number of Project Outputs attached to a project should be
limited to single digits, if possible around 5 or 6, and the probability
of success of each process should be very high at not less than
0.9, which indicates odds of 9 to 1 if we are to achieve our Project
Another problem that comes of having too many Project Outputs,
very often running in departmental or “Subject Matter”
mode is that each department can tend to “pad on”
safety time and safety cost, which can all add up to unacceptable
levels. A shrewd observation suggests, “…people
give their ‘realistic estimates’ according to their
worst, past experience .” (GOLDRATT-1997)
Processes are at the lowest levels of the hierarchy of objectives.
Processes can be simplified into activities and tasks, which represent
the highest confidence of achievement. Activities and tasks are
very much under the control of the project, even if the Project
Goal and Project Purpose are less under project control, as they
depend on external factors.
If the problem solver is doubtful about the achievement of activities
and tasks, the project is very risky, and could result in the
mere performance of activities, which do not lead anywhere. Teams
responsible for processes must brainstorm for the best solutions,
based on the best cause-effect and baseline research information.
Once the solution has been selected, the team must communicate
the task to each other and single-mindedly implement it. Process
Mapping is a useful tool to clearly understand what is involved
in each process.
2.1. Process Mapping
Process Maps quickly communicate what the organisation does and
how it delivers services? A Process Map details the key activities
that make up each process and invariably points to the result,
which can be expected from it. There are two main types of Process
- Process Flowcharts (hierarchy)
- Process Definition Charts
- controls and constraints that regulate the activity
Process maps provide a structured approach, which can help avoid
surprises and cascading chaos. It can ensure that Task Managers
are clear about what they propose to do, and clearly shows the
interrelated processes, activities and tasks must be successfully
executed if the Project Output is to be delivered as promised.
It is most important for Project Managers and staff to understand
where their work fits into the larger picture, with roles and
responsibilities clearly defined and agreed. The integration of
the activities of various individuals and teams helps teams to
co-ordinate and direct their efforts. Such an approach helps to
eliminate inferior alternatives and select a combination which
have the best perceived potential. The selection could be made
by a task force reviewing the alternatives suggested at a brainstorming
2.2. Risk Assessment
Although the terms Risk and Uncertainly are commonly used in
every day conversation, they also have precise mathematical meanings.
Risk is implicit in a situation where we know what the outcomes
are and what the probabilities of each outcome are. For example,
when we toss a coin, we are taking a risk. We know that there
are only two outcomes - Heads or Tails. We also know that the
probability of either of these outcomes is 0.50. If we throw a
dice, there are six possible outcomes, and the probability of
any of these outcomes is 0.17. We talk of uncertainty when we
know the outcomes, but not their probabilities. For example, in
certain international situations, we believe that war might break
out, but we are not sure of the probability of that event. When
neither the outcomes nor their probabilities are known, we are
in a state of ignorance.
Risk monitoring involves monitoring the Important Assumptions
and External Factors in a LogFrame on a regular basis and determining
responsive action at regular intervals. Since Risk is projected
into the future, it is subject to constant change, and Assumptions
and External Factors must be continuously revisited. Experience
in LFA designs show that this is one of the most neglected areas
and therefore provides very little value to the project team.
3. Process Measurement
In most LogFrames, objectives seek to improve a situation: "Labour
productivity improved" or reduce occurrence or intensity of an
undesirable situation: "Indebtedness Reduced". The first step
in measurement would be to select an objective from the Objectives
Analysis. Next, a Baseline must be established to tell us where
we are now. The Objectively Verifiable Indicators proclaim where
we would like to be within a given period. We now need to determine
the gap between Objective (Where we want to be) and Baseline (Where
we are now). We are now in a position to calculate the Improvement
required, and reduce it to numbers and locations.
The Process Logic for processes in LFA based projects can be
determined from the Cause-Effect analysis. However, we need to
constantly search for new solutions based on team creativity instead
of relying only on "time-tested" approaches. Looking for existing
constraints helps to brainstorm how they can be reduced or removed?
A number of "Power Tools" (technology, strategic alliances, methods)
are available to us today, and we need to look at new combinations
of these resources to solve the given problem.
3.1. Output Indicators and Process Indicators
Since the LFA does not give much importance to Processes, it
is only natural that the emphasis in measurement is on Output
and Outcome Indicators and not on Process Indicators. Output and
Outcome Indicators are called "Lag Indicators", because information
on these indicators becomes available too late for corrective
action. This is why it is necessary to find "Performance Drivers"
for each Lag Indicator, which will give us early warning about
the performance on any objective. Performance Drivers are also
called "Lead Indicators" and on closer look, we find that these
are process indicators, which tell us how well we are doing and
help us to judge whether we will get where we want to get as originally
planned. In the development project scenario, "Checkpoints" or
3.2. Measures of Performance
The management maxim, "What you cannot measure, you cannot manage"
shows the importance of measurement in managing performance. It
is also well known that people perform on the basis of how you
measure their performance. Some organizations go overboard with
the idea of measurement and collect all kinds of data. It obviously
does not make sense to measure what the organization cannot or
will not use