Not long ago, I was hired by a well-known cable television network to act as tech lead for a major revision to its Web site's content management system.
The network had been using a homegrown interface, and it was our job to replace it. With a $500,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:30 in the morning and rarely logged out until 6:30 each day, 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 spec that defined exactly what kind of system they wanted. That spec 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. 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 9-month-old document turned out to have virtually no relevance to what they actually needed. We hadn't even been able to customize 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. Not when real users are going to have to use it.
Sign up to receive Data Management Resource Alerts
Recommend This
