Hi I’m the project manager on the Vote 2013 election product. You can find out more about the product in my colleague Jonathan’s blog post.

Here I am going to tell you about the way I managed this project which utilised a number of new technologies and tools to put in place a solid foundation for the next three years of election coverage on News Online.

News coverage of the elections on Vote 2013

As the project manager I was responsible for leading the software development teams and delivering functionality in line with the product priorities.

I was also responsible for actively managing Risks and Issues, reporting progress and project status, planning the delivery and support for election night and being the primary point of contact for all of the other teams we worked with throughout the project.

At the start of the planning phase we looked at the needs specific to the election project and of our major stakeholders. We took the structure and governance of traditional project management and at the same time applied agile development practices to build the software.

This combination was an approach which met the needs of our stakeholders and enabled us to deliver a highly complex system on time.

Why did we need to do this?

Firstly, we were working to a fixed deadline of Election Day: 2 May 2013, a fixed minimum scope (the requirement to provide up to date and accurate information to audiences) and a fixed budget.

Secondly, there were a number of other departments we depended on or were dependent on us: our editorial team, the Red Button team, the data provider and our colleagues over in Core Engineering who provided the platform tools that enabled us to make full use of the cloud.

Thirdly, we weren't just building an application to run the UK 2013 local elections, we were putting in place a strategic platform for the elections coming up over the next few years. We were also building it responsively for mobiles and tablets, for our desktop users and our Red Button service.

And finally, we had to deliver it which means monitoring it, briefing our Operation Support teams on the system and the elections themselves and carrying out end to end data rehearsals alongside our colleagues in TV.

This necessitated having a really tight and aggressive timeline, defining key milestones, actively managing a comprehensive Risk log, implementing a solid communications plan and having appropriate governance in place such as Steering Groups and weekly reports.

Sprint board

Sounds like waterfall right?

We also needed the flexibility to define and refine requirements, to review and revise scope based on the emerging software, to prioritise based on a backlog, to develop iteratively, to measure velocity and provide regular demos to Jonathan Austin, our product manager, and other key stakeholders.

In other words all of the key aspects of an agile delivery approach.

Many of my fellow professionals take an either/or approach to agile vs. waterfall: that they are mutually exclusive or that only agile is appropriate for software development projects.

My view is why throw the baby out with the bath water? Indeed it completely fails to acknowledge that agile is not a ‘process’, it is a mind-set and a cluster of core principles and development techniques.

Likewise you can use ‘traditional project management’ techniques without necessarily utilising a waterfall delivery approach. I say take the best of each, based on the specific needs of your project and layer them on top of each other.


Here's how we did it

We started off with a high level timeline, marked out our delivery date and worked backwards to define milestones and development time. At the same time our product manager was busy putting together the vision, the high level requirements and defining the Minimum Viable Product (MVP).

The milestones we put in were vague enough to enable us to use an agile delivery approach whilst at the same time putting in place useful checkpoints at key dates along the delivery timeline. For example: Results Data Schema delivered, or Product Proposition Checkpoint.

We didn't lock down requirements: we started with a product brief and detailed analysis of the highest priority deliverables whilst iteratively defining the rest ‘just in time’.

UX worked iteratively with the business analyst and product manager and sat with our front end developers to tweak and refine in a real environment.

We used the Steering Group to communicate and demonstrate the emerging product that was built so far. Significant blockers or potential blockers within the development teams were added to the Risks, Issues, Assumptions and Dependency (RAID) log for communication and to aid any escalation activities required. This RAID log was also used as a basis for defining the project's RAG (Red, Amber, Green) status in a meaningful and less subjective (or ‘gut feel’) way.

Issue Status each month

Within the development team we also had some challenges to overcome. There were two distinct skillsets working on two separate bits of the system and interacting purely on a shared API.

It's best practice to carry out planning sessions with the whole team, however the clear split between development meant that this wasn't really practical. So we divided the team into a backend (Java) team and a front end (PHP) team both working in two week sprints on an alternating basis.

The presence of the product manager and the business analyst in both teams ensured consistency and the collaboration between our developer in test and our front end tester ensured the system met the requirements for all scenarios.

As a result of taking this approach we were able to meet the challenge of implementing the first step in the evolution of the election system. The event itself ran like clockwork and due to the careful planning and smooth delivery of the technology neither the project team nor our stakeholders had any surprises or last minute technical issues to overcome.

As a project manager there is nothing more rewarding than working on a project where everything goes to plan.

If you would like to comment on why a hybrid approach got my vote, please leave a comment below.

Hannah Mitchell is the project manager on the Vote 2013 election product.

Tagged with:


This entry is now closed for comments.

  • Comment number 4. Posted by Hannah Mitchell

    on 28 Jun 2013 10:00

    Hi - thanks for your comments, answers below:

    We didn't apply Prince 2 specifically, as we approached things less formally than that. The key was that myself, and our Delivery Manager, Matt Shearer, picked out the elements that we deemed most appropriate to the project. The signoff was owned by our Product Manager, who was actively involved in defining the detailed requirements so we didn't have any issues with that.

    We used a "just enough" approach to documentation. Our UX produced wireframes and then fleshed out designs, our analyst defined acceptance criteria in consultation with our lead developer and our on a feature by feature basis and both were reviewed and tweaked by the Product Manager and the lead developer. Our lead UX then collaborated with our lead developer and made adjustments and tweaks directly on the code base rather than constantly updating the initial designs. All of this was done during each iteration, applying Just In Time planning for the features we were developing. The acceptance criteria were implemented as cucumber tests rather than constantly updating a separate set of documentation,

    As the development side of the project was run in an Agile way, the leadership element of the development process was an overseeing/faciliation role: ensuring preparation activities for each sprint were on track to be completed prior to a planning session; reviewing against the overall project activities and facilitating the removal of impediments. During each sprint the team essentially ran themselves, with the leadership of the lead developer (front end) and the technical architect (backend) based on the output of planning sessions. My role during each sprint was to remove impediments and to be an escalation point. My role between sprints was ensure that the activities required to prepare for the next.

    To put it in the wider context, the amount of time I spent managing, reviewing, or prioritising the development work took around 20% of my time. The majority of Project Management activities were focused on alignment with third party teams, risk management, planning for the election night, and working with the OTG teams to push us through the platform approval process.

    It does indeed! I'm curious as to what extent you have changed your mind.

  • Comment number 3. Posted by stuarta

    on 27 Jun 2013 16:33

    Although my thinking has now changed a great deal since this blog post was published http://www.boxuk.com/blog/the-challenges-of-project-management/ it sounds very similar.

    • This entry is now closed for comments. Number of positive ratings for comment 3: 0
    • This entry is now closed for comments. Number of negative ratings for comment 3: 0
  • Comment number 2. Posted by Aidy Lewis

    on 26 Jun 2013 13:40

    Could you go into a little more detail of how you lead the software development team please?

    • This entry is now closed for comments. Number of positive ratings for comment 2: 0
    • This entry is now closed for comments. Number of negative ratings for comment 2: 0
  • Comment number 1. Posted by Tim Clarke

    on 26 Jun 2013 06:35

    Interesting to read this Hannah. I'm always having to justify that Prince 2 methodology can and probably should work with Agile, as they're perceived as competing approaches.

    I'm keen to know what the UX and Analysts created and how they interacted with the technical development sprints. Was the Agile approach of minimal documentation compatible with sign off from stakeholders and clarity for the technical teams?

    • This entry is now closed for comments. Number of positive ratings for comment 1: 0
    • This entry is now closed for comments. Number of negative ratings for comment 1: 0

More Posts