Bereits aus dem magische Dreieck des Projektmanagement kommt es klar heraus: Zeit, Kosten und Umfang definieren ein Projekt. Darum bin ich als Projektleiter gegenüber meinem Auftraggeber immer mit der (leidigen) Frage konfrontiert: Wann bist du fertig? Was kostet es? Getriggert dadurch, dass der Auftreggeber Sicherheit braucht, da er vermutlich Rechenschaft für das ausgegebene Geld geben und Termine halten muss.
Je länger ich als Projektleiter arbeite, desto mehr beginnt mich diese Frage zu stören, da ich in deren Beantwortung keinen direkten Nutzen für Kunde wie Projekt sehe. Ein Projekt wird immer in Zukunft geplant. Bisher habe ich noch niemanden kennengelernt, der in die Zukunft schauen könnte. Also sind Termine und Kostenangaben immer unsichere Vorhersagen. Und doch stützen sich oft alle Projektbeteiligten auf eine Detailplanung, die auf diesen Vorhersagen beruht und wiegen sich damit in (eine oft falsche) Sicherheit.
Negative Effekte von Schätzungen
Aufwandschätzungen scheint mir, setzen unnötig unter Druck. Wie würdest du dich fühlen, wenn du als Software-Entwickler 8 Stunden geschätzt hast für einen Task und nach 4 Stunden merkst, dass du noch mindestens 12 Stunden benötigst? Dies verursacht automatisch Stress, führt dadurch zu Abstrichen an Qualität und schlussendlich leidet kurz- oder längerfristig die Kundenzufriedenheit. Dann kosten Aufwandschätzungen Zeit und dadurch bares Geld. Anforderungsformulierung, Anforderungsklärung, Schätzung, Meetings, Controlling, Change Requests, Zeiterfassung, Projektplanung. Stell dir vor, die dafür aufgewendete Zeit könnte andersweitig, nämlich direkt in die Entwicklung von Mehrwert für den Kunden des Auftraggeber investiert werden … !
Eine genaue Schätzung ist Zufall
Steve McConnell bestätigt mit seinem Modell Cone of Uncertainty, was wir eigentlich bereits wissen: Je mehr Zeit wir uns mit einer Anforderung auseinandersetzen, desto genauer können wir diese schätzen. Sind wir neu mit einer Anforderung konfrontiert (also z.B. bei Projektbeginn oder in der Presales Phase), liegen wir mit unserer Schätzung vielleicht zufällig richtig, aber viel wahrscheinlicher ist es, dass wir uns um das zwei- bis vierfache verschätzen. Also entweder massiv zu hoch oder massiv zu tief sind. Kürzlich habe ich dies direkt erlebt in der Umsetzung eines Change Requests. Die ursprünglich vom Entwickler kommunizierte Zahl hat sich am Schluss effektiv vervierfacht. Obwohl ich viele Buffer-Stunden eingeplant habe, waren wir am Schluss fast doppelt über dem Budget.
Gibt es eine Alternative?
Wie komme ich als Projektleiter ohne Schätzungen zum Ziel? Wie kann ich dem Kunden Sicherheit in Termin und Budget geben, ohne jeden einzelnen Task akribisch zu formulieren und schätzen zu lassen? Realistisch gesehen, geht es im Projektgeschäft nicht ohne Budget und Termine. Aber es ist ein Unterschied, ob man Kontrollwahnsinn betreibt und den Termin und das Budget in hunderte geschätzte Einzeltasks splittet, oder ob man eine Summe pro Monat oder Sprint definiert und jeweils ein übergeordnetes Ziel dafür festlegt.
Und da sind wir wieder bei Scrum. Die Tatsache, dass im offiziellen Scrum Guide das Wort ‹estimate› nie vorkommt (und übrigens auch nicht Story Points) und Transparenz dafür 12, Value sogar 24 Mal, zeigt schon ziemlich klar, worauf Scrum den Fokus legt. Maximale Transparenz für Stakeholder (z.B. Auftraggeber) wie Scrum Team führt zu Sicherheit. Priorisierung nach Wert für den Endkunden führt implizit zur schnellstmöglichen Terminplanung und damit zu Risikoreduzierung und sichbaren Resulaten nach jedem Sprint. Dadurch erneut zu Sicherheit. Und das ohne eine einzige detaillierte Aufwandschätzung.
Teilweise wird auch in Scrum geschätzt, dann aber oft in Story Points und mit Scrum Poker. Warum, ist ein separates Thema. Zusammengefasst ist der Hauptunterschied, dass nicht Stunden geschätzt, sondern Komplexität verglichen wird. Denn wir Menschen sind viel besser im Vergleichen als im von Grund auf neu schätzen. Mein Sohn weiss z.B. sofort, ob er oder sein Bruder die grössere Portion Pommes erhalten hat – aber die Anzahl der Pommes schätzen könnte er nicht exakt.
Ohne Vertrauen geht es nicht
Das ultimative und dadurch auch effektivste Mittel um Schätzungen zu reduzieren oder ganz zu vermeiden ist meiner Meinung nach Vertrauen. Nur ein Kunde, der mir als Projektleiter, uns als Scrum Team, uns als Unternehmen voll vertraut, erhält maximalen Wert für sein Geld. Nur dieser Kunde ist bereit und entspannt dabei, eine Geldsumme für Entwicklungszyklen freizugeben, ohne das Resultat und die genauen Lieferobjekte bereits zu kennen. Vertrauen entsteht durch Transparenz, durch Kompetenz, durch Zusammenarbeit, Kommunikation auf Augenhöhe, durch Authentizität, Respekt, durch generierten Wert und gelebte und nicht gesprochene Werte. Dieses Vertrauen zu etablieren, dafür brenne ich in meinen Projekten.
Was ist deine Erfahrungen mit Aufwandschätzungen?
Kommentare