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:

• Goal
• Purpose
• Project Output

Other terms used for these three levels of objectives by various agencies are:

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 Plan.

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 closed.

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 fewer.

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 Purpose.

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 maps: Goal

• Process Flowcharts (hierarchy)
  • Sequencing of Activities
  • Process Logic

• Process Definition Charts
  • Inputs
  • Resources required
  • Outputs
  • 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 session.

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 short-term targets.

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

• Typical Schedule for LFA Workshops
• List of LFA Workshops
• Work Schedule - Workshop on Process Management