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.
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).
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.
Getting to know the context can be done in several ways:
Things to learn about:
With all this information as your background, it is time to identify who will be / has to be involved in the project.
Who 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:
This information will help you decide whose interests and view should get priority during the problem analysis.
During 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.
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.
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.
Now 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.
There 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:
When there is more than one suitable strategy, you can use different criteria to select the best one.
Now it's time to put the information together in a logical framework.
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.
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.
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.
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:
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:
If the indicator cannot be readily measured and verified, it should be replaced or dropped altogether.
After the workshop, it is important to finalise the project’s design. This means that you have to check:
During the design phase, the LFA can be used to:
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 :
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.
An evaluation looks at the purpose, outcomes and impact of the project and poses questions like:
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.