Why Agile doesn’t (always) work in a capital project

A project manager recently complained to me about how much grief she gets because she doesn’t use Agile in her projects. I feel her pain. People keep asking me: Why doesn’t CAPEXinsights support Agile?

For context, CAPEXinsights is a project portfolio management application that helps users get better results from their capital projects. The platform automates and streamlines project management processes, including risk management, development gates and approvals. It also lets you view cash flow, risk and results at a portfolio level.

Spoiler alert: it’s not designed for Agile methodologies.

Here are two of the many reasons why.

No one builds a plane while actually trying to fly it

‘Building the plane while trying to fly it’ is the software development cliché at the heart of Agile. In an Agile project, you deploy a Minimum Viable Product (MVP) and then enhance or fix defects through ongoing releases. This contrasts with the linear Waterfall methodology where you might refine and tinker for years before finally deploying a gold standard solution.

We all understand why Agile is an excellent choice – if you’re building software.

However, if you’re building a new factory or processing plant (or a plane!), some things have to be done in a linear order. You can’t be Agile around a process like pouring concrete. You can use Agile to go away and support the invention of a faster drying concrete. But you can’t produce an MVP of the ‘moment of pour’. Similarly, once you’ve chosen your plant, installed the drainage pipes and concreted everything over, no one is going thank you for iterating the plant specifications.

I’m being facetious here – but you get the point. Capital projects involve investing in physical assets that (like planes) have annoyingly immutable boundaries – often shaped by the laws of physics.

Capital project risk management doesn’t lend itself to agility

Agile famously prioritises individuals and interactions over processes. But sometimes processes are more important than people. For example, capital projects are subjected to a vast number of risk identification processes, including HAZOP, Layer Of Protection Analysis or Probabilistic Hazard Analysis studies. These processes unapologetically slow progress down and don’t allow people to take short cuts.

This is because the consequences of getting capital projects wrong can be disastrous. Think: Exxon Valdez, Deepwater Horizon and the Union Carbide Bhopal gas leak.

The ISO 3100 risk management process involves systematically applying policies, procedures and practices. It takes time and discipline. You can automate and streamline the workflows around this process (did I mention CAPEXinsights?). But you cannot take short cuts.

Personally, if the new plant interfaces with the ammonia system, I’m all for the HAZOPs and risk management teams going through painstaking linear processes to make sure our factory doesn’t have a catastrophic end, endangering people, the environment and plant.

Does this mean you can’t use Agile in a capital project?

Not at all. Agile is great within a stage of a capital project, outside risk management and between development gates. If you’re coming up with a new conceptual engineering product or process to support your capital project, Agile is definitely the way to go.

If you want to perform the processes required between each development gate in parallel, or in a new order, it’s all good (and, by the way, CAPEXinsights lets you do that).

But when it comes getting a project through its development gate, it’s a different story. Achieving a point of confidence where the board can approve a hundred-million dollar project and sleep at night requires a whole bunch of checks and balances, accountability and traceability.

Does this mean you can’t fast-track a capital project?

Not at all. But don’t confuse fast-tracking with Agile. In a fast-tracked project you deliberately increase its risk profile. At this point, you actually need more discipline – not less. You have to be able to lower the guardrails to the point where you can still live with the risk. Doing it safely, requires a huge amount of control – the opposite of Agile.

Let me be clear. I’m not against Agile. It was incredibly useful when we were building CAPEXinsights. 

But Agile is not fit for purpose to manage the stage-gate development of large-scale, physical capital projects.

For further information about capital project lifecycles or to have a personalised demonstration of our product, please don’t hesitate to reach out to us.