Taking an adaptive approach to defining a programme

Navigating uncertainty: why adaptability is essential

Imagine trying to chart a course through a landscape that’s still forming. The destination is clear, but the terrain shifts as you move forward. That’s what defining a programme often feels like; especially in complex, fast-evolving environments.

In these situations, a rigid, one-shot approach to programme definition can become a liability. It assumes certainty where there is none. It locks in decisions before the full picture is known. And it risks building a structure that’s elegant on paper but brittle in practice.

We’ve found that a more adaptive approach works best; one that embraces iteration, feedback, and flexibility, leads to stronger outcomes, better engagement, and more resilient delivery. It’s not about being vague or unstructured. It’s about being responsive, deliberate, and open to learning as you go.

Building as we go: what adaptive definition looks like

Defining a programme is often treated like writing a manual: gather the requirements, write the document, get sign-off, and move on. In reality, it’s more like designing a living system. It needs to breathe, evolve, and respond to its environment.

In our client work, we’ve seen three principles consistently underpin successful adaptive programme definition:

• Start with intent, not certainty

At the outset of a programme, you may have a vision or a target operating model, but not a detailed map. That’s okay. The goal is to define enough to move forward, while leaving space to refine as you learn more. Think of it like sketching the scaffolding before the building takes shape.

• Build clarity through iteration

Rather than trying to write the perfect Programme Definition Document (PDD) in one go, break it into features or components. Develop each one through short cycles: draft, review, refine. This allows for early feedback, better alignment, and higher quality. It also creates momentum and a sense of shared ownership. Figure 1, shows an example of an iterative approach, which balances the sprint cycle with light governance and continuous improvement.

Figure 1: Example of a Sprint Cycle

• Design governance that supports agility

Adaptive doesn’t mean chaotic. It means having a governance framework that’s rigorous but light. A framework that enables decision-making, manages risk, and supports change without becoming a bottleneck. It’s the difference between a scaffolding that supports growth and a cage that restricts it.

This approach is especially valuable when the programme is exploratory in nature, when you’re testing new ideas, engaging with a wide range of stakeholders, or working in a space where the technology or policy landscape is still shifting.

It also helps when you’re working with multiple delivery partners or suppliers. An adaptive approach allows you to bring them in at the right time, with the right level of definition, and co-create the path forward.

Lessons from the field: how it worked in practice

We recently supported a client in defining a complex, multi-phase programme aimed at developing early-stage technologies. The programme was ambitious, cross-cutting, and operating in a space where the “what” was clear, but the “how” was still emerging.

Rather than trying to lock everything down upfront, we took an adaptive approach to programme definition. Here’s how it worked in practice:

Phase 1: Programme Definition

We structured the definition phase into five sprint cycles. Each sprint had a clear focus team mobilisation, initial research, stakeholder engagement, feature development, and compilation. This gave us a rhythm and a sense of progress, while allowing us to respond to new information as it emerged.

We developed the Programme Definition Document feature by feature. Each feature (such as governance, stakeholder engagement, risk management, or delivery planning) was treated as a mini-project. It was drafted, reviewed, and refined through collaboration with the client and the wider team.

This approach had several benefits:

• Higher quality outputs: Each feature was developed with care, reviewed by the right people, and aligned with the overall programme vision.
• Faster feedback loops: We didn’t wait until the end to get input. We shared early and often, which helped surface issues and build consensus.
• Better integration: Because features were developed in parallel, we could spot overlaps, gaps, and dependencies early,and address them before they became problems.

We also ran a series of workshops to support the definition process. A vision and risk workshop helped align stakeholders around the programme’s goals and surface key risks. A stakeholder mapping session helped prioritise engagement. And an industry day brought external partners into the conversation, setting the tone for future collaboration.

Phase 2: Resource Generation

With the definition in place, we moved into resource mobilisation. This involved securing funding, setting up commercial agreements, and preparing for the first tranche of delivery. Again, the definition continued to evolve, refined through feedback, shaped by emerging requirements, and informed by ongoing engagement.

Phase 3: Programme Delivery

The delivery phase was designed to be tranche-based and flexible. Projects could be commissioned, paused, or pivoted based on progress and learning. This allowed the programme to pursue promising ideas, drop dead ends, and adapt to changing circumstances.

Figure 2, shows a visual representation of how defining a complex, multi-phased programme aimed at developing early-stage technologies looked in principle.

Figure 2: Example of an Adaptive Approach to Programme Management

Key Recommendations

Taking an adaptive approach wasn’t always easy. It required discipline, transparency, and a willingness to let go of the illusion of control. But it paid off.

Here are some of the key lessons we took away:

What worked well

• Stakeholder engagement was stronger: The iterative approach created more touchpoints for engagement. Stakeholders felt involved, heard, and invested.
• The PDD was better: By developing it feature by feature, we ensured each section was robust, coherent, and aligned with the rest.
• The programme was more resilient: When things changed as they always do, we had the structures and mindset to adapt.
• The team was more connected: Working in sprints created a shared rhythm and sense of momentum. It also made it easier to onboard new team members.

What were the challenges

• Engagement was sometimes inconsistent: At times, key stakeholders were unavailable, which slowed reviews and decision-making.
• Documentation lagged behind: Because the focus was on iteration and responsiveness, some improvements weren’t fully documented.

Recommendations for next time

• Agree roles and responsibilities early: Make sure everyone knows who’s doing what, and what authority they have.
• Streamline commercial processes: Delays in contracting can derail even the best-laid plans. Build in time for approvals and have contingency plans.
• Document as you go: Even in an adaptive approach, it’s important to capture lessons, decisions, and improvements.

The Adaptive Edge: why this approach works

Defining a programme isn’t about writing a perfect document. It’s about creating a shared understanding of what you’re trying to achieve, how you’ll get there, and how you’ll adapt along the way.

An adaptive approach helps you do that. It allows you to start with intent, build clarity through iteration, and stay responsive to change. It creates space for collaboration, learning, and continuous improvement. And it leads to programmes that are not only well-defined, but well-positioned to succeed.

In a world where complexity is the norm and certainty is rare, adaptability isn’t a luxury, it’s a necessity. And when we combine it with empathy, structure, and a commitment to quality, we create programmes that deliver real, lasting value.