|UNESCO-UNEVOC|||||e-Forum|||||Network||TVETipedia||Register | Login|
1 The Logical Framework (LogFrame) Approach (LFA)
2 Objectively Verifiable Indicators (OVIs) [Edit]
a) The Objectively Verifiable Indicators OVIs are Qualified Indicators defined for projects, programmes or systems, right from the identification phase, with a view to verify whether their objectives have been reached and to what extent.
b) The OVIs may be quantitative: measures of quantity, including statistical statements; or qualitative: judgments and perception derived from subjective analysis. In all cases OVIs must provide valid, useful, practical and comparable measures of progress towards achieving the expected targets.
c) OVIs are qualified as objectively verifiable because they should not rely on vague and personal appreciations.
d) A complete OVI contains the following four aspects:
3 The Logical Framework Approach [Edit]
The Logical Framework (LogFrame) Approach (LFA) is a project design methodology which helps to clarify objectives of any project, program, or system. It aids in the identification of the expected causal links—the “programme logic”—in the following results chain: inputs, processes, outputs (including coverage or “reach” across beneficiary groups), outcomes, and impact. It leads to the identification of performance indicators at each stage in this chain, as well as risks which might impede the attainment of the objectives. The LogFrame is also a vehicle for engaging partners in clarifying objectives and designing activities. During implementation of a project, programme or system, the LogFrame serves as a useful tool to review progress and take corrective action.
4 The logical Framework Matrix [Edit]
The Logical Framework Matrix shown in Table 1 is a document which is deceptively simple. There are 16 cells in a 4 column by 4 row matrix. To provide the matrix, the project designers are asked to address and answer a number of questions which, on the surface seem self evident. However, articulating the answers to these apparently self evident questions exposes many unstated assumptions and hypotheses.
The process of examining these unstated beliefs should cause them to be questioned more closely during the design of the project / programme / system. This examination often reveals that the assumptions and hypotheses are often questionable. If we test these assumptions and hypotheses and return the results of our work to the project design, we should produce a higher quality design.
Logical framework matrix
The definitions of the terms used in the column and row headings of the Logical Framework Matrix are:
5 Where's the logic in a Logical Framework Matrix? [Edit]
a) We might note that one common misuse of the Logframe is to design the project first and attempt to "fill in" the logical framework matrix as an afterthought. This defeats the whole purpose of the logical framework and the design methodology.
b) There is a logical connection between the cells of the matrix. The logic that connects the cells in the left most columns is referred to as the vertical logic; the logic that connects the remaining three columns is referred to as the horizontal logic.
c) The vertical logic is the hierarchy of objectives of the project.
d) The horizontal logic is rather more involved. For a given level of objective (equivalent to a horizontal row of cells) the horizontal logic describes:
6 Design Methodology of a Logical Framework Approach [Edit]
The LFA as a design methodology is used to impose a logical discipline on the design team of a project, programme or system. If the process is used with integrity the result will be a high quality project / programme / system design. Many things can go wrong in the implementation phase of a project, programme or system but if the design is inadequate, implementation starts with a severe handicap. A Mind Map Diagram showing the typical steps in the design process of a LFA is illustrated in Figure 1. These steps are:
a) Situation Analysis
This is a document that describes the situation surrounding the problem. The source could be a feasibility study, a pre-appraisal report, or be a compilation done specifically for the project / programme / system design workshop. Typically the document describes the problem situation in detail, identifies the stakeholders and describes the effects of the problems on them.
b) Stakeholder or Participation Analysis
This stage is an analysis of the people, groups, and organizations, TVET Centres or CoC who may influence or be influenced by the problem or a potential solution to the problem. This is the first step to understanding the problem. We might say, without people or interest groups there would be no problem. So to understand the problem, we must first understand the stakeholders. The objectives of this step are to reveal and discuss the interest and expectations of persons and groups that are important to the success of the project / programme / system.
c) Problem Analysis
If there is no agreement between participants on the statement of the problem, it is unlikely there will be agreement on the solution. This stage therefore seeks to get consensus on the detailed aspects of the problem.
The first procedure in problem analysis is brainstorming. All participants are invited to write their problem ideas on small cards. The participants may write as many cards as they wish. The participants then group the cards or look for cause-effect relationship between the themes on the cards by arranging the cards to form a problem tree.
d) Objectives Analysis
In this step the problem statements are converted into objective statements and if possible into an objective tree. Just as the problem tree shows cause-effect relationships, the objective tree shows means-end relationships. The means-end relationships show the means by which the project / programme / system can achieve the desired ends or future desirable conditions. Frequently there are many possible areas that could be the focus of an "intervention" or development project / programme / system. The next step addresses those choices.
e) Alternatives Analysis
The objective tree usually shows the large number of possible strategies or means-end links that could contribute to a solution to the problem. Since there will be a limit to the resources that can be applied to the project / programme / system, it is necessary for the participants to examine these alternatives and select the most promising strategy. After selection of the decision criteria, these are applied in order to select one or more means-end chains to become the set of objectives that will form the project / programme / system strategy.
f) Activities Planning
After defining the objectives and specifying how they will be measured (OVIs) and where and how that information will be found, we get to the detailed planning phase. We now determine what activities are required to achieve each objective.
g) Where to start?
This is a little like the chicken and the egg problem. It is tempting to say; always start at the situation analysis stage, and from there determine who are the stakeholders. Another argument is that the stakeholders define the problem so it is necessary to start with identifying the stakeholders. Each problem situation will require a different approach.
h) Where to go next?
The next step will be implementation planning and implementation.
Stakeholder Where to Analysis go next?
Problem Situation Analysis Analysis Where to start? Objectives Anaylsis
Alternatives Logical Framework Analysis as a Process Activities Logical Framework Planning
Where's the logic? Logical Framework as a Document
7 Advantages of the Logical Framework Approach [Edit]
a. Improving quality of project / programme / system design by requiring the specification of clear objectives, the use of performance indicators, and assessment of risks.
b. Summarizing design of complex activities.
c. Assisting the preparation of detailed operational plans.
d. Providing objective basis for activity review, monitoring, and evaluation.
e. Ensures that decision-makers ask fundamental questions and analyze assumptions and risks.
f. Engages stakeholders in the planning and monitoring process.
g. When used dynamically, it is an effective management tool to guide implementation, monitoring and evaluation.
8 Disadvantages of the Logical Framework Approach [Edit]
a. If managed rigidly, stifles creativity and innovation.
b. If not updated during implementation, it can be a static tool that does not reflect changing conditions.
c. Training and follow-up are often required.
9 Assumptions and Risks [Edit]
a. Assumptions and risks are external conditions that are outside the control of the project / programme / system. The achievement of aims depends on whether or not assumptions hold true and the risks do not materialize.
b. If cause and effect is the core concept of good project / programme / system design, necessary and sufficient conditions are the corollary. The sufficient conditions between the levels in the hierarchy of aims are the assumptions. This is the external logic of the project / programme / system.
c. When working on a project / programme / system, we make assumptions about the degree of uncertainty between different levels of aims. The lower the uncertainty that certain assumptions will hold true, the stronger the project / programme / system design. Any experienced manager will agree that the assumptions - the failing assumptions - can derail a project / programme / system as often as poorly executed outputs.
d. Logframe demands that all hypotheses, assumptions and risks relevant to a project / programme / system are made explicit. By implication, this then further demands that the appropriate action is considered (and if necessary taken) before problems materialize. In this regard, the following questions should be investigated and answered:
10 Links [Edit]