top of page

Starting with the end in mind: From Discovery into Delivery

As we approach the end of the government financial year, we often see an annual flurry of Discovery work commissioned on behalf of our customers. As specialists in the Discovery space we welcome this and plan for it every year; a well-run Discovery can deliver valuable, high-level insight quickly and set a project on the right path for Delivery, and the pressure of an end March completion date can ensure focus on the core issues.

However, when every investment has to offer value for money, all too often we see Discovery work commissioned that will only lead to shelfware or a flashy demo rather than the clear, considered recommendations and roadmap that are needed to enable a seamless transition into Delivery.

Discovery is often centred around a proof-of-concept or a technical demonstrator, but this can often miss the thinking around the broader context and feasibility tests that need to be met. Where does this project fit in the strategic landscape? How will it be funded? What is the roadmap for delivery? If Discovery is not commissioned with Delivery in mind, the risk is that the work grinds to a halt at the end of the Discovery phase and all the value is lost. Simply showcasing a new technology isn’t enough to explore the wider issues and a well thought through Discovery will ensure just enough work is also done around Delivery.

It is essential to start a Discovery by asking the right question, rather than jumping straight into looking at solutions. Taking the time to consider why we are doing something and what we want to achieve is a fundamental starting point. Having a Systems Engineering mindset means that we always start a piece of work by building understanding of the problem space, and we believe this activity should be factored into every Discovery.

Setting out the stakeholder landscape and analysing the key drivers, goals and desired outcomes of the project ensures that the reasons behind it are fully understood. Mapping out the wider context ensures that any dependencies, risks and constraints are surfaced early and allows us to judge the complexity of the translating Discovery into Delivery. This enables both the Discovery work and subsequent Delivery to be properly scoped, and gives confidence that that the problem space is fully understood.

It is also critical to determine how Discovery will deliver value: if it is simply an exercise to prove a concept, it is important to define why this is valuable beforehand and how the outputs will be used, for example to inform other pieces of work. If the value lies in progressing the project beyond Discovery then it is essential to commit to building this in from the beginning. Achieving change will require longer term commitment of funding and resources, and without a clear understanding that Discovery must also explore these factors, it can be easy to stall and lose momentum.

We often see projects paused at the end of Discovery due to uncertainty around funding or decision-making, even when there is a compelling case to continue at pace. These delays result in a loss of stakeholder engagement, potentially the loss of the collective knowledge of the team, and delays in achieving the change sought.

Discoveries are often commissioned with the goal of exploring the ‘art of the possible’ around technology – in the last couple of years there has been particular interest in AI for example - but this needs to be considered within the wider strategic and technical context. If Discovery is simply centred in technology, it can be very easy to end up proving a technology works (probably not for the first time) but having learnt nothing new around the challenges of implementing the change.

For policing especially, the scalability and transferability of any solution needs to be considered at the beginning: not all forces have the same capability, and therefore piloting and proving a solution in one force does not necessarily mean that it would be straightforward or even possible to deploy it at a national scale. Regardless of the technical feasibility, business design and architecture work needs to be carried out early to assess how to implement the solution in the real world, and to set expectations around what is actually possible.

For Tania Eagle, Lead Consultant for national policing, this is a critical part of Discovery. “Business design and architecture are such critical activities, particularly in policing where we see such a complex web of national, regional and local systems. Any Discovery or proof of concept work in this space really should start with this kind of analysis and an impact assessment to ascertain how the work fits into the existing landscape – will it duplicate, add value, or just cause more chaos and confusion?”

Returning to exploring new technology in Discovery, it is important to be realistic around the barriers around implementation. Gaining value from innovative technology depends on a modern infrastructure with high quality data and a clearly defined information handling and security model. Without these foundations in place, public sector clients can find it very difficult to realise the benefits promised from Discovery.

For Lead Architect, Neil Sumner, spending time in Discovery to build a realistic understanding of where you are starting from is key: “Understanding your context and landscape are critical. Imagine that you receive a voucher for your birthday for a cookery lesson in a Michelin Starred restaurant. You are taught how to prepare amazing food by an expert, in a kitchen which has been well designed, with all the right utensils and the finest ingredients. You arrive home, keen to recreate your masterpiece but this is where it all falls down. Unless you have invested in the underlying infrastructure, ingredients and a skilled sous-chef it can be very difficult to recreate that meal. Discovery projects often fall into this trap. You may not be able to realise the benefit of a technology demonstration led by an expert when you are trapped by legacy hardware, unstructured, poor quality data and a scarcity of skills.”

Choosing the right delivery approach is also key. Some of the challenges we see with Discovery are due to embracing Agile as a rapid delivery approach without questioning how each increment should fit together, and in what order. In a complex landscape, understanding the landscape and how it is changing is an essential first step to ensure that individual pieces of work do not become disjointed and potentially end up as waste. This planning will require strategic business-focused input from a multi-disciplinary team to understand where value can be derived and to ensure that the strategy aligns with technology and implementation constraints.

An Agile approach can deliver incremental value quickly, but each of the increments need to ‘add up’ to form a coherent big picture. Working at pace, with an arbitrary deadline at the end of March, can often mean this more strategic level of planning can get lost.

Finally, it is important to be realistic about the project’s constraints from the beginning. If funding or resources are limited (as they always are), thought needs to be given to the most effective way of distributing them: is there funding to continue the project beyond Discovery? (If no, what value will be derived from the Discovery alone?). How long can the project run and with a team of what size? Being realistic about how to make best use of resources, and setting expectations from the beginning about the scale of the project’s ambition will pay dividends.

Discovery phases are hugely valuable and often deliver a lot of insight in a short space of time, but without proper planning and a commitment to progress the work there is a very real risk of ‘analysis paralysis’ or the outputs becoming shelfware. The work can become swallowed up by reprioritisation exercises, ultimately meaning that yet more Discovery work is commissioned to address revised priorities - many of which do not result in value being delivered. Setting out the intention to continue the project beyond Discovery means factoring in business design and architecture work from the start to ascertain where it should be positioned within the existing landscape, how it will add value, and to generate a roadmap to provide a clear route out of Discovery into Delivery. For best results, start with the end in the mind.



bottom of page