Das Problem mit dem Festpreis
Wenn in einem IT-Projekt ein agiles Vorgehen gewünscht ist, gleichzeitig aber ein klassisches Festpreisangebot abgegeben werden muss, ist eine realistische Schätzung des Aufwandes oft schwierig. Es gibt hier zwar verschiedene Ansätze wie etwa das Pareto-Prinzip, die eine solche Schätzung vereinfachen sollen. Dennoch bleibt es auch nach Hinzuziehen solcher Regeln meist nur bei einer Näherung an die Aufwandsschätzung. In einem Beitrag unseres Kollegen William Kessler wurde dieses Problem bereits tiefer erörtert.
Erschwerend kommt hinzu, dass große Systeme oft nur im Verbund (Microservices/ Cloud/ Konzernsysteme) funktionieren. Meist existieren zudem Interdependenzen zwischen den verschiedenen Systemen, so dass etwa System A nicht richtig ohne System B funktionieren kann. Selbst erfahrene Projektmanager können in der Einschätzung solcher Abhängigkeiten und auch der Aufwände nicht immer exakte Aussagen treffen, was bei manchen Kunden bisweilen für Unmut sorgt.
Meilensteine setzen
Sowohl für die Erstellung bzw. Schätzung des Angebotes, als auch für die Nachverfolgung des Projektfortschritts, hat es sich daher bewährt, Qualitätsstufen bzw. Meilensteine einzuführen. Diese helfen bei der Kosteneinschätzung und der Abarbeitung von großen Systemen, aber auch beim Rollout der Software beim Kunden. Die Anforderungen werden dafür zu Beginn in funktional trennbare Arbeitspakete zerlegt: Gemeinsam mit dem Kunden wird mit Hilfe von Wireframes und Datenmodellen ein planbarer Arbeitsumfang definiert. Dieser Arbeitsumfang wird dann von der Entwicklungsabteilung geschätzt und vom Projektleiter nach Rücksprache mit dem Kunden wiederum mit der Entwicklungsabteilung geplant. Dabei geht es z.B. um Kernfunktionen wie Minimum Viable Products (MVP) oder um Komponenten.
Die Qualitätsstufen richten sich nun nach dem Grad der Fertigstellung in Absprache mit dem Kunden. Sie sind beliebig erweiterbar und können z.B. auch noch das Anforderungsmanagement umfassen.
Qualitätsstufen mit Ampelfarben
Im folgenden Beispiel möchte ich ein Ampelsystem aufzeigen, das dem Kunden zu jedem Zeitpunkt über den Status des laufenden Entwicklungsprojekts informieren können soll. Zusätzlich zur Ausgangssituation (Stufe 0) werden hier drei Stufen beschrieben, die sich jeweils auf den Entwicklungsfortschritt beziehen:
Stufe 0: Wenn ein Kunde ein Projekt beauftragt hat, die Arbeiten aber noch nicht begonnen haben, weil man sich z.B. noch im Anforderungsmanagement befindet, erwartet keiner der Projektbeteiligten, dass das Projekt fertig ist. Hier befinden wir uns auf der Qualitätsstufe 0: Die Ampel ist ROT.
Stufe 1: Nachdem die Entwicklung begonnen hat und dies dem Kunden kommuniziert wurde, erwartet dieser nun die Fertigstellung des besprochenen Umfangs, also des ersten Meilensteins, zu einem Zeitpunkt X. Läuft alles nach Plan und Zeitpunkt X ist gekommen, ist die nächste Stufe erreicht – Qualitätsstufe 1: Die Ampel ist DUNKEL ORANGE.
Stufe 2: Zu diesem Zeitpunkt sieht der Kunde ein erstes Ergebnis. Da agil gearbeitet wird, kann der Kunde nun seine Änderungswünsche einfließen lassen. Missverständnisse sind dabei nicht völlig ausgeschlossen, durch die Wireframes und Datenmodelle wird aber sichergestellt, dass die Änderungswünsche das Konzept nicht komplett auf den Kopf stellen. Gerade das Datenmodell sollte in der Regel nicht mehr groß angepasst werden. Es wird nun so lange gearbeitet, bis der Kunde zufrieden ist. Wir erreichen jetzt Qualitätsstufe 2: Die Ampel ist nun HELL GELB.
Stufe 3: Die Software wird in den Produktivbetrieb überführt. Dieser Projektabschnitt beginnt mit dem tatsächlichen Produktivsetzten der Anwendung. Alle Arbeiten, die dazu noch nötig sind und alle Folgeaufträge, die eventuell in einem Rahmenvertrag (Service Level Agreement, SLA) vereinbart wurden, laufen nun auf dieser letzten Stufe – bis das System irgendwann wieder abgestellt wird. Qualitätsstufe 3 ist erreicht, die Ampel ist GRÜN.
Vorteile des „Q-Modells“
Aufgrund der steigenden Komplexität von anzubindenden Software-Systemen und der zunehmenden Verbindung wenig kompatibler Systeme ist das Produktivschalten aus diversen Gründen oft noch nicht möglich. So ist z.B. oft noch kein Betriebskonzept vorhanden, oder es wird noch auf die Bereitstellung anderer Systeme gewartet. Hier kommen die Vorteile des hier vorgestellten Modells zum Tragen, denn beide Seiten hatten sich zu Beginn darauf geeinigt, dass das System laut Beauftragung abgeschlossen ist. Nun kann die Rechnungsstellung erfolgen – mit dem Mangel, dass die Software aus externen Gründen noch nicht produktiv ist. So können beide Seiten von einer Fertigstellung des Projekts profitieren - auch bei Verzögerungen, die nicht unmittelbar kontrollierbar sind.
