When Projects Stopped Having End Dates
We wrap the unfinishable in the ceremony of the finishable.
Executive Summary
For as long as our profession has had a vocabulary, a project has been defined as a temporary endeavour with a beginning and an end, and a programme as the coordinated pursuit of a defined business change that is delivered and then closed. Almost every instrument of governance we possess, the business case, the stage gate, the benefits realisation plan, the closure report, the very distinction between change and business-as-usual, rests on the assumption that the work finishes. This essay argues that the assumption is quietly collapsing. The systems we now build, particularly those that face the customer, do not finish; they evolve continuously and are never done. As organisations begin to reorganise around persistent products rather than temporary projects, the end date, the load-bearing assumption beneath our entire model of governance, is being removed, and much of the apparatus built upon it no longer holds. What follows traces where this shift came from, examines what breaks when the end date goes, asks why the project construct nonetheless persists, and considers what programme management becomes when its central task is no longer to deliver a change and close it down, but to steward a capability that never stops changing.
The Definition We Built Everything On
Open any foundational text on project management and you will find, near the front, the same defining phrase in one form or another: a project is a temporary endeavour undertaken to create a unique product, service or result. The word that carries the weight is temporary. A project has a beginning and, more importantly, an end. It is this boundedness that distinguishes project work from the continuous operation of the business, and it is boundedness that our entire governance apparatus is designed to exploit.
Consider how much of what we do depends on the existence of an end. The business case forecasts a fixed investment against a stream of benefits that begin once the project delivers. The stage gate assumes a linear progression towards a defined completion, at which the temporary organisation is dissolved. Benefits realisation is timed from the moment of closure. The handover from programme to business-as-usual, the ceremonial transfer of a finished thing from those who built it to those who will run it, presupposes that there is a finished thing to hand over. Even the way we resource the work, assembling a team for the duration and disbanding it at the end, treats the endeavour as a scaffold to be erected and then removed. Remove the end date, and every one of these instruments loses its anchor.
For most of the history of the discipline, this caused no difficulty, because the things we built genuinely did finish. A new depot was commissioned and opened. A reorganisation was designed and implemented. Even a large computer system, once installed and stabilised, entered a maintenance phase that was modest relative to the effort of building it. The project ended, the team moved on, and the business ran what had been delivered. The temporary endeavour was an accurate description of the work.
The Software That Would Not Finish
Something has changed, and it has changed most visibly in the software that now sits between the organisation and its customers. A customer-facing digital service is not commissioned and opened in the way a depot is. It is released, and then released again, and again, in a rhythm measured in weeks and increasingly in days. It is never finished, because the standard against which it is judged, the expectations of the people using it, moves continuously, and a service that stops improving does not hold its position but loses it. The work of building such a service and the work of running it are no longer separable into a project phase followed by a maintenance phase. They are the same work, performed continuously by the same standing team, with no natural moment at which anyone can say that the endeavour is complete and the temporary organisation may be dissolved.
This is the observation that ought to trouble us more than it does. We have quietly acquired a category of work that violates the founding assumption of our discipline, and we have mostly responded by pretending it does not. We wrap the unfinishable in the ceremony of the finishable. We fund a continuous product as though it were a project, giving it a start date, an end date, and a business case that promises the funding will stop. We reach the nominal end, discover that the work plainly must continue, and launch a successor project, a phase two, a next release programme, each one a fresh temporary endeavour raised to disguise the fact that the work was never temporary at all. The organisation performs an elaborate accounting fiction, dividing a continuous stream of investment into a sequence of discrete projects, each with its own case, its own gates, and its own closure, none of which corresponds to anything real in the work itself.
“Go-live was never the end of the work. We have simply stopped being able to pretend otherwise.”
The End Date Was Always Partly a Fiction
It is worth pausing to notice that the end date was often something of a fiction even in the traditional world. The date on which a project formally closed was frequently an accounting convenience rather than a fact about the work. Benefits typically began to accrue long after closure, and continued for years; defects and enhancements continued too, rebadged as maintenance to keep them off the project’s books. The temporary endeavour was always, in part, a way of drawing a fundable boundary around an inherently continuous flow of organisational effort. What the rise of continuous digital services has done is not to introduce a wholly new kind of work, but to make the fiction impossible to sustain. When the interval between releases was measured in years, the pretence that each release was a discrete, closable project was harmless enough. When the interval falls to a fortnight, the pretence becomes absurd, and the machinery built upon it begins visibly to grind.
What Breaks When the End Date Goes
Consider what actually breaks when the end date is removed. The business case, first of all, has no idea what to do with open-ended funding. It is constructed to compare a bounded investment against a bounded return, and it has no natural way to justify a commitment that, by its nature, does not stop. Faced with this, organisations either force the continuous work back into an artificial boundary, funding it a project at a time and re-arguing the case at each renewal, or they abandon rigour altogether and fund the team on faith, with none of the discipline that the business case was supposed to impose. Benefits realisation suffers a similar fate. Designed to be measured from a moment of completion, it has no obvious foothold when there is no completion, and the honest tracking of value against investment, never our strongest discipline in the best of times, tends simply to lapse.
The accounting treatment is a particular and underappreciated casualty. A great deal of the effort to build a system has traditionally been capitalised, treated as the creation of an asset, on the reasoning that it is a one-off act of construction with an enduring result. Continuous development strains this reasoning to breaking point. When a standing team improves a product every fortnight, indefinitely, the neat distinction between building the asset and maintaining it dissolves, and with it the basis on which the work was capitalised. This is not a trivial technicality; it changes how the work appears in the accounts, how it is taxed, and how its cost is perceived by those who hold the budget. The organisation’s financial machinery was built for projects, and it registers a persistent product as an anomaly.
Then there is the disappearance of the handover. The transfer from the temporary organisation that builds to the permanent one that runs has been, for decades, one of the central rituals of programme management, complete with acceptance criteria, operational readiness reviews, and the formal acceptance of ownership. When the people who build the service are the people who run it, and when building and running are the same continuous activity, the handover has nothing to transfer and no gap to bridge. An entire body of practice, elaborate and carefully refined, is quietly rendered pointless, and the governance model loses one of its most reliable control points.
| Project logic | Product logic |
|---|---|
| Temporary endeavour with a defined end | Persistent activity with no end in sight |
| Funded as a bounded investment | Funded as a continuous commitment |
| Team assembled, then disbanded | Standing team held together over time |
| Benefits realised after closure | Value delivered and measured continuously |
| Build, then hand over to run | Building and running are one activity |
| Governed by stage and gate | Governed by flow and outcome |
Why the Project Refuses to Die
If the mismatch is this severe, an obvious question arises: why does the project construct persist? Why, given that so much of the work no longer fits, do organisations continue to force it into the shape of temporary projects? The answer is that the project is not an isolated idea but the keystone of an entire structure, and the structure holds it in place regardless of whether it still fits the work.
The most powerful of these structural forces is the annual budget cycle. Organisations allocate money once a year, in discrete lumps, against defined commitments, and the project is the natural unit of such allocation, being precisely a defined commitment of bounded size. A continuous product, which asks for a standing commitment renewed indefinitely, sits awkwardly against a budgeting rhythm designed to divide, allocate, and reconcile in annual portions. So long as money is released in this way, there is enormous pressure to package continuous work as a sequence of fundable projects, whatever the work actually is.
Procurement exerts the same pull. Contracts, particularly with external suppliers, are built around defined deliverables accepted at defined milestones, because that is what can be specified, priced, and enforced. A contract to improve something continuously and indefinitely is far harder to write and far harder to hold anyone to, so the commercial machinery pushes relentlessly towards fixed scope and fixed end dates. And behind both budget and procurement sits the simple comfort of the bounded. A defined scope with a defined end is reassuring. It can be planned, tracked, and reported. It offers the governing body the feeling, however illusory, of control. The open-ended offers no such comfort, and organisations, understandably, prefer the reassurance of a plan that ends to the honesty of work that does not.
The project persists not because it fits the work, but because everything around it, the budget cycle, the procurement model, the governance calendar, the careers built on gates and closures, is constructed to its shape. To let go of the project is to disturb all of it at once.
Tracing the Roots
It helps to trace where the shift came from, because it did not arrive from nowhere. The roots lie in software itself. Software was always the awkward case, the deliverable that refused to stay finished; maintenance, enhancement, and defect correction always continued long after the notional end, and every experienced hand knew that go-live was a beginning as much as an end. For years this was managed as an exception, contained within a maintenance budget and kept to the margins of the project model. What has changed is scale and centrality. When software moved from the back office to the very front of the organisation, from the thing that supported the business to the thing through which the business meets its customers, the awkward exception moved to the centre of the enterprise, and its refusal to finish could no longer be treated as a marginal accounting matter.
Alongside this came a change in how software was built. The move towards iterative and incremental delivery, towards releasing small increments frequently rather than delivering a complete system at a single distant point, had been gathering force for over a decade, and it carried an implication that took longer to absorb than the practice itself. If you release continuously, you are never done by definition, and the temporary team assembled to reach a fixed endpoint gives way naturally to a standing team that maintains a continuous flow. The practice of continuous delivery quietly dismantled the project’s endpoint, and the disciplines of product management, imported from the world of consumer software where products are tended and evolved rather than delivered and closed, supplied a ready-made language for work that is stewarded indefinitely rather than completed. The pieces of a different model were assembling themselves, often faster in the engineering room than in the governance committee, which is precisely why the two are now so visibly out of step.
What Programme Management Becomes
What, then, does programme management become when the end date is gone? It does not become unnecessary; the need to align investment with strategy, to coordinate across teams, to hold the whole to account for the value it produces, is if anything greater when the work never stops and never presents a natural moment of reckoning. But its centre of gravity moves. Its task is no longer to deliver a defined change and close it down, but to steward a persistent capability over time. The fundamental unit of funding and governance shifts from the project to the product, or to the broader stream of value a set of products serves, and money is committed to a standing team pursuing an enduring objective rather than to a temporary endeavour pursuing a fixed deliverable.
The instruments change with it. In place of the stage gate, which asks whether a temporary endeavour may proceed to its next defined phase, comes a lighter, more frequent review that asks whether a continuing investment still deserves to continue, and that is willing to redirect or stop it not at predetermined gates but whenever the evidence warrants. In place of a business case argued once and then treated as settled, comes a living case, revisited as the product and its context evolve, holding the standing team to a continuing account for the value it returns. In place of benefits realised in a single burst after closure, comes value measured continuously as it is delivered, which demands a far more honest and immediate relationship with outcomes than the comfortable distance of a post-closure benefits review ever required. The programme manager ceases to be the builder of a temporary organisation and becomes the steward of a permanent one, less the constructor of a scaffold to be removed than the custodian of a garden that must be tended without end.
Governing What Does Not Finish
None of this is yet the settled practice of the field, and the transition is neither smooth nor complete. Most organisations today are caught between the two models, running continuous products through governance built for temporary projects, and paying for the mismatch in fictional closures, artificial phases, and the slow erosion of the very disciplines the project model was meant to enforce. The task of the coming years is not to abandon the accumulated wisdom of programme management, much of which concerns the coordination of complex work and the honest tracking of value, and is as relevant to a persistent product as it ever was to a temporary project. The task is to detach that wisdom from the assumption of an ending to which it has been bound, and to rebuild it around the more demanding truth that the most important work an organisation now does is work that does not, and will not, finish.
The end date, in the end, was never really structure. It was scaffolding, a temporary convenience we erected around continuous organisational effort so that we could fund it, govern it, and reassure ourselves that we were in control of it. The scaffolding served us well for a long time, and there is no shame in having relied upon it. But the building beneath it has turned out to be a living thing that grows and changes and is never complete, and the scaffolding has begun to obscure more than it supports. Learning to govern what does not finish, without the false comfort of a date on which it will, is the discipline the next era of our profession will be built upon.