Experimenting with Fixed Time and Variable Scope
Last time, I wrote about the new 11 week “mission” structure for all work on GOV.UK. This was a completely new way of working both for me and for many others on teams across the organisation. So how did it go after 11 weeks improving user journeys for worldwide content?
Firstly, this way of working is very different from anything I’ve done before, including at GDS before. I am used to working in projects with no set end date and relatively large (and inevitably, growing) scopes. So to move to a project that had only 11 weeks to deliver something user-facing and substantial was no small feat.
Secondly, this was my first project as a technical lead. The role of technical lead is one that is taken on alongside your usual role, and it exists mainly to provide technical input to the delivery manager and product manager during planning sessions as well as to set technical standards within the team and make higher-level technical decisions, potentially involving other teams. In effect, I was learning leadership on-the-job, in a time-bound project being run in a new way by a team I’d never worked with before.
Bearing in mind these two things, the first mission completed successfully. In the 11 weeks, we defined the work we were going do, drawing on the international discovery work that had been done in 2016. We then engaged the FCO and worked with them to define the changes we wanted to make and how to validate them. Finally, we did the research, content and development work to implement the agreed solution.
Now, that makes it sound like everything went smoothly. For the most part, things worked and happened in the right order, but I would be lying if I said there weren’t bumps along the way. We decided a few weeks into the mission that we needed to be more ambitious in order to deliver something of value to users at the end. This meant some re-planning and a lot more development work.
We decided to go with a taxonomy approach, where individual country pages on GOV.UK would become text-based landing pages with links to commonly-used services such as passport renewals, visa applications and embassy contact details. This meant, however, that we needed to work more closely with the Taxonomy team as well as create some new tooling to support our use of the taxonomy, which wasn’t planned for when it was first created.
Part of our plan of action involved changing a lot of content across all embassy pages, of which there are hundreds. This meant creating template content, customising it where required, and then editing each page individually in the publishing application. All content also needed to be double-checked, so we decided to speed-up the process by sending three content designers to co-locate with their colleagues from the FCO for a few days. This worked really well and meant we could get things done more quickly.
From a development point-of-view, we put some work into automating as many of the content tasks as possible (such as creating all the individual country pages and categories underneath them) to free up time. We then put together a deployment plan for our code. Due to the complicated nature of the applications we were working with the the need to not have any downtime during the switch from the old to the new pages, we had to follow a very specific set of steps in the correct order. This plan worked a treat during the two days when we were deploying all the various applications and making the content changes.
Due to the various complications and the scope of work, we actually only managed to have everything deployed one day before the end of the 11-week period. We spent the Friday fixing a number of small issues that had been flagged up - an inevitable side-effect of a fast-paced, large-scope, time-limited project. Some people (including me) worked a few long days to get everything over the line, and we also had great support from the other teams across GOV.UK that our work touched - in fact, we managed to borrow an extra developer from another team for a few weeks, without whom we wouldn’t have been able to complete everything on time.
So, what lessons come out of this experience?
Firstly, ruthlessly limit scope. This time around, we know we have 11 weeks and we know roughly how much work can be done in that time. Therefore, we are able to more accurately estimate work and cut out any extras that would make our goals unachievable. Last time, we didn’t have any baseline to estimate against.
Secondly, be ambitious from the start. If you start off with an unambitious scope, then inevitably at some point people will start asking questions and pushing you to do more, by which time it requires more work to change direction.
Finally, be aware that you’ll always be thinking about what you could do better/extra/differently. This is natural. As long as you have a solid team around you who give you good feedback, and great team managers who give you air cover, then you’ll succeed. Take what you learn and apply it to your next project, and you won’t look back. This is what I did and it’s a lot easier the second time around!
If this sounds like a good place to work, take a look at Working for GDS - we’re usually in search of talented people to come and join the team.