Problemstellung: Die Kostenprognosen für IT-Projekte sind unzuverlässig

Jüngst rief uns ein Kunde an und stellte fest, dass unsere Schätzungen für ein und das gleiche Projekt von 50 Personentagen auf 96 Tage und inzwischen 110 Tage gestiegen waren. Als Manager in seinem Unternehmen brauchte er Budget- und Planungssicherheit und war verunsichert, ob ein "agiles Vorgehen" diese Sicherheit ermöglichen könne.

These: Es gibt gar keine zuverlässige Prognose für viele IT-Projekte

Die meisten Projekte sind zu Beginn gar nicht sauber zu beschätzen. Die Gründe sind Auftraggebern und Auftragnehmern oft gleichfalls bewusst:

• Fehlende, ungenaue oder falsche Spezifikationen
• Hohe Komplexität der Anforderungen und der Umsetzung, die das Planen erschwert
• Sich verändernde Prioritäten während des Projektverlaufs
• Gemeinsames Lernen in den 'neuen' Bereichen des Projekts sowohl auf Auftraggeber- als auch auf Auftragnehmerseite

Diese und andere Faktoren sorgen dafür, dass IT-Projekte während der Laufzeit auf den ersten Blick teurer werden. Zu Beginn denkt man noch: "Das ist nicht kompliziert. Das können wir schnell umsetzen." Und während der tatsächlichen Umsetzungsphase kommen dann immer mehr Anforderungen hinzu und man versteht, dass das vermeintlich Einfache doch nicht so einfach, sondern ziemlich kompliziert sind.

Warum denn kein Festpreis? Damit geht's doch!

Ein häufiger Ausweg, den große Unternehmen suchen, ist ein Festpreis: "Ihr sagt mir einen Preis, mit dem ich kalkulieren kann und der muss Euch dann reichen." Das ist ein häufig praktiziertes Modell. Im besten Fall für den Auftraggeber verlagert er das Problem der Komplexität und Planungsunsicherheit komplett auf den Auftragnehmer, der in Kauf nimmt, mehr zu arbeiten, ohne dafür vergütet zu werden.

Die Realität sieht oft anders aus:

• Die Elbphilharmonie in Hamburg kostet 399,9 Mio. Euro statt wie geplant 190,9 Mio. Euro. (Wikipedia)
• Das Sydney Opera House kostet 50 Millionen Pfund statt 5 Millionen Pfund und wird nicht 1963 sondern erst 1973 fertig. (Wikipedia)
• The Squaire am Frankfurter Flughafen kostet 1.200 Millionen Euro statt 600 Millionen Euro Planung. (Wikipedia)

Nicht nur diese großen Bauprojekte gehen schief. Sondern auch fast die Hälfte der IT-Projekte. Darin ändern sich laut Untersuchungen bis zu 25% der Anforderungen während der Laufzeit.

Ein Festpreis ist also mehr wahrgenommene als tatsächliche Sicherheit.

Agile: Relative Beschätzung und kontinuierliche Konkretisierung

Wenn man ein agiles Vorgehensmodell wählt, wird zu Beginn nur sehr grob geschätzt. Das führt zu starken Schwankungen des Budgets zur Laufzeit des Projekts. Dafür bekommt man mit zunehmender Laufzeit immer bessere und genauere Zahlen und von Anfang an alle Steuerungs- und Kontroll-Möglichkeiten.

Während in den großen Bauprojekten kaum Änderungen möglich waren, als die Auftraggeber mitgeteilt bekamen, dass die Budgets teilweise erheblich gesprengt würden, können Auftraggeber in agilen Projekten zwischen vielen Optionen wählen:

• Veränderung des Projektumfangs, um das Budget halten zu können. Das geht hier, weil zu Beginn die wichtigsten Sachen erledigt werden.
• Stopp des Projekts. Das funktioniert hier besser, weil man sehr früh im Projekt noch nicht so viel Budget verbraucht hat. Dann ist ein Ausstieg nämlich auch tatsächlich noch möglich.
• Veränderung des Budgets. Die einzige Mäglichkeit, die in einem Festpreisprojekt bleibt, wenn erst sehr spät kostenpflichtige Änderungen und Zusatzbudgetbedarfe kommuniziert werden und ein "lock in" längst stattgefunden hat.
• Budget nutzen und dann stoppen. Scrum liefert nach jedem Sprint ein fertiges Produkt. Wenn man nicht so schnell voran kommt, erhält man trotzdem funktionsfähige Software mit den wichtigsten Funktionen. Aber nicht allen. Da ist besser zu verkraften, als gar nichts "Lauffähiges".