The first challenge for a new digital team is to prove to those watching that it can deliver something that works on the web quicker than the organisation has ever been able to manage before. This can be a relatively low bar, so your true ambition should be to produce something that is not just a little more timely and attractive, but a whole order of magnitude faster, more beautiful and of genuine value to users. The strategy for your first project, like all that follow, should be delivery. Producing working code must be a far higher priority than writing elegant strategy papers that explain what you’re up to, defining your organisational structure or getting your office space right. All these things are important, but secondary to demonstrating things of value to real people outside your organisation. Many other teams in your organisation, be that business or government, will have proved themselves perfectly capable of writing good papers and having exciting ideas. What they haven’t done is put working prototype digital services in front of users in a few weeks, tested them, and made them better based on their feedback and other data. If you haven’t either, there’s not much point in you being there. When we say quick, we mean quick. Quick in some organisations is a year, say, or 18 months at the outside. A working alpha version of GOV.UK was built in 13 weeks. The UK’s e-petitions service went live having been delivered from scratch in 11 weeks to a hard deadline set by parliament. These are government projects, remember. That didn’t mean those services were completely finished; all are still being iteratively improved today. All began small, simple, clearly designed and user tested. They started as good enough, rather than perfect, and got better.615 ↱
Digital Transformation at Scale
Why the Strategy Is Delivery: Why the Strategy Is Delivery
Andrew Greenway, Ben Terrett, Mike Bracken, Tom Loosemore