Two kinds of commitment in one project

A funded research project lives in two worlds at the same time. On one side there are the deliverables: the results we promised the funding body in the grant application. Those are fixed, they are multi-year, and at the end of the project somebody checks whether we delivered them. On the other side there is the actual work of getting there, which in our case nobody can honestly plan in advance, because the project is built around learning what the target organisation needs.

The default mistake controlling makes, and it is an understandable one, is to treat both worlds as the same kind of plan. If the deliverables are fixed for six years, the reasoning goes, then surely the tickets can be too. Just break the big thing into smaller things and put dates on them. That works for building a bridge. It does not work when the project's mandate is to discover its own requirements as it runs.

Why a multi-year ticket plan is fiction

The project runs an assessment every two years, written into the application as a constitutive part of the mandate. Its explicit purpose is to tell us what the target organisation actually needs and what effect the work so far has had. We do not know the answer in advance.

If that is true, planning the implementation level across the full runtime is methodologically wrong. A six-year ticket plan would have to assume that we already know today what the assessment is supposed to teach us in year two and year four. Writing those tickets down would mean committing, on paper, to developing past the real need, which is the one thing the project is designed to avoid.

This is the part controlling found hardest to accept, and I understand why. "We cannot plan the work yet" sounds, to an auditor, like "we have no plan". So the job was to show that there is a great deal we can commit to – just not at the ticket level.

Three layers of commitment

The structure we proposed has three layers, and the point of the layering is that each layer carries a different kind of promise.

1. Deliverables are fixed. They come straight out of the grant application, they are multi-year, each one has a definition of done and a due quarter, and the steering committee formally accepts them. This is the anchor for any long-term planning the project needs. When somebody asks "what will exist at the end", the answer lives here, and it does not move.

2. Epics, or work packages, are self-defined and rolling. We organise them as a Now/Next/Later roadmap: Now holds the epics for the current quarter, Next holds the two quarters after that, Later holds themes we have not yet broken down. Each epic is linked to the deliverable it pays into. This is the layer the assessments are allowed to change, because this is the path to the deliverables, not the deliverables themselves.

3. Tickets are the operational decomposition of the current Now epics into work packages of one to four weeks. This is where the daily work happens, and it only ever exists for the current quarter. We do not write tickets for work we have not yet decided to do.

The direction is binding: the deliverables and the Later themes fix where we are going. The content is concretised as we go, on the one level where planning and learning can coexist.

The trust you actually deliver upward

The fear behind the waterfall request is legitimate: how does anyone above the project know the work is heading toward the agreed result? Our answer is a chain of verification.

The project goals and deliverables are fixed in the application. Deliverables are accepted by the steering committee, with an explicit accepted status that is separate from done. The roadmap is checked against the deliverables and released by the project lead every quarter. Tickets are verified for alignment with their epic and deliverable before anyone starts working on them. At every transition there is a mandated body that has checked and signed off.

So the promise upward changes. "We plan everything in advance" is unkeepable, and everybody senior enough knows it. What we promise instead is a documented, auditable decision process, run and accepted by the responsible bodies. In a research context that promise is institutionally normal, and it holds.

Why this audits better

The argument that finally landed was about auditability, because that is what controlling cares about, and on that ground the rolling approach wins outright.

Everything sits in Jira and in a roughly two-page quarterly report: deliverables with their status, due date and acceptance history; the current and historical state of the roadmap; tickets with their alignment note and done criterion; and the quarterly reports themselves, with planned-versus-completed epics, a target completion corridor of 70 to 85 percent, and every shifted, cut, or newly added epic written down with its reason (an assessment finding, a changed need, a technical insight).

You can therefore audit the project both synchronously, by asking what the state is right now, and diachronically, by following how it developed quarter over quarter. A fictional six-year ticket list can do neither. It records a plan and nothing else. It cannot record the deviation from the plan or the reason for it, because by the time reality diverges, the list is already wrong and quietly abandoned. The rolling roadmap records exactly that deviation and its justification, which is the part an auditor needs.

One thing the process deliberately does not do is track individual working time or measure the performance of single team members. That is personnel management, it belongs there, and a progress-reporting tool is the wrong instrument for it. Pointing it at individuals would only corrupt the data at the project level – the Goodhart effect in its purest form. The proof that the team works comes from the output: accepted deliverables, completed epics, tickets with documented alignment.

Summary

A research project owes its funding body fixed results, but it cannot honestly owe them a multi-year breakdown of the work, especially when the project is built to learn what that work should be. Separating the fixed layer (deliverables) from the rolling one (epics and tickets) lets both promises be true at once. What an auditor can actually check is the documented trail of decisions you took along the way, including the ones that changed your mind, not the plan you wrote at the start. By now I would push for this in any project where the requirements are discovered rather than known, public funding or not.