Magisches Dreieck im Projektmanagement – Eine Übersicht
Wir suchen in dieser Folge Antworten auf folgende Fragen:
- Was ist das klassische Projektmanagement Dreieck?
- Warum finde ich das klassische Projektmanagement Dreieck veraltet und gefährlich und was finde ich besser?
- Was ist das agile Projektmanagement Dreieck?
- Warum stecken im agilen Projektmanagement Dreieck die falschen Glaubenssätze?
Widmen wir uns zunächst der ersten Frage:
Was ist das magische Projektmanagement Dreieck?
Dieses besteht allgemein aus 3 Faktoren: Leistung, Zeit und Kosten.
Beispiel: Eine App soll 3 Funktionen beinhalten, in 3 Monaten fertig sein und 30 Tsd. € kosten.
Stell dir nun vor, dass diese 3 Faktoren an den Spitzen des Dreiecks geschrieben stehen. Das Dreieck soll verdeutlichen:
Mehr Funktionsumfang, also mehr Zeit und mehr Geld. D.h. ich ziehe die obere Spitze gedanklich nach oben und die Kanten von Geld und Zeit werden automatisch länger.
Weniger Geld ausgeben würde bedeuten, dass Funktionen und Zeit zusammenschrumpfen.
Wenn ich weniger Zeit habe, schrumpfen Funktionen und Geld zusammen.
So weit so gut. Nur eine Sache fehlt: Qualität. Diese bildet die 4. Dimension. Qualität ist genauso wichtig wie alle anderen 3 Dimensionen. Das Problem ist jedoch: Wegen diesem gefährlich vereinfachten magischen Dreieck wird Qualität nicht definiert. Weder in den Anforderungen, noch im Vertrag. Und deshalb ist es das erste, auf das jeder Lieferant als erstes verzichtet, wenn er in Zeitnot kommt. Das ist meine Praxiserfahrung seit 20 Jahren.
Ich mache mal ein Beispiel wie ich Qualität definiere. Iso 9126 ist da meine Zauberwaffe. Diese definiert Produktqualität in Qualitätsmerkmalen, wie beispielsweise die Wartbarkeit. Bei einer kleinen App definiere ich mindestens 5-6 Regeln gemäß Clean Code:
- Permanenter Zugriff auf das Software Repository für Reviews
- Benutzbarkeit, was wir auch als UX kennen
- Effizienz. Megawichtig, wenn Du in die AWS Cloud gehst. Da bezahlts Du nach Transaktion. Jeder get request, jeder Put request kostet bares Geld. Beispiel: Datensatz abholen.
- Sicherheit z.B. nach der Norm 62443 für Cyber Securtiy
- Zuverlässigkeit. Mean time between failure
Was ist besser als das magische Projektmanagement Dreieck?
Harry Sneed ist für mich der erste, der “Devils Square” aufgestellt hat und Qualität zu dem Dreieck aufgenommen hat. Das finde ich gut. Wenn man Projektmanagement modellhaft vereinfachen möchte, dann würde ich dieses Viereck wählen.
So: Manche schreiben anstelle Leistung auch als Qualität ins Dreieck. Meinen damit aber die reine Funktionalität und dass diese ohne Bugs geliefert wird. Damit ist aber nur die Funktionalität gemeint. Meine Wahrnehmung der letzen 20 Jahre. Muss nicht stimmen!
Ist folgende Aussage richtig?
“Wenn ich einen Flughafen baue oder ein Haus, dann sollte ich mir von Anfang an schon ziemlich klar darüber sein, was mein Scope ist. Ich kann ja nicht nach ein paar Monaten plötzlich auf die Idee kommen, noch ein Stockwerk dazuzubauen oder die Garage doch auf die andere Seite zu setzen. ”
Völlig richtig. Das Kernproblem ist hier, dass in den letzten 40 Jahren im Projektmanagement eine falsche Analogie gezogen wurde. Man hat gedacht, dass man das Bauen von Software genau so behandelt wie das Bauen eines Hauses. Und der Denkfehler, Software-Funktionen sollte man architektonisch so aufbauen (Qualität/Wartbarkeit), dass man sie unproblematisch abreißen kann. Das ist normal. Egal ob klassisch oder agil.
Noch mal ein Denkanstoß zum Thema klassischer Umsetzung nach Lasten- und Pflichtenheft. Nur mal angenommen, ich würde den Lieferanten bitten, an jede Funktion ins Pflichtenheft einen Eurobetrag zu schreiben.
Und dann bitte ich ihn, die Architektur nicht als großen monolithischen Block zu bauen, sondern lose gekoppelt und alle 2 Wochen zu liefern und mir vorzustellen. Ich als Kunde kann dann alle 2 Wochen entscheiden, dass ich Funktionen oder eine im Pflichtenheft geplante Anforderung wegschmeiße und für den gleichen €-Betrag eine neue Funktion entwickeln lasse. Dann komme ich doch einer agilen Sofwareentwicklung schon ziemlich nahe obwohl ich mit Lastenheft und Pflichtenheft arbeite, oder? Ist das jetzt agile Softwareentwicklung oder klassich?
Grundsätzlich müssen wir Modelle immer mit Vorsicht genießen, da sie schnell zu einengenden Glaubenssätzen führen.
Nun zum Agilen Projektmanagement Dreieck:
Was ist das agile Projektmanagement Dreieck?
Es wird beschrieben, dass Kosten und Zeit fix sind und über die Inhalte gesteuert wird. Gehen wir mal 3 häufige Konstellationen durch:
1) Zeit fix, Budget fix, Leistung variabel.
Die Idee dahinter ist, dass zuerst die Funktionen mit hohem Wert priorisiert werden und dann nur noch “nice to have” folgt.
Das große Problem liegt darin, dass ich als PO zu Beginn der Produktentwickklung nicht garantieren kann, dass das Team alle Kernfunktionen schafft. Das Risiko: Unvollständiges Produkt zum festgelegten Termin (z.b. Messe).
2.) Zeit fix, Budget variabel, Leistung variabel.
Diese Konstellation ist recht ähnlich zu 1.). Jedoch kann ich Experten dazu staffen, um schneller zu sein. Das Risiko “Unvollständiges Produkt” sinkt stark. Auch kann es mit Geld stark minimiert werden, wenn man es hat. Also schon mal besser als 1.).
3.) Alle drei sind variabel. Nach jedem Sprint Review wird von den Stakeholdern entschieden, ob sie zufrieden sind oder weiter am Proukt gearbeitet werden soll. Damit ergeben sich dieselben Vorteile wie bei 2.) & ich gehe erst dann auf den Markt, wenn der Kunde zufrieden ist. Das entspricht an sich am meisten der agilen Idee und Kundenzufriedenheit.
Das agile Projektmanagement-Dreieck, indem die Inhalte variable sind und Zeit und Geld fix ist nur eine einzige Möglichkeit des Umgangs bei der Zielerreichung. Deswegen Vorsicht. Ich würde dies nicht als Standard deklarieren, sondern schränkt es mich bei der Zielumsetzung ein.
Wenn ich denke: Wenn wir agil arbeiten, dann muss Geld und Zeit fix sein, dann ist das ein limitierender Glaubenssatz. Ich komme dann ggf. im Projektverlauf nicht mehr auf die Idee, den Kunden zu fragen, ob er bereit wäre mehr Geld auszugeben, um seine Zufriedenheit zu erhöhen.
Zusammenfassung zum magischen Projektmanagement Dreieck
- Ob agil oder klassich/predictive: Die Kundenzufriedenheit sollte immer mit Prio 1 im Fokus stehen. Und hier würde ich den Kunden fragen was ihm wichtiger ist:
Gibt es keine Mehrkosten oder die Vollständigkeit des Leistungsumfang, dann ist die Leistung fix. Gibt es keine Mehrkosten oder Termintreue um jeden Preis, dann ist die Zeit als Faktor fix.
Um ganz ehrlich zu sein, gibt es keine harten Unterscheidungen zwischen dem klassischen Projektmanagement (also z.B. PMI oder Prince 2) und den agilen Ansätzen. Ich kann..
- klassisch organisierte Projekte sehr agil gestalten
- Inkrementell oder sogar iterativ liefern mit Lasten- und Pflichtenheft
- Methoden aus dem Bereich New work nutzen, z.B. Die Partizipation von Mitarbeitern an Entscheidungen.
- Prototypen bauen und vor Kunden testen lassen
- genauso gut in Scrum kleine Wasserfälle durchführen: Der PO entscheidet nichts, sondern sein Chef. Der heißt dann Chief Product Owner. Die Mitarbeiter werden zu Retros gezwungen, obwohl sie keine Lust haben. Der Kunde wird nicht in die Produktentwicklung mit einbezogen.
Es wird deutlich, dass Scrum nicht automatisch agil und PMI nicht automatisch Wasserfall sein muss.
Meine Vorgehensweise zum magischen Projektmanagement Dreieck :
- Ich würde das Devils Square bevorzugen, um Dinge zu erklären. Mehr Details
- Ich würde meinen Kunden fragen, was ihm wichtiger ist: Vollständigkeit an Features oder Kostendeckung.
- Selbst in Projekten, die mit Lasten- und und Pflichtenheft geschrieben werden, würde ich Methoden aus dem New Work und agile Prinzipien und Werte einfließen lassen, da es einfach sinnvoll ist.
#064
