Agile procurement framework

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.

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.