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. Wir bei Guid.New sind Freunde von offener, frühzeitiger und ehrlicher 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 und Schwankungsbreite wird mit folgenden Maßnahmen Rechnung getragen:

Das Konzept des Cone of Uncertainty wird vorgestellt und erklärt. Wir zeigen auf, in welchen Stadien übliche Schwankungsbreiten liegen, wie wir zu genaueren Aussagen gelangen werden, 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

(Quelle: http://www.agilenutshell.com/cone_of_uncertainty)

Schritt 1: Top-Down Schätzung

Eine erste Einschätzung erfolgt Top-Down. Zum einen gelangen wird basierend auf abgewickelten Projekten und deren Aufwänden durch Analogie zu einer Einschätzung. 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 man die Abschätzung als Fermi-Problem betrachten und basierend auf Rahmenbedingungen des zu lösenden Problems indirekt zu einem möglichen Resultat kommen.

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

Schritt 2: Buttom-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 wenden wir ein an Breitband-Delphi und Planning Poker angelehntes Schätzverfahren an. 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 bei uns in der Praxis wie folgt ab: Kollege A erklärt den Epic, die anderen Kollegen stellen Fragen und der Umfang wird kurz diskutiert. Jeder denkt sich eine Zahl in Personentagen, sobald jeder sagt er hat eine Zahl wird die Zahl 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 wir in Personentagen und nicht in relative Größen schätzen 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 berücksichtigen wir verschiedene, das gesamte Projekt betreffende, Thematiken. Diese teilen sich in funktionale Querschnittsthemen, Themen der Projektabwicklung und Themen der Projektumwelt.

Funkionale 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 ] bestimmen. Derzeit rechnen wir mit einem Konfidenzdivisor von 2.1, 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“ [Zultner 1999, Jorgensen 2004] entspricht. Mit guter Übung in einem bekannten Feld (in unserem Fall Geschäftsanwendungen im .NET/Angular Technologiestack) ist ein Wert von 70% möglich.
Wir summieren die Varianzen der Epics und ziehen daraus die Wurzel für eine Standardabweichung der Gesamtschätzung.

Hintergründe die die Zuverlässigen 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 wir mit dem Kunden gemeinsam in Anforderungsanalyse investieren möchten 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 Steuern 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.

Wir glauben, durch die technologische (Angular, WebAPI, Azure) und inhaltliche (Geschäftsanwendung) Ähnlichkeit unserer Projekte rein auf Epics-Basis eine Grobaussage ohne Referenz-Userstories treffen zu können. Weiters 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 arbeiten wir üblicherweise innerhalb des Projektes aus und beschätzen diese 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 geben wir einer weniger analyseintensiven (entsprechend ungenaueren) Methode in dieser Phase den Vorzug.

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, setzen wir bei Guid.New auf eine strukturierte und erprobte Vorgehensweise in der Ermittlung des Kostenrahmens.