Was kostet Individual Softwareentwicklung? Der Kostenrahmen als Basis weiterer Anforderungsanalysen.

Wie viel kostet es, eine Software entwickeln zu lassen? Für viele Entscheider in Unternehmen ist die Entwicklung einer Individualsoftware ein einmaliges Projekt. Entsprechend groß ist die Unsicherheit in der Budgetplanung. Die Komplexität und Abstraktheit einer Individualsoftwareentwicklung erschwert zudem die Kostenplanung. Je nach Anforderungen an den Funktionsumfang der Software können die Kosten stark variieren. Das macht bereits die Kostenschätzung von Softwareprojekten zu einer komplexen Aufgabe. Die jedoch unter Anwendung bestimmter Techniken und Herangehensweisen zu belastbaren Schätzungen mit geringer Schwankungsbreite führt.

Zu einem sehr frühen Zeitpunkt, meist noch bevor das Projekt angeboten wurde, spricht man über Größenordnungen, die eine Umsetzung kosten kann. Der Abgleich der gegenseitigen Erwartungshaltung in dieser Projektphase ist sehr wichtig für den weiteren positiven Verlauf der Zusammenarbeit. Guid.New setzt auf offene, frühzeitige und ehrliche Tatsachenkommunikation. Einer der kritischen Punkte ist der initiale Kostenrahmen.

Ziel des Kostenrahmens ist es, basierend auf groben Anforderungen einen ebenso groben Kostenumfang kommunizieren zu können. Das ist so früh im Projekt mit entsprechend hoher Unsicherheit und Schwankungsbreite verbunden. Dieser Unsicherheit wird mit folgenden Maßnahmen Rechnung getragen:

• Das Konzept des Cone of Uncertainty wird vorgestellt und erklärt. Es zeigt auf, in welchen Stadien übliche Schwankungsbreiten liegen, wie zu genaueren Aussagen gelangt wird und wieviel Aufwand das benötigt.
• Kosten werden in Von-Bis Spannweiten kommuniziert. Das entspricht dem Cone of Uncertainty mit einer Schwankungsbreite und vermeidet den Eindruck von Scheingenauigkeit.
• Kosten werden gerundet kommuniziert. Es wird in einer Größenordnung gerundet, die dem Gesamtumfang gerecht wird (auf tausend Euro, auf zehntausend Euro, etc.). Auch das vermeidet den Eindruck von Scheingenauigkeit.
• Der Kostenrahmen ist unverbindlich

Meaningful commitments are not possible in the early, wide part of the Cone. Effective organizations delay their commitments until they have done the work to force the Cone to narrow. Meaningful commitments in the early-middle part of the project (about 30% of the way in) are possible and appropriate.

— Steve McConnell – Software Estimation, Best Practices, 2006, p. 40

Schritt 1: Top-Down Schätzung

Eine erste Einschätzung erfolgt Top-Down. Zum einen wird basierend auf abgewickelten Projekten und deren Aufwänden durch Analogie zu einer Einschätzung gelangt. Diese Einschätzung hängt hochgradig von der individuellen Projekterfahrung und dem Einblick in Eigenschaften vergangener Projekte der schätzenden Personen ab, genauer als ein „mehr als Projekt X, weniger als Projekt Y“ wird als Resultat kaum erzielt.

Zum anderen kann die Abschätzung als Fermi-Problem betrachtet werden und basierend auf Rahmenbedingungen des zu lösenden Problems indirekt zu einem möglichen Resultat führen.

Die Top-Down Schätzung dient zur Verifikation der darauffolgenden, detaillierteren, aber auch aufwändigeren Bottom-Up Schätzung.

Schritt 2: Bottom-Up Schätzung

Für die Bottom-Up Schätzung wird die Software in Anforderungen auf hoher Abstraktionsebene (Epics) zerteilt. Die Epics finden Einzug in den Kostenrahmen als Eckpunkte und Abgrenzung der umzusetzenden Funktionalität.

Auf die Epics wird ein an Breitband-Delphi und Planning Poker angelehntes Schätzverfahren angewendet. Dabei nähert man sich iterativ über mehrere Runden durch unabhängiges Schätzen von mehreren Personen aus dem jeweiligen Fachbereich einem Zielwert an. Das läuft in der Praxis wie folgt ab: Ein Kollege erklärt den Epic, die anderen Kollegen stellen Fragen und der Umfang wird kurz diskutiert. Jeder denkt sich eine Zahl in Personentagen aus, sobald jeder eine Zahl hat wird diese genannt. Um der wachsenden Unsicherheit bei größer werdenden Epics gerecht zu werden, wird basierend auf einer exponentiellen Skala (z.B. in der Fibonacci-Sequenz) geschätzt. Da in Personentagen und nicht in relative Größen geschätzt wird, geht es mehr um den exponentiellen Character als um eine fest definierte Skala.

Sind die Werte nahe beieinanderliegend, ist die Schätzrunde abgeschlossen. Gehen die Schätzungen auseinander, wird erneut diskutiert.

Schritt 3: Querschnittsthemen

Basierend auf Erfahrungswerten aus Vorprojekten werden verschiedene, das gesamte Projekt betreffende, Thematiken berücksichtigt. Diese teilen sich in funktionale Querschnittsthemen, Themen der Projektabwicklung und Themen der Projektumwelt.

• Funktionale Querschnittsthemen ziehen sich durch die gesamten Funktionalitäten der Anwendung im Querschnitt. z.B. benötigte Unterstützung für viele verschiedene Endgerätetypen oder Browser, hohe Securityanforderungen, …
• Die Projektabwicklung betrifft Thematiken der Projektabwicklung, also Scrum Meetings, Aufwände des Product Owners, Aufwände für System- und Integrationstests, …
• Die Projektumwelt betrifft zum einen die interne Projektumwelt, z.B. Aufwände in Presales, Risiko für Gewährleistung und Schätzung, …, zum anderen die externe Projektumwelt die im Projekt zu höherer Komplexität führt wie z.B. Erweiterung eines bestehenden Systems, Einbindung in eine komplexe Infrastruktur, viele Stakeholder mit verschiedenen Vorstellungen, etc.

Schritt 4: Schätzgenauigkeit

Je geschätztem Epic wird die geringste Schätzung als Bestcase und die höchste Schätzung als Worstcase herangezogen. Die individuelle Standardabweichung wird durch [(Best – Worst) / Konfidenzdivisor] bestimmt. Derzeit wird mit einem Konfidenzdivisor von 2.1 gerechnet, der einer Konfidenz von 70% entspricht. Studien haben gezeigt, dass der menschlich intuitive Sinn von „90% Zuverlässig“ in Wirklichkeit eher einem „30% Zuverlässig“ entspricht. Mit guter Übung in einem bekannten Feld (in unserem Fall Geschäftsanwendungen im .NET/Angular Technologiestack) ist ein Wert von 70% möglich.

Die Varianzen der Epics werden summiert und daraus die Wurzel für eine Standardabweichung der Gesamtschätzung gezogen.

Hintergründe, die die Zuverlässigkeit dieses Verfahrens für Bottom-Up-Schätzung basierend auf ein oder mehr Teilschätzungen (Epicschätzungen) erläutern, sind in Software Estimation, Best Practices, Steve McConnell, 2006, p. 124 ausführlich beschrieben.

Basis für weitere Anforderungsanalyse

Ein Kostenrahmen ist ein guter Schritt für eine weitere Anforderungsanalyse. Der bisherige Bekanntheits- und Zusammenarbeitgrad mit dem Kunden, in dem Projekt(umfeld), in der Kundendomäne, etc. beeinflusst, wie viel mit dem Kunden gemeinsam in Anforderungsanalyse investiert werden soll, um genügend Vertrauen für eine verbindliche Abschätzung bei Geschäftsanwendungsprojekten in unserem Technologiestack zu haben. Von den oben genannten 30% eines „meaningful commitments“ kann so der Aufwand auf 20% oder gar 10% gedrückt werden.

Damit ist eine Aussage von „Ihre App wird 60.000 – 180.000 Euro kosten und als nächsten Schritt benötigen wir, um auf Wunsch ein Fixpreisangebot legen zu können, einen Designsprint im Umfang von 12.000 – 36.000 Euro“ seriös fundiert in einer sehr frühen Phase (vor) dem Projekt möglich.

Vergleich zum Agilen Festpreis

Der Agile Festpreis ist ein Vertragsmodell, in dem nach einer initialen Testphase Kosten und Termine festgesetzt werden und ein Vorgehen zur Steuerung des Umfangs vereinbart wird. Dabei wird in einer von mehreren Phasen ein Referenz-Epic in UserStories zerteilt, mit Story Points beschätzt und als Proxy für das Gesamtprojekt als indikativer Kostenrahmen verwendet.

Guid.New glaubt, durch die technologische (Angular, WebAPI, Azure) und inhaltliche (Geschäftsanwendung) Ähnlichkeit ihrer Projekte rein auf Epics-Basis eine Grobaussage ohne Referenz-Userstories treffen zu können. Weiterhin ist der Anwendungsbereich als unverbindlichen Kostenrahmen in einer noch früheren Phase, in der initialen Geschäftsanbahnung zum Abgleich der grundsätzlichen Erwartungshaltungen, ein anderer.

Vergleich zu Agile Schätzmethoden in Sprints

Die agile Schätzung auf User Stories bedingt die Ausarbeitung von User Stories. Diese werden üblicherweise innerhalb des Projektes ausgearbeitet und beschätzt für zukünftige Sprints. Zum Zeitpunkt des Kostenrahmens steht das Team meist noch nicht fest. Oft steht überhaupt noch sehr wenig fest. Oft hat der Kostenrahmen selbst Einfluss darauf ob, wann und in welchem Umfang das Projekt umgesetzt wird. Daher wird einer weniger analyseintensiven (entsprechend ungenaueren) Methode in dieser Phase der Vorzug gegeben.

Fazit

Häufig besteht kundenseitig wenig oder keine Erfahrung bei der Formulierung von Anforderungen an ein zukünftiges Softwareprojekt. Um Unsicherheiten in der frühen Projektphase abzubauen, setzt Guid.New auf eine strukturierte und erprobte Vorgehensweise in der Ermittlung des Kostenrahmens.