Projektmanagement

PROJEKTMANAGEMENT
LV Nr. 706.028 (2VU)
LV Nr. 706.038 (1VU)
GRUNDLAGEN DES
PROJEKTMANAGEMENTS
BLOCK 1-2
Autor:
Andreas Schwarz
Lehrveranstaltungsleiter:
Dipl.-Ing. Dr.techn. Christian Gütl
Grundlagen des Projektmanagements
_________________________________________________________________________________
Inhaltsverzeichnis
1 Motivation : Warum Projektmanagement? .............................................................. 3
2 Das Projekt..................................................................................................................... 3
2.1 Allgemeines............................................................................................................. 3
2.2 Pojektaspekte.......................................................................................................... 3
3 Projektmanagement ....................................................................................................... 5
3.1 Definition ................................................................................................................. 5
3.2 Aspekte ................................................................................................................... 5
3.3 Projektmanagementtools ......................................................................................... 6
4 Das Projektmanagement Team ...................................................................................... 7
4.1 Projektsponsor/ Projektpate .................................................................................... 7
4.2 Die Rolle des Projektmanagers ............................................................................... 8
4.3 Die Rolle des Linienmanagers ................................................................................. 8
4.4 Die Schnittstelle zwischen Projekt –und Linienmanager .......................................... 9
4.5 Projektmitarbeiter (Project Staff).............................................................................. 9
4.6 Gruppenleiter .......................................................................................................... 9
4.7 Programm Manager ................................................................................................ 9
4.8 Stakeholder ............................................................................................................. 9
4.9 Kunden und Endbenutzer .......................................................................................10
4.10 Fachexperten .........................................................................................................10
4.11 Steering board........................................................................................................10
4.12 Subauftragnehmer und Lieferanten ........................................................................10
5 Projekterfolg und seine Einflußfaktoren .........................................................................10
5.1 Die Erfolgsgleichung nach Kapur ...........................................................................11
5.2 Projektmisserfolg ....................................................................................................12
5.3 Die sieben Todsünden des Projektmanagements ..................................................12
5.4 Reifegrad und Exzellenz (Maturity and Excellence) ................................................14
5.5 Vorgehensmodell/ Projektmanagementmethoden ..................................................15
5.6 Projektphasen ........................................................................................................15
5.7 Der Projektprozess /Projektmanagementprozess ...................................................15
6 Unterstützende Methoden des Projektmanagement Prozesses.....................................16
6.1 Begriffsdefinitionen: ................................................................................................16
6.2 Work Breakdown Structure (WBS) aka Projektstrukturplan (PSP): .........................17
6.2.1 Work Breakdown Structure – Erstellung (Top-Down Methode) ........................17
6.3 Task Networks – Netzpläne....................................................................................19
6.3.1 Activitiy-On-Arrow (AOA) –Network .................................................................20
6.3.2 Activity-On-Node (AON)–Network ...................................................................20
6.3.3 Abhängigkeiten und Beziehungen ...................................................................21
6.4 Der kritischer Pfad ..................................................................................................23
6.4.1 Berechnungsmethoden zur Kalkulation des kritischen Pfades.........................24
6.4.2 Free Slack – Zeitpuffer und deren Bestimmung...............................................26
2
Grundlagen des Projektmanagements
_________________________________________________________________________________
1 Motivation : Warum Projektmanagement?
Führungskräfte in der heutigen Wirtschaft werden mit immer komplexeren
Herausforderungen konfrontiert. Kostendruck durch eskalierende Personal – und
Materialkosten, Druck von Aktionären und Gewerkschaften oder Inflation lassen sich nicht
auf Dauer durch Rationalisierungsmaßnahmen (Kostenreduktionsprogramme, Entlassungen)
einschränken, zudem diese wiederum den Unternehmensgewinn ernsthaft gefährden
können.
Die rapide fortschreitenden technologischen Veränderungen und die permanente Änderung
des Marktes üben einen enormen Druck auf bestehende Organisationsformen aus. Die
traditionelle Unternehmensstruktur ist äußerst bürokratisch, und die Erfahrung zeigt, dass
sich Unternehmen mit einer solchen Struktur nicht schnell genug an ein sich änderndes
Umfeld anpassen können.
Es besteht Einigkeit darüber, dass die meisten Probleme eines Unternehmens gelöst werden
können, indem die vorhandenen Ressourcen besser gesteuert und sinnvoller eingesetzt
werden und Probleme zuerst intern im Unternehmen gesucht und gelöst werden, statt extern
nach Lösungen zu suchen. Im Rahmen der Suche nach einer internen Lösung nehmen
Unternehmen die Art und Weise unter die Lupe, wie Aktivitäten behandelt werden.
Deshalb muss die traditionelle Unternehmensstruktur durch eine andere Form von
Management auf Zeit ersetzt werden, die es dem Unternehmen ermöglicht, sich schnell
anzupassen, wenn es die Situation im intern im Unternehmen, oder extern in der Umwelt,
erfordert.
Hier kommt der Projektmanagementansatz zum Tragen. Führungskräfte und Wissenschaftler
sehen Projektmanagement schon lange als eine von mehreren möglichen
Organisationsformen, mit denen sich ein hochkomplexer Arbeitsaufwand bewältigen lässt.
2 Das Projekt
2.1 Allgemeines
Vielen mag es überflüssig erscheinen, den Begriff „Projekt“ hier erneut zu definieren, ist man
doch ständig in beinahe allen Lebenslagen damit konfrontiert. Um Projektmanagement
jedoch sinnvoll und zielführend anwenden zu können, sollte dieser Begriff jedem klar sein.
„A Project is a temporary endeavor to create a unique product or process.“
Ein Projekt ist ein Vorhaben mit folgenden Merkmalen:
 Zeitlich begrenzt, d. h. klar definierter Anfangs und Abschluss.
 Neuartiges Vorhaben
 Zielvorgaben, die unbedingt erfüllt werden muss.
 Beanspruchung von Personal -und Sachressourcen
 Abgrenzung gegenüber anderen Vorhaben.
 Multifunktionale Ausrichtung (Projekt erstreckt sich über mehrere Funktionslinien)
2.2 Pojektaspekte
3
Grundlagen des Projektmanagements
_________________________________________________________________________________
Wie in der Definition bereits angegeben ist ein Projekt ein zeitlich begrenztes Bestreben ein
neuartiges Produkt oder einen Prozess zu erschaffen. Dies führt uns bereits zur ersten und
grundlegendsten Erkenntnis des Projektmanagements:
„Wenn ich keine Zeit dafür habe, darf ich kein Projekt beginnen!“
Doch wann wird die tägliche Arbeit zu einem Projekt? Ein Projekt besteht aus einer Reihe
zusammenhängender Arbeiten, Meilensteine und Tasks. Die Fachliteratur gibt als
ungefähren Schwellenwert 200 Arbeitsstunden an. Ab diesem Zeitpunkt ist es sinnvoller, das
Unternehmen als Projekt mit all seinen Aspekten anzusehen. Sollte die erste Abschätzung
deutlich darunter liegen und sich erst in der Abwicklung der Aufgabe zeigen, dass der
Aufwand weit über dem 200 Stunden Schwellenwert liegt, ist es im allgemeinen sinnvoll, die
Aufgabe als Projekt zu managen.
Wirtschaftlichkeit :
Das Projekt soll wirtschaftlich nutzbar sein. Es soll Lösungen zu vorher eindeutig definierten
Problemstellungen bieten, nicht Techniken entwickeln, um neue Probleme ausfindig zu
machen.
Investitionen und Lebensdauer eines Projekts
Hierbei ist es von größter Bedeutung, dass sich sämtliche Mitarbeiter über den
Zusammenhang der investierten Mittel (Investment) in das Projekt und dem Ertrag des
Projektes (return on investment, ROI) im Klaren sind.
Investment
↔
return on investment
Um die Wirtschaftlichkeit des Projekts zu gewährleisten, dürfen die aufgewandten Mittel für
das Projekt die zu erwartenden Erträge niemals übersteigen. Sollte dies bereits bei der
Planung offensichtlich sein, ist es im Allgemeinen sinnvoller, anderweitig zu investieren.
Erfolgreiche Projekte werden nach einem zuvor definierten Zeitraum abgeschlossen. Wird
dieser Zeitraum überschritten müssen zusätzliche Investitionen getätigt werden was
wiederum den erwarteten Ertrag verringert.
Wer ist der Boss?
Bevor das Projekt an den Start gehen kann muss eine klare hierarchische Struktur
geschaffen werden. Der Hauptverantwortliche (the owner), in der Regel der Projektsponsor,
begleitet das Projekt von Anfang an. Dieser Owner ist idealerweise immer mit einer Person
assoziiert, niemals mit einer Abteilung oder einem Komitee.
Veränderung im Status Quo
Das Ergebnis eines Projekts ist ein neuer, verbesserter oder angepasster Prozess bzw.
Produkt, keine Kopie bereits existierender Produkte oder Prozesse.
Projektplan
Das Projektteam muss einen Projektplan erstellen, der sämtliche Phasen des Projekts
enthält. Mit dem Projektplan beschreibt das Projektteam auch bestimmte Voraussetzungen,
wie zum Beispiel, den Kostenvoranschlag, die Dauer des Projekts sowie das Endprodukt.
Der Projektplan beschreibt also den Ablauf des gesamten Projekts unter idealen
Voraussetzungen. Doch selbst unter den besten Voraussetzungen sind meistens einiger der
getroffenen Annahmen nicht einzuhalten. Hierbei spielt die Flexibilität sowohl der
Projektmitarbeiter als auch die der Projektkunden eine tragende Rolle.
Der Störfaktor Projekt
Ein Projekt stellt nicht nur eine ungeheure Belastung für seine Mitarbeiter dar, sondern bietet
auch eine Herausforderung für den Projektkunden. Dieser ist in etliche Abläufe und Prozesse
involviert und somit fixer Bestandteil des Teams. Folgende Tätigkeiten zählen zu seinen
Hauptaufgaben:
4
Grundlagen des Projektmanagements
_________________________________________________________________________________




Anforderungen/ Ziele müssen definiert werden
Designentscheidungen mittragen
Produkt testen
Optional: (Schulungen im Umgang mit dem neuen Produkt)
Dies stellt für die Mitarbeiter des Projektkunden eine Doppelbelastung dar, da dieser zu
seinem normalen Arbeitspflichten in der Firma diese Aufgaben oftmals zusätzlich erfüllen
soll.
Es lässt sich recht einfach erkennen dass vieles an einem Projekt nicht mehr einem üblichen
Arbeitsablauf
entsprechen. Viele Aspekte benötigen ausgeklügelte Planung, andere
erfordern wiederum gewisse Investitionen – sie alle fließen in den Projektplan mit ein und
tragen zum Erfolg oder Misserfolg des Projekts bei.
3 Projektmanagement
3.1 Definition



„Project Management is the application of knowledge, skills, tools and techniques to
project activities to meet project requirements” (PMI)
“Projektmanagement ist die Gesamtheit von Führungsaufgaben, -organisation, techniken und mitteln für die Abwicklung eines Projektes“ (aus DIN 6991)
„…ist der Prozess, Projekte zu managen.“
Letztendlich kann Projektmanagement für jeden etwas anderes bedeuten. Doch das Konzept
wird häufig missverstanden, weil es im Unternehmen bereits laufende Projekte gibt und die
Mitarbeiter das Gefühl haben, sie würden diese Aktivitäten mittels Projektmanagement
steuern. In einer solchen Situation wäre wohl folgende Definition passend:
„Projektmanagement ist die Kunst, den Eindruck zu erwecken, dass jedes Ergebnis die
Folge von vorherbestimmten, vorsätzlichen Handlungen ist, während es tatsächlich reine
Glückssache war.“
Dies hat jedoch nichts mehr mit Projektmanagement an sich zu tun. Vielmehr soll
Projektmanagement dazu dienen, vorhandene Ressourcen effizienter zu nutzen, indem
gleichzeitig parallele Arbeitsabläufe möglich gemacht werden und der bürokratische
Aufwand so gering wie möglich gehalten wird.
3.2 Aspekte
Projektmanagement umfasst folgende Tätigkeiten:




Definieren
Das Projekt beschreiben und die Erfolgskriterien festlegen.
Planen
Umfassenden Plan des Projektablaufs (Phasen, Tasks, Milestones, Deliverables …)
Aufwandabschätzung und Terminierung
Der Projektmanager muss mit seinem Team genaue und vor allem realistische
Abschätzung bezüglich der Dauer der einzelnen Phasen und Task entwickeln, um so
dem Kunden eine Abschätzung der Kosten zu ermöglichen.
Lenken und Leiten
Der Projektmanager/sponsor ist maßgeblich für den Erfolg des Projekts
5
Grundlagen des Projektmanagements
_________________________________________________________________________________



verantwortlich. Seine Führungsqualitäten und Fähigkeiten leiten helfen dem
Projektteam, auch schwierige Situationen zu meistern.
Überwachen und Kontrollieren
Die Arbeitsschritte der einzelnen Projektmitarbeiter sollten kontrolliert werden, um
einen reibungslosen Projektablauf zu gewährleisten. Auf diese Weise können
Unstimmigkeiten im Ablauf oder Abweichungen vom Projektplan schnell erkannt und
behoben werden. Weiters wird es so um einiges einfacher, eventuell nötige
Korrekturen im Projektplan „on the fly“ durchzuführen.
Kommunikation
Kommunikation ist das um und auf für einen geregelten Projektbetrieb. Der
Projektmanager muss alle Interessensgruppen (Mitarbeiter, Projektkunden etc. )
über den Status des Projekts am Laufenden halten. Änderungen und Abweichungen
vom Zeitplan, Kosten oder Personalstruktur müssen allen Interessensgruppen
bekannt gemacht werden.
Abschluss
Wie bereits in der Definition erwähnt, hat jedes Projekt eine Deadline, einen
Abschluss. Der Projektmanager ist hierbei auch dafür verantwortlich, dass auch
dieser eingehalten wird.
Projektmanagement umfasst also die Planung, Organisation und Steuerung der
Unternehmensressourcen in Hinblick auf ein relativ kurzfristiges Ziel, das aufgestellt
wurde, um bestimmten Endzustand zu erreichen. Ein Projektteam mit seinen
Ressourcen kann als temporäre, eigenständige Organisation gesehen werden.
3.3 Projektmanagementtools
Werkzeuge machen unser Leben leichter. Auch für Projektmanagement gibt es mächtige
Softwaretools, die selbst den Ansprüchen der erfahrensten Manager genügen. In einer
Umfrage bei einer internationalen Projektmanagementkonferenz gaben 85 % der Befragten
an, mehr als ein Projektmanagement-Softwarepackage zu benutzen. Trotzdem passieren
nach wie vor kritische Fehler bei der Umsetzung wie Überschreitung des Budgets oder der
Zeitpläne.
Oftmals schicken Manager ausgewähltes Personal auf Kurse im Umgang mit der
Projektmanagementsoftware, ohne sie vorher im Umgang mit Praktiken und Anwendung von
Projektmanagement zu schulen. Dies führte in vielen Fällen zu Fehlkalkulationen und
enormen monetären Verlusten. Trotzdem sehen viele Manager Projektmanagement nach
wie vor als eine Art taktisches Problem an, welches leicht mit entsprechender Software
gelöst werden kann. Doch richtig ausgeführtes Projektmanagement ist weit mehr als das
simple Anwenden von Softwaretools. Für Unternehmen mit gutdurchdachten und erprobten
Projektmanagementpraktiken stellen Tools mächtige Hilfsmittel und Arbeitserleichterungen
dar.
6
Grundlagen des Projektmanagements
_________________________________________________________________________________
4 Das Projektmanagement Team
In jedem Projekt gibt es verschiedene Rollen, die mit unterschiedlichen Aufgaben – und
Verantwortungsbereichen verbunden sind. Diese „Rollen“ implizieren unterschiedliche
Positionen. Einige davon haben wir bereits in den vorigen Abschnitten kennengelernt. Dieses
Kapitel soll eine Übersicht über die verschiedenen Positionen und den damit Verbundenen
Aufgabenbereichen geben.
Abbildung 4.1 Das Projektteam im Detail
4.1 Projektsponsor/ Projektpate
Eine der wichtigsten im Projektteam auszufüllenden Positionen ist die des Projektsponsors.
Obwohl alle Parteien am Erfolg des Projekts beteiligt sind, kommt dem Projektsponsor eine
besondere Bedeutung zu. Häufig scheitern Projekte, weil ihnen bereits zu Beginn die
Unterstützung der Unternehmensleitung fehlt, oder im Laufe des Projekts entzogen wird. Je
grösser das Unternehmen, und je mehr Projekte es in demselben gibt, desto kritischer ist
dieser Erfolgsfaktor. Der Projektsponsor repräsentiert die direkte Schnittstelle zur
Unternehmensleitung. Idealerweise ist er Teil dieser, oder zumindest ausdrücklich an diese
Position berufen worden. Im letzten Fall ist eine weitreichende Unterstützung der Leitung
notwendig.
Zudem ist er verantwortlich für:





Sicherstellung der anfangs festgelegten Projekt – und Geschäftsziele
Überwachung des Projektfortschritts gemeinsam mit dem Projektmanager
Prüfung
und Genehmigung von Change Requests hinsichtlich ihrer Kosten,
Ressourcen – und Zeitplanung
Prüfung der Projektkosten in Bezug zum Projektfortschritt
Leitung von Project-Review Meetings
Die Aufgaben des Projektsponsors sind anspruchsvoll und komplex und sollten auf keinen
Fall unterschätzt werden. Ein aktiver Projektsponsor kann die Wahrscheinlichkeit eines
Erfolgs des Projekts deutlich erhöhen.
7
Grundlagen des Projektmanagements
_________________________________________________________________________________
4.2 Die Rolle des Projektmanagers
Der Projektmanager ist verantwortlich für die Koordination und Integration der Aktivitäten
über mehrere Funktionsbereiche hinweg.
Abbildung 4.2 veranschaulicht die
Verantwortlichkeiten des Projektmanagers, der mit vorgegebenen Inputs, in dem Fall
Ressourcen, ein bestimmtes Ergebnis, hier in der Form von Produkten, Dienstleistungen und
Gewinnen, erzielen muss. Der Projektmanager legt fest, welche Arbeiten erledigt werden
müssen sowie sämtliche Projektvorgaben.
Ressourcen:
Input






Kapital
Material
Geräte
Anlagen
Informationen
Personal
Integrierte
Prozesse



Output
Produkte
Dienste
Gewinne
Abbildung 4.2 Integrationsprozesse veranschaulicht
Neben den Führungsqualitäten und dem Fachwissen muss er exzellente kommunikative und
zwischenmenschliche Fähigkeiten aufweisen, um sich mit seinen Mitarbeitern zu arrangieren
und sie zu motivieren. Entgegen allen Vermutungen besitzt der Projektmanager nur sehr
wenig Weisungsbefugnisse. Vielmehr muss er sich mit seinen Vorgesetzten Managern und
dem Linienmanager über die Verteilung der benötigten Ressourcen organisieren.
Seine Tätigkeit wird häufig auch als Schnittstellenmanagement bezeichnet, da er sich
zudem noch um folgende Beziehungen kümmern muss:




Innerhalb des Projektteams
Zwischen Projektteam und Linienorganisation
Zwischen Projektteam und Unternehmensführung
Zwischen Projektteam und dem Kunden
Der Projektmanager lernt aufgrund seiner Aufgaben viele Arbeitsabläufe im gesamten
Unternehmen kennen. Aus diesem Grund werden oft Führungskräfte, die für Top-Positionen
vorgesehen sind, zunächst als Projektmanager eingesetzt.
4.3 Die Rolle des Linienmanagers
Der Linienmanager muss festlegen, wie und wo die Aufgaben, die der Projektmanager
beschrieben hat, ausgeführt werden sollen. Er ist hauptverantwortlich für die
Ressourcenbereitstellung, damit das Ziel im Rahmen der Projektvorgaben erreicht werden
kann. Zudem ist er für die durchzuführenden Arbeiten verantwortlich. Hat der Linienmanager
8
Grundlagen des Projektmanagements
_________________________________________________________________________________
das Gefühl, dass bestimmte technische Anforderungen des Projektmanagers nicht erfüllt
werden können, so hat er aufgrund seiner Erfahrung und Position das Recht, dies zu
beanstanden und notwendige Schritte einzuleiten, diesen Missstand zu beheben.
Abgesehen vom Projektbudget kontrolliert der Linienmanager sämtliche Ressourcen:





Personal
Sachmittel
Produktionsanlagen
Material
Information/ Technologie
4.4 Die Schnittstelle zwischen Projekt – und Linienmanager
Wie schon bereits erwähnt kontrolliert der Projektmanager bis auf die Finanzmittel
(Projektbudget) keine anderen Ressourcen. Ressourcen werden von den operativen
Managern, Linienmanagern verwaltet. Projektmanager müssen sich an diese Linienmanager
wenden, wenn sie zusätzliche Mittel für ihr Projekt akquirieren möchten. Es ist offensichtlich,
dass eine gute Beziehung zwischen Projekt –und Linienmanager eine Grundvoraussetzung
für einen reibungslosen und erfolgreichen Projektabschluss ist.
4.5 Projektmitarbeiter (Project Staff)
Projektmitarbeiter sind Personen, die über die ganze Projektdauer oder vorübergehend dem
Projekt zugeordnet werden. berichten im Normalfall direkt an ihren Linienmanager. Zu ihren
Hauptaufgaben gehört:
 Ihre Arbeitspakete gemäß den Projektvorgaben fertigzustellen
 Ihren Vorgesetzten regelmäßig über ihren Fortschritt Bericht zu erstatten
 Probleme umgehend ans Licht zu bringen
 Informationen an das Projektteam weiterzugeben
4.6 Gruppenleiter
Oftmals empfiehlt es sich bei großen Projekten mit vielen Teammitgliedern Gruppenleiter
einzuführen um Kommunikationswege zu verkürzen und die Arbeitseffizienz zu steigern.
Meist wird einem Gruppenleiter ein Teilaspekt des Projekts übertragen, zusammen mit einer
Reihe von Projektmitarbeitern. Als Gruppenleiter übernimmt er nun zusätzlich zu seinen
Arbeiten im vorgegebenen Teilbereich gewisse Managementaufgaben, für den er nun
verantwortlich. Oftmals ist es erforderlich, dass sich der Gruppenleiter nur mehr rein auf die
Management –und Kontrollaufgaben seines Teilbereichs konzentriert.
4.7 Programm Manager
Ein Programm bezeichnet in Begriffen des Projektmanagements eine Gruppe von
verschiedenen Projekten, die in direktem (auch zeitlichem) Zusammenhang
zueinanderstehen. Ein einfaches Beispiel dazu wäre die Herstellung eines Autos: Um das
Endprodukt, ein Auto, zu erreichen, ist das Zusammenspiel von unzähligen kleineren
Projekten notwendig, die auch in der Zeitebene voneinander abhängen.
Der Programm Manager koordiniert und verwaltet diese Unterprojekte im Programm, er ist
derjenige der das Gesamtbild des Programms ständig vor Augen hat.
4.8 Stakeholder
Stakeholder sind alle Personen, die direkt oder indirekt ein Interesse am Projekt haben, oder
vom Projekt betroffen sind. Der Begriff stammt noch aus der Zeit der Kolonisierung
Amerikas, als das Land unter den Siedlern aufgeteilt wurde. Ein Stück Land wurde mit
sogenannten „Stakes“ - Holzpflöcken, vom Besitzer, dem „Stakeholder“ abgegrenzt.
Man
unterscheidet
zwischen
internen
und
externen
Stakeholdern:
Interne Stakeholder sind direkt im Projekt involviert (bspw. Teammitglieder) oder vom Projekt
9
Grundlagen des Projektmanagements
_________________________________________________________________________________
betroffen (bspw. Kunden). Externe Stakeholder sind Personen oder Interessensgruppen, die
von den Auswirkungen des Projekts unmittelbar betroffen sind.
4.9 Kunden und Endbenutzer
Auch der Customer /Kunde zählt zum Projektmanagement Team. Als Auftraggeber und
meistens auch Endbenutzer. Bei großen Projekten stellt der Kunde oftmals eigens Leute zur
Verfügung, die in das PM-Team integriert werden und so den direkten Link zum
Auftraggeber herstellen.
4.10 Fachexperten
Fachexperten sind wie der Name schon sagt, Experten wenn es um die Lösung eines
gewissen Teilaspekts im Projekt geht. Sie werden dem Team temporär zugeteilt um
Probleme in den Griff zu bekommen, die den termingerechten Abschluss des Projekts
gefährden könnten oder wenn bestimmtes Fachwissen benötigt wird. Sobald ihre Aufgabe
gelöst ist, werden sie wieder abgezogen. Fachexperten können intern aus dem
Firmenbetrieb zugeteilt werden, oder, was keineswegs unüblich ist, von außerhalb.
4.11 Steering board
Für komplexe und aufwendige Projekte wird gelegentlich ein sogenanntes Steering Board
oder Steering Comitee eingesetzt. Dieses Steering Board setzt sich aus einer Gruppe von
versierten Seniormanagern sowie Experten aus verschiedenen Funktionsbereichen
zusammen, die den Verantwortlichen des Projekts mit Rat und Tat zur Seite stehen. Die
Befugnisse dieses Boards sind unterschiedlich. Oftmals wird dieser Gruppe nur eine
untergeordnete, beratende Funktion zugestanden, jedoch sind in manchen Fällen,
Ratschläge des Steering Boards für die leitenden Manager bindend und richtungsweisend.
4.12 Subauftragnehmer und Lieferanten
Subauftragnehmer werden eingesetzt, wenn es aus zeitlichen oder wirtschaftlichen Gründen
günstiger erscheint, gewisse Dienstleistungen und Aufgaben an externe Firmen
weiterzuleiten. (Outsourcing!).
5 Projekterfolg und seine Einflussfaktoren
Ze
it
n
ste
Ko
Um
fan
g
Ressourcen
tät
ali
Qu
Um als erfolgreich eingestuft zu werden, muss ein Projekt wie
folgt durchgeführt werden:
 Innerhalb des vorgesehenen Zeitrahmens
 Im Rahmen der geplanten Kosten
 Im gewünschten Umfang und Qualität
 Zur Zufriedenheit des Kunden
 Mit minimaler oder mit dem Auftraggeber abgestimmter
Veränderung des Projektzieles
 Ohne den Hauptarbeitsablauf des Unternehmens zu
beeinträchtigen
 Ohne die Unternehmenskultur zu verändern
Gute
Kundenbeziehungen
Abbildung 5.1 Zusammenhang zwischen Ressourcen und den
Haupteinflussfaktoren Zeit, Kosten, Qualität, Umfang sowie deren
Abhängigkeiten
10
Grundlagen des Projektmanagements
_________________________________________________________________________________
Nur sehr wenige Projekte werden innerhalb des ursprünglichen Projektrahmens abgewickelt.
Veränderungen der Rahmenbedingungen sind oftmals unvermeidlich, und können sich nicht
nur auf die Moral und den Arbeitsablauf der Mitarbeiter auswirken, sondern das gesamte
Projekt gefährden. Daher sollten sie minimal gehalten und unbedingt mit dem
Projektmanager und dem Kunden genau abgesprochen werden.
Der Arbeitsablauf selbst im Unternehmen sollte durch ein laufendes Projekt nicht gestört
werden. Viele Projektmanager betrachten sich nach Projektbeginn als eigenständiges
Unternehmen und würden sich gern von der Mutterorganisation abkoppeln. Dies ist nicht
immer möglich, daher sollte der Projektmanager sein Projekt innerhalb der Richtlinien und
Vorgaben der Mutterorganisation durchführen.
Alle Unternehmen besitzen eine Unternehmenskultur, und auch wenn das Projekt an sich
ein kleines selbstständiges Unternehmen ist, sollte diese Kultur auch im Projekt erhalten
bleiben. Wenn beispielsweise eine Firma stets offen und ehrlich mit seinen Kunden
umzugehen pflegt, so sollte dies auch im Projekt als Direktive gelten.
5.1 Die Erfolgsgleichung nach Kapur
Gopal K. Kapur ist der Gründer und Vorsitzende des „Center for Projectmanagement“. Seit
1975 entwickelt er innovative Projektmanagementstrategien, die wegweisend für die
Entwicklung des Projektmanagements sind.
Seiner Meinung nach, setzt sich der Projekterfolg aus einer recht simplen Gleichung
zusammen:
Success = {[(Process + Skills + Techniques + Tools) × Accountability ] × Discipline}
Success (Erfolg): Beschreibt den gewünschten oder auch ein zufriedenstellendes Ergebnis.
Process (Methode): Beschreibt die Art und Weise wie das Projekt gehandhabt wird.
Typischerweise eine Aneinanderreihung von verschiedenen Schritten, die im Endprodukt
schließen.
Skills (Fähigkeiten): Jede Unternehmung und jede Aufgabe setzt gewisse Fähigkeiten
voraus, um sie erfolgreich auszuführen. Bei einem Projektmanager sind das beispielsweise
Fachwissen, Kommunikation, Organisation oder die Art und Weise, sein Team zu motivieren
– um nur einige zu nennen.
Man unterteilt hierbei in 2 große Gruppen – Softskills und Hardskills. Ein Projektmanager
muss aus beiden Gruppen schöpfen, um wirklich erfolgreich zu sein.
Techniques: Die „Variable“ Techniques beschreibt im Grunde die Geschicklichkeit und die
Erfahrung mit der die oben erwähnten Soft –und Hardskills eingesetzt werden. Ein
Projektmanager beispielsweise, der schon in dutzenden Projekten mitgearbeitet hat wird
gewisse grundlegende Tätigkeiten (wie zum Beispiel die Erstellung verschiedener
Projektpläne) nahezu schon im Schlaf beherrschen, während ein frisch beförderter PM sicher
mit einem ordentlichen Maß an Respekt und eventuell auch Unsicherheit an die Sache
herangeht.
Tools (Werkzeuge): Wie schon zuvor erwähnt, können Tools verschiedene Vorgänge im
Projektmanagement automatisieren und dadurch enorm beschleunigen. Für einen
erfolgreichen Einsatz ist es jedoch unumgänglich, dass
Projektmitglieder
alle
grundlegenden Praktiken beherrschen. Tools sind nicht in der Lage, nichtvorhandenes
Wissen zu kompensieren oder ein Projekt im Alleingang fertigzustellen. Ungeschulten
Personen riesige PM-Softwarepakete in die Hand zu drücken endet im Normalfall mit einem
fehlgeschlagenen Projekt und hohen monetären Verlusten.
Accountability (Zuverlässigkeit): Accountability ist in der Kapur’schen Gleichung als
Faktor dargestellt und soll seine Bedeutung unterstreichen. Im Team muss sich jeder auf den
11
Grundlagen des Projektmanagements
_________________________________________________________________________________
anderen verlassen können. Von Teammitgliedern wird etwa selbstständiges Arbeiten in
ihrem Bereich gefordert, aber auch unverzügliche Meldungen, wenn unvorhergesehene
Probleme oder Fehler auftreten. Dies ist insbesondere nicht nur für den weiteren Verlauf des
Projekts wichtig, es soll auch sogenanntes „finger-pointing“ vermeiden. (Als Finger-pointing
wird der Versuch, Fehler von der eigenen Verantwortung auf andere abzuschieben
bezeichnet.)
Discipline: Der zweite Faktor, und zugleich der wahrscheinlich bedeutendste, ist Disziplin.
Jedes Projektmitglied ist für die Disziplin mitverantwortlich. Selbstkontrolle, Effizienz und
Ordnung sind Grundpfeiler für Vertrauen und Verlässlichkeit im PM-Team.
5.2 Projektmisserfolg
Trotzdem, oder aufgrund dieser Erfordernisse werden überraschend wenige Projekte
erfolgreich abgeschlossen. Abbildung 5.1 zeigt ein Diagramm aus dem sogenannten Chaos
Report der Standish Group. Aus dem aktuellen Report, der erst veröffentlicht wird, geht
hervor, dass ca. 35% aller im Jahr 2006 gestarteten Projekte erfolgreich abgeschlossen
werden konnten. 19% der Projekte scheiterten an der Umsetzung und nur mehr 46%
sprengten Zeit –und Kostenumfang.
5.2 Chaos Report 2004, Standish Group
5.3 Die sieben Todsünden des Projektmanagements
Diese sogenannten 7 Todsünden resultieren aus einer weiteren Studie Kapurs „Center of
Projectmanagement“ welche bereits 1997 startete und seitdem kontinuierlich weitergeführt
wurde. Sie beschreibt jene Fehler, die statistisch gesehen den meisten gescheiterten
Projekten zum Verhängnis wurde.
1.) Unausgereifte Ideen werden zu Projekten
Unternehmensleiter stehen konstant unter dem Druck, neue, innovative Ideen, die in
profitable Endprodukte umgewandelt werden können, hervorzubringen. Diese sollen
12
Grundlagen des Projektmanagements
_________________________________________________________________________________
wiederum dem Unternehmen einen Vorsprung gegenüber der Konkurrenz schaffen
und den eigenen Profit sichern.
Die Problematik dahinter ist, dass viele dieser „Innovationen“ nicht zu Ende gedacht
wurden, dass sie vielmehr in einer Vision oder Träumereien enden, die nicht
verwirklicht werden können.
Dass solche Theorien überhaupt zu Projekten werden, die in den meisten Fällen
direkt in eine Katastrophe steuern liegt zum einen an mangelnder Kommunikation
zwischen dem Management und den Projektteams und zum anderen an kaum oder
nicht vorhandenen Kontrollmechanismen, die solide Projektideen aus dem
„Innovationspool“ filtern. (Bspw. Gremien, Expertengruppen oder ähnliches)
2.) Unrealistische Terminvorgaben
Wie schon aus dem Diagramm des Chaos Reports der Standish Group ersichtlich,
spielt der Zeitfaktor für Projekterfolg oder Misserfolg eine maßgebliche Rolle. Viele
Projekte fallen hoffungslos hinter den vorgegebenen Zeitplan zurück. Einer der
Hauptgründe für dieses immer wieder auftretende Problem ist, dass die eigene
Unternehmensleitung sehr enge Zeitpläne vorgibt, da
 das Management es dem Projektteam nicht zutraut, eine realistische
Zeitabschätzung zu entwickeln.
 das Management sein Projektteam durch zusätzlichen Druck antreiben will.
 Kundenvorgabe
Vielfach setzt der Projektmanager bewusst unrealistische Terminvorgaben, um den
Aufwand scheinbar gering zu halten, um so leichter zu einer Genehmigung für das
Projekt zu kommen.
3.) Ineffektives Sponsorship
Ohne einen effektiven und kompetenten Projeksponsor/pate sinken die
Erfolgschancen für das Projekt dramatisch. Der Sponsor ist mit seinen Befugnissen
ausschlaggebend für den Erfolg. Als kompetenter Pate




versteht er die Komplexität des Projekts.
motiviert er den Projektmanager und sein Team.
unterstützt er das Team mit seinem Wissen.
kontrolliert er den Fortgang des Projekts (basierend auf Meilensteinen).
Dies erfordert von ihm ein hohes Maß an zeitlichem Aufwand, Engagement und
Opferbereitschaft.
4.) Unqualifizierte Projektmanager
Ein weiteres großes Problem stellen unqualifizierte Projektmanager dar. Studien des
„Center for Projectmanagement“ belegen, dass hier noch enormer Aufholbedarf
besteht. Nur wenige Firmen bieten ihren zukünftigen wie auch bereits etablierten
Projektmanagern Weiterbildungskurse oder Training an.
Es wird eher versucht, mangelnde Soft –und Hardskills mit überdimensionierten
Projektmanagementtools zu kompensieren, anstatt den PMs fundierte Ausbildung
oder Mentoring (Senior PM supervises Rookie) zukommen zu lassen.
5.) Monitoring der “Lebenszeichen” des Projekts
Vital Signs, oder „Lebenzeichen“ eines Projekts sind eine Reihe von Indikatoren die
richtig angewandt, anzeigen sollen, ob das Projekt fristgerecht auf dem richtigen Kurs
ist. So wird etwa der zeitkritische Pfad überwacht, das Verhältnis von verbrauchten
13
Grundlagen des Projektmanagements
_________________________________________________________________________________
Ressourcen zu den geschätzten, Sponsorship, Meilensteine, oder die Projektkosten
im Verhältnis zur bisherigen Laufzeit des Projekts.
Werden solche Indikatoren nicht überwacht, gibt es prinzipiell keine Möglichkeit den
Status eines Projekts abzufragen, ohne sich wirklich eingehend mit dem Projekt zu
beschäftigen. (Im weiteren Verlauf des Skriptums wird die Critical Path Method
(Kritischer Pfad Methode) noch genauer beschrieben.)
6.) Schlecht entwickelte Projektmanagementmethoden
Projektmanagementmethoden sind standardisierte Vorgehensweisen, die dem
Projektmanager helfen sollen, das Projekt möglichst effektiv und effizient
umzusetzen. Eine gute Methode definiert sich durch
 Einfache Skalierbarkeit
(anwendbar auf verschiedene Projekte mit unterschiedlicher Größe und
Komplexität)
 Verständlich und Durchschaubar
(Jeder Projektmitarbeiter soll das Konzept dahinter verstehen; Seine Aufgab
en sollen für ihn klar ersichtlich sein.)
7.) Fehlende Darstellung von Projektportfolios
Als Projektportfolio Management bezeichnet man das Verfahren, wie Projekte
innerhalb eines Unternehmens initiiert, genehmigt, gemanagt und durchgeführt
werden. Unglücklicherweise wird Ppm in den meisten Firmen kaum bis nicht
angewandt, sodass es vielfach zu unnötigen Verzögerungen, Doppelgleisigkeit und
internen Konflikten kommt.
5.4 Reifegrad und Exzellenz (Maturity and Excellence)
Der Reifegrad im Projektmanagement gibt an, inwieweit das Unternehmen gewisse
Standardmethoden
und
Begleitprozesse eingeführt hat, die
eine hohe Wahrscheinlichkeit für
wiederholten Erfolg bietet.
Ein hoher Reifegrad beinhaltet, dass
das Unternehmen die passenden
Grundlagen
an
Werkzeugen,
Techniken, Verfahren und geschulten
Mitarbeitern
sowie
die
dafür
notwendige
Unternehmenskultur
vorhanden ist.
Wenn ein Projekt vor dem Abschluss
5.3 Reifegrad und Exzellenz
steht, findet in der Regel eine
Besprechung
mit
dem
oberen
Management statt, die dazu dient, den Reifegrad des Unternehmens zu optimieren. Dabei
werden die angewandten Methoden, Änderungen im Ablauf, sowie die wichtigsten
Leistungsindikatoren betrachtet. Zudem bietet sich auch die Möglichkeit, positive Faktoren
hervorzuheben, welche dann bei zukünftigen Projekten perfektioniert werden können.
Exzellenz im Projektmanagement wird dann erreicht, wenn das Unternehmen ein Umfeld
geschaffen hat, in dem ein kontinuierlicher Strom an erfolgreich durchgeführten Projekten zu
verzeichnen ist. Exzellenz bedeutet nicht einen 100%igen Ausstoß von erfolgreichen
Projekten. Es ist unrealistisch zu glauben, dass alle Projekte erfolgreich abgeschlossen
werden können. Vielmehr gilt es zu bedenken:
Unternehmen, bei denen alle Projekte erfolgreich abgeschlossen werden, gehen nicht
genügend Risiken ein und bearbeiten zu wenig Projekte. Offensichtlich liegen hier
ungenützte Kapazitäten brach.
14
Grundlagen des Projektmanagements
_________________________________________________________________________________
5.5 Vorgehensmodell/ Projektmanagementmethoden
Ein Vorgehensmodell stellt Methoden und Elemente des Projektmanagements zu Prozessen
und Phasen eines standardisierten Projektablaufes zusammen. Die Wahl des
Vorgehensmodells bestimmt sich hauptsächlich durch die Art des Projekts, durch die
Vorgabe des Unternehmens (siehe Unternehmenskultur!) oder des Auftraggebers.
Abbildung 5.4 zeigt das
bundesdeutsche
Vorgehensmodell
der
öffentlichen
Hand
für
Softwareprojekte. Es handelt
sich hierbei um ein in Phasen
gegliedertes Modell, bei dem
nach
jeder
Phase
ein
iterativer
Schritt
zur
Überarbeitung
der
vorangegangen
Phase
eingebaut ist. Nach der
Implementierungsphase
folgen eine Reihe von
Testphasen, die jede für sich
Abbildung 5.4 V-Modell
erfolgreich
durchlaufen
werden müssen, um in die nächste Testphase „aufzusteigen“. Wird eine Testphase nicht
bestanden, müssen vorangegangene Phasen erneut durchlaufen werden, um etwaige
Konzeptionsfehler und Bugs auszumerzen.
5.6 Projektphasen
Eine Projektphase ist ein zeitlicher Abschnitt eines Projektverlaufs, der sachlich gegenüber
anderen Abschnitten getrennt ist (Def. Nach DIN 69901). Zum Abschluss einer Phase wird
üblicherweise ein Meilenstein gesetzt und über den weiteren Fortgang des Projekts
entschieden. Typischerweise kann jedes Projekt mindestens in die 4 formellen Phasen
1.
2.
3.
4.
Definition (Filterung, Analyse)
Planung(Projektplanung, Zeitmanagement etc.)
Durchführung (Projektumsetzung bis hin zum fertigen Produkt)
Abschluss(Beendigung, Abschlussbesprechung, Reviews…)
unterteilt werden.
5.7 Der Projektprozess bzw. Projektmanagementprozess
Der Sinn des Projektmanagements besteht darin, ein Projekt zu planen, abzuwickeln und zu
überwachen. Dabei muss zwischen Projektprozess und Projektmanagementprozess klar
unterschieden werden.
Der Projektprozess definiert sich als „Prozess, der unmittelbar die Erzielung von
Projektergebnissen bewirkt“ (aus DIN 69904). Da jedem Prozess ein Ergebnis folgt, wäre
das in Kapitel 5.5 kurz beschriebene Wasserfallmodell ein gutes Beispiel für einen
Projektprozess.
15
Grundlagen des Projektmanagements
_________________________________________________________________________________
Der Projektmanagementprozess hingegen übernimmt eine klar übergeordnete
Projektführungsposition. Im Vordergrund hierbei stehen die Projektplanung, die
Projektmanagementausführung sowie die Projektüberwachung. DIN 69904 beschreibt den
Projektmanagementprozess als „Prozess zur Überwachung und Steuerung von
Projektprozessen“.
Das PMI – „Project Management Institute“ – eine internationale, non Profit Organisation
organisiert diese Aktivitäten in fünf unterschiedliche Prozessgruppen:





Initiierende Prozesse (Initiating Processes):
Hier wird wiederum zwischen zwei Kategorien unterschieden. In der Idea
Stage werden Projektideen –und visionen gesammelt, und sofort auf den
Grad der Ausgereiftheit hin untersucht und gefiltert. In der Prelaunch state
werden brauchbare Ideen nochmal mit größter Sorgfalt überprüft und in einer
umfangreichen Charter zusammengefasst.
Planungsaufgaben (Planning Processes):
Diese Gruppe beinhaltet sämtliche Prozesse, die zur Entwicklung und
erfolgreichen Ausführung des Projekts nötig sind. Dazu gehören Projektziel,
Aufwands –und Kostenabschätzungen, verschiedene Deliverables (in diesem
Fall: Zwischenergebnisse) oder auch Zeitpläne für die Entwicklung.
Ausführung (Executing Processes):
Sämtliche Prozesse, die mit Ressourcenkoordination (Personen –und
Sachmittel) angewandt werden, finden sich in dieser Kategorie.
Kontrolle und Überwachung (Controlling Processes):
Diese Kategorie umfasst Kontrollmethoden, die den ordnungsgemäßen Ablauf
gewährleisten sollen, als auch sogenannte Recovery Processes, die
angewandt werden, falls es im Projekt etwas schief gehen sollte.
Abschluss (Closing Processes):
Hier werden alle Prozesse, die für einen ordnungsgemäßen Abschluss des
Projekts notwendig sind, zusammengefasst. Größtenteils handelt es sich
dabei um administrative Aufgaben wie zum Beispiel das Sichern/Archivieren
aller projektrelevanten Daten, die Auflösung des Projektteams oder die
formelle Übergabe des Projekts bzw. Produkts an den Kunden.
6 Unterstützende Methoden des Projektmanagement Prozesses
6.1 Begriffsdefinitionen:
Task (Aufgabe)
Ein Task ist die kleinste Arbeitseinheit innerhalb eines Arbeitspaketes und wird
normalerweise von einer einzelnen Person ausgeführt. Der Arbeitsaufwand sollte 40
Stunden nicht überschreiten (was in etwa einer Arbeitswoche entspricht).
Deliverable(Liefergegenstand, Ergebnis)
Als Deliverable bezeichnet man im Projektmanagement das Ergebnis eines Tasks oder einer
Gruppe von Tasks und ist somit ein Maßstab für gewisse Zwischenziele im Projekt. Obwohl
möglicherweise mehrere Personen an solchen Deliverables arbeiten, sollte nur eine Person
hauptverantwortlich dafür sein. Es ist zu empfehlen, den Umfang eines Deliverables so zu
gestalten, dass der zeitliche Aufwand dafür unter 20 Tagen liegt. Andernfalls sollte es in
kleinere Deliverables oder zerlegt werden oder auf eigene Meilensteine hin zu gehen. Bei
den Deliverables unterscheidet man zwischen:
16
Grundlagen des Projektmanagements
_________________________________________________________________________________


Product Deliverables: Sie sind Teil des Endprodukts. Sie sind fix implementiert
und stehen dem Kunden zur Verfügung.
Process Deliverables: Sie verhelfen dem Projekt zu einem erfolgreichen
Abschluss. (Projekt Charter, Risikoanalysen, Statusberichte etc.)
Event (Ereignis)
Ein Event im Projektmanagement definiert einen bestimmten Zeitpunkt zu dem irgendein
Ereignis passiert. Events sind zeitraumunabhängig und haben keine explizite Dauer.
Beispiele für ein Event wären etwa der Start oder das Ende von bestimmten Tasks.
Issue (ungeklärte Punkte)
Unter einem Issue versteht man noch offene Fragen, die noch geklärt werden müssen.
Issues resultieren aus verschiedenen Dingen: fachlichen Meinungsverschiedenheiten, die
noch ausdiskutiert und geklärt werden müssen oder vielleicht Ungewissheit in Bezug auf
Zulieferer oder Outsourcing. Prinzipiell gilt: Je mehr davon in einem Projekt auftauchen und
nicht gelöst werden, desto schwieriger wird ein „runder“ Projektverlauf.
Milestone bzw. Meilenstein
Milestones repräsentieren Ereignisse besonderer Bedeutung, etwa den Abschluss einer
bestimmten Phase eines Projekts oder eines bedeutenden Deliverables. Meilensteine sind
gute Zeitpunkte, um den Gesamtfortschritt in Abhängigkeit mit Zeit und Kostenfaktoren
abzuschätzen und zu beurteilen.
6.2 Work Breakdown Structure (WBS) bzw. Projektstrukturplan (PSP)
Nachdem nun alle tragenden Elemente eines Projekts bekannt sind, gilt es, diese auf ein
Projekt anzuwenden. Die beste Methode liegt in der Erstellung eines Projektstrukturplans
(PSP), auch Work Breakdown Structure (WBS) genannt. Der PSP ist eine Methode zur
schrittweisen Unterteilung eines Projekts in verschiedene kleinere „Brocken“: Meilensteine,
Deliverables, Tasks etc. Prinzipiell ist es egal, ob man diesen Prozess im Top-Down Modus
(Hierarchisch betrachtet) oder im bottom–up Prinzip entwirft.
In der Praxis hat sich gezeigt, dass moderne PM-Software dafür eher hinderlich als hilfreich
ist, denn im Normalfall wird der PSP vom Projektteam gemeinsam erstellt und so kommen
Flipcharts und Post-Its anstatt PDAs und Notebooks zum Einsatz. Der Vorteil davon liegt
darin dass
 sich alle Teammitglieder aktiv in den Entstehungsprozess einbringen können.
 einzelne Elemente relativ einfach um positioniert oder unnötige entfernt werden
können.
 sich die Teammitglieder zusammen ein großes „Bild“ des Projekts machen und so zu
Diskussionen angeregt werden.
6.2.1 Work Breakdown Structure – Erstellung (hier Top-Down Methode)
Um einen Projektstrukturplan anhand eines Beispiels zu verdeutlichen, erfinden wir ein
Trainingsprogramm zur Ausbildung von Fachkräften im Verkaufsbereich.
Die einfachste Möglichkeit zur Darstellung besteht in der Erstellung einer Baumstruktur. Der
erste Schritt zur Erstellung eines Projektstrukturplans besteht in der Definition der einzelnen
Projektphasen.
Für unser Trainingsprogramm gliedern wir das Projekt in die Phasen
 Analyse (Was wird benötigt?)
 Design (Wie?)
 Programmentwicklung (Unterlagenerstellung…)
 Testlauf
17
Grundlagen des Projektmanagements
_________________________________________________________________________________
 Evaluierung (Werden die Ziele erreicht?)
Anhand einer detaillierten Darstellung der ersten beiden Phasen soll das Konzept des PSP
verdeutlicht werden:
Trainingsprogramm
Analysen
Design
Programmentwicklung
Testlauf
Evaluierung
Im nächsten Schritt werden die jeweiligen Deliverables für die einzelnen Phasen definiert,
die abgeschlossen werden müssen um die betreffende Phase abzuschließen. Eventuell
auftretende Fragen, Unklarheiten und Probleme werden ebenfalls auf separate „Kärtchen“
notiert und zur weiteren Bearbeitung festgehalten (Issues!). Zu diesem Zeitpunkt im PSP ist
es noch nicht notwendig, sich über die genauen zeitlichen Abläufe der einzelnen
Deliverables Gedanken zu machen, zunächst ist es nur wichtig, sämtliche Deliverables zu
erfassen.
Im Beispiel stellen für Phase 1 (Analysen) Interviewbericht (Interviews mit bereits erfahrenen
Fachkräften und Managern) sowie die Analyse der dieser Interviews die Deliverables dar.
Für Phase 2 (Design) ist das fertige Programmdesign das zu erreichende Deliverable.
Trainingsprogramm
Analysen
InterviewsReport
Design
Analysen
Report
Programmdesign
Im dritten Schritt werden jedem Deliverable die einzelnen Tasks zugeordnet die zu seiner
Erstellung führen. Es ist zu beachten die einzelnen Tasks nicht zu umfangreich zu gestalten,
und stattdessen größere Aufgaben demnach in kleinere aufzuteilen (siehe Beschreibung von
Task, Kap. 6.1 Arbeitsaufwand ca. 40 Stunden).
Danach wird jedem Element eine Identifikationsnummer zugeordnet und Abhängigkeiten der
einzelnen Aufgaben definiert. Diese IDs sagen nach wie vor nichts über die zeitlichen
Abläufe aus, sondern dienen der Identifikation und sollen Zusammenhänge verdeutlichen.
Zudem werden an Tasks und Deliverables, die einen besonderen Einfluss auf das Projekt
haben, Meilensteine zugeordnet. Diese werden mit einer Raute ♦ gekennzeichnet.
18
Grundlagen des Projektmanagements
_________________________________________________________________________________
Trainingsprogramm
Analysen
Interview- 1
Report
Analysen 2
Report
Design
Phasen
Programmdesign 3
Deliverables
Trainingsmethode
auswählen 3
Interviewskript 1
vorbereiten
zusam
Lernobjekte
entwickeln 3
Alle Anforderungen
lt. Analyse
abschließen 2
♦
zusam
Designkonzept
zusam
Seniormanager 1
entwickeln 3
zusam
interviewen
Tasks
Analyse 2
Ergebnisse
zusam
Verkäufer 1
interviewen
zusam
Zusammenfassung
schreiben 1
Zustimmung des
Managements
einholen 3
zusamResultate
Aktuelle
zusammentragen 2
zusam
Designdetails
erneut
zusam
Interviewreport
präsentieren 1
überprüfen 3
♦
♦
zusam
Wird ein Projektstrukturplan konsequent ausgeführt, ergeben sich daraus viele Vorteile.
Einer dieser Vorteile ist beispielsweise, dass das Projektteam erstmals in der Lage ist, eine
realistische Abschätzung über Zeitaufwand und Kosten des Projekts abzugeben. Natürlich
gilt hier die eben oben erwähnte Regel: Je genauer ausgeführt, desto besser. Denn werden
Issues nicht soweit irgendwie nur möglich abgehandelt oder ganze Tasks vergessen, wird es
zunehmend schwieriger, eine genaue Abschätzung durchzuführen.
Ein weiterer Vorteil ist, dass durch die genaue Aufschlüsselung der Tasks, Phasen und
Deliverables es für den Projektmanager einfacher wird, das gesamte Projekt zu coachen und
zu überwachen. Die richtige Aufteilung der Tasks spielt hierfür eine wichtige Rolle. Es gilt, je
umfangreicher die Tasks gestaltet sind, desto schwieriger wird es, diese aus der Perspektive
eines Managers zu überwachen und zu kontrollieren. Analog gilt dies auch für die
Zeitabschätzung.
6.3 Task Networks bzw. Netzpläne
Im Projektstrukturplan wurden nun alle notwendigen Tasks und Aktivitäten beschrieben, die
erledigt werden müssen, um das Projekt abzuschließen. Was jedoch konsequent vermieden
wurde ist, irgendeine Art der zeitlichen Abfolge der einzelnen Aufgaben zu definieren. Um
eine geeignete Abfolge zu etablieren, werden nun sogenannte Task Networks, Netzpläne,
etabliert. In solchen Netzplänen wird unter Berücksichtigung der Abhängigkeiten der
verschiedenen Tasks festgestellt, wie deren genaue zeitliche Abfolge lauten muss, und
inwieweit Task parallel, also gleichzeitig, abgearbeitet werden können.
19
Grundlagen des Projektmanagements
_________________________________________________________________________________
6.3.1 Activitiy-On-Arrow (AOA) –Network
1
1.2 Senior Manager
interviewen
1.1 Interviewskript
vorbereiten
3T
3
2T
2
1.3 Verkäufer
interviewen
5T
5
1.4 Report
schreiben
4T
1.5 Report
präsentieren
6
1T
7
4
Abbildung 6.3.1 Ein AOA Netzwerk
Beim AOA-Netzwerk werden Tasks als Linien oder Pfeile dargestellt, die wiederum mit
verschiedenen Events verbunden werden (dargestellt als Kreise). Typischerweise wird
oberhalb der Linie Task ID oder Task Name angeführt, unterhalb der Linie der Zeit –und
Kostenaufwand. Die Linienlänge ist völlig unbedeutend. Gestrichelte Linien stellen
Zusammenführungen von parallel ausgeführten Tasks oder deren Abhängigkeiten dar. In der
Abbildung 6.1 beispielsweise, die sich auf die erste Phase des PSP unseres fiktiven Projekts
bezieht, können Interviews mit Seniormanagern und Verkäufern parallel abgearbeitet
werden, der Interviewreport aber erst nach der Fertigstellung beider begonnen werden. In
der Praxis allerdings wird nur mehr selten auf AOA Netzwerke zurückgegriffen, da aufgrund
dieser Hilfslinien bei komplexen Projekten recht schnell die Übersichtlichkeit verloren geht.
6.3.2 Activity-On-Node (AON)–Network
Beim AON-Network werden die Tasks nicht mehr als Linien repräsentiert, sondern als
Knoten. Sämtliche Information über den Task, wie z.B. ID, Name, Aufwand und Dauer
werden innerhalb des Knotens dargestellt. Linien repräsentieren die jeweiligen
Abhängigkeiten unter den verschiedenen Tasks. Zur Verdeutlichung dieser Methode soll das
Beispiel in Abbildung 6.3.2 dienen:
Bestelle
Hardware
1Tag
Start
Erhalte Budget
Genehmigung
1Tag
Installiere
Hardware
3 Tage
Erstelle
Kandidatenliste
5Tage
Befrage
Kandidaten
7 Tage
Veranstalte
Training
4 Tage
Ende
17 Tage
Abbildung 6.3.2 Ein Activity-On-Network
Beim oben beschriebenen Vorgang handelt es sich um einen Prozess zur Anschaffung
neuer Hardware(welcher Art auch immer) für ein Unternehmen. Folgende Tasks sind für
einen reibungslosen Ablauf notwendig:
1. Budgetgenehmigung
2. Hardware bestellen
3. Hardware installieren
4. Kandidatenliste erstellen
5. Kandidaten befragen
6. Kandidaten im Umgang mit neuer Hardware schulen
20
Grundlagen des Projektmanagements
_________________________________________________________________________________
Nach dem Erhalt der Budgetgenehmigung kann der Ablauf der weiteren Tasks parallelisiert
werden. Hardwarebestellung und Installation stehen ja nicht in direktem Zusammenhang mit
dem Erstellen der Kandidatenliste und deren (wer letztendlich die neue Hardware bedient ist
für die Hardware nicht von Belang.). Sobald die parallel laufenden Prozesse abgeschlossen
sind, kann das Training für die Kandidaten mit der neuen Hardware beginnen.
6.3.3 Abhängigkeiten und Beziehungen
Die Form der Abarbeitung der Tasks in Beispiel 6.2 wird Finish-to-Start Abhängigkeit
genannt. Sie ist die am häufigsten auftretende Form, doch nicht immer können oder vor
allem sollen Tasks in dieser Art abgearbeitet werden. Ein nachfolgender Tasks kann
manchmal erst gewisse Zeit nach der Fertigstellung des vorangegangenen Tasks
beginnen(Die Bestellung der Hardware kann an einem Tag erledigt werden, deren
Anlieferung jedoch dauert mindestens 2 Tage.) , oder, ein anderer nachfolgender Task, der
nicht die gesamten Informationen des Vorangegangenen benötigt, könnte schon früher
starten (Warum sollte die Befragung der Kandidaten erst nach Vollendigung der gesamten
Kandidatenliste beginnen? Könnte man damit nicht auch schon nach Erfassung von bspw.
20% der Kandidaten starten?).
Um den Bedarf an verschiedenen Abhängigkeiten decken zu können wurden vier
verschiedene Modelle eingeführt:
 Finish-to-Start (FS)
 Start-to-Start (SS)
 Finish-to-Finish (FF)
 Start-to-Finish(SF)
6.3.3.1 Finish-to-Start (FS) – Dependency
Im Falle einer Finish-to-Start Abhängigkeit
kann (muss aber nicht!) der nachfolgende
FS = 2
Prozess direkt nach Beendigung des
Bestelle
Installiere
vorhergehenden Prozesses gestartet werden.
Hardware
Hardware
1Tag
3 Tage
Anders
ausgedrückt
muss
der
der
vorangegangene Prozess fertiggestellt sein,
bevor der nächste Prozess starten kann.
Sollte der nachfolgende Prozess aus irgendeinem Grund erst später gestartet werden
können oder dürfen, wird ein sogenannter Lag-Value in der Abhängigkeit angegeben. Im
Hardwarebeispiel würde so ein Lag zwischen dem Bestellen und der Installation der
Hardware entstehen – durch die Dauer der Anlieferung der Hardware (hier mit dem
angenommenen Wert von 2 Tagen, daher FS=2)
6.3.3.2 Start-to-Start (SS) - Dependency
Bei einer Start-to-Start Abhängigkeit startet
der nachfolgende Task nach einer gewissen
SS=3
Verzögerung, bevor der vorhergehende Task
Erstelle
Befrage
beendet wird. Der Wert dieser Verzögerung
Kandidatenliste
Kandidaten
(Delay) wird über dem vorangegangenen
5Tage
7 Tage
Task und der Abhängigkeit dargestellt. Bei
unserem Hardwarebeispiel könnte man eine solche Beziehung bei den Tasks der Erstellung
und der Befragung der Kandidaten einbauen, denn die Kandidatenliste muss ja nicht
komplett fertiggestellt sein, um bereits Befragungen mit ausgewählten Kandidaten
durchzuführen. Als Delay geben wir hier 3 Tage an (SS=3; d.h. der Task der Befragung der
Kandidaten startet bereits 2 Tage nachdem das Team für die Erstellung der Liste begonnen
21
Grundlagen des Projektmanagements
_________________________________________________________________________________
hat.). Somit kann die komplette Abarbeitung des Themas „Personalauswahl“ 2 Tage früher
beendet werden. Der Arbeitsaufwand für beide Aufgaben bleibt der gleiche, trotzdem können
so 2 Tage eingespart werden. In diesem Fall wäre dies besonders günstig, denn da diese
beiden Tasks die meiste Zeit beanspruchen, bevor eine Schulung beginnen kann (zum
Vergleich: die „Hardware“ kann bereits nach 6 Tagen inklusive Lieferzeit einsatzbereit sein),
ist es möglich, dass gesamte Projekt 2 Tage früher abzuschließen.
6.3.3.3 Finish-to-Finish (FF) – Dependency
Bei einer Finish-to-Finish Abhängigkeit muss der vorgehende Task fertiggestellt werden
bevor der darauffolgende Fertiggestellt werden kann. Dies mag jetzt vielleicht ähnlich der
Finish-to-Start Abhängigkeit klingen, der Teufel steckt hier jedoch im Detail. Um dies
verständlich darzustellen wollen wir den „Hardwarezweig“ in unserem Beispiel ein wenig
erweitern:
Bestelle
Hardware
1Tag
Bestellte HW
Subsysteme
anpassen
3 Tage
Installiere
Hardware
3 Tage
Wir nehmen nun an, dass die bestellte (und
FF=2
mittlerweile auch gelieferte) Hardware aus
Bestellte HW
mehreren Subsystemen besteht, die erst auf
Installiere
Subsysteme
unsere Ansprüche hin adaptiert werden muss.
Hardware
anpassen
3 Tage
Natürlich ist es für uns möglich, bereits fertig
5 Tage
adaptierte Systeme zu installieren, wir können
die Installation jedoch erst abschließen,
nachdem alle Subsysteme fertig adaptiert wurden. Dargestellt wird eine Finish-to-Finish
Relation über der Abhängigkeit und dem nachfolgenden Task. Auch hier können
Verzögerungswerte angegeben werden, in unserem Beispielfall wären hier nach 2 Tagen die
ersten Subsysteme fertiggestellt. In der Praxis allerdings kommen bei IT-Projekten nur in den
seltensten Fällen FF-Abhängigkeiten vor.
6.3.3.4 Start-to-Finish-(SF) Dependency
Bei einer Start-to-Finish Abhängigkeit kann der nachfolgende Prozess nicht fertiggestellt
werden bevor der vorhergehende Prozess nicht gestartet wurde. Um dies mit unserem
Hardwarebeispiel wieder darstellen zu können, erweitern wir diesen wieder:
Veranstalte
Training
4 Tage
Teste neues
System
unbestimmt
Statistische
Auswertung
4 Tage
Nachdem wir unsere Kandidaten auf die neue
SF=2
Hardware eingeschult haben, wollen wir feststellen,
Teste neues
Statistische
ob sie in der Lage sind damit umzugehen und die
System
Auswertung
gewünschten Produktionskapazitäten erreichen.
unbestimmt
4 Tage
Daher führen wir eine unbestimmte Testperiode und
deren Auswertung ein. Die Auswertung kann erst
dann abgeschlossen werden, wenn die Testphase begonnen hat. Auch hier können Delaywerte angegeben werden, für unser Beispiel etwa arbeitet das System 2 Tage im
22
Grundlagen des Projektmanagements
_________________________________________________________________________________
Testbetrieb, bevor wir mit der statistischen Auswertung beginnen. Dargestellt wird die SFDependency über beide Tasks mit dem Delay Value über der Abhängigkeit.
6.3.3.5 ON-Network Beispiel mit Relationen
Bestelle
Hardware
1Tag
Erhalte Budget
Genehmigung
1Tag
FS=2
Installiere
Hardware
3 Tage
SF=2
Veranstalte
Training
4 Tage
SS=2
Erstelle
Kandidatenliste
5Tage
Teste
System
unbestimmt
Stat.
Auswertung
4 Tage
Befrage
Kandidaten
7 Tage
6.3 Relationsbehaftetes AON-Network
6.4 Der kritischer Pfad
Ist der Netzplan mit all seinen Abhängigkeiten kreiert und ist der Zeitaufwand für jeden
einzelnen Task bestimmt, kann man die Kalkulation des kritischen Pfades in Angriff nehmen.
Der kritische Pfad repräsentiert den längsten Weg durch einen Netzplan, sprich, er stellt eine
Aneinanderreihung der Tasks dar, deren Summe der Aufwandsabschätzung am längsten
dauert. Richtig angewandt, kann man mit dem kritischen Pfad die Gesamtdauer des Projekts
abschätzen, und so den erstmöglichen Fertigstellungtermin bestimmen.
Beispiel einer einfachen Kalkulation:
Anhand unseres Hardwarebeispiels (Abbildung 6.4) können wir eine einfache Kalkulation
des kritischen Pfades demonstrieren. Der längste Weg im Netzplan ist:
Start > Budgetgenehmigung (1) > Kandidatenliste (5) <> Kandidatenbefragung (7) >
Training (4) > Ziel
Zusammengezählt würden wir auf eine Projektgesamtdauer von 17 Tagen kommen, da
jedoch das Erstellung der Kandidatenliste und die Befragung der Kandidaten über eine Startto-Start Relation voneinander abhängig sind, ist die Dauer dieser beiden Tasks auf 10 Tage
reduziert (SS=2) und die Gesamtdauer beträgt somit nur mehr 14 Tage.
Bestelle
Hardware
1Tag
Start
Erhalte Budget
Genehmigung
1Tag
FS=2
Installiere
Hardware
3 Tage
Veranstalte
Training
4 Tage
SS=2
Erstelle
Kandidatenliste
5Tage
Befrage
Kandidaten
7 Tage
6.4 Einfache Kalkulation des kritischen Pfades
Voraussetzungen zur Bestimmung des kritischen Pfades sind also:
23
Ziel
14 Tage
Grundlagen des Projektmanagements
_________________________________________________________________________________
1. Netzplan ist mit all seinen Abhängigkeiten konstruiert
2. Aufwandsabschätzung für jeden Task erstellt
Der kritische Pfad gibt an:



den Pfad mit der längsten Gesamtdauer
die gesamte Projektlaufdauer
Enthält keine Zeitpuffer
Da ein Projekt aber im Normalfall deutlich mehr Tasks und Abhängigkeiten besitzt als in
unserem einfachen Hardwarebeispiel angegeben, kann es durchaus mehrere mögliche
Pfade geben, mit unterschiedlichen Abhängigkeiten, was die Kalkulation durchaus erschwert.
Daher ist eine effizientere Methode, wie etwa Vorwärts –und Rückwärtskalkulation
wünschenswert.
6.4.1 Berechnungsmethoden zur Kalkulation des kritischen Pfades
Die Vorwärtspfadmethode (Forward Path Computation) wird dazu verwendet, um die
ehestmöglichen Start -und Endzeitpunkte jedes Tasks zu bestimmen. Die
Rückwärtsmethode (Backward Path Computation) bestimmt die spätest möglichen Start –
und Endzeitpunkte der einzelnen Tasks zu bestimmen.
Um diese (Zeit)Punkte für jede Aufgabe zu bestimmen, wird folgende Notation eingeführt:
 Early Start (ES)
 Early Finish (EF)
ES
EF


Task Name
Late Start (LS)
Late Finish (LF)
Dauer
LS
LF
6.4.1.1 Early Start (ES)
Die Early Start Time eines Tasks hängt von der Fertigstellung des vorangegangenen Tasks
ab. Sobald der vorangegangene Tasks beendigt wird, kann der neue Task starten – Early
Start.
6.4.1.2 Early Finish (EF)
Early Finish definiert sich durch folgende Formel:
(EF = (ES + Taskdauer) – (1 Zeiteinheit)
Angewandt auf unser Hardwarebeispiel sieht das folgendermaßen aus:
Zwecks Übersichtlichkeit entfernen wir die Abhängigkeiten, um das Prinzip besser darstellen
zu können. Die ES und EF Punkte sind hier recht simpel anhand deren Regeln einzutragen.
Der Knoten am Ende der beiden parallel laufenden Stränge markiert die Stelle, an der der
weitere Verlauf des kritischen Pfades einfach bestimmt werden kann. Nach der Installation
der Hardware beträgt der Wert für EF 5 Tage, bei der Kandidatenbefragung steht der
Counter für EF bei 13. Da sich der kritische Pfad durch den längsten Weg bestimmt, wird mit
dem unteren Pfad weiterkalkuliert (da 13 >5).
24
Grundlagen des Projektmanagements
_________________________________________________________________________________
ES= 2
ES= 1
Start
EF= 1
Erhalte Budget
Genehmigung
1Tag
EF= 2
ES= 3
Bestelle
Hardware
1Tag
ES= 2
EF= 5
Installiere
Hardware
3 Tage
EF= 6
Erstelle
Kandidatenliste
5Tage
ES= 7
EF= 13
ES= 14
EF= 17
Veranstalte
Training
4 Tage
Ziel
17 Tage
Befrage
Kandidaten
7 Tage
Abbildung 6.5 AON-Network mit Forward Path Notation
6.4.1.3 Late Finish (LF)
Die Late Finish Time ist die Zeit, in der ein Task fertiggestellt werden kann ohne die
Gesamtdauer des Projekts zu verzögern. Die LF Wert des letzten Tasks ist daher gleich dem
des Early Finish Wertes. Für die Berechnung der LF Zeiten für alle anderen Tasks gilt die
Formel:
LF= LS(nachfolgender Task) – 1
6.4.1.4 Late Start (LS)
Late Start kalkuliert sich aus der Formel:
(LS= (LF-Taskdauer) +1 Zeiteinheit)
Nun wenden wir die Rückwärtskalkulation auf unser Hardwarebeispiel an:
Schritt 1: Wir beginnen mit dem letzten Task. Der EF-Wert für den letzten Task beträgt 17.
Da laut Definition EF und LF des letzten Tasks gleich sein müssen, ist unser Ausgangspunkt
mit LF = 17 festgelegt. Die Berechnung für den LS des letzten ergibt sich aus der oben
erwähnten Formel
(LSTraining= (17-4) +1)=14
Bei der weiteren Berechnung spaltet sich das Netzwerk wieder in 2 parallel laufende
Stränge, den „Hardwarestrang“ und den Kandidatenstrang.
Berechnung des Hardwarestrangs:
Task Hardware installieren:
Die LF ergibt sich aus der LS des nachfolgenden Tasks (Training) minus einer Zeiteinheit:
LF(HW installieren) = LS(Training) – 1 Zeiteinheit
13 = 14(Training) – 1
Hat man den LF des Tasks bestimmt, berechnet sich die LS aus:
LS(HW installieren) = LF(HW installieren) – Taskdauer + 1 Zeiteinheit
11(HW installieren) = 13(HW installieren) – 3 + 1
Task Hardware bestellen:
LF(HW bestellen) = LS(Hardware installieren) – 1 Zeiteinheit
10 = 11 -1
LS(HW bestellen) = LF(Hardware bestellen) – Taskdauer + 1 Zeiteinheit
10 = 10 -1 +1
25
Grundlagen des Projektmanagements
_________________________________________________________________________________
Die Berechnung des Hardwarestrangs erfolgt auf dieselbe Art und Weise.
Task Kandidaten befragen:
LF(Befragung) = LS(Training) – 1 Zeiteinheit
13 = 14(Training) – 1
LS(Befragung) = LF(Befragung) – Taskdauer + 1 Zeiteinheit
7(Befragung) = 13(Befragung) – 7 + 1
Task Kandidatenliste erstellen:
LF(Liste) = LS(Befragung) – 1 Zeiteinheit
6 = 7(Befragung) – 1
LS(Liste) = LF(Liste) – Taskdauer + 1 Zeiteinheit
2(Liste) = 6(Liste) – 5 + 1
Der Knoten der Gabelung weist wieder auf die Zusammenführung zweier parallel laufender
Stränge hin. Im Fall der Rückwärtsberechnung ist hier jedoch der Pfad mit der geringsten
Late Start Zeit als Ausgangspunkt für die weitere Berechnung zu wählen.
Task Budgetgenehmigung:
LF(Budget) = LS(Liste) – 1 Zeiteinheit
1 = 2(Liste) – 1
LS(Budget) = LF(Liste) – Taskdauer + 1 Zeiteinheit
2(Budget) = 1(Budget) – 1 + 1
ES= 2
ES= 1
Start
EF= 1
Erhalte Budget
Genehmigung
1Tag
LS=1
LF=1
EF= 2
ES= 3
Bestelle
Hardware
1Tag
LS= 10
ES= 2
Installiere
Hardware
3 Tage
LF= 10
EF= 6
Erstelle
Kandidatenliste
5Tage
LS=2
EF= 5
LF=6
LS= 11
ES= 7
LF= 13
EF= 13
Befrage
Kandidaten
7 Tage
LS=7
ES= 14
EF= 17
Veranstalte
Training
4 Tage
LS=14
Ziel
17 Tage
LF=17
LF=13
6.6 AON-Network mit FPN und BPN
6.4.2 Free Slack – Zeitpuffer und deren Bestimmung
Def. Free Slack : Pufferzeit, gemäß DIN 69900-1 ist Pufferzeit eine "Zeitspanne, um die,
unter bestimmten Bedingungen, die Lage eines Ereignisses bzw. Vorgangs verändert oder
die Dauer eines Vorgangs verlängert werden kann, ohne die Gesamtdauer des Projekts zu
beeinflussen."
Wie bereits im vorigen Abschnitt erwähnt, wird der kritische Pfad aus der Kette jener Tasks
zusammengesetzt, die keine Pufferzeiten jedweder Art enthalten (slack-free). Zeitpuffer
beziehen sich auf jeden Task im Netzplan. Sie geben jene Zeit an, die ein Task verzögert/
verspätet starten kann, ohne dass der folgende Task in seiner Ausführung behindert wird.
Für die Bestimmung des Slacks wird folgende Formel angewandt:
Slack(Task) = LF(Task) – EF(Task)
Um Slack in unserem Hardwarebeispiel gebührend darzustellen erweitern wir es um einen
Task, der parallel zum Hardware –und Kandidatenstrang verläuft, nämlich Raum adaptieren.
26
Grundlagen des Projektmanagements
_________________________________________________________________________________
Task
Budgetgenehmigung
HW bestellen
HW installieren
Kandidatenliste
Befragung
Training
Raum adaptieren
LF-Value
1
10
13
6
13
17
13
EF-Value
1
2
5
6
13
17
4
ES= 2
Slack
0
8
8
0
0
0
9
EF= 4
Raum
adaptieren
3 Tage
LS= 11
ES= 2
ES= 1
Start
LS=1
EF= 2
ES= 3
Bestelle
Hardware
1Tag
EF= 1
Erhalte Budget
Genehmigung
1Tag
LF= 13
LS= 10
LF= 10
ES= 2
EF= 6
LS=2
ES= 14
LF= 13
LS= 11
ES= 7
Erstelle
Kandidatenliste
5Tage
LF=1
EF= 5
Installiere
Hardware
3 Tage
EF= 13
Befrage
Kandidaten
7 Tage
LF=6
LS=7
EF= 17
Veranstalte
Training
4 Tage
LS=14
Ziel
17 Tage
LF=17
LF=13
Wie gefordert ist unser kritischer Pfad (grau unterlegt) slack-free. Der Hardwarepfad weist
einen Slack von insgesamt 8 Tagen auf, bei der Raumadaption beträgt der Slack-Value 9
Tage. Die grafische Darstellung ist in Abbildung 6.7 gezeigt.
Time
1
2
3
4
5
6
Raum adaptieren
7
8
9
10 11 12 13
Slack = 9
Hardware bestellen/
Hardware installieren
Slack = 8
Kandidatenliste
Befragung
6.7 Slack-Diagramm
6.5 Angepasste Netzpläne
Der Grund für die Erstellung eines Strukturplanes basiert auf der Annahme, dass alle
genehmigten Ressourcen permanent sofort abrufbar sind – die Taskabfolge wurde rein auf
dieser Grundlage erstellt. In der Praxis kann –und wird – es jedoch vorkommen, dass
Projekte Ressourcen wie beispielsweise Personal, Budget oder Infrastruktur abgeben
müssen.
Daher unterscheidet man zwischen verschiedenen Arten von Netzplänen basierend auf
möglichen Einschränkungen oder Erweiterungen:
27
Grundlagen des Projektmanagements
_________________________________________________________________________________
6.5.1 Version 0 Network
Beim Version 0 Network handelt es sich um den ursprünglichen mit den zuvor
bereitgestellten Ressourcen Netzplan. Dieser beschreibt eingehend Abhängigkeiten und
Abläufe für die „Originalverhältnisse“, d.h. er geht von der Annahme aus, dass alle zuvor
bestätigten Ressourcen dementsprechend verfügbar sind.
6.5.2 Constrained Network
Ein constrained Network, zu deutsch ein eingeschränkter Netzplan, leitet sich direkt aus dem
Version0 Network ab. Es beschreibt die Abläufe und Abhängigkeiten für ein eingeschränktes
Maß an Ressourcen. Beispielsweise müssen parallele Arbeitsabläufe in serielle
umgewandelt werden, oder die Dauer einzelner Tasks erhöht sich, falls die Mitarbeiterzahl
aus irgendeinem Grund gekürzt wird.
6.5.3 Extra Ressources
Im dem seltenen Fall, dass vom Management dem Projekt zusätzliche Ressourcen zur
Verfügung gestellt werden, gilt es zu überlegen, diese richtig einzusetzen. Es dürfte nicht
schwierig sein, festzustellen, dass diese am besten entlang des kritischen Pfades eingesetzt
werden sollten, da dies zur Verkürzung der Gesamtprojektdauer beiträgt. In Bezugnahmen
zu unserem Hardwarebeispiel wäre es beispielsweise unsinnig, zusätzliche Ressourcen für
die Installation der Hardware freizugeben, wenn die Erstellung der Kandidatenliste sowie
deren Befragung diese deutlich dringender benötigen würde.
28
Grundlagen des Projektmanagements
_________________________________________________________________________________
7 Verwendete Literatur:
[Kapur 2005]
Kapur, G.K.: Project management for information, technology, business, and certification;
Pearson Prentics Hall, Ohio, USA, 2005.
[Kerzner 2003]
Kerzner, H.: Projektmanagement. Ein systemorientierter Ansatz zur Planung und Steuerung;
mitp Verlag, Bonn, Germany, 2003.
[Specker 2005]
Specker A.: Modellierung von Informationssystemen: Ein methodischer Leitfaden zur
Projektabwicklung, vdf Hochschulverlag AG, Germany, 2005
[Standish Group]
http://www1.standishgroup.com/sample_research/PDFpages/q3-spotlight.pdf
http://www1.standishgroup.com/sample_research/PDFpages/extreme_chaos.pdf
[WIKIPEDIA]
Projektmangement: http://de.wikipedia.org/wiki/Projektmanagement
Vorgehensmodell
http://www.projektmagazin.de/glossar/gl-0089.html
Projektmanagementprozess
http://www.projektmagazin.de/glossar/gl-0512.html
Projektprozess
http://www.projektmagazin.de/glossar/gl-0513.html
Projektlebenszyklus
http://www.projektmagazin.de/glossar/gl-0611.html
Lebensweg
http://www.projektmagazin.de/glossar/gl-0312.html
Projektstrukturplan
http://www.projektmagazin.de/glossar/gl-0093.html
Projektphase
http://www.projektmagazin.de/glossar/gl-0088.html
Liefergegenstand
http://www.projektmagazin.de/glossar/gl-0417.html
Meilenstein
http://www.projektmagazin.de/glossar/gl-0046.html
Tätigkeit
http://www.projektmagazin.de/glossar/gl-0342.html
Ereignis
http://www.projektmagazin.de/glossar/gl-0371.html
29