Logical Framework Approach (LFA)

The Logical Framework Approach or LFA is a systematic and analytical process for objectives-oriented project planning and management. LFA is also known under other names, such as Objectives Oriented Planning or Goals Oriented Planning. It makes use of the basic logframe matrix to design, plan and manage projects.

What LFA adds to the basic logical framework, is a method to develop the project’s goals and activities and identify key information (such as risks) through a participatory approach. Basically, this means that instead of having a single person who designs the project all on his own, you seek the involvement of all concerned parties – also known as the stakeholders. The most important stakeholders are the potential beneficiaries of the project, or the target group.

Getting the involvement of your target group and other stakeholders not only ensures that your project is well designed. It also makes sure that everybody is aware of the project and what it is supposed to change. It allows people to get involved, and develop a feeling of responsibility for the project and its results.

This is known as developing ownership for the project’s outcomes, and it is important to make sure that the positive realisations of the project are embedded locally and durable over  time. People will care about the project and take care about its results.

Project design with the Logical Framework Approach

The main steps in the Logical Framework Approach are:

Although you can go step by step through this process, you mustn’t forget that this is not a linear process per se. You may need to come back to a previous step, or you may want to go through these phases in a different order. For instance, you may want to start be identifying the stakeholders and the identify the problems with them, but you can also start by identifying the problem and then see who is most impacted by them (and maybe do a closer problem identification with them).

Logical framework Approach - overview of the process

The main activity during the design phase of a project using LFA is a workshop with the stakeholders. But before you get together a group of people, it is important to get to know the environment in which your project will take place.

 

Learning about the context

Getting to know the context can be done in several ways:

  • Reading reports, books, documents, websites
  • Studying maps
  • Talking with (local) experts
  • Field visits
  • Feasibility study

In case you're wondering: this is the maternity ward of a hospital in the Democratic Republic of the Congo (province of Kasaï Occidental)

Things to learn about:

  • Is there a need for your specific expertise/assistance?
  • Potential beneficiaries/target groups
  • Potential intervention areas
  • Potential for funding/financing
  • Potential partners, networks
  • Potential competition
  • Potential impact of your interventions
  • Political, social, economic situation of the country/region/area
  • (Recent) history
  • Current and potential market situation, economic stability
  • Available human resources, level of education
  • Gender situation, discrimination, social (in)stability
  • Infrastructure, ICT, logistics
  • Security situation
  • Climatic conditions, natural risks (droughts, earthquakes, rains…)

With all this information as your background, it is time to identify who will be / has to be involved in the project.

Identify the stakeholders

Step 2 - identify the stakeholdersWho are the people, groups, organisations, government bodies, companies… that are somehow involved or touched by this project? When you do a background analysis you will get a basic idea about who will be involved. This first contacts may lead you to identifying others.

It is important to list the potential stakeholders, and then to determine who will get priority when you start analysing the problems. Is the view of the local authorities more important than that of the ministry? Is the view of the local NGOs more important than that of the (local) government? Is the view of the farmers more important than that of the local trades people? Also, make sure you get the view of both men AND women.

There are a number of tools that can help you with stakeholder analysis, such as mapping tools, Venn diagrams, organisation charts (to identify administrative levels for instance) and so on.

When you’ve selected the most important groups, you can then analyse:

  • Their main problems
  • Their interests and needs
  • Their strengths and weaknesses
  • How they relate to other groups (cooperation/conflict; dependent/independent…)

This information will help you decide whose interests and view should get priority during the problem analysis.

Stakeholder meeting in Ituri, Democratic Republic of the Congo

Problem tree analysis

Step 3 - Problem Tree AnalysisDuring the workshop (or sometimes it may be necessary to organise a series of workshops), you get a representative sample of the stakeholders that you identified with the group. The problem tree analysis is an exercise that allows you to identify the different problems that people face, and the relationships between those problems. The idea is to identify the core problem, and see what things are at the root cause of this central problem, and what other problems are a consequence of the core problem.

 

The first step is to identify the different problems

  • Ask people to note different problems on cards: one card per problem.
  • The problems have to be real – if there’s doubt ask them to clarify by an example.
  • Sometimes people will bring up things that they think are important for you – because you are rich and otherwise you’re not going to give the money, right?
  • Real problems also means that they are occurring now, not that they could occur if…
  • A problem is not the absence of a solution – it’s still too early to think of solutions. For instance, if someone thinks that he would get better crop yields if only he’d have fertilizers, the problem is not ‘The absence of fertilizers’, but ‘Poor (quality of the) soil’.
  •  

Identify the core problem and establish a problem tree

Basically there are two ways to go about this. The group can agree on the core problem, and develop the problem tree around it. This means you look at what issues are causing the problem and which ones are a consequence of the core problem and you try to establish cause-and-effect relations between them. Often, the core problem is quite clear and just pops up. Also, your very presence and the fact that you can do specific things will influence the choice. If you are specialised in water and irrigation, the core problem will tend to be more ‘watery’ than when you are specialised in commercialisation of food items.

The other way is to establish the cause and effect relationships between the problems first, and then select the core problem. This may give you more work to do, because it will be less clear from the onset what issues are less important or relevant than others.

Problem trees can be quite large, so here  the floor is used to give every card a place

 

The problem tree itself has roots and branches

The roots can be found below the core problem, these are the causes that lead to the issue that you've identified. Directly below the core problem you'll find the cards with the most direct causes. Below these issues are their respective causes and so on.

The branches or the consequences are above the core problem. The most direct consequences can be found right above the core problem, then the issues that are a consequence of these direct consequences and so on.

When your tree is finished, you may find that there are still some gaps – meaning there are problems (cards) that you’ve not identified yet. Or maybe you don’t understand the relation between a separate root/branch and the rest of the tree, and you may have to reflect on what is missing – or maybe there is a no relation at all.

The objectives tree

Step 4 - the Objectives TreeNow it’s time to turn your problem tree into something constructive: the objectives tree. This simply means that you start at the top row of your problem tree, and rephrase every card in a positive statement or a solution.

  • As before, sometimes you may need to rephrase the objective or clarify it.
  • You also have to check the cause-and-effect relationships. If problem A causes problem B, does solution A also lead to the solution of B?
  • Remove objectives that are not realistic.
  • Sometimes it is necessary to add (intermediary) objectives.

 

 

 

 

 

 

 

Choosing the project’s main strategy

Step 5 - choose the main strategyThere are often different ways to achieve the same objective. This means that it is important to agree on one single strategy. Often you’ll find that there is one strategy that fits your organisation’s capabilities (type of activities, experience, available donor funds, capacities of staff and available human resources…) better than the other ones. Other elements that may influence your choice are:

  • the price tag of each individual option;
  • the potential risks and benefits;
  • the ecological and financial impact and sustainability of each option;
  • the potential impact on gender issues (both positive and negative);
  • the social impact, including impact on social tensions and conflicts
  • etc.

When there is more than one suitable strategy, you can use different criteria to select the best one.

 

 

 

 

 

 

Formulate the logical framework

Step 6 - Formulate the logframeNow it's time to put the information together in a logical framework.

  • First you decide on the project's logic (intervention logic). This is the first column of the logical framework, and you can use the information from your objectives tree to identify the general objectives or goals of your project (the things above the main problem), the specific objective or purpose (the main problem itself) and the expected results (the things below the main problem).
  • Then we jump to the far right column of the logframe, to identify the assumptions. These are the things that need to hold true in order for you to achieve your objectives.
  • Finally it's time to think about how you are going to follow-up the progress of your project and evaluate its results. You'll need indicators for monitoring and evaluation (second column) and verification sources that specify how, where and when you can find that information (third column).

You can establish the basic version of your logframe during the workshop with your stakeholders. During the workshop, focus on getting the main ideas right and clear for everybody. Afterwards, you can put everything in nice sentences.

 

 

Identify the project logic

You now have the basic information needed to establish the project’s logic – meaning the first column of the logical framework.

Generally the core problem, rephrased as an objective, becomes the purpose (or specific objective) of your project. This is the main reason why you started the project; the thing that you most urgently want to solve.

The solution of the core problem contributes (in the long run) to the solution of a problem in the larger society. This is the long term goal (or general objective) your project contributes to. Sometimes a project contributes to the solution of several issues that exist within that particular context and society.

The cards in the objective tree that were placed below the core problem/purpose – and that are part of the selected strategy – become the outputs and activities. The outputs are the concrete things the team and beneficiaries will achieve during the life of the project. When the outputs are combined, the project’s purpose should be achieved.

To achieve each output, you’ll need a process that generally includes several activities. To do the activities, the project needs a number of means (inputs), such as staff, transport, tools, equipment, ICT, training, building materials, seeds… These come at a price, so now is a good time to get an indication of how much this all will cost.

The information from the objectives tree is necessary to develop the logical framework, but generally it takes some tinkering to perfect the logframe. Maybe some outputs and activities may have to be added. Or maybe the scope of the purpose has to be redefined, to make its achievement more realistic. During the workshop, make sure the project’s basic logic is sound.

Identify risks and assumptions with your stakeholders

Because the problem tree has given you an insight in the relationship between different issues, it allows you to see what things may influence your main strategy and the achievement of your purpose. However, there may also be other elements that were not identified in the problem tree: generally you’ll find the elements that come from the context or environment. You also have to take into account other risks such as financial risks, practical or operational risks, and organisational risks.

  1. List the risks/assumptions
  2. Eliminate those that are not important
  3. Try to assess what the probability is that each risk occurs
    • If the risk is very likely to occur and the impact on the project is grave (it is doubtful you can achieve the project), then you have to redesign your project to eliminate or significantly reduce this risk. If this is not possible you should really think again about doing the project.
    • If the risk is likely to occur and the impact is important, but not life threatening, you should include it in the logframe and monitor the risk. If possible, you should try to influence the risk.
    • If the impact of the risk is low, you shouldn’t include it into the logframe.
  4. Identify whether the risk is a threat to one of the different outputs or to the achievement of the project’s purpose itself. Other risks may threaten the sustainability of the results of the project, and therefore its long term impact and contribution to the solution of some of the society’s problems.

 

Indicators and their sources of verification

The next step in the workshop is to identify the indicators. There are a number of advantages to formulating the indicators with the whole group:

  1. People that are closer to the field and the actual problems will know better how you can see that the situation improves. With the group, you can find better indicators.
  2. It is easier to find useful indicators, that can effectively be monitored.

When a project manager tries to identify indicators on his own, he or she will have a tendency to create indicators that can be expressed in numbers, such as the income per household to measure improved welfare. However, in the field it may be very difficult to get such a number, because people often don’t have a notion of how money they earn. Besides, no-one likes to talk about how much they earn, do they? With a group you will be able to come up with indicators that are more easily measured. For instance whether people can afford to send their children to school, or if they can afford to improve their house or pay for transport.

When the indicators are identified, the group should check for each indicator:

  • What information is needed
  • Who should give/find that information
  • In what form

If the indicator cannot be readily measured and verified, it should be replaced or dropped altogether.

Verify the project’s design

Step 7 - Verify the project logicAfter the workshop, it is important to finalise the project’s design. This means that you have to check:

  • The project’s basic logic: are all the activities there to achieve the outputs that you want? Does the combination of the outputs lead to the purpose? Does the purpose contribute to the goal(s)? Aren’t there any loose ends (missing activities, outputs that are not relevant for the purpose…)?
  • Is the target group clearly defined (size, location, type of activities they do, gender, age…)?
  • Who will receive the (financial/material) benefits from the project?
  • Are all the elements clear and unambiguous? Will everyone concerned understand what is written in the same way? Aren’t there any concepts that can be interpreted in different ways in various contexts (for instance: ‘gender equality’ is interpreted differently in Western Europe, in Eastern Europe, in Northern Africa, in Central Africa, in South-East Asia…)
  • Are the project as a whole and its different elements realistic?
  • Is the analysis of the risks/assumptions well made? Is it clear how you will react in the event that one or several of these risks occur?
  • Is the monitoring system established (indicators + verification sources) ? Are the indicators well designed?
  • Are the necessary resources there to execute the activities and to manage the project? What will you do with investments once the project is over?

Monitoring, reporting and evaluating with LFA

During the design phase, the LFA can be used to:

  • Identify the stakeholders
  • Identify issues and problems, determine how they are related in a problem tree and create a solutions tree
  • Identify/formulate the goals, purpose, outputs and activities of the project
  • Identify/formulate the risks and assumptions
  • Identify/formulate the indicators and verification sources
  • Create a detailed planning
  • Establish the project’s budget

Most of these elements can be found during a workshop (or a number of workshops) with stakeholders/partners/potential beneficiaries.

But apart from the identification and preparation of the project, the LFA can also be used during and after the execution of the project, to :

  • monitor;
  • report;
  • evaluate/review.

Monitoring and reporting

Monitoring basically means that you check whether the execution of the project is on target by verifying whethere the activities are executed as planned. Monitoring allows you to answer the question: are we on our way to achieving the outputs (results) that we want?

During the design phase, the indicators and verification sources were identified and integrated in the logical framework. It is important that this system of indicators and means of verification remains stable throughout the project. If not, it will be impossible to see the evolution in the indicators, and there will  be confusion between partners about what indicators to use.

In the field, specific tools and formats have to be developed to gather information and do the measurements. Generally, standardised forms are used that can be filled out by project staff, often in a participatory exercise with groups of beneficiaries. Sometimes a database is needed to manage the information, or a spreadsheet to make calculations. It is also important to define who does what; who reports to whom; etc.

The results can be presented in the form of the project’s logframe, updating the values of the indicators over time. Often, donors will oblige you to present intermediary and final reports in this way. Some donors then use the logframe to review the project together with the lead-NGO or with the partners.

Evaluations

An evaluation looks at the purpose, outcomes and impact of the project and poses questions like:

  • Was it a good idea to do this project in the first place and does it address the problems of the people (is the project relevant?)
  • Did the project change anything in the long run? What is its impact? What are the positive and the negative impacts?
  • Are the achievements durable/sustainable? Do the positive outcomes persist when the project/assistance is finished? Are the partners or beneficiaries capable of maintaining the working costs and periodic investments costs that come with the new structures/organisations/infrastructures (financial sustainability)? Is ecological sustainability guaranteed?

Evaluations can be done by the partner organisations involved in the project (internal evaluation), or by someone external to the project, like a consultant. Sometimes donors won’t accept the findings of internal evaluations because they may not be objective (the partners may have an interest in pretending the outcome and impact of the project is better than it is in reality).

In order for an evaluator to be able to do his or her work, he/she needs to have access to information produced by the monitoring system over the course of the project. At the very least, the evaluator has to be able to compare the situation of the beneficiaries before any activities took place (the baseline), with the situation at the end.

In principle, the purpose of an evaluation is to learn, and to be able to adapt and guide projects that are still being executed, or to take into account what’s been learned when you design new projects. Evaluations also serve to control whether the project is going to achieve or has achieved its purpose. However, very often evaluations are only used to control and not so much to learn.