How Should We Approach the DIP? Start with Force Design, Then Build for Delivery

The Defence Investment Plan will be judged by the operational capability it creates - not simply by the programmes launched or systems purchased. Stephen Jefferies explores why coherent long-term force design must be supported by a delivery system built for technological change, assurance, adaptability and scale.

At the SDE Nexus session on uncrewed systems this week, I posed a question that prompted a great deal of discussion: how do we approach the Defence Investment Plan?

It’s a deliberately broad question. The DIP will encompass many different capabilities, priorities and timescales. But the challenge becomes particularly clear when we consider rapidly evolving uncrewed systems.

How do we move promising technology into operational use quickly? How do we increase capacity and scale when required? And how do we achieve that without creating unacceptable compromises in security, assurance, training or support?

One response to my presentation made an important point: before discussing procurement processes, specialist resources or delivery tools, the UK needs a clear and sustainable view of what it wants its Armed Forces to achieve.

I agree.

If programmes are repeatedly procured, changed or cancelled as governments and defence reviews adopt different visions of the future force, instability is inevitable. Funding is consumed without creating enduring capability. Suppliers find it harder to invest. Skills disperse. Gaps emerge between strategic ambition and what can actually be deployed.

But I do not believe we can separate that long-term vision from the machinery required to deliver it. Force design tells us what military power the UK needs to sustain. The delivery system determines whether that intent can become assured, supportable and adaptable operational capability.

We need both.

A Plan Is Not Yet a Capability

One of the recurring patterns I have seen throughout my career is that an individual technology can attract considerable enthusiasm while the wider capability receives less attention.

A platform may perform well in trials. A sensor may generate valuable information. A communications component may demonstrate impressive range or resilience. Each can be successful on its own terms.

But operational capability exists only when those elements work as part of a system.

That means considering communications, data, cyber security, information assurance, training, deployment, maintenance, supply, integration and command structures. It also means understanding the people, authority and infrastructure needed to operate the capability safely and effectively.

These are sometimes treated as matters to resolve once the technology has proved itself. In my experience, that is precisely when they become constraints.

A successful demonstration is valuable, but it does not automatically tell us how the system will be accredited, fielded, supported, upgraded or scaled. Nor does it tell us what happens when it must connect with existing platforms and networks, operate in contested environments or be maintained by people who weren’t involved in its development.

The DIP should therefore be judged not simply by what is purchased, but by the operational effects that can be generated and sustained.

Start with the Force We Can Sustain

The first requirement is a sufficiently stable view of the force the UK needs.

That doesn’t mean attempting to predict every future threat or freezing the design of the Armed Forces for several decades. The pace of technological and geopolitical change makes that impossible.

It means being clear about the enduring outcomes we expect Defence to deliver, the missions for which we must retain sovereign capability, where we expect to operate with allies and which capabilities must be available at meaningful scale.

This also requires realism.

A force design that cannot be resourced, supported or replenished is not a sustainable force design. Ambition, affordability, industrial capacity, people and readiness have to be considered together.

For uncrewed systems, that raises difficult questions. Which assets should be reusable and which might be treated as expendable? Where is exquisite capability necessary, and where would larger numbers of lower-cost systems create a better operational effect? What must be sovereign? What can be sourced from allies or commercial markets? How quickly must systems be replaced, refreshed or reconfigured?

Those are force-design questions before they are procurement questions.

Design for Change, Not a Fixed End State

The technology cycle for uncrewed systems is considerably faster than the traditional lifecycle of many Defence programmes.

Sensors, processors, software, communications technologies and countermeasures can all change while a system is being evaluated and acquired. Components that are readily available during an initial demonstration may be unsuitable for a UK or NATO programme because of their origin, security implications or supply-chain risk.

If we define success as delivering a fixed technical configuration, there is a danger that the capability will begin ageing before it reaches meaningful operational use.

The alternative is to design for change from the outset.

That means using open architectures where appropriate, defining interfaces clearly and avoiding unnecessary dependencies on components that cannot be replaced. It means distinguishing between the parts of a system that must remain stable and those that should be refreshed frequently.

Modularity will not solve every problem. Open architectures require governance, configuration control and integration discipline. However, a considered approach can make it easier to introduce new sensors, payloads, software and communications components without redesigning the entire capability.

The objective should not be to procure something described as “future-proof”. Nothing is. The objective should be to create a capability that can evolve without having to restart the programme every time the technology or threat changes.

Plan for Scale Before Scale Is Needed

Scale is often discussed as a later phase: demonstrate the concept first, then work out how to increase production and deployment.

That sequencing is understandable, but it can conceal important constraints.

A prototype may depend on scarce specialists, manually intensive integration work, temporary security arrangements or components that cannot be obtained in volume. It may work only because the small team behind it understands every aspect of the system.

None of those conditions necessarily survives scale.

The route to increased capacity should therefore be considered early. That includes manufacturing, component availability, secure facilities, testing capacity, training, maintainability, network capacity and access to suitably qualified and experienced people.

It also requires authority.

Teams cannot deliver at pace if every important decision must travel through layers of governance that were designed for a different type of programme. That does not mean abandoning scrutiny or proven decision-making processes. It means making decision rights clear, giving appropriately skilled people the authority to act and providing better information at the points where decisions need to be made.

Pace comes from shortening the distance between evidence and decision – not from removing accountability.

Build Assurance into the Delivery Model

Cyber security and information assurance are sometimes characterised as obstacles to pace. I think that framing is unhelpful.

The real problem occurs when security is treated as a test at the end rather than a design consideration throughout.

With uncrewed systems, every platform may also be a network node, a source of intelligence and a potential point of compromise. We need to consider what data is collected, where it’s processed, what needs to be transmitted and what could happen if the asset is lost, captured, interfered with or spoofed.

Sending every piece of raw data across a constrained network is unlikely to be practical or desirable. More processing and filtering may need to happen at the edge, with the system passing on information that is relevant to the operational decision.

Those architectural choices have consequences for hardware, software, communications, security and command. They cannot sensibly be bolted on after the platform has been selected.

Security also reaches beyond the equipment. If Defence wants to draw innovation from smaller companies, those suppliers need realistic ways to operate within tightening security requirements. Clearance, facilities, cyber controls and access to secure development and testing environments all require time, money and specialist resources.

If those constraints are left unresolved, Defence may say it wants a diverse and innovative supplier ecosystem while creating conditions that only the largest organisations can navigate.

Treat Training and Support as Part of the Operational Concept

Training and lifecycle support are easily overlooked when attention is focused on getting new technology into the field.

For higher-volume, lower-value and rapidly evolving assets, the traditional support model may not always be appropriate. It may be neither affordable nor operationally sensible to support every system as if it were a small number of expensive platforms expected to remain unchanged for decades.

Different systems will require different choices. Some components may be repaired. Others may be replaced. Software may change more frequently than hardware. Training may need to follow the user rather than being delivered only in a fixed location. Digital and hybrid training could become an integral part of how capability updates are introduced.

These are not secondary commercial considerations. They affect availability, readiness and operational confidence.

If people aren’t trained when the capability changes, or if assets cannot be returned to use quickly enough, the programme may have delivered equipment without delivering the intended effect.

Build an Ecosystem, but Give It Structure

No single organisation possesses all the technology, specialist knowledge, infrastructure and operational understanding required to solve these challenges.

Defence will need to bring together MOD organisations, the Armed Forces, primes, specialist SMEs, start-ups, academia and international partners. But calling this an ecosystem does not make it one.

Effective collaboration needs structure. Participants need clarity about the outcome, interfaces, responsibilities, commercial arrangements and decision rights. Intellectual property and security expectations must be understood. Smaller suppliers need routes into programmes that do not require them to carry risks they cannot absorb.

Primes will continue to have an important role in integration, scale and long-term delivery. SMEs and start-ups can provide specialist expertise, agility and technology. The question is how to combine those strengths without forcing every contribution through a delivery model that removes the very pace and innovation being sought.

In practice, that may require a thinner integration layer, clear technical and security standards, shared delivery tools and teams organised around operational outcomes rather than organisational boundaries.

The Outlook the DIP Requires

If the DIP is to deliver lasting operational capability, I believe it needs an outlook built around six principles:

  1. Begin with operational effect. Define what the Armed Forces must be able to achieve and sustain before deciding what equipment to acquire.
  2. Treat capability as a system. Consider people, data, networks, security, training and support alongside the platform or technology.
  3. Design for evolution. Assume that threats, components and software will change, and create architectures that can accommodate that change.
  4. Plan for scale early. Identify the constraints that will appear beyond the demonstration stage before they become programme blockers.
  5. Integrate assurance from the outset. Use security, testing and information assurance to shape good design rather than treating them as final hurdles.
  6. Align authority with expertise. Give suitably qualified people access to the information, tools and decision rights needed to make progress without weakening accountability.

The hardest part may not be identifying these principles. It will be applying them consistently across programmes, spending decisions and political cycles.

A coherent long-term force design is essential. But it must be accompanied by a delivery system capable of translating that design into operational effect – and then adapting as the threat, technology and available resources change.

That is how I believe we should approach the DIP: not as a list of procurements, but as an opportunity to create a more coherent, adaptable and sustainable route from strategic intent to operational capability.

Below is my presentation delivered at SDE Nexus: Uncrewed Systems – From Innovation to Operational Capability.

Share the Post:

Related Posts