Here at GDS, agile thinking and techniques inform how we do what we do, this extends from delivering projects, programmes and the GDS portfolio of work. I’ve been working with a team of people to implement and run an agile portfolio management function at GDS and this is an overview of how and why we did it.
A growing organisation
In October 2012 we launched GOV.UK. This was a big milestone for GDS, and prior to its launch it was a large focus of our organisational efforts.
Although GOV.UK was a large part of the work we were doing, the organisation was also growing in other areas. We had gone from 12 people working on Alpha GOV to over 300 people working on a number of programmes of work in just over 1.5 years.
Rapid growth is a challenge a small group of people have the ability to act more like a startup, but as an organisation gets bigger how do you make sure you can retain the same transparency and collective decision making?
After the GOV.UK launch, it was a natural time to take a moment to reflect on the organisation and re-consider our processes. This is where the GDS approach to an agile portfolio framework was born.
The implementation of a portfolio framework
We addressed the portfolio implementation project, much like we would any project at GDS, in an agile way: We spent time with the users and stakeholders to understand what their needs were; we spent time workshopping to understand drivers, what success looked like, what we hoped the project would do, and what our fears were – as well as opportunities that could arise from the project.
From this process we defined the project goals as:
- create a portfolio management function at GDS that compliments the existing agile project management methods
- create a cross GDS view of priority
- implement clear and understandable workflows
- produce clear, actionable management information
We also took time to map out the what the current situation was. How did a project or piece of work become part of someone’s backlog? What were the routes for work coming into GDS and who was making those decisions? This allowed us to pragmatically look at what was happening and how we could improve it.
The portfolio wall
The GDS Portfolio wall
At GDS we use walls to focus teams and show others what we are working on. Once we had tested some ideas for a new workflow with our users, it seemed natural for us to reflect it on a wallspace in the office.
(When we have visitors, it’s often the place that causes them to stop and appreciate the sheer number of things the team here are working on.)
The wall has been iterated on a few times since it’s initial incarnation, but the columns are currently:
Projects flow from an initial idea, through a short assessment, into a longer discovery, through delivery to operational or done. Each decision point allows for sharing information and the opportunity to stop something if need be.
The information on the portfolio wall is the most up to date project information and allows everyone in the GDS offices to easily see what we are currently working on. We then back up data from the wall into Google Docs that we can manipulate to provide insightful and actionable management information.
After the wall first went live, we spent some time with product owners getting each project into the relevant columns. We then mapped each of those projects to the GDS goals. Using this information along with any deadlines gave us a list of all projects in priority order, priority is then considered on each project at each stage to give a continuous view across GDS as to what we should be doing.
Forums and decision making
One important item that came out of the discovery is that we needed some clear decision gateways. This also helps gather useful data about projects, which in turn helps us make decisions about what we are doing as an organisation.
Asking for information of busy people isn’t enough. Getting the right regular forums in place to gather data for clear purpose has better success.
We added a weekly meeting (called the GDS Approvals Board) where we ask one simple question of the senior management team: Based on the information we have, should this project move into the next stage? This meeting takes no more than an hour a week and over the past few months we have managed to make it shorter.
The amount of information gathered prior to this meeting is dependant on what stage the project is in; e.g. if it’s to understand if we should move from assessment to discovery (work out what the project would deliver and what effort would it take to deliver it) than we ask just five questions around the need for the project, fit with goals and how long discovery will take. If it’s to understand if we should move a project from discovery to delivery (actually doing the project), the questions will be more detailed, e.g. what is the user need, what are the success measures, what are the technical considerations.
Project Card
We also have a weekly stand-up with representatives from each of the functional areas across GDS, where we walk the wall, move project cards and highlight project blockers, all of which is feeds into management information.
Where we are now
The portfolio management framework at GDS has created a single place to see what is happening across the organisation and a framework to manage that within. It has created increased transparency to allow all of GDS to see what we are working on, what’s coming up and provides management information so that we can make decisions as an organisation.
Projects by stage
Of course, we are continuing to improve it; the next iteration will include further joining up the people side of projects and how we ensure that it links in with the portfolio framework.
If you’ve got any questions, leave a comment or send me a tweet @ewebber
Filed under: GDS
