Vorteile einer agilen Kostenkalkulation

Fixpreis-Angebote haben sowohl für Sie als Kunde sowie für uns als Auftragnehmer meines Erachtens ganz offensichtliche Mängel und Nachteile: Zum einen lassen sich bestimmte Anforderungen und Features im Vorfeld häufig kaum vernünftig schätzen, da oft detaillierte Informationen fehlen. Zum anderen ist es bei dem überwiegenden Teil von Projekten so, dass sich während der Implementierung mitunter weitreichende Änderungen ergeben. Entweder weil sich Anforderungen ändern oder weil sich herausstellt, dass die im Vorfeld geplanten Lösungsansätze sich in der Praxis nicht wie ursprünglich geplant umsetzen lassen.

Ein vernünftig agierender Dienstleister kalkuliert - und dies muss er aus wirtschaftlichen Gesichtspunkten auch - Unsicherheiten bzw. Unwägbarkeiten aufgrund von fehlenden Detailinformationen und Erfahrungswerten in sein Angebot mit ein. Der Auftraggeber entscheidet sich daher möglicherweise für den vermeintlich günstigsten Anbieter. Machen wir uns hier aber nichts vor: Heutzutage hat niemand etwas zu verschenken. Genauso wenig wie Sie Ihre Produkte oder Dienstleistungen für lau abgeben, wird dies eine Agentur tun. Insofern erlebt man es auch recht häufig, dass der vermeintlich günstigste Anbieter den Zuschlag bekommt, dieser in der Umsetzung dann aber eben aus Budgetgründen entweder nicht sauber arbeitet, ein halbfertiges Produkt abliefert und/oder am Ende eine Nachkalkulation fordert, um seine Kalkulation "sauber" halten zu können. Dadurch kann das vermeintliche Schnäppchen schnell in einem Desaster enden. Im schlimmsten Fall geht es dann jedoch nicht mehr "nur" ums Geld, sondern möglicherweise auch ums Image und etwaige Schäden.
Aus unserer Sicht und aufgrund unserer 15-jährigen Erfahrung im Bereich Webentwicklung können wir mit nahezu 100%-iger Sicherheit feststellen, dass man bei Softwareprojekten seriöser- und richtigerweise im Vorfeld eigentlich nur Schätzungen abgeben kann, da hier einfach zu viele Unwägbarkeiten mitspielen, die nicht kalkulierbar sind. Insofern bietet ein Fixpreis-Angebot nur auf den allerersten Blick die vermeintliche Sicherheit für den Auftraggeber. Wie bereits ausgeführt, wird er die tatsächlichen Kosten ñ und diese werden sehr häufig höher ausfallen als das erste Angebot ñ anderweitig bezahlen, entweder unmittelbar in Form von Change Requests oder über Umwege, also etwa über Nachbesserungsmaßnahmen durch einen anderen Dienstleister aufgrund mangelnder Qualität bzw. nicht fertiggestellter Software.

Darüber sollte man sich als Auftraggeber im Klaren sein: Die Rechnung wird kommen - so oder so! Fairerweise muss man hier auch ganz klar erwähnen, dass es unter wirtschaftlichen Gesichtspunkten kaum möglich sein wird, bei einem komplexeren IT-Projekt ein Lasten- und Pflichtenheft in der Qualität zu erstellen, dass es als richtige Basis für ein Fixpreisangebot verwendet werden kann. Der Aufwand hierfür wird am Markt kaum bezahlt werden, wodurch sich dann einmal mehr die Frage stellt, ob ein günstigeres "Alibi-Lasten- und Pflichtenheft" dann überhaupt Sinn macht.

Scrum ist insofern der für alle Beteiligten ehrlichste Ansatz. Ein Großprojekt wird in kleinere Teilprojekte zerlegt und dann einzeln geschätzt. Es wird auch nur das abgerechnet, was tatsächlich an Aufwand entstanden ist. Durch die vollständige Transparenz hat der Auftraggeber höchstmögliche Sicherheit und kann auch jederzeit reagieren. D.h. er kann bei sich abzeichnenden Budgetüberschreitungen jederzeit ñ auch in Abstimmung mit dem Scrum-Team ñ gegensteuern und im Notfall natürlich auch abbrechen. Hier hat er auch immer den Vorteil, dass bis dahin entwickelte Software oder Teile davon weiterverwendet werden können, da das Ziel von Scrum in der Bereitstellung von funktionsfähiger Software bzw. Softwareteilen besteht.

Das bedeutet: Transparenz und Bezahlung nur für die tatsächlich erbrachte Leistung! Aus unserer Sicht ist dies der deutlich bessere und auf lange Sicht gesehen auch für alle Beteiligten der wirtschaftlichste Ansatz.

In der Praxis hat sich bewährt, das Product Backlog im Rahmen eines bezahlten Workshops zusammen mit dem Kunden zu erstellen. Auf Basis der so erfassten Anforderungen kann eine erste Abschätzung der Aufwände ("Wir gehen aufgrund der im Backlog erfassten Anforderungen von x Sprints · 2-4 Wochen mit x Personen aus.") erfolgen. Durch diese Kalkulation kann der Projektumfang in einem sehr frühen Stadium bereits umrissen werden. Hier besteht für den Auftraggeber dann auch die Möglichkeit die so ermittelten Werte zu deckeln oder einen niedrigeren Wert als Höchstgrenze für die Implementierung anzusetzen.

Bei der Umsetzung wird dies dann entsprechend berücksichtigt. Grundsätzlich werden in der Folge nur die tatsächlich angefallenen Aufwände abgerechnet, wobei durch den jederzeitigen Zugriff auf die Projektmanagementtools diese Aufwände täglich eingesehen und überwacht werden können. Dadurch werden böse Überraschungen vermieden!

Insofern lässt sich mit Scrum - auch wenn dies nicht der eigentlichen Idee von Scrum entspricht - ein IT-Projekt auch mit einem vorab fixierten Budget realisieren. In diesem Fall wird - sofern das Budget für die gewünschten Features nicht ausreichen sollte - in Abstimmung mit dem Kunden die eine oder andere Funktionalität gestrichen oder angepasst, wodurch das definierte Projektbudget jedoch wieder gehalten werden kann ohne - und dies ist sicherlich ganz entscheidend - Kompromisse bei der Qualität eingehen zu müssen!

Zusammenfassung

Aus unserer Sicht bleibt für Auftraggeber nur die Empfehlung, sich beim nächsten Projekt einmal auf das Thema Scrum einzulassen. Auch ein Festpreisangebot schützt den Auftraggeber nicht vor etwaigen Risiken und damit verbundenen Mehraufwänden, die dann vielleicht zwar nicht sofort zur Kasse schlagen zu einem späteren Zeitpunkt aber in nahezu allen Fällen zum tragen kommen. Bei Scrum steht nicht ein fixer Preis für vorab genauestens definierte Features im Vordergrund, sondern die termingerechte Auslieferung bestmöglicher und funktionierender Software, die definierte Anforderungen erfüllen muss. Bei der Umsetzung bestehen hier mehr Freiheiten ñ was jedoch keinesfalls mit mangelnder Qualität gleichzusetzen ist.

Was aus unserer Sicht noch besonders herauszustellen ist: Auch mit Scrum ist man vor Sackgassen in einem IT-Projekt nicht geschützt, man erkennt diese in der Regel jedoch deutlich schneller und kann dementsprechend frühzeitig reagieren. Insofern eignet sich Scrum immer dann ganz besonders gut, wenn bereits zu Beginn des Projektes bei einer Vielzahl von Punkten noch Klärungsbedarf besteht, gewisse Unsicherheiten vorhanden sind bzw. bereits im Vorfeld zu erkennen ist, dass es hier noch zu diversen Änderungen und Anpassungen im Projektverlauf kommen kann bzw. wird.

Foto von Kelly Sikkema auf Unsplash