Logical framework matrix for business support programs: how to build one that works

Key Takeaways

• The logical framework is a method for planning a program from the problem it solves, and the four-by-four matrix is its summary. The European Commission describes it as an aid to thinking (Project Cycle Management Guidelines, 2004).
• Each matrix has a single purpose. It is the change the program seeks in companies, and it lies outside the operator's direct control; the operator answers for the outputs (Economic Commission for Latin America and the Caribbean, ECLAC, Metodología del marco lógico, 2005).
• In Colombia, the General Adjusted Methodology (MGA) of the National Planning Department (DNP) builds on the logical framework. Its value chain summarizes the vertical logic of the matrix, and what the logframe calls components, the MGA treats as products.
• The assumptions column is usually the least worked, and in a business program it is where the risk sits. In weak logframes it becomes the "too hard" column, according to Isabel Vogel's review for UK aid (DFID, 2012).
• A matrix that is not revised during implementation becomes a straitjacket. The Inter-American Development Bank (IDB) already asked in 1997 for it to be modified several times, during preparation and implementation.

Almost every business support program funded with public or donor money ends up with a logical framework matrix. The multilateral bank asks for it, Colombia's DNP asks for it through the MGA, or the committee that approves the budget asks for it. Often it gets filled in at the end, once the design has been decided, just to meet the requirement.

This guide is for the people who have to build it and want it to be useful beyond passing the review: economic development departments, chambers of commerce, foundations, and program officers. It explains how to build it step by step for programs that work with companies, with a complete example and with the mistakes documented in the development cooperation literature that we have also run into while operating programs.

What is the logical framework?

The logical framework is a planning method that starts from a problem, turns it into objectives, and organizes the program as a verifiable chain of causes and effects. The result is summarized in a matrix with four rows (goal, purpose, outputs or components, and activities) and four columns (narrative summary, indicators, means of verification, and assumptions).

According to the European Commission, it was developed in the late 1960s to help the US Agency for International Development (USAID) plan and evaluate its projects better, and the Commission itself has required it in its project cycle since 1993. The ECLAC manual presents it as a response to three problems that are still common: multiple objectives that do not connect to activities, unclear responsibilities for whoever manages the program, and no clear picture of what success would look like.

Two things are often confused. The logical framework approach is the analysis process: who is involved, what the problem is, which objectives follow, and which strategy is chosen. The matrix is the document that summarizes that analysis. When the matrix is filled in without doing the analysis, the document looks tidy and says nothing.

The columns answer four questions for each row: what is sought (narrative summary), how you know it was achieved (indicators), where the data comes from (means of verification), and what has to happen outside the program for it to work (assumptions).

The matrix is read in two directions. The vertical logic runs from bottom to top: if the activities are carried out and their assumptions hold, the outputs are produced; if the outputs are produced and their assumptions hold, the purpose is achieved; and if the purpose is achieved and its assumptions hold, the program contributes to the goal. The horizontal logic runs across each row: what you want to achieve, how it is measured, and where the data comes from.

How does it relate to Colombia's value chain and MGA?

In Colombia, the logical framework usually arrives through the General Adjusted Methodology (MGA), the tool used to formulate and register public investment projects. The DNP's conceptual manual says the MGA builds on the logical framework and that the value chain summarizes the vertical structure of the matrix.

The practical equivalence is this: the central problem of the problem tree becomes the general objective, its causes become specific objectives, and the logframe's components are treated as the products of the value chain. The DNP value chain guide also requires at least two activities per product, and warns about a common mistake when writing the general objective: putting the solution or the targets in it.

There is a practical detail worth knowing before you write the outputs. In the MGA, products are not written freely: they are chosen from the sector's product catalog, and each one comes with standardized indicators. Check that catalog first, so the deliverables you will pay the operator for match a product that can be registered.

For anyone formulating a business program with Colombian public funds, this means the logframe work is done once and feeds both documents: the matrix a donor asks for and the value chain the MGA requires.

Why are so many logframes useless for managing the program?

Many logframes are useless for management because they are filled in at the end, to meet the requirement, and never reopened during implementation. Des Gasper (2000), who studied how the method is used in development cooperation, describes two vices: filling in boxes without precise logic, and freezing the matrix as a tool for upward accountability.

The review Oliver Bakewell and Anne Garbutt did for Sida in 2005 found the same in practice: in theory the matrix could be revised during the cycle, and it rarely was. They describe a partner in Central America that felt obliged to build a building included in the matrix even though the business that justified it was losing money, until it asked for permission to postpone construction. When the matrix becomes a contract, changing it feels like a breach.

There is a third, quieter problem. Isabel Vogel's review for UK aid (DFID, 2012) found that, in weak logframes, the assumptions column had become the "too hard" column. In a business program that column holds almost all the risk, because it is where you write down, or fail to write down, what has to happen for a company that receives a plan to carry it out.

How to build the logical framework of a business program step by step

If you already have the program's theory of change, steps 1 to 3 come from it: the situation analysis is your problem tree and the direct change is your purpose. If you do not have one, these steps give you a minimal version. Come to the workshop with data on the segment you will serve, the list of stakeholders (funder, likely operator, business owners), and the matrix format your funder requires.

1. Build the problem tree with people who know the companies

The ECLAC manual warns that the matrix reflects the analysis behind it, which is why the work starts here. The problem tree puts the problem the program wants to solve at the center, its causes below and its effects above. ECLAC recommends building it in a workshop with stakeholders, and in a business program that includes owners from the target segment and whoever will operate the program.

The typical mistake is to write the absence of the solution as the problem: "companies lack access to advisory services." That already has the program built in. The problem is what happens to the company: "companies in the sector do not sell outside their city," and lack of advice will be one possible cause among several.

2. Turn the tree into objectives and decide which branches you address

Each negative state in the tree is rewritten as a positive one, so the central problem becomes the general objective and its causes become specific objectives. A program can rarely address every cause, so this is the moment to choose.

Also write down which causes are left out and who addresses them. If the main reason companies do not export is a customs procedure the program does not touch, no amount of mentoring will make up for it, and it is better for the matrix to say so from the start.

3. Write a single purpose, in terms of what changes in companies

The purpose is the change the program expects to see in participating companies, and ECLAC and the IDB ask for one per matrix. In the MGA it plays the role of the general objective: it is the same sentence. It must be verifiable at the company: "participating companies sell through at least one online channel of their own" can be checked; "strengthen the digital capabilities of the business fabric" cannot.

The purpose lies outside the operator's direct control, because it depends on what companies decide. That is why the operator answers for the outputs and the program as a whole answers for the purpose. If the purpose is well written, it is the same sentence that appears as the expected change in the program design, and it is the starting point of the theory of change.

4. Define outputs as deliverables the operator controls

Outputs are what the program delivers: a diagnostic validated with the company, an approved action plan, a completed mentoring process, a schedule of commercial meetings. They are under the operator's control, which makes them the natural basis for paying the operator. If the funder wants to tie part of the payment to milestones in the companies, those milestones come from the purpose indicator, with the way they will be verified defined from the start.

Each output must be necessary for the purpose, and together they must be sufficient. If removing an output leaves the purpose just as achievable, it is redundant. If, with all of them in place, the purpose still depends on something nobody delivers, one is missing. When the matrix feeds procurement, these outputs are the ones to turn into deliverables in the operator's terms of reference.

5. List activities without locking in the methodology

Activities are what has to be done to produce each output. In the ECLAC format, the indicators cell of this row holds the budget for each activity. The DNP guide requires at least two activities per product.

Describe them at the level the budget needs and no more. Cost can be estimated per deliverable and per company (validated diagnostic, approved plan, completed mentoring) without turning that estimate into a mandatory number of sessions. Fixing sessions or hours per company in the matrix makes a methodological decision contractual, and the operator ends up meeting the input even when the company needs something else.

6. Write assumptions as "if... then" conditions

Assumptions are the conditions outside the program's control that must hold for each level to lead to the next. They are written as a chain: if the outputs are delivered and this condition also holds, then the purpose is achieved.

Business programs have assumptions that almost always apply and are almost never written down. That companies keep operating during the program. That the owner has time for the sessions. That there is demand for what they are being helped to sell. That the anchor company in a supplier program keeps buying. ECLAC suggests running each one through four questions: whether it is really outside the program's control, whether results depend on it, how likely it is to hold, and, if it is unlikely, whether the program can be redesigned. What the program controls is a design decision, not an assumption. What is almost certain does not need to be written. And what is important and unlikely is not solved by leaving it in the column: it needs an output that addresses it or a change in design.

7. Fill in indicators and means of verification for each row

Each row gets its indicators, specified in quantity, quality, and time, and the source the data comes from. ECLAC warns that purpose indicators should not be a summary of the outputs: counting delivered plans does not tell you whether companies changed anything.

Means of verification must be necessary and sufficient, and someone has to be responsible for producing them. If the purpose indicator requires going back to companies six months after closing, that measurement belongs in the activities and in the budget. How to write each indicator with its technical sheet is covered in indicators for business support programs.

8. Write down when and how the matrix will be revised

A 1997 IDB evaluation document, which the ECLAC manual cites and draws on for much of its explanation of the matrix, asked for it to be built with the implementing agency and modified repeatedly, during preparation and during implementation. The European Commission recommends revising it whenever new information appears.

Build one or two review points into the design (for example, once company selection is complete and halfway through implementation) and define who can approve changes to activities and outputs without touching the purpose.

Logframe matrix example: a supplier development program

Picture a program in which a large company and a chamber of commerce support small local suppliers so they can sell to the anchor company. Targets are in brackets because in a real matrix they are set against the baseline.

Notice three things. The purpose indicators measure audits passed and actual purchases, not delivered plans, and the purchasing measurement happens after closing, so it has to be budgeted. Each output has its own indicator, which is what later becomes a deliverable for the operator. And the output-level assumption, that the anchor company keeps buying, is the one that can bring down the whole program: it is worth turning it into a signed commitment before the open call.

Real case: advisors trained in artificial intelligence in Central America

In 2026 we designed and facilitated, for a development cooperation agency in Central America, an artificial intelligence training program for advisors at public support centers for micro and small enterprises. It shows in practice the difference between an output and a purpose, because the program could have been declared a success by looking only at the outputs row.

The target was to certify at least 75 advisors, and 117 were certified. That number is an output: the operator controls it, and it tells you the training was delivered. The purpose was something else: for advisors to improve the support they give to digital businesses and to companies in the cultural and creative industries. That is why each advisor was assessed on a real company from their portfolio, supported during the training, rather than on an exam. In this way, 79 creative businesses were supported, from handicraft workshops to dance companies.

Two assumptions were addressed from the design stage. The first was about the advisors' starting point: the entry diagnostic showed that half were at a very basic or basic digital level, so mentoring was done in small groups and ran alongside the training from the start. The second was that each advisor had a company to practice with, because without one the application would have been a made-up case.

If the report had covered only the outputs row, the program would have come in 56% above target and nobody would know whether any advisor changed the way they advise. The purpose row is the one that answers that question.

When should you build the theory of change before the matrix?

You should do it when the program depends on companies changing a practice, and almost every business program does. The matrix has one assumptions cell per row, and there is no room there to explain why a company that receives a plan carries it out. Vogel's review records divided views, although most interviewees found it useful to have both tools. The full comparison and the method for building one are in theory of change for business development programs.

Frequently asked questions about the logical framework in business programs

What is the difference between the goal and the purpose in a logframe matrix?

The purpose is the direct change the program seeks in the companies it serves, and the goal is the broader objective it contributes to along with other factors. The program answers for the purpose. The goal is stated to show where the program is heading, but it cannot be attributed to the program alone, and it is honest to say so.

What if the program has more than one purpose?

Use a master matrix for the program and a subordinate matrix for each line or project. The IDB described this arrangement in 1997: the goal of each subordinate matrix is the purpose of the overall program. That way each line keeps a single purpose and the program does not mix objectives that are measured differently.

Which indicators go in the purpose and which in the outputs?

Output indicators measure what the operator delivers, such as validated diagnostics or approved plans. Purpose indicators measure what changes in companies, such as purchases received or a practice still in place months later. If the purpose indicator is met just by adding up the outputs, it is at the wrong level.

Who should build a program's logical framework?

The funding institution should build it together with whoever will implement it, with input from companies in the target segment. If the operator has not been hired yet, it is worth validating the matrix with someone who has run a similar program before opening the call, because assumptions look different from the operating side.

How often should a logframe matrix be updated?

Whenever new information changes what was known at design, and at least at one or two points set from the start. Activities and outputs can be adjusted during implementation. The purpose should not change; if it has to, the program needs a redesign, not an update.

A matrix is worth the conversations it forces

A well-built logical framework matrix forces you to decide early what is expensive to decide late: the one change the program promises, what the operator delivers to achieve it, and what has to happen outside for it to work. When those decisions are written down, the matrix becomes a tool to manage the program month by month.

If you are formulating a program and want to review the matrix before presenting it to the funder or opening the operator's call, we can work on it with you in a design session.

Request a design session | How we work with institutions

Read also: How to design a business support program