Back in 2011, in the wake of the car crash that was the NHS records system, an interesting thing happened in the UK Government’s IT program.
Shifting from the “bigger is better” mantra that we still too often see desired from public and private sector IT projects, the rollout of the new gov.uk portal (the website that rolls up government functions from benefits to passport eligibility) adopted an approach that was previously the reserve of Silicon Valley startups, and often smaller, faster-moving technology companies.
The project gathered a team of about 100 people together in a single Central London location and adopted delivery methods that focus on getting a minimal version of the product in to the hands of real customers as quickly as possible. The first release of gov.uk, realised 12 weeks after the team first assembled, and one day late, contained only a small subset of the desired features: but did provide a number of complete features that customers may have found useful. Since the first public launch, there have been hundreds of updates released to the site that have added new features and changed existing ones.
In doing these fundamentally simple things, UK Government leapfrogged the vast majority of UK industry, most of whom are still delivering big, complex projects to timescales that should have long been deemed unacceptable for any modern organisation.
IT projects, and particularly large-scale IT projects have significant complexity. They’re also being delivered in to increasingly complex and competitive environments, where the need to demonstrate business agility and move quickly often delivers a significant commercial advantage. Until it’s in the hands of customers, a product delivers no value. The number one focus of almost every project needs to be to get a minimum version of the product used by customers as quickly as possible. In the Lean Startup world, this is usually referred to as the Minimum Viable Product.
There are two particularly powerful advantages that are realised from delivering early:
Until you’ve got your product in to the hands of your customers, you’re guessing about the features they want from it and you’re guessing at how they will use it. The sooner you can get feedback from real customers the better. This feedback can prove (and indeed disprove) assumptions you’ve made and because you’ve got it early enough, you’ve not wasted too much time heading in the wrong direction.
Always release ready
In more traditional projects, you’ll often see long running “testing” phases bolted on to the end of the project. If the product is being released often, testing needs to happen often. This gives much greater transparency as to the true state of the product – by keeping it in a release-ready state, when a feature is marked as done: it’s done.
For too long big IT projects have been approached in much the same way as bridge building and other civil engineering undertakings. Organisations around the globe bear the scars of SAP and CRM rollouts that have taken years to complete and have never delivered their promised value. Too often IT and its friend complexity are the barrier to businesses behaving with agility, to seizing commercial opportunities in acceptable timeframes, and to delivering truly outstanding customer experiences.
The UK Government has demonstrated that things don’t need to be this way. In the digital age big projects don’t need to be delivered slowly. If your organisation isn’t able to keep pace with government, your shareholders should be in revolt.