„Was kostet das Projekt?“

Bei neuen Projektanfragen werden wir häufig gebeten zu ermitteln, was eine Umsetzung genau kosten wird und wie lange es dauern wird. So nachvollziehbar und einfach die Frage ist, so schwierig ist sie zu beantworten. Denn es liegt in der Natur der Sache: wenn ein Projekt dazu dient, etwas Neues, Anspruchsvolles, Ambitioniertes zu erschaffen, ist der Weg mit Unwägbarkeiten gepflastert.

In der IT und Software-Entwicklung 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 Software-Projekte entstehen heute durch agile Arbeitsweisen.

Klassische Planung geht oft an der Realität vorbei

Um einen Festpreis berechnen zu können, muss man ein Projekt zuvor vollständig durchplanen. 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 Kollegen und packt für Zeit und Budget noch einen Sicherheitspuffer obendrauf. Am Ende hat man einen übersichtlichen Projektplan (meist ein Gantt-Diagramm) und eine darauf beruhende Kalkulation. Alle fühlen sich gut, weil es einen verlässlichen und gewissenhaft durchgeführten 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 der Ansprechpartner beim Kunden wechselt oder weil weitere Stakeholder ein Mitspracherecht einfordern.;

  • Es greifen neue Regularien, beispielsweise durch Gesetzesänderungen oder neue 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 Risiko-Aufschlag 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 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 in all 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.

Je größer also ein Projekt, desto unwahrscheinlicher ist es, dass vorab alles durchdacht und geplant werden kann und desto wahrscheinlicher ist es, dass Ereignisse eintreten werden, die eine Planänderung erforderlich machen.

Abgesehen davon kostet intensive Detailplanung vorab viel 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 Software-Entwicklung 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 berücksichtigt 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, aber 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 und bieten daher 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 gegeneinander 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 Entwicklern 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 Nutzersicht. 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 geringst möglichem 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 mit 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 direkt 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 die Kunden außerdem Zugriff auf unser Ticketsystem. Darin können sie den Status der Aufgaben und die angefallenen Stunden 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 Budget-Planung 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 des Total-Cost-Of-Ownerships berücksichtigt werden. Auch hier unterstützen wir Sie 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 Software-Projekte 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?

Sie sind sich noch unsicher, ob agile Entwicklung auch für Ihr Vorhaben geeignet ist? Nutzen Sie unser Workshop-Angebot „Agile Kick-Off – das optimale Setup für Ihr agiles Software-Projekt“. Lernen Sie die Grundlagen der agilen Vorgehensweise kennen, stellen Sie alle Fragen zu den agilen Methoden und erarbeiten Sie mit uns gemeinsam, wie Ihr agiles Projekt-Setup aussehen könnte. Vereinbaren Sie ein unverbindliches telefonisches Kennenlernen.