Was kostet das Projekt?

von Patrick Schuh

| zuletzt aktualisiert am 05.09.2024

|
• Technologien

Bei neuen Projektanfragen werden wir oft gefragt, was eine Umsetzung genau kosten und wie lange sie dauern wird. So verständlich und einfach die Frage ist, so schwierig ist sie zu beantworten. Denn es liegt in der Natur der Sache: Wenn mit einem Projekt etwas Neues, Anspruchsvolles, Ehrgeiziges geschaffen werden soll, ist der Weg dorthin mit Unwägbarkeiten gepflastert.

In der IT- und Softwareentwicklung kennt man dieses Problem seit jeher. Und nach unzähligen Versuchen, die optimale Planungsmethode zu entwickeln, hat man schließlich die Veränderung zum Prinzip erhoben: Die meisten erfolgreichen Softwareprojekte entstehen heute mittels agiler Arbeitsmethoden. 

Klassische Planung geht oft an der Realität vorbei

Um einen Festpreis kalkulieren zu können, muss ein Projekt zunächst vollständig geplant werden. Die sogenannte Wasserfallmethode zerlegt die Anforderungen in ihre Einzelteile, bringt alle Abhängigkeiten in eine zeitliche Abfolge, schätzt die Umsetzungszeiten der Teilaufgaben, verteilt die Zeiten auf die zuständigen Kolleg:innen und packt noch einen Sicherheitspuffer für Zeit und Budget obendrauf. Am Ende steht ein übersichtlicher Projektplan (meist ein Gantt-Diagramm) und eine darauf aufbauende Kalkulation. Alle haben ein gutes Gefühl, weil es einen verlässlichen und gewissenhaft erstellten Plan gibt. Soweit die Theorie. 

In der Praxis wird es dann allzu oft leider etwas komplizierter: 

• der Kunde formuliert nachträglich Änderungen an den ursprünglichen Anforderungen 

• es tauchen technische oder konzeptionelle Probleme auf 

• die organisatorischen Rahmenbedingungen des Projekts verändern sich, zum Beispiel, weil die Ansprechperson beim Kunden wechselt oder weil weitere Stakeholder ein Mitspracherecht einfordern 

• es greifen neue Regularien, beispielsweise durch Gesetzesänderungen oder geänderte interne Compliance-Vorgaben

• eingeplante Mitarbeiter:innen werden krank 

• es wurde mit Annahmen gearbeitet, die sich nun als falsch herausstellen  

• die Projektgruppe entwickelt neue Ideen, die die Anforderungen viel besser abdecken könnten 

• es gibt technologische Veränderungen (neue Browser, Betriebssysteme…), die berücksichtigt werden müssen 

An dieser Stelle kommt häufig der Einwand: "Diese Eventualitäten können wir ja alle benennen und ordentlich managen. Am Ende braucht es dann einen passenden Risikoaufschlag in der Planung – fertig. So arbeiten schließlich Unternehmen weltweit." 

Das stimmt: Die Praxis ist weit verbreitet. Aber ist sie deshalb auch sinnvoll? 

brainbits blickt auf über 20 Jahre Erfahrung in der Entwicklung von IT-Projekten zurück. Und auch wir sind jahrelang dem Wasserfallparadigma gefolgt – "Weil man es eben so macht!" Unsere Erfahrung: Es gibt Branchen und Projekte, bei denen eine Wasserfallplanung sinnvoll und verlässliche Prognosen möglich sind – die Software-Entwicklung gehört aber ganz sicher nicht dazu. Wir haben alle den Jahren praktisch kein Projekt gesehen, das dem aufgestellten Wasserfallplan tatsächlich gefolgt wäre. Ursache dafür waren in der Regel gleich mehrere der vorgenannten Unwägbarkeiten. 

Abgesehen davon kostet intensive Detailplanung vorab Zeit und Geld. So schrumpft das Entwicklungsbudget und das Datum der Einführung verschiebt sich nach hinten. Und steht der schöne Plan erst einmal, reicht eine einzige Verzögerung oder inhaltliche Veränderung und der gesamte Plan muss überarbeitet werden.

Aber andere Anbieter können Festpreis! Warum brainbits nicht? 

Wir wollen nicht unterschlagen, dass Wasserfall in der Softwareentwicklung dann möglich ist, wenn man zu einigen Zugeständnissen bereit ist: 

•  es wird viel Zeit und Geld in die Planung und Projektsteuerung investiert 

• der Funktionsumfang und die konkrete Umsetzung werden vor Aufnahme der Arbeiten festgeschrieben

• die Kalkulation beinhaltet einen sehr hohen Risikoaufschlag

All das zieht allerdings ungünstige Konsequenzen nach sich:

• der Entwicklungsstart verzögert sich durch die Planungsphase 

• der Kunde muss von Anfang an genau wissen, was er will. Nachjustieren im Projektverlauf ist nicht oder nur mit immensem Aufwand möglich, da alle Auswirkungen betrachtet und die gesamte Planung – inklusive Kostenplan – aktualisiert werden müssen! Und zwar bei jedem Änderungswunsch, da die Auswirkungen der Änderungen auf den ersten Blick meist gar nicht ersichtlich sind 

• im Zweifelsfall, spätestens wenn das Budget knapp wird, fällt die Stabilität und Gesamtqualität der Anwendung dem Druck der Entwicklung neuer Funktionen zum Opfer 

• es besteht ein hohes Risiko, dass das entwickelte Produkt bei Inbetriebnahme nicht mehr vollumfänglich nützlich ist 

Wir bei brainbits haben uns entschieden, dass wir diese Konsequenzen nicht tragen wollen. Deshalb bieten wir keine Festpreisprojekte an. 

Agiles Arbeiten

Agiles Arbeiten unterscheidet sich maßgeblich von den klassischen Methoden. Es betrachtet Veränderungen nicht mehr als unerwünschte "Störung", sondern rechnet fest mit ihnen und macht sie zum Prozessbestandteil. Dadurch wird das Vorgehen beweglicher – eben agiler. 

Es gibt unterschiedliche Frameworks für agiles Arbeiten. Bei der Entwicklung neuer Software-Produkte arbeiten wir nach der Scrum-Methode. Die wesentlichen Kriterien dieser Methode sind:

In Iterationen arbeiten

Aufgaben werden in wiederkehrenden Intervallen, den sogenannten Sprints, bearbeitet. Die Dauer jedes Sprints ist dabei immer gleich, variiert jedoch von Projekt zu Projekt und liegt in der Regel zwischen zwei und vier Wochen. Am Ende jedes Intervalls stellt das Entwicklungsteam dem Kunden eine funktionsfähige Software zur Verfügung, die untersucht und ausprobiert werden kann.

Aufgaben priorisieren

Alle Aufgaben werden fortwährend priorisiert. Die zentrale Fragestellung dabei ist: Welche Funktion bringt den meisten Nutzen – Geschäftswert (Business Value) – für die Software in ihrer aktuellen Ausbaustufe? Die Funktionen mit dem höchsten Business Value befinden sich an der Spitze der Liste. So definiert der Business Value unmittelbar, in welcher Reihenfolge die Aufgaben bearbeitet werden. Was sich nicht aktuell in der konkreten Umsetzung befindet, kann jederzeit neu priorisiert werden. 

Komplexität teilen

Je größer eine Aufgabe ist, desto mehr Unwägbarkeiten können sich in ihr verbergen. Daher wird jede Anforderung in überschaubare Teilaufgaben aufgeteilt. Jede dieser Aufgaben muss innerhalb eines Sprints vom Team abgeschlossen werden können und bereits Mehrwert zur Verfügung stellen.

Planungshorizont anpassen

Zu Beginn reicht es, die Anforderungen und Aufgaben grob zu erfassen, damit sie untereinander priorisiert werden können. Eine detaillierte Planung erfolgt immer erst kurz vor der eigentlichen Umsetzung. So können die aktuelle Situation und alle bisherigen Erkenntnisse berücksichtigt werden. Die Detailplanung übernehmen dieselben Entwickler:innen, die auch die Umsetzung verantworten.

Eigenverantwortung fördern und fordern

Es gibt bei Scrum keine Projektmanager:innen, die den Entwickler:innen sagen, wie sie eine Aufgabe erledigen sollen. Stattdessen werden Product Owner eingesetzt, die das Produkt und seine Vision sehr gut kennen. In enger Zusammenarbeit mit den Stakeholdern formulieren sie die Zielsetzung einer Aufgabe aus Nutzendensicht. Wie diese Anforderungen dann technisch am besten gelöst werden, liegt vollständig in der Verantwortung des Entwicklungsteams, denn dieses besitzt die notwendige Expertise. 

Minimal-Umsetzung anstreben

Mit zwei bis vier Wochen sind die Entwicklungszyklen bewusst kurzgehalten. Am Ende muss jeweils ein funktionales Ergebnis erreicht werden. Das Team konzentriert sich also darauf, die Anforderung mit möglichst geringem Aufwand und unter Einhaltung der definierten Qualitätskriterien zu erfüllen. Nicht mehr und nicht weniger. Soll das Ergebnis nach einer Prüfung noch um weitere Anforderungen erweitert werden? Dann entsteht dafür eine neue Aufgabe, die priorisiert und in einer der nächsten Iterationen umgesetzt wird. So reift das Produkt Schritt für Schritt. Die eingesetzte Entwicklungszeit wird bedarfsgerecht gesteuert.

Erfahrungen sammeln

Regelmäßig funktionierende Software-Bestandteile zu erhalten hat den Vorteil, dass die Software fortlaufend geprüft werden kann: Sind die Anforderungen ausreichend umfassend erfüllt? Funktioniert das Zusammenspiel der unterschiedlichen Komponenten? Ist die Nutzung für die Anwender intuitiv? Niemand muss bis zur endgültigen Fertigstellung des Produkts warten, um erste Erkenntnisse aus der (Teil-)Umsetzung zu ziehen. Und diese Erkenntnisse fließen in Form von neuen oder angepassten Anforderungen und veränderten Prioritäten unmittelbar in den Entwicklungsprozess ein.

Transparenz schaffen

Bei allen Arbeitsschritten ist die Transparenz das A und O. Es gibt festgelegte Termine definierter Dauer, in denen alles Relevante rund um das Projekt angesprochen und somit frühestmöglich bekannt wird. Probleme bei einer Umsetzung, neue Ideen für ein Vorgehen, Rückfragen zu einer Aufgabenstellung, alles kommt zeitnah auf den Tisch und wird besprochen. 

Der Kunde ist dabei stets unmittelbar beteiligt: Am Ende jeden Sprints trifft er sich mit dem Entwicklungsteam, bekommt die Ergebnisse präsentiert und kann direkt Feedback geben. Anschließend werden die Etappenziele für den nächsten Sprint gemeinsam abgestimmt. 

Bei brainbits erhalten unsere Kunden außerdem Zugriff auf ein Ticketsystem. Darin können sie den Status der Aufgaben und auch den angefallenen Arbeitsaufwand in Echtzeit verfolgen. 

Agiles Arbeiten ist dynamisch und energetisch. Es fordert ein hohes Commitment und uneingeschränktes Engagement von allen Beteiligten. Und genau das ist es, was diese Methode so effektiv macht.

Wie ermittele ich, ob ich mir die Software leisten kann? 

Agile Projekte arbeiten nicht mit einem Projektfestpreis. Zu viel kann und wird sich ändern; eine ganz konkrete Vorstellung und Planung existiert jeweils nur für das nächste Entwicklungsintervall. Aber natürlich beraten wir unsere Kunden bei der Budgetplanung und liefern eine grobe Aufwandsindikation für jedes Vorhaben. 

Grundlage hierfür ist der sogenannte MVP-Workshop. Das MVP (Minimum Viable Product) beschreibt dabei die kleinste Ausbaustufe des Produkts, in dem es sinnvoll nutzbar ist und Geschäftswert generiert. Im Rahmen des Workshops entsteht in Zusammenarbeit zwischen dem Kunden, dem Product Owner und dem Entwicklungsteam eine gemeinsame, allerdings noch recht grobe Vorstellung des zukünftigen Produkts. 

Sie ist Grundlage für die Ermittlung diverser Eckdaten, wie sinnvolle Teamgröße, benötigte Rollen und Kosten für den Betrieb der voraussichtlich benötigten Infrastruktur. Mit Hilfe dieser Parameter ermitteln wir eine Schätzung für die durchschnittlichen Kosten pro Entwicklungsmonat. 

Schließlich schätzt das Entwicklungsteam die ungefähre Entwicklungsdauer der im MVP- Workshop identifizierten Produktmodule. Aus der Multiplikation der monatlichen Kosten mit der Entwicklungsdauer ergibt sich die Budgetschätzung bis zum MVP. 

Häufig sind individuell entwickelte Software-Produkte geschäftskritische Anwendungen, die für den Betrieb eines Unternehmens unabdingbar sind. Spätestens dann muss die kontinuierliche Weiterentwicklung und Pflege der Software in der Abschätzung der Total Cost Of Ownership berücksichtigt werden. Auch hier unterstützen wir Dich bei der Ermittlung entsprechender Planwerte.

Mehr Kontrolle und effiziente Investitionen 

Beim klassischen Festpreismodell wird der Anbieter immer versuchen, den Einfluss des Kunden zu minimieren, um seine Kalkulation zu sichern. Im schlimmsten Fall bedeutet das, dass nach Monaten oder Jahren Entwicklungszeit eine Software geliefert wird, die die aktuellen Anforderungen nicht (mehr) erfüllt. 

Agile Softwareprojekte kehren dieses Missverhältnis um und stellen den Nutzen in den Mittelpunkt. Von Anfang an wird in lauffähige Software investiert, die getestet und auf ihre Verwendbarkeit und ihren Nutzen hin überprüft werden kann. Die dabei gewonnenen Erkenntnisse fließen unmittelbar in die weitere Entwicklung ein, um sicherzustellen, dass diese zu jedem Zeitpunkt am tatsächlichen Bedarf ausgerichtet ist. So entsteht nach und nach ein Produkt, das frühestmöglich den maximalen Nutzen zu den geringsten Kosten liefert.

Noch unsicher? 

Du bist Dir noch unsicher, ob agile Entwicklung auch für Dein Projekt geeignet ist? Lass uns unverbindlich darüber sprechen und es gemeinsam herausfinden - auch wenn Du bisher noch keine Berührungspunkte mit agilen Vorgehensweisen hattest!