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
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.
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.
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
7 comments
Comment by Mike Laurie (@mikelaurie) posted on
Love it. I particularly like the single question that qualifies the project to progress; it's basically a pull process, as opposed to push, which is massively more efficient. Brilliant.
Comment by Ian Marshall posted on
I see your "fit with goals / timeliness" grid. Covey's task management principles might have you swapping "Do next" and "Do soon" around. He might say that it is better to do important, non-urgent stuff before urgent but (relatively) unimportant stuff, in order to improve the alignment of tasks and goals.
What do you think?
Comment by Emily Webber posted on
Hi Ian,
Projects in the "Do next" and "Do soon" (as labeled here) quadrants could be weighted fairly similarly, depending on where exactly on the grid the project falls.
Something with a high urgency for us can be due to an external factor, a public commitment made or a project that has a policy element, which is why we class it as "Do next". Anything in the 'Do soon' quadrant has the potential to move over to "Do first" in which case it would supersede anything in "Do next".
This way is working for us right now, but each organisation will have their own ways of working and may change for us in the future.
Comment by alexstobart (@alexstobart) posted on
Emma
You say in the article
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.
Have you had any experience where you took a project through the Approvals Board, and then it turned out to be the wrong decision ?
Also, who are your users ? Are they mainly other Government Departments ? Are you finding that your users contribute and inform your processes as a Community in their own right now, or is it too soon ?
Thanks
Comment by Emily Webber posted on
Hi Alex,
We haven’t had anything that has come through that has shown to be the wrong decision. As mentioned in my response above, we have a number of points where a project may be stopped before getting to the delivery stage if not suitable for example; at post assessment, post discovery or through prioritisation.
Our users are internal to GDS, these are the people that form the approvals board, those that present new work and the rest of GDS who can attend or see the outcomes of the meeting. Gathering feedback on the process is done with these stakeholders and has already caused a number of iterations of the wall as well as changes to the approvals board format.
Comment by Matthew T posted on
How do you approach limiting work in progress? If a project is neither urgent or well aligned rather than 'do sometime' why not put it in the trash?
Comment by Emily Webber posted on
Hi Matthew,
thanks for your comment.
Limiting work in progress is an important aspect of agile delivery. Most of the projects that come through are initiated by members of GDS, so we don’t tend to have anything coming through that is completely misaligned. When a project is “Do Sometime” i.e. less of a good fit and not urgent, we review it to check it has the correct prioritisation and if it does, either make the call to not do it, or find an alternative to the GDS doing it.