Recipe for a development disaster
- 02 October, 2005 21:00
The Television Station had been using a home-grown interface, and it was our job to replace it. With a US$500,000 (NZ$713,000) budget to work with, I thought we had a good chance of doing it right — and I looked forward to a challenging project. Little did I know!
The 20 overworked editors, producers and designers who used the current interface practically lived inside the software. They logged on at 9:30am and rarely logged out until 6:30pm, juggling promos, entering episode blurbs, uploading photos and managing polls and sweepstakes. Many of them had developed complex routines, tricks and shortcuts that helped get their work done.
The new system I was developing would be an improvement but I knew it would take time for our users to become productive in the new environment — and they were not known for their patience. I was particularly worried because our project plan didn’t include any opportunity for interaction with the users.
In the early design stage they had been invited to create a detailed specification that defined exactly what kind of system they wanted. That specification was eventually turned over to us but by then the requirements were locked down. The schedule allowed exactly one week for the users to try out the new software and report bugs and for us to fix any problems before launch.I told my boss, the director of interactive technologies, that we needed to bring the producers, editors and designers back into the design process. I said that at the very least we ought to sit and watch them work with the new screens, solicit their feedback and ideas and plan for at least one revision phase before final user testing and acceptance. I think they call this “iterative development” in Project Management 101.
My old-school boss had never heard of this approach. He insisted that we stick to Plan A: we code, we test, we launch. Extreme programming? What the heck is that?
When the users got their first look at the interface, they hated it.
The abstract requirements they’d written down in that nine-month-old document turned out to have virtually no relevance to what they actually needed. We hadn’t even been able to customise the out-of-the-box interface for them because they had never asked us to do so in their specification. As I sat with a miserable assistant producer, showing her the screens I felt like I was handing a starving person a rubber chicken.
Needless to say, the project immediately devolved into a desperate and unplanned round of last-minute revisions, accompanied by lots of yelling and finger-pointing.
In real life, although a functional requirements specification is a good first step in preparing for a project anyone who thinks that such a document, in and of itself, is sufficient to guarantee a project’s success is crazy. When real users are going to be involved it’s never going to be enough on its own.