Das ist doch mal ein anständiges Projektvolumen: Für 500.000 Dollar wollte ein TV-Sender in den USA sein selbstgebasteltes Content Management System durch eine Lösung auf Basis von Standardsoftware ersetzen. Doch das Projekt endete, so berichtet ein anonymer Projektmanager bei Infoworld, im Desaster:
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.
Wolfgang Sommergut, der dieses Beispiel ausgegraben hat, meint dazu:
Solches Projekt-Management ist nach dem, was ich so sehe und höre,
keine Ausnahme. Vermutlich hat fast jeder in seiner Firma schon so
etwas erlebt.
Die eine oder andere derartige Katastrophe ließ sich ja noch der relativen Unerfahrenheit einer jungen Branche zuschreiben. Doch diese Ausrede zieht nach zehn Jahren Web nicht mehr so richtig. Da ist es nur ein schwacher Trost, dass richtig große, klassische IT-Projekte noch sehr viel dramatischer scheitern.
Die richtigen Ansätze sind seit langem bekannt und keine Raketenphysik. Was hindert Projektmanager, Entwickler und Designer daran, sie einzusetzen?