The Death of the "IT Project" - Governance and Funding for Programmes That Never Close
IT programmes in manufacturing no longer end. ERP, MES, and APS platforms that once closed with a post-implementation review now run as permanent infrastructure, updated continuously long after their original charters expired. This shift breaks two assumptions senior executives and project managers were trained on: governance built around gate reviews and closure, and funding built around a fixed project envelope. Drawing on programme experience across integrated steel plants, this article examines why the project model is breaking, what continuous governance looks like in practice, how funding is shifting from capital envelopes to persistent value-stream budgets, and the accountability risk this shift quietly introduces if left unmanaged.
The Road With No Destination
चरैवेति चरैवेति
Keep moving, keep moving.
The Aitareya Brahmana gives this answer to a traveller who asks the sages when the road ends. There is no destination named in the reply. The instruction is only to keep walking.
I think about that phrase more often than I expected to, usually somewhere between a steering committee deck and a go-live date that has moved for the third time. Somewhere in the last decade, the integrated steel plant IT programme stopped being a journey with a destination and became a road that just keeps going. The APS system that "went live" in 2019 is still being rebuilt, quarter after quarter. The MES that closed its project charter five years ago now runs a backlog longer than the original scope. Nobody has told the finance team, the steering committee, or the project manager who has since moved on that the project, as originally chartered, is dead. It just kept moving after everyone stopped watching for the finish line.
This is not a complaint about scope creep. It is a description of what has actually happened to programme work in manufacturing IT, and it means two things every senior executive and project manager were trained to rely on, a governance model built around gates and closure, and a funding model built around a fixed envelope, no longer describe the work sitting in front of them.
The Project That Never Ends
Twelve years ago, when I first worked a slab-to-order matching rollout for a hot strip mill, the shape of the work was familiar to anyone who had read a PMBOK guide. A charter. A work breakdown structure. A go-live date circled on a wall calendar in the programme office. A post-implementation review, six months after go-live, that formally closed the project and released the team to whatever came next.
That shape does not describe what I see now. The same hot strip mill, visited today, would show a scheduling platform that has had eleven "releases" since its original go-live, none of them called projects, most of them not requiring a steering committee paper at all. The blast furnace's MES has absorbed two acquisitions' worth of new plant configurations without ever being formally reopened as a programme. The APS layer sits on a cloud vendor's release train and receives features it did not request every quarter, whether the plant is ready for them or not.
Ask the plant IT head when this "project" will be done and there is usually a fair pause before the honest answer: it won't be. Not because it is behind schedule, but because the thing it built is now infrastructure, the way the continuous caster or the rolling mill motor is infrastructure. Infrastructure does not close. It gets maintained, extended, and occasionally re-platformed, but the idea of a post-implementation review followed by team disbandment stopped making sense the day the plant started depending on the system for daily production decisions rather than a one-time cutover.
Project Management Institute's own research has moved in the same direction. Its recent work on redefining project success widens the frame beyond the classic time-cost-scope triangle, noting that this research was undertaken against a backdrop of transformation in the workplace and the profession, making it an apt moment to reexamine the changing landscape in which projects are conducted along with the value they create over time. That is a careful, institutional way of saying what plant IT heads say more bluntly on the shop floor: the project ended on paper, but the work never did.
Why the Old Model Is Breaking
Three forces sit behind this shift, and none of them are unique to steel, though steel plants feel all three at once in a way few other industries do.
The first is the software itself. ERP, MES, and APS platforms used to ship as discrete versions, SAP R/3 to ECC to S/4HANA, each a project with a defined migration and a defined end. Now they ship as a continuous stream of releases from a vendor's cloud, whether the plant asked for them or not. There is no "version 7" left to plan a project charter around. There is only next Tuesday's release notes.
The second is architecture. Plants that once bought one ERP and one MES from a single vendor now run a stack of composable services, APIs stitching together scheduling, quality, and maintenance modules that get updated independently and constantly. McKinsey's research on this shift describes the resulting structure plainly: high-maturity organisations are distinguished by a clearly defined product and platform taxonomy, with cross-functionally assembled and persistent teams set up with the right role ratios and end-to-end ownership, so fewer handoffs occur between teams. A team that disbands after go-live cannot own something that keeps changing after go-live. There is nobody left holding the thread.
The third, and the one senior executives feel first in their budget reviews, is that value no longer arrives in one lump at cutover. It arrives in instalments, a new grade-transition rule here, a faster changeover algorithm there, an AI-assisted quality prediction bolted on eighteen months after the "project" supposedly closed. PMI's own research on the convergence of project and product disciplines confirms this from the practitioner side. In a survey of nearly fourteen hundred practitioners with thirty-seven in-depth interviews, the large majority of product managers reported meaningful project management experience, and PMI frames this convergence as central to delivering sustainable value in an environment shaped by product-led growth and ongoing digital transformation. The professions are not merging by accident. They are merging because the work itself stopped having a shape that either discipline could own alone.
None of this means the word "project" disappears entirely. Discrete, boundable pieces of work, a new mill commissioning, a one-time data migration, a regulatory compliance build, still deserve a project structure with a real start and a real end. What is dying is the assumption that the platform underneath all of it, the ERP, the MES, the APS, the AI layer now riding on top of all three, is itself a project. It isn't. It has become a resident of the plant, and residents don't move out on a schedule.
Governance Without a Closing Date
If the programme has no end date, the first casualty is a governance model built entirely around one. Gate reviews assume a finite number of gates. Post-implementation reviews assume an implementation that is, in fact, post. A risk register assumes a register that eventually gets archived. Remove the end date and each of these either becomes a fiction everyone quietly agrees to keep performing, or it has to be rebuilt around a different rhythm altogether.
I have sat through steering committees that kept meeting monthly for a "project" that had, in every practical sense, become business as usual four years earlier. The papers still said "Phase 6," the RAID log still carried open items from 2021, and nobody on the committee, not the Chief Supply Chain Officer, not the VP of Operations, could tell you with a straight face what "done" would look like. Done had quietly become a moving target the day the plant started running shift schedules through the system. The committee wasn't governing a project anymore. It was performing the governance of one, because that was the only vocabulary anyone had been trained in.
What replaces it, in the organisations that have genuinely made the shift, looks less like a gate and more like a heartbeat. Scaled Agile's Lean Portfolio Management guidance describes this directly: funding and governance attach to the value stream, the persistent flow of work that keeps delivering, with the available portfolio budget allocated directly to these value streams rather than to individual projects with a defined start and finish. Governance becomes a cadence, quarterly, sometimes monthly, of reviews against a small set of outcome metrics, throughput, defect escape rate, plant uptime attributable to the platform, rather than a one-time sign-off against a fixed scope document that stops being relevant within a year.
Two things change underneath this that senior executives should notice early, before the terms of reference quietly go stale.
The steering committee becomes a platform council. Its job is no longer "approve this scope, then disband." Its job is "own this capability, indefinitely, and decide each quarter what it has earned and what it hasn't." That is a genuinely different mandate, and in my experience most committees have never been formally told this is what they are now doing. They just kept meeting.
The risk register becomes a living instrument, not a closing document. A risk register archived at project closure is honest about one assumption: that the risk stops accruing when the project does. In a platform that never closes, technical debt, vendor lock-in, and single points of knowledge, the one engineer who understands the custom scheduling logic and nobody else, accumulate for as long as the platform runs, which in a steel plant can mean fifteen or twenty years. Treating that register as a one-time artefact is how organisations wake up to a "surprise" risk that was, in fact, visible and unaddressed for half a decade.
None of this is theoretical drift. McKinsey's more recent work on operating model transformations found that companies which kept their old funding logic, large projects approved by a steering committee, layered on top of an otherwise agile delivery structure, ended up with exactly this kind of quiet mismatch: significant time still went into business case templates, approvals, and backward-looking tracking, even as delivery teams themselves had already moved past a project mindset. Governance built for a finish line does not gracefully evolve into governance for a road with no finish line. It has to be redesigned on purpose, with someone accountable for doing the redesigning.
Funding: From the Envelope to the Tap
Governance is the visible half of this shift. Funding is the half that actually forces the change, because nothing reorganises a programme faster than the CFO asking a different question.
The classic project funding model is an envelope. A business case is built, a capital budget is approved, usually as CAPEX, spend is tracked against that envelope until it's exhausted or the project closes, and whatever wasn't spent either gets returned or triggers an awkward conversation about why the estimate was wrong in the first place. This model carries one deep assumption: that the thing being funded has a foreseeable, finite scope. Ask any CFO what happens when the "project" quietly becomes permanent, and the honest answer is usually some version of, we just keep re-approving it every year under a fresh business case, which is a polite way of admitting the envelope model stopped fitting three renewal cycles ago.
The alternative that mature product and platform organisations are moving toward funds the team, not the task. Scaled Agile's framework calls this Lean Budgets, a financial governance approach built specifically to fund value streams instead of projects, introduced because traditional project cost accounting was found to directly conflict with the pace organisations were trying to operate at. Instead of re-justifying the same team's existence every year through a fresh business case, the organisation commits to funding the capability, steel plant scheduling intelligence, say, or MES platform reliability, as a standing line, with guardrails on how that money can move rather than a fixed scope it must be spent against.
This is a genuinely uncomfortable shift for a finance function trained on capital budgeting discipline, and I don't think the discomfort is entirely misplaced. A persistent team funded on an outcome metric can drift, quietly, into a cost centre nobody quite has the authority to shut down, because there is no closure event left to force that conversation. The organisations handling this well seem to solve it not by returning to project envelopes, but by tightening the guardrails on the standing budget itself. Fixed-envelope funding, where a unit gets a stable budget and has to prioritise ruthlessly within it rather than ask for more, is one version McKinsey has documented working in practice, introduced after a bank's early funding reforms left the underlying steering-committee logic largely untouched underneath a new label.
For a steel plant specifically, this plays out as a question finance and IT have to answer together, and honestly, most haven't yet. Does the APS platform get capitalised once, at initial build, with everything afterward treated as an unglamorous maintenance OPEX line that loses every budget fight to the next shiny capital project? Or does the organisation accept that a scheduling platform generating measurable production value every single quarter deserves standing, defensible funding on the same terms as the blast furnace's own maintenance budget? I have watched the second answer win the argument in the room, and then quietly lose the actual budget cycle six months later, because nobody went back and updated the chart of accounts to make it possible. Funding models don't shift because a memo says they should. They shift when the accounting entities finally catch up with how the work is actually organised.
For Senior Executives
- Retire the phrase "when does this project end." Replace it with "what capability are we funding, and what does it need to earn this quarter to keep earning next quarter's budget." The first question forces a false answer out of an honest team. The second is one your platform owner can actually answer without pretending.
- Turn the steering committee into a platform council with standing membership, rather than letting it quietly keep meeting past its own project's expiry date under the old name. Give it an explicit, written mandate to own the capability indefinitely, not to approve a scope and disband.
- Ask for outcome metrics, not milestone completion. Uptime attributable to the platform, cycle time for a grade change, forecast accuracy, tell you more about whether the money is working than "82% of tasks complete" ever did, and they don't stop being useful the day a project would have closed.
- Name a platform owner and treat the role like a P&L owner, not a rotating PM assignment refreshed every eighteen months. Persistent capability needs persistent, accountable ownership, the same way a rolling mill has a named mill manager, not a rotating shift supervisor holding authority over capital decisions.
- Expect the finance conversation to be the hardest one. It usually is. Push it early, deliberately, not after the fifth year of quietly re-approving the same "project" under a new business case nobody fully believes anymore.
For Project Managers
- Learn to read a backlog the way you once read a work breakdown structure. The discipline is different, prioritisation by value and by flow rather than sequencing by dependency, but it is a discipline, not an absence of one, and treating it as looser than a project plan is the fastest way to lose credibility with a platform team.
- Redefine "closure" as a rhythm, not an event. A quarterly business review that honestly assesses what the platform earned this quarter does more real governance work than a post-implementation review nobody reads six months after go-live.
- Get comfortable owning something you didn't finish and never will. This is, genuinely, the hardest psychological shift in this whole transition. Most of us came into this profession trained to feel closure at a go-live party. Persistent ownership doesn't offer that feeling, and pretending otherwise just delays the adjustment everyone eventually has to make.
- Watch for the eternal beta trap. A platform with no end date and no discipline can drift into an excuse to never finish anything properly, chasing the next feature instead of hardening the last one. Flow metrics and a genuinely prioritised backlog are the guardrail here, not good intentions.
- Build the vocabulary now. Objectives and Key Results (OKRs), flow metrics, value stream mapping, are not buzzwords to tolerate until the fad passes. For a project manager on a platform-based programme, they are becoming as basic to the job as a Gantt chart used to be.
The Risk Nobody Puts in the Steering Deck
Every model has a failure mode, and the failure mode of continuous governance is quieter and slower than the failure mode of the old project model, which makes it more dangerous, not less.
A failed project is visible. It's red on a dashboard, it misses a go-live date, someone eventually has to explain it to the board. A platform that never closes can fail slowly enough that nobody ever has to explain anything, because there's no closure event left to force the reckoning. Budget renews quietly. The steering committee, now technically a platform council, keeps meeting and keeps nodding at metrics that have drifted sideways for three quarters running, and because nobody formally declared the project "failed," nobody escalates it as one.
This is the honest tension sitting underneath everything I've written here. Persistent teams and continuous funding solve a real problem, the mismatch between how software actually gets built now and how we used to govern and pay for it. But they remove a mechanism, project closure, that used to force an honest reckoning at least once. Replace that mechanism with nothing, and the result isn't agility. It's accountability diffusion with better dashboards on top of it.
The organisations getting this right seem to have replaced the reckoning rather than simply removed it. Fixed-envelope funding forces a prioritisation conversation every cycle, because the team genuinely cannot fund everything. OKRs that are actually reviewed, not just reported upward, force someone to say out loud when a target was missed. A platform owner with named, personal accountability, the way a mill manager owns mill performance, replaces the diffuse accountability of a rotating steering committee membership that changes every eighteen months. None of these are quite the same as a project closing. But they do the same job the closure used to do: they force somebody, on a schedule, to say clearly whether this is still worth funding.
चरैवेति चरैवेति.
Keep moving, keep moving.
It's a demanding instruction, not a comforting one, because it offers no finish line to rest at. Governance for a road with no end has to build its own rest stops, its own honest checkpoints, deliberately, because the road itself will never provide one. That, I think, is the real work in front of every steering committee that quietly became a platform council without anyone updating the terms of reference to say so out loud.
#ProjectManagement #ProductOperatingModel #ITGovernance #DigitalTransformation #SteelIndustry #ManufacturingIT #AgileGovernance #LeanPortfolioManagement #PlatformThinking #ProjectToProduct
Disclaimer: The incidents, characters, projects, and organisations referenced in this article are fictionalised composites drawn from recurring patterns observed across complex transformation programmes. Their purpose is to illustrate leadership and governance lessons rather than describe any specific organisation, project, customer, or implementation. The lessons, however, are very real.