Business Technology 06/11

Business Value trotz Festpreis

Autor:

Viele Projekte scheitern und erzielen nicht den erhofften Business Value. Gerade bei Festpreisprojekten besteht die Gefahr, dass die Festlegung auf Zeit, Kosten und Inhalt dazu führt, die Qualität, Kundenzufriedenheit und den Geschäftswert aus den Augen zu verlieren. Nach Meinung des Autors kann nur durch einen flexiblen Umgang mit dem Inhalt der Business Value eines Projekts maximiert werden – trotz festem Preis.

Individualsoftware zu bauen ist komplex, bietet aber auch das größte Potenzial, hohen Geschäftswert zu erzeugen. Unternehmen können damit Wettbewerbsvorteile realisieren, wenn die neu entwickelte Software beispielsweise Geschäftsprozesse effizienter umsetzt als die Mitbewerber oder ein ganz neues Produkt im Markt positioniert werden kann. Hierbei handelt es ich um einen echten Geschäftswert, weil das Unternehmen mithilfe der Software entweder günstiger produzieren kann oder ein Alleinstellungsmerkmal hat, das zu höheren oder stabilen Preisen führt. In der Vergangenheit haben wir uns als IT allerdings einen schlechten Ruf erarbeitet, da solche Projekte oft scheitern oder zumindest nicht den erhofften Geschäftswert erzielen. Mit dem Modell des „Festpreisprojekts“ sollte das Risiko für den Kunden minimiert werden, allerdings mit geringem Erfolg. Grund hierfür ist der falsche Fokus dieser Projekte. Das grundsätzliche Problem mit Festpreisprojekten ist, dass in den meisten Fällen eben nicht nur der Preis festgeschrieben wird, sondern auch Inhalt und Termin. Das wird im Projektmanagement gerne auch „Magisches Dreieck“ genannt. Das Management dieser drei Zielgrößen führt in klassischen Festpreisprojekten dazu, dass eben nicht mehr der Geschäftswert im Fokus des Projekts steht:

  • Das „Change Management“ beschäftigt sich mit der inhaltlichen Abgrenzung des Projekts. Der Kunde soll genau das erhalten, was er im Pflichtenheft aufgeschrieben hat. Abweichungen von dieser „Baseline“ werden als Änderung erfasst und weichen somit vom Umfang des Festpreisprojekts ab. Je später solche Änderungen im Projektverlauf eingestellt werden, desto teuerer ist in der Regel deren Umsetzung. Viele Kalkulationen von Festpreisen gehen schon beim Angebot davon aus, dass das Projekt nur über die Änderungen profitabel wird. Oft werden Änderungen deshalb auch vom Kunden nicht beauftragt, mit der Konsequenz, dass weniger Geschäftswert erzeugt wird oder teilweise sogar keiner, weil nicht die Software gebaut wird, die der Kunde benötigt, sondern die, die zu Beginn des Projekts spezifiziert wurde.
  • Die Qualität und insbesondere die nicht funktionalen Anforderungen werden in Projekten meist nur rudimentär oder zu ungenau spezifiziert. Ein typisches Beispiel hierfür ist, dass gerne gesagt wird, dass eine Anwendung schnell und sicher sein soll. Leider ist „schnell“ keine feste Größe, sodass beispielsweise die Antwortzeit einer Webanwendung von acht Sekunden Sekunden vom Dienstleister gerne als schnell definiert wird, während der Kunde die Anwendung als langsam empfindet. Diskussionen und Streitigkeiten sind dann vorprogrammiert. Die Wartbarkeit einer Software lässt sich zudem sehr schwer spezifizieren und messen. Aber gerade in der Wartung fallen bis zu 90 Prozent der Kosten einer Software über den Lebenszyklus an, d. h. der Kunde merkt oft erst sehr spät, ob er gute Qualität erhalten hat oder nicht. Aus diesem Grund fällt gute Wartbarkeit einer Software dem Zeitdruck im Projekt zum Opfer.
  • Die Kundenzufriedenheit spielt in klassischen Projekten kaum eine Rolle. Gerade der Anwender wird häufig nicht oder erst sehr spät in die Entwicklung einer Software eingebunden. Durch ein klassisches „Wasserfall“-Vorgehen ist ein Feedback auf Basis funktionierender Software auch schwierig, weil die Implementierungsphase erst sehr spät im Prozess beendet wird. Wird dann festgestellt, dass der Anwender die Software anders benutzt als erwartet, führt das zu Änderungen, die durch den späten Zeitpunkt des Anwendertests nur mit hohen Aufwänden umgesetzt werden können. Oft werden die Anwender aber auch erst mit einbezogen, wenn Sie die fertige Software benutzen sollen.

Lösungsideen für die stärkere Fokussierung auf den Geschäftswert findet man in der agilen Softwareentwicklung. Schon das Agile Manifest setzt den Fokus auf funktionierende Software, Zusammenarbeit mit dem Kunden und Reagieren auf Veränderung. Damit sich diese Werte in den Zielen eines Festpreisprojekts wiederfinden, erweitern wir das Magische Dreieck um drei weitere Kerngrößen: Kundenzufriedenheit, Geschäftswert und Qualität.

Die Erweiterung des Magischen Dreiecks mit den Faktoren Zeit, Kosten und Inhalt um die drei neuen Kennzahlen zu einem „Magischen Sechseck“ führt dazu, dass Projekte weniger „plangetrieben sind“ und mehr „wertgetrieben“ umgesetzt werden. Für ein Festpreisprojekt bedeutet das allerdings, dass man einen Kompromiss eingehen muss, denn man kann nicht alle sechs Größen in einem Projekt fest vorgeben. Der hier vorgeschlagene Ansatz, der im Übrigen auch von den meisten agilen Ansätzen so gewählt wird, beruht darauf, dass man den Inhalt eines Projekts nicht konkret fixiert. Auf den ersten Blick hört sich das nicht praktikabel an, ist aber nach Meinung des Autors der einzig ehrliche und funktionierende Ansatz, um die anderen fünf Zielgrößen optimal zu bedienen. Die Diskussion soll mit drei Thesen starten, die in der Softwareentwicklung schon lange Bestand haben, aber sehr häufig nicht berücksichtigt werden:

  • „For a new software system, the requirements will not be completely known until after the users have used it.“ [1]
  • „Uncertainty is inherent and inevitable in software development processes and products.“ [2]
  • „An interactive system can never be fully specified nor can it ever be fully tested.“ [3]

Jeder, der schon einmal in Softwareprojekten gearbeitet hat, kann diese wissenschaftlichen Thesen in der Praxis bestätigen: Man kann in einem überschaubaren Aufwand keine Software zu 100 Prozent spezifizieren: Gesetze und Vorschriften ändern sich, neue Technologien und Produkte werden verfügbar, Menschen haben neue Ideen und Meinungen, Dinge, die auf dem Papier gut ausgesehen haben, stellen sich in der laufenden Software als nicht wirklich benutzerfreundlich dar oder man hat schlichtweg etwas falsch verstanden oder vergessen zu dokumentieren.

Trotzdem werden die meisten Softwareprojekte, insbesondere die auf Festpreis basierenden, immer noch nach dem Wasserfallmodell implementiert und auf Basis des magischen Dreiecks geführt. Winston Royce, der die erste formale Beschreibung des Wasserfallmodells im Jahr 1970 veröffentlicht hat [4], beschreibt in seinem Artikel bereits die Probleme dieser Vorgehensweise, an die er „zwar glaubt, aber die riskant ist und zu Fehlern einlädt“. Er beschreibt in seiner Veröffentlichung, dass Änderungen zu einem späten Zeitpunkt in der Regel elementare Änderungen am Design haben können und man dann mit 100 Prozent mehr Aufwand und Kosten rechnen muss. Seine Aussage zeigt eindrücklich, welche Gefahr ein Festpreisprojekt birgt, wenn man den Inhalt schon zu Beginn des Projekts spezifiziert und den Inhalt der Spezifikation (Pflichtenheft) als Basis für den Vertrag zwischen Kunden und Dienstleister nimmt.

Ein weiterer Punkt ist nicht nur das hohe Risiko bei späten Änderungen an der ursprünglichen Definition der Anforderungen, sondern auch, dass die Anforderungen nicht den Bedürfnissen der Anwender entsprechen. Die Standish Group hat in ihrer Studie „CHAOS Report 2009“ herausgefunden, dass 45 Prozent der Funktionen einer Software nie benutzt werden. 20 Prozent werden sehr selten und 16 Prozent manchmal benutzt. Nur 20 Prozent der Funktionen einer Software werden laut dieser Studie immer oder oft genutzt. Das bedeutet im Umkehrschluss auch, dass 80 Prozent der erstellten Software keinen Business Value erzeugen. Das ist ein Resultat aus der Befolgung eines Plans und der fehlenden Fokussierung auf den Geschäftswert. Das Ziel in Projekten sollte es daher sein, den Anteil der Software, der Geschäftswert erzeugt, deutlich zu erhöhen. Folgt man den obigen Thesen und den daraus resultierenden Problemen in Festpreisen, dann wird klar, dass man das nur über den Inhalt machen kann. Man muss akzeptieren, dass man komplexe Anwendungen nicht vollständig spezifizieren und deshalb die Ermittlung der Anforderungen nur gemeinsam und empirisch mit den Stakeholdern durchführen kann.

Das magische Sechseck

Konkret bedeutet das, dass man kurze Feedbackschleifen in das Projekt einbauen muss, um die Komplexität von Softwareprojekten beherrschen zu können und das Risiko zu minimieren. Nach Humphrey kann dieses Feedback aber nur auf Basis lauffähiger Software erfolgen, da erst beim Benutzen des Systems Anforderungen validiert werden können. Das bedeutet, dass man die Software auf Basis eines iterativen und inkrementellen Prozesses umsetzen muss, damit die Anwender das notwendige Feedback geben können. Die Kombination iterativer und inkrementeller Ansätze führt zu einem Entwicklungsprozess, der Softwarein kleinen, funktionalen Einheiten (Inkremente), in sich wiederholenden Zyklen (Iterationen) ausliefert. Die Länge der Iteration sollte dabei vier Wochen nicht überschreiten. Das verkürzt die Dauer für die Rückmeldung, limitiert aber auch das Risiko auf den Inhalt eines Monats.

Ein Projekt startet deshalb am besten mit einer Untermenge der zu Beginn bekannten Systemanforderungen und implementiert ein einfaches und ausbaufähiges erstes Inkrement. Auf diese Weise steigt das Wissen über die sinnvollen Anforderungen an das System mit jeder Iteration, und dieses Wissen kann in die Planung der nächsten Inkremente einfließen. Für die Auswahl der Funktionen, die in das nächste Inkrement einfließen, sollten der Business Value und das Risiko als Priorisierung herangezogen werden. Das bedeutet, dass immer die Funktionen als Nächstes umgesetzt werden sollten, die am meisten Nutzen für den Kunden liefern oder das höchste Risiko für das Projekt bedeuten, sodass diese frühzeitig im Projekt evaluiert werden können.

In diesem Artikel wird absichtlich nicht der Einsatz agiler Vorgehensmodelle wie Scrum oder XP fokussiert, denn nicht nur agile, sondern auch klassische Vorgehensmodelle wie der Rational Unified Process oder das V-Modell erlauben ein iteratives und inkrementelles Vorgehen und können damit die Basis für einen solchen Business-Value-fokussierten Ansatz sein. Wichtig ist allerdings noch zu erwähnen, dass für die Umsetzung in der Praxis sowohl handwerkliche Fertigkeiten benötigt werden, um Software in kurzen Iterationen von maximal vier Wochen ausliefern zu können, als auch spezielle Praktiken für das Planen und Schätzen des Projekts. Gerade die klassischen Vorgehensmodelle vernachlässigen das Softwareentwicklungs-„ Handwerk“, was nach Meinung des Autors einer der Gründe ist, warum RUP und das V-Modell meistens in ihrer Wasserfallausprägung eingesetzt werden. Der Umgang mit evolutionären Architekturen, die es ermöglichen, auf Änderungen gut zu reagieren, ein hoher Automatisierungsgrad aller Teststufen, die kontinuierliche Integration der Anwendung und der professionelle Umgang mit Code sind Beispiele für Praktiken, die ein Entwicklungsteam kennen und beherrschen muss, damit eine iterative, inkrementelle Entwicklung funktionieren kann.

Bei Festpreisen ist aber weiterhin das Planen und Schätzen ein wichtiger Bestandteil, um Zeit und Kosten zu Beginn eines Projekts gut vorhersagen zu können. Auch hier kann man sich agiler Praktiken bedienen, die beispielsweise Mike Cohn in seinem Buch [5] über das Planen und Schätzen in agilen Projekten beschreibt. Wichtig dabei ist, dass sowohl Planung als auch Schätzung wertorientiert ausgerichtet sein müssen und mit der Ungenauigkeit im Umfang des Projekts umgehen können – sprich, kurzfristig detailliert und langfristig grobgranular sind.

Fazit

Den Geschäftswert in Projekten und insbesondere in Festpreisprojekten zu optimieren bedeutet, den Fokus auf den Inhalt des Projekts zu reduzieren und neben Zeit und Kosten auch Qualität, Kundenzufriedenheit und den Geschäftswert als wichtige Kennzahlen zur Steuerung eines Projekts aufzunehmen. Iterative, inkrementelle Vorgehensmodelle helfen, die Feedbackzyklen der Stakeholder zu reduzieren und die Erfahrung mit der erstellten Software in die Weiterentwicklung einfließen zu lassen. So passt sich der Inhalt des Projekts an den tatsächlichen Bedarf des Kunden an. Grundlage dafür ist aber Vertrauen zwischen Kunde und Dienstleister, denn nur so kann die Ungewissheit über den Inhalt eines Projekts bei einem Festpreis überbrückt werden. Hat man dieses Vertrauen nicht, sollte man auch keinen Festpreis verhandeln, denn dann wird der Geschäftswert ins Hintertreffen geraten.

Links & Literatur

[1] A Discipline for Software Engineering, Watts S Humphrey, 1995

[2] T he Uncertainty Principle in Software Engineering, Hadar Ziv u.a.: http://www.ics.uci.edu/~ziv/papers/icse97.ps

[3] T he Paradigm Shift from Algorithm to Interaction, Peter Wegner: http://www.cs.brown.edu/people/pw/papers/ficacm.ps

[4] Managing the Development of Large Software Systems, Winston Royce: http://www.cs.umd.edu/class/spring2003/ cmsc838p/Process/waterfall.pdf

[5] Agile Estimating and Planning, Mike Cohn, 2005

Vollständiger Artikel