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:
- Zeit
- Budget
- Qualität
- Leistung
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:
(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:
- Er reduziert die Anforderungen, sodass das Produkt billiger wird.
- 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:
- Welche Kosten fallen für die Entwicklung an?
- Welche Kosten fallen im laufenden Betrieb an? Gemeint damit sind
hochgerechnet auf die prognostizierte
Lebensdauer der Software die Wartungskosten, Kosten für
Software-Pflege, für evtl. notwendige Geräte und für die
Arbeitszeit der Fachanwender, wenn sie das IT-System benutzen.
- Welche Kosten fallen an, wenn der Fachanwender eine andere
Lösung findet, z.B. mit Tabellenkalkulationssystemen oder
manueller Arbeit?
- Wie zeitkritisch ist der Prozess im Tagesgeschäft?
- Wie sind die Qualitätsanforderungen an den Prozess? Wie genau
müssen die Ergebnisse sein?
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:
- Wie hoch ist der Gewinn an Lebens- und Arbeitsqualität aus
einer Lösung?
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
- einen höheren Preis zu erzielen
- höhere Verkaufszahlen zu erreichen
- den Marktanteil zu erhalten oder zu erhöhen.
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:
- Wie will der Frager die Software billiger herstellen?
- Wogegen werden die Kosten der Software gemessen?
Als Frager muss man sich diese Gegenfragen gefallen lassen.
- 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.
- 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.
- Teuer sind Planungsfehler, die zu Produkten führen, die die
Investition nicht einspielen.
- Teuer ist es, wenn man Budgetüberziehungen in unbekannter
Höhe billigend und schweigend in Kauf nimmt, wenn man sich erst
auf ein Budget und dann auf einen damit nicht in Einklang zu bringenden
Leistungsumfang festlegt.
- Teuer ist es, wenn man spart, koste es, was es wolle, vor
allem, wenn Personal nach den Kosten und nicht nach den
Fähigkeiten
ausgewählt wird.
- Teuer ist es, wenn auf Schulung und Fortbildung des Personals
verzichtet wird.
- Teuer ist es, aus gemachten Fehlern nicht zu lernen und
Qualitätsmanagement als Kostenfaktor zu betrachten.
- Teuer ist es, wenn in der Analysephase Fehler gemacht werden oder
wenn die Analysephase unnötig in die Länge gezogen wird, da
keine verbindlichen Entscheidungen gefällt werden und kompetente
Auskünfte nicht eingeholt werden.
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.
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.
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.
Schwimmende
Eispyramiden
Stellen wir uns eine Pyramide aus Eis mit vergoldeter Spitze vor, die
im Wasser schwimmt. Das würde wohl etwa so aussehen:
Gold ist schön, teuer und schwer. Ohne das Eis darunter wäre
das Resultat etwa so:
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:
- Der Auftragnehmer wurde zu spät mit der Realisierung des
Produkts betraut oder es gab in der Spezifikationsphase erhelbliche
Zeitverzug, evtl. wurden auch zu viele Anforderungen aufgenommen.
- Ein Prototyp kann nicht gebaut werden, dafür fehlt die Zeit.
Evtl. hat man sich auch geeinigt, Teile der Anforderungen auf Zuruf zu
klären.
- Das Screen-Design der Oberfläche ist in zweiter oder dritter
Version fertig, die Oberfläche ist aber noch nicht mit der
Funktionalität vollständig abgestimmt.
- Der Auftraggeber wird nervös, er hat kein Vertrauen mehr zum
Auftragnehmer, da man nichts sehen kann. Er übt Druck auf
den Projektleiter des IT-Teams aus, um endlich Resultate zu sehen.
- Der Projektleiter kommt seiner Pflicht nicht mehr nach, sein Team
zu schützen und ihm ungestörtes Arbeiten zu ermöglichen.
Er gibt den Druck an das Team weiter.
- Man entscheidet sich daher, vom geplanten Software-Design
abzuweichen, und eine provisorische (Zwischen-) Lösung zu liefern,
die das Bedürfnis nach sichtbaren Teilen befriedigt.
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:
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:
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:
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.
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.
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:
- Die Aufwandsabschätzung wird aktualisiert,
das Buget und der Liefertermin werden angepasst.
- 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:
- Wenn einerseits schon auf Grund der Budgetgrenzen die
Anforderungsanalyse vorzeitig abgebrochen werden muss, können
sicher
nicht die Wünsche im Sinne eines vollständigen Systems
festgehalten
werden.
- Wenn andererseits die Anforderungsanaylse vollständig sein
soll, bleibt ziemlich sicher nicht genügend Budget und Zeit
übrig, um auch alle Wünsche zu realisieren.
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
- in bürokratischen Strukturen eingebundene Fachanwender nicht
diszipliniert die strikten Zeitpläne eines IT-Projekts einhalten.
Daraus folgt häufig eine zeitlich in die Länge gezogene
Spezifikationsphase (=Überschreitung des Zeitplans).
- Fachanwender ohne Unterstützung nicht ausreichend gute
Vorgaben liefern, um ein IT-System zu bauen. Dadurch, dass dies nicht
beachtet wird, werden Projektpläne zu knapp gehalten und
Liefertermine zu früh geplant.
- sich geschäftliche Anforderungen bewegen oder Fachanwender
Entscheidungen mehrfach hin und her revidieren. Daraus folgt
häufig Zeitverschwendung durch sich wiederholende
Spezifikationsarbeiten, die nicht kompensiert werden kann
(=Überziehung des für die Analysephase geplanten
Aufwands und des Budgets)
- Festlegungen im Fachbereich vermieden bzw. keine verbindlichen
Entscheidungen gefällt werden. Daraus folgt häufig eine
zeitlich in die Länge gezogene Spezifikationsphase.
- bürokratische Paralyse und Budgetgrenzen auch innerhalb von
IT-Abteilungen dafür sorgen, dass für die Entwicklung
wichtige Mittel nicht ohne weiteres zur Verfügung stehen.
- Entwickler stets nach einer schönen und möglichst guten
Lösung suchen, nicht nach einer Lösung, die gerade noch gut
genug für den Moment ist.
- generell Ressourcenmangel herrscht und Projektmanagement
häufig Mangelverwaltung bedeutet.
- persönliche und politische Interessen einen Projekterfolg
vereiteln können.
- der von den Fachanwendern gewünschte Liefertermin
häufig vollkommen illusorisch ist und regelmäßig
überschritten werden.
- das Budget vor Projektbeginn feststeht und trotzdem
regelmäßig überzogen wird.
- nicht alle spezifizierten bzw. geforderten Leistungsmerkmale des
Produkts erfüllt werden.
- reaktives Verhalten dominiert.
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:
- Formulierung der Idee
- Formulierung der Vision bzw. Mission
- 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.
- Das verplanbare Budget wird mit 75% des vorhandenen Budgets
angesetzt. - Der Rest ist Puffer.
- Die Zeit bis zum Liefertermin wird um ca. 40% gekürzt. - Der
Rest ist Puffer.
- 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:
- Die Anforderungen werden priorisiert und eine erste
Produktversion wird definiert.
- 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.
- 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.
- 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.
- 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.
- 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