Accountable design—Part 2: Tracing accountability

by David Week on 12 September 2010


Maps of accountability

In my first post on “accountable design”, I put forward the key question: “cui bono”… who benefits from the design?

Of course the question of accountability is not new in Western civilisation. It’s as old as… well… accounting. But over time, the accountability question has slipped further into the future.

  • The earliest forms of accountability, reflected in today’s basic bookkeeping, revolve around “who did you give the money to?” This accountability for expenditure. But this tells us nothing about whether that expenditure was a good idea or not. Therefore, we developed…
  • Program or project accountability… which asks, “how did this payment relate to program or project objectives?”
  • Further down the track lie outcome and impact accountability.

But let’s for the time being focus on program or project accountability, since this is well established, and has been well worked. out.


I first encountered the LOGFRAME in 1992, on the Kandrian-Gloucester Integrated Development Project (KGIDP). When I first heard the phrase, as an architect, it brought to mind something like this:

I kid you not. But I soon learned that it stood for Logical Framework… which still seemed a little grandiose, as though all other possible frameworks were ILLOGFRAMES: Illogical Frameworks.

A LOGFRAME is simply a set of relationships which tie all the factors of a project together, and relate them to a clear project GOAL.


The cartoon at left comes from a very fine explanation and tutorial of the LOGFRAME methodology, published by IFAD: the International Fund for Agricultural Development. The LOGFRAME has become the standard for planning and monitoring of international development projects. The LOGFRAME operates hierarchically.

  1. At the top, there is the GOAL: the overall development objective like “better education” or “improved health for mine workers.”
  2. But a project is specific, and doesn’t address the whole development objective en toto. It tackles a piece of it. This more limited goal is called the project’s PURPOSE.
  3. Okay, that’s nice. But in fulfilling the project’s purpose, what are you going to do? What are you going to produce? The answer to this question becomes the project’s OUTPUTS.
  4. How are you going to produce these outputs? Well, you have to do stuff. The stuff you do to produce the outputs are termed the project’s ACTIVITIES.
  5. And in order to undertake those ACTIVITIES you need to have INPUTS, which might be people, trucks, airfares, etc.
  6. And as one goes further down the hierarchy of the LOGFRAME, one can produce further levels of details, such as:
  • COSTS: how much all those inputs are going to cost the funder
  • ANNUAL PLANS: what activities you are going to do in a given year
  • VERIFIABLE INDICATORS: what the evaluators, when they come, should look at to see what happened at each level of the hierarchy.

IFAD have documented a detailed example here. AusAID‘s manual is here.

Project Management Planning

To architects, the LOGFRAME may sound vaguely familiar. This is because almost all project planning follows a similar structure. High level goals and objectives are broken down into pieces (the WBS, or work breakdown schedule), and these bits of work are costed and scheduled. Scheduling is usually presented in the form of the Gantt Chart. From the WBS, one can also resource and cost the project, and thus—again—build up a detailed picture of how every input contributes to the project result.

For project management, the hierarchy is usually:

  • Project
  • Milestones (intermediate outputs)
  • Activities
  • Resources
  • Costs

The Work Breakdown Structure is a parallel hierarchy, which shows have various kind of work map onto the Activities.

Both the LOGFRAME and conventional construction planning show hierarchical networks of accountability which—among other things—show how various inputs are tied to the production of an output. If you want to spend project money on “Tickets to Disneyland”, you have to show how those tickets are necessary Input to an Activity which produces an Output which is part of the Purpose of the Project, and serves the Goal. Otherwise, you’re in trouble.

Critiques of the LOGFRAME approach

There are numerous critiques of the LOGFRAME approach. Here are mine, not necessarily original:


Once you’ve set up this hierarchical machinery, and set it into motion, it’s very difficult to change direction. If on Day 7, you realise that the Goal is misguided and the Activities don’t properly link to the Outputs, it’s rare to change what’s happening until the next Annual Plan, or even the Mid Term Review.

A famous case of a project which steamrolled ahead towards an ill-councieved Goal was the Great Groundnut Scheme, which began as “an idea to cultivate groundnuts in the British protectorate of Tanganyika”, but with the result that “the total cost over the years had risen to £49 million… only 2000 tons of groundnuts were harvested… and the land had been ruined in the process, leaving it an unusable dust-bowl.”


I have nothing against hierarchy per se, but as Chris Alexander spelled out in A City Is Not a Tree, hierarchical structures are simply not rich enough to capture all of connections that are relevant to human society or endeavours. For instance, in a typical LOGFRAME, buildings will be placed down as OUTPUTS, necessary for a PURPOSE. The GOAL might be better education, the PURPOSE might be to extend education to remote parts of the country, and the OUTPUT might be 400 new schools in the remotest and poorest districts.

That’s a laudable aim by itself, but the problem is that it doesn’t look at any of the other possible outcomes of such a construction program, such as:

  • building local contractor capacity
  • building local skills and materials production
  • building local ownership and confidence
  • flowing cash into the poorest districts.

Since these outcomes are not part of the project GOAL or PURPOSE, they are invisible, with the result that the project managers don’t exploit them, and they don’t happen. This is a wasted opportunity.

Reinventing the wheel

According to the wikipedia article on the LOGFRAME:

The Logical Framework Approach (LFA) is a management tool mainly used in the design, monitoring and evaluation of international development projects. It is also widely known as Goal Oriented Project Planning (GOPP) or Objectives Oriented Project Planning (OOPP).


The Logical Framework Approach (Rosenberg & Posner, 1979) was developed by Practical Concepts Incorporated in 1969 for the United States Agency for International Development (USAID).

In comparison:

  • The Gantt chart was invented in 1910
  • Eisenhower planned the Allied invasion of Europe in 1944
  • 10 years of NASA effort resulted in the first manned moon landing in 1969.

Yet it appears that none of these efforts or innovations were incorporated into LOGFRAME—least of all the humble Gantt Chart.

Cumbersome and Counter-intuitive

A convensional project management document looks like this:

A typical LOGFRAME looks like this:

In the first diagram—if you use the tool right—all of the relationships and the hierarchy can be shown on one page, graphically. Furthermore, it’s easy to answer the question: “What are we doing on Monday.”

That’s not true of the LOGFRAME.

There are no people

But the crucial flaw in both of these tools is that there are no people in them, other than—occasionally—as “resources” or “inputs”.

But development is all about people, and the development process is a joint one which involves dialogue with counterparts. Both the tools above—LOGFRAME and conventional project management—succeed in tying inputs to results, and thus setting up  a framework for accountability. Both fail in that they squeeze people right out of the project picture.

They fail in different ways.

  • The LOGFRAME fails by supplanting people with abstractions: “goals” and “objectives”. In practice these abstractions become reified (treated as real things) and personified (they taken on the attributes of people). Thus, the managers focus on the abstractions, and start saying things like: “the objectives demand that we do such and such.” But in fact objectives are abstractions, and don’t demand anything. People demand things. The LOGFRAME is too abstract. It replaces people with abstractions.
  • The conventional project plan, though it has certain advantages over the LOGFRAME, does the opposite. The output of the project is usually very clear, and its something like: classrooms, textbooks, new curricula, trained teachers. The conventional project plan is too concrete. It either replaces people with things (buildings, textbooks), or—in the case of “trained teachers”—objectifies people into outputs.

What we need is a way of designing programs and buildings, which takes as central the human beings we are working with: the stakeholders. That will be the subject of Accountable design—Part 3: Design for stakeholders.

Previous post:

Next post: