Definition

A gravy train project is a large, long-term initiative that attracts significant promised investment, often sanctioned by very senior decision-makers and spread over multiple years. These projects typically involve substantial spending, the rapid hiring of new staff, and the signing of large and expensive vendor contracts, often without clear short-term deliverables.

Explanation

A gravy train project usually begins with extensive hype. It is positioned as the next big thing and is supported by high-profile backing, whether from major corporations’ investment areas or government bodies. Marketing activity from vendors and internal stakeholders quickly follows, reinforcing the scale and ambition of the initiative.

From a delivery perspective, the outcomes are often framed as being years away. This removes immediate pressure for tangible results while releasing large amounts of funding into the system. As a result, spending accelerates rapidly. In many cases, this expenditure does not always align with effective delivery or long-term value.

Vendors and external partners are well aware that this type of funding rarely lasts indefinitely. As the money is expected to dry up eventually, there is often a rush to secure as much of it as possible while the programme still has momentum.

Real-World Context
One of the most visible examples in England has been HS2. There was an excellent interview with the former head of the Channel Tunnel rail link construction into London, where he contrasted the gravy train nature of HS2 with the way the cross-Channel connection was managed.

His key lesson was that large projects should not release all funding at once. Instead, investment should be announced and approved in tightly defined phases. While the overall programme may span many years, each phase should be funded only when the previous phase has delivered successfully. In effect, this turns one vast programme into a series of smaller, tightly controlled projects.

Why This Matters?
This phased approach limits uncontrolled spending, maintains delivery focus, and helps prevent the gravy train mentality that assumes unlimited money for unlimited activity. It also reduces the risk of large-scale failure, reputational damage, and the familiar situation where those who spent most freely are never held to account, while delivery teams are left to manage the consequences and the frantic panic as the funds run dry.

Disclaimer: As always these posts are not aimed at anyone client or employer and are just my personal observations over a lifetime of dealing with both management and frontline associates.

I have worked with LDC and LDC Via for well over a decade now, and it remains my main professional home for the work I do. Like many small companies, however, we are far better at delivering for clients than we are at regularly refreshing our own website.

This time, Ben and his excellent UI skills have once again come to the rescue. He has produced a clean, modern single-page redesign that puts everything front and centre. It covers what clients most commonly ask for, provides clear links to everything else, and does so in a way that is simple, fast and easy to navigate. It is a huge improvement on what we had before.

If you have not already seen it, I would encourage you to take a look at https://ldcvia.com/

And yes, you can also use it to hire us.

Definition

An “Admin rampart” is an odd but very real construct. It is a defensive structure, usually built by one team, silo, or functional area to protect itself from the perceived aggressions of another.

Explanation

Often the creation of “Admin Ramparts” is the unintended consequence of a well-meaning initiative.
A large corporation realises that it is drowning in paperwork and process, to the point where it is actively impeding delivery to the business and even to itself. In response, it launches a drive for simplification or boundary breaking.

In practice, this rarely breaks down the old issues. Instead, new processes are created in the hope that they will simplify delivery. The critical flaw is that the existing processes are very often not removed first. Another layer is simply added on top, usually by the team creating the new framework. This is done to demonstrate progress and the aim of simplifying delivery.

Meanwhile, the areas whose boundaries and controls are being challenged frequently respond by placing even more dependencies in front of their current processes, as they feel they are losing control of their own deliveries and so want to place responsibility safeguards in place for the inevitable “blame game”; sometimes these dependencies become cyclic and impossible to achieve for a new delivery. The result is that regardless of whether you follow the new route or not, you still have to complete all of the old steps as well, often just under a different name.

This back-and-forth, without ever dismantling what already exists, produces admin ramparts. These become great walls of paperwork that serve to deflect blame, avoid responsibility, and maintain control, rather than enable delivery.

Disclaimer: As always these posts are not aimed at anyone client or employer and are just my personal observations over a lifetime of dealing with both management and frontline associates.