Gestern habe ich an einem guten und sehr produktiven Meeting teilgenommen. Leider ist das nicht der Standard. Es gibt durchaus Meetings in denen sich die Frage der Sinnhaftigkeit aufdrängt. Viel mehr möchte ich dazu nicht schreiben. Besser als Richard Joerges könnte ich es ohnehin nicht auf den Punkt bringen: Meetings sind Zeit- und Geldverschwendung. Es sei denn …
über Namen, Hunde, Rosen und Missverständnisse
Was könnte mein Gesprächspartner gemeint haben? Diese Frage sollte man sich immer wieder stellen. Allzu leicht entsteht aus dem ersten Verständnis einer Äußerung eine falsche Reaktion, die dann zur Quelle weiterer Missverständnisse werden kann. Sicher – das ist eine banale Weisheit über Kommunikation. Ich selbst habe hier schon oft über Kommunikation geschrieben und habe das natürlich alles komplett verinnerlicht und kommuniziere stets erfolgreich und angemessen 
… weit gefehlt. Auch “Kommunikationsspezialisten” sind nicht vor groben Schnitzern gefeit. Aktuelle Beispiele der letzten Tage gefällig?
Einsatz von PM Standards
Zum Wochenende gibt es ein kurzes Zwischenergebnis aus der aktuell laufenden Umfrage. Nebenstehende Grafik zeigt die Verteilung der eingesetzten Projektmanagement Standards. Unabhängig von den noch ausstehenden Auswertungen hinsichtlich der Projektgrößen sowie dem zusätzlichen Einsatz von agilen Methoden zeichnet sich doch schon Interessantes ab. Hinter den 33%, die einen selbst definierten Standard angegeben haben, verbergen sich sicher noch einige agile Projekte. Die geringe Häufigkeit des Einsatzes der großen Standards hat mich etwas überrascht. Sehr bedenklich stimmt mich die Zahl von 24%, die keine standardisierte Vorgehensweise verwenden.
Wie so oft in der Forschung leiten sich aus diesem Zwischenergebnis mehr Fragen als Antworten ab:
- Werden PMBOK, ICB und Prince2 eher in großen Projekten eingesetzt?
- Ist die Erfolgsquote der Projekte ohne standardisierte Vorgehensweise unterdurchschnittlich?
- Zeigt ein Standard eine deutlich vom Mittelwert abweichende Erfolgsquote?
- Sind die selbst definierten Standards mit agilen Methoden vermischt?
Die Daten liefern zumindest erste Hinweise für Antworten. Für eine stabile Aussage insbesondere inkl. einer Aufschlüsselung nach Projektgrößen und Typen ist die Zahlenbasis allerdings noch zu gering. Deshalb möchte ich an dieser Stelle nochmals bitten sich an der Umfrage zu beteiligen und den Link an möglichst viele Bekannte und Kollegen weiter zu geben.
Das Wasserfallmodell hat noch nie funktioniert
Im voran gegangenen Beitrag hatte ich diese Aussage schon getroffen. Nachdem einige Nachfragen eingetroffen sind, möchte ich die Aussage etwas weiter ausführen. Nebenstehend ist ein typisches Wasserfall-Diagramm zu sehen. Die konkrete Benennung der Phasen kann variieren – entscheidend ist der Grundgedanke, dass eine Phase abgeschlossen wird und ihre Ergebnisse quasi in die nächste Phase ergießt. Die Ähnlichkeit zu Gantt Diagrammen und klassischen Projektplänen ist keineswegs zufällig. Diese Darstellung geht auf eine Veröffentlichung von Winston Royce aus dem Jahr 1970 zurück. Der Titel lautet MANAGING THE DEVELOPMENT OF LARGE SOFTWARE SYSTEMS. Diese Darstellung des Wasserfalls hat sich in das Bewusstsein der Softwarebranche und des Projektmanagements eingebrannt. Bei aller Kritik am Wasserfallmodell blieb der Eindruck hängen, dass es bei hinreichender Sorgfalt der Anforderungserhebung, funktionieren würde.
Anforderungs-, Change- und Scopemanagement sind genau genommen Versuche das Wasserfallmodell zu verbessern. Im Laufe der Zeit verbreiteten sich iterative Ansätze und mündeten in den 90er Jahren des letzten Jahrhunderts in agile Vorgehensweise. Das tragische Element an dieser Geschichte ist, dass die Grundaussage der Veröffentlichung eine andere ist als jene die in das Bewusstsein der Branche drang.
Winston Royce schreibt in der Zusammenfassung:
In my experience, however the simpler method has never worked on large software development efforts and the costs to recover far exceeded those required to finance the five-step process listed.
Die erwähnte “simpler method” ist der klassische oben skizzierte Wasserfall. Die Mehrkosten durch den aufwändigeren Prozess (Iterationen) sind geringer als jene, die durch Nachbesserungen (Terminüberschreitungen) am einfachen Modell entstehen. Er schreibt also sinngemäß: “Das hat noch nie funktioniert“. Dementsprechend sind in der Veröffentlichung einige andere Grafiken enthalten, mit denen er bereits 1970 eine iterative Vorgehensweise bis hin zu wiederholtem Coding vorschlägt – das würde man heute Refactoring nennen.
Ein wenig erinnert mich das an die Legende vom Eisengehalt des Spinats
… den bis heute noch gelegentlich behaupteten, außergewöhnlich hohen Eisenanteil besitzt Spinat jedoch nicht – der Schweizer Physiologe Gustav von Bunge hatte 1890 den Wert zwar richtig berechnet, doch bezogen sich seine Angaben auf getrockneten Spinat, wurden aber später irrtümlich frischem Spinat zugeschrieben, der zu ca. 90 % aus Wasser besteht. (Wikipedia)
Posted in Projektmanagement RT
Tagged Anforderungsmanagement, Planung, Softwareentwicklung
3 Comments
