der Aufbau oder die Verstärkung eines guten Rufs durch einen positiven Eindruck auf den Kunden und auf den Markt,Nachdem in Kapitel 7 die statischen Strukturen betrachtet wurden, die in Software-Projekten vorkommen, geht es in diesem Kapitel um die Durchführung der Projekte und damit auch um die Rolle, die der Projektleiter spielt. Wir gehen nachfolgend von einem starken Projektleiter aus, wie er vor allem in der reinen Projektorganisation auftritt.
Projektmanagement hat immer zum Ziel, das Projekt erfolgreich durchzuführen und abzuschließen. »Erfolgreich« bedeutet, dass das Projekt die definierten Resultate in der geforderten Qualität innerhalb der vorgegebenen Zeit und mit den vorgesehenen Mitteln erzielt. Weitere sekundäre Ziele sind in der Regel
der Aufbau oder die Verstärkung eines guten Rufs durch einen positiven Eindruck auf den Kunden und auf den Markt,
die Aneignung von Kenntnissen, die zukünftig benötigt werden,
die Entwicklung wiederverwendbarer Komponenten,
die Wahrung eines attraktiven Arbeitsklimas für die Mitarbeiter.
Damit diese Ziele erreicht werden, muss das Projekt aktiv geleitet werden. Die Aktivitäten des Projektmanagements haben folgende Schwerpunkte:
Planen
Ohne Pläne kann ein Projekt nicht geführt werden; Planungsfehler lassen sich später selbst durch hochklassige Technik nicht kompensieren.
Bewerten und kontrollieren
Die Arbeitsergebnisse und der Projektfortschritt müssen bewertet werden; es muss überwacht werden, ob sich die Beteiligten an Vereinbarungen und Absprachen halten.
Kommunizieren
Der Projektleiter steht zwischen dem Management, dem Kunden oder dem Marketing und den Mitarbeitern. Für das Management repräsentiert er das Projekt, für den Kunden die Herstellerfirma, für das Marketing die Technik, für die Mitarbeiter die Leitung der Firma. Entsprechend unterschiedlich sind die Erwartungen, denen er genügen soll. Nur wenn er auf allen Seiten zuhört und nach allen Seiten Informationen weitergibt, hat er eine Chance.
Günstige Rahmenbedingungen schaffen und erhalten
Ein Projekt gedeiht am besten, wenn die Mitarbeiter, ausgestattet mit der notwendigen Infrastruktur, konzentriert und ungestört stabile Ziele verfolgen können. Aber um das Projekt herum gibt es wankelmütige Kunden, unklare Zielsetzungen, Restrukturierungen, Sparmaßnahmen, enge Büros, lange Wege und andere Projektleiter, die versuchen, Mitarbeiter zu »stehlen«. Es ist Aufgabe des Projektleiters, das Projekt vor diesen störenden Einflüssen zu schützen.
Mitarbeiter führen und motivieren
Führen heißt: vorangehen, den Weg zeigen, auch die Gruppe mitziehen. Die meisten Entwickler wollen gute Leistungen erbringen, brauchen aber auch Orientierung und Bestätigung.
Schwierigkeiten möglichst früh erkennen und bekämpfen
Unvorhergesehene Schwierigkeiten und Probleme sind im Projekt nicht die Ausnahme, sondern die Regel. Darum muss der Projektleiter den Horizont regelmäßig nach Eisbergen absuchen und, wenn er einen entdeckt hat, rasch und wirksam reagieren. Er muss also systematisches Risikomanagement betreiben.
Manche Software-Projekte sind von Beginn an scharf konturiert. Das ist bei Systemprojekten (siehe Abschnitt 7.3.4) der Fall, wenn die Software Bestandteil eines größeren Systems sein wird, über dessen Entwicklung schon entschieden wurde. Ist zudem klar, dass man die benötigte Software nicht einkaufen kann, so gibt es an der Durchführung des Software-Projekts keine Zweifel. Meist ist dann nur noch zu entscheiden, ob die Arbeit nach außen vergeben oder im eigenen Hause durchgeführt werden soll.
In sehr vielen Fällen gibt es aber zu Beginn weit mehr Unklarheiten, auch die, ob das Projekt überhaupt zustande kommt. Typisch sind folgende Situationen:
Ein Software-Haus bemüht sich in Konkurrenz mit anderen Anbietern, einen Auftrag zu erhalten.
Software-Entwickler schlagen vor, ein Werkzeug zu entwickeln, das bestimmte oft durchzuführende Arbeiten erheblich erleichtern würde.
Die Marketing-Abteilung weist auf einen Trend hin, durch den der Bedarf an bestimmten Software-Produkten erheblich steigen wird, und schlägt vor, rechtzeitig ein solches Produkt zu entwickeln.
Mitarbeiter einer Bank wünschen eine neue Software für die Kundenberatung, weil die vorhandene veraltet und unflexibel ist.
Die mit der Software-Wartung befassten Mitarbeiter schaffen es kaum noch, die notwendigen Anpassungen vorzunehmen, und drängen darauf, die alte Software nicht weiter zu flicken, sondern durch eine neue zu ersetzen.
Allen diesen Situationen ist gemeinsam, dass zunächst niemand wirklich weiß, welche Entscheidung richtig ist.
Natürlich müssen Aufträge akquiriert werden, aber durch ein zu billiges Angebot kann sich der Anbieter ruinieren; ein zu teures Angebot hat keine Chance.
Wird der Nutzen des Werkzeugs die Kosten übersteigen? Ist überhaupt die personelle Kapazität für eine Werkzeugentwicklung verfügbar?
Haben wir das Know-how, um das neue Produkt zu entwickeln, und können wir es rechtzeitig auf den Markt bringen?
Liegt das Problem wirklich in der Software, oder brauchen die Mitarbeiter einfach neue Rechner, moderne Bildschirme oder eine bessere Vernetzung?
Könnte man die Probleme der Wartung auch dadurch entschärfen, dass man Änderungswünsche der Anwender sachlich prüft, statt sie grundsätzlich zu akzeptieren?
Wie man sieht, ist die Vorstellung, dass ein Projekt einfach beschlossen und begonnen werden könnte, allzu naiv. Meist brauchen wir ein Vorprojekt.
Das Vorprojekt führt von der Projektidee (»Wir könnten dieses Projekt machen«) zum Beschluss oder zur Feststellung über das Projekt (»Wir machen dieses Projekt« oder »Wir machen es nicht«).
Das Projektmanagement erfordert immer wieder Kompromisse, weil sich keines der Projektziele in reiner Form verwirklichen lässt. Das gilt ganz besonders für das Vorprojekt. Wenn am Ende eine negative Entscheidung steht, ist der investierte Aufwand verloren. Das spricht für eine enge Begrenzung des Aufwands.
Andererseits ist es notwendig, alle Informationen zu beschaffen und zu verarbeiten, die für eine leidlich zuverlässige Aufwandsschätzung benötigt werden. Eine zu hohe Schätzung kann eine in Wahrheit sinnvolle, rentable Entwicklung verhindern. Eine zu niedrige Schätzung ist noch schlimmer: Die personelle Kapazität wird länger gebunden, als vertretbar ist, die Kosten werden durch den zu niedrig angesetzten Preis nicht hereingeholt, und im Fall eines Auftragsprojekts wird der Ruf des Anbieters beschädigt.
Im (nicht erreichbaren) Idealfall hat man am Ende des Vorprojekts alle Informationen, die für die Entscheidung über das Projekt benötigt werden. Bei einem Auftragsprojekt weiß man, wie weit man sich bei den Terminen und beim Preis aus dem Fenster lehnen darf, beim EDV-Projekt kennt man die Kosten und die Dauer des Projekts, und bei einem Entwicklungsprojekt kann man vorhersagen, wann und in welchen Schritten die Markteinführung möglich und welcher Erfolg zu erwarten ist.
Dazu ist vor allem eine Aufwandsschätzung nötig, verbunden mit der Analyse, ob die richtigen Leute zum richtigen Zeitpunkt verfügbar sein werden. Das erfordert eine ungefähre Vorstellung von der Struktur des Systems und der eingesetzten Technologie, und diese hängen wiederum von den Anforderungen ab. Wir benötigen also:
einen Überblick über die wichtigsten Anforderungen, vor allem solche, die den Aufwand erheblich beeinflussen,
eine Konzeption, die Architektur des Systems, freilich ohne Details, aber mit den wichtigsten Entscheidungen über die einzusetzende Technologie,
einen Entwicklungsplan,
eine Aufwandsschätzung.
Es hat sich bewährt, das Vorprojekt in einer kleinen Gruppe (das sind bei einem kleinen bis mittelgroßen Projekt zwei bis fünf Leute) durchzuführen, in der sowohl Kenntnisse des Anwendungsbereichs als auch der Technik vertreten sind. Die Zusammenarbeit ist eng und kaum reglementiert. Der insgesamt investierte Aufwand liegt typischerweise bei wenigen Prozent der Entwicklungskosten.
Soll ein Auftrag akquiriert werden, dann ist das Ergebnis des Vorprojekts das Angebot. Darin beschreibt der Anbieter, was er wann zu welchem Preis liefern kann. Ein Angebot enthält also:
eine Beschreibung des zu liefernden Systems,
Alleinstellungsmerkmale des Angebots,
einen Plan mit den externen Meilensteinen des Projekts (Abschnitt 8.3.3),
Hinweise zum weiteren Vorgehen (Kontaktpersonen).
Das zu liefernde System sollte so beschrieben werden, dass sich der Auftraggeber darin wiederfindet. Das schließt in der Regel eine rein technische Beschreibung aus. Stattdessen sollte der Auftraggeber erkennen, wie er später das System benutzen und von diesem profitieren kann. Der Anbieter muss dazu die Perspektive des Auftraggebers einnehmen. Ein guter Prototyp ist in vielen Fällen ein überzeugendes Argument.
Das bedeutet: Es ist falsch, das System als Maschine zu beschreiben. (»Wir liefern Ihnen eine Software auf der Basis der Technologie XYZ mit den folgenden technischen Merkmalen: ...«) Viel besser ist es, ein Szenario zu entwerfen, in dem der Auftraggeber vorkommt. (»Sie können auf diese Weise Ihre alten Kundendaten ohne weitere Bearbeitung übernehmen und an dieser Bedienschnittstelle jederzeit abfragen, wo sich eine bestimmte Lieferung gerade befindet.«)
Die Alleinstellungsmerkmale können ganz unterschiedlicher Art sein. Es kann sich um eine besonders elegante Bedienung handeln, um die garantierte Zuverlässigkeit oder um die sehr bescheidene Inanspruchnahme der Ressourcen, z. B. des Speichers. Auch die Art der Projektdurchführung kann ein Alleinstellungsmerkmal sein. In jedem Falle muss es sich um Merkmale handeln, die über die Anforderungen hinausgehen, für den Auftraggeber attraktiv erscheinen und für den Anbieter keinen erheblichen Mehraufwand verursachen.
Bei der Akquise eines Auftrags spielt natürlich auch die Erwartung eine Rolle, ob und in welchem Maße man sich bei der Wartung der zu entwickelnden Software schadlos halten kann. Es ist offensichtlich, dass in dieser Phase oft mehr gepokert als technisch argumentiert wird.
Das Vorprojekt schafft die Grundlagen für die Entscheidung über das Projekt. Kommt das Projekt tatsächlich zustande, sollte der im Vorprojekt eingesetzte Aufwand weiter genutzt werden, denn es sind ja bereits einige Dokumente entstanden – natürlich nur rudimentär:
Anforderungen wurden erhoben.
Die Architektur ist wenigstens grob entworfen.
Eine erste Aufwands- und Kostenschätzung wurde angefertigt.
Ein Plan für die Durchführung wurde erstellt.
Alle diese Dokumente sind für die weitere Entwicklung nützlich, wenn sie ausreichend strukturiert, nachvollziehbar formuliert und verfügbar sind. Besonders wichtig ist es, die Quellen aller Anforderungen zu notieren; in vielen Fällen ist es später nötig, Quellen zu überprüfen, bei den Gesprächspartnern nachzufassen oder mit ihnen über Alternativen zu verhandeln.
Vor allem, wenn kein externer Auftraggeber beteiligt ist, besteht eine starke Neigung, das Vorprojekt gleitend ins Projekt übergehen zu lassen. Da das eigentliche Projekt wesentlich weiter gehenden Regeln unterliegt, sollte sein Beginn (und damit das Ende des Vorprojekts) sehr deutlich signalisiert werden. Eine Vermischung der Phasen beschädigt den Entwicklungsprozess.
Ein Software-Projekt konkretisiert sich in einem Zeitraum zwischen zwei Ereignissen: der Entscheidung des Auftraggebers, ein Software-System entwickeln zu lassen, und dem eigentlichen Startschuss des Projekts. Dieser fällt, wenn der Projektplan in Kraft gesetzt wird. Dazwischen liegt die Definition des Projekts, die sogenannte Startphase. In dieser Phase wird der Projektleiter ernannt. Er verkörpert das Projekt, vertritt es nach außen und innen und bildet die Keimzelle des Projektteams.
Seine erste und wichtigste Aufgabe ist es, auf der Grundlage eines mehr oder weniger klar und vollständig formulierten Projektauftrags einen Vorgehensplan zu erstellen und die Rahmenbedingungen zu gestalten, unter denen das Projekt durchgeführt wird. Wichtige Teilaufgaben der Planung sind:
Abgrenzen des Liefer- und Leistungsumfangs
Definieren und Gliedern der Aufgaben
Festlegen des Berichtswesens innerhalb des Projektteams sowie an der Schnittstelle zum Auftraggeber
Abschätzen des Personalbedarfs (Anzahl und Qualifikation der benötigten Mitarbeiter)
Erstellen des Budgets und der Terminpläne
Verteilen der Aufgaben über die Rollen
Bereitstellen der notwendigen Unterstützung (Dienstleistungen)
Identifizieren von Risiken
Das Resultat dieser Tätigkeiten ist der Projektplan (siehe Abschnitt 8.3.3). Darin beschreibt der Projektleiter, wie das Projekt durchgeführt werden soll. Nachdem der Projektplan durch den Projekteigentümer und den Auftraggeber bestätigt und in Kraft gesetzt wurde, beginnt der produktive Teil des Projekts, die Durchführungsphase.
Ein Plan ist die geistige Vorwegnahme des zukünftigen Handelns. Wenn wir ein Projekt planen, dann legen wir auf der Basis des aktuellen Wissensstandes fest, wie und mit welchen Mitteln wir das Projekt durchführen wollen. Da wir das nicht exakt tun können, stimmen die Pläne nie exakt mit dem realen Verlauf überein. Eine gewisse Spannung zwischen Soll und Ist lässt sich nicht vermeiden. Das gilt insbesondere, wenn weit in die Zukunft geplant werden muss.
Diese Schwierigkeit ist aber kein Grund, eine brauchbare Planung als Utopie abzutun. Indem wir Risiken und Schwankungen der Bedingungen bereits in der Planung berücksichtigen, sorgen wir dafür, dass wir insgesamt im Plan bleiben. Ein Forschungsreisender, der Probleme mit dem Kompass hat, sollte den Kompass nicht wegwerfen, sondern ihn mit mehr Bedacht gebrauchen.
Planung ist die zentrale Aktivität in der Startphase, zudem ist sie Bestandteil des Regelkreises der Projektdurchführung (siehe Abschnitt 8.5.1). Weil sich Pläne von der Realität lösen können, muss während der Projektdurchführung kontinuierlich geprüft werden, inwieweit der Stand des Projekts (Ist-Werte) mit der Planung (Soll-Werte) übereinstimmt. Wird eine erhebliche Abweichung festgestellt, dann müssen Korrekturmaßnahmen ergriffen werden. Möglicherweise muss auch die Planung korrigiert werden. In Abschnitt 8.5 stellen wir einige Ansätze vor, um den Projektstand zu bestimmen. Prinzipiell muss die Planung die folgenden Aspekte abdecken:
Planung der Aufgaben
Dabei wird festgelegt, was zu tun ist, um die Projektziele und Projektleistungen zu erreichen. Das Ergebnis der Aufgabenplanung sind Arbeitspakete. Die Aufgabenplanung ist eine Voraussetzung, um Termine und Ressourcen planen zu können.
Planung der Termine
Es ist festzulegen, wann welche Resultate verfügbar sein sollen. Dazu gehört die Terminplanung für die Meilensteine und die Releases, wenn das System in Ausbaustufen entwickelt wird. Natürlich ist auch der Endtermin anzugeben.
Planung der Ressourcen
Um die definierten Arbeitspakete zu bearbeiten, werden Ressourcen (im weitesten Sinne) benötigt, vor allem der Aufwand der Mitarbeiter (in Personentagen). In Abschnitt 8.4 gehen wir näher darauf ein, wie dieser Aufwand geschätzt werden kann. Auf der Basis dieser Schätzungen kann geplant werden, wann wie viele Mitarbeiter mit welchen Qualifikationen benötigt werden. Weiterhin müssen die Kosten für Hardware, Software und andere Investitionen eingeplant werden, die das Projekt benötigt. Sind alle diese Zahlen ermittelt, kann geplant werden, welches Budget zu welchem Zeitpunkt im Projekt sinnvoll und erforderlich ist.
Bevor Termine, Zeiten und Aufwände geplant werden können, müssen die Aufgaben identifiziert werden, die zu lösen sind, um die Projektziele zu erreichen. Dies geschieht natürlich auf verschiedenen Granularitätsstufen. Zuerst werden die großen Aufgabenbereiche ermittelt, dann werden sie verfeinert. Die Aufgaben werden folgendermaßen identifiziert: Die Gesamtaufgabe wird so lange baumartig in Unteraufgaben zerlegt, bis die Blätter des so entstehenden Aufgabenbaums nicht weiter aufgeteilt werden müssen, weil sie Arbeitspakete definieren, die jeweils separat geplant, durchgeführt und kontrolliert werden können.
Ein Arbeitspaket ist eine Aufgabe, die ein Entwickler oder ein kleines Team in überschaubarer Zeit, höchstens einem Monat, mit gut planbarem Aufwand lösen kann. Die Arbeitspakete sind die Atome der Projektplanung, eine weitere Verfeinerung ist aus Sicht der Planung weder sinnvoll noch notwendig.
Eine Aufgabe ist als Arbeitspaket geeignet, wenn
sie durchgängig erledigt werden kann, ohne dass es Koordinationszwänge gibt,
der Fortschritt und das Ende objektiv feststellbar (messbar) sind,
es Ereignisse gibt, die Anfang und Ende bestimmen, und
der Aufwand und die Termine schätzbar sind.
Auch wenn diese Kriterien in der Praxis nicht immer zu erfüllen sind, sollte man sich von ihnen leiten lassen. Das Ergebnis der Aufgabenplanung ist immer eine Liste von Arbeitspaketen. Es hat sich bewährt, die Gliederung der Aufgaben in einer grafischen Baumdarstellung oder in einer strukturierten Liste zu visualisieren (siehe Abb. 8–1). Als Ergebnis erhalten wir den sogenannten Projektstrukturplan (engl. work breakdown structure).
Abb. 8–1 Beispiel eines Projektstrukturplans
Prozessmodelle wie das V-Modell (Abschnitt 10.3) oder der Unified Process (Abschnitt 10.4) erleichtern die Aufgabenplanung, da sie Phasen und die durchzuführenden Entwicklungsaktivitäten vorgeben und somit eine generische Struktur für die Aufgabenplanung bieten.
Eine Phase ist ein zusammenhängender, also nicht unterbrochener Zeitraum, in dem bestimmte Arbeiten durchgeführt und abgeschlossen werden. Am Ende der Phase steht ein Meilenstein. Die Phase ist erfolgreich beendet, wenn die Kriterien, die der Meilenstein vorgibt, erfüllt sind. Typischerweise beginnt dann die nächste Phase. Die Phasen überlappen sich also nicht; allerdings kann es in größeren Projekten verschiedene Entwicklungsstränge geben, die parallel ablaufen und durch unterschiedliche Meilensteine gegliedert sind.
Die Aufteilung eines Projekts in Phasen erleichtert die Kontrolle, da nicht das gesamte Projekt auf einmal betrachtet und finanziert werden muss, sondern jeweils nur ein einzelner Abschnitt. Am Meilenstein, d. h. an der Prüfung der Zwischenergebnisse, ist der Kunde beteiligt.
Die Granularität der Phasengliederung ist kritisch; sind die Phasen sehr kurz, so wird der Kunde laufend in Anspruch genommen, und es gibt keine Freiräume für eine ruhige Entwicklung. Sind die Phasen zu lang, so kann es innerhalb der Phasen zu erheblichen Verzögerungen kommen, die erst am Ende der Phase auffallen. Darum werden, wenn nötig, neben den oben beschriebenen externen Meilensteinen interne Meilensteine eingeführt, an denen der Kunde nicht beteiligt ist.
Externe Meilensteine definieren Ergebnisse, die aus Sicht des Auftraggebers von Bedeutung sind, z. B. das Vorliegen bestimmter Dokumente, eines Prototyps oder einer ersten Ausbaustufe. Bei externen Meilensteinen entscheidet der Auftraggeber nach Bewertung der erzielten Ergebnisse, ob die Arbeitspakete der nächsten Phase in Angriff genommen werden dürfen. Je nach Vertrag können mit dem Erreichen von Meilensteinen auch Zahlungen des Auftraggebers verbunden sein.
Interne Meilensteine sind dann sinnvoll, wenn der Zeitraum zwischen zwei externen Meilensteinen so groß ist, dass Zwischenkontrollpunkte eingeführt werden sollten. Diese müssen aus Sicht des Projektleiters geeignet sein, den Fortschritt des Projekts sichtbar und messbar zu machen.
Wichtig ist, dass es für das Erreichen eines Meilensteins Kriterien gibt, die keinen Raum für Subjektivität (und damit Willkür) lassen. Es muss sich also objektiv feststellen lassen, ob alle Voraussetzungen zum Erreichen eines Meilensteins erfüllt sind. Zur Definition eines Meilensteins gehören demnach
die Definition der Ergebnisse, die vorliegen müssen,
die geforderten Qualitätseigenschaften dieser Ergebnisse,
die Instanz (Person oder Gremium), die entscheidet, ob der Meilenstein erreicht ist, und
der vorgesehene Zeitpunkt für das Erreichen des Meilensteins.
Damit die in einem größeren Unternehmen durchgeführten Projekte nach einem einheitlichen Schema organisiert und durchgeführt werden, verwenden diese Unternehmen oft eigene Prozessmodelle, die allen Projekten Standardphasen und Meilensteine vorgeben.
Abb. 8–2 Das ABB-Gate-Modell (aus Fröhlich, Lichter, Zeller, 2001)
Abbildung 8–2 zeigt ein solches Beispiel: Das Prozessmodell definiert drei Projektphasen und sieben externe Meilensteine, die Gates genannt werden (Cooper, 2001). An jedem dieser Meilensteine sind spezifische Ergebnisse vorzulegen; dann wird entschieden, ob das Projekt weitergeführt werden kann oder abgebrochen werden muss.
Damit die definierten Arbeitspakete zeitlich sinnvoll angeordnet werden können, müssen die folgenden Einflüsse berücksichtigt werden:
Logische Abhängigkeiten zwischen Arbeitspaketen
So muss der Entwurf eines Moduls vorliegen, bevor es codiert werden kann.
Aufwand für die Arbeitspakete
Einflüsse von außen
Lieferungen der Hardware und zugekaufter Software, Bereitstellung von Daten, Algorithmen usw. durch den Auftraggeber sowie die Bestätigung der Abnahme von Zwischenresultaten sind wichtige Ereignisse, die der Projektleiter nicht direkt beeinflussen kann.
Verfügbarkeit von Mitarbeitern und Betriebsmitteln
Die Verfügbarkeit von Spezialisten, der Zugriff zu Rechen- oder Testeinrichtungen, eventuell konkurrierend mit anderen Projekten, schaffen zusätzliche Einschränkungen.
Werden die logischen Abhängigkeiten zwischen den Arbeitspaketen und den externen Ereignissen ermittelt und dargestellt, dann wird ersichtlich, welche Arbeitspakete von der Sache her nur nacheinander und welche auch gleichzeitig ausgeführt werden können. Es gibt in der Praxis die folgenden drei Anordnungsbeziehungen zwischen Arbeitspaketen:
Normalfolge (Ende-Anfang-Beziehung)
Das Ende eines Arbeitspakets ist Voraussetzung für den Anfang eines anderen Arbeitspakets. Beispiel: Die Testumgebung muss installiert sein, bevor mit dem Test begonnen werden kann.
Anfangsfolge (Anfang-Anfang-Beziehung)
Der Anfang eines Arbeitspakets ist Voraussetzung für den Anfang eines anderen Arbeitspakets. Beispiel: Die Codierung muss begonnen haben, bevor mit der externen Code-Dokumentation begonnen werden kann.
Endfolge (Ende-Ende-Beziehung)
Das Ende eines Arbeitspakets ist Voraussetzung für das Ende eines anderen Arbeitspakets. Beispiel: Die Evaluierung des Prototyps muss abgeschlossen sein, bevor die Anforderungsanalyse abgeschlossen werden kann.
Terminpläne werden mit Balkendiagrammen (Gantt-Charts) und Netzplänen (PERT-Charts) dargestellt. Die Gantt-Charts sind nach dem amerikanischen Ingenieur Henry L. Gantt benannt, der sie 1917 eingeführt hat (Abb. 8–3). PERT steht für Program Evaluation Review Technique; diese Netzpläne sind in den Fünfzigerjahren in der US-Militärindustrie entstanden. In Netzplänen werden im Unterschied zu Balkendiagrammen die Abhängigkeiten zwischen den Arbeitspaketen explizit dargestellt. Wenn zusätzlich deren Dauer und der Starttermin des Projekts bekannt ist, kann für jedes Arbeitspaket ermittelt werden,
wann es frühestens begonnen und frühestens beendet werden kann,
wann es im Hinblick auf den Endtermin des Projekts spätestens begonnen und beendet werden muss.
Abb. 8–3 Gantt-Chart mit Meilensteinen
Arbeitspakete, deren Dauer (d. h. auch: deren Verzögerung) direkt auf den Endtermin durchschlägt, werden kritische Arbeitspakete genannt. Sie bilden den kritischen Pfad, der besonders überwacht werden muss. Im Beispiel in Abbildung 8–4 sind die Arbeitspakete auf dem kritischen Pfad farblich hervorgehoben.
Abb. 8–4 PERT-Chart (Netzplan) mit kritischem Pfad
Die Erstellung und Nachführung von Netzplänen wird durch Planungswerkzeuge unterstützt, die in steigender Zahl angeboten werden. Sie erleichtern dem Projektleiter die Arbeit, bergen aber zwei Gefahren: Je ansprechender, »fertiger«, die Darstellung erscheint, umso eher ist man geneigt, sie leichtfertig für sinnvoll zu halten (der bekannte Hochglanzeffekt). Und Abweichungen vom Plan lassen sich mit Werkzeugunterstützung leicht beseitigen, indem man die Pläne laufend der Realität anpasst. Da wedelt der Schwanz mit dem Hund. Das ist natürlich nicht sinnvoll.
Die Netzplantechnik wird z. B. in Kerzner (2003) eingehend beschrieben.
Die vorangehenden Abschnitte haben gezeigt, dass es eine Reihe von Plänen gibt (oder geben sollte), die zusammen die Planung bilden. Offensichtlich ist es sinnvoll, alle zum Projekt gehörenden Teilpläne in einem Dokument (oder Dokumentensystem), dem Projektplan, zusammenzuführen.
Abbildung 8–5 auf Seite 115 zeigt ein Muster für Projektpläne. Natürlich kann ein Projektplan auch anders strukturiert werden. In jedem Falle ist es aber sinnvoll, bei der Planung von einem Muster auszugehen, das dann an die spezielle Situation angepasst wird. Dabei werden vor allem solche Punkte weggelassen, die für das konkrete Projekt keine Bedeutung haben.
Könnte der Projektleiter in die Zukunft sehen, so wüsste er schon vor Projektbeginn, welche Aufwände und damit, welche Kosten entstehen werden, und alle im Laufe des Projekts auftretenden Probleme könnte er schon im Voraus berücksichtigen und durch Gegenmaßnahmen abmildern.
Da die meisten Projektleiter nicht hellsehen können, bleibt ihnen nur die Möglichkeit, durch Aufwandsschätzung und Risikomanagement die Unsicherheit der Zukunft in den Griff zu bekommen.
Eine der wichtigsten Fragen bei der Vorbereitung einer Software-Entwicklung lautet: Wie hoch wird der Aufwand sein? Sie ist eng verbunden (aber nicht gleichbedeutend) mit den Fragen:
Wie lange wird die Entwicklung dauern?
Wie viele Leute werden benötigt?
Abb. 8–5 Muster für einen Projektplan (nach Frühauf, Ludewig, Sandmayr, 2002, modifiziert)
Aufwands- oder Kostenschätzverfahren zielen darauf ab, möglichst frühzeitig Antworten auf diese Fragen zu liefern. Die Resultate werden benötigt für die
Kalkulation und Angebotserstellung,
Personalplanung und mittelfristige Disposition,
Vorbereitung einer Entscheidung »make or buy«,
Nachkalkulation.
Zunächst ist festzustellen, dass es auf keinem Gebiet eine Möglichkeit gibt, wirklich neue Projekte präzise abzuschätzen; das unerwartet teure Münchner Olympiadach und das Opernhaus von Sydney (Gesamtkosten von 102 statt der geschätzten 7 Mio. AUS-$) sind zwei spektakuläre Beispiele, das Grimm’sche Wörterbuch (von den Gebrüdern Grimm als Arbeit für einige Jahre bei A begonnen, aber erst Generationen später mit Z abgeschlossen) ist als eigentliches Software-Projekt ebenfalls typisch. Da in der jungen Informatik neue Anwendungen noch viel öfter vorkommen als auf anderen Gebieten, ist die Zahl der unplanbaren Projekte besonders hoch. Der Trend geht jedoch in Richtung Routine-Entwicklung.
Aber auch wenn wir nichts völlig Neues planen, bleibt eine Schätzung eine Schätzung, wir kennen den tatsächlich benötigten Aufwand erst dann (oder könnten ihn kennen), wenn wir das Projekt abgeschlossen haben. Je früher wir schätzen, desto mehr Unsicherheit müssen wir in Kauf nehmen, weil vor uns entsprechend viele Unsicherheiten und Unklarheiten liegen. Je weiter das Projekt fortgeschritten ist, desto sicherer können wir schätzen, weil wir den Aufwand für die bereits abgeschlossenen Arbeitspakete kennen und auf das Fehlende hochrechnen können.
Abb. 8–6 Der Schätztrichter, die Unsicherheit beim Schätzen (nach Boehm et al., 2000, S. 10)
Abbildung 8–6 zeigt die abnehmende Unsicherheit im Projektverlauf. Da wir gerade auf Grund dieser Unsicherheit bei einer Schätzung nie wissen können, ob wir zu hoch oder zu niedrig schätzen, hilft uns der »Schätztrichter« nicht für die konkrete Prognose. Aber er macht deutlich, dass es sinnvoll ist, immer wieder zu schätzen. Sollte das Projekt mehr Aufwand benötigen als zu Beginn erwartet, muss der Projektleiter das so früh wie möglich erkennen.
Der Aufwand für kleine Einheiten lässt sich genauer schätzen als der für große, die nicht auf erkennbare Weise aus kleinen zusammengesetzt sind. Darum kann man erst brauchbare Schätzungen erwarten, wenn die Grobstruktur des Systems festgelegt ist. Vorher hat man nicht mehr als eine Daumenpeilung.
Für die Aufwandsschätzung gibt es zwei grundsätzlich verschiedene Ansätze:
1. Expertenschätzung
Fachleute nutzen ihre Erfahrung, um den Aufwand zu schätzen.
2. Algorithmische Schätzung
Kosten werden aus Größen berechnet, die frühzeitig bekannt sind oder leichter und genauer als der Aufwand geschätzt werden können.
Diese Ansätze werden nachfolgend separat besprochen; in der Praxis werden sie sinnvollerweise kombiniert, zumindest durch eine Kontrollschätzung mit dem komplementären Ansatz.
In der Literatur findet man auch die Begriffe »top-down-« und »bottom-up-Schätzung«. Leider ist der Gebrauch dieser Wörter völlig uneinheitlich. Vom Wortsinn her liegt es nahe, die algorithmische Schätzung als Bottom-up-Verfahren zu bezeichnen, denn sie geht von elementaren Programmbestandteilen wie Code-Zeilen aus. (Was kostet ein Abendessen aus diesen einzelnen Bestandteilen?)
Umgekehrt wäre ein Vorgehen, das von den vorgegebenen Gesamtkosten auf die erreichbare Funktionalität und Qualität schließt, ein Top-down-Verfahren. (Was alles kann ich für diesen Betrag essen?) Aber der tatsächliche Sprachgebrauch ist meist anders.
Der alte, aber durchaus erhellende Artikel von Wolverton (1974) bietet eine Taxonomie der Ansätze.
Die Kosten eines Projekts durch einen oder besser mehrere Experten schätzen zu lassen, ist ein naheliegender, bewährter Ansatz. Er wird oft angewendet, allerdings meist nicht ausreichend systematisch; die präzise Dokumentation der Daten unterbleibt, sodass am Ende oft der schwarze Peter herumgeschoben wird: »Du hast mit deinen Zahlen weit danebengelegen.« »Als ich geschätzt habe, sah die Planung noch völlig anders aus.« »Das war ja nur die Schätzung für ein Teilprojekt.« Damit haben die Schätzungen kaum Nutzen. Jede Schätzung sollte mit den Voraussetzungen, dem Zeitpunkt, den Personen und allen Vorbehalten und Einschränkungen dokumentiert werden. Das wirkt auch allzu leichtfertigen Prognosen entgegen.
In den Sechzigerjahren entstand in der RAND Corporation (Santa Monica, CA) das Delphi-Verfahren als Methode der Zukunftsforschung. Es handelt sich um eine verfeinerte Variante der Expertenschätzung, die den Zweck hat, einerseits soziale Effekte der gegenseitigen Beeinflussung auszuschließen, andererseits Schätzergebnisse rückzukoppeln und die Gelegenheit zu Korrekturen zu bieten. Dazu wird eine moderierte Sitzung mit den Experten abgehalten. Der Moderator erläutert zu Beginn die Aufgabenstellungen, die abgeschätzt werden sollen, und verteilt, wenn sinnvoll, begleitende Unterlagen. Die Experten schätzen anschließend getrennt und geben ihre Schätzungen dem Moderator. Dieser fasst die Schätzungen zusammen und anonymisiert damit die Aussagen und Zahlen, die Ergebnisse teilt er den Experten mit. Diese können nun – weiterhin separat – ihre Schätzungen, vor allem die Abweichungen von den anderen Schätzungen, begründen oder korrigieren. Dieser Prozess wird wiederholt, bis die Abweichungen nach Meinung der Experten akzeptabel sind. Das Ergebnis der Schätzung ist der Median der Einzelschätzungen. Fairley (1985) beschreibt die Anwendung des Delphi-Verfahrens zur Aufwandsschätzung.
Unter den algorithmischen, also den auf Berechnungen basierenden Verfahren zur Kostenschätzung sind vor allem zwei (und eine Reihe von Varianten) bekannt: COCOMO und das Function-Point-Verfahren. Diese werden nachfolgend näher beschrieben.
COCOMO (Constructive Cost Model) ist ein algorithmisches Verfahren zur Kostenschätzung von Barry W. Boehm (Boehm, 1981). Allen Rechnungen liegt die geschätzte Programmgröße S, angegeben in DSI oder KDSI (Thousands of Delivered Source Instructions), zu Grunde. Mit Formeln, die Boehm aus großen Mengen archivierter Projektdaten abgeleitet hat, können daraus der Aufwand und die Entwicklungsdauer errechnet werden. Spezielle günstige oder ungünstige Umstände, z.B. extreme Sicherheitsanforderungen oder ein überdurchschnittlich erfahrenes Projektteam, können durch Einflussfaktoren berücksichtigt werden, deren Werte man umfangreichen Tabellen entnimmt. Wir stellen zunächst das alte COCOMO vor (»COCOMO 81«); es ist im Nachfolger COCOMO II (Boehm et al., 2000) mit kleinen Modernisierungen, aber konzeptionell unverändert enthalten.
COCOMO 81 bietet drei Stufen der Präzision an; die höheren Stufen verlangen mehr Informationen zu Projekt und Produkt und höheren Aufwand, liefern dafür aber genauere Schätzungen.
Basic COCOMO
Die Bestimmung der Werte basiert lediglich auf der global geschätzten Programmgröße. Basic COCOMO kann verwendet werden, wenn man eine erste sehr grobe Schätzung erhalten möchte.
Intermediate COCOMO
Die Programmgröße wird teilweise auf der Ebene der Subsysteme geschätzt, nicht nur global. Zusätzlich werden 15 förderliche oder hemmende Einflüsse (spezielle Merkmale des Projekts und des Produkts) durch Kostenfaktoren berücksichtigt. Diese setzen teilweise beim Gesamtsystem, teilweise bei den Subsystemen an. Intermediate COCOMO eignet sich für die Gesamteinschätzung zu Projektbeginn und für Schätzungen auf Subsystem-Ebene.
Detailed COCOMO
Die Berechnung von Aufwand und Dauer geschieht wie bei Intermediate COCOMO, allerdings werden die Kostenfaktoren weiter heruntergebrochen und die Entwicklungsphasen einzeln betrachtet.
Zuerst wird das Projekt einer von drei Schwierigkeitsklassen zugeordnet (Tab. 8–1). Diese Zuordnung ist nicht mit der Wahl der Präzisionsstufe zu verwechseln!
Entwicklungsart |
Merkmale |
Organic |
– relativ kleine Projektgröße (S < 50 KDSI) – stabile Entwicklungsumgebung – jeder Mitarbeiter kennt das gesamte Projekt – fast keine Entwicklung von neuen, nichttrivialen Algorithmen |
Semidetached |
– Projektgröße S < 300 KDSI – Projektteam besteht aus erfahrenen und unerfahrenen Mitarbeitern – jeder Mitarbeiter besitzt Spezialwissen bzgl. der Entwicklung |
Embedded |
– Entwicklung für einen neuen Einsatzbereich – das Projekt wird von einer relativ kleinen Anzahl von Analytikern definiert – ein relativ großes Projektteam realisiert anschließend die Entwürfe |
Tab. 8–1 Projektklassifikationen nach COCOMO 81
Die Tabelle 8–2 zeigt die Formeln für Basic und für Intermediate COCOMO, mit denen der Aufwand E (gemessen in Personenmonaten, PM) und die Projektdauer T (gemessen in Kalendermonaten, CM) bestimmt wird.
Aufwand E/PM (Basic COCOMO) |
Aufwand E/PM (Intermediate COCOMO) |
Dauer T/CM |
|
Organic |
2,4 (S/KDSI)1,05 |
M · 3,2 (S/KDSI)1,05 |
2,5 (E/PM)0,38 |
Semidetached |
3,0 (S/KDSI)1,12 |
M · 3,0 (S/KDSI)1,12 |
2,5 (E/PM)0,35 |
Embedded |
3,6 (S/KDSI)1,20 |
M · 2,8 (S/KDSI)1,20 |
2,5 (E/PM)0,32 |
Tab. 8–2 Grundgleichungen für COCOMO 81
Der Faktor M in den Aufwandsformeln ist das Produkt der Kostenfaktoren, die die fördernden und hemmenden Projektmerkmale repräsentieren (Tab. 8–3). Kostenfaktoren, die als neutral (nominal) bewertet werden, haben den Wert 1.
Faktor |
very low |
low |
nom. |
high |
very high |
extra high |
RELY Required software reliability |
0,75 |
0,88 |
1 |
1,15 |
1,40 |
|
CPLX Product complexity |
0,70 |
0,85 |
1 |
1,15 |
1,30 |
1,65 |
TIME Execution time constraint |
|
|
1 |
1,11 |
1,30 |
1,66 |
ACAP Analyst capability |
1,46 |
1,19 |
1 |
0,86 |
0,71 |
|
PCAP Programmer capability |
1,42 |
1,17 |
1 |
0,86 |
0,70 |
|
LEXP Programming language experience |
1,14 |
1,07 |
1 |
0,95 |
|
|
TOOL Use of software tools |
1,24 |
1,10 |
1 |
0,91 |
0,83 |
|
SCED Required development schedule |
1,23 |
1,08 |
1 |
1,04 |
1,10 |
|
Tab. 8–3 Werte einiger Kostenfaktoren für Intermediate COCOMO
Die Faktoren hinter M unterscheiden sich von den entsprechenden Faktoren für Basic COCOMO, weil M bei Projekten des Typs Organic typischerweise unter 1, bei Projekten des Typs Embedded über 1 liegt.
Die Vorgehensweise bei Intermediate COCOMO verdeutlicht das folgende Beispiel: Es soll ein Informationssystem entwickelt werden, als Entwicklungsart wird Organic angenommen. Das System soll aus drei Subsystemen – Kernsystem, Datenimport und Report-Generator – bestehen. Die Größe der Subsysteme wird wie folgt abgeschätzt:
|
|
a) Kernsystem |
2100 DSI |
b) Datenimport |
900 DSI |
c) Report-Generator |
600 DSI |
Die Verarbeitungsgeschwindigkeit muss sehr hoch sein. Es wird eine neue Programmiersprache eingesetzt, für die kaum Entwicklungswerkzeuge zur Verfügung stehen. Mit diesen Informationen werden aus der Tabelle 8–3 folgende Koeffizienten entnommen (alle anderen sind neutral, d. h. gleich 1):
TIME (Execution time constraint) |
sehr hoch: |
Faktor 1,30 |
LEXP (Progr. language experience) |
niedrig: |
Faktor 1,07 |
TOOL (Use of software tools) |
sehr niedrig: |
Faktor 1,24 |
Auf Basis dieser Einschätzungen können nun Aufwand und Dauer bestimmt werden.
|
|
Aufwand: |
E = 3,2 · 3,61,05 · (1,30 · 1,07 · 1,24) PM = 21,18 PM |
Dauer: |
T = 2,5 · 21,180,38 CM = 7,98 CM |
Intermediate COCOMO liefert also für den Aufwand etwa 21,2 PM, die in etwa 8 Kalendermonaten zu erbringen sind. Mit Hilfe dieser Schätzwerte können nun die benötigten Mitarbeiter, hier als Headcount mit H bezeichnet, und deren Produktivität P bestimmt werden. H hat die Einheit FTE (für Full Time Employee), P die Einheit DSI/PM.
|
|
Headcount: |
H = E / T = 21,18 PM / 7,98 CM = 2,65 FTE |
Produktivität: |
P = S / E = 3 600 DSI / 21,18 PM = 170 DSI/PM |
Tatsächlich dürften E, T und H etwas niedriger, P entsprechend höher liegen. Die Zahlenwerte in COCOMO 81 beruhen auf sehr umfangreichen Daten, die in den späten Siebzigerjahren erhoben wurden. In den folgenden zwei Jahrzehnten ist die Produktivität etwa auf das Doppelte gewachsen. Wer COCOMO 81 anwenden will, sollte zunächst alte Projekte nachkalkulieren und auf diese Weise einen zusätzlichen Korrekturfaktor bestimmen, der wie M in die Aufwandsgleichungen eingefügt wird. Dieser Faktor spiegelt auch Einflüsse der eingesetzten Programmiersprache und andere spezielle Vor- oder Nachteile der konkreten Umgebung wider. Dieser Faktor liegt meist im Bereich 0,4 bis 0,7.
Eine komplette Aufwandsberechnung nach COCOMO 81 für ein ungewöhnlich großes Beispiel, nämlich den Linux-Kernel, findet sich im Web (Wheeler, 2006).
COCOMO 81 war Ende des 20. Jahrhunderts in zweierlei Hinsicht veraltet: Zum einen stimmten die Parameter nicht mehr, zum anderen waren einige Faktoren bedeutungslos geworden, während andere fehlten. Ein Beispiel für einen obsoleten Faktor ist die turn around time, die Wartezeit, bis ein Programm im Batch-Betrieb ausgeführt wird; dagegen war 1981 an Projekte, die an mehreren Standorten kooperativ durchgeführt werden (multi-site development), nicht zu denken. Neu war auch die Vielfalt der Vorgehensmodelle und die Idee der Prozessbewertung und -verbesserung. Zusammen mit einer langen Reihe von Koautoren hat Boehm das ursprüngliche COCOMO revidiert, aktualisiert und erweitert (Boehm et al., 2000). Das Ergebnis nannte er COCOMO II.
COCOMO II definiert drei verschiedene Modelle zur Aufwandsabschätzung, die in unterschiedlichen Entwicklungssituationen und zu unterschiedlichen Zeitpunkten im Projekt eingesetzt werden können:
das Application Composition Model für Systeme, die weniger programmiert als konfiguriert oder – etwa mit Hilfe eines GUI-Builders – generiert werden,
das Early Design Model als Adaption des Function-Point-Verfahrens (Abschnitt 8.4.5), das sich bereits deutlich früher als COCOMO 81 einsetzen lässt, nämlich dann, wenn die Anforderungen geklärt sind,
das Post-Architecture Model als modernisierte Fassung des COCOMO 81. Dieses Modell erfordert, dass die Software-Architektur definiert ist und dass der Umfang der Software-Komponenten abgeschätzt werden kann.
COCOMO II basiert wie COCOMO 81 auf einer Schätzung des Programmumfangs, jetzt gemessen in SLOC (Source Lines of Code), das sind alle Zeilen bis auf solche, die leer sind oder nur Kommentar enthalten. Alternativ können auch Function Points1 verwendet werden; sie werden mittels Tabelle 8–4 in SLOC umgerechnet.
Sprache |
SLOC/FP |
C |
128 |
COBOL |
95 |
C++ |
55 |
JAVA |
53 |
ADA 95 |
49 |
Tab. 8–4 SLOC/FP-Umrechnungsfaktoren (nach Boehm et al., 2000, S. 20)
COCOMO II berücksichtigt bei der Abschätzung der Programmgröße das Maß der Code-Wiederverwendung und den Stabilitätsgrad der Anforderungen. Wiederverwendung ist im Allgemeinen billiger als Neuentwicklung. Deshalb wird der Code-Anteil, der übernommen und adaptiert werden muss, in eine äquivalente Menge neu zu entwickelnden Codes umgerechnet. Ändern sich die Anforderungen während der Entwicklung, dann müssen unter Umständen bereits erstellte Programmteile überarbeitet werden. Dieser Effekt geht ebenfalls in die Bestimmung der Programmgröße ein, indem der angenommene Ersetzungsgrad (requirements volatility, REVL) prozentual in die Größenbestimmung einfließt. Wenn neue Anforderungen 10 % des Codes unbrauchbar machen, dann ist REVL 10 % = 0,1. Die Grundformel zur Berechnung der Programmgröße ist damit2:
S = (1 + REVL) · (Sneu + Säquivalent)
Säquivalent ist eine rechnerische Größe. Ist die Erstellung einer Software um einen Faktor q aufwändiger als die Wiederverwendung, dann ergibt sich Säquivalent für w LOC, die wiederverwendet werden, zu w/q. Die detaillierten Formeln zur Umrechnung des adaptierten Codes in äquivalenten neu entwickelten Code sind in Boehm et al. (2000) angegeben.
In unserem Beispiel hatten wir den Programmumfang mit 3 600 DSI geschätzt. Wir unterstellen SLOC = DSI, also die gleiche Definition der Zeilenzahl. Nehmen wir an, dass sich 10 % der Anforderungen verändern werden und dass 1 000 LOC wiederverwendet werden können, die einem Aufwand von 200 LOC neuen Codes entsprechen, dann ergibt sich folgende Programmgröße:
S = (1 + 0,1) · (2 600 + 200) SLOC = 3 080 SLOC
Zur Bestimmung des Aufwands nutzt COCOMO II dieselbe Beziehung zwischen Programmgröße und Kostenfaktoren wie schon Intermediate COCOMO.
In COCOMO 81 war der Exponent X für jede der drei Projektarten fest vorgegeben. In COCOMO II sind die Projektarten weggefallen, stattdessen wird X nun aus fünf sogenannten Skalierungsfaktoren berechnet. Die Bezeichnung ist unglücklich, denn es geht nicht um Faktoren, sondern um Einflüsse, die als Summanden im Exponenten stehen und damit umso stärker wirken, je größer das System ist. Abbildung 8–7 zeigt, wie der Aufwand pro Code-Zeile in Abhängigkeit von X und von der (logarithmisch skalierten) Größe des Systems steigt.
Abb. 8–7 Einfluss der Größe S und des Exponenten X auf den relativen Aufwand
Folgende Skalierungsfaktoren werden in COCOMO II verwendet:
Precedentedness (PREC)
Dieser Faktor berücksichtigt die Erfahrung mit ähnlichen Projekten. Je mehr Erfahrung vorliegt, desto besser kann das Projekt mit der Größe umgehen.
Development flexibility (FLEX)
Dadurch wird berücksichtigt, inwieweit der Entwicklungsprozess durch den Kunden vorgegeben ist, d. h., wie flexibel der Prozess gewählt werden kann. Hohe Flexibilität, also geringe Festlegung, erlaubt es dem Projekt, sich auf die Größe optimal einzustellen.
Architecture/risk resolution (RESL)
Wenn Risikomanagement systematisch durchgeführt wird und hohe Kompetenzen im Bereich des Architekturentwurfs zur Verfügung stehen, dann ist die Größe des Projekts weniger bedrohlich.
Team cohesion (TEAM)
Größe schlägt sich vor allem in Kommunikationsaufwand nieder. Ein gut harmonierendes Projektteam braucht wenig Kommunikation und bewältigt dadurch große Systeme besser.
Process maturity (PMAT)
Hier dient die Einstufung des Entwicklungsprozesses nach CMM (Abschnitt 11.2) als Bewertungsgrundlage. Je besser der Entwicklungsprozess verstanden und umgesetzt wird, desto positiver wirkt sich das auf den Aufwand aus.
Tabelle 8–5 zeigt die Werte für die Skalierungsfaktoren. Man beachte, dass hier anders als sonst nominal nicht »neutral, keine Änderung« bedeutet. Wenn alle Skalierungsfaktoren Nominalwerte haben, hat der Exponent X den Standardwert 1,1.
Faktor |
very low |
low |
nominal |
high |
very high |
extra high |
PREC |
6,20 |
4,96 |
3,72 |
2,48 |
1,24 |
0,00 |
FLEX |
5,07 |
4,05 |
3,04 |
2,03 |
1,01 |
0,00 |
RESL |
7,07 |
5,65 |
4,24 |
2,83 |
1,41 |
0,00 |
TEAM |
5,48 |
4,38 |
3,29 |
2,19 |
1,10 |
0,00 |
PMAT |
7,80 |
6,24 |
4,69 |
3,12 |
1,56 |
0,00 |
Tab. 8–5 Werte der Skalierungsfaktoren
Die Zuordnung der Prozessreife (PMAT) zu den Stufen ist so definiert, dass eine schwache Stufe 1 (keine Ansätze für definierte Prozesse) als very low, eine Stufe 1 mit Tendenz nach 2 (Bemühungen um Prozessverbesserung) als low gewertet wird. Die Stufen 2 bis 5 verteilen sich dann auf nominal bis extra high.
Die der Tabelle entnommenen Werte werden addiert. Die Summe (zwischen 0 und 31,62) wird durch 100 geteilt, das Ergebnis ist δ. Vermehrt um ω = 0,91 wird daraus der Exponent X. Werte unter 1 sind nicht plausibel; sie bedeuten, dass Größe zum Vorteil wird (eine Art Mengenrabatt). Allerdings besteht diese Möglichkeit praktisch kaum, denn dazu müssen die Skalierungsfaktoren im Schnitt unter 2, also auf Stufe very high sein.
In den Aufwand geht wie bei Intermediate COCOMO 81 das Produkt vordefinierter Kostenfaktoren ein, die die speziellen Randbedingungen des Produkts, des Projekts, der Entwicklungsumgebung und des Projektteams berücksichtigen. Im Early Design Model werden sieben, im Post-Architecture Model 17 Kostenfaktoren verwendet (siehe Tab. 8–6 und 8–7).
Gruppe |
Faktor |
Beschreibung |
Produktfaktoren |
RELY |
erforderliche Zuverlässigkeit des Systems |
DATA |
Größe der Datenbank |
|
CPLX |
Komplexität des Systems |
|
RUSE |
Grad der Entwicklung von wiederverwendbaren Komponenten |
|
DOCU |
Umfang der geforderten Dokumentation |
|
Plattformfaktoren |
TIME |
Forderungen an die Ausführungszeit |
STOR |
Forderungen an den Speicherverbrauch |
|
PVOL |
Stabilität der Entwicklungsumgebung |
|
Teamfaktoren |
ACAP |
Fähigkeiten der Analytiker |
PCAP |
Fähigkeiten der Programmierer |
|
PCON |
Kontinuität der eingesetzten Mitarbeiter |
|
APEX |
Erfahrungen im Anwendungsbereich |
|
PLEX |
Erfahrungen mit der Entwicklungsumgebung |
|
LTEX |
Erfahrungen mit Programmiersprache(n) und Werkzeugen |
|
Projektfaktoren |
TOOL |
Einsatz von Werkzeugen |
SITE |
Grad der Verteiltheit der Entwicklungsstandorte |
|
SCED |
Bedingungen an die Entwicklungsdauer |
Tab. 8–6 Kostenfaktoren im Post-Architecture Model
Im Early Design Model werden diese Faktoren teilweise zusammengefasst, um der Tatsache Rechnung zu tragen, dass zu einem frühen Zeitpunkt weniger Wissen über das zu entwickelnde System vorhanden ist.
Die in den COCOMO II-Formeln benutzten Konstanten sowie die Werte der Skalierungs- und Kostenfaktoren wurden von Boehm empirisch auf der Basis vorhandener Projektdaten ermittelt. Sie können an die eigenen Gegebenheiten angepasst werden. Ausführungen zur Kalibrierung sind in Boehm et al. (2000) zu finden.
Faktor |
very low |
low |
nominal |
high |
very high |
extra high |
RELY |
0,82 |
0,92 |
1,00 |
1,10 |
1,26 |
|
DATA |
|
0,90 |
1,00 |
1,14 |
1,28 |
|
CPLX |
0,73 |
0,87 |
1,00 |
1,17 |
1,34 |
1,74 |
RUSE |
|
0,95 |
1,00 |
1,07 |
1,15 |
1,24 |
DOCU |
0,81 |
0,91 |
1,00 |
1,11 |
1,23 |
|
TIME |
|
|
1,00 |
1,11 |
1,29 |
1,63 |
STOR |
|
|
1,00 |
1,05 |
1,17 |
1,46 |
PVOL |
|
0,87 |
1,00 |
1,15 |
1,30 |
|
ACAP |
1,42 |
1,19 |
1,00 |
0,85 |
0,71 |
|
PCAP |
1,34 |
1,15 |
1,00 |
0,88 |
0,76 |
|
PCON |
1,29 |
1,12 |
1,00 |
0,90 |
0,81 |
|
APEX |
1,22 |
1,10 |
1,00 |
0,88 |
0,81 |
|
PLEX |
1,19 |
1,09 |
1,00 |
0,91 |
0,85 |
|
LTEX |
1,20 |
1,09 |
1,00 |
0,91 |
0,85 |
|
TOOL |
1,17 |
1,09 |
1,00 |
0,91 |
0,84 |
|
SITE |
1,22 |
1,09 |
1,00 |
0,93 |
0,86 |
0,80 |
SCED |
1,43 |
1,14 |
1,00 |
1,00 |
1,00 |
|
Tab. 8–7 Werte der Kostenfaktoren im Post-Architecture Model
Nun wollen wir den Aufwand für unser Beispielprojekt gemäß COCOMO II bestimmen. Die Programmgröße hatten wir zu Beginn mit 3 600 DSI abgeschätzt, diese wurde unter Berücksichtigung der Effekte der Wiederverwendung und der Stabilität der Anforderungen auf 3 080 LOC korrigiert. Um den Exponenten X für unsere Schätzung zu berechnen, bewerten wir die Skalierungsfaktoren wie folgt (vgl. Tab. 8–5):
Faktor |
Bewertung |
Stufe |
Wert |
PREC |
Es wurden bereits ähnliche Projekte erfolgreich durchgeführt. |
high |
2,48 |
FLEX |
Der Kunde schreibt große Teile des Prozesses vor. |
low |
4,05 |
RESL |
Risikomanagement und Architekturdesign werden beherrscht. |
nominal |
4,24 |
TEAM |
Das Team arbeitet schon lange zusammen. |
very high |
1,10 |
PMAT |
CMM Level 2 ist erreicht. |
nominal |
4,69 |
Summe |
|
|
16,56 |
δ = 0,01 · 16,56 = 0,1656
X = δ + ω = 0,1656 + 0,91 = 1,0756
Wenn wir das Post-Architecture Model verwenden, dann müssen wir die oben beschriebenen Kostenfaktoren berücksichtigen. In unserem Beispiel wirken sich nur die folgenden Faktoren aus, alle anderen haben den Nominalwert 1.
Faktor |
Bewertung |
Stufe |
Wert |
TIME |
hohe Anforderungen an die Ausführungsgeschwindigkeit |
very high |
1,29 |
PLEX |
keine Erfahrungen mit der Plattform |
very low |
1,19 |
LTEX |
wenig Erfahrungen mit Sprachen und Werkzeugen |
low |
1,09 |
Produkt |
|
|
1,67 |
Als Aufwand erhalten wir nun:
E |
= 2,94 · 3,081,0756 · (1,29 · 1,19 · 1,09) PM |
|
= 2,94 · 3,35 · 1,67 PM |
|
= 16,5 PM |
COCOMO II definiert wie die Vorgängerversion ebenfalls eine Formel, um auf Basis des Aufwandes die Entwicklungsdauer T zu bestimmen.
Wenn geplant ist, das Projekt in kürzerer als der nominalen Zeit durchzuführen, muss in der Aufwandsberechnung der Kostenfaktor SCED entsprechend gesetzt werden; der Gesamtaufwand steigt also, und zwar um bis zu 43 %. Trotzdem kann die Verkürzung nach Boehm nicht dazu führen, dass das Projekt in weniger als 75 % der nominalen Dauer durchgeführt wird. Das heißt praktisch: Wenn das Projekt in 12 Monaten mit 10 Mitarbeitern zu schaffen ist, sind 19 Leute nötig, um es in 9 Monaten zu beenden.
Für unser Beispiel (nominale Dauer ist vorgesehen) können wir die Entwicklungsdauer folgendermaßen bestimmen:
T |
= 3,67 · 16,5(0,1656+1,4)/5 CM |
|
= 3,67 · 16,50,313 CM |
|
= 3,67 · 2,40 CM |
|
= 8,8 CM |
Wir werden also etwa knapp 9 Monate lang im Mittel knapp zwei Leute mit diesem Projekt beschäftigen.
Vergleichen wir die Resultate mit denen von COCOMO 81, so stellen wir zunächst eine große Ähnlichkeit fest. Der geschätzte Aufwand ist mit COCOMO II dank der Wiederverwendung um etwa 4,5 PM gesunken. Der etwas größere Exponent spielt im Beispiel wegen des sehr geringen Umfangs keine Rolle. Die geschätzte Dauer ist nicht gesunken, sondern leicht gestiegen. COCOMO II legt uns also nahe, mit weniger Leuten etwas länger zu arbeiten.
COCOMO II bietet ein umfangreiches Rüstzeug für die Schätzung von Aufwand und Dauer. Zurzeit liegen noch keine größeren Studien vor, die zeigen, wie gut die Modelle sind und in welchen Bereichen sie noch kalibriert werden müssen.
Die Idee der Function Points wurde 1979 von A. Albrecht, IBM, publiziert (Albrecht, 1979) und seitdem von verschiedenen Autoren und Institutionen weiterentwickelt (z. B. Albrecht, Gaffney, 1983). Das Verfahren unterscheidet sich von COCOMO prinzipiell wie folgt:
Basis der Schätzung ist nicht die Zahl der Code-Zeilen, sondern der Umfang des Programms, ausgedrückt in den zu implementierenden Funktionen. Die Software wird also nicht aus der Sicht der Implementierung, sondern aus der des Benutzers gesehen.
Da die Software-Architektur nicht vorausgesetzt wird, können die Einflussfaktoren nur global, nicht nach Modulen differenziert berücksichtigt werden.
Das Verfahren ist arithmetisch einfacher, ein exponentieller Zusammenhang wie in COCOMO kommt nicht vor; stattdessen muss eine progressive Kennlinie (Aufwand über FPs) experimentell ermittelt werden.
Vereinfacht geht man dabei wie folgt vor: Alle für das Problem relevanten Daten, d.h. die logischen Datenbestände (Dateien) und alle Ein- und Ausgaben der zu realisierenden Vorgänge, werden erfasst und den folgenden Kategorien zugeordnet:
Externe Eingabe
Externe Ausgabe
Externe Abfrage
Interne Anwenderdaten
Externe Referenzdaten
Eine Eingabe kann von der Tastatur, von einem Datenträger oder aus einer anderen Quelle kommen. Entsprechend gehen Ausgaben auf den Bildschirm, auf einen Drucker oder an ein anderes Gerät. Abfragen sind spezielle Ausgaben, die keine weitere Bearbeitung (z. B. eine Mittelwertbildung) der gespeicherten Informationen erfordern und diese auch nicht verändern.
Anschließend wird der Schwierigkeitsgrad jedes Datums als niedrig, mittel oder hoch bewertet. Durch Tabellen ist für jeden Typ und für jede Schwierigkeitsstufe (z. B. für »externe Eingabe, mittel«) eine Punktzahl gegeben. Diese Punkte werden addiert; das Ergebnis liefert die sogenannten Unadjusted Function Points (siehe Abb. 8–8).
Nun werden 14 Einflussfaktoren (General System Characteristic, GSC) wie Verflechtung mit anderen Projekten, dezentrale Datenverwaltung, Transaktionsrate, komplexe Verarbeitungslogik, Wiederverwendbarkeit, Konvertierungen oder Benutzerfreundlichkeit betrachtet und mit 0 bis 5 bewertet (0 = kein Einfluss, 5 = starker Einfluss), um einen Korrekturfaktor (Value Adjustment Factor, VAF) zu bestimmen. Dieser wird wie folgt berechnet:
Dadurch ergibt sich ein Wert zwischen 0,65 und 1,35, der zu einer Korrektur von -35 % bis +35 % führt.
Typ |
Komplexität |
Summe |
||
niedrig |
mittel |
hoch |
||
Eingabe |
____ ·3 = |
____ ·4 = |
____ ·6 = |
|
Ausgabe |
____ ·4 = |
____ ·5 = |
____ ·7 = |
|
Abfrage |
____ ·3 = |
____ ·4 = |
____ ·6 = |
|
Anwenderdaten |
____ ·7 = |
____ ·10 = |
____ ·15 = |
|
Referenzdaten |
____ ·5 = |
____ ·7 = |
____ ·10 = |
|
Unadjusted Function Points |
UFP |
|
||
Value Adjustment Factor |
VAF |
|
||
Adjusted Function Points |
AFP = UFP · VAF |
|
||
Abb. 8–8 Function-Point-Berechnungsschema
Das Produkt aus Unadjusted Function Points und Korrekturfaktor liefert die Adjusted Function Points. Tabelle 8–8 zeigt ein einfaches Schema, um nach dieser Vorgehensweise die Function Points zu bestimmen.
Der so ermittelte Function-Point-Wert wird schließlich mit Hilfe einer Kurve oder Tabelle, deren Grundlage die Nachkalkulation alter Projekte bildet, in Personenmonate umgesetzt (siehe Abb. 8–9).
Auf Basis der gemachten Erfahrungen mit neuen Projekten wird die Umrechnungstabelle stetig aktualisiert. Dazu können die neuen Wertepaare (FP/PM) zusätzlich in die Tabelle aufgenommen oder gegen die ältesten Wertepaare ausgetauscht werden.
Abb. 8–9 IBM- und VW-Kurve für die Umrechnung von AFPs in PM gemäß Noth, Kretzschmar (1984) und Knöll, Busse (1991)
Das Function-Point-Verfahren ist in der Praxis heute am weitesten verbreitet, vor allem im Bereich der kommerziellen Software. Entsprechend ist es in der Literatur (z. B. Poensgen, Bock, 2005) und im Web sehr präsent. Es ist aber auch auf diesen Bereich beschränkt: Für technisch-wissenschaftliche Software ist es kaum zu gebrauchen, weil deren algorithmischer Anteil deutlich höher ist als bei der Software, die in Banken und Versicherungen läuft. Umgekehrt taugt COCOMO nicht für die kommerzielle Software, wenigstens nicht ohne eine spezielle Korrektur, denn bei unveränderter Anwendung fallen die Schätzungen in diesem Bereich deutlich zu hoch aus.
Aufwandsschätzung ist – und bleibt auch mit den vorgestellten Verfahren – schwierig. Aber der Projektleiter hat keine Alternative! Schätzen, dokumentieren, besser schätzen, das ist der einzige Weg zu brauchbaren Prognosen. Nur wenn wir die Erfahrungen machen, aufzeichnen und für künftige Projekte zur Verfügung stellen, können wir aus den unvermeidbaren Fehlern lernen und die Qualität unserer Schätzungen über die Zeit verbessern. Mängel der verfügbaren Methoden (die es zweifellos gibt) sind kein Alibi für den Verzicht auf die systematische Kostenschätzung.
Schon in den Neunzigerjahren wurde das Function-Point-Verfahren weiterentwickelt und modifiziert, um den Anwendungsbereich zu erweitern (von Informationssystemen auf Echtzeitsysteme und technisch-wissenschaftliche Software) und um die Genauigkeit der Schätzungen zu verbessern.
Inzwischen ist eine ganze Reihe von Varianten entstanden. Einige, z. B. die »feature points«, die »full function points«, die »Mark II function points« und die »3D function points«, werden in der neueren Literatur3 kaum noch erwähnt, sind also mutmaßlich ohne Bedeutung. Andere genießen einige Aufmerksamkeit und haben auch namhafte Vertreter. Die ursprüngliche Idee wird vor allem von der IFPUG vertreten, der International Function Point Users Group. Das oben zitierte Buch (Poensgen, Bock, 2005) basiert auf dieser Sichtweise.
Gleichzeitig hat sich der Schwerpunkt der Methoden von der Kostenschätzung zur Größenbeschreibung (»Sizing«) verschoben. Nun geht es darum, ein Verfahren zu definieren, das eine neutrale, objektive Charakterisierung des Software-Umfangs (functional size) liefert; die Kostenschätzung wird nur noch als Zusatzfunktion betrachtet. Natürlich wäre eine allgemein anerkannte Metrik der Software-Größe außerordentlich nützlich.
Das zuständige Normungskomitee der ISO hat 1998 einen (Meta-)Standard für die Größenbeschreibung verabschiedet, ISO 14143 Functional Size Measurement mit sechs Teilen (Functional Size Measurement Concepts, Compliance, Verification, Reference Model, Software Domains und Guide to 14143 & related standards). Dieser Standard legt fest, welche Anforderungen ein Verfahren zur Größenmessung erfüllen muss. Eine ganze Reihe von Vorschlägen wurde dann als kompatibel mit ISO 14143 ebenfalls standardisiert:
ISO/IEC 19761, die COSMIC-Methode (Common Software Measurement International Consortium)
ISO/IEC 20926, die IFPUG-Methode
ISO/IEC 20968, die Mark-II-Methode (MkII)
ISO/IEC 24570, die Methode der Nesma (Nederlandse Software Metrieken Associatie)
Bei Verfahren, die (wie die IFPUG-Methode) auch die Kostenschätzung einschließen, erfasst die Normung nur den Teil, der den funktionalen Umfang betrifft.
Offensichtlich sind wir von einem einzigen allgemein akzeptierten Standard für die Beschreibung der funktionalen Größe noch weit entfernt.
Das Function-Point-Verfahren beruht auf der einfachen Idee, Bestandteile der geplanten Software zu identifizieren und zu zählen. Unterschiede zwischen den Bestandteilen, im Prozess und in den Rahmenbedingungen des Projekts werden durch Gewichte und Einflussfaktoren berücksichtigt.
Es liegt daher nahe, auch andere Bestandteile als die Ein- und Ausgaben heranzuziehen. So entstanden die Object Points und die Use Case Points. Das Prinzip, andere Einflüsse durch Faktoren darzustellen, bleibt grundsätzlich unverändert.
Die Bezeichnung »Object Points« wurde zweimal in unterschiedlicher Bedeutung eingeführt: Banker, Kauffman und Kumar (1991) haben eine sehr früh einsetzbare Metrik entwickelt, die die Zahl und Komplexität von Bildschirm-Masken, zu erzeugenden Ausgaben und Programmeinheiten verwendet. (»Objects include screens, reports and modules in third generation programming languages.«) Wie auch bei Sneed (siehe unten) wird die Wiederverwendung eingerechnet. Nach Angaben der Autoren gelangt man so mit weniger Aufwand zu besseren Resultaten als mit den Function Points. Diese Methode wurde später in COCOMO II (Abschnitt 8.4.4) integriert.
Sneed hat kurz darauf – vermutlich in Unkenntnis der älteren Arbeit – unter demselben Namen eine Bewertung speziell für objektorientierte Programme vorgeschlagen (Sneed, 1996). Dabei werden Klassendiagramme (Klassen, Attribute, Methoden, Klassenassoziation), Sequenzdiagramme (Nachrichten, Parameter, Sender und potenzielle Empfänger) und Use-Case-Diagramme (Online-, Batch-und System-Anwendungsfälle, jeweils gewichtet mit der Zahl der Ausgänge) herangezogen. Sneed verwendet diese Metrik vor allem, um existierende Software zu charakterisieren, die verändert oder modernisiert werden soll.
Die Use Case Points haben eine vorwiegend akademische Karriere gemacht. Sie wurden in einer schwedischen Diplomarbeit vorgeschlagen (Karner, 1993), später in einer norwegischen Master-Thesis weiterentwickelt (Ribu, 2001) und in jüngster Zeit in einer deutschen Dissertation erneut verbessert (Frohnhoff, 2009). Bei dieser Methode werden die Akteure und die Anwendungsfälle gezählt und gewichtet. Da in vielen Projekten Anwendungsfälle für die Spezifikation verwendet werden, sind entsprechende Daten oft und bald nach Beginn der Entwicklung verfügbar. Frohnhoff setzt noch früher ein, indem er aus den Beschreibungen der Geschäftsprozesse auf die Anwendungsfälle schließt. Unsicherheiten entstehen vor allem durch die individuellen Unterschiede bei der Strukturierung und Detaillierung der Anwendungsfälle; dasselbe Szenario wird von verschiedenen Entwicklern keineswegs durch gleich viele, gleich große Anwendungsfälle beschrieben. Entsprechend zählen sie auch unterschiedlich viele Use Case Points.
In jedem Projekt treten Probleme auf, die das Projekt behindern, verzögern oder im schlimmsten Falle scheitern lassen. Mit dem Risikomanagement verfolgen wir das Ziel, möglichst frühzeitig denkbare Probleme zu identifizieren, um geeignete Gegenmaßnahmen einzuleiten, damit diese Probleme entweder gar nicht erst entstehen oder das Projekt nicht ernsthaft bedrohen. Risikomanagement ist eine kontinuierliche Tätigkeit, die in der Startphase besonders wichtig ist, aber danach, bis zum Projektende, systematisch fortgesetzt werden muss.
Präzises Risikomanagement ist notwendig, um Projekte erfolgreich abzuschließen. Umso erstaunlicher ist es, dass es in der Praxis oft vernachlässigt wird oder ganz fehlt (oder, was die gleiche Wirkung hat, zu einer Formalübung wird). Denkbare Gründe dafür sind, dass der Begriff Risiko vorbelastet ist, dass man nicht gerne über Risiken spricht, weil man alles »im Griff hat« oder glaubt, haben zu müssen. Außerdem sind die Verfahren für ein systematisches Risikomanagement oft nicht bekannt.
Was ist ein Risiko? In Anlehnung an Hindel et al. (2004) definieren wir:
Risiko — Ein Problem, das noch nicht eingetreten ist, aber wichtige Projektziele oder Projektergebnisse gefährdet, falls es eintritt. Ob es eintreten wird, kann nicht sicher vorausgesagt werden.
Risikomanagement umfasst alle Aktivitäten, die darauf abzielen, dass aus einem Risiko kein schweres Problem für das Projekt wird. Im Einzelnen zählen dazu:
Identifikation von Risiken
Analyse und Bewertung der Risiken
Planung von Gegenmaßnahmen
Verfolgen der Risiken und der gewählten Gegenmaßnahmen
Wichtig ist, dass Risiken explizit dargestellt und kommuniziert und dass geeignete Gegenmaßnahmen frühzeitig eingeleitet werden.
Um Projektrisiken zu identifizieren, hat es sich bewährt, Checklisten für Risikoquellen zu benutzen. Sie stellen sicher, dass die erfahrungsgemäß kritischen Themenfelder betrachtet und die identifizierten Risiken dokumentiert werden. Ziel ist es, eine möglichst vollständige Sicht auf die Projektrisiken zu erhalten. Beispiele für solche Themenfelder sind die verwendete Technik, die Beziehungen zum Kunden, die Verfügbarkeit von Mitarbeitern und Ressourcen und die Stabilität der Anforderungen. Carr et al. (1993) geben eine Taxonomie für Risikoquellen und Themen vor, die als Grundlage für Checklisten verwendet werden kann. Um eine möglichst vollständige Liste der Projektrisiken zu erhalten, müssen alle Experten beteiligt werden. In der Praxis haben sich dazu moderierte Workshops bewährt. Es liegt aber in der Natur der Risiken, dass wir nicht sicher sein können, alle Risiken entdeckt zu haben. Umso wichtiger ist es, dass gesammelte Erfahrungen verfügbar sind, die zum Beispiel in Form von Abschlussberichten anderer Projekte vorliegen.
Nachdem die Risiken identifiziert und beschrieben sind, müssen sie analysiert und bewertet werden. Dazu werden für jedes betrachtete Risiko die Eintrittswahrscheinlichkeit (p) und die im Schadensfall entstehenden Kosten (K) für das Projekt abgeschätzt. Das Produkt dieser beiden Werte ergibt den Risikowert, der für die weitere Analyse benutzt wird.
Risikowert = p · K
Natürlich sind die Schätzwerte für die Eintrittswahrscheinlichkeit und den verursachten Schaden immer mit erheblicher Unsicherheit behaftet. Trotzdem sollte man versuchen, p und K für jedes Risiko abzuschätzen; es wird sich später zeigen, dass Fehler, die dabei unvermeidlich sind, keine schlimmen Folgen haben. Mit p und K kann man jedes Risiko als Punkt in einer doppelt logarithmischen Darstellung eintragen (Abb. 8–10). Geraden von links oben nach rechts unten kennzeichnen einen bestimmten Risikowert, der rechts abgelesen werden kann. In der Abbildung ist unterstellt, dass Risikowerte bis 10000 € akzeptabel sind; das ist natürlich von der jeweiligen Umgebung abhängig, in einer kleinen Firma dürfte dieser Wert niedriger sein. Für Punkte, die unter der Diagonalen liegen, sind keine Aktionen erforderlich.
Punkte über der Diagonalen müssen nach links oder nach unten bewegt werden. Eine Senkung der im Problemfall entstehenden Kosten verschiebt den Punkt nach unten (Pfeil a), eine Senkung der Wahrscheinlichkeit verschiebt ihn nach links (Pfeil b). In der Praxis haben alle Maßnahmen zur Folge, dass zusätzliche, sichere Kosten entstehen, die aber wesentlich geringer sind als der mögliche Schaden.
Zwei Bereiche (oben und rechts) sind von besonderer Bedeutung: Oben liegen extreme Risiken. Wenn ein solches Risiko eintritt, ist der Schaden nicht mehr zu beherrschen (z. B. ein Bankrott der Firma). In diesem Falle ist zu erwägen, ob eine Versicherung abgeschlossen werden kann. Versicherungen senken den Risikowert nicht, sondern machen aus einem wenig wahrscheinlichen sehr hohen Schaden eine sichere kleine Zahlung (Pfeil c).
Risiken mit einer Eintrittswahrscheinlichkeit über 50 % sollten als sichere Ereignisse behandelt werden. Dass der Kunde seine Anforderungen ändert, dass auch nach dem Test noch Fehler im Programm sind, dass es Änderungen im Personal geben wird, das ist so sicher wie der Schneefall im kommenden Winter. Wir wissen noch nicht, wann und wie viel Schnee fällt, aber wir können sicher damit rechnen, dass er fällt.
Alle geschätzten Werte sind unvermeidlich vage; die doppelt logarithmische Darstellung mildert aber den Effekt der Fehler ganz erheblich. Und wir erleben hier ähnlich wie bei der Aufwandsschätzung, dass die Zahlen genauer werden, wenn wir das Verfahren einige Male angewandt haben: Wer ein Instrument spielen will, muss es schlecht gespielt haben, um es eines Tages gut spielen zu können.
Wer die Abschätzung der Werte scheut, kann eine vereinfachte Variante des Verfahrens anwenden. Tabelle 8–8 zeigt eine dreiwertige Skala für die beiden zu schätzenden Werte. Die Produkte der beiden Werte (1, 2, 3, 4, 6 oder 9) kennzeichnen das Risiko.
Wert |
Eintrittswahrscheinlichkeit |
Schadensausmaß |
1 |
Es ist wenig wahrscheinlich, dass das Risiko eintritt. |
Der Schaden wird für das Projekt kaum merklich sein: – geringe Einschränkung der Leistungen – geringe Zeitverzögerung – geringe Überschreitung der Kosten |
2 |
Es wäre nicht überraschend, wenn das Risiko eintritt. |
Der Schaden ist beträchtlich: – merkliche Einschränkung der Leistung – merkliche Zeitverzögerung – merkliche Überschreitung der Kosten |
3 |
Es ist damit zu rechnen, dass das Risiko eintritt. |
Der Schaden für das Projekt ist groß: – zentrale Funktionen sind betroffen – lange Zeitverzögerung – starke Überschreitung der Kosten |
Tab. 8–8 Eine dreiwertige Skala für die Risikobewertung
Abb. 8–11 Klassifikation von Risiken
Präventivmaßnahmen sollen die Eintrittswahrscheinlichkeit eines Risikos senken (im günstigsten Fall auf null) oder die Bedingungen so verändern, dass der eintretende Schaden erträglich bleibt. Beispielsweise könnte das Risiko darin bestehen, dass ein für das Projekt sehr wichtiger Mitarbeiter die Firma verlässt. Indem man ihm eine Erfolgsprämie oder eine andere Belohnung für den erfolgreichen Abschluss in Aussicht stellt, kann man die Wahrscheinlichkeit, dass er geht, senken. Indem man ihm einen Kollegen zur Seite stellt, der in der Zusammenarbeit wichtige Kenntnisse aufnimmt, verringert man den Schaden, der eintreten kann. Natürlich schließen sich die beiden Strategien nicht gegenseitig aus.
Notfallmaßnahmen werden reaktiv ergriffen, sie dienen dazu, den Schaden zu begrenzen, wenn ein Schadensfall eingetreten ist. Auch solche Maßnahmen können geplant werden. Beispielsweise könnte man sich im Falle des Mitarbeiters, dessen Firmentreue unsicher ist, frühzeitig vergewissern, wo und wie ggf. ein Nachfolger gefunden werden kann. Auf diese Weise hat man eine Problemlösung in der Schublade, wenn sie gebraucht wird.
Gegenmaßnahmen müssen, seien sie nun präventiv oder reaktiv, in den Projektplan aufgenommen werden, denn sie müssen – mehr als alle anderen Maßnahmen – überwacht werden, damit sie sicher zum Erfolg führen. Wenn nötig muss die Maßnahme abgeändert oder durch weitere Maßnahmen verstärkt werden. Da die Gegenmaßnahmen Kosten verursachen, müssen diese im Projektbudget eingeplant werden.
Da sich die Risiken während der Projektdurchführung verändern – vorhandene Risiken schwächen sich ab oder verstärken sich, neue Risiken kommen hinzu –, muss die Risikosituation eines Projekts während der gesamten Laufzeit immer wieder bewertet werden. Dies geschieht häufig in Form regelmäßiger Projektsitzungen. Es hat sich bewährt, die Risikosituation kondensiert darzustellen, sodass sie von den Managern schnell eingeschätzt werden kann. Häufig werden deshalb die zehn wichtigsten Risiken zusammen mit den Gegenmaßnahmen aufgelistet, und die Gesamtbewertung wird in Form einer Ampelskala visualisiert (mit Grün für alles, was glatt läuft, Gelb für drohende Probleme und Rot für dringenden Handlungsbedarf).
Ein solches systematisches Risikomanagement hat folgende Vorteile:
Risiken werden frühzeitig identifiziert und für alle Beteiligten sichtbar gemacht.
Risiken werden nicht verschwiegen, sondern offen kommuniziert.
Gegenmaßnahmen können frühzeitig geplant und durchgeführt werden. Es wird nicht erst dann gehandelt, wenn das Kind bereits in den Brunnen gefallen ist, d. h., wenn die Risiken zu Problemen geworden sind.
Die Kosten und der Nutzen von Gegenmaßnahmen können bewertet werden.
Das Ergebnis der Risikobewertung fließt in die Termin- und Kostenplanung ein.
Auf die sich verändernde Risikosituation kann angemessen reagiert werden, weil die Risiken kontinuierlich neu bewertet werden.
Die Fähigkeiten zur Risikobewertung werden laufend verbessert, weil die Risikodaten gesammelt, analysiert und in Folgeprojekten genutzt werden.
Auch hier gilt, was in vielen Bereichen des Software Engineerings gilt: Es kommt vor allem darauf an, dass man das Risikomanagement ernsthaft, systematisch und projektbegleitend betreibt und laufend verbessert. Welche Techniken und Werkzeuge verwendet werden, ist sekundär.
Die Projektkontrolle und -steuerung hat die Aufgabe, den Fortschritt eines Projekts zu beobachten und steuernd einzugreifen, wenn Abweichungen festgestellt werden, die durch Störungen verschiedenster Art verursacht sein können.
Für eine wirksame Projektkontrolle eignen sich solche Maßnahmen am besten, die Abweichungen vom Plan oder andere Probleme möglichst früh anzeigen. Nur dann können Korrekturen so früh eingeleitet werden (auch Korrekturen des Plans, wenn er ungeeignet war), dass noch Mittel für Maßnahmen bereitstehen und Zeit bleibt, damit die Maßnahmen wirken können.
Die Projektkontrolle und -steuerung kann als eine Art Regelkreis modelliert werden. Damit er nicht nur intuitiv, sondern explizit umgesetzt wird, ist es erforderlich, dass
a) Vorgaben und Erwartungen festgehalten werden: das Soll, der Plan,
b) erfasst und bewertet wird, was im Projektverlauf erreicht wird: das Ist,
c) Erwartungen und Bewertungen verglichen werden: Soll-Ist-Vergleich,
d) aus allen Abweichungen Konsequenzen gezogen, also korrigierende Maßnahmen eingeleitet werden.
Wird eine dieser Tätigkeiten nicht ausgeführt, so ist der Regelkreis nicht geschlossen, und das Projekt wird nicht geführt, sondern entwickelt sich nach seinen eigenen Gesetzen. Abbildung 8–12 zeigt, wie diese Tätigkeiten zusammenhängen.
Der Ist-Zustand wird anhand der bearbeiteten oder fertiggestellten Arbeitspakete festgestellt. Darauf gehen wir im nächsten Abschnitt genauer ein. Zeigt der anschließende Soll-Ist-Vergleich (Bewertung des Projektfortschritts) Abweichungen von der Planung, dann ist zu entscheiden, ob mit Hilfe geeigneter korrektiver Steuerungsmaßnahmen das Ist wieder an das Soll herangeführt werden kann oder die Planung geändert werden muss, also der Plan der korrigierten Einschätzung der Gegebenheiten angepasst werden muss. Bei der Auswahl von Steuerungsmaßnahmen muss immer berücksichtigt werden, welche Auswirkungen die erkannten Abweichungen auf die Projektziele haben; Leistungen, Kosten und Termine sind dabei zu unterscheiden. Steuerungsmaßnahmen (technische und organisatorische Maßnahmen) sind in vielen Fällen, Planänderungen unbedingt mit dem Auftraggeber abzustimmen.
Abb. 8–12 Projektkontrolle und -steuerung als Regelkreis; fette Pfeile kennzeichnen die konstruktive Entwicklung, punktierte Pfeile korrigierende Eingriffe. Die übrigen Pfeile dienen der Projektplanung und -verfolgung
Die Abbildung 8–12 ist, mag sie auch auf den ersten Blick kompliziert erscheinen, vereinfacht; die Bewertung des Projektfortschritts hat in vielen Fällen zusätzlich die Wirkungen, die bei der Bewertung der Funktionalität und der Qualität eingezeichnet sind. Zudem ist die Spezifikation, die aus der Aufgabe folgt, nicht explizit dargestellt.
Im Mittelpunkt der Projektkontrolle steht das Arbeitspaket. Jeder Mitarbeiter ordnet seine Arbeitsstunden den Arbeitspaketen zu, mit denen er sich befasst hat. Dieser Ist-Aufwand wird dem Soll, der Aufwandsschätzung für das Arbeitspaket, gegenübergestellt. Abweichungen entstehen,
wenn die Schätzung falsch war,
wenn die Arbeit ineffizient durchgeführt wurde,
wenn tatsächlich eine andere oder größere Aufgabe gelöst wurde, als im Arbeitspaket vereinbart war,
wenn die Arbeitszeit falsch verbucht wurde.
Die Zeiterfassung wird in der Regel auch in Bezug auf die einzelnen Mitarbeiter ausgewertet. Wer für 40 h pro Woche bezahlt wird, sollte auch 40 h Arbeit nachweisen. Durch einige Stunden Toleranz berücksichtigt man die Tatsache, dass es Zeiten gibt, die nicht sinnvoll zugeordnet werden können. Trotzdem entstehen scheinbare Fehlzeiten, wenn bestimmte notwendige Arbeiten nicht in den Arbeitspaketen berücksichtigt waren, weil sie in der Planung vergessen wurden oder weil sie gar nicht auftreten dürfen. (Ein Beispiel sind in vielen Unternehmen die zusätzlichen Arbeiten, die entstehen, wenn die Projekte international durchgeführt werden. Das Management, das mit dieser Entscheidung seinen Willen zur Kostensenkung demonstriert, kann nicht zugeben, dass dadurch Kosten entstehen.)
Die Mitarbeiter reagieren darauf, indem sie die Zeiten irgendwo buchen. Ein ähnlicher, weit verbreiteter Effekt ist zu beobachten, wo die Budgets der einzelnen Projekte oder Projektphasen hart beschränkt sind, die Mitarbeiter aber typischerweise in mehreren Projekten arbeiten. Dann gilt das Prinzip: Dieser Topf ist leer, also esse ich aus einem anderen. Damit verliert die Aufwandserfassung natürlich ihren Sinn und Nutzen. Nachfolgend unterstellen wir, dass wir korrekte Zahlen für den erbrachten Aufwand haben.
In einer idealen Welt könnte man (wenn es dort nicht ganz überflüssig wäre) den Fertigstellungsgrad nach der folgenden Formel ermitteln:
Sie entspricht dem optimistischen Prinzip: »Mein Geld ist fast alle. Also ist heute der 28.« Selbst wenn die Aufwandsschätzung relativ gut war, ist der entstehende Fehler gegen Ende des Projekts groß. Betrachten wir ein Beispiel: Nach neun Monaten eines Projekts sind etwa 90 % des geschätzten Aufwands erbracht. Wir folgern, dass der Fertigstellungsgrad 90 % ist, nach einem weiteren Monat werden wir vermutlich fertig sein. Wenn aber die Schätzung um (nur) 11 % zu niedrig lag, haben wir tatsächlich noch zwei Monate vor uns; wir werden also von der Verzögerung überrascht.
Um den Fertigstellungsgrad einer Software zu beurteilen, sollten wir nicht den geschätzten Gesamtaufwand, sondern den Restaufwand, den noch notwendigen Aufwand bis zur Fertigstellung, zu Grunde legen. Mit anderen Worten: Wir verwenden nicht die ursprüngliche, sondern die aktuelle Aufwandsschätzung.
Diese ergibt sich als Summe des bereits erbrachten Aufwands und des Restaufwands:
Diese Größe hat den Vorteil, dass eine Übertreibung in irgendeine Richtung dem Mitarbeiter schadet: Ist der prognostizierte Restaufwand zu groß, wird die bereits geleistete Arbeit abgewertet, ist der Restaufwand zu klein, sind Probleme bei den nächsten Fortschrittskontrollen programmiert.
Auf ein mögliches Missverständnis sei hier vorsorglich hingewiesen: Der prognostizierte Restaufwand oder der prognostizierte Gesamtaufwand wird nicht automatisch zum neuen geplanten Aufwand und somit zu einer neuen Zielgröße. Der Planwert gilt weiterhin, und eine abweichende Prognose ist eine Aufforderung, Maßnahmen zur Beseitigung dieser Abweichung zu ergreifen.
In Organisationen, in denen der erfasste Ist-Aufwand erst nach Wochen zur Verfügung steht, kann diese Größe nicht zur Vorhersage des Restaufwands herangezogen werden, denn sonst liegt die Bewertung des Fertigstellungsgrads erst zu einem Zeitpunkt vor, zu dem sie bereits überholt ist.
Ein anderer Ansatz umgeht dieses Problem, indem der Ist-Aufwand gar nicht verwendet wird. Als Referenz dient nicht der prognostizierte Gesamtaufwand, sondern der geplante Aufwand. Dabei wird der erarbeitete Wert nach folgender Gleichung bestimmt:
Erarbeiteter Wert = Geplanter Aufwand - Prognostizierter Restaufwand
Der Fertigstellungsgrad lässt sich auf dieser Basis durch folgende Formel berechnen:
Achtung, der erarbeitete Wert und damit der Restaufwand kann negativ werden, wenn das Projekt sehr sorglos geplant worden war, sodass während der Durchführung der Restaufwand höher ist als der zu Beginn geschätzte Gesamtaufwand.
Kennt man auch den Ist-Aufwand, so erlaubt der erarbeitete Wert Aussagen wie: »Wir haben 90 % des budgetierten Aufwands geleistet, aber erst 80 % der Aufgabe erledigt.«
Den Fertigstellungsgrad des gesamten Projekts kann man sehr einfach auf Basis der bereits abgeschlossenen Arbeitspakete nach folgender Beziehung ermitteln:
In diese Rechnung gehen die gerade bearbeiteten Arbeitspakete nicht ein. Das liefert Ergebnisse, die etwas zu niedrig sind. Bei einer geringen Gesamtzahl ist dieser Fehler möglicherweise inakzeptabel hoch; dann kann man Pakete, die gerade in Arbeit sind, mit 0,5 oder einem noch genauer abgeschätzten Gewicht berücksichtigen.
Das bisher beschriebene Verfahren ist für kleinere Projekte angemessen. Bei größeren und großen Projekten reicht es jedoch nicht aus. In solchen Projekten wird oft die sogenannte Earned Value Analysis (EV-Analyse) genutzt, ein vom US-Verteidigungsministerium entwickeltes Verfahren, um den Fortschritt eines Projekts zu bewerten und um Prognosen über den voraussichtlichen Endtermin und die zu erwartenden Gesamtkosten zu erhalten. Als Ergebnis der Analyse erhält die Projektleitung eine kleine Menge von Kennzahlen, die sie als Steuerungsgrößen nutzen kann.
Als Datenlieferanten der EV-Analyse dienen die Kostenplanung durch Angabe der geplanten Kosten über die Projektlaufzeit und der geschätzten Gesamtkosten (Budget At Completion, BAC) sowie die Buchhaltung, die die bis zum Berichtszeitpunkt aufgelaufenen Projektkosten kennt. Natürlich stützt sich die EVAnalyse auch auf die Bewertung der einzelnen Arbeitspakete. Für diese müssen die folgenden Werte ermittelt werden, die dann auf Projektebene zusammengefasst werden:
1. Geplante Kosten (Planned Value, PV)
Das sind die bis zum Berichtszeitpunkt laut Planung vorgesehenen Kosten für ein Arbeitspaket.
2. Tatsächliche Kosten (Actual Cost, AC)
Das sind die bis zum Berichtszeitpunkt tatsächlich entstandenen Kosten für ein Arbeitspaket.
3. Erarbeiteter Wert (Earned Value, EV)
Das sind die geplanten Kosten für den Wert der bis zum Berichtszeitpunkt geleisteten Arbeit. EV gibt also die geplanten Kosten für ein Arbeitspaket an, gemessen am tatsächlichen Fertigstellungsgrad.
Betrachten wir dazu das folgende sehr einfache Beispiel: Ein Arbeitspaket soll mit der Kalenderwoche 37 beginnen und fünf Arbeitstage erfordern; jeder Arbeitstag kostet 1000 € (1 k€). Die geplanten Kosten sind somit 5 k€. Zum Berichtszeitpunkt am Ende der KW37 stellt sich die Situation so dar: Das Arbeitspaket konnte nicht wie geplant am Montag, sondern erst am Dienstagmittag in Angriff genommen werden; damit sind Kosten in Höhe von 3,5 k€ entstanden. Durch unerwartete Probleme wurde in diesen dreieinhalb Tagen nur die Arbeit geschafft, für die drei Tage (entsprechend 3 k€) vorgesehen waren. Wir haben damit als Kennwerte PV = 5 k€, AC = 3,5 k€, EV = 3 k€.
Mit Hilfe dieser Basisgrößen lassen sich nun die Kosten- und die Zeitabweichung relativ zur Planung bestimmen.
Kostenabweichung (Cost Variance, CV = EV - AC)
Sie ergibt sich aus der Differenz zwischen erarbeitetem Wert und tatsächlichen Kosten. Ist sie negativ, dann hat die Arbeit nicht so viele Werte geschaffen, wie sie gekostet hat.
Planabweichung (Schedule Variance, SV = EV - PV)
Sie berechnet sich aus der Differenz von erarbeitetem Wert und den zum Berichtszeitpunkt geplanten Kosten. Die Planabweichung wird also durch die finanzielle Differenz zur Planung ausgedrückt. Ist der SV-Wert negativ, dann liegt das Projekt gegenüber der Planung zurück, und zwar um Arbeit im Umfang des SV-Wertes.
In unserem Beispiel erhalten wir die folgende Werte:
CV = 3 k€ - 3,5 k€ |
= -0,5 k€ |
SV = 3 k€ - 5 k€ |
= -2 k€ |
Sie bedeuten, dass das, was bisher erarbeitet wurde, 500 € teurer war als geplant und dass wir einen Arbeitsrückstand äquivalent zum Wert von 2000 € haben.
Wie bereits erwähnt, wird die EV-Analyse auf Projektebene durchgeführt. Die PV-Werte aus der Kostenplanung kann man in einem Diagramm über der Zeit auftragen. Fügt man regelmäßig die ermittelten EV-Werte und die aktuellen AC-Werte aus der Buchhaltung hinzu, dann entspricht der vertikale Abstand der EV-Kurve von den PV- und AC-Kurven den Größen SV und CV (Abb. 8–13).
Abb. 8–13 Darstellung von Kosten- und Planabweichung
Die EV-Analyse kann auch genutzt werden, um die Gesamtkosten und den Fertigstellungstermin vorherzusagen. Dazu dienen zwei Leistungskennzahlen:
Cost Performance Index (CPI = EV / AC)
Dieser setzt den Wert der tatsächlich geleisteten Arbeit ins Verhältnis zu den tatsächlichen Kosten. Ist der Quotient größer als eins, dann war die geleistete Arbeit günstiger als geplant; ist er kleiner, dann war sie teurer.
Schedule Performance Index (SPI = EV / PV)
Hier wird die tatsächlich geleistete Arbeit zu den geplanten Kosten ins Verhältnis gesetzt. Ist der Wert größer als eins, dann konnte mehr erreicht werden als geplant. Ist er kleiner als eins, dann ist der Arbeitsfortschritt geringer als angenommen.
Dementsprechend sollten die Werte für CPI und SPI in einem gut geführten Projekt nur in einem schmalen (und definierten) Intervall um 1 liegen.
Unser Beispielprojekt liefert für den Berichtszeitpunkt nach Woche 9 folgende Werte: PV = 70 k €, AC = 85 k€, EV = 60 k€ (Abb. 8–13). Daraus berechnen wir als Kennzahlen CPI = 0,71 und SPI = 0,86. Sie bedeuten, dass wir bis jetzt 14 % weniger Leistung erbracht haben als geplant. Da wir gleichzeitig mehr Aufwand hatten, als vorgesehen war, liegen wir sogar 29 % unter der Leistung, die nach den Kosten zu erwarten wäre. Das Projekt erfordert also massive Eingriffe oder gar den Abbruch.
Wenn aufgrund von Erfahrungen angenommen werden kann, dass die ermittelten Leistungskennzahlen typisch sind und sich im weiteren Projektverlauf nicht wesentlich ändern werden, dann können Prognosen gestellt werden:
Wie viel wird das Projekt am Ende kosten?
Die auf Basis der aktuellen Bewertung prognostizierten Projektkosten (Independent Estimate At Completion, IEAC) berechnen sich als Verhältnis vom anfangs geschätzten Gesamtaufwand (BAC) zum Cost Performance Index.
IEAC = BAC / CPI
Wie viel Zeit werden wir für das Projekt benötigen?
Die voraussichtliche Projektdauer (Independent Schedule At Completion, ISAC) kann auf Basis der geplanten Dauer und des Schedule Performance Index bestimmt werden.
ISAC = Geplante Dauer / SPI
Statt nach einer Prognose können wir auch fragen, ob es durch höhere Leistung möglich ist, das Projekt noch zu den geplanten Kosten fertigzustellen. Über das ganze Projekt hinweg hätte ein CPI = 1 ausgereicht. Bislang wurden aber nur 71 % (CPI) der erwarteten Leistung erreicht.
Die noch ausstehende Arbeit ist BAC - EV, das noch verfügbare Budget BAC - AC. Bis zum Projektabschluss müsste also der To Complete Performance Index (TCPI) gelten:
TCPI = (BAC - EV) / (BAC - AC)
Mit den bereits ermittelten Kennzahlen erhalten wir für unser Beispielprojekt die folgenden Prognosen:
IEAC |
= 110 k€ / 0,71 = 155 k€ |
41 % Mehrkosten! |
ISAC |
= 17 Wochen / 0,86 = 19,8 Wochen |
16 % Zeitüberschreitung! |
Die Frage nach dem erforderlichen TCPI ergibt:
TCPI = (110 k€ - 60 k€) / (110 k€ - 85 k€) = 50/25 = 2
Ein TCPI von 2 bedeutet, dass das Projektteam ab dem Berichtszeitpunkt 200 % der Leistung bringen müsste, die ursprünglich gefordert war, um das Projekt zu den geplanten Kosten abzuschließen. Gegenüber der bisherigen Leistung (71 %) ist fast eine Verdreifachung notwendig. Das ist offensichtlich irreal. Selbst ein wesentlich kleineres »Über-Soll« wie 120 % ist nur schwer und nicht auf Dauer zu schaffen.
Durch die Projektverfolgung, wie sie im vorigen Abschnitt beschrieben ist, werden Daten gesammelt, die den Stand des Projekts charakterisieren und später die Chance bieten, Schwächen des Projekts zu erkennen, sodass sie bei weiteren Projekten vermindert oder vermieden werden können. Dazu müssen die Informationen möglichst anschaulich visualisiert werden; eine simple Tabelle reicht nicht aus, auch wenn sie rein formal alle Informationen enthält.
Eine besonders eingängige Darstellung des Projektverlaufs und der aufgetretenen Abweichungen von der Planung erhält man durch das Termindrift-Diagramm. In der Literatur wird es meist als Meilenstein-Trend-Analyse bezeichnet, das suggeriert aber eine Methode, wo es sich nur um eine einfache Darstellungstechnik handelt. Leider finden wir nirgends eine Angabe, die den Urheber würdigt.
Die Grundidee besteht darin, in einem Koordinatensystem aus zwei Zeitachsen einzutragen, wie sich die Termine für das Erreichen bestimmter Meilensteine im Laufe des Projekts verändern (oder nicht verändern). Prinzipiell ist es natürlich gleichgültig, ob man die vertikale Achse nach oben oder nach unten zeigen lässt; wir ziehen (wegen der Schreib- und Leserichtung von links nach rechts und von oben nach unten) die hier gezeigte Form vor.
Die Abbildung 8–14 zeigt ein einfaches (und untypisches) Beispiel. Zum Anfang des Projekts (links) gibt die Planung die vertikale Achse mit den geplanten Meilensteinen vor. Mit fortschreitender Zeit wächst das Diagramm von links nach rechts. Immer, wenn der Stand des Projekts neu eingeschätzt und die Planung eventuell verändert wird, können unter dem entsprechenden Punkt der horizontalen Achse die geplanten Meilensteine markiert werden. Im Beispiel wird M1 planmäßig erreicht, und zum selben Zeitpunkt stellt sich heraus, dass M2 früher als ursprünglich erwartet erreicht werden kann. Dadurch entsteht die Stufe nach oben. Wenn die Meilenstein-Linie die Diagonale trifft, ist der Meilenstein erreicht; das Gebiet rechts über der Diagonalen ist Vergangenheit, es hat keinen Sinn, die Linien dort weiterzuführen.
Abb. 8–14 Termindrift-Diagramm zu Beginn und nach Ende des Projekts
Offensichtlich werden in einem perfekt geplanten Projekt die Meilensteine genau zum geplanten Zeitpunkt erreicht (M1 in Abb. 8–14). War die Planung allzu ängstlich oder wurde der Aufwand überschätzt, so werden Meilensteine früher erreicht, als geplant war (M2); im sehr viel häufigeren Fall einer allzu sorglosen Planung ist das Gegenteil der Fall (alle Meilensteine in Abb. 8–15).
Abb. 8–15 Termindrift-Diagramm, Beispiel mit Verzug beim Erreichen aller Meilensteine
wie die ursprüngliche Planung war (die Zieltermine der Meilensteine),
wann die Planung korrigiert wurde,
wann die Meilensteine tatsächlich erreicht wurden.
Am Ende eines schlecht geplanten und entsprechend schlecht gelaufenen Projekts ähnelt das Diagramm den Schleuderspuren eines Autos, dessen Fahrer die Schwierigkeiten und Risiken der Fahrt unterschätzt hatte. So erkennt man in Abbildung 8–15, dass sich der Projektleiter auch nach frühen Anzeichen für Planungsfehler nicht zu einer Totalrevision entschließen konnte. Stattdessen hat er wider besseres Wissen angekündigt, die späteren Meilensteine wie geplant zu erreichen, und an der falschen Prognose festgehalten, bis die Termine jeweils kurz bevorstanden.
Oft enden Projekte ohne eigentlichen Abschluss. Viele Mitarbeiter verlassen das Projekt schon vor der Auslieferung, andere haben noch darüber hinaus mit Nacharbeiten zu tun. Auf diese Weise fehlen sowohl die objektive Dokumentation der mit diesem Projekt erreichten Erfolge und Misserfolge als auch das subjektive Bewusstsein der Beteiligten, auf etwas Abgeschlossenes zurückblicken zu können.
Zu den administrativen Arbeiten gehört zunächst die Archivierung der Projektresultate und aller Projektunterlagen.
Organisatorisch ist es notwendig, die Projektorganisation aufzulösen und alle Projektmitarbeiter in neuen Aufgaben unterzubringen. Dies macht vor allem bei einer reinen Projektorganisation Arbeit. Oft müssen noch einige Restarbeiten erledigt werden, auch wenn das Projekt schon abgeschlossen ist. Diese müssen identifiziert und Personen zugewiesen werden.
Der Abschluss eines Projekts bietet wie kein anderer Moment die Möglichkeit, durch Aufzeichnung von Projektkennzahlen aus verschiedener Sicht ein plastisches Bild des Projekts festzuhalten, das für die Planung weiterer Projekte benutzt werden kann. Es sind mindestens die Standpunkte des Projektleiters, eines erfahrenen Entwicklers und der Kosten-/Terminplanstelle zu berücksichtigen.
Traditionell vollziehen die Menschen Rituale, wenn eine größere Veränderung stattgefunden hat. Meist sind diese Rituale religiös geprägt. Typische Beispiele sind die Begrüßung eines Neugeborenen, die Aufnahme in den Kreis der Erwachsenen, die Heirat oder die Totenfeier. Auch im Beruf gibt es eine Reihe solcher Rituale, beispielsweise die Aufnahme unter den Handwerksgesellen oder die Priesterweihe. Offensichtlich ist der wesentliche Zweck des Rituals, die Veränderung für alle Menschen deutlich zu machen.
Auch Projekte durchlaufen verschiedene Zustände. Auf dem Bau kennen wir die Grundsteinlegung, das Richtfest und die Schlüsselübergabe. Mehr noch als bei einem Haus, das gut sichtbar aus dem Fundament wächst, sind bei der Entwicklung eines Software-Systems Rituale extrem nützlich. Mindestens die drei Meilensteine Projektstart, Fertigstellung der Konzeption und Abschluss sollten Anlass sein, die Veränderung durch ein Fest im Bewusstsein der Beteiligten (Projektleiter und Mitarbeiter, Kunden, Projekteigentümer, Management) zu verankern.
Die Rückschau wird am besten in einem Dokument mit einer dem Projektplan ähnlichen Gliederung zusammengefasst (Abb. 8–16).
Die ersten vier Kapitel dienen einer kompakten Darstellung der gesammelten Informationen. Die beiden letzten Kapitel sollen Interpretation und Umsetzung in Maßnahmen enthalten.
Um vergleichbare Erfahrungswerte zu bekommen, insbesondere Werte, die für die Planung des nächsten Projekts nützlich sind, ist es wichtig, die wesentlichen Projektstrukturen, z.B. die Phasenfestlegung oder die Gliederung in Arbeitspakete, über einen längeren Zeitraum konstant zu halten.
Abb. 8–16 Inhaltsverzeichnis der Projektgeschichte
Projektmanagement ist und bleibt eine sehr komplexe Aufgabe, die sich nicht durch einige einfache Regeln beschreiben oder verbessern lässt. Aber in der Praxis sieht man immer wieder, dass sehr simple Fehler gemacht werden. Zumindest diese kann man durch Beachtung einiger Regeln vermeiden. Besonders kritisch ist die Besetzung der Projektleiter-Rolle.
Die Wahl des Projektleiters ist von großer Bedeutung, denn nur, wenn der Projektleiter das ihm übertragene Projekt angemessen leiten kann, hat es eine Erfolgschance. Ein geeigneter Projektleiter ist eine notwendige Voraussetzung für ein erfolgreiches Projekt.
Natürlich gibt es den idealen Projektleiter nicht. Bei der Auswahl sollte jedoch immer beachtet werden, dass jedes Projekt individuelle Randbedingungen und Probleme hat, denen die Qualifikationen und Fähigkeiten des Projektleiters entsprechen sollten. Je größer ein Projekt ist, desto mehr Management- und Organisationstalent ist gefragt. Technisches Verständnis ist hier weniger wichtig, dies kann von einem Mitglied des Projektteams ergänzt werden.
In der Praxis beginnt die typische Projektleiterlaufbahn damit, dass jemand auf Grund guter technischer Leistungen zum Projektleiter ernannt wird. Diese Person kann und will einen solchen Karriereschritt in der Regel nicht ablehnen, auch wenn die neue Rolle nicht unbedingt den eigenen Neigungen und persönlichen Zielen entspricht. Eine Absage würde in vielen Fällen das Ende der Karriere bedeuten, da Karriere oft ausschließlich über Projekt- und Mitarbeiterverantwortung definiert ist. Eine technische Karriere (zum Chef-Entwickler oder Senior Software Engineer) gibt es nur selten.
Als Konsequenz dieser Karrierepolitik leiten Mitarbeiter Projekte, obwohl sie in technischen Bereichen viel bessere Leistungen erzielen könnten. Andere arbeiten technisch, obwohl sie in organisatorischen Bereichen deutlich mehr Erfolg hätten.
Auf Grund der zentralen Rolle im Projekt und der vielseitigen Tätigkeiten, die er durchführen muss, werden von einem guten Projektleiter viele Qualifikationen und Fähigkeiten gefordert. Dazu zählen:
Fachliche Qualifikation
Der Projektleiter benötigt kaufmännisches Know-how, Wissen über die Anwendung, die erstellt werden soll, und natürlich auch Software-technisches Wissen.
Projektmanagement-Qualifikationen
Der Projektleiter muss gängige Techniken der Planung, der Schätzung, der Planverfolgung und des Zeitmanagements beherrschen. Aber auch Verhandlungsgeschick im Umgang mit dem Auftraggeber und dem eigenen Management ist gefragt.
Führungsfähigkeiten
Als Leiter des Entwicklungsteams benötigt der Projektleiter Offenheit, Kommunikations- und Entscheidungsfähigkeit, Bereitschaft zum Delegieren, Fähigkeit zur Motivation und zur Vermittlung zwischen den beteiligten Personen.
Persönliche Fähigkeiten
Dazu zählen beispielsweise Verantwortungswille, Belastbarkeit, Beharrlichkeit, Teamgeist, Geduld, Fähigkeit zum Umgang mit unterschiedlichen Typen von Menschen und Konfliktfähigkeit.
Es gibt zahlreiche Studien über den Projekterfolg oder -misserfolg und über die Gründe dafür. Am weitaus häufigsten wird der sogenannte »Chaos-Report« zitiert, den die Standish Group regelmäßig veröffentlicht. Allerdings sind die Zahlen darin zwar spektakulär, aber nicht seriös begründet, sodass man sie nicht zitieren sollte; der Artikel von Bob Glass (2005) setzt sich kritisch mit diesen Zahlen auseinander. Wir sind – anders als der Standish-Report – überzeugt, dass die meisten Software-Projekte insgesamt erfolgreich abgeschlossen werden. Aber es gibt auch – nicht nur in den gescheiterten Projekten – schwere Probleme; die Ergebnisse der Studie von Mandl-Striegnitz und Lichter (1999) belegen das. Wir sehen dafür vor allem die folgenden Gründe:
Mangelnde Ausbildung
In vielen Fällen übernehmen Personen die Leitung eines Projekts, ohne vorher die notwendigen Managementkonzepte, Methoden und Techniken zu erlernen. Lernen durch Fehlermachen ist die logische Konsequenz. Das funktioniert aber bei weitem weniger gut als allgemein angenommen. Denn es setzt voraus, dass der Lernende die Möglichkeit hat, Fehler zu erkennen, zu reflektieren und zu korrigieren. In einem Projekt mit hartem Termindruck und reichlich Problemen hat er diese Möglichkeit kaum.
Unrealistische Erwartungen des oberen Managements
Oft werden von Seiten des oberen Managements ungünstige Randbedingungen für Projekte vorgegeben. Trotzdem sollen die Projekte erfolgreich durchgeführt werden. So ist es beispielsweise unmöglich, hochqualitative Software zu entwickeln, wenn die Termine viel zu eng sind und zu wenig und häufig noch unzureichend geschultes Personal zur Verfügung steht.
Implizite Kundenerwartungen
Der Kunde erwartet, dass das Projekt Anforderungen realisieren soll, die nie klar formuliert wurden.
Sie erwarten Informationen vom Projektleiter, geben aber eigene Informationen, z. B. über den bereits geleisteten Aufwand, selbst nicht korrekt weiter.
Eigener Anspruch
Übernimmt der Projektleiter zusätzlich auch noch technische Aufgaben, so wird ab einer bestimmten Belastung einer der beiden Bereiche darunter leiden. Da die Ergebnisse der technischen Aktivitäten besser sichtbar und bewertbar sind als die Management-Aufgaben, werden die technischen Aktivitäten vorgezogen.
Aus diesen Feststellungen folgern wir speziell für die Projektleiter:
Projektleiter müssen ausgebildet sein! Wie jedes andere Teammitglied muss auch der Projektleiter die notwendigen Fähigkeiten mitbringen.
Projektleiter müssen ernst genommen werden! Dies gilt insbesondere für die vom Projektleiter erstellten Planungen, Schätzungen und Risikobetrachtungen.
Die Zusammenarbeit mit dem Management muss reibungslos funktionieren.
Nur dann können die notwendigen Entscheidungen im Projekt abgestimmt und zielführend getroffen werden.
Die Auftraggeber müssen erkennen, dass ohne ihre eigene intensive Beteiligung keine brauchbaren Systeme entstehen können.
Die Mitarbeiter müssen lernen, systematisch und nach Vorgaben zu arbeiten und ihre Ergebnisse angemessen zu dokumentieren.
Die Projektleiter müssen sich auf die Aufgaben des Projektmanagements konzentrieren.
Bei Entwicklungsprojekten treten immer wieder Führungsprobleme auf. Aus der Sicht des Projektleiters (Manager-Perspektive) sind mögliche Ursachen dafür:
Die Mitarbeiter sind nicht zielstrebig.
Die Eigeninitiative der Mitarbeiter ist unzureichend, sie lassen sich kaum fördern.
Die Mitarbeiter haben kein Verständnis oder gar Interesse für »höhere« Ziele, also die Ziele der Organisation oder Firma.
Den Mitarbeitern fehlt bei ihren Entscheidungen das Kostenbewusstsein.
Die Spezialisten genießen ihre Macht und sind entsprechend arrogant.
Aus Sicht der Mitarbeiter (Frosch-Perspektive) stellt sich das natürlich anders dar. Als Ursachen werden hier gesehen:
Die Mitarbeiter erhalten keine Informationen über den Projektstand, über Änderungen der Rahmenbedingungen und über Entscheidungen, die das Projekt betreffen.
Den Mitarbeitern werden keine Anreize geboten, sie werden nicht motiviert.
Die persönlichen Interessen der Mitarbeiter werden ignoriert.
Aufgabe, Vollmachten und Verantwortung werden voneinander getrennt.
Die Führung fehlt; Zielvorgabe, Kontrolle, Beurteilung und Entscheidung werden voneinander getrennt.
Die Manager sind fachlich inkompetent, treffen aber dennoch fachliche Entscheidungen.
Die Beurteilung der erzielten Ergebnisse fehlt oder bleibt ohne Konsequenzen.
Die Rahmenbedingungen sind schlecht und werden nicht verbessert.
Das Management und – vor allem – der Verkauf treffen ohne Rücksprache Entscheidungen, die den Projekterfolg gefährden.
Die häufigsten Fehler des Projektleiters sind:
Keine Führung
Der Projektleiter ist nicht präsent, er kommuniziert nicht oder zu wenig.
Keine Beobachtung
Der Projektleiter nimmt die Arbeit der Mitarbeiter nicht wahr.
Keine Bewertung
Der Projektleiter bewertet die Arbeitsergebnisse nicht und bildet sich kein Urteil.
Keine Konsequenzen
Der Projektleiter trifft keine Entscheidungen als Folge von Bewertungen.
Technokratisches Verhalten
Der Projektleiter respektiert nicht das Bedürfnis der Mitarbeiter nach Information, Bewertung und Anerkennung; er berücksichtigt die persönlichen Interessen, z. B. nach Fortbildung, nicht oder zu wenig.
Projektleiter müssen so ausgewählt werden, dass sie auf Grund ihrer Fähigkeiten in der Lage sind, das Projekt zu leiten. Gute Entwickler sind nicht immer auch gute Projektleiter; wenn auch eine technische Karriere angeboten wird, sinkt der Druck, etwas zu tun, was manchem nicht liegt.
Projektleiter müssen geschult, ernst genommen und kontrolliert werden.
Aufgabe, Vollmacht, Verantwortung und Erfolg dürfen niemals voneinander getrennt werden.
Bei der Arbeitsteilung müssen die Zuständigkeiten für beide Seiten immer klar geregelt sein; es gilt das Vertragsprinzip.
Die Ziele bzgl. Terminen, Kosten, Ergebnissen und deren Qualität müssen klar definiert sein.
Die erreichten Zwischen- und Endergebnisse, auch der festgestellte Projektfortschritt, müssen laufend gegen die definierten Ziele kontrolliert werden.
Zuerst müssen die Ergebnisse beurteilt werden, dann sind die Mitarbeiter darüber zu informieren, anschließend müssen die notwendigen Konsequenzen (Belohnung, Schulung oder sonstige Änderung) daraus gezogen werden.
Metzger (1981) gibt in seinem Buch die folgenden Regeln an, um ein Projekt erfolgreich abzuschließen.
Rules of behavior for successful project management
1. Think people first, the business second. All a business is, is its people. Take care of them.
2. Establish a clear definition of your project’s development cycle and stick to it.
3. Emphasize the front-end of the project so that the rear-end won’t be dragging.
4. Establish baselines early and protect them from uncontrolled change.
5. State clearly the responsibilities of each person on the project.
6. Define a system of documents clearly and early.
7. Never give an estimate or an answer you don’t believe in.
8. Never forget Rule 1.
