Why Project Management Should Be a Business Process

Project Management is a Business Process – So Why Don't We Treat It Like One?

There is something worth acknowledging up front: most organisations are far more disciplined about how they run their business than how they change it.

Finance has controls. HR has governance. Operations gets measured, optimised, and reviewed on a cycle. There are owners, standards, and accountability structures that have been built up deliberately over time. And then you look at how those same organisations deliver change, and it is a different story entirely. Projects get run however the project manager runs them. Documentation varies. The same type of project gets handled in completely different ways depending on who is leading it. And, strikingly, nobody seems to find this particularly strange.

The reason, I think, is that project management has always been framed as a capability: something individuals bring to the table through training, certification, and experience. That framing is true, but it is also incomplete. Because underneath all of that, project delivery is fundamentally repeatable. It has defined inputs, a structured sequence of activities, and measurable outputs. That is a process, whether we call it one or not. And the organisations that fail to recognise it as one are paying a price they often cannot quite put their finger on.

The cost tends to be invisible until it isn't

Working with a large facilities management provider, we saw this play out in a fairly typical way. They were running hundreds of site-level projects simultaneously (planned maintenance programmes, compliance upgrades, contract mobilisations) and each regional team had developed its own approach. Some used detailed project plans. Others ran entirely off email threads and weekly calls. Reporting to the centre was inconsistent, which meant leadership had no reliable picture of delivery performance across the portfolio.

The projects were not failing dramatically. But they were unpredictable. Costs crept. Timelines slipped. And because every project looked different, there was no straightforward way to diagnose why.

That last part is the thing that tends to go unnoticed. When delivery is inconsistent, the problems it produces are easy to attribute to individual projects rather than to a systemic gap. You fix the symptom, not the cause, and the same issues surface again three months later under a different name.

The more durable fix is structural

This is a problem we have thought hard about in our own delivery model. The work we do is focused on process implementation - typically using WEBCON - and our projects rarely run longer than a couple of months. But the fact that they are smaller in scale does not mean consistency matters any less. If anything, it matters more, because there is less room to absorb the cost of reinventing the wheel each time.

So we standardised our delivery as a process in its own right. Every engagement starts the same way: a structured interaction with the client to capture requirements, which are logged directly within our process and produce a Statement of Work as a formal output. That SOW then drives the next stage: requirements are converted into discrete tasks, mapped to a project Gantt, and used to monitor delivery through to completion. Every project we run, regardless of client, sector, or scope, follows the same structure.

The simplicity is the point. A new team member can orientate themselves quickly. A client knows what to expect. And we can see, at any point, exactly where a project stands. What we have built is a delivery process, not just a delivery habit. That distinction matters more than it might initially sound.

What process thinking actually unlocks

Business process management is usually applied to operational workflows: finance, procurement, customer service. But the underlying logic applies just as well to change delivery, and the stakes for getting it wrong are just as real.

We have seen this particularly clearly in power markets, where organisations are managing complex, interdependent programmes, such as grid infrastructure upgrades, regulatory compliance projects, market system migrations, often running in parallel and under significant time pressure. In that environment, inconsistency is not just an efficiency problem. It is a risk problem. A stage gate missed on one workstream can create a dependency failure three months later in another.

One organisation we worked with had strong project managers individually. But because there was no standard delivery framework, each programme had become its own ecosystem. When a senior PM left mid-delivery, the incoming resource spent weeks just understanding how the project had been structured before they could meaningfully contribute. The knowledge existed in one person's head, and when that person left, it largely went with them.

If you treat project delivery as a process, you can standardise it, measure it, and build on it over time. You can define a consistent lifecycle, set clear stage gate criteria, and actually track whether projects are delivering the outcomes they promised. None of this requires heavyweight methodology or enterprise tooling. A structured requirements capture, a well-formed SOW, and a Gantt that reflects real tasks, applied consistently, is enough to make delivery predictable.

The gap most organisations have not closed

In practice, the same gaps tend to appear wherever we look: no consistently applied lifecycle, governance that varies by project or sponsor, little to no measurement of delivery performance at a portfolio level, and lessons learned that feed back into nothing.

In facilities management, we have seen lessons learned documents that were thorough, well-written, and completely ignored on the next project. Not out of negligence — there simply was not a mechanism to carry them forward. That is not a people problem. It is a process problem, and the distinction matters because only one of those has a structural solution.

The blunt summary is that most organisations have standardised how they run the business, but not how they change it. Every improvement you make to a delivery process pays off across every project that follows. In a sector like power markets, where a single delayed project can carry regulatory or commercial consequences well beyond its own budget, that compounding effect is significant. But the same logic applies at any scale.

If your projects are only as good as the person leading them, you do not really have a delivery process. You have a collection of individual approaches. And that is not something you can build on.