Beruflich Dokumente
Kultur Dokumente
Tutorial
fr Project Version 0.18 Chain-Release
Project ermglicht den Aufbau von Projektplanungen klassisch oder nach CCPM.
Project bietet die Mglichkeit manuell oder automatisiert den Projektverlauf gegen-
ber dem Plan zu betrachten.
Tutorial
Project nutz zur Planung und Verfolgung des Projektes ein einziges Fenster.
1 3
2
5 6
4
1. Projektstrukturplan mit Arbeitspaketnummer, Bezeichnung, Dauer in Tagen,
Vorgnger und Ressourcen. Wenn ein Projektpuffer geplant wird hat dieser
die Ressourcenbezeichung project buffer
6. execution im Modus manual oder automatic kann hier mit (ein Tag)
oder (10 Tage) der nchste Tag oder die nchsten Tage akti-
viert/rckgemeldet werden. Ergnzend wird die Projektlaufzeit planned end
und die tatschliche real end berechnet. Bei Projekten mit einem Projektpuf-
fer (Ressource = project buffer) wird das Phasendiagramm gem CCPM
angezeigt.
Beispiel #1 Grundfunktionen
Ausgangssituation
Project startet mit einem vorbelegten Minimalprojektplan, der die Grundfunktionen
zeigt und als Anschauung dient.
Das Projekt besteht aus fnf einfachen Arbeitspaketen (AP). AP2 und AP3 knnen
parallel bearbeitet werden um das Ende (AP5) abzusichern ist ein Projektpuffer
(AP4) mit der Ressource project buffer vorgesehen. Arbeitspakete werden automa-
tisch nach dem Prinzip latest possible start an den sptest mglichen Startzeitpunkt
geschoben.
manueller Modus
Jetzt kann der Projektverlauf simuliert werden. Gestartet wird mit einem klick in
execution entweder auf manual oder automatic. Im Folgenden wird der manuel-
le Modus beschrieben der die Arbeitsweise des Project verdeutlicht.
Ein Klick auf bei execution signalisiert das Ende eines Arbeitstages.
Im Anschluss wird der Projektplan aktualisiert. Der aktuelle Tag wird durch eine rote
Linie angezeigt. Dieser Vorgang wird so lange durchgefhrt, bis das Projektende er-
reicht ist.
Falls sich ein Arbeitspaket verlngert, z.B. am Tag 2 wird die Restlaufzeit nicht ver-
ringert, wird der Unterschied zwischen ursprnglichem Plan (grau) und aktuellem
Plan (schwarz) sofort sichtbar. Des Weiteren hat sich der Meilenstein Ende um ei-
nen Tag verschoben und man sieht die Abweichung von real end zu planned end
unter der Tagesanzeige.
automatic Mode
Der automatic Mode unterscheidet sich dadurch, dass kein manuelles Update der
Arbeitspakete notwendig ist. Basierend auf einer typischen Wahrscheinlichkeitsfunk-
tion werden zu Beginn der Simulation die realen Enddauern der Arbeitspakete zufl-
lig ermittelt. Dies geschieht durch eine klick auf den reset-Button.
final duration die tatschliche Dauer des Arbeitspaketes sobald es beendet wurde
In diesem Beispiel weichen die ermittelten Dauern nicht von den geplanten Dauern
ab. Die hinterlegte Wahrscheinlichkeitsfunktion entspricht sehr der Projektpraxis.
Wenn gengend Puffer in den Arbeitspaketen enthalten ist kommt es in 80% der Fl-
le nicht zu einer berschreitung. Bei vier Arbeitspaketen kann es schon mal passie-
ren, dass alles glatt geht aber lnger dauert als notwendig.
Das Projekt kann nun Tageweise mit execution und (ein Tag) oder (10 Tage)
schrittweise verfolgt werden. Man sieht wie der rote Strich und der Tageszhler wei-
ter voranschreiten.
mit Projektpuffer
Beim Start des Projektes ist ein kleiner Projektpuffer im Projektplan enthalten, der
den Endtermin absichert.
Wenn das erste Arbeitspaket nach Tag 1 noch eine Restdauer von z.B. 5 eingege-
ben wird verlngert sich die kritische Kette um 2 Tage. Dies ist der gerade vergan-
gen Tag + 5 weitere Tage = 6 abzglich der ursprnglichen Planung 4 = 2 Tage
Verzug, diese werden durch den Puffer aufgefangen, der sich entsprechend verkrzt.
Im Phasendiagramm sieht man nun einen kleinen schwarzen Strich, der den Projekt-
fortschritt zeigt. Auf der X-Achse ist der Fortschritt auf der kritischen Kette aufgetra-
gen. Ein Tag von 14 ist erbracht daher leichter Fortschritt. Auf der Y-Achse ist der
Pufferverbrauch zu sehen. Zwei von 6 Puffertagen sind verbraucht. Daher der deut-
liche Anstieg.
Am nchsten Tag luft es besser. Die Restlaufzeit konnte von 5 auf 3 Tage redu-
ziert werden.
Es wurde ein Tag Puffer zurck gewonnen und Fortschritt erzielt. Dies kann im Pha-
sendiagramm schn sichtbar gemacht werden das Projekte ist wieder weiter ins
Grn gekommen.
Nach ein paar Tagen kann sich solch ein Bild zeigen. Am Ende von Tag 9 kam es
zu deutlichen Verzgerungen in AP3 Wnde mauern. Der Puffer ist bis auf einen
Tag abgeschmolzen. Der Fortschritt sogar rcklufig.
Durch gutes Projektmanagement konnten im Verlauf zwei Tage Puffer erhalten blei-
ben:
Im Phasendiagramm sieht man auch retrospektiv schn den Verlauf von Fortschritt
und Pufferverbrauch.
Beispiel #2 GPM-Planspiel
Project kann auch verwendet werden um das wirklich gelungene und anschauliche
GPM-Planspiel zu untersttzen
Das Ende des Projektes wird mit 84 Tagen ermittelt. In diesem Plan sind keine Res-
sourcen aufgefhrt.
Wenn man die Simulation mit mode = automatic startet wird fr zwei Arbeitspake-
te (AP4 und AP9) ein berschreitung der geplanten Dauer berechnet.
Bei durchsteppen des Planes wird dies sichtbar der tatschliche Projektverlauf
weicht vom Plan-0 (grau hinterlegt) ab.
Ab Tag 73 sind beide Verzge sichtbar. Der aktuelle Plan hat sich gegenber dem
ursprnglichen um 6 Tage verlngert.
Im Projektplan sind jetzt die Ressourcen aufgefhrt die Abhngigkeiten sind unver-
ndert. Der Projektplan sieht daher identisch aus wie im ersten Beispiel
In der Simulation kommt es jetzt aber zu der Situation, dass ein Arbeitspaket zwar
begonnen werden knnte die Ressource aber anderweitig schon im Einsatz ist.
Laut Plan htten beide Arbeitspakete beginnen knnen. Das Programm hat sich fr
AP2 entscheiden und damit die Ressource Betonierer blockiert. Das AP1 muss nun
warten bis der Betonierer wieder frei wird und kann daher nicht gestartet werden.
AP2 ist fertig und jetzt kann an AP1 gearbeitet werden das Projekt ist jetzt schon 6
Tage in Verzug.
Am Ende des Projektes ist so ein Verzug von 36 Tagen aufgelaufen. Hier handelt es
sich aber schlicht um Planungsfehler.
Bei genauem hinsehen kann man entdecken, dass das AP13 spter beginnt als laut
Plan mglich. Dies ist dem Prinzip latest possible start von CCPMgeschuldet. Das
Arbeitspaket muss erst zum Einzug des Bauherrs AP16 fertig sein und wird daher
entsprechen nach hinten geschoben.
Wenn man dieses Projekt durchsteppt kommen 6 Tage Verzug durch verlngert Ar-
beitspakete hinzu und man endet bei 120 Tagen wie im vorigen Beispiel. Durch bes-
sere Planung und Bercksichtigung der Ressourcen wird also kein Projekt schneller.
Im nchsten Schritt werden die Arbeitspakete in ihrer Dauer halbiert. Hierzu wird mit
duration halfed alle Dauern der Arbeitspakete halbiert.
Als nchstes wird ein Projektpuffer vom 29 Tagen (57/2 auf ganze Tage aufgerundet)
ergnzt. Auf Arbeitspaket 16 klicken und mit ein neues Arbeitspaket anlegen.
Dauer 29, Vorgnger 13,15 und Ressource project buffer angeben. Das AP17
Einzug den Vorgnger auf 16 den Projektpuffer ndern.
Das gleiche Ergebnis stellt sich auch mit unterschiedlichen Random Seeds ein. Oft
sind die Ergebnisse noch besser (zu viel Restpuffer) in ca. 5% der Flle kommt es
auch zu einer Terminberschreitung. In der Realitt wird durch CCPM ca. 95% Ter-
mintreue erreicht.
Alles keine Hexenwerk der Trick ist die korrekte Bercksichtigung der Wahrschein-
lichkeiten in Projektplnen.
o http://de.wikipedia.org/wiki/Critical-Chain-Projektmanagement
o Eliyahu Goldratt: Critical Chain. North River Press, Great Barrington 1997, ISBN 0-
88427-153-6
o Uwe Techt, Holger Lrz: Critical Chain - Beschleunigen Sie Ihr Projektmanagement,
Haufe-Verlag, ISBN 3-448-07520-5
Wahrscheinlichkeitsfunktion
Ein wesentliches Konzept von Critical Chain Project Management ist die Bercksich-
tigung von Wahrscheinlichkeiten bei Schtzungen.
relative
Wahrscheinlichkeit
sinnvolle Schtzung
max. 50%
typ. Schtzung
0%
opt. real. pes.
Die Absolute Wahrscheinlichkeit eines Schtzwertes ergibt sich ber die Integration
unter der relativen Wahrscheinlichkeitskurve.
o wenn man eine Schtzung erfragt werden von den Schtzern typischerweise
Puffer eingerechnet die dazu fhren, dass sie sicher ihr Arbeitsergebnis recht-
zeitig abliefern. Dies bedeutet nichts anderes als eine absolute Wahrschein-
lichkeit zwischen 80% und 90%.
o die Erfahrung aus CCPM Implementierung zeigen, dass die Halbierung der
Arbeitspakete und anschlieend 50% der Laufzeit als Puffer sehr gute Ergeb-
nisse erzielt. Mit diesen Werten kann man davon ausgehen, dass ca. 95% der
Termine eingehalten werden.
WT 86%
WT/2 48%
bei bei
N=10 N=100 N=1000
Orclassic 4% 4% 3%
%Dropout gibt an wie viele Normprojekte mit diesen Parametern eine berschreitung
des Projektende gem CCPM aufweisen.