Software-Projektmanagement Ausarbeitung

Transkript

1 Software-Projektmanagement Ausarbeitung Björn Lohrmann (220642) Software Engineering Projekt WS 07/08 TU-Berlin

2 Inhalt 1 Einführung Motivation Organisation der Ausarbeitung Projektmanagement Allgemein Projektbegriff Projektziele Projektmanagement Projektphasen und Vorgehensmodell Projektstart Vorstudie Machbarkeitsstudien Grobe Ziele und Plan Beschluss zur Durchführung Projekteinrichtung Projektdefinition Projektplanung Meilensteine Projektstrukturplan (PSP) Aktivitäten und Arbeitspakete im PSP Größen- und Aufwandsschätzungen Aktivitätenzeitplan Balkendiagramme Netzpläne Aufbau Netzplan-Beispiel Kritischer Pfad Ressourcenplanung Kostenplan Projektdurchführung Kontrolle Fortschrittsüberwachung Aktivitätenebene Projektebene Steuerung Quellen

3 1 Einführung Software ist zu einem Bestandteil unseres alltäglichen Lebens geworden, sei es in Form von Programmen, die unsere Waschmaschine steuern, unser Auto bei Glatteis auf der Straße halten oder in Form eines Web-Browsers, über den wir die aktuellsten Nachrichten aus dem Internet beziehen. Mit rasantem Tempo hat Software faktisch alle modernen Lebensbereiche durchdrungen. Im Besonderen spielt Software eine große Rolle in vielen Industriebereichen, da der Einsatz von Software erst die effiziente Umsetzung vieler Aufgaben ermöglicht. Die zielgerichtete Erstellung von Software in Projektform ist somit ein kritischer Faktor für viele Unternehmen. Die hierbei eingesetzten Management-Techniken bestehen zum Teil aus etablierten Methoden, die auch außerhalb der Softwarebranche eingesetzt werden, z.b. Zeitplanungstechniken oder Projektorganisation. Es wird allerdings auch eine Vielzahl anderer softwarespezifischer Techniken notwendig um die speziellen Anforderungen des Software-Projektmanagements zu erfüllen, so z.b. der Einsatz bestimmter Prozesse bzw. Vorgehensmodelle oder Techniken zur Aufwandsschätzung. Diese Ausarbeitung wird auf Basis des Buches [1] die allgemeinen und speziellen Aspekte von Software-Projektmanagement zusammenfassend darstellen. 1.1 Motivation Warum ist es nun wichtig im Speziellen auf die Aspekte des Software- Projektmanagements einzugehen? Studien, wie z.b. die regelmäßig von der Standish-Group durchgeführten Chaos-Studien belegen, dass ein großer Prozentsatz von Software-Projekten nicht die von der ursprünglichen Planung festgelegten Kosten- und Terminziele erfüllt. Aus [1] wurden folgende Werte entnommen: Abgebrochen 31% 23% 18% Über Kosten- oder Termin Plan 53% 49% 53% Im Plan 16% 28% 29% Trotz steigender Tendenz zu erfolgreichen Software-Projekte, die sich innerhalb des Kosten- und Terminplans befinden, haben im Jahr 2004 bis zu 71% der durchgeführten Projekte ihre Ziele streng genommen nicht erfüllt. Die besondere Wichtigkeit des Projektmanagements wird klar, wenn man nun betrachtet, was in diesen 71% der Projekt zum Abbruch oder Nicht-Einhaltung des Plans geführt hat. Auch hierzu hat die Standish-Group Studien durchgeführt, die klar besagen, dass die schlechte oder nur mangelhafte Durchführung von Management Aktivitäten, allen voran das Anforderungsmanagement, sowie realistische Ziele und Planung 3

4 Hauptfaktoren für den Misserfolg von Projekten darstellen. Zuspitzend kann man sagen, dass es ohne gutes Management keine erfolgreichen Software-Projekte geben kann, was natürlich nicht das Scheitern eines Projekts trotz guten Managements ausschließt. 1.2 Organisation der Ausarbeitung Nach einer allgemeinen Vorstellung der Charakteristika eines Projekts und den allgemeinen Aktivitäten des Projektmanagements, orientiert sich die Ausarbeitung an den einzelnen Phasen eines Projekts. Zu jeder Phase wird zusammenfassend dargestellt, welche wichtigen Aktivitäten von Seiten des Projektmanagements durchzuführen sind. 2 Projektmanagement Allgemein 2.1 Projektbegriff Was zeichnet nun die Arbeit an einem Projekt aus? Die Gesamtheit der wichtigen Aspekte unterscheidet es von anderen Tätigkeiten, wie z.b. einer Hotline-Arbeit oder einem reinen Programmierjob: 1. Zeitliche Beschränktheit: In einem Projekt existieren üblicherweise feste Anfangs- und Endtermine, deren Überschreitung negative Konsequenzen hat. 2. Definierte Ziele: Projektziele sollten vorher fest definiert sein, vor allem um festzustellen welche Kriterien für den Erfolg eines Projektes angesetzt werden. 3. Komplexität: Die Arbeit an einem Projekt weist zumeist einen gewissen Grad an Komplexität auf. Diese kann sich z.b. aus den verwendeten Techniken, der Problemstellung selber oder den verschiedenen Interessenslagen der beteiligten Stakeholder ergeben. 4. Einmaligkeit: Die Kombination aus Projektzielen, Anforderungen, Umsetzung und beteiligten Personen führt zu einer Einmaligkeit des Vorhabens, mit der Konsequenz, dass es keine Musterlösung zur Umsetzung von Projekten gibt, sondern für jedes Projekt sollte beispielsweise das verwendete Vorgehensmodell neu evaluiert und angepasst werden. 5. Ausrichtung an strategischen Unternehmenszielen: Ein Projekt muss auf die mittel- bis langfristigen Unternehmensziele abgestimmt sein. 2.2 Projektziele Der bereits verwendete Begriffs des Projektziels verdient spezielle Beachtung, da of schon bei der Formulierung der Ziele Fehler gemacht werden. Ein Projektziel ist gemäß DIN ein nachzuweisendes Ergebnis und/oder eine vorgegebene 4

5 Realisierungsbedingung der Gesamtaufgabe. An den Projektzielen wird letztlich beurteilt, ob das Projekt erfolgreich war oder nicht. Hierbei sind folgende Aspekte hervorzuheben: Quantifizierbarkeit: Die Vorgaben, die ein Projektziel macht sollten nach Möglichkeit objektiv messbar sein, da ansonsten die Erfüllung eines Ziels nicht oder nur schwer nachweisbar ist. Erreichbarkeit: Ist ein Projektziel von vornherein nicht erreichbar, so wird das Projekt selber nie erfolgreich abgeschlossen werden können. Die Erreichbarkeit der Ziele sollte daher in technischen und wirtschaftlichen Machbarkeitsstudien geprüft werden. Nicht erreichbare Projektziele führen gemeinhin zur Demotivation der Beteiligten und suboptimaler Arbeitsleistung. Bei der Formulierung von Projektzielen sollte man sich immer im Dreieck Zeit, Kosten und Qualität bewegen. D.h. neben dem gewünschten Ergebnis selber, sollte auch festgelegt sein in welchem Zeit- und Kostenrahmen das Ziel sich bewegt, und welche besonderen Qualitätseigenschaften es aufweisen soll. 2.3 Projektmanagement Projektmanagement bezeichnet die Gesamtheit von Aktivitäten der Planung, Steuerung und Kontrolle eines Projekts in Hinsicht auf Projektziele. Ein Projekt lässt sich üblicherweise in die folgenden Phasen unterteilen: 1. Projektstart 2. Projektplanung 3. Projektdurchführung 4. Projektabschluss Die Aktivitäten des Projektmanagements stehen während dieser Phasen in einem Regelkreislauf, der in der folgenden Graphik dargestellt ist (Quelle: [1]): 5

6 In der Projektstartphase finden schwerpunktmäßig Planungsaktivitäten statt, später während der Durchführung finden schwerpunktmäßig Kontrolle und Steuerung von Projektaktivitäten statt, allerdings wird auch der Plan weiter gepflegt und verfeinert. Im erwähnten Regelkreislauf gibt der Plan Soll -Werte vor, d.h. er legt fest wer, wann welche Aufgaben mit welchen Ergebnissen durchführen soll. Diese Soll-Werte werden im Rahmen der Kontrollaktivitäten auf Erfüllung geprüft, d.h. sie werden mit gemessenen Ist-Werten während der Durchführungsphase verglichen. Ergeben sich hierbei Diskrepanzen zwischen Plan und Projektrealität, werden Steuerungsaktivitäten angestoßen, wie z.b. eine Anpassung des Plans oder direkte operative Maßnahmen mit dem Ziel das Projekt wieder auf den geplanten Kurs zu bringen. 2.4 Projektphasen und Vorgehensmodell Schon früh wurde die Notwendigkeit erkannt Vorgehensmodelle für die Entwicklung von Software aufzustellen. Diese Vorgehensmodelle stellen auf Erfahrungswerten basierende Schablonen für die Durchführung von Softwareprojekten dar. Über die Jahre wurden viele Ansätze, wie z.b. das Wasserfallmodell, das V-Modell oder agile Methoden aufgestellt und weiter verfeinert. Die Diskussion eines bestimmten Vorgehensmodells ist nicht der Schwerpunkt dieser Ausarbeitung, es sollte aber zumindest darauf verwiesen werden, dass ein solches Vorgehensmodell auf das zuvor aufgestellte Projektphasenmodell abgebildet wird, d.h. im Besonderen die Durchführungsphase wird durch das gewählte Vorgehensmodell strukturiert. 3 Projektstart Der Projektstart bezeichnet die erste Phase eines Projektes. Zu diesem Zeitpunkt existiert meistens erst eine vorläufige Projektleitung, ebenso ist weder das Team aufgestellt noch ist klar, ob das Projekt durchgeführt werden kann. Der Ausgangspunkt besteht zumeist darin, dass eine grobe Idee oder ein vom Kunden eingereichtes Lastenheft ein Projekt initiiert hat. Die Projektstartphase hat zum Ziel die technische und wirtschaftliche Machbarkeit eines Projektes zu untersuchen und im positiven Fall die sog. Projektdefinition zu formulieren, das Personal anzustellen und somit eine Grundlage für die darauffolgende Planungsphase zu schaffen. Die Projektstartphase lässt sich grob unterteilen in zwei Unterphasen: 1. Vorstudie 2. Projekteinrichtung Diese beiden Unterphasen werden im Folgenden nun erläutert und abschließend wird der Umfang und das Ziel der Projektdefinition beschrieben. 6

7 3.1 Vorstudie Die Vorstudienphase verfolgt eine eine Reihe von Zielen: 1. Die technische und wirtschaftliche Machbarkeit eines Projekts zu untersuchen. 2. Formulierung erster grober Projektziele 3. Aufstellen eines groben Plans 4. Beschluss zur Durchführung Machbarkeitsstudien Bereits an diesem Punkt beginnt gemäß [2] die Anforderungsermittlung. Der Kunde bzw. die Auftraggeber sollten zumindest grob ihre Anforderungen formulieren. Auf dieser Basis wird nun ermittelt, ob sie zum einen technisch aber auch wirtschaftlich umsetzbar und lohnend sind. Nicht alle Projektideen sind umsetzbar oder passen in die mittel- bis langfristige Strategie eines Unternehmens. Die technische Machbarkeit sollte generell gegeben sein, allerdings muss ein Projekt nicht zwingend kurzfristige Gewinne abwerfen. Auf lange Sicht kann es z.b. sinnvoll sein selbst verlustträchtige Projekte durchzuführen, solange sie z.b. einen Vorsprung im Know-How gegenüber Mitbewerbern oder technologische Grundlagen erschaffen auf Basis derer eine ganze Reihe von gewinnbringenden Projekten später umgesetzt werden kann. Zudem kann das einzelne Projekt Bestandteil eines ganzen Portfolio von zusammenhängenden Projekten sein. Diese Aspekte sind bei einer neuen Idee generell zu untersuchen und entsprechend zu formulieren um eine Grundlage zur Entscheidung bezüglich der Durchführung zu schaffen Grobe Ziele und Plan Bereits in der Vorstudienphase sollte sich die vorläufige Projektleitung über die groben Ziele des Projekts (Dimensionen Zeit, Kosten und Qualität) klar werden und einen groben Plan zum Erreichen dieser aufstellen. Der Plan besteht zu diesem Zeitpunkt zumeist nur aus eine Reihe von Meilensteinen, die mit vorläufigen Fertigstellungsterminen versehen sind. Es ist anzumerken, dass weder die Ziele noch der Plan vollständig festgeschrieben sind, da sie noch weitere Verfeinerungen unterlaufen. Bisher ist nur sehr grobes Wissen über die Anforderungen vorhanden und die Zeitschätzungen werden zu diesem Zeitpunkt meistens von der Projektleitung ermittelt und nicht von einer Expertengruppe in einem methodischen Prozess, wie es später in der Planung geschehen wird Beschluss zur Durchführung Haben die Machbarkeitsstudien positive Ergebnisse geliefert, so wird nun über die Durchführung eines Projektes entschieden. Selbst Projekte, die sich als machbar und gewinnbringend herausgestellt haben, werden nicht zwangsweise auch immer 7

8 durchgeführt. In größeren Unternehmen kann es passieren, dass eine ganze Reihe von Projekten zur Auswahl steht, aus denen dann nur die lohnendsten ausgewählt werden, z.b. in Hinsicht auf Gewinnmaximierung oder die langfristigen strategischen Ziele des Unternehmens. 3.2 Projekteinrichtung Ausgangspunkt für die Projekteinrichtung ist ein stehender Beschluss zur Durchführung des Projektes sowie die bereits aufgestellten Ziele und der Plan. Die Projekteinrichtungsphase hat zum Ziel die Projektstrukturen (vor allen Dingen Personal und Organisation) festzulegen und zudem die Ziele und den Plan weiter zu verfeinern. Zu Beginn bietet es sich an, dass die nun finale Projektleitung ein Kernteam von Mitarbeitern einsetzt. In größeren Projekten sind dies zumeist die nächsttieferen Verantwortlichen (z.b. Team-Leader etc.), in kleineren Projekten kann dies bereits das finale Team darstellen. Um alle neuen Beteiligten auf einen Informationsstand zu bringen, bieten sich sog. Kick-Offs an. Dies sind reine Informationsveranstaltungen in denen die Projekt-Teilnehmer einander vorgestellt werden und der bisherige Wissensstand zusammenfassend kommuniziert wird. Es ist von Vorteil auch die Vorstellungen zur Projektkultur festzulegen, z.b. wann und in welcher Form in Zukunft Meetings abgehalten werden. Mit mehr Mannstärke kann nun z.b. in Form von Workshops die weitere Verfeinerung der Ziele, der Strategie und des Plans voranschreiten. In Workshops werden durch Recherche weitere Informationen zum Projekt gesammelt. Die Organisation des Projekts wird weiter verfeinert, z.b. werden Aufgabenbereiche und Verantwortlichkeiten abgesteckt und benötigte Teamstärken bestimmt. Die Wahl bzw. Erstellung eines geeigneten Prozesses/Vorgehensmodells sollte auch an dieser Stelle stattfinden. Zudem wird falls notwendig noch weiteres Personal hinzugezogen, so dass am Ende der Projekteinrichtungsphase (und damit auch Projektstartphase) ein Kick-Off des finalen Projektteams stattfinden kann, auf dem ähnlich wie auf dem bereits davor geschehenen Kernteam-Kickoff die Informationen zur Vision, dem Projektinhalt, der Organisation und der vorläufigen Planung kommuniziert werden. 3.3 Projektdefinition Die Projektdefinition ist ein Artefakt, das zusammenfassend die Ergebnisse der Projektstartphase enthält und damit die wichtigsten Aspekte des Projekts für alle Stakeholder, d.h. sowohl die Projektmitglieder, aber auch Vorgesetzte oder Auftraggeber zur Verfügung stellt. Gemäß [1] sind die wichtigsten Bestandteile einer Projektdefinition: 1. Motivation: Was sind die unternehmerischen Gründe für die Projektdurchführung, so z.b. Erarbeitung von Know-How für zukünftige 8

9 Projekte, Ergänzung des Produkt-Portfolios, Ziele (wie bereits definiert) 3. Produkte: Was ist der Output des Projekts, in welcher Form soll er vorliegen, was sind die Hauptbestandteile; falls vorhanden sollte hier auch auf die bereits ermittelten Anforderungen verwiesen werden. 4. Strategie: Der grobe Plan mit Meilensteinen und eine vorläufige Kostenplanung. 5. Organisation: Hierarchien, Teams und Verantwortlichkeiten, im Speziellen auch eine Beschreibung der Projektkultur und einzusetzenden Instrumente zur Fortschrittskontrolle. 6. Risikoanalyse: Eine Analyse der zentralen Risiken, die für das Projekt bestehen. Hier nicht weiter betrachtet. 4 Projektplanung Ausgehend von der Projektdefinition wird nun der grobe Plan verfeinert. Ziel ist es eine Basis für die Kontroll- und Steuerungsaktivitäten bereitzustellen und eine hohe Effizienz während der Durchführungsphase zu erreichen. Üblicherweise werden noch nicht alle Meilensteine komplett ausdetailliert, da dies mangels Informationen nicht möglich ist. Die parallel zur Planung laufende weitere Verfeinerung der Anforderungen ist strenggenommen keine Aufgabe des Projektmanagements, sondern bereits eine Entwicklungstätigkeit. Sie liefert jedoch nützliche Informationen für die Planung, da hier z.b. Aufwände konkreter Aufgaben geschätzt werden müssen. Die Projektplanung lässt sich in mehrere Unterphasen unterteilen: 1. Festlegung der Meilensteine (meist schon geschehen) 2. Erstellung eines Projektstrukturplans (PSP) (engl.: work breakdown structure, WBS) 3. Größen- und Aufwandsschätzungen 4. Erstellung eines Aktivitätenzeitplans 5. Erstellung eines Kostenplans Es ist wichtig hierbei zu erwähnen, dass diese Schritte nicht einmal streng nacheinander durchlaufen werden. Die Ausführung eines einzelnen Schritts kann und wird meistens zu Rückkopplungen mit den vorangegangenen Schritten führen. Beispielsweise kann sich in der zeitlichen Planung von Aktivitäten ergeben, dass die angesetzten Termine für Meilensteine nicht realistisch sind, so dass diese entweder in ihrem Umfang im PSP oder in ihrer zeitlichen Einteilung in der Meilenstein- Übersicht geändert werden müssen. 9

10 4.1 Meilensteine Meilensteine werden an einer Zeitachse dargestellt und markieren das Erreichen eines wichtigen und messbaren Zustands oder Ereignisses. Ein Meilenstein kann z.b. abgeschlossen sein, wenn ein Software-Prototyp fertiggestellt oder eine andere Form von Liefergegenstand (engl.: deliverable) erzeugt wurde. Die graphische Darstellung in den gängigen Tools ist in untenstehender Graphik exemplarisch aufgezeigt. 4.2 Projektstrukturplan (PSP) Eine gängige Methode um ausgehend von den Meilensteinen einen Schritt näher an die Aktivitäten zu kommen, ist die Erstellung eines Projektstrukturplans (PSP), der Aufgaben und/oder Liefergegenstände in einer hierarchischen Struktur bis zu einem ausreichenden Detailgrad aufschlüsselt. Ein PSP sollte möglichst vollständig alle Liefergegenstände/Aktivitäten des Projekts beinhalten. Dies umfasst nicht nur Implementation, sondern Projektmanagement-Aktivitäten, QS-Aktivitäten etc. Gemäß [2] gibt es mehrere Ansätze wie konkret ein PSP gegliedert werden kann. Es gibt zum einen die reine Orientierung an zu erledigenden Aufgaben, die in immer kleinere Aufgaben aufgeschlüsselt werden bis eine hinreichende Granularität erreicht ist und man handhabbare Aktivitäten erhält. Das andere Extrem ist die reine Orientierung an Liefergegenständen, die im PSP in ihre einzelnen Bestandteile zerlegt werden. In der Praxis haben sich Mischvarianten etabliert, z.b. die Variante aus IBMs MITP Projektmanagement Methode. Hier wird vorgeschlagen, dass die Struktur eines PSPs die folgenden Ebenen haben soll (von oben nach unten in der PSP Hierarchie): 1. Level: Das Projekt 2. Level: Die einzelnen Liefergegenstände des Projektes, z.b. die verschiedenen Prototypen. 3. Level: Die Komponenten eines Liefergegenstands, z.b. Programmmodule bei einem Prototypen 4. Level: Arbeitspakete (engl: work-packages) die bereits eine einzelne Aktivität darstellen oder aber nochmal Aktivitäten zusammenfassen 5. Level: Falls notwendig, den Arbeitspaketen untergeordnete konkrete 10

11 Aktivitäten, die meistens von einer oder wenigen Personen erledigt werden. Bei der Erstellung eines PSPs ist darauf zu achten die Arbeitspakete und letztendlich auch Aktivitäten nicht zu groß und nicht zu klein in ihrem Aufwand zu gestalten, da somit entweder keine vernünftige Fortschrittskontrolle möglich ist (zu groß) oder der Kontrollaufwand zu hoch ist (zu klein). Es existieren verschiedene Darstellungsformen für PSPs, z.b. als hierarchische Liste oder als Mindmap. An dieser Stelle wurde die Mindmap aufgrund ihrer optischen Wirkung bevorzugt. Ein Teil eines beispielhaften PSP in Mindmap-Form ist in der untenstehenden Graphik gezeigt Aktivitäten und Arbeitspakete im PSP Wie bereits erwähnt muss speziell auf eine angemessene Dimensionierung der Arbeitspakete und Aktivitäten geachtet werden. Weiterhin ist es sinnvoll diese noch einmal genauer zu beschreiben. Zu diesem Zweck bietet sich eine eindeutige Benennung der einzelnen PSP Knoten an, wie es auch in obiger Graphik demonstriert ist. Gemäß [1] sind erklärenswerte Aspekte eines Arbeitspakets bzw. einer Aktivität: Eine ausführliche Beschreibung Die durchführende(n) Person(en) Benötigte Qualifikationen zur Durchführung Aufwand (wird nach der Aufwandsschätzung im nächsten Schritt nachgetragen) evtl. Liefergegenstände Voraussetzungen zur Durchführung Kriterien/Kennzahlen um als korrekt erfüllt zu gelten 11

12 4.3 Größen- und Aufwandsschätzungen Nachdem der PSP das Projekt soweit möglich in kleine Elemente heruntergebrochen hat, sollte die Beschreibungen der einzelnen Arbeitspakete/Aktivitäten mit einer möglichst akkuraten Aufwandsschätzung versehen werden. Zum Schätzen selber gibt es viele Methoden, diese stehen allerdings nicht im Fokus dieser Ausarbeitung. Gemäß [1] sollte mit einer Größenschätzung (LOC, Anzahl Module, Dokumenten- Seiten,...) begonnen werden, die dann zu einer Aufwandsschätzung (Arbeitsstunden eines Mitarbeiters mit einem bestimmten Satz von Qualifikationen) verfeinert werden. Generell sind hierbei folgende Regeln zu beachten: 1. Schätzen sollte immer in Gruppen stattfinden. Die gemittelten Schätzwerte einer Gruppe sind meist besser, als die einer einzelnen Person. 2. Verwendung einer festen Methodik, zwecks Nachvollziehbarkeit der Ergebnisse. Die Methodik und auch Zwischenergebnisse sollten dokumentiert werden. 3. Verwendung von Erfahrungswerten oder sogar quantitativen Vergangenheitsdaten für ähnlich in der Vergangenheit erledigte Aufgaben. 4. Expertenschätzungen, z.b. könnten die späteren Bearbeiter der Aufgaben die Schätzungen durchführen. 4.4 Aktivitätenzeitplan Der Aktivitätenplan setzt die durch den PSP identifizierten und im Aufwand geschätzten Aktivitäten in einem konkreten Zeitrahmen zueinander in Beziehung. Hierbei definieren die durch die Meilensteinübersicht gegebenen Termine einen zeitlichen Spielraum, innerhalb dessen man Aktivitäten anordnen kann. Die Planung der Aktivitäten findet üblicherweise mittels Toolsupport statt, da die Pläne häufigen Änderungen und Optimierungen unterliegen. Es sind folgene Schritte iterativ auszuführen um den Aktivitätenzeitplan aufzustellen: 1. Abhängigkeiten zwischen Aktivitäten definieren 2. Geschätzte Aufwände einbringen 3. Ressourcen zuordnen 4. Den Meilensteinen zuordnen und Start-/Endtermine überprüfen Da die ersten Versionen des Plans meistens nicht optimal sind, d.h. z.b. die Endtermine der Meilensteine verfehlt werden sind Anpassungen nötig. So können beispielsweise Aktivitäten parallelisiert werden soweit es die Ressourcen zulassen. Falls es schlichtweg nicht möglich ist alle per PSP vorgesehenen Aktivitäten innerhalb eines Meilensteins zu erledigen müssen ggf. die Termine des Meilensteinplans oder aber der PSP selber angepasst werden. 12

13 Es gibt verschiedene Arten den Aktivitätenplan darzustellen. Im Folgenden werden zwei grundsätzliche Methoden erklärt, die unterschiedliche Ansätze verfolgen Balkendiagramme Balkendiagramme sind ein recht einfaches und intuitives Mittel zur Darstellung eines Aktivitätenzeitplans. Eine Aktivität wird dargestellt als Balken auf einer Zeitleiste und Abhängigkeiten werden durch Pfeile zwischen Aktivitäten modelliert (siehe Beispielgraphik). Ein Vorteil der Balkendiagramme liegt in ihrer Intuitivität, was konsequenterweise auch bedeutet, dass sie selbst von Personen gut zu verstehen sind, die sich nicht mit dem Werkzeug oder der speziellen Darstellungsweise auskennen. Für ein größeres Projekt wird allerdings auch das dazugehörige Balkendiagramm sehr groß. Dieses Problem wird in den meisten Tools dadurch gemildert, dass sich Aktivitäten zusammenfassen und die Ansicht sich nur auf die wesentlichen Details reduzieren lässt. Die Darstellungsform als Balkendiagramm enthält allerdings wiederum bestimmte Informationen nicht, die einen bei einer detaillierten Beschäftigung mit der Zeitplanung interessieren würden, so z.b. der kritische Pfad. Die im Folgenden angerissenen Netzpläne bieten genau dies Netzpläne Aufbau Ein Netzplan stellt Aktivitäten als Knoten in einem Graphen dar. Die Abhängigkeiten zwischen Aktivitäten sind die Graphenkanten, wobei theoretisch folgende Arten von Abhängigkeiten möglich sind: 1. Ende-Anfang: Vorgänger muss beendet sein, bevor Nachfolger beginnen kann. Beispiel: Implementation muss beendet sein, bevor getestet wird 2. Ende-Ende: Vorgänger muss beendet sein, bevor Nachfolger beendet sein kann. Dies beschreibt zumeist eine Form der Aggregation von Aktivitäten. 13

14 Beispiel: Die Zeitplanung muss beendet sein bevor die Projektmanagement- Aktivitäten enden. 3. Anfang-Anfang: Vorgänger muss begonnen haben, bevor der Nachfolger angefangen werden kann. Beispiel: Die Anforderungsermittlung muss begonnen haben bevor damit begonnen werden kann einen vorläufigen Projektplan aufzustellen. 4. Anfang-Ende: Vorgänger muss begonnen haben, bevor Nachfolger beendet sein kann. Am gebräuchlichsten sind Ende-Anfang Beziehungen in Netzplänen. Anfang-Ende Beziehungen wird nur eine theoretische Bedeutung zugemessen. Die Knoten enthalten in ihrer graphischen Darstellung meist noch weitere Informationen über die Aktivität. Hier z.b. ein exemplarischer Knoten eines Netzplans: Die Dauer der Aktivität ist der geschätzte Zeitaufwand. Der Gesamtpuffer berechnet sich aus der Differenz zwischen frühestem und spätestem Anfang bzw. frühestem und spätestem Ende Netzplan-Beispiel Im untenstehenden Netzplan sind eine Reihe von Aktivitäten definiert mit entsprechenden Ende-Anfang Abhängigkeiten untereinander. Die rot markierten Knoten liegen auf sog. kritischen Pfaden. 14

15 Kritischer Pfad Ein Netzplan kann einen oder mehrere kritische Pfade enthalten. Ein kritischer Pfad ist ein Pfad durch den Netzplan, auf dem alle Knoten einen Gesamtpuffer von Null haben. Dem kritischen Pfad kommt in der Planung besondere Bedeutung zu. Die Entstehung von kritischen Pfaden sollte möglichst vermieden werden, da sich Verzögerungen auf diesem Pfad direkt auf den Meilenstein oder die übergeordnete Aktivität auswirken. Dem kann auf verschiedenen Ebenen begegnet werden. Zum einen kann auf der Planungsebene von vornherein darauf geachtet werden, dass die Anzahl der Knoten mit einem Gesamtpuffer von Null minimal gehalten wird. Lässt es sich nicht vermeiden, so sollten die Aktivitäten auf dem kritischen Pfad verstärkt beobachtet (Kontrollaktivität) werden um möglichst zeitnah Diskrepanzen festzustellen und reagieren zu können. Verzögert sich eine Aktivität muss entweder der Plan optimiert oder verkleinert werden (oft nicht mehr möglich) oder die übergeordnete Deadline muss zwangsweise verschoben werden, was sich möglicherweise negativ auf die Kundenzufriedenheit auswirkt Ressourcenplanung Jede Aktivität benötigt einen gewissen Einsatz von Ressourcen, beispielsweise in Form von Personal, Arbeitsgeräten, etc. Da die einem Projekt zur Verfügung stehenden Ressourcen generell beschränkt sind, ist darauf zu achten, dass zu keinem Zeitpunkt mehr Ressourcen benötigt werden als vorhanden. Ein aufgestellter Aktivitätenzeitplan muss durch einen validen Ressourceneinsatzplan begleitet werden, der zu jeder Aktivität vorschreibt wie viele Einheiten welcher Ressource, wann eingesetzt werden. Im Besonderen kann aber auch die Menge an verbleibenden Ressourcen als Anlass dazu genommen werden, den Plan weiter zu optimieren, z.b. Aktivitäten vorzuziehen um eine gleichmäßigere Arbeitslast zu erzeugen oder Termine besser einhalten zu können. 4.5 Kostenplan Der Kostenplan berücksichtigt die entstehenden Kosten und die (falls vorhandenen) erwarteten Einnahmen auf einer Zeitachse. Hieraus ergeben sich zu bestimmten Zeitpunkten im Projekt Finanzierungsanforderungen. Speziell zu erwähnen ist noch, dass die Einnahmen für gewöhnlich stufenweise erfolgen, d.h. dass selbst bei insgesamt profitablen Projekten zeitweise Durststrecken entstehen in denen das Projekt sich nicht selber trägt (dies ist vor allen Dingen auch ganz zu Anfang der Fall). Posten die Ausgaben verursachen lassen sich zumeist recht zuverlässig vorausbestimmen, typischerweise gehören hierzu: Personalkosten Neuanschaffungen, im Besonderen die technische Ausrüstung in Soft- und Hardware 15

16 Arbeitsmaterialien externe Berater und Subunternehmer Reserven für bestimmte Projektrisiken 5 Projektdurchführung Während der Projektdurchführung stehen nun alle Aktivitäten aus dem zuvor erwähnten Regelkreislauf im Fokus des Projektmanagements. Zum einen muss der bestehende Projektplan gepflegt werden, d.h. er muss kontinuierlich an die sich ändernden Gegebenheiten des Projektes angepasst werden. Zukünftige Meilensteine sollten so bald wie möglich ausdetailliert werden, so dass immer mit Vorausblick gehandelt werden kann. Im Besonderen können Plananpassungen notwendig sein, wenn im Rahmen der Kontrollaktivitäten festgestellt wurde, dass das tatsächliche Projektgeschehen vom Plan abweicht. Im Folgenden werden nun die Kontroll- und Steuerungsaktivität genauer erläutert. 5.1 Kontrolle Der Projektplan legt die Soll-Werte für die Durchführungsphase fest. Die Kontrollaktivität des Projektmanagements besteht nun darin, darauf zu achten ob diese Vorgaben eingehalten werden und im Fall von Diskrepanzen Steuerungsaktivitäten anzustoßen. Zumeist werden hierfür Schwellwerte definiert, so dass nicht schon bei Kleinstabweichungen vom Plan reagiert wird. Hierbei bedient sich das Projektmanagement hauptsächlich bei den Methoden der Fortschrittsüberwachung Fortschrittsüberwachung Zur Überwachung des Fortschritts der einzelnen Arbeitspakete und/oder Aktivitäten, hat das Projektmanagement Berichtsstrukturen geschaffen. Diese können unterschiedlich komplex ausgeprägt sein je nach Projektgröße, allerdings ist generell zu sagen, dass Fortschrittsüberwachung immer auf zwei Ebenen stattfindet. Zum einen gibt es die Aktivitätenebene, auf der die Entwickler ihren Fortschritt an den nächsthöheren Verantwortlichen berichten, zum anderen die Projektebene auf der zusammengefasste Fortschrittsinformationen bis in die Projektleitung und von dort oft noch weiter bis zum Kunden gegeben werden Aktivitätenebene Überwachung auf Aktivitätenebene kann in kleinen Projekten sehr informell stattfinden, indem die einzelnen Entwickler regelmäßig, z.b. in einem Meeting, mündliche Zusammenfassungen geben. Bei größeren Projekten und speziell auch bei solchen, die sich im Kontext eines größeren Unternehmens befinden, wird eine etwas formalere Vorgehensweise zur Berichterstattung verwendet. Gängig ist es, 16

17 dass in regelmäßigen Abständen schriftliche Reports von den Entwicklern an ihre nächsten Vorgesetzten geschickt werden. Folgende Informationen sind oft in Reports enthalten: Bisher entstandener Zeitaufwand Geschätzter Restaufwand und/oder Endtermin Fertigstellungsgrad Ampelbericht Der bisher entstandene Zeitaufwand lässt sich vom Entwickler sehr einfach ermitteln. Anhand des vom Entwickler geschätzten Restaufwand bzw. Endtermins lässt sich oft schon erkennen, ob es Probleme mit der Einhaltung von Terminen geben wird. Der Fertigstellungsgrad beziffert den vom Entwickler geschätzten prozentuellen Grad der Fertigstellung der Aufgabe. Speziell die Verwendung des Fertigstellungsgrads ist oft nicht unproblematisch aufgrund des sog. 90% Syndroms. Dies ist eine Beobachtung, die besagt, dass zu Anfang die Schätzung zur Fertigstellung linear steigt aber gegen Ende der Zuwachs nur noch sublinear ist und im schlechtesten Fall beinahe asymptotisch gegen 100% geht. Dies geschieht vor allen Dingen bei komplexeren Vorhaben, deren Fertigstellungsgrad zu Beginn zu optimistisch eingeschätzt wurde. Ampelberichte sind explizit zur Überwachung von Problemen gedacht. Hier wird auf einer dreistufigen Skala zusammenfassend dargestellt, ob es zum aktuellen Zeitpunkt im Projekt Probleme gibt. Gängig ist es auch Ampelberichte noch nach Kosten, Terminen, Funktionalität und Qualität auszudifferenzieren um die Aussagekraft zu erhöhen. Ampelberichte können nicht nur auf der Aktivitätenebene eingesetzt werden. Da sie sehr komplexitätsreduzierend wirken, eignen sie sich auch für die stärker zusammenfassenden Berichte auf Projektebene Projektebene Fortschrittsberichte auf Projektebene müssen vor allem die Informationen der darunterliegenden Ebenen verdichten. In Hinsicht auf eine zusammenfassende Darstellung von Problemen bietet sich auch hier wieder die Ampelmethode an. Um den Projektfortschritt zusammenzufassen haben sich hauptsächlich zwei Methoden etabliert: Meilensteintrendanalyse (MTA): Ein MTA Diagramm betrachtet auf einer Zeitachse die Terminverschiebungen eines Meilensteins. Es ergibt sich eine Kurve, an deren Bergen und Tälern einfach ablesbar ist wie oft und in welchem Umfang der Endtermin eines Meilensteins im Projektverlauf angepasst werden musste. Häufig verschobene Endtermine sind ein Indikator für Probleme innerhalb des Projekts. Earned Value Analysis (EVA): EVA ist eine komplexere Methode, die sich vor allem auf den Vergleich von geplanten und entstandenen Kosten sowie den 17

18 aktuellen Fortschrittsgrad des Projektes konzentriert. Aus der EVA lässt sich ermitteln ob die geplanten Kosten und Termine eingehalten werden. Da hier jedoch eine Schätzung des bereits erwähnten Fortschrittsgrades mit eingeht sind EVA zwar mächtig, aber nicht immer unproblematisch in ihrer Aussage. 5.2 Steuerung Steuerungsaktivitäten werden immer aus gemessenen Soll-Ist Diskrepanzen aus der Kontrolle angestoßen. Hierbei wird der Art des Problems entsprechend reagiert. Es können folgende (nicht überschneidungsfreie) Arten von Problemen unterschieden werden: 1. Terminprobleme: Kann ein Termin nicht eingehalten werden, so kann darauf auf verschiedene Arten und Weisen reagiert werden. Man kann z.b. versuchen mit dem Kunden einen reduzierten Funktionsumfang auszuhandeln oder versuchen durch optimiertes Aktivitätenmanagement mehr Freiräume zu schaffen. Ein gängiger Fehler ist einer solchen Situation zu versuchen das Problem durch mehr Personaleinsatz zu lösen. Es hat sich gezeigt, dass dies lediglich zu einer noch größeren Verspätung führt, da die neuen Mitarbeiter meistens erst eingearbeitet werden müssen. 2. Kostenprobleme: Kostenprobleme hängen größtenteils mit nicht vorhersehbaren Aufwandssteigerungen während der Durchführung zusammen. Auch hier wird sich nur auf Kosten der Funktionalität oder der Qualität das Defizit wieder ausgleichen lassen, solange kein neuer Kostenplan mit dem Kunden verhandelt wird. 3. Funktionalitätsprobleme: Funktionalitätsprobleme sind zumeist auf technische Probleme oder mangelnde Anforderungsanalyse zurückzuführen. Mögliche Lösungsansätze sind z.b. das Hinzuziehen von projektexternen Experten oder das Zukaufen einer Komponente, die die erwünschte Funktionalität bietet. 4. Qualitätsprobleme: Da diese meistens erst im späteren Phasen auftreten bleibt meistens nur verstärktes Testen und Debugging und evtl. der Einsatz von Reviews. 6 Quellen 1: Bernd Hindel, Klaus Hörmann, Markus Müller, Jürgen Schmied, Basiswissen Software-Projektmanagement, : Bob Hughes, Mioke Cotterell, Software Project Management,