Analysis complete, stakeholders bought in and design signed off.
It was time to deliver and it was going surprisingly well.
The self-confessed, "artistically challenged" dev team needed a 60 page style guide but that was nothing some strong coffee and late nights couldn't fix.
I was nearly finished with it when the Communications Director stomped into the office with damp feet.
"The sodding water main has burst on Victoria Street", she shouted
at no one in particular, "Someone needs to get a release up on the website."
Our team exchanged nervous glances. We'd consulted dozens of people over several months to ask for every possible use case for
the site and no one had mentioned that once in a while they had to publish new content like right now.
We weren't live yet. That day it wasn't our problem but it would be in four weeks time.
The advantage of being agile
Discovering new requirements with four weeks to go sucks but it sucks a lot more when you can't do anything about them.
Fortunately our team was more than qualified to address the problem.
I waited for the Communications Director to dry out and sat down with her to discuss what this kind of emergency update needs to look like. When there's no official request. No content editor to write it. No final approval for it to go live. Just a load of water flooding the street and people who need to know about it.
The problem breaks down into two parts.
1. Finding out something has happened. Its rare that the communications director quite literally steps in the problem.
2. Letting people know what's going on.
I solved the first problem by making site search data more easily available to the communications team. If lots of people start typing, "Flood on Victoria Street" into the search box, they know about it.
And solved the second by making the Big Six configurable so they could make their public statement as visible as possible as quickly as possible.
It was all ready by launch and the council have reported that its one of the best parts about the new system.