Skip to content

How to procure for agile projects

Added to your CPD log

View or edit this activity in your CPD log.

Go to My CPD
Only APM members have access to CPD features Become a member Already added to CPD log

View or edit this activity in your CPD log.

Go to My CPD
Added to your Saved Content Go to my Saved Content

“We are going to be agile, and we are not going to see cost overruns in delivering this project.” How many times have you heard this statement in your project delivery career?

Most of us buy into the benefits of agile. With any project, we want to identify the challenges early and address outputs in manageable deliveries. Difficulties arise however, when we need to involve contracts and purchase from third parties. In short, our contracts and procurement processes are not agile enough – and we will not add benefits to large capital projects until we discuss the constraints of undertaking procurement with an agile project.

Procuring for Agile Projects, going out on Thursday this week. Read on to find out more about what we will be covering and how you can help guide your teams and processes to support agile projects.  

For most of my career I’ve worked on initiatives that involved purchasing something from the market. In one project we had to buy professional marketing services. There was research and significant effort put into requirements analysis. This led to slow decisions and hugely variable cost estimates. There was an ‘us’ and ‘them’ culture treating the market as ‘an enemy’ in the process. The term ‘agile’ was thrown around like it was magic dust, meant to make the project move faster, but there was a reluctance to engage with the market early. 

A common root cause of this delay involves a failure to engage the commercial team. On the project example above I realised that they held different views than the project team and client department on risk and cost. Yes, a well managed project has all stakeholders engaged early but, in my experience, no matter how early engagement takes place, this challenge remains. The project team intends to embody the ethos of agile, but the organisation’s commercial processes are often contrary to them. The commercial team wants price certainty and precise decisions on risk. Have you seen the same in your projects?

For our profession to advance and move agile outside of its traditional product development stronghold, our organisations must adapt and change. To do this means addressing the illusion of certainty – believing that we are confident, at the time we begin our project, that we know what we want to purchase at what price.

Now, many amongst you may question are we ever sure we will get what we pay for when we sign the contract. But, let me assure you that it is possible to address the commercial processes for the better. I am not going to lie to you, it takes a lot of engagement with your legal team, who want a water-tight contract; you’ll work with your procurement team to get the decision making and provider selection more modular, and introduced much earlier in the project life cycle. Yes, your view on risk, market engagement, price certainty and your model contracts are likely to change significantly. But the benefits are well worth it.

In my case, my mistake was not asking the market: “What is your view on my problem?” All that time put into requirements could have been moved forward, drawing upon the experts’ knowledge to define a pragmatic outcome.

A silver lining to our current lockdown situation is that you may have a few moments to step back, consider a shift in the ways of working. You could take a few weeks to design, test, and embed improved processes so your organisation can live the ethos of agile and be more efficient and flexible in the long term.

I’d welcome hearing about your experiences in undertaking procurement for agile projects.


Join us for a webinar on Procuring for Agile Projects on 23 April. 

Download the whitepaper


Join the conversation!

Log in to post a comment, or create an account if you don't have one already.