Agile procurement framework
Apply agile methodologies to support iterative testing and learning to achieve great innovation buying outcomes.

Why agile procurement is important
When buying projects use a challenge statement to attract innovative solutions, they don't know the end solution. They face the challenge of structuring and documenting a procurement approach that has a lot of uncertainty.
Aligning methods for ICT project delivery and procurement
Agile is a form of project management designed to deliver products and services iteratively. With a focus on learning quickly and adapting, agile is well-suited to managing uncertainty. Agile methods are increasingly used in the NSW Government for ICT project delivery but are less familiar in procurement.
Standard procurement requires buying teams to know all procurement parameters before approaching the market. When buying innovation, teams should form instead a hypothesis about each of those parameters, expect to learn new things and periodically revisit any decisions made. Learning and adapting is at the heart of agile. Affected parameters include:
- what they want to buy
- how they will evaluate it
- how much it will cost
- the risks they will need to manage
- how long it will take
- how they will deliver it
- how they will contract for it.
This page describes how buying teams can adopt agile methodologies to achieve great innovation outcomes and manage risk in their buying projects. It helps teams apply agile procurement in a public sector context while meeting procurement obligations.
Learn more about the agile public procurement framework.
While this page focuses on agile procurement, project teams looking for guidance on agile project management methods can read more on the Agile principles and benefits and refer to the Digital NSW toolkit. Some agencies may also have internal agile experts.
When to apply agile methods to procurement
Agile procurement is the recommended approach for managing innovation procurement. It is also useful for any procurement with a multi-stage approach if there is some uncertainty about the outcome. For ICT procurement there is a high likelihood that agile methodologies will also be used for delivery or implementation of the solution.
Agile procurement supports every step of the innovation buying journey, as shown in Figure 1. Buying teams should set up to apply the agile public procurement framework as early as possible.
How to apply an agile public procurement in each phase
There are also specific actions to either prepare for, or implement, an agile framework at each phase of procurement.
The decision to use an agile methodology forms part of whether a buying project qualifies for innovation procurement.
Getting buy-in to use the agile public procurement framework from the start creates a strong foundation for a buying project. It gives the buying team the best chance of identifying the right stakeholders. It also helps with managing expectations about the steps to follow, the time to allocate and how decisions will be made.
The Discover phase of innovation procurement sets up how the agile procurement framework will apply. Also, how it will interact with other processes like project management and business cases. Each step in the Discover phase plays an important role in setting up agile processes not often used in procurement.
In the Scope step, problem shaping leads to an outcome-focused challenge statement which attracts innovative proposals. It is also the frame of reference for documenting requirements and evaluating proposals. Thus, it drives the evaluation process which generates the insights to help refine later stages. Scoping is therefore foundational for iteration.
In the Pathway step, early views on the best methods for supplier engagement and solution testing are formed. These shape the timing and methods for uncovering new information. The pathway therefore proactively drives iteration.
In the Mobilise step stakeholders will need to understand how to participate in agile procurement. This includes working collaboratively and anticipating how their role will evolve as information is uncovered. This will help future phases run more smoothly. The mobilisation guidance ensures that stakeholders:
- understand the buying objective and the role of the outcome-focused challenge statement
- know how evidence and research will form the basis of an iterative approach
- have clearly documented roles and ways of working
- embrace and expect change as part of execution and know how to govern it.
In the Market research step, there is often a limit to information that can be uncovered through desktop research and/or industry engagement. Thus, the stages of procurement and iterations between them become an ongoing form of market research. Buying teams can think ahead about what new insights at each stage might shape the next steps in the process.
In the Iteration plan step, buying teams apply the agile public procurement framework by building on the buying pathway to create project-specific stages, gates and decision-making processes.
If a Business case is required there will usually be formal decision gates that unlock funding. These should be reflected in the iteration plan. This applies even for less formal business cases. Aligning business case or funding stages with the iteration plan will ensure that evidence from procurement is informing investment decisions. In turn, this ensures procurement stages are designed to collect the evidence needed.
During the initial Plan phase of an agile procurement, the outcome-focus and iteration structure gets formalised into procurement processes and documentation. Iteration is not usually part of procurement for buying projects involving known solutions. Nor is it usually accommodated by procurement templates for requirements or strategies. The Document your buying strategy page has guidance on how to approach procurement strategies for agile procurement.
The challenge statement from the scoping step, stages and stage gates from the iteration plan will be needed to complete:
The Requirements step, including:
- Market-facing requirements (usually an outcome-focused challenge statement)
- Stage-based requirements (e.g. the requirements of a Proof of Concept)
- Stage gates where stage design can be revisited based on any new insights.
The Evaluation criteria step, including:
- Outcome-focused evaluation criteria
- Stage-based evolution of evaluation criteria (e.g. cyber security might be assessed in detail as part of a Proof of Concept, but not at an earlier stage like a pitch).
The Strategy step, including:
- The milestones and expected timing for each stage that align to stage gates
- Types of changes and governance structures for each.
Each subsequent stage starts with an Iterate step, where requirements, evaluation criteria and the stages of the buying strategy are revisited based on insights from the previous stage. Any resulting changes should trigger some action, based on the change governance in the strategy.
During the initial Source phase of procurement, buying teams need to be able to communicate agile structures to suppliers. Stages and iteration are not usually accommodated by procurement templates for market-facing documentation or evaluation plans. Guidance on tailoring market-facing documents and evaluation plans for agile procurement is coming soon.
Information relating to iteration in tender documents should come directly from documents approved in the Plan phase. Information from the Plan phase that will need to be communicated to suppliers include:
- stage names, objectives and approximate timing
- staged requirements and associated evaluation criteria
- staged funding, including any uncertainty where funding of later stages is subject to a business case
- how any iterations will be communicated to suppliers, e.g. if the scope of a testing stage needs to change based on the evaluation of the previous stage.
Evaluation plans will also need to capture information about when iteration will occur and how change will be managed. This should come directly from approved Plan phase documents. This includes:
- staged requirements and associated evaluation criteria
- when evaluation criteria will be revisited and how any changes will be governed and communicated.
If there are subsequent Source phases (e.g. second or third rounds of shortlisting), the tender documents and evaluation plans will need to be updated. Updates should highlight any changes that impact suppliers.
An agile procurement approach can involve multiple Manage phases. Like in the Source phase(s), it involves bringing forward prior lessons to iterate upon and shape future steps.
The contracting approach documented in the buying strategy may be adjusted in line with the evidence uncovered during the previous Source and Manage phases. It may itself include multiple milestones that allow for iteration.
If any change occurs, project teams should check for probity implications or other risks. They should manage these through clear communication with suppliers or other stakeholders covering what the change is, why it has occurred and any potential impacts.
Who to involve
To support iteration, contributions of subject-matter experts are needed through all procurement stages. Every stakeholder involved in the procurement should be informed of the agile, iterative approach as early as possible. This ensures they can help anticipate changes and adapt to new evidence.
To ensure each stage uncovers the right information at the right time, subject-matter experts should be willing to 'look around the corner' and participate in:
- the design of the procurement pathway
- defining the scope of each stage
- identifying the information that will be requested from suppliers at each stage
- setting stage-based evaluation criteria
- assessing and reassessing risks and mitigants.
After each stage, SMEs should reflect on learnings from the stage and help refine the information requested from suppliers at later stages.
Every stakeholder has a role to play within the iterative structure of agile procurement, but certain stakeholders have specific responsibilities in creating structures and driving iteration.
Expand the headings below to read more about their contributions:
Project leads should drive agile ways of working within the buying team and any engaged stakeholder groups, with a particular focus on subject-matter experts. They should also factor in early stakeholder engagement when developing project timelines.
If project leads are not familiar with agile methods, they will find useful resources in the mobilisation, pathway and iteration plan steps.
Agile procurement can feel difficult because most templates, guides and practices are not designed with stages or iterations in mind. Early collaboration with procurement teams can make it easier to tailor templates and design agile procurement practices. Procurement teams can also help get ahead of value for money, compliance and probity matters.
In turn, procurement teams should aim to be comfortable iterating and revisiting decisions when new information emerges. They should support buying teams to create iterative structures where change is expected and governed rather than avoided. Where risks are managed well rather than removed.
Service designers can help embed agile ways of working in a buying team by facilitating mobilisation activities, agile management tools and other ceremonies as the procurement progresses.
Approvers and financial delegates should be willing to revisit decisions based on new evidence when signing off on the procurement strategy, approving spend and entering into agreements with suppliers. They should focus on ensuring changes are justified and well-governed.
Buying teams may need to invest time into building the comfort of approvers, preparing them to expect changes and reassuring them about how change will be managed. The iteration plan is a useful tool for creating buy-in for agile practices.
Experts in risk domains such as probity, legal, governance, IT, cyber security, data privacy and artificial Iintelligence may be engaged in an innovation buying project. They should be comfortable with a degree of uncertainty over their role at the start of the process, when they are first engaged. These experts can help anticipate when risks in their domain of expertise can be more accurately identified. They can also help design their contribution to future stages and iterations. Early and consistent engagement throughout the process will ensure they know when there is enough information for them to make detailed contributions.
Buying teams may need to invest time into building the comfort of these risk domain experts, reassuring them of how their contributions will be anticipated and managed at each stage. The iteration plan is a useful tool for creating buy-in for agile practices.
Agile procurement framework resources
Explore Test and Buy Innovation
- Stakeholder managementeast
- Stakeholder roles and responsibilitieseast
- Engage the right expert for each stepeast
- Agile procurement frameworkeast
- Agile principles and benefitseast
- Agile buying for the public sectoreast
- Probity when buying innovationeast
- Amplified probity riskeast
- Probity risk treatmentseast
- Get ahead of probity and riskeast
- Risk management when buying innovationeast
- Key innovation buying risk conceptseast
- Apply your agency’s risk frameworkeast
- Worked risk exampleseast
- Policy support for buying innovationeast
- The innovation buying journeyeast
- Learn about Test and Buy Innovation Programeast
- Get help from Test and Buy Innovation advisoryeast