THE PROJECT LOGICAL FRAMEWORK: TECHNIQUES AND ISSUES

Transcription

1 THE PROJECT LOGICAL FRAMEWORK: TECHNIQUES AND ISSUES The use of the Logframe in the design of public projects The European Commission adopted the Project Cycle Management (PCM) approach in 1992 as a framework to manage the projects financed under the European Development Fund (EDF). This approach was subsequently used in other cooperation frameworks (like TACIS, PHARE, MEDA) and is presently used in a generalised manner. PCM brings associated with it the Project Logical Framework (or logframe), a technique that is particularly adequate to design any kind of public intervention whatever its degree of complexity (from small projects to large programmes), its nature (tangible or intangible) and scope (sectoral, regional, local). In many cases, the financing proposals submitted to the European Commission are only approved after being endorsed by the Quality Support Group, which assesses the quality of the project proposals using the logframe methodology. The use of this method assumes a good knowledge of the context in which the project is designed and implemented. It is important that those involved in the elaboration of a project are well aware of the policy objectives of the sector or region in which context the project is to be implemented. It is also recommended that they be aware of the technical aspects involving the use the project logframe. Project design using the logframe The use of the method is split in two main phases: the analytical and the planning phases. The analytical phase unfolds in four steps: i. Stakeholder analysis ii. iii. iv. Problem analysis Analysis of objectives Analysis of strategies As the PCM handbook points out, the analytical phase should be carried out as an iterative learning process rather than as a simple set of linear steps. For instance, if the analytical process starts with the stakeholder analysis, it might have to be reviewed later in light of the issues raised during the subsequent steps of problem and objectives analysis.

2 In the planning phase, the outputs of the analytical stage are translated into an operational plan envisaging the project implementation. In concrete, the planning phase includes the following steps: v. Elaboration of the project logical framework vi. vii. Setting up the activity schedule Preparation of the project budget An iterative process is also recommended in this phase. For instance, it might be necessary to revise the objectives setting and the activity planning if the budget constraints do not allow meeting the initial objectives. The following box sums up the content of each step of the analytical phase. Table 1: Steps of the framework analytical phase Stakeholder analysis Stakeholder is any individual or organization that has a significant interest in the project (target groups, beneficiaries, implementers, etc). These different groups likely have different if not contradictory interests that need to be understood and recognized very early in the stage of project identification. In this context, it is important to know the motivations of the different stakeholders as regards the project and try to take them into account when objectives are set. A participative approach is particularly recommended to channel the different stakeholders and to capture the different perspectives in order to form consensus when required. Problem analysis Problem analysis envisaged identifying the negative aspects of a given situation and setting up the cause-effect links among the identified problems. This analysis can be supported by a problem tree (see example below) highlighting the core problem, the cause problems and the effect problems. Problem analysis allows the identification of the possible constraints and issues to which a response is required. Such problems in general reflect the perception of the relevant stakeholders and therefore they have a higher priority in the stakeholders perspectives. A well done problem analysis paves the way for a proper setting of objectives, in the sense that they correspond to the beneficiaries expectations. Analysis of objectives The analysis of objectives aims at anticipating a future desired situation, which represents a 2

3 positive answer to the problems identified in the previous phase. The analysis is supported by an objectives tree, which is deducted from the problem tree through the conversion of problems (formulated as negative situations) into objectives (formulated as positive situations). Analysis of strategy Before the range of possible objectives, a choice must usually be made in light of a set of criteria like: availability of financial resources, the mandate of the implementing entity, the complementarities with other projects, etc. This analytical phase is, in general, the most complex one, as it involves a significant volume of complex information that must be sorted out in order to produce a consensual and feasible project. In practice, it implies a number of commitment in order to ensure an adequate balance between the interests of the agents, the political demands and the available resources. The following figure shows an example of the relation between the structures and content of the problem tree and the objectives tree, using the example of a project envisaging the reduction of river pollution. The example highlights that the definition of objectives is strictly linked to the problem analysis. Moreover, it shows how to formulate both problems and objectives. The former as negative present situations; the latter as future positive situations. 3

4 Figure 1: Example of a problem tree 1 1 CE (2004), Project Cycle Management Guidelines 4

5 Figure 2: Example of an objectives tree 2 The following table shows the main elements of a logframe. It is built on the basis of the stakeholder analysis, the objectives and the strategy, which provide the information for the fulfillment of the first column of the table. The second column contains the performance indicators, which should be set in relation to each level of the objectives hierarchy. The third column indicates the sources of information to build the indicators. Finally, the fourth column highlights those factors that are not under the responsibility of the project management but which are nevertheless essential to the project success. Table 2: Logframe structure Intervention logic Performance Sources of Assumptions indicators verification Overall objectives Impact indicators: Sources of The broad socioeconomic impact to which the project contributes at a national or sector Measures the longterm consequences of the outcomes. information and methods used to collect and report it (including who and when/how 2 CE (2004), Project Cycle Management Guidelines 5

6 level (it provides the frequently) link to the policy and/or sector programme content) Purpose Outcome indicators: Sources of Assumptions (factors The outcome at the end of the project more significantly the expected benefits to the target groups Measure the results in terms of target group benefits information and methods used to collect and report it (including who and when/how frequently) outside project management s control) that may impact on the purpose-objective linkage Results Output indicators: Sources of Assumptions (factors The direct and tangible results that the project delivers, and which are largely under project management s Measure the immediate and concrete consequences of the measures taken and resources used information and methods used to collect and report it (including who and when/how frequently) outside project management s control) that may impact on the resultpurpose linkage control Activities Assumptions (factors The tasks that need to be carried out to deliver the planned results outside project management s control) that may impact on the activity-purpose linkage 6

7 Strengths and shortcoming of the use of the Logical Framework Matrix The generalised use of the Logical Framework Matrix since the early 90 s by the European Commission provides enough evidence to strike a balance between its benefits and limitations. In general it can be said that the difficulties found are more related to its misuse than to its intrinsic limitations. The following table synthesizes the main strengths and problems related to its use. They are grouped in three domains: problem and objective setting, performance indicators and format and application of the logframe. As regards the shortcomings, the most relevant ones are indicated in the first place within each domain. Table 3: Strengths and shortcomings of the logframe Domains Strengths Common shortcomings/difficulties Problem analysis and objective setting Indicators and source of verification Requires systematic analysis of problems, including cause and effect relationships Provides logical links between means and ends Places the project within a broader development context (overall objectives and purpose) Encourages examinations of risks and management accountability for results Requires analysis on how to measure the achievement of objectives, in terms of both quantity and quality Helps improve clarity and specificity of objectives Helps establish the monitoring Problems and objectives set without participation of the relevant stakeholders Getting consensus on prioritary problems Getting consensus on prioritary objectives Reducing objectives to a simplistic linear chain Inappropriate level of detail Finding measurable and practical indicators for higher level objectives and for projects with capacity building and process objectives Establishing unrealistic targets too early in the 7

8 and evaluation framework planning process Relying on project reports as the main source of verification and not detailing where the required information actually comes from, who should collect it and how frequently Format and application Links problem analysis to objective setting Emphasizes importance of stakeholder analysis to determine whose problems and who benefits Visually accessible and relatively easy to understand Formulated after the project has been designed, to comply with donors demands, instead of being used as a guide Prepared mechanistically as a bureaucratic box-filling requirement, not linked to problem analysis, objective setting or strategy selection Used as a means of topdown control too rigidly applied Can alienate staff not familiar with the key concepts Becomes fetish rather than a help Adapted from CE (2004), Project Cycle Management Guidelines In conclusion, the Logic Framework Matrix provides a convenient framework to design public projects supported by EU funds. If its analytical and planning capabilities are not convincing enough, in many EU financed projects its use is mandatory as part of the eligibility criteria. Alessandra Merlo, July