An Overview of Linking Project Design, Annual Planning and M&E
When you "manage for impact", project design,
annual planning and M&E become linked processes. Your starting point
for implementation is the initial project design as outlined in the
project appraisal report. But design is an ongoing process for the life
of the project. Continually adapting the project strategy in response
to new understanding and to changing contexts is key in maximising impact
on rural poverty. So, good project design is as important for managers
and M&E staff as for the initial design team.
Key aspects of a projects design are built into the project
loan agreement. Changing these can be difficult and time consuming.
Thus it is critical that the initial design be as high quality as possible.
In addition, the initial design team must build in flexibility to allow
changes at project start-up when the design is revised. The PROCHALATE
project in El Salvador learned the importance of rethinking the design
the hard way. Staff there estimate that they could have prevented the
loss of two years at the beginning if implementers had had better understanding.
3.1.1 Project Design as an Ongoing
Why is change to the project design necessary? First,
many projects start up to several years after initial design, during
which the context will have changed. The project cycle (see Section
1.4) includes the many steps that lead to start-up, each of which takes
time. Second, the initial design of IFAD-supported projects is undertaken
with limited time and resources. Many of the implementing partners will
not have been identified and so there will have been limited participation
in the process. This means that a comprehensive participatory process
of reviewing and, where necessary, improving project design is critical
at start-up. After start-up, the two main opportunities for improving
the project design are: (1) on an annual basis as part of the annual
progress review and planning process and (2) during the mid-term review
(MTR). Table 3-1 lists the design and adaptation
tasks during the projects lifetime, showing how (re-) design is ongoing.
Table 3-1. Design and adaptation
tasks at key moments during the project lifetime
Initial design phase
- Assess feasibility, scope and
rationale of project.
- Determine the goal and objectives.
- Outline main project outputs and key activities.
- Outline project implementation process and structures.
- Outline the M&E system.
- Develop the budget and specify staffing levels.
- Develop understanding of project
goals and objectives with key stakeholders.
- Review and revise the initial design.
- Design and plan work in sufficient detail to allow for implementation.
- Develop a detailed operational M&E system.
Annual review of the
work plan and budget
- Check if the outputs,
purpose-level objectives and goal remain relevant; adjust.
- Decide what activities and tasks are necessary to deliver
- Discuss overall progress
of the project.
- Decide on changes that should be made in the annual
- Assess any potential changes in the overall design
that require loan agreement negotiations.
End of the early implementation
- Review overall project strategy
in light of early implementation experience.
- Develop recommendations for the work plan in the next
- Negotiate any significant changes to project design
for the next phase.
Mid-term review (or
reviews between phases if the project has a flexible lending
- Review achievement
of outputs and progress towards the purpose(s) and goal.
- Assess appropriateness of the overall strategy.
- Redesign the project as necessary.
Beginning of the phase-out period
- Identify the priorities of final
activities in order to maximise impact.
- Review and adjust strategies with a view to sustained
3.1.2 Good Practices for Project Design
There are six good practices in any design process of
a development intervention. They are critical during formulation and
start-up and when any revision of the project is undertaken, such as
during annual and mid-term reviews.
1. Involve all relevant stakeholders in participatory processes of project
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 peoples 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
- 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
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 projects 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.
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
3.2.1 Involve Stakeholders in Project
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
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
hadnt been made up front, much money would have to have been spent later
for one-way information campaigns before and during project implementation.
Box 3-1. Community participation in the
project design process
When the irrigation specialist of Zebilla District, Ghana, shared
his plans for the rehabilitation of the earthen dam and irrigation
network in the village of Saka, the village water users association
(WUA) quickly sent him back to the drawing board! Many years before,
when the dam was first constructed and functioning, the village
had established a substantial mango orchard directly below it. Even
though the dam had not been working for the past 17 years, the mangoes
had continued to produce each year. With the start of the IFAD-supported
LACOSREP project, the villagers had formed self-help groups, elected
a WUA and requested their dam to be rehabilitated under the project.
The projects irrigation specialist then recommended cutting down
most of the mango trees to make room for an expanded irrigation
scheme just below the dam. The community objected, as the mangoes
were valued, especially during the dry season. One older man explained,
"With the mango trees, I know that my children will have something
to eat during the lunch break at school." The villagers suggested
extending the canal beyond the mango orchard instead. This way,
not only would the orchard be saved, but the canal would expand
the amount of cultivable, irrigated land.
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.
Box 3-2. List
of questions to outline multi-stakeholder-level strategy for the
PIDP project in Tanzania
Farm Household Level
* What is the present situation of the farm household?
* What does the future, improved situation of the farm households
* What changes have to be undertaken at farm household level?
* What support do farm households need?
* What support do farmers and members of the water users
* Who is to provide the support?
Water Users Association
* What is the present situation of the WUA?
* What does the future, improved situation of the WUA look like?
* What changes have to be undertaken at the level of the WUA?
* What support do the WUAs need?
* Who is to provide the support?
District Councils (DCs)
* What is the present situation of the DCs?
* What does the future, improved situation of the DCs look like
in terms of mandate, structure and services offered?
* What changes have to be undertaken at the level of the
DC and district-level project management unit?
* What support do DCs need?
* Who is to provide the support?
* What is the present situation of the PCU?
* What does the future, improved situation of the PCU look like?
* What changes have to be undertaken at the level of the PCU?
* What support does the PCU need?
* Who is to provide the support?
Stakeholder participation in design is not limited to working
with local communities or valuing their views above others. The idea
of a "community" that one consults is quite simplistic and
can cause problems. For example, if implementing partners or project
staff consult a community, will all local voices be heard? Which ones
will unintentionally be forgotten or ignored? Also, what is good for
one community is not necessarily good for another or for its region.
So which community will you listen to if they have differing opinions?
Understanding differences within and between local communities means
listening, listening and listening again and working together. Only
then can you gain insights into local relationships and interests. Some
people think that illiteracy and geographic isolation of target groups
makes participation impossible. But many examples show how including
the poorest, most isolated and illiterate of groups is possible with
some creativity and time (IFAD/AGNGOC/IIRR 2001 publication, see Further
Reading). Good participatory processes involve sharing perspectives
and negotiating differences. Stakeholders can be involved in many ways,
including comprehensive participatory rural appraisal (PRA) processes,
informal discussions and planning workshops. However, peoples physical
presence is not enough. Some very poorly designed projects have included
many local people who did not participate freely. Ensuring high-quality
participation is key and will require creating project structures that
can respond to peoples requests (see Box 3-3).
Box 3-3. New project structures in Colombia
to create space for participation
The PADEMER project in Colombia negotiated several
recommendations when refining the project at start-up: 1) changing
focus from supply to demand, wherein project activities start
with a participatory process of identifying rural microenterprise
demand for services, 2) introducing competition through open tenders
for service delivery, and 3) forming regional groups for selecting
and prioritising projects, with primary stakeholder representatives
invited to assist in selecting and supervising service delivery
Good project design requires questioning, sharing and negotiation.
This happens when good information is available and when differing perspectives
between community people, scientists, NGO staff and government officers
are discussed openly and negotiated. Planning workshops with stakeholders
are important, and a good process, understood by all, will help achieve
a valuable outcome. Some projects focus on a single workshop. This creates
pressures; and agreements may be made that do not make much sense afterwards.
It might be tempting to think that, because such outputs came from the
stakeholders during the workshop, they are "correct" and cannot
be changed. However, people learn by participating in dialogue. The
views they held in one meeting might change. The next day, after having
had a chance to reflect and discuss with others at home, they might
see things quite differently. So rather than a one-off workshop, it
is better to hold a sequence of events where peoples ideas can be shared
and merged, and informed agreement can be reached (see Box
Box 3-4. A workshop process for participatory
logframe design in Uganda
Ugandan project staff recommend the following workshop
process for developing the logframe. At the beginning, they draw
a diagram that shows the process in terms of steps to be undertaken
through the workshop. This includes scanning the project environment,
developing the vision, mission, goals and purposes (impacts) for
the project, and then filling in the details of outputs and activities.
By referring back to the visual diagram of the workshop process,
participants can see the progress they are making in working through
the LFA steps. The workshop lasts about two to three days. At
the end, participants find they have worked through the whole
logframe matrix themselves.
3.2.2 Be Clear about Cross-Cutting Issues: Poverty,
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 CACBs
(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).
Box 3-5. Definitions in
an organisational context
In one project area in North Africa, the president
of a rural community, who also worked in local government, was involved
in linking project staff and local people. He found it difficult
to justify investing the limited project resources only in poor
households. Instead, he tried to spread out project resources to
as many people as possible, especially those who were motivated
and capable of completing what the project had started. He explained,
"For the land rehabilitation work, we have the resources to
remove stones on one hectare of land per household, so we choose
people with more than one hectare who will be able to remove the
stones from the rest of their land with their own resources."
People with more land and capacities were not the poorest, but the
strategy was understandable. The local government, in which he worked,
had the mandate to organise service delivery for the majority of
citizens rather than to the project target of only the poorest.
3.2.3 Plan for Capacity Development and
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. Participation and
capacity-building for sustained impact
The Cuchumatanes project in Guatemala worked with
organised farmers: formal organisations, interest groups and communal
banks. In 1998, a primary stakeholder committee was created to strengthen
their participation in project management. It supervised field activities
and collected primary stakeholders claims. When the project finished
in 2000, the primary stakeholder committee became an association
called the Association of Organisations of the Cuchumatanes
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 Nepals 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.)
Performance Indicators in the Project
Infrastructure programme implemented
- Rural infrastructure schemes identified, constructed and maintained
by disadvantaged groups on a demand-driven basis
- Infrastructure-related policy developed and enforced that
benefits the disadvantaged
| Number of small-scale
or micro irrigation schemes constructed/rehabilitated and maintained
Kilometres of trails and number of bridges constructed/rehabilitated/maintained
Number of community facilities (including storage facilities)
constructed and maintained
Number of water supply and sanitation schemes constructed/rehabilitated
Number of disadvantaged groups successfully expanding irrigated
area and the per cent by which the irrigated area increased
Kilometres of rural roads constructed/rehabilitated and maintained:
Per cent of labour for earthworks provided by the target group
identified by the communities and social mobilisers: 70 (of
which at least 50% are female)
Number of disadvantaged people employed through component
Rural infrastructure constructed or rehabilitated
- Number of primary stakeholder households served by new domestic
water supplies: 25,000
- Kilometres of rural road network upgraded to class 4: 198
- Number of villages supplied with electricity: 67
- Number of household biogas systems installed: 22,500
Including a capacity-development perspective has implications for policy,
as existing policies can be questioned when local people take more charge
of their own situation. By explicitly linking project activities to
specific policies, the project team has the opportunity to engage and
provide feedback to policy makers. The ADIP project in Bangladesh found
this when it aimed to implement the governments New Agricultural Extension
Policy. In the process, the project created opportunities for informing
government on the policy itself. This link has two advantages: providing
primary stakeholders with a voice at policy level and ensuring that
local capacity-building stays in tune with the current policy outlook.
Good capacity-building is essential for sustained impact. Three points
need particular consideration.
- A broad base. Capacity-building must include not only primary
stakeholders but also other key stakeholders, particularly local government
(see Box 3-8).
- 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.
- Sensitivity in M&E. Tracking and evaluating capacity development
is particularly sensitive because it focuses on people and makes judgements
about their activities.
Box 3-8. From project focus to supporting
The terms of reference for M&E expertise in Ugandas
District Development Support Project (DDSP) focused only on the
project. Staff recognised that this could easily be changed to become
a local government M&E framework that benefits the district
as a whole. For the consultant to contribute to the district, and
not just the project, he/she should:
know and understand the local government system
work closely with the DDSP team to create a multi-level,
multi-stakeholder M&E system for the planning, allocation
and implementation needs of the local governments. This would
include mentoring the district planning units and other departments
to help their partners/other stakeholders develop their own
indicators for the M&E of local government services;
work closely with the efforts of other agencies
in developing M&E systems for local governments;
ensure that the roles and responsibilities fit
within existing local government/authority roles and responsibilities
(so as not to create unsustainable committees, organisations
have documentation and dissemination skills to
assist local governments to develop communication strategies
for meeting their constituencies learning and information needs;
for example, assist by documenting the local governments M&E
framework for wider dissemination and use by other districts
In this way, there can be a shift in focus from short-term
project learning to the development of longer-term institutional
3.2.4 Plan for Learning and Adaptation
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
- 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.
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.
- Be as clear as possible about what you are trying to achieve
and how it will be achieved.
- Decide how you will know if you are achieving your objectives and
put in place a monitoring system.
- 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.
Box 3-9 Usefulness of the logframe, as
seen by primary stakeholders
When members of the water users association of the
PIDP project in Tanzania were asked their opinions on the logical
framework approach, they gave the following comments:
- "It makes planning easier."
- "Now we have a plan for the year. It helps us in scheduling
- "With this kind of meeting [LFA process] we get time to
sit together with the technical staff and the farmers to talk
about our problems and the solutions to our problems. It is a
teaching approach to solving problems."
- "It was difficult to understand in the beginning. But
then when you understand, it is easy for planning."
- "Unlike the first projects [previous development projects],
now we have indicators so that we are able to judge our achievements.
The problems from the first project had been continually carried
over until now."
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
- establish the general scope or focus of the project;
- agree on the specific planning framework, terminology and design process;
- undertake a detailed situation analysis;
- develop the project strategy (objective hierarchy, implementation
arrangements and resources);
- identify and analyse the assumptions and risks for the chosen strategies,
modifying the project design if assumptions are incorrect or risks are
- 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
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
- what the project should achieve, from the level of an overall goal
down to specific activities;
- the performance questions and indicators that will be used to monitor
progress and overall achievement;
- how these indicators will be monitored or where the data can be found;
- 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)
(Narrative summary, intervention logic)
(Objectively verifiable indicators, indicators, targets)
(Means of verification, sources of information)
Assumptions and Risks
(Overall objective, development objective)
The long-term objective, change of state or improved
situation towards which the project is making a contribution
How to write it: put the verb in the past
tense, as something already achieved over the long term
and Indicators at goal level high-level impacts
information will be gathered
sustainability of the project
(Project development objective)
The immediate project objective, the overall
observable changes in performance, behaviour or resource status
that should occur as a result of the project
How to write it: put the verb in the present
or past tense as if already achieved
and indicators for each purpose (component) lower-level impact
and outcome indicators
information will be gathered
moving from purposes to goal
The products, services or results that must be
delivered by the project for the component objectives and purpose
to be achieved
How to write it: put the verb in the present
or past, as if already achieved
and indicators for each output output indicators
information will be gathered
moving from outputs to purposes
The actions taken by the project that are required
for delivery of the outputs
How to write it: put the verb in the infinitive,
as something to do
the needed inputs go here, not indicators for activities
in moving from activities to outputs
When using the logframe flexibly for IFAD-supported projects, two issues
are important: (1) knowing how to use the matrix for large projects
or programmes and (2) making sure outcomes are adequately considered.
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.
- The project is oversimplified to such an extent that the matrix provides
insufficient detail for effective management or M&E.
- 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.
- Insufficient detail is given at the purpose level in defining the
outcomes needed to guide the project strategy towards impact (see Section
You have three options for overcoming these problems (see Table
- 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".1 Many projects already implicitly
or explicitly work with this idea but do not include it in the logframe
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 womens 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
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
Type of Structure
Four levels: 1
x goal, 1 x purpose, any number of outputs, any number of activities
- Is very simple.
- Is commonly used and understood.
larger, multi-component projects.
- Does not make project outcomes clear.
Four levels: 1
x goal, as many purposes as needed, any number of outputs per
purpose, any number of activities per output
- Maintains the
standard four levels of the logframe matrix.
- The standard
is one purpose, so this may cause confusion.
- Confusion between purposes and outcomes can still occur.
standard four-level logframes; each project component written
up in a separate logframe; the purpose level = the component objective
- Maintains the
standard four levels of the logframe matrix.
- Enables a focused, "sub-project" approach to management.
- Doesnt give
an overview of cross-cutting objectives.
- Focusing on integrative impact is difficult.
- Is more complex.
Five levels: 1
x goal, 1 x purpose, any number of key outcomes (or component
objectives), any number of outputs per outcome, any number of
activities per output
- Makes a clear
distinction between output, outcome and purpose levels, facilitating
- Is consistent with standard LFA.
- Some donors already use it.
- More detail has
to be included in the logframe matrix.
Recognising the Importance of Outcomes
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.
3.4 Using the Logical
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.
Box 3-10. Weaving together
a participatory design phase (based on IFAD experiences in Asia)2
- Establish a mentoring team a group of committed, experienced
and respected nationals who, on a voluntary basis, act as resource
persons to advise the formulation process and champion the goals,
strategies and approaches proposed by the project.
- Undertake a participatory stakeholder analysis through a process
of brainstorming with groups/individuals/institutions, grouping
stakeholders, assessing their interests and impact on project
success, assessing their influence and importance for project
success, and outlining a strategy for their participation.
- Establish the design team with national specialists from different
professional sectors, relevant NGOs and government agency staff.
- Train the design team in the use of diagnostic participatory
tools and in drawing implications for project design from qualitative
discussions with groups of stakeholders.
- Review secondary data and key informant interviews.
- Formulate the study design and analysis plan based on the
information gaps you have identified.
- Divide the project area into study zones, by identifying a
number of relatively homogenous agro-ecological areas.
- Undertake village-level problem identification and needs assessment
through focus-group meetings and household interviews:
- Assess problems: discuss problems, issues and concerns
of villagers; assess causes and effects; identify which
issues could relate to the project being planned; agree
on criteria for prioritising problems; and prioritise problems.
- Analyse options: discuss strategies and options proposed/desired
by the community to overcome the problem situation.
- Analyse alternatives: agree on criteria for comparing
options to overcome problems and realise visions, then identify
and assess alternative strategies/options available to reach
the desired objectives.
- Undertake a cross-cutting analysis, by agro-ecological zone
and socio-economic stratum, to integrate analyses from different
- Hold design workshops involving different levels of stakeholders
to work together on the logframe matrix:
- Summary of objectives (objective hierarchy): develop project
concept, vision, mission, results and activities.
- Indicators: together identify which indicators capture
and measure the different levels of changes the project
is anticipated to affect.
- Means of verification: agree on the sources of information
to be used for monitoring impact.
- Important assumptions/external factors: discuss the attitudes,
behaviours, processes, trends, natural hazards/disasters,
etc. outside the control of the project that could affect
it positively or negatively.
- Conduct continual surveys of primary stakeholder opinions
to ensure that the consultation process and the interim results
are as good as possible.
- Hold national-level project reality-check and planning workshops
to which a wide range of (primary) stakeholders are invited
and during which initial ideas are presented and debated to
consider different realities.
- Draft the project proposal, based on workshop outputs, with
a team of national and international experts.
- Verify the draft project outline with the key stakeholders,
particularly the intended primary stakeholders, in a series
of discussions or workshops.
3.4.3 Step Three: Undertake a Detailed Situation
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
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.
Peoples perspectives evolve as they debate and listen. After a community
meeting, subsequent discussion in peoples 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.
Box 3-11. Key themes, questions and methods
(italicised, see Annex D) for a thorough situation analysis with
Stakeholders (stakeholder maps, institutional diagrams,
- Who are the local people likely to benefit from the project?
- Who are the other key stakeholders?
- How do different stakeholder groups interact?
- What are the power relations between different groups?
Problems and Issues (rich picture, conceptual maps, focus
group discussions, historical analyses, secondary data, matrix ranking)
- What problems or issues are central to the focus of the project?
- What are the main problems or concerns of the different stakeholder
groups and how do these relate to the focus of the project?
Visions and Opportunities (rich pictures, role plays)
- What changes would different stakeholder groups like to see
the project bring about?
- Generally, what visions, hopes or dreams do different stakeholders
have and are there implications for the project?
- What opportunities do stakeholders see for realising their visions?
Biophysical Setting (maps, transects, field visits, seasonal
- What are geographical characteristics of the project areas?
- What are the climatic conditions?
- What are the main forms of land use?
- What are the environmental problems or risks?
Organisations (institutional diagrams, network diagrams,
flow charts, matrix ranking)
- What are the important government, business and NGO organisations?
- How effectively are these organisations performing?
- How are the different organisations linked together (power relations,
communications, joint work, competitors)?
Infrastructure (resource maps)
- What are the key infrastructure issues for the area?
Law, Policy and Political Institutions (rich pictures,
institutional diagrams, historical analyses, focused interviews,
- What legal factors are significant for the project?
- What government policies and programmes are significant?
- What are the main government and political structures and processes
in the area?
Economic (wellbeing ranking, daily activity charts, seasonal
calendars, livelihood profiles, secondary data)
- What is the economic situation of local people?
- What are the main forms of economic livelihood?
- What are the key characteristics of the local economy?
- What are the market opportunities and constraints?
Social and Cultural (historical analyses, focus group
discussions, SWOT analyses)
- What are the main social and cultural conditions relevant to
3.4.4 Step Four: Develop the Project
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
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.
Table 3-4. Logic testing questions
- Define the project goal. This should reflect the longer-term
and highest-level impact to which the project will contribute.
- 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.
- 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
- 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.
- Check the logic. Once the objective hierarchy has been
drafted, use the logic testing questions in Table 3-4
for checking and finalisation.
- Allocate resources required for activities and develop an overall
- Develop a work schedule for the main activities over the life
of the project and establish key milestones.
- Establish the management and operational arrangements,
with key responsibilities and working procedures.
Logic Testing Questions
- Does the goal express some future
desired state or higher-order impact towards which the project
- Does the goal help place the project in a wider context that
provides the rationale for the project?
- Is the goal narrow enough that it is meaningful given the scope
of the project? Avoid goals expressed at an excessively general
- Is the goal something owned and shared by relevant stakeholders?
(if a single
- Is the purpose a succinct statement
of what the project will achieve overall?
-Is the purpose realistic given the resources, time span and
working context of the project?
(if multiple purposes)
(if an extra level is included)
- Are the outcomes/component objectives
the set of main outcomes necessary to achieve the purpose? In
other words, if the outcomes/component objectives are achieved
will the project purpose be achieved?
- Do the purposes/outcomes/component objectives reflect the highest-level
achievements of the project for which it can realistically be
- Are the purposes/outcomes/component objectives realistic for
the project to achieve during its lifetime?
- Is there a set of practical actions that can be carried out
to achieve each purpose/outcome/component objective?
- Is one of the purposes/outcomes/component objectives dedicated
to effective project management?
- Do the outputs together describe
the set of achievements that must be realised for the outcome/component
objective to be realised? In other words, if the outputs are achieved
will the outcome/component objective be achieved?
- Are any outputs unnecessary to achieve the outcome/component
objective or logically belong under another outcome/component
- Are the outputs realistic for the project to achieve during
- Is there a set of practical actions that can be carried out
to achieve each output?
- Do the set of activities for each
output reflect the main actions that must occur for the outputs
to be achieved?
- Are any activities included that are unnecessary for achieving
the outputs or that logically belong under another output?
- Are there any activities that need to be split up and partly
allocated to different outputs?
- Are the activities all roughly equivalent in terms of their
level of detail? In other words, are you sure that some activities
are not more at an output level while others are at a task level?
- Is the list of activities manageable (not too long)?
For all levels
- Are all levels understandable to
project stakeholders and expressed as plainly and succinctly as
- Are any unnecessary means of achievement included?
- Are there between three and about seven items for each of the
(outcome/component objective, output and activity) levels?
Developing a good project strategy does not happen in one
go from top to bottom. You will need to return to earlier steps as thinking
becomes more detailed. For example, when you start thinking about the
cost and practicality of some activities you might realise that some outputs
and purposes might be unrealistic. Box 3-12 lists
some mistakes to avoid when drafting the objective hierarchy.
Box 3-12. Common mistakes
to avoid when formulating the objective hierarchy
Defining overly ambitious goal/purposes, given
local conditions and available resources and capacities
Overlooking key activities and outputs that are
needed to achieve higher-level objectives (outcomes/purpose/goal)
Poor logic as to why particular activities are
needed for a certain output or particular outputs for a certain
Objectives expressed too vaguely to know what
will be achieved or how to implement ideas
Inclusion of principles, such as "stakeholder
participation" or "gender equity", as separate
purposes or outputs, instead of integrated into project activities
Confusion in the levels of the objective hierarchy
As far as possible, make each level in the objective hierarchy
SMART (see Box 3-13). Remember that the logframe
is only a summary of a more detailed description and justification for
each level of the project strategy in the appraisal report. Try to make
each statement in column one of the logframe as specific as possible.
Additional targets can also be included as indicators in column two of
the logframe. To avoid blueprint planning, remember that outputs and purposes
are not only physical, such as roads, irrigation schemes or yield increases,
but also include dialogue processes and capacity development. You can
include approximate targets and explain that these will become more precise
after the participatory planning processes at start-up that will lead
to clearer understanding of primary stakeholders priorities.
Box 3-13. Ensuring you have SMART objectives
The goal, purpose, component objectives, outputs and activities
should be SMART if they are to be impact oriented:
Relevant (to the project purpose and goal)
But dont get too SMART!
- What is achievable may need to be developed from experience.
- Good ideas take time to develop.
- Not everything that is worth doing can be easily measured.
The project strategy is something with details that evolve
over the life of the project. For example, at start-up a more detailed
project strategy is necessary than for appraisal, and even more detail
is required for an annual work plan and budget.
Developing a clear, logical and feasible project strategy
is worth all the time and analysis that is invested. Very often project
staff understandably are impatient to "get started". However,
if actions are based on a shared clear understanding of the project strategy,
then they will be more easily directed towards achieving the desired impact.
Without this understanding, team members may end up doing good but isolated
bits of work that do not reinforce each other. For example, in one Indonesian
project, both a logframe and a work plan were produced, but they bore
little relationship to each other and the logframe was therefore not used
optimally by the project.
3.4.5 Step Five: Identify and Analyse
Assumptions and Risks
Assumptions, in the fourth column of the logframe, are
the logframe "orphan" (see Box 3-14). They
often receive little serious thought or time. Yet assumptions are the
very backbone of the project strategy. They specify the necessary conditions
(if-then relationships) outside the direct management control of the project
that must exist for the project to achieve its objectives. They are fundamental
to the overall logic of the project and therefore to project success (see
Section 2.3, Box
2-9). Ideally, think about assumptions as you develop the objective
hierarchy and do this again with the full draft.
Assumptions are only important when they describe conditions
that if they do not occur may jeopardise the projects success. Many
logframe matrices only note assumptions that are extremely obvious, general
and often very probable, such as: "national security maintained",
"free market policies", "foreign exchange bottlenecks",
"limited flexibility of government administration" and "environmental
degradation". These are not useful for giving strategic guidance
to a project.
Box 3-14 Assumptions column:
the "rubbish bin"
According to an M&E consultant in Uganda, the assumptions column
of the logframe is like "the rubbish bin where everything goes".
Instead of dealing with them as an integral part of the project,
design teams tend simply to throw all the institutional aspects
in this column. This means that such issues are not dealt with by
the project staff who then see them as being beyond project control.
More time is needed in the planning process to analyse the assumptions
and think about what could be done with them.
Most projects recognise the importance of assumptions that
show up as problems during project implementation. Many of these can be
identified during project design, helping improve it. They are not recognised
when a situation analysis is absent, has not been thorough or has not
been analysed well enough to tease out the underlying assumptions. For
- In one project, one of the main targets was "non-rice cropping
area increased by 10%". It was only during implementation that
the project became aware that the target group of small farmers did
not have access to any additional land for planting such crops. Verdict:
poor situation analysis.
- Another project had the output "radio programs developed and
aired" and as an assumption "communities have access to
radio media". Communities did not, in fact, have radios. Verdict:
poor situation analysis.
In both cases, the assumptions should have been checked out before the
outputs were affirmed. If they had been, and it had turned out that the
communities did not have necessary access to land or radios, the outputs
would either have been thrown out or redesigned. For instance, in the
latter case, outputs might be redrawn to provide radio access and the
extra budget this would require.
Risks are the reverse of an assumption. One look at the
assumptions for a project will give an idea of the level of risk that
the project is taking. The more assumptions there are, the more improbable
they are and the more they are out of the projects control. This makes
the risk of project failure higher. One project had as an assumption "the
annual rainfall is above the annual average for the region." If project
success is based on this assumption (which may have been developed in
haste without much thought), then it is certainly a high-risk project.
Good M&E needs clear, valid assumptions. When a certain objective
is not realised or problems occur, you will often find a faulty assumption
is the cause. Part of good M&E means keeping a close check on the
validity of assumptions. Here are a few tips to make assumptions a useful
Figure 3-1. Deciding which assumptions are important
- Think of assumptions first as risks. When identifying assumptions,
you might find it helpful to start by thinking of possible risks to
the project. For example, if you think that a risk for the project is
"non-delivery of contracted services on time by project partners",
then this would appear in the logframe matrix as "project partners
will comply with their contracts on time".
- Consider assumptions about: performance of public agencies,
performance of private organisations, performance of NGOs/CBOs, performance
of contractors/consultants, performance of funding agencies, policy
environment, natural events, world or domestic markets and prices, and
- You cannot observe a large number of assumptions. Limit the
number of assumptions to only those that are most critical for success.
After listing all possible assumptions, filter out those that are not
important to project success and those that are almost certain so dont
demand monitoring. A useful method for assessing the importance of assumptions
is through the use of a risk assessment analysis (see Figure
- Focus on those assumptions about whose probability you are uncertain.
Such assumptions need to be monitored as they may seriously endanger
the project if they turn out not to be true. Examples of such assumptions
from project logframes include: "larger lessees are cooperative",
"primary stakeholders will be effective in the management of their
newly acquired land", "climate fluctuates within normal ranges"
and "community abides by fishery regulations on size of nets".
- Check that the assumptions are clearly outside the control of the
project. Use a decision tree for this (see Figure
3-1). The process of formulating assumptions is very important.
It helps in checking that the project strategy is on course to achieve
its purpose, having considered in its design as many components as possible
that assumed factors might affect. If you realise that assumptions can
fall within the control of the project, you can use them to indicate
additional outputs and activities in the logframe matrix. The following
assumptions, taken from IFAD-supported projects, could all have been
tackled as part of the project strategy: "department of agricultural
extension staff motivated", "nutritious feed available"
and "monitoring reports are based on contextual analysis".
- If important assumptions are very unlikely to be true, then these
are "killer assumptions". The project must be redesigned
to remove these assumptions. An example of a killer assumption is: "training
of extension agents will lead to more uptake of new technologies by
farmers". This cause-effect assumption needs to be dealt with by
the project because it is, in fact, very unlikely that lack of knowledge
is the key constraint for extension agents (you dont know if you have
enough people whom you could train nor if they are the right people).
It is also extremely likely that farmers face many other constraints
to the uptake of technologies, not just extension agents knowledge.
- Revisit your assumptions regularly, at least during the annual
review, to adjust or remove those that are no longer valid and add those
that have emerged. A reflective participatory project will formulate
new assumptions as the strategy changes and initial results become clear.
Compare your M&E data to the assumptions to see if there are contradictions
that need to be removed. For example, you might assume that a 25% increase
in household income would lead to less illegal firewood collection.
When the monitoring data show that incomes are up by 35% and such firewood
collection is still at the same level, then you need to rethink the
project logic if you want to reduce deforestation. Increased local purchasing
power could be stimulating the demand for more firewood. You can probably
conclude that "increasing incomes" is not the best strategy
for "reducing illegal firewood collection".
3.4.6 Step Six: Develop the Monitoring
and Evaluation Framework
The final step is to develop the monitoring and evaluation
framework for the project. The key performance questions and indicators
are summarised in column two of the logframe and the main monitoring mechanisms
in column three. However, remember that this is only a summary of the
overall M&E framework. The details of setting up the M&E system
are the subject of the remainder of the Guide so will not be discussed
3.5 From a Logframe
Matrix to an Annual Work Plan and Budget
Translating a project strategy, as worded in the logframe
matrix, into an operational annual work plan that is clear to project
staff and partner organisations transforms ideas into actions. An operational
plan is detailed enough when staff and implementing organisations know
what they are expected to do, when and how.
3.5.1 What is the AWPB?
The most important operational and planning tool of a project
is the annual work plan and budget (AWPB). The AWPB guides daily implementation
- Work plan: a logframe-based description of each activity/output/indicator
- Schedule or time plan: specifying when activities are to take place
and in what order;
- Budget: identifying the cost of each output and activity per component;
- Personnel plan: identifying responsibilities, additional staff needs,
- Material/equipment plan: requirements for each output and activity
per component, including procurement.
The AWPB describes the annual commitment of the project towards the communities,
the government and IFAD. The AWPB is normally integrated into ongoing
government budget processes. With that, the AWPB has acquired legal endorsement
and forms the formal base for implementation and release of funds (for
IFAD funds and counterpart contributions). In some countries, immediately
after AWPB approval, required counterpart funds are released to the project.
The AWPB process is usually initiated before the fiscal year ends and
is based on experience gained at the field level during implementation.
With the detailed AWPB, the importance of the project appraisal report
fades away over the projects lifetime. After the first year, it is no
longer useful for planning, except for general guidance on objectives,
principles and approaches. The project appraisal report does, however,
remain an important evaluation reference point, as AWPBs do not include
references to long-term objectives and general principles.
The AWPB sits within the framework of the loan agreement, which can be
amended when required. Changes come from the experiences of all project
participants, who prepare the AWPB based on experiences and actual performance
results. The first AWPB usually relies on the project appraisal report,
updating details such as prices and actual requirements. Subsequent AWPBs
are best when prepared during a participatory review and planning workshop
process. Communities and project and partner staff jointly review performance
of the past year. The outcomes of these discussions form the basis for
participatory, goal-oriented planning for the next AWPB.
In an increasing number of projects, AWPBs are preceded by participatory
appraisals during which primary stakeholders with the guidance of project
staff, identify their communitys needs, resources and priorities. These
form the basis for "community action plans" that are the building
blocks for higher-level plans (e.g., district or ward) from which the
project derives its AWPB (see Box 3-15).
The AWPB not only guides the project for a year but is also the mechanism
by which the project can review the experiences of the previous year and
make modifications accordingly. It adapts the projects operational plan
to the current situation and specifies for the year: the outputs to be
achieved, the activities to be undertaken to achieve these outputs, the
resources required to undertake the activities and the costs of these
resources as well as the institutions with financial responsibility. The
AWPB should be the basis on which IFAD, the cooperating institution and
project participants will assess implementation progress.
3.5.2 reparing the AWPB
To prepare the AWPB, information is drawn from the project
appraisal report, the loan agreement, any specific strategic plans, and
plans and reports of previous years. AWPBs are produced for each level
of participants in the project, starting with the project primary stakeholders
according to their needs and demands using a bottom-up participatory process.
At the highest level, preparation of the AWPB should be made just before
government funding allocations for the following fiscal year, to give
a clear indication of the funds required by the project. To develop an
AWPB, here are some basic steps (also see Box 3-15):
- Take the activities from the revised project logframe matrix and list
them in the first column of the work plan. List them in terms of which
activity is needed in order to do others. Clarify them further and add
sub-activities, if needed.
- For each (sub-) activity, specify the following: milestone what
is to be done by when, who is responsible for implementing it and for
checking it, when it should start and finish, staff requirements in
terms of person-months, quantity of material and equipment needed, cost
and cost category and important assumptions.
- Check the plan by ensuring that the total cost is within the budget
(see Box 3-15) and that people are not overloaded
or forgotten in terms of responsibilities (or that there are gaps or
contradictions). Also make sure that timing is realistic and consistent.
You cannot have the same person or piece of equipment scheduled at the
- Do the above with the main stakeholders to ensure a shared sense of
responsibility (see Boxes 3-15, 3-16
- Compile the final consensus into the AWPB document (see Table
3-5) and send this to the appropriate body for approval, including
a "no objection" from the cooperating institution.
The AWPB is the basis for more detailed operational planning: work plans
per project component, per staff member, per month/quarter/half-year,
etc. Some projects use Gantt charts to show when activities are to happen
during the year. However, these charts do not show other important information,
such as responsibility and resources, so other charts are also needed
(see Annex D).
Box 3-15. The development of the AWPB in a Tanzanian
Box 3-16. Participatory revision of the
budget and project strategy
Even simply integrating the budget with the logframe can, as project
staff in Uganda found, prove difficult. At a participatory workshop
on developing the logframe, the participants were in a hurry simply
to plug in the numbers and leave. Project staff had to encourage
them to justify the expenses as part of the wider strategy and activities.
Not surprisingly, the budget was far beyond the resources available.
To reduce the budget they had to review their thinking process and
identify those activities which most contribute to the outcomes
they wanted to see. This process of backtracking helped the participants
explain and justify why the activities were important and what would
not be undertaken if not for external resources.
Box 3-17. Validating and
documenting the planning system in Nicaragua
Tropisec in Nicaragua developed a guide that summarised
their participatory planning and M&E system. The guide was an
important resource for the project management unit and implementing
partners, covering the concepts and procedures to be considered
during their relationships, organisation and verification of actions.
The system and guide were validated in several joint workshops,
where it was recognised that neither should limit the creativity
and innovative capacity of stakeholders. During the project lifetime,
both the system and guide were modified based on suggestions for
improvements from stakeholders and a formal M&E review by implementing
partners. The guide became more user friendly, suggesting basic
tips for grassroots organisations and implementers in general.
Table 3-5. Example table of contents for an AWPB
Summary of project objectives,
area and components that focuses on the strategy to reduce poverty.
Describe any critical issues or recommendations resulting from
changes in policy, government directives or supervision missions.
2. Analysis of implementation
Description of progress
made, problems experienced, adequacy/inadequacy of project inputs,
lessons learned for each level of logframe. Indicate any adjustments
needed to the logframe and justify them.
3. Budget summary
summarised per project component, per output, per district/facilitation
unit and at national and overall project levels. Explain how components
are to be financed by different stakeholders: government, primary
stakeholders, IFAD and other funding agencies, as well as what
each stakeholder is contributing to each component.
4. Overall work plan
For each component,
an explanation of what is to be funded, rationale, strategy, expected
outputs and any changes from last years AWPB, outlined following
the logframe format. Explain which of these relate to needs prioritised
by primary stakeholders and which needs are left out and why.
Summarise the process to be followed for primary stakeholder participation
in the coming year.
5. Output/ activity
Plans for each component,
including what is needed in terms of project support and coordination
and training activities for project/partner staff and primary
stakeholders; how plan implementation is to be monitored.
6. Procurement plan
Types of facilities
and equipment to be purchased, quantities, cost, destination and
description of purpose.
7. Contracted services
NGO and private sector services to be contracted.
8. Required plan and
definition of the input requirements for carrying out the activities,
by component and by expenditure category. This is directly related
to the work plan.
9. Overall schedule
The period during which
activities are to be undertaken and outputs to be achieved, who
is responsible and key milestones for the year.
Outlines of formats:
output/activity plan, output/activity budget, indicators and monitoring
schedule, contracted services monitoring, training activities
monitoring, implementation progress monitoring, financial status,
project status summary, credit analysis, project outputs summary
and calendar of activities.
3.6 Outlining M&E
During Initial Project Design
3.6.1 How Initial Project Design Influences
Unintentionally, M&E is often set up to fail during
initial project design. How? For example, there is not an adequate budget
for M&E, insufficient time and expertise have been allocated to M&E
during the start-up phase, or there is insufficient flexibility in the
project design to enable the M&E system to influence the project strategy
during implementation. Initial project design influences M&E through:
- 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;
- the operational guidelines for M&E.
Lets consider each point.
First, during project implementation, the effectiveness of M&E will
be greatly influenced by the attitudes and commitment of local people
and partners involved in the project and how they relate and communicate
with each other. Individuals or organisations that have been active in
the design phase are more likely to know if the project is genuinely in
their interests and to understand the objectives. They are more likely
to take an interest in monitoring the progress and achievements of the
project. Alternatively, if people have been disillusioned, frustrated
by or left out of the design process, then they are less likely to be
interested in and committed to M&E activities.
In practice, projects experience considerable delays between design
and start-up and related changes regarding who is involved. Nevertheless,
the experience and legitimacy of the design process will have lasting
consequences for implementation. The definition of clear responsibilities
may also require the formation of new institutions or groups/units within
institutions to undertake them. The appraisal report of the PADEMER project
in Colombia defined the coordination component as including the shaping
of a national technical coordination unit "that will integrate the
functions of the monitoring unit with the evaluation unit and will be
framed within the national evaluation system". It further stipulated
that this coordination unit would be responsible for the annual work plan,
the systemisation of information on project progress to guarantee timely
decision-making by the management, and the preparation of relevant reports.
Box 3-18 describes the importance of relationships
and organisational structure for laying the foundation for effective M&E.
Box 3-18 A weak basis for effective M&E
In the initial project design of the TEPP project
in Yemen, the project M&E department was not part of the project-management
organisational structure. Instead, it fell under and was directly
responsible to a government agency with a long-established M&E
unit of its own based on national guidelines. Similarly the project
director was also directly responsible to the chairman of the agency.
This structure meant that the M&E unit had no direct access
to resources and relied on minimal government funding. So no M&E
reporting was undertaken. M&E activities required approval via
a complex hierarchy of top-level managers. As the M&E department
was responsible to the agency, relationships with project management
were sensitive. This further affected the M&E budget, project
incentives for M&E and adoption of M&E recommendations by
the project. To make matters worse, project M&E was based on
the existing government system without necessarily holding relevance
to project specificities. This was compounded by the fact that project
M&E staff were also responsible for M&E activities of other
projects under the auspices of the government agency.
The second design fault is when a project lacks logic in
its strategy or has unrealistic objectives, making good M&E almost
impossible. This is because the evaluation questions and indicators often
become quite meaningless and will not produce useful information. Furthermore,
if you dont know clearly where you are heading then you will not know
how best to use any information that might be produced. A good M&E
system can help put a poorly designed project back on track, but this
creates considerable extra work during start-up and implementation.
The third is when the design team does not allocate enough
resources to the M&E system (see Section
7 for more on budgeting). Critical resources include: funding
for information management, participatory monitoring activities, field
visits, etc.; time for a start-up phase that is long enough to
establish the M&E system, do a participatory baseline, train staff
and partners, include primary stakeholders in M&E and monitor and
reflect; and expertise, such as a consultant to support M&E
development. As the design team, you must negotiate the level and extent
of M&E that is possible for a given budget. Then you can make a detailed
The fourth factor is critical if M&E systems are to
generate the learning that helps a group of project partners continually
improve implementation and strategy. The more rigid a project design is,
the more difficulty the project team will have in adjusting it as a result
of changes in the context and understanding of interim impacts. As the
design team, identify how flexible you feel the project design needs to
be and what the boundaries of and processes for design adaptation should
be. A project with inbuilt flexibility provides an important rationale
for the M&E system.
Fifth, it is important that during design, the broad framework
of the M&E system is established. Then everyones expectations about
his or her responsibilities and information rights can be clear. The next
sub-section indicates what could be included in the documentation that
describes the M&E system in the project appraisal report.
3.6.2 Documenting M&E in the
Project Appraisal Report
The last M&E-related step for the design team is writing
down the suggested M&E framework in the appraisal report. How this
is done can strongly affect the start-up of the project (see Box
Box 3-19. Implications of
how the M&E system is documented at appraisal
The appraisal report of one project had included the
design of a baseline survey and even the follow-up survey, but not
the overall M&E system, specific targets by activity or a systematic
way for data collection. According to the project staff, "The
design of the project does not include a full description of how
an M&E system looks and functions, nor what it would produce."
Due to this, although the M&E unit existed before the project
became effective, the data collected were not directly relevant
to project objectives. It was more than a year after the start of
field implementation that a supervision mission drafted a performance-indicator
framework based on the AWPB targets, and constructed a more elaborate
logframe. Also at this time, a technical advisor was appointed,
which stimulated the construction of a database, prototype forms
for data collection and so on.
Table 3-6 outlines what to include in
the appraisal report as related to the M&E framework. This can serve
to guide the writing process. As management functions relate to project
M&E and implementation, so the M&E component of the appraisal
report may either be included as a separate section or be integrated into
a section on project organisation and administration and/or management.
The main point is that the more the M&E component is integrated into
the management system, the more useful and effective it may be.
Table 3-6. Suggested contents lists
for the M&E component in a project appraisal report
of purpose of this section of the appraisal report plus a summary
of key innovations and potential obstacles for the project implementers
Specific Project/Context Features that Affect M&E
affecting the resources required for the M&E unit to remain
viable, including, for example, geographic coverage and level
of in-country communication systems; other contextual features:
the range of project components and the project organisational
M&E Purpose and Scope
defined purpose and scope of M&E in the project context, including
the project M&E needs and the information to be generated
Key Performance Questions, Indicators, Information-Gathering Requirements
and Implications for the M&E System
of possible key questions and indicators for the goal, purpose
and output levels, plus generally described information gathering
and organising methods to enable resource allocation
Internal Self-Evaluation Processes (input/output monitoring, ongoing
evaluation and impact evaluation)
outline of key processes, tasks and events
External Evaluations (ongoing and impact evaluations)
frequency of external evaluations and how the project will be
integrated into this evaluation process, including special evaluation
studies or thematic studies that might be needed at key moments
in the project
Intended Primary Stakeholder and Partner Participation in M&E
the early identification of stakeholders for their involvement
in M&E planning at start-up
Structures and Staffing for M&E
staffing levels and types, roles and responsibilities related
to activities, and a clear description of the organisational structure
of M&E and its interaction with other project sectors, particularly
with project management
Capacity-Building for M&E
of support needed to create sufficient appropriate M&E capacity
among project stakeholders
specific information management systems that are recommended for
the project context
Process for Detailed Planning of M&E during Start-Up
draft timeframe for development of the M&E system
description of key audiences and types of information that should
be communicated to them
budget for key items (staff time, materials, evaluation and training
events, publication/documentation, consultants)
Responsibilities of Project Management
of Reference for those Responsible for M&E and for Consultants
Providing M&E Support
Detailed M&E Budget
Sites for overview of logframe or objective oriented planning:
AusAid Logframe. Clear overview of logframe steps and issues,
with examples. View
Objectives-Oriented Project Planning document. Download.
Swiss Agency for Development and Cooperation (SDC). See
publications section (in
multiple languages) online .
Broughton, B. and Hampshire, J. 1997. Bridging the Gap:
A Guide to Monitoring and Evaluating Development Projects. Canberra: Australian
Council for Overseas Aid. Contact: firstname.lastname@example.org.
IFAD, ANGOC and IIRR. 2001. Enhancing Ownership and Sustainability:
A Resource Book on Participation. International Fund for Agricultural
Development, Asian NGO Coalition for Agrarian Reform and Rural Development
and International Institute of Rural Reconstruction. Contact: email@example.com.
Download PDF Version (316KB)
This is now a standard approach by AusAids's (Australian bilateral aid
agency) approach to the logframe.
2/ From V. Altarelli. Participatory Diagnostic Study in
Project Formulation and Beyond. A Process Approach. J. Kumar Dutta. Stakeholder
Involvement in Participatory Practices. An Overview of Bangladesh NGOs.
Both in IFAD, ANGOC and IIRR. 2001. Enhancing Ownership and Sustainability.
A Resource Book on Participation.