What the contract doesn’t see

We delivered on time. We delivered the quality we had promised. The client signed off, the payment arrived and the project closed green. Months later, in a casual conversation, someone mentioned that the courses we had built had probably never been opened to the people they were made for. A year after that we got a message about problems with the platform: the courses were still there, finished, never fully loaded. We found no record of a single cohort taking them.

No report said so. No indicator turned red. By every management instrument, that project was a success. By the only question that mattered, did it reach people?, nobody knows.

For years I have led projects for cooperation agencies and government bodies across Latin America, from Innovahub. This piece comes out of that discomfort: the distance between fulfilling a contract and changing something. It is not an academic study. It is a practitioner’s essay, built on three real experiences, told without the names of people or projects, and on what others have already researched about why so many development projects deliver and don’t transform.

00 — Before we startHome cooking

There are two easy ways to get cooperation and government projects wrong.

The first is the Michelin-star kitchen: methodology served on huge plates in tiny portions. A plan to manage every plan, forty-row matrices, reports nobody reads, certifications displayed more than they are used. It costs a fortune and you leave the table hungry.

The second is street food: “we’ll figure it out as we go”, the spreadsheet only one person understands, the schedule that lives in the coordinator’s head. Fast, cheap and convenient. And sometimes it leaves a painful memory.

What I propose is home cooking. Prepared with judgement, with real ingredients, in the right amount. In project management that means something concrete: take from the formal methods what earns its place at the table, leave the rest, and never lose sight of who you are cooking for.

01 — The problemDelivering is not transforming

Anyone who has worked in cooperation knows the logframe chain: inputs, activities, outputs, outcomes, impact. It is a good tool. But it hides a trap that is rarely named: the contract ends at outputs, and the project exists for outcomes.

Implementers are paid to deliver courses, platforms, documents, workshops. They are assessed on time, cost and scope. What happens afterwards (whether the courses are opened, the platforms used, the workshops change a decision) falls into territory that nobody fully owns: the implementer has closed, the contracting body has other urgencies, and the donor reads the final report.

The project-success literature has long distinguished between project management success (time, cost, scope) and project success (achieving what the project exists for). Lavagnon Ika, one of the few scholars who studies project management in international development systematically, has shown that in this sector the gap between the two is especially wide, and that much of the explanation is not technical: it lies in incentives, in the distance between those who fund and those who receive, and in the pressure to show outputs.

The contract pays for outputs. The project exists for outcomes. Between them lies a gap that nobody owns.

That gap is not closed with more methodology. It is closed by looking, from day one, at what the contract doesn’t see.

02 — Three experiencesWhere this comes from

Cases before ideas. All three are e-learning and institutional-strengthening projects that I led or worked on closely.

The first was a large-scale international initiative, funded through cooperation and implemented with several agencies and government institutions. We built a broad set of online courses and learning resources on sensitive topics. We had an excellent counterpart. And the work came as the initiative was nearing its end.

The second was for a national public body that needed to train thousands of staff on complex topics. A programme of online courses with many components, dozens of deliverables and a deadline that had to be extended. Months of very intense work. Those courses are in use today.

The third was a multi-year programme with local governments: training public officials to bring an international development framework into their government plans, with targets and indicators. Some experiences were very good; others did not work.

None of them failed on the contract’s terms. All three teach something about what happens outside it.

03 — What goes unseenSeven forces that move a project

None of these forces appears in the schedule. All of them move it more than the schedule does.

1. The money running out

When an initiative nears its close, the goal changes without anyone declaring it. Same logframe, same indicators, same name. But what is being pursued is no longer change in a population: it is spending the budget before a date.

That happened in the first case. We had to deliver no matter what, on very tight timelines, with pressure from the client and from the funder behind it. The author content, written by specialists hired by the client itself, arrived late: the last pieces reached us with very little contract left. Invoicing dates, on the other hand, were fixed. Some products were signed off after the contract’s end date. We delivered. But we delivered on a project that had become, in practice, a budget-execution exercise. The products were born with no budget for what came next: promoting them, opening them, supporting the people who would take them.

What goes unseen: the pressure to spend and the pressure to transform do not always pull in the same direction. When they collide, the first almost always wins, because it is the one with a deadline.

2. The orphan deliverable

Compare the first two cases. Both were high-quality online courses on similar topics. One is in use; of the other we know nothing. The difference was not the product. It was that one had an owner and a path to use, and the other did not.

In the second case, the contracting body was the same one that had the platform, the audience, the mandate to train and the obligation to account for it. The course had somewhere to land before it existed. In the first case, the product was handed to an initiative that was about to end, with no institution adopting it as its own.

What goes unseen: an approved deliverable with nobody to use, maintain and defend it after closure is an asset that starts losing value the day it is signed off.

3. The calendar that isn’t in the schedule

Schedules are built in weeks and months. Institutions live in terms of office, fiscal years, planning cycles, electoral seasons and recesses.

The third case showed this clearly. Where training coincided with the moment local governments were drafting their plans, it worked very well: what people learned they applied that same week to a document they had to submit. Where it arrived at another time, the same course with the same content was a formality.

In the second case, election-period contracting restrictions and a change of government held up payments for a while. They were later released. The project had no technical problem; it had a calendar problem.

What goes unseen: institutional timing weighs more than product quality. The same deliverable is worth a great deal or almost nothing depending on when it arrives.

4. People who change

In the first case we had one of the best counterparts I have ever worked with. One person centralised communication, compiled comments from every institution, and left no room for doubt in approvals or in sending inputs. She built trust towards her organisation and towards us as providers. If that project delivered on impossible timelines, it was largely thanks to her.

That is the good news. The bad news is its flip side: a focal point like that is also a single point of failure. In the third case there were staff changes throughout the programme, and each one meant rebuilding context, agreements and trust. In government, turnover is not an exception: it is part of the climate.

What goes unseen: a project’s most powerful accelerator appears on no organisation chart, and almost never has a replacement ready.

5. The wrong audience

In the third case there were groups where some participants attended to meet a training quota their institution required. There were spaces that included youth groups with topics that were not close to them. And there was fatigue: packed webinars and great interest at the start; months later, weariness.

They were not bad courses. They were good courses for the wrong people, or at the wrong time.

What goes unseen: choosing who takes part usually falls outside the designer’s reach, and it is one of the decisions that most shapes the result.

6. Review rounds

Nobody budgets for review rounds. The contract says the client has five days to review each deliverable, and the plan assumes they will review once. Reality is different: late comments, reviewers who join halfway, contradictory feedback across institutions, acceptance criteria discovered during review. In the first case, the terms of reference required incorporating comments from several organisations and counterparts; review emails ran into the dozens, and some changes arrived when everything seemed closed. In our internal evaluation at the end, the team said it plainly: we were missing a phase between writing the content and scripting it, and we paid for it in rounds.

In the second case we measured it. In one of the stages, deliverables spent longer waiting for review than it had taken to produce them. The odd thing is that quality was not the problem: the vast majority were approved without adjustments or after a single round. The problem was the wait. One of the reasons we requested the extension was precisely to avoid saturating the institution’s review capacity.

And the wait does not stay in the schedule: it moves into cash flow. Each payment depended on a whole stage being approved, so a single pending deliverable held back payment for the whole stage. One of those payments arrived months later than planned. During that time, the company financed the work with its own funds. That does not appear in any logframe either: the implementer of a development project is often also financing it, without anyone having decided so.

What goes unseen: much of a project’s delay lies not in production but in approval, and it is almost never measured.

7. The invisible hero

In the second case I am proud of something that also worries me. For months, many people on the team worked on products that were not theirs, because there was no time, because resources fell short, because someone had to do it. We delivered very high-quality products. And we did it, in part, thanks to an effort that was in no plan. Our own risk register said it: team capacity above 95%.

In 1967, the economist Albert Hirschman observed development projects in the field and described what he called the hiding hand: we tend to underestimate a project’s difficulties, but we also underestimate our ability to solve them, and one offsets the other. Decades later, Bent Flyvbjerg and Cass Sunstein looked at data from more than two thousand projects and found that the hand is often not benevolent: underestimation repeats itself, and creativity does not always make up for it.

The hero is the hiding hand in flesh and blood. They hold the project up, do not appear in the report, are not invoiced and cannot be repeated indefinitely.

What goes unseen: if a project only succeeds thanks to heroes, it was not a good plan. It was a good team covering for a bad plan.

04 — From the formal kitchenWhat actually works from PMBOK and PRINCE2

None of this is an argument against formal project management. It is an argument against using it as ceremony. The PMBOK Guide, in its seventh edition, has already moved from processes to principles and value delivery. PRINCE2 is built on seven principles, several of which speak directly to the forces described above. This is what I bring to the table:

• Continued business justification (PRINCE2). A project must keep making sense at every stage, not only at signature. In cooperation the question takes a concrete form: is there still someone who will use this?
• Focus on products (PRINCE2). Before producing, describe each deliverable: what it is for, what criteria it must meet to be accepted, who approves it. This practice alone removes a good share of review rounds.
• Manage by stages (PRINCE2). Split the project into stages with a decision point at the end of each. In a fixed contract, those gates are the only honest place where adaptation fits.
• Manage by exception (PRINCE2). Agree tolerances for time, cost and scope, and escalate only when they are exceeded. Fewer status meetings, more timely decisions.
• Stakeholder register (PMBOK). Including those who don’t sign: the population, the end users, whoever will maintain the product when we are gone.
• One-page risk register (PMBOK). With calendar and political risks at the top, not at the bottom of the list.
• Change control (both). Written, simple, with its impact on time and cost. Not to defend yourself from the client, but so that both sides know what is being decided.
• Learn from experience (PRINCE2). Lessons learned are read at the start of the next project, not written at the end of this one to be filed away.

And this is what I leave in the kitchen: management plans for every plan, forty-row responsibility matrices, weekly reports nobody answers, templates filled in because they exist, and the idea that more documentation means more control.

The methodology is the recipe. The point is that someone gets to eat.

05 — The proposalSix principles, one tool each

This is the recipe. Six principles drawn from the seven forces, each with a single tool light enough to actually be used.

1. Start with use, not with the product

Before designing a deliverable, answer in writing who will use it, when, through which channel, and who takes charge of it after closure. If there is no answer, that is the project’s first risk, and it must be said out loud, however uncomfortable.

The tool: a one-page destination sheet for each major product, signed by whoever will adopt it.

2. Plan with the other side’s calendar

Before your own schedule, the institutional calendar: elections and contracting restrictions, fiscal year-ends, planning cycles, recesses, changes of administration. Then the schedule adapts to that, not the other way round.

The tool: an institutional timeline on the same page as the schedule, reviewed at every decision point.

3. Agree what “done” means before you start

Every deliverable with its acceptance criteria, the name of its reviewer, the review period and the number of rounds included. Anything beyond that is a change, and is treated as one.

The tool: the PRINCE2 product description, cut down to half a page.

4. Measure to decide, not to report

In the second case, the dashboard we used to run the project ended up being used by the institution for its own accountability, and the institution then asked for it to run its own projects. Not because of its design. Because it measured few things, the same ones the client needed to see: progress weighted by status, deliverables in review, payments unlocked, alerts. It also had classic earned-value indicators, such as the schedule performance index, but what people looked at most was the simplest: how much was approved, and what was waiting on whom.

The tool: a dashboard of no more than five or six indicators, shared with the client, that answers one question: what do we need to decide this week?

5. Protect the human bridge

Explicitly recognise the focal-point role, on the client’s side and on yours. Give it what it needs to work and prepare its replacement before you need one: a living summary of the project, the agreements made and the decisions pending, so that turnover costs days rather than months.

The tool: a handover folder of no more than three pages, updated at every decision point.

6. Budget for reality, not heroism

Put in the plan what always happens: review rounds, adjustments, approval delays, time for handover. And be wary of any plan that only works if the team gives its best every single day. If heroes appear halfway through, the job is not to applaud them: it is to revisit the plan.

The tool: an explicit time and cost reserve, visible to the client, with clear rules for its use.

06 — LimitsWhere this proposal falls short

It would be dishonest to finish without saying what this does not solve.

• It does not fix a badly designed project. If the problem was poorly framed in the proposal, better management only lets you be wrong in a more orderly way.
• The implementer does not control use. It can make use visible, insist, put it in writing. It cannot force an institution to adopt what it received.
• It needs a willing client. Some of these tools are uncomfortable, because they force people to say out loud what everyone knows and nobody writes down.
• It does not guarantee impact. Impact depends on many things no project team controls. What we can do is stop getting in its way.

07 — In conversationNot the first to say it

There is serious work in this field, and it deserves recognition. The PMD Pro guide, from PM4NGOs, adapts formal project management to the development sector in a practical, free way. Problem-Driven Iterative Adaptation (PDIA), from Matt Andrews, Lant Pritchett and Michael Woolcock, proposes solving concrete problems in short cycles instead of importing solutions. And the adaptive-management movement in cooperation has pushed the idea of learning and adjusting along the way.

What this piece tries to add is a point of view that is rarely written down: that of the implementer, inside a fixed contract, with a fixed budget, agreed scope and someone else’s calendar. From that seat you cannot always iterate as you would like. But you can manage with your eyes on what lies beyond the contract.

I cannot promise a project will go well. Nobody can. What I can do is look at what the contract doesn’t see, say it in time, and organise the work so that what matters has a chance.

That is home cooking: nothing spectacular, nothing improvised. Real ingredients, prepared with judgement, so that they nourish. In the end, a project is not measured by what we delivered. It is measured by what someone was able to do with it.

Delivery is not the end. It is the halfway point.

The recipe on one page: a printable sheet with the six principles and their tools ↗