The ever-growing capability of AI has sparked some interesting debates in my team at Scott Logic around the shape, size and speed of discovery and alpha phases. Those debates often led back to the same question: what is the core value these phases need to deliver?

On the one hand, there’s the race to an MVP. With the cost of building a proof of concept or a demo shrinking by the day, and mounting pressure to deliver, discovery and alpha can feel like an opportunity for a quick win. But then there’s the goal of reducing uncertainty about the bigger transformation, which is what GDS guidance recommends.

In a discussion at a recent roundtable hosted by the Institute for Government in partnership with Scott Logic, the discussions highlighted the difficulty of achieving this under time pressure, often when a team is still only just forming, and with pressure to find a politically ‘right’ answer. Sometimes this leads people away from “what do we need to learn first” to “what can we ship first?”

In this article, I want to examine how organisations can resist that pressure and get the most out of their discovery and alpha phases.

Starting small is easy. Starting in the right place is hard.

Organisations face almost infinite complexity. The agile methodology tells you to start small and iterate, so teams often constrain scope under pressure. The danger, attendees noted, is that in doing so, teams choose a first iteration that teaches them almost nothing about the wider transformation. In the race to an MVP, teams get trapped inside a single use case while answering none of the questions that actually matter.

One attendee put it plainly: agile is too often interpreted as permission for incomplete thinking, with projects built on broad assumptions rather than investigation.

My colleague Nel recently wrote about how AI can be used to support organisational readiness for change – but if not treated with care, AI can be a double-edged sword. AI makes it far easier for suppliers and internal teams to turn out increasingly convincing demos, which make it feel like a solution is within touching distance; those glitzy demos can feel much easier than doing the hard work of examining how the solution aligns to user needs, and understanding the technical and service design trade-offs sitting underneath.

AI means we can iterate faster than ever. But iterating quickly should never be confused with iterating in the right direction.

Real examples, real costs

I’ve seen the consequences of shallow thinking play out first-hand, and we heard plenty of war stories at the roundtable.

One attendee described a major system upgrade where users actively avoided the new system, or found offline alternatives to it. The issue, it turned out, was that during discovery nobody had asked what parts of the legacy system users actually liked and valued; as a result, the new system was missing many of those parts.

Another spoke of a broad ambition, shared across organisations, to integrate services and data. But the project failed, because it turned out that there were foundational technical and organisational disparities, which were skipped over during discovery and alpha. With those issues unanswered, there was no way to achieve the goal of integration.

A third spoke of a trend towards local optimisation within larger services that felt like wins at first. Ultimately, though, they left service outcomes the same – or worse – than before. Those initial ‘wins’ had simply pushed the pressure points elsewhere in the system, instead of eliminating them.

How to make discovery phases work properly

Fortunately for the public sector, the GDS delivery approach contains guidance to properly focus transformation efforts. Specifically, it states that the alpha phase should test the biggest risks identified in discovery.

Easy to say; harder to do. In my experience, a few things are needed in order to achieve that:

  • Supportive leadership that isn’t driving toward fixed timelines and outcomes. Leadership has to see the value of tackling the riskiest elements first, so that they can protect the team when other parties chafe at what can look like slow progress at the start. Without that advocacy and support, doing things ‘right’ will often be done in spite of the process, not because of it.

  • A realistic amount of time must be dedicated to discovery and Alpha. In order to discover the biggest risks, project teams need enough time to develop an “appropriate” level of understanding of users, policy, realistic delivery options, and the trade-offs a team or its leadership will need to decide on. Then, they need enough time to properly explore and test the biggest risks discovery has found.

  • A genuinely multidisciplinary team with the time and licence to have deep conversations. Discovery is hard. It should involve people with different expertise and experiences. If they end up arguing with each other, that is a sign that progress is about to be made. They need time to understand where the complexity really lies, and to decide what to do about it.

  • An assessment process, where one applies, that judges the quality of thinking and the understanding of risk. Too often assessments are based on performative elements such as the level of documentation produced, while giving no weight to the quality of the thinking in that documentation.

I admit that the word “appropriate” in that second point is doing a lot of work. GDS has guidance on how long discovery and alpha should run, but I’ve worked on discoveries anywhere from six weeks to six months(!).

Six months might sound extreme – and for many projects it would be – but in that instance the leadership of the programme had correctly identified that the risks to a large number of vulnerable citizens, combined with real policy and technical complexity, justified it. They wanted a full understanding of the risks, a deep grasp of a complex user base, and a shared understanding across every party of what they were trying to achieve.

Lengthy discovery phases are not a virtue in themselves. But neither are they always a problem. The question should always be asked: “is this enough time to do things properly?” If the answer is yes, that’s fine – but asking the question forces everyone involved to assess whether they can do the thinking required to make the subsequent project phases a success. If that time is skipped, it’s entirely possible to iterate successfully for years and still end up in the wrong place.

Building on Nel’s previous blog, this is where AI can add value without beguiling people into thinking they have a finished product that’s fit for purpose. Nel gave examples of using AI to rapidly analyse organisational data to identify larger themes and trends that might not be apparent, even to those within the organisation. When used correctly, AI can be a powerful tool for identifying the risks that can be tested in alpha.

Shift the language, shift the focus

It can be helpful to think in terms of ‘activity’ and ‘transformation’. ‘Activity’ refers to things such as features shipped, milestones hit, or budget spent; ‘transformation’ instead refers to things like risks reduced, critical assumptions tested, key constraints removed, or desired outcomes brought closer.

Many projects that race towards MVPs will see lots of activity, but not much transformation. The pattern shows up again and again as local optimisation. A team picks a single use case, makes it demonstrably better, and becomes absorbed in the complexity surrounding it. The use case improves, visibly and genuinely, but the organisation learns nothing about the barriers that will determine whether the wider transformation succeeds, and the pressure just moves somewhere else in the system.

This shift in mindset was also referenced in Suzanne’s blog “rethinking transformation”. Transformations are not projects; a new system is not a transformation. A new system can be a vehicle for transformation, but only if it meaningfully changes a process, or an outcome, or both. Tracking transformation milestones like those I’ve outlined above gives organisations and teams a way of ensuring they don’t fall into what Suzanne called “the programme trap” where they get fixed on a specific outcome that ends up being the wrong one.

Build freedom into the future

The best early delivery decisions I’ve seen increase future freedom rather than optimise a single use case. The strongest architectural choices are the ones that enable a service to adapt as the picture changes to preserve the transformational goal, rather than locking the service into today’s reality.

Transformation at the Bank of England came up repeatedly at the roundtable as an example of this done well – not because its design phase was long, but because real effort went into understanding the challenge properly. Alternative solutions were genuinely explored, leadership accepted accountability for the choices made, and implementation followed directly from that understanding, rather than running in parallel with it.

Working to find the balance

Part of the joy of working joining Scott Logic is that the strength of our relationships with our clients means we are able to be part of complex and challenging conversations with them. As AI changes the patterns and methodologies of delivery around us, we and our clients can discuss: where does AI meaningfully provide efficiency? Do we bank that saving, or does it give us more time to focus on the real value of those early discovery and Alpha phases? Are our clients able to withstand delivery pressure and hold their nerve to spend the time up front, to de-risk delivery?

For us at Scott Logic, the most valuable conversations are rarely about how quickly something can be built, but about what needs to be understood before building begins.