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?
Ganz einfach: "Projektmanager, Entwickler und Designer" lieben die technische Herausforderung - und die Budgetverantwortlichen haben in der Regel zu wenig Ahnung (i.S.v. stecken zu wenig tief im Thema), um frühzeitig gegenzusteuern.
Meine Erfahrung: Geh mit einer schicken Projektidee los - und als erstes wird über die technische Machbarkeit und die zugrundeliegende Technik diskutiert. Irgendwie auch verständlich, denn damit können sich "Projektmanager, Entwickler und Designer" profilieren.
"Wir haben 100000e Kunden glücklich gemacht" ist einfach nur halb so cool wie "Wir haben ein ...-Projekt auf ...-Basis umgesetzt."
Könnte mir allerdings gut vorstellen, dass dies mit Projektmanagerinnen, Entwicklerinnen und Designerinnen anders aussähe.
> Was hindert Projektmanager, Entwickler und Designer daran, sie einzusetzen?
Der Kunde!
Kunden schaffen systematisch eine Marktsituation, in der tendenziell die schlechteren Anbieter einen Wettbewerbsvorteil haben. Typische Auswahlverfahren bevorzugen z.B. Anbieter, die ihre Fähigkeiten über- und Risiken unterschätzen - also die größeren Projektrisiken mitbringen.
Das bleibt natürlich auf Dauer nicht ohne Wirkung auf die durchschnittlich am Markt angebotene Qualität.
Das wirkliche Problem sind ja auch nicht die wirklich gescheiterten Projekte, sondern die "erfolgreichen", die den Nutzer jedes Jahr mehr kosten als sie einbringen (was der i.d.R. wegen mangelhaftem oder bewusst verschleierndem Accounting gar nicht merkt). Solche Projekte beschädigen selten den Ruf des "minderwertigen" Anbieters - bleiben also ohne Folgen.
Eine analoge Problematik kennt man aus dem Bereich der Managementberatung.
Dort spricht man inzwischen von der Notwendigkeit zur "Klientenprofessionalisierung".
Zwei spontane Beobachtungen hierzu: wenn denn ein Big-5-Dienstleister das Projekt an die Wand fährt, sucht so mancher Kunde die Schuld in der ursprünglichen Aufgabenstellung, die wohl prinzipiell unlösbar sei, wenn selbst so ein renommierter Diensteister Schiffbruch erleide (aka Stockholm-Syndrom).
Und: der seit geraumer Zeit zu beobachtene Trend, den Konzern-Einkauf stärker bei der Auftragsvergabe zu involvieren, fördert zusätzlich die systematische Entfremdung zwischen den Projektverantwortlichen beider Seiten in der Angebotsphase.
Beides führt, ganz richtig, zur Absenkung der durchschittlichen Qualität der am Markt angebotenen Dienstleistung, insbesondere im Bereich Softwareentwicklung. Sinkt aber die Qualität, wird (auch) Softwareentwicklung zur reinen Commodity und die Arbeitsplätze wandern um den Globus.
Auch eine interessante Auslegung des Stockholm Syndroms von Herrn Schrader. Ich finde den Vergleich zwischen einer Geschäftsbeziehung und einer Täter-Opfer Beziehung in einer Geiselnahme nicht gerade vergleichbar.
http://de.wikipedia.org/wiki/Stockholm_Syndrom