Agile Procurement – What is it, when would you use it and why would you use it?

What’s the problem with traditional procurement?

Often, end-to-end procurement can take six months or more due to detailed specification development and approval; contract development; time out to market; detailed evaluation and protracted negotiations. After this detailed and protracted process, it would be unusual for (business / technical, regulatory) requirements NOT to have changed before the solution is delivered; potentially resulting in a solution that’s not fit for purpose, and a problematic and dysfunctional supplier relationship.

So, is there an alternative that can both speed up the procurement process and deliver a better suited solution / contract partner? It may be that Agile Procurement is the answer.

What is Agile Procurement?

Chances are that you’ve already heard of Agile / DevOps, and possibly even experienced, Agile techniques in a project / development environment. Agile techniques work particularly well in this case because they’re more likely to produce results faster and be more attuned to client requirements than a typical ‘Waterfall’ approach.

Agile techniques can also be adapted for procurement to deliver faster results that are more attuned to client requirements, for both Public and Private sector procurement. That is, Agile Procurement places emphasis on the solution outcome (inherent capability and flexibility) and the capability and approach of the supplier, as opposed to traditional procurement where detailed specification development and desk based evaluation drive the process.

The key differences between a traditional and Agile Procurement can be summarised as:

Specification Detailed requirements developed upfront High-level outcomes drafted and refined ongoing
Draft Contract Fully developed and released with RFT Drafted and released with RFT, furter refined
Desktop Evaluation Focus on compliance with Specification Focus on supplier capability and experience
Interactive Evaluation Presentation and 'static' mockup Implementatation and demonstration of an outcome
Negotiations Based on Contract and Specifcation departures Based on departures and lessons learned during development
Project Delivery Focus on delivery to plan and Specifications, change is an exception, big bang Focus on the interactions, collaborations, change expected, iterative and ongoing

The key point to understand is when should Agile Procurement be used? Fortunately there are some (happily common!) circumstances where Agile Procurement offers substantial benefits.

When would you use Agile Procurement?

  • Where potential solutions are already known to exist, are mature and probably already embody standard, good or best practices. Typically, these are administrative functions (e.g. Financials (accounting, assets etc.), HR, CRM, ERP etc.) that, ‘out of the box’ (OOB) deliver the required functionality through configuration and / or limited customisation.
  • Complicated solutions (counter intuitively, almost the opposite of the above) that would require significant customisation and/or development effort. For example this might be for:
    • procurements in areas where you consider yourself to have a competitive advantage (e.g. unique processes) or for new / emerging industries (where common / good practice has yet to evolve); or
    • new / emerging service requirements within a new or specific legislative set (i.e. the service may be similar to other jurisdictions, but the legislative / regulatory environment is significantly different).

Why would you use Agile Procurement?

  • To reduce the time and effort for the procurement process (compared to a traditional approach), via:
    • Specifications being outcome focused (i.e. what do we want to do (higher level, less detailed specification and hence fewer requirements in number) as opposed to input focussed (what we want to do AND how do we want to do it, more detailed specification, large number of requirements). Further, contracts in an Agile Procurement process would typically go to market in a draft form, with more focus on the nature of the working relationship with the supplier than otherwise typical;
    • Possibly reducing time out to market. A reduced requirements set makes it easier and quicker for the market to respond; and/or
    • Reducing desk evaluation time. The reduced number of, and less complex requirements set (outcome focused) is easier / faster to evaluate.
  • To increase the probability of acquiring a better suited solution. During the evaluation process, instead of the traditional prospective supplier(s) presenting their detailed response and doing static mockups and demonstrations, you actually set them tasks which require them to use their proposed solution, to develop capability interactively. These real-time tasks might include working with you to:
    • add or modify products / services / capability to demonstrate OOB functionality; and/or
    • develop some unique / custom requirement (or configurational requirement) to demonstrate the solution’s flexibility. 
  • To increase the probability of contracting with the right supplier. The abovementioned live / interactive development process allows you, as the client, to assess the supplier’s capability, attitude, soft skills etc. by working with the same supplier staff you’ll be working with during the implementation AND walk away earlier and with less cost, if ‘things’ aren’t working as expected and required.