1. Involve all relevant stakeholders in participatory processes of project design.
2. Undertake a thorough situation analysis, together with primary stakeholders, to learn as much as possible about the project context as a basis for designing a project strategy and implementation processes that are relevant.
3. Develop a logical and feasible project strategy that clearly expresses what will be achieved (goal and purposes) and how it will be achieved (outputs and activities).
4. Agree and fous on cross-cutting issues of poverty, gender and participation.
5. Plan for long-term capacity development and sustainability to ensure that the project contributes to the empowerment and self-reliance of local people and institutions.
6. Build in opportunities and activities that support learning and enable adaptation of the project strategy during implementation.

3.1.3 Using the Logical Framework Approach

Since 1998, IFAD has required that projects be designed using the Logical Framework Approach (LFA). This process was originally developed in the 1970s to improve the quality and clarity of project design. The LFA process is based on participation of key stakeholders, including primary stakeholders. The project design that results from the LFA process is summarised in a table that is referred to as the logical framework matrix, or logframe (see Section 3.3.2). While the LFA has become widely accepted as useful for project planning, it also has some clearly recognised problems. So the standard LFA planning process has been improved in different ways over the years. Flexible and critical use of the LFA means:

• recognising that development is not mechanical by building options and opportunities for adaptation into the design;
• valuing outcomes (achievements between tangible outputs and long-term impacts) by making them explicit in the logframe;
• avoiding over-simplification of large projects or programmes by using multiple purposes, a cascading logframe or a five-layer logframe;
• including people’s visions and aspirations and identifying opportunities during the planning rather than focusing only on problem analysis;
• recognising that quantifiable indicators and qualitative information, such as opinions and stories of change, are needed for M&E;
• guarding against bureaucratic control by reporting more on outcomes, (interim) impacts and planned improvements – and less on activities and outputs;
• avoiding token use of the logframe matrix by ensuring it represents the shared vision for the development intervention, by using it as a management tool and by keeping it updated;
• tracking assumptions as part of M&E to help guide the project strategy.

Note that a project can be designed well in different ways – and that the LFA is only one of these ways. Also, using the LFA is certainly no guarantee of ending up with a good project design. You need to be both critical and creative to achieve a design process that is appropriate for the context.

3.1.4 Linking Project Design with the Annual Work Plan and Budget

The project logframe will show the main activities for the life of the project. Each year the implementers need to identify which activities are needed for the coming year and prepare a budget. The logframe is the basis for the annual work plan and budget (AWPB). For the logframe to be useful, it must be sufficiently detailed and, in particular, updated to reflect the current situation of the project. For example, the original logframe may have included outputs or even components that are no longer appropriate and have been dropped. How the project appraisal report is translated into operational plans varies enormously across projects, although all have annual plans. Some have an overall operational plan with milestones that look at key implementation over the project’s lifetime, which can help translate the logframe into annual clusters of activity. Others have "project implementation manuals" that detail operations. Some have two- or three-year operational plans, alongside annual plans.

3.1.5 Linking M&E to Project Design

Developing M&E starts long before start-up. Initial project design strongly influences the ease with which M&E is implemented later on through, for example:

• the relationships and commitment established with partners and local people, particularly the intended primary stakeholders;

• the logic and feasibility of the project strategy;

• the resources allocated to M&E (funding, time, expertise);

• the degree of inbuilt flexibility that allows M&E findings to have a steering function;

• any operational details of M&E that might be established during initial design.

During project formulation, a broad M&E framework should be developed and included in the formulation and appraisal documents. This framework provides: a) sufficient detail to enable budgeting and allocation of technical expertise, b) an overview of how M&E will be undertaken, and c) some guidance for project staff about how M&E should be set up during start-up. The M&E framework complements the highly summarised M&E information that is the logframe (see Section 3.4). Much of what is developed for the M&E system during the initial project design phase will only be indicative of the final plan and will need to be revised and refined during start-up.

Back to Top

3.2 Designing for Learning, Empowerment and Sustainability

Designing a good rural development project requires careful attention to the social processes and institutional development that will enable learning and the empowerment of primary stakeholders and lead to sustained benefits.

3.2.1 Involve Stakeholders in Project Design Processes

Projects without good stakeholder consultation are setting themselves up for failure. Those that do consult widely increase their chances of success. Box 3-1 describes a simple case in Ghana where a participatory process created the opportunity for primary stakeholders to adjust part of the strategy to make it appropriate to their situation and thus more likely to meet their real needs. Involving stakeholders in project design is important specifically for:

• inspiring them to identify, manage and control their own development aspirations, and so empower themselves;
• ensuring the project goals and objectives will be relevant and, as a result, meet the real needs of the rural poor;
• ensuring the project strategy is appropriate to local circumstances;
• building the partnerships, ownership and commitment needed for effective implementation.

Local participation early on can also be cost-effective in the long run. In Uganda, more time and money were spent to involve primary stakeholders in a more inclusive formulation process of the District Development Pilot Project, which was then found to be effective because of local inputs and ownership and a deeper understanding of the project. If the investment hadn’t been made up front, much money would have to have been spent later for one-way information campaigns before and during project implementation.

The first step in project design is to conduct an initial stakeholder analysis (see Annex D for more detail). This requires listing potential stakeholders (individuals, social groups and organisations), prioritising who must be involved (and not everyone who it would be nice to involve) and agreeing with them on how they can best be involved. This is the basis for being able to understand their needs. Box 3-2 lists questions developed by a project in Tanzania to guide an analysis of stakeholder needs.

A shared understanding by stakeholders of the concepts of poverty reduction, gender equity and participation is critical. It is the only way to secure agreement on how to build these concepts into the project strategy. Differing understandings can lead to diverging objectives. For example, in one project in Yemen, concerns were raised about the CACB’s (Cooperative Agricultural Credit Bank) apparent lack of commitment to the project target group of small farmers. Then project staff discovered that the CACB was defining as eligible all small farmers within the project region. However, the project was targeting only those from 47 specific villages involved in project shelterbelt activities, as named in the project design documents. Different definitions had caused frustration and disrupted monitoring of credit activities. Defining what these three concepts mean for the intended implementers is the first step. M&E experiences in India revealed that the intention to target the poorest of the poor was not always fulfilled because the official criteria for "below poverty line" (BPL) were inadequate for the project. An NGO there used the official criteria in "wealth ranking" and "wealth mapping" methods to check the proportion of village members from poor households against the status of households who had not joined the self-help groups (SHG). They found that many households not in the SHGs did not meet the BPL criteria, yet they were still living in relative poverty.

Agreeing on terms like "poverty" and "basic necessities" is essential both for good project design and M&E. Opportunities for reaching agreement need to be created. For example, the ADIP project in Bangladesh took a group-based extension approach and kept close ties with NGOs and local agencies in the project design. This created good opportunities for agreeing on poverty indicators that guide some M&E.

The same is true for "gender" and "participation" (see Section 2.7). Even when everyone agrees on these concepts at the onset, they need to return to them regularly to limit deviations from a goal in poverty reduction and equitable development. Nevertheless, differing opinions may remain, as the activities based on these definitions are implemented in the organisational context of each stakeholder group (see Box 3-5).

3.2.3 Plan for Capacity Development and Sustainability

Many IFAD-supported projects focus on delivering infrastructure and public facilities– wells, roads, covered markets, clinics, school buildings, etc. But it is the people who use and maintain a structure. A major lesson learned by development agencies over the past 25 years is that investing in capacities is at least as important as in infrastructure for sustained poverty reduction. An interesting example of what this may mean in practice comes from the WUPAP programme in Nepal. Its overall purpose is "To assist in self-empowerment and in strengthening the capacity of poor and socially disadvantaged groups of people to: mobilise and increase their own resources; gain access to external resources; claim social justice." [Emphasis added.] To ensure this focus, questions to consider during project design and adaptation are:

1. Whose capacities are being built through the project?
2. Will these capacities reduce rural poverty?
3. If not, what else do we need to do in terms of capacity-building to have a lasting local impact?

Some people think that capacity development simply requires counting how many people attend training workshops. But attending a workshop does not necessarily strengthen capacity. Building capacity requires conscious effort to share decision-making with primary stakeholders over time (see Box 3-6).

Monitoring and evaluating capacity-building is not as straightforward as counting infrastructure changes. "Capacity" is sometimes difficult to describe clearly in ways that will allow measurable indicators and may therefore require additional creative thinking. Box 3-7 compares performance indicators for Nepal’s WUPAP rural infrastructure component with indicators from a similar component in a project in China. Note that including a capacity-development focus requires a participatory M&E approach – only the stakeholders themselves can explain if and how capacity might have been built. For example, capacity is not about how many kilometres of road have been built, but how stakeholders are going to ensure that these roads are maintained, used and extended.

Box 3-7. Comparing indicators that foster capacity development with ones neutral towards it (Note: the italicised words indicate where capacity development is made explicit.)

1. A broad base. Capacity-building must include not only primary stakeholders but also other key stakeholders, particularly local government (see Box 3-8).
2. The plan for phasing-out. Project managers in India have systematic phasing-out plans that list specific responsibilities to be able to show sustainable outcomes for their investments in local development.
3. Sensitivity in M&E. Tracking and evaluating capacity development is particularly sensitive because it focuses on people and makes judgements about their activities.

3.2.4 Plan for Learning and Adaptation During Implementation

Any project will require many adjustments during its life. This is guaranteed. Do not overly detail a project strategy, as this hinders adjustments during implementation. Here are some ideas for a design team to build learning opportunities and change into the design.

• Design the process, as well as objectives, at the higher levels (also see next point). Identify the forums and processes that will be used to involve stakeholders in project review and adaptation, and build in flexibility to respond to unplanned opportunities. This approach was used to advantage by the TEPP project in Yemen to involve emerging stakeholder groups in information-gathering and feedback. Local communities had a strong sense of group action. When local youths saw what the project was beginning to develop, they started to participate voluntarily in certain aspects, lending a hand with seedling protection, community health and water supplies. The project was able to involve them in implementation and M&E, and so gained valuable support and informal feedback on the field situation.
• Focus on clear goals (impacts) and purposes (outcomes), rather than over-specifying activities and outputs. Project design teams commonly over-specify activities and spend time on the overall goal, then they fill the in-between steps with hastily formulated purpose(s) or outcomes. Yet these interim levels are the most important part of "managing for impact" so require most of the attention. This approach can also have secondary benefits, as was seen in Ghana where the second phase of a project was designed to be less targeted and more flexible. Project management and the cooperating institution were given the authority to adjust the components and outputs in the design to respond to locally expressed targets. This more flexible design also increased the involvement and ownership of the project by the primary stakeholders.
• Be explicit about uncertainty. Instead of trying to force specificity, explain what you simply do not yet know, such as exactly how communities will want to administer local development funds. Explain what is unknown and how and when project management should be clear on the issues. This means suggested targets should be approximate. State quantitative targets as being approximate and describe how the project could revise them, if necessary. For example, the logframe of the WUPAP programme in Nepal explicitly states: "As the programme is demand driven, the output targets remain highly indicative and in some cases are not specified in detail… The logframe should be regarded as indicative, as it will need to be reworked by its stakeholders in the course of implementation."
• Build in mini-research phases at key moments. Not all issues of relevance to a project can be anticipated ahead of time. List as an activity and budget for "focused studies" to answer questions about the project context that may arise. For example, if the project is testing a new kind of micro-credit scheme, then before this is expanded a focused and detailed interim evaluation is needed.
• Make it explicit that the project strategy and logframe matrix should be revised each year. Annual adjustments to the logframe are increasingly accepted and expected. A project design can indicate when and with whom this will take place.
• Make "adaptive management" a key function in the terms of reference for senior management and partner contracts. When hiring managers and selecting partners, select those who can balance uncertainty with being clear about poverty reduction goals.
• Budget for experimentation and for the unexpected. If the project is testing a new approach, then the budget should reflect this and more money should be allocated to later years when there is more certainty about expanding the approach. Also leave a portion of the budget and staff time for activities that do not fit into established categories. In some companies that must innovate to survive, researchers can spend 10% of their time on activities of their own choosing. This allows them to respond to unexpected opportunities.

Back to Top

3.3 Introducing the Logical Framework Approach

The logical framework approach (LFA) can be very useful for guiding project design and implementation. The basic ideas behind the LFA are simple and common sense for any design process.

1. Be as clear as possible about what you are trying to achieve and how it will be achieved.
2. Decide how you will know if you are achieving your objectives and put in place a monitoring system.
3. Make explicit the conditions (assumptions) outside the direct control of the project that are critical for the project to succeed and assess the risk for the project if these conditions fail to arise or change.

The LFA also has some limitations. The main criticism is that it can lead to a rigid and bureaucratically controlled project design that becomes disconnected from field realities and changing situations. However, the LFA is easy to use more adaptively, particularly if the original design is seen, at least in part, as needing future finalization and probably revision, and project management prioritises annual reviews and logframe updating. The logframes of IFAD-supported projects vary widely in their quality, application and terminology. Design teams using the logframe for IFAD-supported projects commonly experience difficulties. These arise because IFAD-supported projects are long term, aim at high-level poverty reduction goals and aim to undertake a wide range of development activities. These features require a fine balance between too much detail and oversimplification. So in practice, a summarised logframe will be useful to provide an overview of the project and for those making decisions about project funding. For those using the logframe as a management tool, more detail will be needed. When facilitated well, the LFA is generally seen as very valuable by project stakeholders (see Box 3-9) and leads to a better quality and shared understanding of needs, objectives and strategies by all involved. When possible, try to follow the basic ideas without forcing everyone to understand the full detail of the logframe matrix. Visually mapping out the process steps can make them clearer than using the four-column table format. It may also be a good idea to avoid some official terminology, finding local words instead. Some people may be scared off by terms like "logframe" and "objectively verifiable indicators". These practices all lend to flexible use.

3.3.1 Key Steps in the Logical Framework Approach

While most people are familiar with the logical framework matrix, the most important part of the LFA is actually the planning process that has been developed to improve the quality and clarity of project design. There are various versions of the steps in the LFA. The one presented below takes account of the specific nature of IFAD-supported rural development projects. The key steps to be undertaken – with well-selected and diverse stakeholders – are:

1. establish the general scope or focus of the project;
2. agree on the specific planning framework, terminology and design process;
3. undertake a detailed situation analysis;
4. develop the project strategy (objective hierarchy, implementation arrangements and resources);
5. identify and analyse the assumptions and risks for the chosen strategies, modifying the project design if assumptions are incorrect or risks are too high;
6. develop the monitoring and evaluation framework.

Each step is discussed in more detail in the next sub-section, with detailed examples of the logframe matrix in Annex B and of the M&E matrix in Annex C.

3.3.2 The Logical Framework Matrix

The written output of the LFA is the logframe matrix. The standard matrix is a table with four rows and four columns. This matrix summarises:

1. what the project should achieve, from the level of an overall goal down to specific activities;
2. the performance questions and indicators that will be used to monitor progress and overall achievement;
3. how these indicators will be monitored or where the data can be found;
4. the assumptions behind the logic of how activities will eventually contribute to the goal, plus associated risks for the project if assumptions turn out to be incorrect.

Table 3-2 shows a logical framework matrix appropriate for IFAD-supported projects and consistent with ideas in this Guide. Alternative, commonly found terms used in the matrix are given in parentheses. Note that inputs required for activities to be carried out are written at the activity level in the second column (Performance Questions and Indicators) – the column is not for indicators. The table also suggests how to write the objectives in the hierarchy.

Table 3-2. The logical framework matrix and how each level is written (alternative common terms in parentheses)

Using the Matrix for Large Projects or Programmes

Many IFAD-supported projects involve diverse components, including health, infrastructure, extension support, irrigation development, micro-finance, organisational development and social justice. Each of these different elements could be considered projects in their own right, although they are often closely linked. So some IFAD "projects" are more like programmes, in the sense that they involve a diverse range of loosely-coordinated initiatives being implemented by different groups for the same overall goal. Three problems occur when large and multidimensional projects (or programmes) are summarized into a four-by-four logframe matrix.

1. The project is oversimplified to such an extent that the matrix provides insufficient detail for effective management or M&E.
2. Outcomes, outputs and activities tend to become confused. For example, what might be an overall outcome for the irrigation component is written in the matrix as an output of the project; then, what are really irrigation-related outputs are included in the matrix as project activities.
3. Insufficient detail is given at the purpose level in defining the outcomes needed to guide the project strategy towards impact (see Section 2.3).

You have three options for overcoming these problems (see Table 3-3).

• Introduce multiple purposes for the project. With projects that have a number of components, each component then has a separate purpose. This is commonly done with IFAD-supported projects. (Be aware that some versions of the LFA only allow one purpose per project). Try to avoid viewing large project components as outputs. An output is a specific deliverable product or service, whereas a project component is broader and is achieved by the delivery of a series of outputs.
• Use the idea of a "cascading logframe". View your project in terms of one master logframe matrix, with a series of smaller, linked logframes (or sub-projects).
• Extra level of objectives. Introduce an extra layer into the logframe matrix between "Outputs" and "Purpose", which could be called "Component objectives" or "Key outcomes".¹ Many projects already implicitly or explicitly work with this idea but do not include it in the logframe matrix.

The most common version of the LFA suggests only one purpose per project. However, the size, range of components and long timeframe of IFAD-supported projects means that having a single project goal and only one project purpose is not helpful. Therefore, many IFAD-supported projects have moved to using multiple purposes that relate to each of the major components. It is this model of the logframe matrix that guides the examples in the Guide.

Another problem of concern in complex projects is the difficulty of including cross-cutting concerns in a linear objective hierarchy. For example, you may want to pay particular attention to women’s empowerment in project activities. Setting up an output layer around gender equity may isolate gender, when what you want to do is integrate gender into all activities. Yet you cannot ignore this output as distinct, since it risks leaving out indicators for assessing performance on the gender front.

This dilemma can be overcome by including separate cross-cutting objectives or principles. Sometimes these fit into the logframe in an integrated manner. If not, they need to be included in the project document and preferably as an attachment to the matrix. Being explicit about these cross-cutting objectives or principles is important in order to include them not only in activities but also in M&E.

Table 3-3. Three options for adjusting the structure of the logframe matrix

Your project may have one output that is formulated as: "improve the capacity of the agricultural extension service and the skills of extension workers". Many projects use an indicator such as "number of extension workers trained". But if you want to manage for impact, you need to know the extent to which extension staff are using new skills in the field and, in turn, the extent to which farmers are developing and adopting improved agricultural practices. These are outcomes that occur after you have achieved your outputs (number of extension agents trained) and are necessary in order to have impact (increased productivity and income for farmers). If your M&E data show that although many extension workers have been trained, farmers are not adopting improved practices, then you can question what might be going wrong with your strategy of improving the extension service through training. This is why monitoring change at the level of outcomes is so critical in managing for impact. For IFAD, outcomes are also recognised as lower, purpose-level impacts. So, for communication and reporting reasons, it is important not to limit the documentation of impact to only the goal level of the objective hierarchy. Most people who use the standard LFA and matrix focus on tangible outputs. Outcomes should be included as indicators at the purpose level, but this is rarely done well. This is partly because the logframe was originally designed to focus on controlling the delivery of tangible outputs to be produced, such as kilometres of road built or area of irrigation scheme constructed. The three ways of dealing with larger projects, mentioned above, all help make the outcome level more explicit and detailed and also easier to monitor and evaluate.

Back to Top

3.4 Using the Logical Framework Approach

3.4.1 Step One: Establish the General Scope and Focus of the Project

The starting point for any project is to identify the general situation that will be improved, the likely primary and other stakeholders, the geographic scope of the project, the range of issues that will be addressed, and the likely length and expenditure of the project. Also find out what the community, government and potential funding agencies’ interests are in the project. This initial information provides the starting point for defining and guiding the detailed situation analysis and design steps. Some of this information will be outlined in the Country Strategic Opportunities Paper (COSOP). During this initial step, it is important to find out if the basic concept underpinning the project is feasible and if there is sufficient support from key stakeholders for it to be worthwhile to proceed to the next step.

3.4.2 Step Two: Decide on the Planning Framework, Terminology and Design Process

As already discussed, there are different planning frameworks and various approaches to the use of the LFA. In different countries, people will have had experience with different models and be used to a particular set of terms. It will help everyone if early on in the design process there is agreement about the approach to planning that will be followed, how the logframe will be used and what terminology will be used. Also define clearly what the design process will be, in terms of who will be involved, how and at what stage; what information needs to be gathered and how; and how the final design will be checked with key stakeholders. Box 3-10 lists key elements of participatory design based on IFAD experiences in Asia. This "designing the design process" step is often given very little thought and is the source of many problems that emerge during design and implementation.

Situation analysis involves learning as much as possible about the project context and the interests and needs of local people in order to design a relevant project. This learning is best done with several groups of stakeholders. Box 3-11 provides a list of key situation analysis topics, questions and useful methods.

The standard LFA focuses project planning on developing a problem tree for the situation. A problem tree works well for simple situations. However, problem-based planning fits with a more mechanical approach to development where projects are designed to "fix" problems rather than to facilitate local development processes. Furthermore, people see their future in terms of visions and aspirations – not just as problems. Analysing future visions helps identify opportunities for improvement and of successes that can be further developed. The LACOSREP water users’ association (WUA) programme in Ghana developed four complementary visions to describe the ideal WUA that they were aiming to help create.

A good situation analysis will combine information gathering and analysis about the local context, expert advice and participatory processes such as participatory appraisals, community meetings and multi-stakeholder workshops. A creative and learning-oriented situation analysis will combine several methods (see Annex D).

One result of a good situation analysis is that stakeholders have more insights about their situation and have better capacity to design a solid project. However, this will not be achieved in one community meeting. People’s perspectives evolve as they debate and listen. After a community meeting, subsequent discussion in people’s homes might have lead to adjustments if a meeting were held the following day. Take care that the situation analysis is designed as a series of events.

Updating the situation analysis is critical for the M&E system. Note that a situation analysis is not the same as a baseline survey. Both are information-gathering exercises. But a situation analysis is more open-ended in terms of the themes and questions that are analysed, while a baseline survey only includes data that are needed to make impact-related comparisons. A baseline survey is undertaken after project design has been completed, while a situation analysis is undertaken as part of design.

3.4.4 Step Four: Develop the Project Strategy

With a good understanding of the situation, you are now ready to start developing the project strategy. This simply explains clearly what everyone hopes to achieve and how it will be achieved. A project strategy includes the objective hierarchy, implementation arrangements and resources required. This sub-section focuses on the objective hierarchy – column one of the logframe – central to the strategy. The objective hierarchy is a tree-type structure that maps out how activities and outputs contribute to the project purpose(s) and goal (see Figure 2-4 and the method description in Annex D).

A project strategy will only work well if it is logical. This means that all the outputs required to achieve a particular purpose have been correctly identified and, in turn, that all the activities needed to deliver an output have been identified. For example, you cannot have as your output "production and certification of seed of improved varieties", without also including "testing and setting up private production of seed" and "training of ministry of agriculture staff for certification" as activities. Once the objective hierarchy is drafted, the logic needs to be tested (see Table 3-4).

The standard LFA uses a very structured method of converting a problem tree into an objective tree or hierarchy. When working with project visions and in more complex situations where the problem tree becomes unwieldy in size, you could use a more open and iterative approach. The main steps in developing an objective hierarchy are outlined below and described in Annex B with a detailed example.

1. Define the project goal. This should reflect the longer-term and highest-level impact to which the project will contribute.
2. Identify the purpose(s). This is what must be achieved by the project in order to contribute to the goal. The purpose level generally describes major changes in behaviour or capacity. Because a project can contribute to the goal in many ways, the stakeholders will need to decide what is most worthwhile and feasible for this particular project. It helps to establish criteria to help make these decisions. It is good practice to include a separate purpose for project management. Here, key project management tasks can be included as outputs (see next step), such as staff management, financial management, plant and equipment maintenance, and M&E.
3. Establish necessary outputs. For each purpose, identify what outputs are necessary for the purpose to be achieved. Think of it a bit like designing a car. If a key part is left out, like the wheels or the engine, it will not matter how good the rest of the car is – it still will not work. Also you do not want tractor wheels on a car or a motor-bike engine in a big tractor. In other words, make the outputs fit the real needs and avoid outputs that are not absolutely necessary. Any purpose can be achieved in several ways. Think creatively and analyse the advantages and disadvantages of different options before making a choice.
4. Identify activities. Each output is delivered via a set of activities. At the initial project design stage, the best way of achieving purposes and outputs may be unclear, so activities may need future finalization and probably revision.
5. Check the logic. Once the objective hierarchy has been drafted, use the logic testing questions in Table 3-4 for checking and finalisation.
6. Allocate resources required for activities and develop an overall budget.
7. Develop a work schedule for the main activities over the life of the project and establish key milestones.
8. Establish the management and operational arrangements, with key responsibilities and working procedures.