Every list contrasting projects with operations contains one attribute that has no counterpart on the other side. It is the one that costs you.
Open almost any introductory treatment of project management and you will find the same comparison table. Projects have temporary structures and goals; operations have established, ongoing ones. Projects are a catalyst for change; operations change evolutionarily. Projects produce something unique; operations produce something standard. Project teams are dynamic; operational teams are stable. Projects are flexible; operations are ongoing.
Then comes a sixth attribute on the project side: fixed start and end date. And nothing is written opposite it.
That empty cell is not sloppiness. It is the whole point. Operations do not end, which is why the comparison cannot pair the item. The defining property of the project form — the reason organisations reach for it — is that it is designed to dissolve. And the moment a structure is designed to dissolve, you have committed to a handover, whether or not anybody has planned one.
Most enterprises make that commitment dozens of times a year without ever pricing it.
The Strategic Context
The decision to put work into project form is made constantly and deliberated rarely. A capital initiative arrives, someone appoints a manager and a team, a charter is written, and the organisation proceeds as though the form were given rather than chosen.
The teaching literature goes further, describing an approach it calls management by projects: managing the whole business using projects as the means of achieving strategic goals, with organisations adopting it tending to define their business activities as projects and manage them accordingly. It is offered as a maturity position — an advanced way of running an enterprise.
It is worth treating as a genuine choice with genuine costs rather than as a destination. The project form buys real things: a bounded commitment, a named owner, a visible end point, a team assembled for a purpose and released afterwards, and — importantly — a decision point at which the organisation can stop. Those are considerable advantages, and for genuinely novel, bounded, time-limited work they are decisive.
But the same properties that make the form powerful make it expensive in ways that do not appear in the business case. The team disbands. The knowledge disperses. The structure that understood the work ceases to exist at precisely the moment the organisation begins to depend on the result.
What Leaders Commonly Misread
The first misreading is that the handover is an implementation detail. It is the structural consequence of the form. A project ends; the thing it built does not. Somebody must operate it, maintain it, improve it, and be answerable for whether it delivers what was promised — and that somebody was not in the room when the decisions were made.
The gap is not primarily about documentation. It is about judgement. The project team knows which parts of the design were deliberate and which were compromises, which risks were accepted and why, and what would break if a particular assumption changed. Almost none of that transfers in a handover pack, and none of it exists once the team is redeployed.
The second misreading is that benefits belong to the project. They cannot. Benefits are realised in operations, over time, by people doing their jobs differently. A project delivers a capability; an operating unit converts it into value or fails to. Any business case that assigns benefit ownership to a temporary structure has assigned it to something that will not exist when the benefits are due.
The third misreading is that more projects means more change capacity. Frequently the reverse. Every project draws the same scarce operational people into a second set of commitments, and an organisation that has projectised ordinary improvement work has taken activity that would have happened inside a function, wrapped it in governance, and made it compete for the same attention as genuinely novel work. The overhead is real and the visibility gained is often not worth it.
A fourth error is definitional, and it propagates. A program is frequently described as accountability for several projects run concurrently. Concurrency is not what makes a program. The organisation's own definition of management by projects gives the better test: work is a program when a set of changes must combine to produce an outcome that the organisation's strategic goals require and no single project delivers. Two unrelated projects sharing a manager are two projects. Five projects whose combined effect is a changed operating model are a program, and they need a governance structure oriented to the outcome rather than to the components. Getting this wrong produces the familiar pathology of a program board that reviews five status reports and never discusses whether the outcome is arriving.
Reframing the Issue
The reframing is to treat project form as a financing and governance instrument with a maturity date, rather than as a container for work.
Instruments with maturity dates require a plan for what happens at maturity. A bond is refinanced or repaid. A lease is renewed or exited. A project matures into an operational responsibility, and the organisation should be as explicit about that transition as it would be about any other.
Two questions follow immediately, and both should be answered before the form is chosen rather than after.
What does this work look like on the day the structure dissolves? If the answer is that a function will absorb it and carry on, name that function and its accountable leader now. If the answer is unclear, the organisation is about to create an orphan.
Is the temporary form actually buying anything here? Bounded, novel, cross-functional work with a genuine end point: yes. Continuous improvement to an existing process, owned by an existing team: almost certainly not, and putting it in project form adds governance cost while removing the ownership that made it work.
Strategic Analysis
The handover is a capability transfer, not a document transfer
Consider a manufacturer installing automated inspection across three production lines. The project runs eighteen months, delivers on budget, and hands over a working system with a comprehensive documentation set. Within a year, first-pass yield has drifted back toward its pre-project level. Nobody sabotaged anything. The operating team simply does not know which of the system's forty configurable thresholds were tuned to their specific process and which were defaults, so when conditions changed they adjusted the wrong ones.
The documentation described what the system does. It could not describe what the team understood. That distinction is the cost of the form, and it is paid in every industry — the utility whose new outage system reverts to workarounds, the agency whose case management platform is used at a fraction of its capability, the hospital whose scheduling tool is overridden daily by staff who never learned why it recommends what it recommends.
The remedy is not better documentation. It is designing the transfer as a capability handover: operational people embedded in the project early enough to acquire judgement rather than instructions, and project people retained past go-live long enough to answer the questions that only arise in use.
The unowned interval
Between the project's closure and the operating unit's full assumption of responsibility there is an interval — sometimes weeks, often months — in which the thing exists and nobody is accountable for its performance. Formal acceptance of deliverables is meant to close it, which is why it sits among the sponsor's obligations, as discussed in [Related article: Sponsorship Is an Office, Not an Endorsement]. In practice acceptance is frequently a signature that transfers custody without transferring capability, and the interval remains open.
This unowned interval is where a surprising proportion of realised benefit is lost. Problems that surface in it are attributed to the project, which has closed, or to operations, which did not build it. Neither party has both the knowledge and the mandate to fix them.
When management by projects becomes a cost
An organisation that defines most of its activity as projects gains visibility and loses something less obvious: the standing capability to improve without ceremony. Functions that would once have made a change and absorbed it now write a case, seek a slot in a portfolio, and wait. The work that survives that process is the work someone was willing to sponsor, which is not the same as the work with the best return.
There is a related and separate question — whether a standardised delivery method fits every kind of work, and where enforcing it destroys value — which is examined in [Related article: Why "The Principles Apply to Any Project" Is Only Half True]. The argument here is prior to method: before asking which method fits, ask whether the temporary form should be used at all.
There is a reason the standard apparatus is so poorly suited to this question. Completion-based measures and phase-gated funding stop at handover because they were designed for work whose value genuinely did arrive at handover — an inheritance traced in [Related article: What Kind of Work Were These Instruments Built For?].
Decision Framework
A form test, applied before a delivery method is chosen.
1. Does the work have a genuine end? Not a milestone — an end, after which the organisation does something different permanently. If the work is continuous, the project form is the wrong instrument and will produce a project that never closes.
2. Does it require capability the standing organisation does not have? The strongest case for the form is cross-functional work no single function can execute. Where one function could do it, the form adds cost and removes ownership.
3. Who operates the result, and are they identified now? Name the receiving function and its accountable leader at initiation. An initiative that cannot name its receiver should not be approved.
4. What must transfer, and how? Distinguish artefacts from judgement. Then specify how judgement will move: named operational people in the team from a defined point, and named project people retained for a defined period afterwards. Put both in the plan and the budget.
5. Who owns the benefit, and from when? The receiving function, from acceptance, with the measure agreed at initiation rather than negotiated at closure.
6. If this is a program, what is the outcome no single project delivers? Where that outcome cannot be stated in a sentence, it is a portfolio of projects that share a manager, and it should be governed as one.
From Strategy to Execution
Immediate. Take every initiative closing in the next two quarters and establish, for each, the named receiving leader and the agreed benefit measure. Where either is missing, it can still be fixed before closure. After closure it usually cannot.
Medium term. Add the form test to initiation. Two consequences follow quickly: some work returns to functions where it belongs, and the initiatives that remain in project form carry a named receiver and a transfer plan from the start. Fund the transfer explicitly — a period of overlap costs perhaps two to five per cent of a program's budget and routinely protects considerably more than that in realised benefit.
Long term. Decide deliberately how much of the enterprise should run through project form. Management by projects is a legitimate operating philosophy, but it is a choice with a price, and organisations that drift into it rarely notice they have made it. What the enterprise retains from all this delivery activity is a related question, examined in [Related article: What Does the Enterprise Own After a Capability Investment?].
Signals to Monitor
- Performance drift after handover. Track the delivered measure for twelve months past acceptance. A characteristic pattern — good at go-live, decaying over two to three quarters — indicates capability that did not transfer.
- Projects that never close. An initiative running past its second extension with no end state defined is usually operational work in project clothing.
- Benefit measures agreed at closure rather than initiation. Where the measure is negotiated after the fact, it will be negotiated to something achievable.
- Rising share of enterprise activity inside the portfolio. Worth watching as a ratio. A steadily increasing proportion signals projectisation of work that functions used to absorb.
- Program boards that review components rather than outcomes. If the meeting is five status reports, the program is a portfolio and the outcome has no owner.
- Support tickets referencing the project team. Operational staff still contacting a disbanded team months later is direct evidence that the transfer did not happen.
Questions for the Leadership Team
- For each initiative closing this year, who is the named leader that will operate the result, and have they agreed the benefit measure?
- How much of our current portfolio is work a function could have absorbed, and what did we pay in governance to take it out of the function?
- What happens in the interval between project closure and full operational ownership — and how long is it, on average?
- Do we fund the capability transfer, or do we fund the build and assume the transfer?
- Which of our programs can state, in one sentence, the outcome that no single one of its projects delivers?
- Where has a delivered capability decayed after handover, and did we treat that as an operational failure or as a design failure in how we ended the project?
Closing Perspective
The project form is a good instrument. It bounds commitment, creates ownership, and gives an organisation a legitimate point at which to stop. Nothing here argues against using it.
What it does not do — cannot do — is carry a result past its own dissolution. That property is fixed, it is the reason the comparison table has an empty cell, and it means every use of the form incurs a transfer cost that is almost never estimated and frequently never paid.
Enterprises that realise their benefits are not distinguished by better project management. They are distinguished by having decided, before the structure was built, exactly how it would be taken down — who would be standing there when it was, and what they would need to know.
About the author
Kevin Jogin is Founder & Principal Advisor at EraNorth. Meet the Founder.