Kosten und Aufwände


Zusammenfassung
Controlling
Exkurs: Von Schlössern und geometrischen Figuren
Wie lange dauert es, bis die Anforderungsanalyse fertig ist? Wieviel kostet das fertige Software-Produkt?
Wie ermittelt man, ob ein gewünschtes Feature implementiert werden soll?
Ein unvermeidlicher Zwischenruf: Prozess-Modelle in der Praxis


Zusammenfassung

In diesem Kapitel wird zunächst auf die grundsetzlichen Fragen des Controlling im Rahmen von Software-Entwicklungs-Projekten eingegangen. Dabei wird auch ein praxisbewährtes Vorgehensmodell vorgestellt, das auf Basis eines Vorprojekt/Hauptprojekt-Prinzips einen seriösen Ansatz für IT-gerechte Projektplanung vorschlägt. Bei der Betrachtung der Anwendung bzw. Nicht-Anwendung von Prozessmodellen in der Praxis wird in erster Linie auf das Scheitern von Software-Projekten und die dadurch verursachten Kosten eingegangen. Abschließend wird ein Ansatz vorgestellt, mit dem bei vorgegebenen Budget und Liefertermin, ohne das geforderte Leistungsspektrum des Systems zu kennen, eine Projektplanung und Durchführung möglich ist. Nebenbei wird noch dargestellt, auf welche Weise eine Abschätzung über die Notwendigkeit der Implementierung spezifischer Produktfeatures vorgenommen werden kann.

Controlling

Als Business Analyst bewegt man sich fernab des Controlling. Durch die relative Unkontrollierbarkeit des häufig erst während der Analysephase dynamisch entstehenden Aufwandes für die Analyse selbst kommt es allerdings nicht selten zu Konflikten zwischen der Kaste der Erbsenzähler (wie sie gerne von IT-Leuten genannt werden) und dem Analytiker bzw. der mit ihm arbeitenden Fachanwender. Innerhalb eines IT-Projekts obliegt dem Projektmanager die Projektüberwachung. Ungeachtet dessen sollte jeder Projektmitarbeiter im Auge behalten, dass sein Arbeitsplatz nur dann erhalten bleibt, wenn der Ertrag größer als der Aufwand ist. Das Gehalt bzw. die Rechnung wird vom Kunden bezahlt, nicht vom Chef. Für einen Analytiker kann das Controlling ein wichtiger Verbündeter sein, denn häufig kann nur durch die konsequente Termin- und Budgetüberwachung für die Wünsche der Fachabteilung eine konkrete Priorisierung und Beschränkung auf das Machbare erreicht werden.

Dem Controlling unterliegen vier Gebiete:
Man stolpert dabei über Schlagworte wie Planungsschleifen oder Meilenstein-Trendanalyse. Ziel ist, dass die vorgegebenen Rahmenbedingungen eingehalten werden. Fängt ein Meilenstein an, aus der Planung "heraus zu wandern", so wird in den seltensten Fällen Budget und Liefertermin angepasst, sondern die Umstrukturierung des Projektplans versucht. Die Konsequenz daraus ist, dass weiter hinten im Projekt gespart werden muss, wenn weiter vorne verschwendet wurde. Weiter vorne im Projekt liegt die Projektplanung, hier auch die Budget- und Zeitplanung, sowie die Analysephase mit allen dazu gehörenden Entscheidungsprozessen, weiter hinten die Entwicklung und der Test und dazwischen Architektur und Design. Anders formuliert leidet die Produktqualität und der geplante Leistungsumfang (da keine Zeit zum oderdentlichen Programmieren und Testen mehr vorhanden ist) und die Lebensqualität der Entwickler (die unbezahlte Überstunden leisten, um den Liefertermin noch halten zu können), wenn weiter vorne im Projekt, an erster Stelle bei der Planung, Willens- und Entscheidungsfindung und an zweiter bei der Analysephase Nachlässigkeit, Trägheit, Entschlusslosigkeit und Schlamperei regiert.

Wichtig ist für jedes IT-Projekt folgene kurze aber sehr korrekte und immer wieder ignorierte Aussage: Zeit, die zu Projektbeginn verloren wird, wiegt genau so schwer, wie Zeit, die gegen Projektende verloren wird.

Software-Entwicklung unterliegt eigenen Gesetzmäßigkeiten. Es gibt zwei grundsätzlich verschiedene ideologische Ansätze: Entweder, man versucht den Software-Entwicklungsprozess wie einen industriellen Fertigungsprozess zu verstehen, oder wie einen wissenschaftlichen Forschungsprozess. Die Wahrheit liegt m.E. dazwischen. Man muss den Prozess wie einen industriellen Fertigungsprozess verstehen, wenn man ein Prozess-Modell für die Projektdurchführung ansetzt. Ein dokumentenorientierter Ansatz entspricht auch eher einem industriellen Fertigungsprozess. Die Ausführung der einzelnen Prozessschritte Analyse, Design und Implementierung sind jedoch eindeutig Forschungsarbeit. In der Analysephase kann man teilweise sogar von einem investigativen Prozess sprechen, der manchmal wie stochern im Nebel ist, und der mehr an Sir Arthur Conan Doyles Sherlock Holmes erinnert, als an ingenieurmäßige Planung.

Im Controlling werden folgende sechs Fragen regelmäßig gestellt, und ich will kurze an der Wahrheit orientierte Antworten geben, auch wenn sie Ihnen als Controller nicht gefallen:

Wo wollen wir hin? Diese Frage muss zunächst der Auftraggeber selbst beantworten, wobei eine klare Vision genügt. Die für ein IT-System notwendingen Details zu erarbeiten ist die Arbeit des Business Analysten zusammen mit seinen Fachanwendern. Der Analytiker begnügt sich jedoch nicht mit einer vagen strategischen Zielformulierung oder einigen grundsätzlichen Regeln der Geschäftslogik, sondern arbeitet die Anforderungen soweit ins Detail aus, dass eine realistische Projektplanung möglich wird. - Niemand würde auf die Idee kommen, dass die Zielformulierung "Wir wollen das schönste Haus in der Stadt" tatsächlich auch nur ein Körnchen Lösung enthält. Vielleicht reicht ja die Fassade oder ein Vogelhaus!

Wo stehen wir? In der Analysephase lässt sich dies nur grob sagen, häufig gar nicht, denn der Leistungsumfang des Produkts wird ja gerade erst festgelegt. Erst mit einer abgeschlossenen Anforderungsanalyse und dem fertigen Anforderungsdokument lässt sich eine genaue Planung machen, und die aktuelle Position lässt sich erst dann gegen die Planung messen. Ein Analytiker kann Ihnen zu Projektbeginn nicht sagen, wie lange die Analysephase dauert, und rückblickend betrachtet ist mein Berufsstand häufig bis kurz vor Schluss der Analyse nicht in der Lage, dies auch festzustellen, da das Ende durch die Kreativität der Fachanwender und nicht durch den Analytiker bestimmt wird.

Wie gehen wir vor? Bei einem IT-Projekt haben Sie einen ganze Menge Prozess-Modelle zur Auswahl, aber alle haben eine Reihenfolge gemeinsam: verstehen, spezifizieren, designen, implementieren. Seriöse Termin- und Kostenpläne sind erst mit Abschluss der Spezifikation möglich. Die Auswahl des Prozess-Modells sollte abhängig von der Problemstellung und der Unternehmensumgebung gewählt werden.

Was bringt das? Diese Frage müssen Sie den Auftraggebern stellen, also der Fachabteilung, dem Vertreib und dem Marketing, nicht der IT-Abteilung oder dem Analytiker.

Was kostet das? Die Kosten für ein IT-Produkt können erst dann ermittelt werden, wenn die Anforderungen dafür vollständig und im Detail bekannt sind. Die Kosten für die Analysephase lassen sich korrekt betrachtet im Voraus nicht abschätzen, dies wird auf dieser Seite recht genau dargestellt. Als Faustregel gilt, dass die Analysephase etwa ein Drittel des Gesamtaufwands eines IT-Projekts ausmacht.

Bis wann kann ich das haben? Auch diese Frage kann seriös erst beantwortet werden, wenn die Anforderungsanalyse vollständig abgeschlossen ist.

Exkurs: Von Schlössern und geometrischen Figuren.

Wo wollen wir hin? Bis wann kann ich das haben?

Das Beispiel "Ich will ein Schloss!" kennt jeder. Hier ein paar Ergebnisse der Bildersuchmaschine ditto, und hier noch ein paar Ergebnisse, die ganz anders aussehen. Einmal wurde mit lock gesucht, das andere mal mit castle. Selbst castles können auf hunderte Art und Weisen gebaut werden, nicht nur locks. Wo wollten wir eigenlich hin? Welches Schloss sollte es sein?

Folgendes Experiment kann lustige Resultate haben: Zeichnen sie irgendeine etwas komplexere geometrische Figur, am besten mit freier Hand. Dann nehmen Sie etwa zehn Testpersonen. Eine der Testpersonen soll diese Figur nur verbal beschreiben, evtl. in einem schriftlichen Aufsatz, der dann vorgelesen wird, die anderen sollen sie zeichnen. Die Resultate werden alle verschieden sein und alle von Ihrer Vorgabe abweichen. Wenn Sie nun fragen, bis wann Sie den fertigen Aufsatz bekommen können, bevor Sie Ihre Zeichnung vorlegen, und wie lange es wohl dauern wird, bis alle Zeichner tatsächlich eine längen- und winkelgenaue Abbildung fertig haben, ebenfalls bevor Sie Ihre Zeichnung vorlegen, werden Sie nur Verwunderung oder Gelächter ernten. Selbst eine Auskunft, dass Sie nur drei Linien gezeichnet haben, hilft nicht weiter, denn jede Linie kann mehrere Meter lang und verschnörkelt sein.

Betriebswirtschaftler sprechen bei diesem Experiment manchmal von einem Totschlag-Argument, da auf diese Weise kein Auftag gewonnen werden könne. In der Praxis gibt es jedoch genügend Unternehmen, die dies sehr wohl können. Die Frage, wie bei einer Preisvereinbarung vor einer Vereinbarung eines Leistungsumfangs ein Gewinn garantiert werden kann, bleibt offen.

Wie lange dauert es, bis die Anforderungsanalyse fertig ist? Wieviel kostet das fertige Software-Produkt?

Zeit ist Geld und Geld regiert die Welt. Auf diesen Seiten wurde bereits die ebenso triviale wie regelmäßig ignorierte Tatsache erwähnt, dass die Kosten für das fertige Produkt erst dann abgeschätzt werden können, wenn das vom Kunden gewünschte Leistungsspektrum vollständig bekannt ist. Um Kostensicherheit zu bekommen, sollte es in beiderseitigem Interesse liegen, zunächst den Anforderungskatalog, also die Spezifikation des Produkts, verbindlich festzulegen. Aus diesem Katalog, dem Analysedokument, kann dann vom technischen Team erstmalig eine realistische Zeitschätzung für den Bau des Produkts erarbeitet werden, die sich wiederum in Geld umrechnen lässt.

Als Erfahrungswert hat sich inzwischen die Faustregel durchgesetzt, dass ca. 30% bis 40% des Aufwands und somit der Kosten für das Gesamtprojekt in der Analysephase steckt. [Fowler2]  S. 21 setzt etwa ein Fünftel der Gesamtentwicklungszeit eines Projekts an und bewegt sich damit unterhalb der üblichen Annahmen. Auf S. 36 merkt er jedoch an, dass der Detaillierungsgrad der Spezifikation eines Anwendungsfalls (eine genauere Darstellung als im vorstehenden Glossar-Eintrag mit einem Beispiel finden Sie im Inhalt eines Anforderungsdokuments) von seinem Risiko für das Projekt abhängt, und er sieht auch mündlich formulierte Anforderungen vor. Fowler ist ein Verfechter iterativer Prozess-Modelle. Auf die Durchgängigkeit hoher Detaillierung zu verzichten verlagert den Aufwand lediglich: entweder folgen Rückfragen der Designer und Entwickler, die der Business Analyst nachträglich zu klären hat, oder aber die Entwickler interpretieren das Anforderungsdokument nach eigenem Gusto und verschieben die Implementierung der genauen Anforderung in eine spätere Iteration der Produktentwicklung, die wiederum eine eigene Analysephase und zusätzlich die Überarbeitung des betroffenen Codes nach sich zieht. Mündlichen Anforderungen fehlt die Verlässlichkeit und sie sind nicht testbar, ein unbedingtes Vertrauensverhältnis zwischen Auftraggeber und Auftragnehmer ist Bedingung, will man nicht unkalkulierbare Projektrisiken akzeptieren. - Je mehr Freiheiten dem Entwicklungsteam bzw. dem Auftragnehmer zugestanden werden, um so niedriger kann der Aufwand für die Analysephase und letztendlich auch für die Entwicklung angesetzt werden. Der Kunde muss dann jedoch damit rechnen, dass seine nur vage ausformulierten oder gar nur mündlich artikulierten Wünsche nicht in seinem Sinne umgesetzt werden und wesentliche Anforderungen übersehen werden. Er hat in diesem Fall keinerlei Messlatte, über die die Erfüllung seiner Forderungen nachvollziehbar gemacht werden kann. Streit ist dann vorprogrammiert. [Fowler2] S. 21 klammert die politischen Risiken eines Projekts vollkommen aus und empfiehlt recht allgemein, einen Unternehmenspolitiker ins Boot zu holen.

Abhängig vom Willensfindungsprozess des Auftraggebers und dessen Entschlussfreudigkeit kann das zeitlich Volumen (nach Kalendertagen, nicht nach Personentagen) der Analysephase die Hälfte bis zwei Drittel der gesamten Projektzeit in Anspruch nehmen, wobei längere Leerlaufzeiten normal sind.

Beide Erfahrungswerte werden gelegentlich nicht akzeptiert und der Auftraggeber erwartet, dass die Analysephase deutlich kürzer ausfällt. Das Resultat sind dann i.d.R. unvollständige oder vage bzw. sehr interpretierbare Analysedokumente, die am ehesten als eine ausführliche Darstellung der Vision des Auftraggebers bezeichnet werden können und bestenfalls eine unvollständige und nicht Programmierungs-taugliche Darstellung eines Teils der Geschäftslogik enthält. Die vermeintlichen Einsparungen in der Analysephase werden dann auf die Design-Phase oder den Test verlagert. Einerseits wird der Designer die Anforderungsliste vervollständigen müssen, damit überhaupt eine abgeschlossene Produktversion definiert werden kann. Dabei beschränkt er sich natürlich rein auf die technischen Erfordernisse, denn einen fachlichen Anspruch verfolgt der Software-Designer nicht. Andererseits wird am Ende nur Qualität in das Produkt hinein getestet. Zudem tauchen erfahrungsgemäß beim Test oder gar erst bei Inbetriebnahme des Produkts versteckte Anforderungen auf, die es u.U. unmöglich machen, das Produkt überhaupt einzusetzen.

Wenn jemand, egal ob Auftraggeber oder Auftragnehmer, keine Überraschungen erleben will, dann sollte er folgendes Vorgehensmodell verwenden:

Vorgehensmodell Vorprojekt - Hauptprojekt
(angeregt für diese Seiten durch einen meiner früheren Software-Chefs, Klaus Meggendorfer, der dieses Modell erfolgreich benutzt)

Nach Abschluss der Vorprojekts kann gesagt werden, wieviel das Hauptprojekt kostet. Liegen die Kosten zu hoch, so hat der Auftraggeber zwei Möglichkeiten:
  1. Er reduziert die Anforderungen, sodass das Produkt billiger wird.
  2. Er nimmt das fertige Anforderungsdokument aus dem Vorprojekt als verwertbares Zwischenergebnis und holt weitere Angebote ein.
Die Software-Technologie kennt verschiedene Wege, einigermaßen korrekte Aufwandsschätzungen vorzunehmen, z.Z. ist die Function Point - Methode modern, die nur auf Basis des fertigen Anforderungsdokuments und ohne Grobdesign auskommt. Dem Auftraggeber bleibt i.d.R. nichts anderes, als diese Schätzung zu glauben oder von einer dritten Stelle eine unabhängige Schätzung einzuholen, die dann aber wieder mit Kosten verbunden ist. Der Auftraggeber sollte sich der Seriosität dieses unabhängigen Experten sicher sein.
Beispiel aus der Praxis

Grobdesign und Kostenschätzung dauerten in einem mittelgroßen Projekt ca. eine Woche, wobei die Designer bereits mit dem zu etwa 90% fertig gestellten Anforderungsdokument gut vertraut waren. Dem Kunden war der genannte Preis zu hoch. Er hatte binnen zwei Tagen eine neue Schätzung eines von ihm nicht näher benannten Experten auf dem Tisch, die nur halb so hoch war. Der Analytiker konnte das kaum glauben, denn alleine das Erststudium der Spezifikation sollte so lange dauern, ein formalisierter und nachvollziehbarer Abschätzungsprozess konnte in zwei Tagen gar nicht möglich sein. Der Kunde legte die Grundlagen der Schätzung nicht offen. - Später entschied sich der Auftraggeber, die Realisierung nicht vom ursprünglichen Aurtragnehmer umsetzen zu lassen. Das fertige Produkt war abweichend von der ursprünglichen Spezifikation soweit leistungsreduziert, dass die ursprüngliche Kostenabschätzung natürlich nicht mehr gültig war. Weiterhin war offensichtlich auf einen strukturierten Test verzichtet worden, der in der ursprünglichen Kostenplanung ebenfalls berücksichtigit worden war.
Zwar hat man nun einen Weg um die Kosten für das Endprodukt nach Festschreibung der Anforderungen zu ermitteln, aber was kostet nun das Vorprojekt?

Die ehrliche Antwort ist die, die Auftraggeber nicht hören wollen: Es läßt sich nicht abschätzen.

Bestenfalls läßt sich nach intensiven Vorgesprächen und der Erarbeitung eines Mission Statements eine Größenordnung abschätzen, aber abhängig von der Kreativität, dem Willensfindungsprozess und der Entscheidungsfreude des Auftraggebers kann eine Schätzung auch um den Faktor zwei, manchmal um den Faktor drei oder mehr daneben liegen; meist noch oben, gelegentlich aber auch nach unten. Bei der Reevaluierung meiner mittleren und größeren Projekte musste ich bei einem Teil der Fälle feststellen, dass ich rückwirkend gesehen auch nach der Hälfte der aufgewendeten Zeit nicht sagen konnte, wie lange es noch dauern würde, wobei eine Korrelation zwischen Kreativität (also das Ändern bereits vermeintlich festgeschriebener Anforderungen) und Unabschätzbarkeit signifikant ist. - Mich würden hier Ihre Erfahrungen interessieren. (Kontakt)

Lassen Sie mich diese Frage noch durch einige drastische Beispiele aus der Praxis darstellen:
Beispiele aus der Praxis

Nachdem mit einem Aufwand von ca. 10 Personentagen durch den Business Analysten und etwa genau so viel Aufwand an anderen Stellen inkl. Kunde ein Grobkonzept für ein mittelgroßes Produkt erstellt worden war, insistierte der Projektleiter auf eine Zeitabschätzung  für die Fertigstellung des Anforderungsdokuments. Der Business Analyst wies die Forderung nach einer verbindlichen Abschätzung zurück, da er weder den Kunden noch dessen Arbeitsweise kannte, und da offensichtlich war, dass der Willensfindungsprozess des Kunden erst mit Beginn der Grobkonzeptionierung begonnen hatte und noch nicht abgeschlossen war. Schließlich schätzte er optimistisch, dass er weitere 15 Tage für ein fertiges Konzept brauchen würde, falls der Kunde sich an alle Vereinbarungen im Grobkonzept halten würde, keine zusätzlichen Sonderfälle auftreten würden und der Kunde entscheidungsfreudig sei, sodass die Anforderungen dem Analytiker soz. nur in die Feder diktiert würden. Er wies den Projektleiter darauf hin, dass er so etwas noch nie erlebt hätte, und dass sich der Aufwand vervielfältigen könne, wenn der Kunde einzelne Punkte aus dem Grobkonzept sehr individuell und spezifisch implementiert haben wollte. Zusätzlich veranschlagte er fünf bis sieben Überarbeitungen mit einem mittleren Aufwand von zwei Tagen - unter denselben Vorbehalten. Insgesamt setzte der Analytiker optimistisch also ca. 30 Personentage an, ohne Beachtung des Murphyfaktors acht bis zehn Zeitwochen, realistisch jeweils das Doppelte und pessimistisch ließ er das Ende offen. Der Projektleiter schrieb 20 Personentage und sechs Zeitwochen in den Projektplan. Tatsächlich waren sechs Überarbeitungen notwendig, jedoch bewegten sich die Anforderungen so stark, dass der Willensfindungsprozess des Kunden ca. ein Jahr dauerte und die Aufwände des Analytikers bei ca. 70 Tagen lagen. Zwischendurch traten Leerlaufzeiten von mehreren Wochen auf.

Die Geschäftsführung eines mittelständischen Unternehmens bestand beim Leiter der Software-Entwicklung auf Lieferung eines Produkts (Ablösung eines produktionskritischen Altsystems) innerhalb von sechs Wochen, das hausintern verwendet werden sollte. Der Leiter tat, was er konnte, und übernahm selbst die Analyse. Die Fachabteilung, für die das Produkt eingesetzt werden sollte, machte sich jedoch nicht einmal die Mühe, das Anforderungsdokument gründlich zu studieren. Also begann die Entwicklung auf Basis der Annahme, dass das Konzept korrekt sei. Bei der ersten Vorführung lehnte der Abteilungsleiter der Fachabteilung das Produkt als unbrauchbar ab. Einige Monate später wechselte der Entwicklungsleiter das Unternehmen. Ein anderer Mitarbeiter erarbeitete kurzfristig eine Teillösung und verließ wenig später ebenfalls das Unternehmen. Die Teillösung war zusammen mit Teilen des Altsystems über ein Jahr später noch immer im Einsatz, keine der beiden Lösungen wurde weiter gepflegt.

Für ein Point of Sale-System wurden ca. 3 Mio. Euro veranschlagt. Noch während das Management untereinander und mit potentiellen Auftraggebern diskutierte hatte ein mit der Materie halbwegs vertrauter Entwickler eine brauchbare Lösung entworfen und implementiert.
Im ersten Fall war der blockierende Faktor das Unvermögen der Auftraggeber, ihren Willensfindungsprozess zu beschleunigen; der Analytiker hatte seinen Arbeitsplatz 1000 km vom Fachanwender entfernt und konnte somit nicht regelmäßig vor Ort eingreifen, was hier sicherlich angebracht gewesen wäre. Im zweiten Fall war der Blocker vermutlich ein Kommunikationsproblem oder der Unwillen der Fachabteilung, sieht man davon ab, dass die gesetzte Frist in keinem Fall zu halten war. Im dritten Fall konnte das Management offensichtlich nicht die Un-Komplexität der Problematik erkennen und war durch interne Politik paralysiert.

Wilhelm Reich sagte einmal: "Wir können tun, was wir wollen. Aber wir können nicht wollen, was wir wollen." Ein Business Analyst kann auf den Willensfindungsprozess des Fachanwenders keinen Einfluss nehmen. Er kann ihm lediglich die Konsequenzen seiner Entscheidungen vor Augen führen, Lücken in seinen Ideen aufdecken und nicht zu Ende gedachte Prozesse selbstständig vervollständigen. Er kann dem Fachanwender als Methodiker zur Seite stehen, wenn Alternativen gegeneinander abgewogen oder konkrete Ergebnisse erarbeitet werden sollen; er kann jedoch nicht für den Fachanwender entscheiden, welche der Alternativen er zu wählen hat. Ein Analytiker mit tiefem Fachverständnis kann u.U. die Hälfte einer Lösung selbst erarbeiten, die organisationsinternen Spezialitäten bleiben dabei aber auf der Strecke. Wäre es anders, könnte sich die Fachabteilung ein am Markt käufliches Standardprodukt anschaffen.

Die Dauer und somit die Kosten für eine Business Analysis und das damit verbundene Vorprojekt hängen vor allem von einem Faktor ab: Wie genau weiß der Kunde, was er will?
Beispiel aus der Praxis

Im Rahmen einer ersten Vorbesprechung fragte der Business Analyst nach den groben Inhalten eines gewünschten und noch recht vage formulierten Produkts, das ausschließlich Marketingzwecken dienen sollte. Nach einer Stunde recht kreativer Diskussionen stellte der Analytiker dem Kunden gegenüber fest, dass er selbst wissen muss, was er will. Der Kunde zeigte sich verärgert und stellte seinerseits fest, dass er vom auftragnehmenden Unternehmen hier Kreativität erwarte. In diesem Moment wusste der Analytiker, dass das Produkt teuer werden würde.
Als Fachanwender sollte man sich keinen Illusionen hingeben: Sie mögen glauben zu wissen, was sie wollen. Aber so lange Sie die für Ihr Produkt notwendigen Verfahren nicht schriftlich ausformulieren können, so lange bleibt Ihre Idee nur ein vager und schöner, vielleicht ein teurer, vielleicht ein unerfüllbarer Traum.

Verfolgt ein Analytiker die durch den Fachanwender verursachten Änderungen an bereits spezifizierten Prozessen, so kann er eine Metrik erarbeiten, nach der er abschätzen kann, wann die Spezifikation aus der flüssigen in die feste Phase wechselt. So lange die Anzahl der Änderungen noch steigt, ist die Spezifikation flüssig und ein Ende der Analysephase kann nicht prognostiziert werden. (vgl. hierzu den Abschnitt über Qualität in der Anforderungsanalyse)

Wer sein Ziel nicht kennt, wird es nicht finden. Zu Beginn einer Analysephase kennt weder der Fachanwender noch der Business Analyst das Ziel und erst das fertige Anforderungsdokument beschreibt das Ziel. Ob der Weg dorthin geradeaus oder in Schlangenlinien verläuft, hängt vor allem vom Fachanwender ab. Der Analytiker kann in seiner Eigenschaft als Methodiker wie Karte und Kompass verstanden werden, ob sich der Fachanwender aber an seine Richtungshinweise hält, kann vom Analytiker nicht erzwungen werden.

Aus dieser Sichtweise heraus ist es auch absurd, zuerst Budget und einen Liefertermin festzulegen, und dann erst darüber nachzudenken, was man haben will. Die Notwendigkeiten der Praxis verlangen aber gerade dies. Als Faustregel hat sich bewährt, etwa ein Drittel des Gesamtaufwandes für die Analysephase anzusetzen, jedoch die Hälfte oder zwei Drittel der Zeit.

Wie ermittelt man, ob ein gewünschtes Feature implementiert werden soll?

Nicht-anonyme Produkte

Bei nicht-anonymen Produkten ist der Endanwender bekannt und kann befragt werden. Wird ein Feature gewünscht, so müssen folgende Kennzahlen ermittelt werden, um entscheiden zu können, ob eine Implementierung sinnvoll ist:
Ist der Prozess sehr zeitkritisch und kann keinesfalls ohne Software-Unterstützung schnell genug erledigt werden, um das Funktionieren des Tagesgeschäfts sicher zu stellen, so ist eine Umsetzung ungeachtet der Kosten immer notwendig. Andernfalls ist die Geschäftsidee hinfällig, da der Gewinn aus dem Geschäft die Kosten nicht kompensiert.

Sind die Qualitätsanforderungen an den Prozess hoch genug, dass genaue Ergebnisse erzwungen werden müssen, so ist eine Umsetzung ungeachtet der Kosten immer notwendig, so lange die Kosten die Qualitätsanforderungen noch rechtfertigen können.

Sind die Entwicklungskosten zzgl. der laufenden Betriebskosten größer als die Kosten für eine manuelle Alternativlösung, und die zu erzielenden Ergebnisse können in angemessener Zeit und Qualität erzeugt werden, so sollte von einer Software-Lösung abgesehen werden.
Beispiel aus der Praxis

Über die Jahre war aus einem Software-Provisorium eine dauerhafte aber nicht minder provisorische bzw. schwerfällige Lösung gewachsen. Diese Lösung lief ursprünglich unter DOS bzw. später  in der DOS-Box der verschiedenen Windows-Versionen. Da mit der Lösung Daten zu den unmöglichsten Uhrzeiten aus aller Welt herunter geladen wurden, eine Automatisierung dieser Prozesse jedoch als relativ aufwendig erschien und zudem immer wieder Probleme auftraten, die einen manuellen Eingriff erforderlich machten, wurden Studenten angeheuert. Deren Aufgabe war es im wesentlichen, zur richtigen Uhrzeit den richtigen Knopf zu drücken, Dateien umzukopieren und zu verifizieren, dass die fraglichen Daten auch wirklich geladen worden waren.
Diese drei Regeln klingen einfach, sind es aber nicht. Wie häufig wird eine genaue Kostenabschätzung für administrative Vorgänge tatsächlich gemacht? Wenn ein Arbeitsprozess in einer Fachabteilung mit den dort vorhandenen Mitteln vollzogen werden soll, und wenn dieser Prozess noch gar nicht existiert, steht die Fachabteilung vor derselben Fragestellung wie ein IT-Team: Eine genaue Abschätzung kann immer erst dann stattfinden, wenn die Anforderungen genau bekannt sind. Dazu müsste eine fiktive Arbeitsvorschrift erstellt werden, und für diese Arbeitsvorschrift müssten die anfallenden Aufwände ebenfalls genau ermittelt werden. Ein Business Analyst kann dies zwar zusammen mit einer Fachabteilung machen, gefordert wird dies aber in den seltensten Fällen. Statt dessen werden sehr häufig Anforderungen unhinterfragt gestellt und als unbedingt notwendig klassifiziert.
Beispiel aus der Praxis

Ein Vorgang wurde als unbedingt erforderlich für die Umsetzung in einem IT-System vom Fachanwender klassifiziert. Bereits nach sehr grober Abschätzung kam man in der IT-Abteilung zu dem Schluss, dass an die zwei Personenmonate für die Umsetzung anfallen würden. Die Fachabteilung wollte diese Kosten nicht tragen, da sie "zu hoch" seien. Nach einer Rückfrage stellte sich heraus, dass der fragliche Vorgang nur vier Mal pro Jahr stattfand, etwa einen halben Tag Arbeit erforderte und bei den Mitarbeitern sehr unbeliebt war.
Das Beispiel zeigt sehr deutlich, dass es noch eine weiche Regel gibt:
Die Beurteilung dieser Frage ist nur subjektiv möglich. Prinzipiell sollte ein möglichst positives Arbeitsumfeld erzeugt werden, nicht zuletzt, um die Motivation und Leistungsfähigkeit der Mitarbeiter zu steigern, die einen großen Teil ihrer Lebenszeit an ihrem Arbeitsplatz verbringen. Eine vernünftige Relation zu den damit verbundenen Kosten ist jedoch unvermeidbar.

Auch bei nicht-anonymen Produkten gilt, dass der Analytiker lediglich Empfehlungen aussprechen kann. Die letztendliche Entscheidung, ob ein Feature implementiert werden soll oder nicht, liegt stets beim zahlenden Auftraggeber.

Anonyme Produkte

Bei anonymen Produkten ist der Endanwender nicht persönlich bekannt und kann daher auch nicht nach seinen Wünschen befragt werden. Die Auswertung von Benutzer-Feedback bei schon existierenden Produkten ist der Normalfall - sofern sich jemand die Mühe gemacht hat, es zu sammeln und zu strukturieren. Bestenfalls kann noch eine Umfrage unter den Anwendern durchgeführt werden, vielleicht auch eine Diskussion mit einigen ausgewählten Anwendern, bei denen sie bestimmte Features anregen oder zu Produktideen Bewertungen abgeben können. Der Regelfall ist jedoch, dass eine oder einige Personen aus der Fachabteilung bzw. aus dem Marketing eine Idee haben und die dazu gehörenden Detailanforderungen selbst definieren und vom Business Analysten spezifizieren lassen.

Eine Messbarkeit über die Notwendigkeit einer Anforderung anhand relativ leicht zu gewinnenden Zahlen wie bei nicht-anonymen Produkten ist nicht möglich.

Generell müssen alle Basisfunktionalitäten implementiert werden, die zum Funktionieren des Produktes bzw. zur Erfüllung seiner Aufgabe gehören. Werden diese Basisfunktionalitäten bereits als zu teuer eingeschätzt bzw. bewegt man sich dabei schon am Rande des vorgesehenen Budgets, sollte über einen Verzicht auf die Produktentwicklung nachgedacht werden. Mit einer Minimallösung ist kaum jemand hinter dem Ofen hervor zu locken.

Produkte bzw. Online-Services, die bezahlt werden, sind von kostenlosen klar abzugrenzen. Bei bezahlten Produkten können entweder die gesamten oder ein Teil der Kosten über den Preis herein geholt werden.

Bei bezahlten Produkten muss evaluiert werden, ob das fragliche Feature dazu beiträgt
Bei kostenlosen Produkten, vom Internetservice bis zur kommerziell hergestellten Freeware (z.B. der Acrobat Reader), muss hinterfragt werden, wo überhaupt der Return on Investment zu finden ist. Im Internet kann dies z.B. das Sammeln von Adressen oder anderen persönlichen Informationen sein, die zu konkreten Marketingaktionen genutzt werden können, bei denen andere Produkte verkauft werden. Andere Möglichkeiten sind die Platzierung von bezahlter Werbung oder Provisionen durch den Verkauf von Produkten. Bei Freeware kann der ROI die Verbreitung eines Produktstandards darstellen: dadurch, dass ein kostenloses Produkt häufig genutzt wird, müssen andere Produkte zur "Bedienung" des kostenlosen Produkts gekauft werden.

Bei bezahlten Internetprodukten steht jedoch gelegentlich nicht der ROI auf Basis des Preises im Vordergrund, sondern ebenfalls Marketingergebnisse. Kostenpflichtige Börsenspiele sind ein typisches Beispiel: Selbst, wenn die Teilnahmegebühr bereits die Entwicklungs- und Betriebskosten deckt oder sogar Gewinn abwirft, ist dies kein Argument, das für eine Investmentbank interessant ist. Die Bank will Kunden gewinnen und dazu animieren, Umsätze an der Börse zu machen.
Beispiel aus der Praxis

Bis zum Ende der Spezifikationsphase eines Internetprodukts konnte sich die Marketing-Abteilung des Auftraggebers weder entschließen, für die Nutzung eine Gebühr zu verlangen, noch, darauf zu verzichten. Interessant dabei war, dass aber sehr klare Vorstellungen über Regeln für Rabatte und Rabattstaffeln existierten. Am Ende wurde das Produkt kostenlos angeboten.
Nachvollziehbare Marktstudien können eine Grundlage bilden, um den ROI aus Sicht des Marketing zu messen. Diese durchzuführen fällt jedoch nicht in den Aufgabenbereich des Business Analysten. Vom Business Analysten und dem IT-Team kommen lediglich die Kostenschätzungen für die Herstellung des Produkts. Die Erfahrung zeigt, dass prognostizierte Benutzerzahlen nicht immer etwas mit der tatsächlichen Produktnutzung zu tun haben. Hier sind die Vertriebs- und Marketingprofis am Zuge, nicht die IT-Profis.

Ein unvermeidlicher Zwischenruf: Prozess-Modelle in der Praxis

Vgl. hierzu Business Analysis als Bestandteil eines Prozess-Modells bei IT-Projekten

Warum ist Software so teuer?

Die Frage, ob ich ein so übertiteltes Kapitel hier aufnehmen sollte oder nicht, bereitete mir einige schlaflose Nächte, denn man begibt sich hier auf sehr umstrittenes Gelände, das eher von Polemik als von Sachlichkeit dominiert wird. Immerhin hat Tom DeMarco 1995 ein gleichnamiges Buch geschrieben [DeMarco2], das 1997 erstmalig auf Deutsch erschien, und auf das ich zum weiteren Studium verweisen will. Das Datum mag kein Zufall gewesen sein, denn bei Budget-Überziehungen von 180%  in diesen Jahren war es höchste Zeit, etwas zu tun.

Betrachtet man die Budget-Überziehungen, dann ist die Frage aber falsch gestellt. Sie muss lauten: Warum wird Software teurer als ursprünglich geplant? Seit DeMarco sein Buch geschrieben hat, haben sich zwar die Überziehungen deutlich reduziert, die Frage, oder bersser die Behauptung, dass Software (so) teuer sei, steht aber nach wie vor immer wieder im Raum. Abzuwarten bleibt, ob sich dieser Trend in Zukunft fortsetzen wird. Wahr ist lediglich, dass Budgets überzogen und Termine nicht eingehalten werden, und zwar vor allem dann, wenn Liefertermine und Kosten festgeschrieben werden, ohne dass das geforderte Leistungsspektrum des Produkts vorab vollständig spezifiziert wurde.

Wird die Frage gestellt, warum Software so teuer ist, so kann mit zwei Gegenfragen geantwortet werden:
  1. Wie will der Frager die Software billiger herstellen?
  2. Wogegen werden die Kosten der Software gemessen?
Als Frager muss man sich diese Gegenfragen gefallen lassen.
  1. Hat man selbst die Kompetenz, die Herstellungskosten einer Software qualifiziert zu beurteilen, so sollte man die Frage gar nicht stellen müssen. Im Gegenteil sollte man die Entwicklung selbst übernehmen.
  2. Hat man vor Beauftragung der Entwicklung keine Kosten-Nutzen-Analyse vorgenommen, in der nachgewiesen wurde, dass sich die Investition in die Produktentwicklung auch lohnt, so hat man einen entscheidenden betriebswirtschaftlichen Planungsfehler gemacht, der dem IT-Team nicht anzulasten ist.
Dass Software teuer ist, ist m.E. eine unhaltbare Behauptung.
Unternehmerisches Denken fordert, dass mit Gewinn gearbeitet wird. Damit dies gelingt, muss auf allen Ebenen des Projekts vernünftig gearbeitet werden.

So stehen die Dinge!

Es passiert so gut wie nie, dass bei Projektbeginn zunächst für alle Beteiligten klar kommuniziert wird, wie das benutzte Prozess-Modell aussieht. Dabei ist es gleichgültig, ob es sich um ein großes, mittleres oder kleines Unternehmen handelt. Abhängig von der Unternehmenskultur und insbesondere abhängig vom Projektmanager ist meistens wenigstens eine vage Vorgehensweise angepeilt, die auch einen Spezifikationsprozess vorsieht.
Beispiele aus der Praxis

Ein Projektmanager fragte einmal den ihm zugeordneten Business Analysten im dritten Projektmonat, ob das Dokument, an dem er arbeiten würde, das Lastenheft sei. Der Analytiker hielt die Frage irrtümlich für einen Witz.

Ein Projektmanager schickte an die Analytiker der beiden von ihm betreuten Projekte eine Dokumentenvorlage weiter. Das Release Management forderte, dass das Dokument komplett ausgefüllt würde, ehe ein Produkt freigegeben werden konnte. Der Projektmanager bat darum, dies in den nächsten beiden Tagen zu erledigen. Beide Analytiker zeigten sich nicht beeindruckt und ignorierten diese Forderung. Die fragliche Vorlage betraf die gesamte Projektdokumentation, musste also parallel zur Entwicklung des Projekts über Monate von der Formulierung der ersten Idee bis zu den fertigen und abgearbeiteten Testplänen hinweg aufgebaut und gepflegt werden. Der Projektmanager hatte offenbar keine Ahnung, um was es ging.
Entgegen der Intention des Qualitätsmanagements, das ein aktives Leben von Qualität vorsieht und fortwährende Verbesserung fordert, wird Qualität entweder gar nicht bewusst gelebt, oder aber der QM-Prozess verkümmert zum bürokratischen Parasiten. Die Ergebnisse spiegeln sich in der praktischen Anwendung von Prozess-Modellen wider: Häufig werden Vorgehensweisen nur vage definiert und intuitiv angewendet und führen schließlich zu Entgleisungen und gescheiterten Projekten. Eher in größeren Organisationen wird dagegen ein bestimmtes Prozess-Modell vorgegeben und muss auch unhinterfragbar strikt eingehalten werden, ohne dass dem Projektteam eine Gelegenheit gegeben wird, das Modell der aktuellen Situation angemessen zu modifizieren und einzusetzen. Dadurch entsteht ein bürokratischer Moloch, und die IT-Teams wenden sehr viel Energie auf, diesen Moloch auszutricksen, um überhaupt ihre Arbeit machen zu können. Erfolgreich und konsequent werden Prozess-Modelle m.E. am ehesten in kleinen oder mittleren Unternehmen von erfahrenen Projektmanagern mit eher akademischen Ansatz angewendet, die die ihnen gewährten Freiheiten einerseits nutzen, um ein dem Projekt angemessenes Modell zu definieren und einzusetzen, andererseits auch die notwendige Kompetenz und Konsequenz mitbringen, um die Forderungen des Modells auch durchzusetzen. Diese Projektmanager haben meist sehr tiefe Kenntnisse der IT in ihrem Arbeitsumfeld, sodass sie die Qualität der Arbeit des Teams sowohl ein- als auch wertschätzen können.

Der Sicht einer geplanten, strukturierten und nachvollziehbaren Vorgehensweise, egal welcher Art, steht die der Ereignis gesteuerten gegenüber. Dieses für jeden Manager normale und unvermeidliche Verhalten ist für Software-Entwickler, Analytiker und letztendlich für den Software-Entwicklungs-Prozess Gift, wie nicht nur Tom DeMarco [DeMarco1] nachgewiesen hat, sondern die tägliche Praxis zeigt. Wie die z.T. stark voneinander abweichenden immer wieder einmal publizierten Zahlen zeigen, ist aber eine klare Tendenz erkennbar. Die von der Standish Group veröffentlichten Zahlen (Pressemitteilung vom 25.3.2003) basieren auf der Auswertung von 13522 IT-Projekten in den USA und liegen etwa auf der Linie der verschiedenen Publikationen: 34% der IT-Projekte waren immerhin erfolgreich, doppelt so viele wie 1994. 15% der Projekte wurden vorzeitig abgebrochen, etwa halb so viele wie 1994, 51% der Projekte waren nur bedingt erfolgreich.
Erfolg von IT-Projekten
Zwar ist die IT-Branche bzgl. des Projekterfolgs etwa so verrufen wie der Freitag der Dreizehnte, jedoch ergab eine in Capital (Ausgabe 19/2003 S.121) veröffentlichte Umfrage unter 481 Managern aus deutschen Konzernen und mittelständischen Betrieben branchenübergreifend lediglich eine Erfolgsquote von 19%. Ein verwandtes Thema, mangelhafte Effizienz, wird bei Focus Money (Ausgabe 43/2003, S. 9) angesprochen, wobei eine Studie von Czipkin & Proudfoot zitiert wird: Deutsche Unternehmen verlieren durch mangelhafte Effizienz 238 Milliarden Euro pro Jahr, 9,8 Milliarden Arbeitsstunden verpuffen ohne Ergebnis. Als wichtigste Ursachen werden mangelnde Planung und Steuerung mit 44% benannt, fehlende Arbeitsmoral macht 13% aus, und schließlich schlagen fehlerhafte IT-Lösungen mit 9% zu Buche. Genaue Messungen zu Projekterfolgen gibt es insbesondere unternehmensintern nur selten, wahrscheinlich aus gutem Grunde. Selbst in Tageszeitungen wird das Thema inzwischen aufgegriffen. So schreibt z.B. die Süddeutsche Zeitung (6./7.9.2003, Nr. 205, S. V1/15) in einem mit "Management per Zufall" übertitelten Artikel: Die Dunkelziffer gescheiterter Projekte ist hoch. Denn über Pleiten, Pech und Pannen sprechen Manager aus Sorge um das Firmen-Image nicht gern. Trotz der finanziellen Folgen mangelt es an Problembewusstsein, eine systematische Auswertung der Fehler unterbleibt. - Anders formuliert: Trivialste Grundlagen des Qualitätsmanagements werden nicht angewandt.

Im Mittel wurde das Budget der von der Standish Group analysierten IT-Projekte um 43% überzogen (1994 waren es noch 180%), jedoch bei zwei Dritteln um weniger als 20% - wenn es also finanziell schief geht, dann gründlich. Nur 52% der geforderten Funktionalität wird umgesetzt (2000 waren es noch 67%). Im Mittel dauern die Projekte 82% länger als geplant, wobei hier eine Verschlechterung gegenüber 2000 (damals 63%) zu sehen ist. - Die Zahlen deuten auf eine Verschiebung des Fokus hin zur Qualität und Bezahlbarkeit und weg von der Umsetzung von Features um jeden Preis, m.E. ein Resultat des gesunden Einflusses des Kosten-Controllings und Qualitätsmanagements. Zeit- und Leistungs-Controlling werden dafür zunehmend vernachlässigt.
Beispiele aus der Praxis

Ein Projektleiter legte einen Zeit- und Kostenplan vor, der einen Murphyfaktor von 2 enthielt. Dies war auch so beschrieben und mit dem Erfahrungswert begründet, dass die üblichen Pläne um diesen Faktor übertroffen wurden. Das Controlling, das keinerlei IT-Kompetenz nachweisen konnte, strich den Faktor ersatzlos und bewilligte nur den Plan ohne Murphyfaktor. Natürlich lief das Projekt aus dem Ruder. Der Projektleiter bewarb sich fortan nur noch als UNIX-Admin und zwar stets mit der Auflage, nicht als Projektleiter arbeiten zu wollen.

Im Rahmen eines Vorstellungsgesprächs bei einem bekannten schweizerischen Unternehmen fragte der Bewerber nach der Erfolgsquote der laufenden IT-Projekte. Die Antwort lautete 98%. Der Bewerber konnte sich nur mit Mühe ein lautes Auflachen verkneifen. Man konnte sich nicht auf eine Zusammenarbeit einigen.
In einem Artikel aus der Computerwoche 23 (4.Juni) 2004, S. 10, der über ein Forum von 40 CIOs berichtet, heißt es: Häufig beginnen demnach die Missverständnisse bereits mit unklar formulierten Aufträgen an die IT-Organisationen. "Das Business weiß oft selbst nicht genau, was es will", pointierte ein CIO aus dem Auditorium. Eine Meinung, die das technische Personal so gut wie immer teilt. Auf derselben Seite heißt es, dass Einspareffekte in die Zahlen des jeweiligen Fachbereichs einfließen, wenn es gelingt, Prozesse mittels IT zu verbessern. Andererseit wird die Verantwortung für das Scheitern gerne der IT zugeschoben, selbst wenn der Misserfolg in der mangelnden Beweglichkeit des Fachbereichs wurzele.

Ein Dauerbrenner unter den IT-Witzen lautet: Wer glaubt, dass Projektleiter Projekte leiten, der glaubt sicher auch, dass Zitronenfalter Zitronen falten. Ganz so schlimm ist es nach meinen Erfahrungen nicht. Allerdings sollte ein Projektleiter seinen Leuten das Arbeiten ermöglichen und sie nicht dabei behindern. Sobald das eigene Team um den Projektleiter herum arbeiten muss, um ein Projekt voran zu treiben, ist etwas schreckliches schief gegangen. Ein Analytiker kann zwar zur Projektkultur beitragen, die unantastbare Leitfigur ist jedoch der Projektleiter. Wenn also kein klar definiertes und dem Projekt angemessenes  Prozess-Modell verfolgt wird, das auch an alle Projektbeteiligten kommuniziert wurde, dann kann ein Analytiker auch kein konkretes Modell unterstützen. Er kann jedoch die Anforderungen nach wie vor aufnehmen, aber nur so gut es geht. Die Betonung liegt deshalb hierauf, da eine Produktversion klar abgegrenzt sein muss, egal, welches Prozess-Modell befolgt wird. Ein Analytiker ist normalerweise mit einem stetigen Zufluss von Anforderungen konfrontiert, die die Geschäftslogik formen und - mehr oder weniger - wichtig sind, zusammen hängen und logisch sind. Martin Fowler spricht den Informatikern aus der Seele, wenn er den Terminus Geschäftslogik (business logic) in Zweifel zieht und dabei von einer willkürlichen Ansammlung seltsamer Bedingungen spricht, die oft auf überraschende Weise miteinander interagieren ([Fowler1], S. 17). Die Abgrenzung einer Produktversion ist das Resultat eines Entscheidungsprozesses, zu dem Analytiker und Entwickler zwar Empfehlungen aussprechen und die Fachanwender Prioritäten setzen können, die Entscheidung ist aber letztendlich vom Projektleiter unter starker Beachtung der Fachanwenderseite zu verantworten. Zu berücksichtigen sind dabei allerdings nicht nur die Bedürfnisse der Fachabteilung, sondern auch die Realisierbarkeit der Forderungen auf sinnvolle Art und Weise. Dabei muss nicht nur die Produktentwicklung gewährleistet sein, sondern auch die Einhaltung des Zeitplans und Budgets bei Erfüllung einer Mindestqualität. Hat der Projektleiter dazu nicht die notwendigen Qualifikationen, so kann er u.U. die Definition der Version an den Analytiker delegieren, sollte dann aber auch bereit sein, die Empfehlungen nur noch abzunicken; wenn ihm die Qualifikaiton fehlt, eine Version zu definieren, dann fehlt ihm auch die Qualifikation, die Empfehlung zu beurteilen und ihr zu widersprechen.
Beispiel aus der Praxis

Ein Projektleiter, der dritte in weniger als einem Jahr im aktuellen Projekt, hatte die Eigenart, etwa einmal pro Woche von Besprechungen mit dem mittleren oder höheren Management der Fachabteilung zurück zu kommen und ein ad hoc meeting einzuberufen, bei dem die Anforderungen in der laufenden Entwicklung geändert wurden. Der Business Analyst war bei diesen Besprechungen nur selten eingeladen. Zu keinem Zeitpunkt war ein verbindlicher Leistungsumfang für eine erste produktive Version festgeschrieben. Die meisten Entwickler verließen das Team ohne eine Verlängerung ihrer Verträge zu erwägen, aber das Budget war zu diesem Zeitpunkt ohnehin bereits erschöpft. Das Produkt lief am Ende mehr schlecht als recht. Ein Entwickler. der selbst ein erfahrener technischer Projektleiter war, kritisierte nachdrücklich, dass der Projektleiter einer seiner Hauptaufgaben nicht nachkäme: das Team zu schützen und ihm zu ermöglichen, ein IT-Produkt zu schreiben. Er sagte bei anderer Gelegenheit, dass es ihm noch niemals zuvor passiert sei, dass er nach drei Monaten Projektmitarbeit das Gefühl hatte, nichts erreicht zu haben.
Um einem IT-Team die Arbeit zu ermöglichen und somit den Projekterfolg nicht dem Zufall zu überlassen, sind Regeln in Form eines wie auch immer definierten Prozess-Modells notwendig, an das sich sowohl die Mitarbeiter der Fachabteilung als auch des IT-Teams halten müssen. Die Verantwortung für die Einhaltung des Prozess-Modells liegt beim Projektmanager. Die Definition einer für eine erste Produktversion bzw. Iteration ausreichenden Menge an Anforderungen steht an erster Stelle, die Umsetzung dieser Anforderungen ist der Folgeprozess.
Beispiel aus der Praxis

In einem zeitkritischen Projekt wurden zwei Parallelentwicklungen angestoßen: Eines mit regulärem Projektmanagement und einem IT-Team bestehend aus einem Designer und weiteren zwei Entwicklern, parallel eine fall back - Lösung eines mit der Materie sehr vertrauten Einzelkämpfers, der für kurze Lieferzeiten und eigenwillige Vorgehensweise bekannt war. Dazu kam noch ein Datenbankentwickler, dessen Arbeit nicht auf dem kritischen Pfad lag und der Abrechnungsprozesse implementieren sollte. Der Einzelkämpfer lieferte seine Version zu einem Zeitpunkt ab, als das Team mit dem Design fertig und mit der Entwicklung halb fertig war. Zunächst wurde erwogen, die Team-Lösung nicht mehr weiter zu verfolgen. Allerdings zeigte sich bereits bei den ersten Tests dieser Version, dass der Einzelkämpfer das Anforderungsdokument nicht gelesen und die davon abgeleiteten Testfälle nicht abgearbeitet hatte, sondern die Anwendung lediglich anhand der Templates entsprechend seiner persönlichen Interpretation umgesetzt und ungetestet weiter gegeben hatte. Es war sicher, dass der Kunde diese Version niemals abnehmen würde und dass der Versuch, Qualität hinein zu testen, scheitern würde, da der Entwickler lediglich bereit war, gemeldete Fehler stückweise nach Meldung zu beheben, anstatt selbst die Anforderungen wie spezifiziert umzusetzen. Der Aufwand wäre nur von der Entwicklung zum Test verlagert worden, weder war ein Zeit- noch ein Kostengewinn erkennbar.
Planungsfehler sind zusammen mit der Nicht-Beseitigung von Projekthindernissen die teuersten Fehler. Erst an zweiter Stelle kommen Fehler, die im Rahmen der Anforderungsanalyse gemacht werden. Zeitverzug bei der Anforderungsanalyse entsteht nach meinen Erfahrungen hauptsächlich durch Unentschlossenheit der Fachanwender, einzelne Produkt-Features verbindlich festzuschreiben, oder durch eine niedere Priorisierung des IT-Projekts im Vergleich zum Tagesgeschäft und anderen Aufgaben. Hohe Folgekosten eines Projekts sind dagegen auf Fehler im Design und der Entwicklung der Software zurückzuführen. Diese liegen wiederum in den meisten Fällen an grundsätzlichen Planungsfehlern bzw. mangelhafter Durchsetzung der Planung: Schreitet ein Projekt auf dem Zeitstrahl fort, so werden die zeitlich weiter hinten liegenden Realisierungsphasen abgekürzt, ein zu Lasten späterer Wartbarkeit vereinfachtes, inflexibleres und unterm Strich schlechteres Software-Design und hardcodes sind die kostspielige Folge.

Exkurs - Pyramidenbau damals und heute, schwimmende Eisberge und zu Wasser gelassene Pyramiden

Hinweis

Lassen Sie mich diesen Abschnitt etwas humoristisch angehen, inhaltlich ist er aber Ernst gemeint.

Pyramidenbau (klassisch)

IT-Systeme teilen sich mit den alten ägyptischen Pyramiden eine Eigenschaft: Beide stehen, aber eigentlich wissen nur die, die sie bzw. es gebaut haben, wie sie es hingekriegt haben. Zumindest bei IT-Systemen ist es manchmal besser, wenn man als Aussenstehender nicht weiß, wie der Bau zu Stande kam.

Über den Bau der Pyramiden haben sich einen Haufen Leute den Kopf zerbrochen und es gibt eine Reihe von mehr oder weniger abstrusen Theorien dazu, wie die 6 Mio. Tonnen Gestein zum Bau der Cheopspyramide aufgestapelt worden sind. Keine Diskussionen gibt es dagegen um die Reihenfolge des Baus: Man fing unten an, arbeitete sich von dort aus nach oben und kam mit der Spitze zu einem Ende. Für Pyramiden gilt auch, dass sie auf dem Sockel stehen, nicht auf der Spitze.

Pyramide - wie es sein sollte  

Eisberg (klassisch)

Die Sichtbarkeit bei einem IT-System ist analog zum Eisberg, sehen kann man nur die Spitze bzw. die Benutzeroberfläche. Bei klarem Wasser kann man immerhin noch ein wenig in die Tiefe blicken und erahnen, dass da noch mehr ist. Dasselbe gilt für das IT-System: es kommen Ergebnisse raus, irgend etwas hat es gemacht, irgend etwas ist da noch, ausser der Benutzeroberfläche. Den vollen Umfang von Eisberg und IT-System erkennt man jedoch nicht, aber damit die Benutzeroberfläche mehr als nur ein paar hübsche Bilder darstellt und sie somit nicht "untergeht", wenn man das System zu Wasser lässt, muss noch ein gewaltiger "Unterbau" da sein, der für Auftrieb sorgt. Knapp unter der Wasseroberfläche können heimtückische Ausläufer des Eisbergs versteckt sein, die eine bedeutende Gefahr für die Schifffahrt darstellen. Fehler im "Unterbau" des IT-Systems sind ein entsprechend großes Projektrisiko.

Eisberg - wie im Polarmeer (klassisch)




Schwimmende Eispyramiden

Stellen wir uns eine Pyramide aus Eis mit vergoldeter Spitze vor, die im Wasser schwimmt. Das würde wohl etwa so aussehen:

Eispyramide im Wasser

Gold ist schön, teuer und schwer. Ohne das Eis darunter wäre das Resultat etwa so:

Eispyramide - nach dem Untergang

Ein IT-System als schwimmende Pyramide

Beim Bau von IT-Systemen scheint gelegentlich Hopfen und Malz verloren, und zwar immer dann, wenn man auf die Anwendung eines Prozess-Modells verzichtet, wenn der Projektleiter keine Ahnung von den Entwicklungszyklen der Software hat oder die Arbeitsreihenfolge im Zyklus gewaltsam durchbrochen wird. Die typische Frage, die zu letzterem führt, lautet: "Kann man schon was sehen?".

Als Kunde hat man das legitime Recht, einen Prototypen zu bestellen. Dieser Prototyp ist so etwas wie eine auf zwei Seiten vergoldete Fassade einer Pyramidenspitze, die am Strand aufgestellt ist. Sie vermittelt einen guten Eindruck, wie das System am Ende optisch aussieht bzw. bei prototypischen Pilotsystemen welche Basisfunktionalitäten es enthalten wird, mehr aber auch nicht.

Pyramiden werden von unten nach oben gebaut. Gerade, wenn Termindruck herrscht, werden Auftraggeber gelegentlich nervös und vergessen das. Sie wollen unbedingt Resultate sehen, und zwar im Sinne von fertigen Produktteilen mit einer fertigen Benutzeroberfläche. Nur auf diese Art und Weise lassen sie sich überzeugen, dass die Entwicklung auch wirklich voran kommt. Dies kann soweit gehen, dass Resultate geliefert werden sollen, obwohl noch nicht einmal ein Anforderungsdokument begonnen worden ist. Der Regelfall ist allerdings, dass die Forderung, etwas sehen zu wollen, während der Entwicklung kommt. Der typische Projektverlauf sieht dann etwa so aus:
Das Resultat sieht aus Sicht des Auftraggebers etwa so aus, wobei er sich an der leicht verzogenen Form der Spitze nicht stört, denn das wusste er schon vorher:
Eispyramide - Kundensicht

Das IT-Team hat sich wirklich bemüht, den Druck vom Projektmanager zu nehmen. Der Auftraggeber ist beruhigt. Die Katastrophe schreitet voran. Dem unter Wasser arbeitenden Team bietet sich etwa folgendes Bild:

Eispyramide - IT-Team-Sicht
Der investierte Aufwand für die Provisorien ist verloren. Da aber nun die Zeit noch mehr drängt und der Abbau der Provisorien weitere Aufwände verschlingen würde, bleibt nichts anderes übrig, als weitere Provisorien zu basteln, die im Wesentlichen von der sich noch in ihrer Form verändernden goldenen Spitze bestimmt werden. Die ganze Angelegenheit ist in einem labilen Gleichgewicht, jede Schwerpunktänderung der Spitze muss durch einen massiven Umbau der Provisorien kompensiert werden, sonst kippt die Möchtegern-Pyramide um.

Das Projekt kann am Ende bestenfalls als Teilerfolg verbucht werden. Der Auftraggeber mag an der Oberfläche nicht sehen, wie schrecklich der Unterbau ist, er wird es aber sehr wohl spüren, wenn er das System belastet oder einen späteren Umbau wünscht. Weder ist solch ein System stabil, noch sind die Wartungskosten im Griff zu halten.
Beispiel aus der Praxis (aus einer Zuschrift)

Bei einem Projekt hatte man sich vorgenommen, mit einem richtigen Datenbank- und Objekmodell zu arbeiten. Der Projektleiter, der seine Projektleitungs-Kompetenz durch ein Zertifikat einer bekannten Fortbildungseinrichtung belegen konnte, kam aus dem Marketing und hatte von IT keine Ahnung. Er unterstützte diesen Ansatz begeistert. Nach zwei Wochen war die Begeisterung dahin, nach drei Wochen die Unterstützung. Er stellte ein einwöchiges Ultimatum, um ein Eingabeformular zu sehen. "Und", so aus der Zuschrift wörtlich zitiert, "so wurde es doch wieder ein typisches Projekt, wo von oben nach unten und von unten nach oben gewerkelt wurde, und die Stoßstellen mit lustigen Interface-Klassen überbrückt wurden..."

Schwimmende Anforderungsanalyse

Die Abschnitte oben stehen eher für einen fehlgeschlagenen Entwicklungsprozess, der nach Abschluss der Anforderungsanalyse ruiniert wurde. Eine Anforderungsanalyse zeichnet sich gelegentlich durch Zeiten der Orientierungslosigkeit aus. Dies ist normal, wird aber zum Projektrisiko, wenn die Orientierungslosigkeit überhand nimmt und keine richtungsweisenden Entscheidungen gefällt werden. Das sieht dann etwa so aus:

Weg nach Nirgendwo

Der gerade Weg vom Start nach unten, um dann zum Ende hin richtig abzubiegen, ist das, was sein sollte: Nach Idee und Vision (=Initialisierung) wird festgestellt, was der Auftraggeber will. Und das wird dann gemacht. Ende.

Den Rest gibt es dazu, etwa wie das Schwarze am angebrannten Kuchen. Aber leider ist das nicht kostenlos. Im Gegenteil ist dies der Kostentreiber im Projekt schlechthin, wenn der Kuchen zu verbrannt ist, muss er sogar weggeworfen werden. Dieser Kostentreiber hängt gleichrangig an der Kompetenz des Analytikers und des Projektmanagers, und, an erster Stelle, am Willensfindungsprozess des Auftraggebers und der Unterstützung des Managements für das Projekt.

Das wirklich schlimme an dieser Zeichnung ist, dass ich sie einmal neben einer Tasse Kaffee sitzend selbst angefertigt und in den Anhang eines Anforderungsdokuments des Unterhaltungswertes wegen aufgenommen hatte. Das für sich ist weniger schlimm, bedenklich war, dass sich im Laufe der Folgemonate herausstellte, dass nur ein Teil der Projektbeteiligten, die eine Mitwirkungspflicht an der Anforderungsanalyse hatten, die Zeichnung kannte! Alle anderen hatten das Dokument kein einziges Mal komplett durchgearbeitet, sonst wäre ihnen dieser Unsinn aufgefallen.

Wunsch vs. Wirklichkeit

Alle gängigen Prozessmodelle gehen davon aus, dass die Wünsche des Auftraggebers erfüllt werden. Ebenfalls wird dabei implizit postuliert, dass der Willensfindungsprozess des Auftraggebers abgeschlossen ist. Erst dann beginnt das eigentliche Prozessmodell, das - egal ob ein linearer oder iterativer Ansatz verfolgt wird - vorsieht, dass die Produktteile spezifiziert und abgenommen sind, die zum Design und in die Entwicklung gehen sollen.

Wunschvorstellung IT-Produktentwicklung

Die Realität sieht aber meist anders aus: Am Anfang steht stets der Wunsch, auch der nach einem baldigen Liefertermin und niedrigen Kosten, der Willensfindungsprozess hat aber oft noch gar nicht begonnen. Der Analytiker unterstützt nun den Auftraggeber beim Willensfindungsprozess und spezifiiert parallel das Anforderungsdokument. Dieser Prozess zieht sich jedoch häufig zu sehr in die Länge. Spätestens bei Implementierungsbeginn ist absehbar, dass der Liefertermin nicht gehalten werden kann und dass die Erfüllung der Kundenwünsche, d.h. Lieferung des geforderten Leistungsumfangs, im vorgesehenen Budget nicht mehr möglich ist. Eine Reduzierung des Anforderungskatalogs ist nicht zu vermeiden. Ob das Projekt dennoch als Erfolg einzustufen ist, ist Definitionsfrage.

Wirklichkeit IT-Produktentwicklung

Aufgabe des Business Analysten ist es, die Kundenwünsche aufzunehmen und so zu formulieren, dass daraus ein IT-Produkt gebaut werden kann. Termin- und Budgetüberwachung sowie die Korrektur des Plans, wenn er von der Realität eingeholt wird, fallen dagegen in die Verantwortung des Projektmanagers. Ein Analytiker hat nicht die Möglichkeit, den Auftraggeber zu einer Entscheidung zu zwingen. Seine Aufgabe ist es, dem Kunden Optionen aufzuzeigen bzw. mit dem Kunden gemeinsam Optionen zu erarbeiten, die Auswahl einer Option obliegt jedoch alleine dem Kunden.

Rein verwaltende Projektmanager haben keine andere Alternative, als Fachanwender und Business Analysten zu bedrängen, den Willensfindungs- und Spezifikationsprozess abzuschließen, wenn sie feststellen, dass Zeitverzug droht oder gar eingetregen ist. Häufig wird dabei versucht, die Verantwortung zur rechtzeitigen Fertigstellung der Anforderungsanalyse an den Business Analysten zu delegieren, nicht aber die notwendingen Befugnisse. Zwar kann versucht werden, im Analytiker oder Fachanwender einen Schuldigen zu finden, die Spezifikation wird deshalb aber nicht schneller fertig. Konkret bedeutet dies, dass das Management den Verzug ignoriert.  Dasselbe gilt für den Auftraggeber, wenn er auf seiner Seite ebenfalls nur auf die Fertigstellung der Anforderungsanalyse drängt, nicht jedoch proaktiv die Ursachen für mögliche Verzögerung im Vorfeld des Projekts vermeidet. Die Durchführung einer Meilenstein-Trendanalyse ist nicht notwendig um zu erkennen, dass das technische Team gehalten sein wird, die verlorene Zeit zu kompensieren.

Es gibt zwei Alternativen zur Reaktivität und Untätigkeit:
  1. Die Aufwandsabschätzung wird aktualisiert, das Buget und der Liefertermin werden angepasst.
  2. Man arbeitet proaktiv und läßt es gar nicht soweit kommen.
Die erste Variante ist die übliche und führt zu den Resultaten, die die Standish Group Jahr für Jahr misst. Die zweite Variante setzt voraus, dass der Projektmanager gegenüber dem Auftraggeber einen radikalen Schnitt durchsetzen kann, sodass die Spezifikationsphase bzw. deren Unterphasen beendet wird, auch wenn noch nicht alle Wünsche des Kunden spezifiziert worden sind. Da man allerdings kaum mitten in der Arbeit den Bleistift fallen lassen kann, sondern die Spezifikation weit genug getrieben werden muss, um auch gut genug für die Realisierung der Implementierung zu sein, ist die Planung von Pufferzeiten Pflicht.

Beide Varianten sind aber noch immer Notlösungen. Der einzig gangbare Weg, um zu vernünftigen Zeit- und Kostenplänen zu kommen, besteht darin, zuerst den Willensfindungsprozess abzuschließen, diesen in Form eines Anforderungsdokuments zu fixieren und dann den Realisierungsaufwand abzuschätzen.

Darüber sollten wir also nachdenken: Ein Modell, um bei vorgegebenen Budget und Liefertermin Puffer zu bestimmen!

Über eines sollte man sich stets im Klaren sein: Man lügt sich selbst in die Tasche, wenn eine Lieferzusage zu einem bestimmten Termin bei vorgegebenen Budget gegeben wird, ohne den genauen Leistungsumfang zu kennen. Dies gilt sowohl für Auftraggeber als auch Auftragnehmer. Insofern ist es eine berechtigte Frage, ob die hier angestellten Überlegungen seriös oder unseriös sind, denn wenn es schon soweit ist, ist etwas schief gegangen. Basis der Überlegungen ist, dass Budget und Liefertermin vorgegeben sind und sich daran nichts mehr ändern lässt, der Leistungsumfang jedoch nicht definiert ist und somit vor allem vom Budget abhängt, und dass man nur noch das Beste aus der Situation machen kann. Die Ursachen für derartige Projekte seien dahingestellt, sie kommen aber immer wieder vor und tragen wesentlich dazu bei, dass nur etwa ein Drittel aller Projekte als Erfolg verbucht werden kann.

Damit die einzelnen Projektphasen bei Budgetvorgaben vor Festlegung des geforderten Leistungsumfangs durchgeführt werden können, müssen einzuhaltende Meilensteine definiert werden. Kritisch ist dabei nur die Anforderungsanalyse. Werden zu viele Anforderungen spezifiziert, dann können sie nicht mehr im Budgetrahmen realisiert werden. Die Folgen sollten jeden Auftraggeber nachdenklich stimmen:
Vernüftig ist und bleibt daher, dass der Auftraggeber zuerst im Rahmen eines eigenen (Vor-) Projekts die Anforderungen bestimmt, dann über die Realisierung entscheidet und erst dann im Hauptprojekt die Anforderungen realisiert. U.U. zeigt sich schon nach einigen Tagen oder Wochen, dass das System komplexer und teurer wird, als vorgesehen, sodass ein Projektabbruch ohne großen Schaden möglich ist.

Jedes Prozess-Modell ist nur so gut wie seine Durchführung. Insofern ist jeder Ansatz davon abhängig, wie diszipliniert er sowohl von IT- als auch von Fachseite verfolgt wird, und wie gut er zum aktuellen Projekt passt. Dem Informatiker geht es nicht anders als dem Psychiater oder Psychotherapeuten, der mit hunderten von Analyse- und Therapie-Modellen arbeiten kann: am Ende geht es nur darum, dass dem Patienten geholfen wird.

Es ist eine Gesetzmäßigkeit, dass Planungen nicht eingehalten werden. Insofern gilt das Prinzip, dass ein Projekt erfolgreich sein muss, egal wie. Es geht, entgegen oder trotz aller Theorien, Ideen und Prozess-Modelle  für den einzelnen Mitarbeiter ebenso wie für ein Unternehmen darum, die Realität zu überleben. Das funktioniert am besten dadurch, dass man nicht in eine lebensbedrohliche Situation kommt.

Um die Realität zu überleben muss man sich an die Realität halten. Der Normalfall in IT-Projekten und vor allem in denen mit vorgegebenem Lierfertermin, vorgegebenem Budget und undefinierten Anforderungen ist, dass
Die Planungen müssen sich also an der Realität orientieren, um das Überleben zu gewährleisten, nicht an den Wünschen der Projektbeteiligten. Und die Realität beginnt im hier behandelten Szenario mit einem gewünschten Liefertermin und einem vorgegebenen Budget.

Die Grundforderung lautet: Das Projekt muss erfolgreich sein. Ehe ein Projekt überhaupt erfolgreich sein kann, muss er zuerst geboren werden. Die ersten drei Projektschritte lauten ungeachtet der weiteren Vorgehensweise:
  1. Formulierung der Idee
  2. Formulierung der Vision bzw. Mission
  3. Definition des Erfolges
Bevor nun für ein Projekt überhaupt Geld ausgegeben wird, muss festgestellt werden, ob ein Projekterfolg auf Basis der Vision oder Mission überhaupt vorstellbar ist, oder ob die Investition vollkommener Unsinn ist. Hierzu müssen die Randbedingungen betrachtet werden, die durch das Controlling vorgegeben sind: Zeit (=erster Einsatztermin), Budget, Qualität, Leistung. Aus Budget und den Tagessätzen der Entwickler lassen sich über den Daumen gepeilt die Länge der Projektphasen ermitteln. Da wir allerdings die Realität im Auge behalten wollen, gilt für Zeit- und Budgetplanung, dass nicht die gesamte Zeit und auch nicht das gesamte Budget verplant werden kann, wenn es statistisch sehr wahrscheinlich ist, dass die Planung falsch ist. Liefertermin und Kostenplanung sollen stattdessen der Realität so angepasst werden, sodass auch am Ende wirklich geliefert werden kann. Konkret gemeint ist damit, dass die Planung Pufferzeiten vorsieht, die die üblichen Verzögerungen kompensieren, und dass proaktiv nur die Anforderungen spezifiziert werden, die am Ende auch geliefert werden können. Als Denkansatz kann die Planung mit einer gekürzten Ressource Zeit, Geld und Leistung stattfinden, da man ja ohnehin von der Wirklichkeit eingeholt wird, und mehr ausgeben, mehr Zeit verbrauchen und einen geringerer Leistungsumfang implementieren wird, als geplant.

Anhand der Zahlen aus dem Abschnitt oben wissen wir, dass Budgets bei 43% der Projekte überzogen werden, in zwei Dritteln der Fälle um höchstens 20%. Wir wissen aber auch, dass vor einigen Jahren Überziehungen von 180% normal waren, dass also die aktuelle Zahl nicht verbindlich ist. Statistische Aussagen lassen sich zudem nicht auf den Einzelfall übertragen, aber selbst ein schlechter Ansatz in der richtigen Richtung ist besser, als gar keiner. Die zwangsläufige Schlussfolgerung aus dem Zahlenmaterial liegt nahe. Eine an die Realität angepasste Projektplanung muss einen Puffer enthalten und kann auf der Annahme basieren, dass nicht 100% des Budgets zur Verfügung stehen, sondern nur ca. 75%. Somit kann eine (realistische) Überziehung von einem Drittel ohne weiteres verkraftet werden, da man sich ja noch immer im Budget befindet. Von der Zeitplanung wissen wir, dass sie im Mittel um 82% überzogen wird. Als Liefertermin müßte also etwa nur die Hälfte oder zwei Drittel der möglichen Zeitspanne vorgesehen werden. Der nächste Schritt sieht als logische Konsequenz die Revision von Zeit- und Budgetplan vor. In gewissem Sinne hat dies sogar einen positiven psychologischen Effekt, dann man kann - umgerechnet auf die Laufzeit - mehr Geld in weniger Zeit ausgeben.

Als Erfahrungswert kann man ansetzen, dass die Anforderungsanalyse ca. 30% bis 40% des Projekts ausmacht. Da allerdings nur etwas mehr als die Hälfte (52%), vielleicht zwei Drittel der geforderten Leistung realisiert wird, kann auch davon ausgegangen werden, dass die Anforderungsanalyse in einem normalen Projekt zu umfangreich ist. Weshalb sollten Features im Detail spezifiziert werden, die schließlich doch nicht umgesetzt werden? Allerdings erfolgt die Selektion, welche Features nun tatsächlich umgesetzt werden, erst während der Realisierung des Projekts, und zwar immer dann, wenn selbst ein Blinder sieht, dass Zeit und Budget nicht mehr reichen. Dies ist eine reaktive Verhaltensweise.

Zum Zeitpunkt der Formulierung der Mission steht noch keine einzige Anforderung fest, häufig aber sehr wohl das Gesamtbudget und ein Liefertermin. Im Sinne des Vorgehensmodells Vorprojekt-Hauptprojekt ist dies ein grober Fehler, der zu den nachgewiesenen Überziehungen von Zeit und Budget bei reduziertem Lieferumfang führt. Die Realität sieht jedoch so aus, dass ein Budget vorgegeben ist, ohne dass zum Zeitpunkt der Budget-Festlegung die dafür gewünschte Leistung soweit im Detail bekannt ist, dass eine Kostenschätzung auch seriös sein kann. Die logische Konsequenz ist, dass die Anforderungsanalyse an das Budget angepasst wird. Wird nun ca. ein Drittel des Gesamtbudgets für die Anforderungsanalyse vorgesehen und auch so kommuniziert, so kann man sich empirisch betrachtet sicher sein, dass bereits dieser Budgetposten überschritten wird. Denken wir den Ansatz eines reduzierten bzw. um einen Murphyfaktor bereinigten Budget- und Zeitplans weiter, so ist ca. ein Drittel des reduzierten Budgets als erste Schätzung für den Umfang der Anforderungsanalyse brauchbar, um nahe an der Realität und den beinahe zwangsläufigen Überziehungen zu bleiben. Da ausserdem in der Realität ohnehin nicht alle geforderten Leistungen geliefert werden, kann eine weitere Kürzung stattfinden, vielleicht auf ein Viertel des reduzierten Budgets, was etwa dem Fowlerschen Wert von 20% des Gesamtbudgets entspricht.
  1. Das verplanbare Budget wird mit 75% des vorhandenen Budgets angesetzt. - Der Rest ist Puffer.
  2. Die Zeit bis zum Liefertermin wird um ca. 40% gekürzt. - Der Rest ist Puffer.
  3. Für die Spezifikationsphase werden etwa 25% des Projekts auf Basis des reduzierten Budgets angesetzt, was etwa 20% des Gesamtbudgets entspricht. - Der Rest ist Puffer.
Wie lange darf nun die Anforderungsanalyse dauern? Dies ist eine Frage der Entwicklerressoursen und des gewählten Prozess-Modells. Ich sehe hier ein lineares Modell vor. Wird ein evolutionäres oder nebenläufiges Modell gewählt, so können die bisherigen Planungen auf die einzelnen Iterationen herunter gebrochen werden. Es ist eine einfache Gleichung, wie aus der Anzahl der Entwickler der spätest mögliche Entwicklungsstart ermittelt werden kann, vorausgesetzt, die Entwickler arbeiten auch alle Vollzeit. Ein Viertel des reduzierten Budgets wird auf die Analysephase gebucht. Somit können (reduziertesBudget * 0.75) /  TagessatzEntwickler Entwicklertage vorgesehen werden. Entwicklertage / AnzahlEntwickler Werktage vor dem virtuell vorverlegten Liefertermin muss also angefangen werden. Diese Vorgehensweise, bei der gegenüber den Erfahrungswerten zur Dauer der Anforderungsanalyse zunächst den Entwicklern anteilig mehr Zeit als dem Analytiker zugebilligt wird ist insofern billig, als die Entwickler auf Basis der Anforderungsanalyse eine relativ genaue Abschätzung abgeben können. Bleibt Zeit übrig, so können noch immer zusätzliche Anforderungen spezifiziert und auch implementiert werden.

So könnte also die interne Planung für Pufferzeiten aussehen, die aus den Budget- und Terminvorgaben unter Berücksichtigung statistisch wahrscheinlicher Überziehungen zu einem realistischen Ansatz führt, der die Vorgaben erfüllen kann. Wie geht es nun im Projekt weiter?

Selbstverständlich wird die Fachabteilung und somit der Business Analyst zu diesem vorverlegten Termin nicht liefern. Man muss auch hier realistisch sein: Termine werden überzogen, der statistische Beweis ist dafür gegeben, und daher werden hier auch Pufferzeiten vorgesehen. Murphy lässt sich allerdings nicht erzwingen. Alle Projektbeteiligten, die von diesem Ansatz wissen, werden stets irgendwo im Hinterkopf haben, dass sie ja noch mehr Zeit und Geld haben, und deshalb den Planungen (zu) entspannt begegnen.
Exkurs in die echte Welt

Am Hauptbahnhof in Helsinki geht die Bahnhofsuhr um zwei Minuten vor. Irgendwann einmal kam ein neuer Mitarbeiter auf die Idee, die Uhr richtig zu stellen. Die Folge war, dass tausende Leute ihre Züge nicht erwischten, da sie davon ausgingen, dass die Uhr vorgeht. Die Uhr wurde wieder vorgestellt.
Die Frage in der Realität ist nicht, was sich die Fachanwender wünschen, wenn das Budget begrenzt ist, sondern immer, welche Anforderungen innerhalb des Budgets realisiert werden können. Der Analytiker braucht sich so gesehen daher auch nicht bemühen, ein möglichst vollständiges und perfektes System zu spezifizieren, das am Ende doch nicht realisiert wird. Statt dessen können sich Analytiker und Fachanwender am Budgetplan orientieren und definieren so viele Anforderungen so vollständig wie möglich im gegebenen Zeitrahmen. Dabei wird darauf vertraut, dass sich aus der Länge der Spezifikationsphase die Länge der Entwicklungsphase ableiten läßt. Ist das Budget für die verkürzte Spezifikationsphase aufgebraucht, so muss sie auch abgebrochen werden, sonst ist nichts gewonnen. Solch ein radikaler Schnitt hat zur Folge, dass die Spezifikation natürlich nicht fertig ist. In der üblichen Vorgehensweise ohne Puffer ist dies aber ebenfalls fast immer der Fall: Budgetüberziehungen sind eine Folge von zu realisierenden Forderungen, und die Aufnahme dieser Forderungen selbst verursacht ihrerseits Kosten. Egal ob mit oder ohne reduziertem Budget, irgendwann drängt die Zeit sosehr, dass die Spezifikationsphase abgebrochen werden muss. Im Projekt geht es dann wie folgt weiter:
  1. Die Anforderungen werden priorisiert und eine erste Produktversion wird definiert.
  2. Das Entwicklerteam beginnt sofort mit der Umsetzung der vollständig abgenommenen Teile der Spezifikation, d.h. mit dem Design- und soweit möglich mit dem Entwicklungsprozess.
  3. Parallel dazu wird die Spezifikation der ersten Produktversion vervollständigt, sofern man es erwartungsgemäß nicht geschafft hat, im reduzierten Zeitraum eine vollständige erste Version zu definieren. Auf Basis des reduzierten Budgets wird nun das Budget für den Analytiker überzogen, aber es bewegt sich noch im Rahmen des Gesamtbudgets. - Ohne Reduzierung und radikalem Schnitt beginnt nun bereits hier die Überziehung des Budgets.
  4. Das Entwicklerteam nimmt diese vervollständigten Prozesse mit auf und setzt die Entwicklung fort. - Normalerweise ist zu diesem Zeitpunkt die Stimmung im Team nicht gut. Anforderungen bewegen sich, vielleicht erst gestern erarbeitete Teillösungen müssen modifiziert werden, und es ist (bei üblicher voller Verplanung von Zeit und Budget) abzusehen, dass weder der Liefertermin eingehalten werden kann, noch, dass die Produktqualiät befriedigend sein wird.
  5. Mit den gemachten Erfahrungen wird nun hochgerechnet, wann das Projekt tatsächlich fertig sein und wie viel es kosten wird. - Dies ist der Zeitpunkt, zu dem Projekte abgebrochen werden. Der Kunde erfährt das erste Mal, wieviel er wirklich bezahlen muss, um alle seine Forderungen erfüllt zu bekommen, und bricht das Projekt ab oder reduziert den Leistungskatalog, wenn er die Möglichkeit dazu hat. Bei einem Ansatz mit reduziertem Zeit- und Budgetplan kann man nun sehen, wie weit die Puffer reichen.
  6. Stellt der Fachanwender fest, dass der bislang definierte Leistungsumfang nicht für einen Betrieb - selbst unter Berücksichtigung unbequemer workarounds - ausreicht, dann wird eine zweite Version definiert, die tatsächlich den Anforderungen des Anwenders genügt. Abhängig von der Budget- und Zeitsituation kann es sein, dass man noch ohne Überziehung fertig wird, aber nur, wenn tatsächlich Puffer vorgesehen waren. Bleibt noch Zeit und Geld übrig, können neue Anforderungen definiert werden, um die Anwendung "schön" zu machen, wünschenswerte aber nicht notwendige Leistungen zu implementieren oder die Qualität zu erhöhen.
Offensichtlich können dabei die Wünsche der Fachanwender bzw. des Auftraggebers zu kurz kommen. Der Unterschied zu den üblichen Prozess-Modellen besteht bei diesen Überlegungen lediglich darin, dass davon ausgegangen wird, dass dies ohnehin passieren wird. Obwohl nicht das gesamte geforderte Leistungsspektrum geliefert wird, werden Produkte in der Geschäftswelt trotzdem akzeptiert und abgenommen. Das Prinzip dieser Überlegungen orientiert sich an der Realität und statistischen Aussagen über Projekterfolge. Es baut darauf, dass proaktiv die statistisch messbaren Abweichungen normaler Planungsmethoden ebenfalls statistisch kompensiert werden. Ziel ist es, Budget- und Zeitpläne einzuhalten und die spezifizierten Anforderungen zu liefern. Dazu werden auch nur die Anforderungen spezifiziert, die tatsächlich im Zeit- und Kostenplan umgesetzt werden können.

Die hier vorgestellten Zahlen sind lediglich statistische Größen zur Ermittlung von Pufferzeiten, die das einzelne Unternehmen nicht davon befreien, eigene Metriken zu erstellen, um zu Murphyfaktoren zu kommen, die der individuellen Situation gerecht werden.

Proaktives handeln ist gefragt. Hoffnung, so sagt ein Sprichwort, ist ein gutes Frühstück, aber ein schlechtes Abendessen.
home - top - Kontakt - letzter Update 11.6.2004 - © Karl Scharbert