I – Die drei klassischen Projektgrößen und ihre Auswirkungen
|
Scope (fix) |
Time (fix) |
Quality (variabel) |
Ein Umfeld, in dem es nicht auf hochwertige Qualität ankommt, ist das Einzige, in dem diese vernachlässigt werden darf. Dies kann der Fall sein für kurzlebige Produkte, die regelmäßig runderneuert oder sogar ganz ausgetauscht oder neu gebaut werden. Beispiele: Webseiten, Marketing-Produkte, Event-spezifische Produkte, die jeweils nur einen kurzen Zeitraum genutzt und nicht über Jahre betrieben und weiter entwickelt werden müssen. Durch die vernachlässigte Qualität entstehen bei der Nutzung des Produktes Mehraufwände in den Entwicklungsteams. Erhöhtes Fehleraufkommen, Workarounds für Anwender und Entwickler, Anfragen an Service Teams, unzufriedene Anwender und Kunden sind nur die offensichtlichen Auswirkungen eines qualitativ vernachlässigten Systems. Im schlimmsten Fall ist die Qualität so gering, dass das Produkt zu dem fixen Termin gar nicht lieferbar ist und „zähneknirschend“ ein neuer, „fixer“ Termin gefunden werden muss. |
|
Scope (fix) |
Quality (fix) |
Time (variabel) |
In einem Umfeld, in dem ein definierter Funktionsumfang wichtiger ist als ein festgelegter Termin, kann dieser vernachlässigt werden. Dies trifft oft bei der Ablösung eines bestehenden Systems zu, dessen umfangreiche Funktionalität im neuen System gewährleistet sein muss. Andernfalls wäre das neue System von den Anwendern für ihren Workflow nicht nutzbar. Ein weiteres Beispiel ist die Entwicklung von Produkten, die eine vollständige, konzeptionelle und inhaltliche Integrität benötigen. Dies ist der Fall bei vielen Computerspielen und Spielfilmen. Hier kommt es auf Perfektion und Details an. Im schlimmsten Fall verzögert sich der Termin so weit in die Zukunft, dass alternative Produkte von anderen Herstellern früher auf dem Markt erscheinen oder der Aufwand in keinem Verhältnis mehr zum Ergebnis steht. |
|
Time (fix) |
Quality (fix) |
Scope (variabel) |
Wenn ein Liefertermin das wichtigste Erfolgskriterium ist, dann kann der Funktionsumfang am ehesten vernachlässigt werden. Dies trifft in erster Linie auf Event-getriebene Entwicklungen zu, wie beispielsweise saisonale (Feiertage, Ferien) und extern vorgegebene Ereignisse (Messen, Konferenzen). In diesen Fällen muss die Funktionalität des Produktes hart priorisiert umgesetzt werden, so dass zum Zieltermin ein funktionierendes Produkt geliefert werden kann und einen sinnvollen Mehrwert stiftet. Im schlimmsten Fall ist der Funktionsumfang so gering, dass kein minimales Produkt geliefert werden kann. |
II – „Ja aber alles ist wichtig! Dann nehmen wir halt mehr Geld!“
Was sind die Auswirkungen, wenn das Budget entsprechend erhöht wird mit dem Ziel, auch die dritte Variable zu fixieren?
|
Scope (fix) |
Time (fix) |
Quality (variabel) |
Einkauf weiterer Mitarbeiter für Testing, QA und Entwicklung. Entstandene Fehler sollen behoben werden. Gleichzeitig wird versucht, die weitere Entwicklung von vornherein in höherer Qualität liefern zu lassen. All diese Maßnahmen kosten viel Zeit, die durch den Einsatz weiterer Mitarbeiter kompensiert werden soll. Diese müssen jedoch eingearbeitet werden, so dass die bestehende Mannschaft unter einer erweiterten Aufgabenliste leidet: der Termin steht immer noch fest, die vorhandene Qualität ist nicht zufriedenstellend, Fehler müssen behoben werden, neue Mitarbeiter müssen eingearbeitet werden, die noch offenen Entwicklungsaufgaben/Features müssen angefangen und fertig gestellt werden, die bisherige Arbeitsweise wird in Frage gestellt, der Druck steigt und die Unzufriedenheit wächst. Die einzige Möglichkeit wäre also, Scope zu reduzieren oder durch Terminverschiebung mehr Zeit zu gewähren. Beides ist in diesem Szenario jedoch nicht möglich und ausgeschlossen. |
|
Scope (fix) |
Quality (fix) |
Time (variabel) |
In dieser Konstellation machen wir das Richtige richtig. Wir haben nur nicht genügend Zeit, alles umzusetzen. Die Schlussfolgerung lautet also, dass schneller umgesetzt werden muss. Die bestehende Mannschaft ist bereits ausgelastet, so dass als einzige Option die Beschaffung weiterer Mitarbeiter übrig bleibt. Diese Maßnahme ist in diesem Szenario tatsächlich einfacher als in dem oben beschriebenen, kostet jedoch ebenso sehr viel Zeit. Und damit wird das eigentliche Ziel, die Entwicklung zu beschleunigen, mit dieser Maßnahme torpediert. Die Einarbeitungsaufwände für die neuen und bestehenden Mitarbeiter sind enorm, gerade weil das Qualitätsniveau unbedingt gehalten werden muss. Der Druck auf die Entwicklungsmannschaft steigt, da nun die Erwartungshaltung existiert, dass ein früherer Termin gehalten wird. |
|
Time (fix) |
Quality (fix) |
Scope (variabel) |
Hier haben wir beinahe die gleiche Problematik wie eben beschrieben. Wir können zwar einen Termin mit hoher Qualität halten, liefern jedoch zu wenig Scope. Mehr Budget hilft uns auch in diesem Falle wiederum nur, weitere Mitarbeiter hinzu zu nehmen. Die Auswirkungen sind letztlich die gleichen. Neue und alte Mitarbeiter investieren viel Zeit für die Einarbeitung und der Druck, mehr umgesetzt zu bekommen, steigt. |
III – Scope ist nie fix, Änderungen finden immer statt!
Wenn wir uns das Wesen der drei klassischen Projektgrößen anschauen, dann machen wir folgende Feststellungen.
- Ein festgelegter Termin („Time“) verändert sich normalerweise nicht. Er besitzt eine statische Größe, die so bleibt, wie sie ist.
- Eine definierte Produktqualität („Quality“) verändert sich normalerweise ebenso nicht. Sie wird im Regelfall sehr hoch erwartet und in kaum einem Fall ist es sinnvoll, die Qualität neu zu verhandeln.
- Der Umfang bzw. die Features einer Entwicklung („Scope“) verändern sich normalerweise in jeder Phase der Umsetzung. Neue Ideen und Erkenntnisse entstehen während des Entstehungsprozesses und sollen in die laufende Umsetzung konstruktiv einfließen.
Daher können wir als goldene Regel für die Durchführung von Entwicklungsvorhaben postulieren: Hohe Qualität wird zu einem festgelegten Termin geliefert, den Umfang halten wir jedoch flexibel.
Dies ist der Grund, weswegen agile Methoden in kurzen Abständen funktionierende Produkte liefern und die Teile mit dem höchsten Anwendernutzen bzw. Business Value zuerst umgesetzt werden. Mit einem konsequent priorisierten Backlog ist das magische Projektdreieck überhaupt nicht mehr magisch und wir bekommen ein nutzbares Werkzeug an die Hand.