Das kommt darauf an. Das kann man manchmal erst nach Jahren sagen. Das hängt von der Zufriedenheit der Stakeholder ab. Zeit und Budget sind nicht alles schließlich ändern sich die Anforderungen laufend. Es gibt unzählige Argumente um den Projekterfolg zu beschwören. Wenn wir von Verantwortung reden hilft es aber nicht um den heißen Brei herum zu reden. Vorhaben, deren Ziele so unpräzise definiert sind, dass man erst nach Jahren etwas über den Erfolg sagen kann, sollte man nicht Projekte nennen. Der Aufbau eines neuen Geschäftsfeldes ist kein Projekt sondern ein strategisches Vorhaben, in das mehrere Projekte eingebettet sein können. So lässt sich der Erfolg eines Produkt-Entwicklungsprojektes sehr wohl feststellen. Ob die Verkaufszahlen Jahre später so sind wie man es sich gewünscht hat ist nicht mehr Sache des Projektes. Das gute Ergebnis des Projektes kann ggf. nicht verwertet werden, weil sich der Markt grundlegend ändert. Auch die andere Variante ist zu betrachten. Nur weil ein schlechtes Produkt – aus welchen Gründen auch immer – gut verkauft wird heißt das nicht, dass das vorgelagerte Entwicklungsprojekt nicht schlecht gewesen sein kann.
Es gilt für die Projektleitung für das konkrete, abgrenzbare Projekt den Erfolg zu definieren und zu verantworten. Ausgehend von der Definition eines Projektes sind die drei Parameter Anforderungen, Zeit und Budget nach wie vor wichtige Größen. Die Anforderungen sind dabei jene, die im Laufe des Projektes erhoben oder präzisiert wurden – diese können ggf. erheblich vom ursprünglichen Plan abweichen. Egal welche Methodik im Projekt eingesetzt wird, die Anforderungen müssen dokumentiert werden, nur gegenüber den dokumentierten Veränderungen der Anforderungen lässt sich ein Projekterfolg messen und nachweisen. Für den Fall, dass sich die Veränderung als signifikante Vermehrung erweist ist die Dokumentation zwingende Voraussetzung für das Durchsetzen einer Budget- und / oder Zeitrahmenänderung. Damit muss sich jede Projektleitung nach wie vor an diesen drei Punkten messen lassen. Die spannende Frage ist dann eher wie weit die ursprünglichen Anforderungen von den tatsächlich realisierten abweichen.
Für einen überzeugenden Projekterfolg reicht das aber noch nicht. Die Kundenzufriedenheit muss separat betrachtet werden. Wenn die erhobenen Anforderungen wirklich die Bedürfnisse des Kunden widerspiegeln ist das erst die Hälfte der Miete. Hierzu eine kleine Anekdote aus meinem Erfahrungsschatz. Für zwei mittlere Firmen mit absolut identischem Geschäftsmodell und Prozessen wurde ein neues Auftragsmanagementsystem entwickelt. Das System wurde eingeführt, in Firma A wurde es als Erfolg gefeiert, in Firma B mit Skepsis betrachtet. Wenige Zeit später wurden Firma A und B unter dem Dach der Firma C zwangsfusioniert. Aufgrund der gesetzlichen Regelungen und Vorgaben war auch das Geschäft der Firma C mit dem von A und B identisch. Im Rahmen der Ãœberlegungen zur Ablösung des C-Alt-Auftragsmanagementsystems wurden Meinungen aus den Firmen A und B eingeholt. Ich wurde vom zuständigen Entscheidungsträger befragt ob ich die Entscheidung das System A zu verwenden aus technologischer Sicht mittragen könne, dieses System wäre funktional dem System B weit überlegen. Die Ãœberraschung war groß als ich mitteilte, dass System A und B identisch seien. Ein Projekt, ein Ergebnis und doch völlig unterschiedliche Wahrnehmungen. Merke:
Die positive Wahrnehmung des Projektergebnisses ist wichtig für die Einschätzung als Erfolg.
Zu guter Letzt ist auch die persönliche Einschätzung nicht zu vernachlässigen. Auch wenn es in der Außenwirkung und in den Projekten nicht erscheinen mag ist ein auf Kosten des Projektes ausgebranntes Team sicher kein Grund den Erfolg allzu laut zu feiern.
Die im Text gezeigten Ausschnitte aus Fragebögen sind Teile der zur Zeit laufenden Untersuchung zu Erfolgsfaktoren in Projekten. Wer 10 min Zeit übrig hat und im letzten Jahr in einem Projekt mit gearbeitet hat darf gerne mitmachen – es gibt auch was zu gewinnen 😉
Ich kann mich den Kommentaren nur anschließen. Das A&O sind aus meiner Sicht die Anforderungen und die Definition zum Start. Dort werden die meisten Fehler gemacht, die am Ende oft nicht mehr ausgebügelt werden können.
Hallo Thomas, sorry für meine verspätete Antwort, es gab viel zu tun.
In Einzelfällen habe ich das „nicht festlegen wollen“ auch schon erlebt, dass das mit einer Angst „sich festnageln zu lassen“ zusammenhängt kann ich mir gut vorstellen, wie häufig der Effekt ist kann ich aber nicht einschätzen.
Das mit der präzisen Formulierung haben nicht nur Ingenieure nicht gelernt, das ist vielleicht ein Phänomen der Generation „Powerpoint Deutsch“. Ich habe schon Anforderungsdokumente in den Fingern gehabt, die vollständig aus Spiegelstrichaufzählungen bestanden.
Die Bereitschaft zur gelungenen Kommunikation – nichts anderes ist Anforderungsdefinition – ist leider nicht sehr verbreitet. Damit wird auch plausibel, warum manche agile Ansätze so gut funktionieren, hier wird die „Anforderungskommunikation“ (z.B. durch user stories) sehr viel intensiver geführt.
hm… spannender Beitrag, dem ich auch grundsätzlich zustimme. Nur warum erlebe ich dann so häufig, dass Anforderungen nicht klar aufgeschrieben werden? Liegt es vielleicht daran, dass sich die Stakeholder des Projekts nicht festlegen wollen, weil sie Angst haben, dass das Geschriebene in Zukunft auch gegen sie verwendet werden kann?
Ich bin der Meinung, dass dies eines der Probleme ist. Daher sage ich meinen Kunden immer, dass Anforderungen, die wir aufschreiben, jederzeit geändert werden können und nicht dazu dienen, Schuldige nach dem Motto „aber am 25.3. haben Sie gesagt…“ zu finden. Wenn nun dieses Verhalten auch durch Tatsachen bestätigt wird, so baut sich ein Vertrauensverhältnis auf allen Seiten auf, das am Ende zu klaren aber veränderlichen Anforderungen führt.
Ein zweiter Aspekt des Unwillens, Anforderungen zu formulieren, ist dazu noch in der Sprachfertigkeit von Menschen zu sehen. Ich arbeite in einem ingenieurwissenschaftlichen Umfeld und stelle immer wieder fest, dass die präzise, schriftliche Formulierung von Anforderungen eine Aufgabe ist, die von vielen Ingenieuren nicht geleistet wird. Ich glaube, dass dies daran liegt, dass Ingenieure nicht gelernt haben, präzise Anforderungen zu formulieren und plädiere deswegen für eine stärkere Betrachtung von „requirements engineering“ in den ingenieurwissenschaftlichen Studiengängen.
Meine Eltern schmunzeln immer, wenn ich heute – mit vielen Jahren Abstand zur eigenen Schulzeit – konstatiere, dass ich meine damalige Haltung (als ingenieur muss ich nicht gut schreiben können) redigiert habe.
Insofern behaupte ich heute, dass Vertrauen und die Fähigkeit, Anforderunge präzise zu formulieren, fundamentale Elemente für einen Projekterfolg sind.
Zuerst mal Hallo und danke für den Kommentar.
Wenn die Anforderungen nicht umgesetzt sind, kann meiner Meinung nach ein Projekt nie ein Erfolg sein.
Genau!
Hallo,
da wird mir regelrecht aus der Seele gesprochen. Wenn die Anforderungen nicht umgesetzt sind, kann meiner Meinung nach ein Projekt nie ein Erfolg sein. Was bringt es, ein Produkt abzuliefern das vom Kunden nicht gewollt worden ist?
Von daher bin ich auch immer wieder überrascht, wie wenig darauf geachtet wird, dass die Anforderungen korrekt Erhoben, Dokumentiert und Gepflegt werden. Meiner Meinung nach sind genau dies das Problem von vielen gescheiterten Projekten.
Das die im Idealfall gut umgesetzten und vollständingen Anforderungen dann noch gut verkauft werden müssen gehört natürlich auch dazu.
Viele Grüße
Wortspiel