Ö÷²¥´óÐã

Hi I’m the project manager on the . You can find out more about the product in my colleague .

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 .

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 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.

Sounds like 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 , 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.

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.

is the project manager on the Vote 2013 election product.