It’s time to phase out – a rethink of the traditional service standard phases
These phases served their purpose in the past, but there’s a risk that they’ve turned into the bottlenecks they were designed to eliminate
It’s been a while since I last undertook the GDS Discovery and Alpha phases but, for the last few months, that’s exactly what I’ve been doing. Whilst passing through these time-boxed phases it’s made me question whether, in a more digitally mature government space, the way we use them are still fit for purpose. In this post, I’ll explore why we should think about breaking free from the rigid structure of traditional service standard phases into a more agile, value-focussed future.
Before I delve into this topic, I want to make a critical distinction between the 14 service standard points, and the phases commonly known as Discovery, Alpha, Beta, and Live. I’m a steadfast advocate of the 14 points, yet deep within point 7. use agile ways of working, lie the phases of an agile project, and I believe that they are what’s currently stifling our ability to be agile.
I want to add that I’m not here to completely write off the value of the phases. They were pivotal during the early era of agile digital delivery in the government sector. They put a stop to the detrimental, bloated, up-front requirement gathering and waterfall methodology that was prevalent at the time. Instead, they compelled teams to thoroughly understand the problem at hand and to experiment with potential solutions.
I also do not want to say goodbye to the activities that sit within the phases. We must not throw them out with the bath water. They are still valid in ensuring that when we build new products we can realise their maximum value.
But our digital landscape has significantly evolved since the phases were introduced, and this evolution necessitates the reassessment of tools and methodologies we once found indispensable. While these phases served their purpose brilliantly in the past, there’s now a risk that they’ve turned into the very bottlenecks they were designed to eliminate.
Holding back realising value
My reservations about these phases began to take shape when I transitioned from project to product management a few years ago. Even though these phases seem to follow a logical order, I started to learn that sticking to them too rigidly stopped the team I was working in from continually evolving and realising value. And that’s where the problem lies.
As a Product Manager, some of my prime responsibilities are to ensure that we’re maximising value and achieving the right outcomes.The age-old phased approach though complicates this task, which brings me to my first bone of contention.
Consider product development as a betting game. You decide where to place your bets based on the potential return. If we map this to the phases, Discovery and Alpha are choosing and validating your bet, Beta is placing small bets to test the waters, and Live is going all in. So when asked who to put our money on in the weekend Premier League fixtures, why would we spend an inordinate amount of time in Discovery and Alpha studying the form guides when we, sadly, already know that all the recent known evidence points to the fact that we’re going to back Man City? Why not speed up the process, place the bet, and start reaping the potential benefits as soon as possible?
Sadly, the traditional phased approach does not allow this. Even for small, low-risk bets, we’re wrung through a time-boxed 10 to 16-week Discovery and Alpha period until we’re allowed to put our chips on the table.
The cost of delay
The second issue at hand is the inherent complexity of the products and services we develop. A phased approach can inadvertently make the building process more costly, and delay the delivery of value to our end users.
Imagine gearing up for winter – you’ve ordered a hat, scarf, and gloves set from your favourite online store. Unfortunately, when you receive your parcel, the hat is missing and the gloves are the wrong size. It’s started to snow and you need to pop down to the shops to pick up the Yorkshire Post. When you venture outside do you shiver in the cold whilst you wait for the complete set, or do you put on the scarf to get some immediate warmth?
By sticking strictly to phases, we risk missing out on the immediate benefits we could be reaping. We’re made to wait to put the scarf on, and in product development we call this missed immediate value realisation the cost of delay.
Time to phase out?
So, is it time that we reassessed the phased approach? Is clinging to these phases stopping your project from realising value sooner? Could we all do with being a bit more agile?
I’d be interested to hear your thoughts.