TVETipedia has been relaunched. The information below may be outdated. Please click on the images on the left to access our new services.

The Logical Framework (LogFrame) Approach (LFA)

Objectively Verifiable Indicators (OVIs)

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:

  • Quality: a variable that describe exactly what will change or be delivered.
  • Quantity: How much of the quality will be changed or delivered.
  • Target group: by whom or for whom will the change or service be realized?
  • Time: When will the change or service be realized?

The Logical Framework Approach

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.

The logical Framework Matrix

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

Narrative SummaryObjectively Verifiable Indicators - OVIsMeans of Verification -MOVsExternal Factors (Assumptions)
Development Objective ' '
Immediate Objective ' ' '
Outputs (Results)

' '
' '
Table 1: The Logical Framework Matrix

The definitions of the terms used in the column and row headings of the Logical Framework Matrix are:

  • Narrative Summary: This term used to describe the text that "narrates or describes" the objectives. It could have been given the title "Hierarchy of Objectives", but this might be misleading because the bottom cell in the column is a summary of the activities.
  • Objectively Verifiable Indicators (OVIs): These are the measures, direct or indirect that will verify to what extent the objectives have been fulfilled. The term "objectively" implies that if these should be specified in a way that is independent of possible bias of the observer.
  • Means of Verification (MOVs): These statements specify source of the information for the measurements or verification specified in the indicators column. For example, will statistics from an external source be used for the verification or will project / programme / system resources be used to gather the statistics.
  • External Factors (Assumptions): These are important events, conditions, or decisions which are necessarily outside the control of the project / programme / system, but which must remain favorable for the project / programme / system objective to be attained. The implication here is the design team has an obligation to consider what might derail their efforts (let their efforts run of the track) and to plan responsibly to reduce that risk of "derailment (running of the track)".
  • Development Objective: The higher level objective that the project / programme / system is expected to contribute to. The addition of the word "contribute' implies that this project / programme / system alone is not expected to achieve the development objective. Other project / programme / system's immediate objectives are expected to also contribute.
  • Immediate Objective: The effect which is expected to be achieved as the result of the project / programme / system delivering the planned outputs. There is a tendency for this to be expressed in terms of the "change in behavior" of a group, or institution and the project / programme / system outputs are expected to facilitate this change.
  • Outputs: These are the "deliverables" the tangible or real results that the project / programme / system management team should be able to guarantee delivering. The objective statements should specify the group or organization that will benefit. Outputs are delivered, usually on a certain date or dates.
  • Activities: These are the activities that have to be undertaken by the project / programme / system to produce the outputs. The activities take time to perform.
  • Inputs: These are the resources that the project / programme / system "consumes" in the course of undertaking the activities. Typically they will be human resources, money, materials, equipment, and time.
  • Vertical Logic: The vertical logic is the reasoning which "connects" the three levels of objectives in the matrix; the outputs, the purpose, and the goal. For example achievement of all the output level objectives should lead to achieving the purpose. Each of these links between the objectives is connected by hypotheses. For example at the bottom level - the implementation hypotheses the implication is "we believe that in the environment of this project / programme / system the planned outputs will produce the planned result. At this level, the hypotheses are usually supported by research or experience. The explanation of the hypotheses at the other levels is similar.
  • Horizontal Logic: The horizontal logic has similar features to the vertical logic. In this case, the links between the levels of objectives are the items in the External Factors column. For example, if the project / programme / system is successful in implementing all of the planned activities, we ask ourselves, what circumstances or decisions (outside the project / programme / system's control) could prevent the delivery of the project / programme / system outputs.
  • Caution: The term "deceptively simple" implies that the description given above is not exhaustive and does not explain all the meaning of the Logical Framework project / programme / system design tool. Proper use of the tool requires practice.

Where's the logic in a Logical Framework Matrix?

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:

  • How the achievement of the objective will be measured or verified?
  • How this information will be obtained?
  • What are the external factors that could prevent the project manager and staff from achieving the next level objective?

Design Methodology of a Logical Framework Approach

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?


Situation Analysis

Analysis Where to

start? Objectives



Logical Framework Analysis

as a Process


Logical Framework Planning

Where's the



Framework as a


Figure 1: Mind Map Diagram for LFA Design Process

Advantages of the Logical Framework Approach

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.

Disadvantages of the Logical Framework Approach

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.

Assumptions and Risks

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:

  • How important are the assumptions?
  • How big are the risks?
  • Should the project / programme / system be redesigned?
  • Should elements of the proposed project / programme / system be abandoned?


page date 2009-10-05

Share: Facebook   Twitter   Google+   print version