Any.Talk Podcast Episode 10 - Agile Procurement
One of the tenets of agile, is people and relationships over processes. So does the agile methodology work in big organisations, such as government departments? We discuss this as well as when and how to implement agile successfully in a project.
Listen to the full episode below or stream it on Spotify, Apple Podcasts or anywhere else you listen to podcasts.
Any.Talk Episode #10: Agile Procurement
Annie-Mei: Hello and welcome to another year of Any.Talk, a podcast about project management, people and procedures. We’re very excited for what’s in store for the year ahead, so without further ado, here’s our first episode of 2021.
Hello, and welcome back to Any.Talk. Today on the show we’re going to be discussing agile procurement. We’ve got two new guests on the show today, but first I’d like to welcome back Anywise General Manager Steven Kouloumendas. Hello, Steve.
Steve: Hello, Annie-Mei. Thanks for having me.
Annie-Mei: And our two guests on the show today are Anywise Principal Consultants Tom Dalton and Eric Dempster-Hoad. Good morning, Eric and Tom.
Tom: Good morning, Annie-Mei.
Eric: Good morning, Annie-Mei. Thanks for having me.
Annie-Mei: Ok, so if I could start with Steve. If you could just give us some background on the topic. What does the government procurement landscape look like?
Steve: Thank you, Annie-Mei.
So today we’ll be talking about agile procurement as it mainly applies to how the government does procurement. In the government landscape, including all the major departments here in Australia, including the Department of Defence, the Department of Health, DFAT, all the organisations that conduct typically large procurement.
In the context of Defence for example, Defence tries to conduct procurement in order to establish capability for the Australian Defence Force and all the different service branches. Fundamentally trying to put either equipment or capability into the hands of our defence forces that defend our great nation.
The way they do that typically, is to define a requirement and then approach the market through an open tender or sometimes a closed tender. But approach the market to acquire that solution, be it a widget or a large fighter jet or submarine, for example. Throughout that process there’s typically different ways to do that. So we’re talking everything from smaller procurements of values that aren’t that great, all the way to large dollar sums of 20, 30 even 50 year programs that are capabilities for defence.
So in that context, we talk about agile procurement and we talk about traditional procurement. The traditional procurement we talk about is typically a waterfall approach. Following on some of the previous conversations that we’ve had about development programs where we’ll develop things in a waterfall approach where you typically define a requirement. You then design and build something in accordance with that requirement. You would then test it and then you would hand it over to a customer. All of those are typically done in a sequential manner.
Now that can be a very efficient process at times. There are times where that can fail though. Some of those times are when the requirement can change whilst you’re actually designing the product or about to hand over the product. Something in the landscape or the environment may have changed and it’s fundamentally changed the usefulness of the product that you’ve delivered or the product that you’ve acquired.
So it’s an important concept to understand how we could do that better and agile procurement can in certain scenarios present a much more efficient way of tracking the landscape and looking at better ways to make sure we are providing whatever the procurement agency is. So whichever department or agency that is procuring the product or capability, and making sure we can give them and solve the problems that they need to be solved in a faster, more responsive manner.
Annie-Mei: Okay, thanks Steve. So Tom, Steve mentioned how the agile procurement method differs from more traditional methods. So when should agile procurement be adopted?
Tom: I think it all depends, right? So within Defence, as Steven was saying, predominantly the projects in Defence are the waterfall approach. But there are also some quite big programs such as the [LAND] 1508 program, which is for the Special Forces and that has adopted an agile process or methodology (Scrum process), and that’s working really well.
It works well because it’s over a long time, but it’s a lot of procurements within that time. So they’re always changing their requirements, they’re always evolving and the agile works perfectly for that.
Annie-Mei: Okay great, thanks Tom. And Eric, when should agile procurement not be adopted?
Eric: Thanks Annie-Mei.
Look I think as Tom said, there’s a continuum of possibilities for every procurement, but from a large organisation’s perspective like the Department of Defence or Australian Government branches where there’s a low-risk project where the requirements are really well-known and really defined, potentially there’s less of an appetite to adapt that risk-based approach in a procurement.
In those senses, it may benefit from just approaching it in a waterfall sense. You know your requirement; you go out to market and we purchase something, or you approach the market for some prices, and we purchase something. Oftentimes in large organisations change is difficult. Agile encourages people to embrace change, be flexible and take risk-based approaches. Sometimes those changes are difficult to embrace. So that’s where you see, potentially the waterfall approach might be providing some benefit.
Annie-Mei: Okay, thanks Eric. Back to Steve now, Eric mentioned that it’s difficult for large government organisations to adopt agile approaches so what are the benefits of agile procurement?
Steve: This is a really interesting question. One that I’ve experienced myself in understanding it. I think the first part of that question – why it’s so difficult for some government organisations to adopt a more agile approach to procurement – these organisations have a strong history to them, they’ve got established processes, procedures that they’ve done procurement in the past, and it’s typically done in an established manner. And it’s typically a waterfall approach.
So you’ve got not only got established processes and procedures, you’ve also got organisational culture. That is very wedded to the current policies and procedures that they’ve been adopting and utilising for the last 20-30 years. So it makes a lot of sense to stick with that. And as with any large organisation, it’s difficult to move away from that and new concepts are sometimes difficult to grasp and establish.
But there have been numerous success stories within these organisations as well of positives. So ways that either small projects or elements of larger departments have managed to implement agile procurement and do so successfully. And reap some quite significant benefits including just being quicker to respond to the environment. So having a really short cycle from the moment a user or the need arises, all the way to actually conducting a procurement is one of those benefits.
So having a cycle from someone identifying a need, all the way to actually getting a procurement done and getting the capability in someone’s hands, that really needs to be front and centre. The way government organisations measure how successful their procurement operations are and that can typically be achieved in a much faster manner using some of these agile procurement methodologies. No matter how hard they are to implement.
Eric: I think Steve touched on a really key point there, Annie-Mei. An agile procurement methodology encourages both sides of that procurement to own the outcomes of the procurement. And that encourages innovation from a government perspective in industry to respond to that requirement that the government has and identify potentially where the government hasn’t identified their requirement correctly. Or has missed an opportunity to go one step further. It encourages industry to provide better response to that underlying as opposed to just responding to the list of requirements that the consumer has delivered to them.
Steve: Indeed. And if I can continue to elaborate. Great points, Eric.
One of the tenets of agile, is people and relationships over processes. And I think that really comes to bear in this context as well with what you just discussed because it’s valuing these relationships. And being responsive to the environment can really help assist with what you just described as innovation and getting and focusing on the solution, not focusing on the contract that says ‘Guess what, you said you wanted this with an aluminium washer not a stainless-steel washer. Too bad we’ve already shipped it with the aluminium washer, even though we know it’s going to corrode when you put it into a sea environment’.
Some of these things are really important and they’re really important benefits in that whole discussion of agile procurement versus some more traditional aspects. I’ve seen it happen before where the government will put themselves into dispute with the contracted parties as a result of differences in opinion or arguing about a contractual element. During that whole period, there’s only one element that suffers, and that’s the problem has not yet been solved.
Annie-Mei: Ok, so maybe we move onto more of the risks and challenges of agile procurement?
Tom: I see the main risk or challenge for agile procurement, especially in the Defence organisation is the change management that is required. That takes into account the people, the processes, the tools, all that kind of stuff. Defence is quite a large, moving organisation and they’d like to adopt the agile methodology – and they have in some projects, and those projects have been quite successful, and the stats coming out of those projects are looking really good – but it’s predominantly a waterfall project management organisation.
All their processes, their procedures, all their people, they all understand waterfall. And what we’ve been able to do in the past is include agile methodology within the waterfall methodology, which works but to actually shift from a waterfall methodology to an agile methodology, the change management involved in that is quite large. That would probably be the biggest challenge that I could see.
Annie-Mei: So Tom, do you see them, if we just talk about Defence, do you see them adopting more agile procurement strategies in the future?
Tom: Yes, Annie-Mei. Yes, definitely. With the good reports that are coming such as the project 1508. All the reports that are coming out of that and the successes they are having, Defence would like to adopt it within their projects, and they’ll do it, it’s just a time thing.
Eric: There’s a drive from the end users, Annie-Mei. At least within the Department of Defence for a more agile and responsive delivery of capability and that will drive a change, I believe. But as Tom said, change management is a complex process and it takes time. There’s a whole established framework around delivering large capability projects in a waterfall manner within Defence. So an organisation just takes time to embrace change.
Tom: Some of the other risks that we’ve discussed previously basically revolve around establishing the long-term contracts which would usually happen within a waterfall project. An agile project, you wouldn’t preferably establish a long-term contract, but a long-term contract has benefits. A risk could be that you miss out on some of those benefits.
Steve: Very good point, Tom. And I think in the context that you just described as well, so more in the implementation of agile – how we go about actually establishing that when it may not be a long-term contract. It almost brings up some of the risks of an agile approach. And I think there are a number of things that can be done to negate that as well.
So everything from establishing contracts in advance or standing of the contracts where we identify a range of suppliers that would be suitable to provide the broad capability set and may or may not be needed at the start, but signing them up to agreements where there’s contractual already in place for certain items or certain services. So when the need arises, there’s no need to go back and solicit the market because we already have a good understanding of the broad domain and the landscape of the suppliers and what they can provide. And it really shortcuts the time to actually engage them and get the capability that you’re after.
Annie-Mei: Okay great, well we’ll wrap it up there. So thank you Steve, Tom and Eric for talking about agile procurement.
Steve: Thank you, Annie-Mei. Thanks for having us.
Tom: Thank you, Annie-Mei.
Eric: Thanks, Annie-Mei.