A few videos online refute the idea that agile and capital project delivery can coexist.
For a while, I even thought so myself.
I thought that agile delivery implicitly invalidated phased delivery. The logic here is that once you’ve completed one phase of a project, you move on to the next, having made irreversible decisions. That’s the definition of waterfall, and the project delivery paradigm that’s very old.
Agile advocates for continual responsiveness, and in technology (where agile gained traction) that’s comparatively easy. Sweeping changes are loads easier in tech than they are when compared to, say, a finished stadium or railway. Indeed, in tech, the concept of ‘finished’ is largely redundant. I reasoned this couldn’t apply practically to physical projects.
I was wrong.
Working with a massive oil company, even through the chaos of 2020, has shown that there’s a valuable and practicable case for agile in capital projects.
Through serial example projects, most of which have seen teams surprise themselves with their performance, I’ve been able to map agility to capital project delivery. Working together, we’ve:
- Consistently reduced decision time in early phases by a staggering 80%.
- Chopped delivery time in detailed design phase in half in around five examples.
- Applied lightweight scale principles to construction phase work.
- Cut major capital project spend by 30% in three examples, totaling over US$1bn.
- Used similar approaches to speculation on new asset development bringing decisiveness and action that was previously unheard of.
Almost unbelievable, right? I felt strongly that the first few pilots we did were fluke, a stroke of luck brought about by intense observation by senior leadership and having the best the business had to offer in the room. But I was proven wrong when we repeated the examples again and again.
So what gives? How do we get these benefits, especially as I’ve said ‘phase’ (a very waterfall-y word) in the examples?
It’s about being pragmatic.
The phased nature of capital project delivery isn’t going anywhere fast.
There are broadly three phases:
- Is there a project?
- If so, let’s write the instructions
- Let’s build it
Agile helps differently in each phase
What we’ve shown is that agile helps differently in each phase. Be agile about agile.
When we’re speculating on whether to do a project, we can use Scrum. There’s high ambiguity, so all the aspects of scrum (including structure, value-orientation, and cross-functional teams) combine together to act like a firecracker to how projects would prevaricate in this phase usually. Good decisions take only 20% of the usual time.
When we’re detailing up our project, Kanban comes into its own. Gone is speculation on value, in its place is a focus on quality, dependency and risk. Visualising the whole project system and bringing a clear communications system (borrowed from Scrum) radically reduces rework and exposes issues before they cause headaches. In this phase, we’ve seen higher delivery rates and a practical elimination of re-work.
And in construction, we use both Kanban and Scrum – Kanban for the overall project, and dedicated Scrum events to allow the project to respond to unexpected events (for example, your foundations are being dug on a surprise Roman archaeological site) rapidly and with the best information.
Across the three phases, the big numbers in benefits are to be found in the earlier phases, where there’s the most waste and the most unknowns. But as we step through the project, the clarity and responsiveness from lightly applying these frameworks and mindsets brings the most responsiveness that can be brought in the circumstances.
And that – to be as agile as is practical – is all that’s really necessary to have a dramatic positive impact in project delivery.
Leave a comment