By Hüseyin Aktürk
General Manager, AB-ilan.com / Senior Project Manager

Most professionals encounter the Logical Framework Matrix for the first time and have the same reaction: “How am I supposed to fit all of this into one table?” The answer, though, is that the Logframe is not a form to be filled in — it is a thinking tool. Once you grasp its internal logic, the challenge stops being about fitting things in and starts being about genuinely understanding your project.

This guide walks through the matrix column by column, in the sequence that actually works. It is written for people preparing a grant application and for those already in implementation who have quietly shelved the Logframe somewhere in a shared folder.

What Is the Logical Framework — and Where Did It Come From?

In Turkey, the Logframe is almost synonymous with EU projects. But its origins are American. The Logical Framework Approach (LFA) was developed between 1969 and 1971 by a team led by Leon Rosenberg at Practical Concepts Inc., a Washington-based consultancy, originally commissioned by USAID to bring more rigour to its development portfolio.

The European Commission adopted the approach in the early 1990s. Germany’s development agency GTZ had already been running its own variant — ZOPP (Zielorientierte Projektplanung, or Goal-Oriented Project Planning) — since the 1980s. In Turkey, the Logframe became standard practice with the IPA programming period after 2003 and has been a fixture of grant applications ever since.

The most widely used format is a 4×4 matrix of 16 cells. The top-right cell is always left empty — the reason for that will become clear when we get to the assumptions column.

The Structure of the Matrix

The Logframe brings four types of information together in one place:

• Intervention Logic / Hierarchy of Objectives: Overall objective, specific objective(s), and expected results
• Project Inputs: Activities, means, and costs
• Assumptions: The external conditions that must hold true for your project logic to work — things you depend on but cannot directly control
• Indicators and Verification: How you will measure success, and where the evidence will come from

These four components are not independent sections. They are interlocked. You cannot write credible indicators without a solid results chain; you cannot identify realistic assumptions without first knowing what your activities are.

Before You Start: The Preliminary Analyses

One important note before touching the matrix: the Logframe cannot be filled correctly without completing the upstream analytical work first. Problem analysis, objective analysis, strategy analysis, and stakeholder analysis must all be done before you sit down with the template.

Skipping these steps and going straight to the matrix produces something that may look internally consistent but has no real connection to the actual problem being addressed. It is a fairly common mistake in rushed grant applications, and experienced evaluators tend to spot it quickly.

Column One: The Intervention Logic

Work through this column from the bottom up.

Overall Objective. The long-term goal that your project contributes to but cannot achieve on its own. It sits above what any single intervention can deliver. It must align with the objectives stated in the programme guidelines. Your strategy tree’s top level will typically point you here.

Specific Objective(s) / Outcome. The mid-term change that your project is directly designed to bring about. EU programmes usually expect a single specific objective. Again, alignment with the programme guidelines is not optional — it is a condition of eligibility.

Expected Results. The short-term, concrete outputs of your project activities. Here is a distinction worth getting right: organising a ceramics training course for 20 people is an activity. The expected result is the improved vocational capacity of those 20 people at the end of the course. The results you define here must be consistent with the result and output indicators specified in the grant guidelines.

Activities. The project’s work packages — every concrete action that will take you from inputs to results. Keep these specific enough to be manageable and monitor them against your work plan throughout implementation.

Means. The resources required to carry out each activity: personnel, equipment, premises, materials. For a training course, this might include a trainer, a classroom, a projector, printed materials, and an attendance register.

Costs. A summary of the main budget headings — Human Resources: €X, Travel: €Y, Equipment and Supplies: €Z. This cell mirrors the structure of your financial annexes.

Column Four: Assumptions (read from the bottom up)

The assumptions column is where many applicants go wrong — either by leaving it vague (“political stability,” “favourable weather”) or by confusing it with risks. The logic here is precise.

For each row, ask: even if the row below has been delivered successfully, what external conditions must also hold true for me to reach this row?

The reading sequence, from the bottom up, goes like this:

• If I carry out the activities and my assumptions hold, then I achieve the expected results.
• If I achieve the expected results and my assumptions hold, then I reach the specific objective.
• If I reach the specific objective and my assumptions hold, then I contribute to the overall objective.

This is why the top-right cell is empty. Once you have reached the overall objective, there is no higher rung on the ladder. The chain ends there.

One further distinction worth making: below the activities row, the Logframe includes a separate space for preconditions — conditions that must be in place before the project can even start. If you plan to run training sessions in schools, a signed protocol with the Ministry of Education is a precondition, not an assumption. No protocol, no activities.

Columns Two and Three: Indicators and Sources of Verification

For each row, you are answering two questions:

1. How do I define success for this row in measurable terms? (Indicator)
2. Where can I objectively prove that success has been achieved? (Source of Verification)

At the activity / output level. What is the quantitative threshold that defines successful delivery? If you are running a vocational training course for 100 people, what counts as success — 90% attendance and certification? If that is your indicator, you are accountable for it throughout the project. Finish at 40% and expect questions.

Sources of verification at this level should be concrete and auditable: signed attendance sheets, photographs, exam results, certificate copies. “Participants improved their skills” is not a source of verification.

At the expected results level. Let us follow a single example through the whole matrix: Activity is vocational tourism training for 100 people; Expected Result is improved vocational capacity of those 100 people; Specific Objective is improved hotel quality in a given district; Overall Objective is an increase in the number of foreign visitors to that district.

How do you express “improved hotel quality” as a number? One approach: the average Booking.com rating of hotels in the district was 7.2 in the baseline year; the project aims to bring this to 7.6 by the end. That rating alone may be a limited indicator, but the logic holds. For more rigorous applications, consider complementary measures — the number of staff with professional certification, occupancy rates, or tourism authority membership figures.

Source of verification: Booking.com data extracted at baseline and at project end, with a comparison report.

At the specific objective and overall objective level. The most macro indicators. For “increased visitor numbers,” set a realistic numerical target. A 50% increase is not credible for a single project. A 5–10% increase is defensible, depending on context and project scale.

Source of verification: Ministry of Culture and Tourism statistics, Chamber of Commerce records, or other official data sources.

A note on the example: it uses one activity feeding one result feeding one objective. In real projects, you will define separate indicators and verification sources for each activity, each expected result, and each specific objective.

The Updated Logframe: Baseline, Current Value, and Target

Since the IPA II programming period, the indicators column has been divided into four sub-columns. The underlying logic has not changed — the purpose is to make indicators more visible and to structure the monitoring and evaluation process more clearly.

The four sub-columns are:

Indicator. The qualitative definition of the criterion, without the number. Example: “Participants holding a nationally recognised qualification approved by the Vocational Qualifications Authority (MYK).”

Baseline. The current situation for this indicator before the project starts. It might be zero; it might be 117. If there are currently three licensed tourist guides in the district and you aim to increase that to eight, your baseline is 3.

Current Value. During the writing phase, leave this blank — at that point, the current value equals the baseline anyway. This column is used for interim reports and monitoring visits. If a mid-term report is due at month six, enter the figure as of that date (with the reference date noted). If there are now five licensed guides in the district, the current value at month six is 5.

Target. The value you commit to reaching by the end of the project. In the example, 8. The column to the right of these four, as in the original template, is the source of verification.

One terminological change worth noting: the new template replaces “Project Logic” with “Results Chain” at the top of the first column, in line with results-based management methodology. At the specific objective level it uses the term outcomes, while the activities level uses outputs. The outputs vs. outcomes distinction matters and deserves its own discussion — that will come in a separate post.

The Logframe Is a Management Tool, Not a Submission Requirement

The most common mistake is treating the Logframe as a box to tick during application and ignoring it during implementation. This is where many projects run into trouble — not because the original design was wrong, but because the team loses sight of the logic that holds the project together.

The matrix tells you what you committed to, what you assumed would remain stable, and what evidence you said you would produce. If your assumptions break down halfway through, the Logframe is where you go first to understand what needs to change and why.

Fill it carefully. Every figure in the indicators column is a commitment. And if you do not know your baseline, you will have no way of demonstrating that you reached your target.

Have questions about a specific part of the Logframe, or dealing with a tricky assumptions column? Leave a comment below or get in touch via the contact page.

© Hüseyin Aktürk – huseyinakturk.com This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License. No part of this article may be reproduced or published elsewhere without proper attribution.