Alle Teile dieser Serie:
Der Projektstrukturplan
Der Ablaufplan
Arbeit und Dauer

Im vorigen Teil dieser Serie habe ich den Aufbau eines Projektstrukturplanes mit Hilfe von Microsoft
Project beschrieben. Einer meiner Empfehlungen war, dass man sich zunächst wirklich auf den PSP konzentriert und
Dinge wie Abhängigkeiten und Termine zunächst ignoriert. Um die Abhängigkeiten möchte ich mich in diesem Artikel
kümmern.

Meilensteine

Meilensteine kennzeichnen Ereignisse im Projekt. Da es sich um Ereignisse handelt haben sie Dauer und Arbeit 0. Das
sagt zumindestens die Theorie. MS-Project meint es mal wieder besser zu wissen. Dort gibt es für einen Vorgang
einerseits die Angabe "Dauer", andererseits die Angabe "Meilenstein". Wenn man die Dauer auf 0 setzt, wird auch
automatisch das Meilensteinflag auf "Ja" gesetzt. Soweit so gut. Aber man kann auch von Hand das Meilensteinflag auf
"Ja" setzen, ohne dass die Dauer, oder die Arbeit dadurch beeinflusst wird. Eindeutig ein weiteres Unfeature von
Microsoft Project, dass man tunlichst meiden sollte, es sei dann man plant seine Kollegen in den Wahnsinn zu treiben.

Jedes Projekt sollte wenigstens zwei Meilenstein haben, den Projektbeginn und das Projektende.
Meilensteine sollten immer mit einem klaren Kriterium versehen sein, wann sie erreicht werden. Dadurch zwingen sie
den Projektleiter, das Projektteam und gegebenenfalls Steuerungsgremien dazu innezuhalten und bewusst eine
Entscheidung zu treffen, ob der Projektfortschritt bisher befriedigend war und ob mit dem Projekt fortgefahren werden
sollte. Damit dies immer wieder einmal im Laufe eines Projektes geschieht, sollten immer mal wieder Meilensteine in
einem Projekt vorgesehen werden.

Neben der groben zeitlichen Strukturierung eines Projektes können Meilensteine für verschiedene Zwecke eingesetzt
werden. Ich werde immer wieder darauf hinweisen.

Ablaufplan

Der Ablaufplan beschreibt in welcher Reihenfolge Tätigkeiten auszuführen sind. Er entsteht aus dem
Projektstrukturplan, in dem zu jedem Vorgang Vorgänger und Nachfolger definiert werden. Dazu wird in die
Tabellenansicht so konfiguriert, dass die folgenden Spalten zu sehen sind:

• Nr.
• i wie Information
• Vorgangsname
• Notizen
• PSP-Code (s.u.)
• Vorgänger
• Nachfolger

Nr. ist einfach die laufende Nummer eines Vorgangs, wie sie MS-Project verwendet, und genau diese Nummer wird bei
Vorgänger oder Nachfolger eingetragen. MS-Project kümmert sich für uns darum, dass die beiden Angaben immer synchron
sind, d.h. wenn Vorgang Nummer 2 als Nachfolger von Vorgang 1 eingetragen ist, dann ist Vorgang 1 auch Vorgänger von
Vorgang 2.

Das ganze ist auch per Maus im Ganttchart (die blauen Balken mit Pfeilen dazwischen) editierbar, ich würde davon aber
dringend abraten. Eine Mausgeste hat in dem Ganttchart sehr unterschiedliche Bedeutung, je nachdem wo man sie
ausführt. Nur zu schnell haben sie einen Vorgang aus versehen auf einen festen Termin festgelegt, oder eine Beziehung
definiert, die sie gar nicht haben wollten, und in dem Gewusel, das sie bald im Ganttchart haben, werden sie dass
nicht so schnell wieder finden. Die Tabelle ist ihr Freund.

An alle, die jetzt schon fleissig Vorgänger und Nachfolger definieren ein gerufenes HALT! Es fehlt
noch ein wenig Theorie.

Was ist ein Vorgänger / Nachfolger

Eine Vorgänger-Nachfolger Beziehung wie ich sie oben mit MS-Project-Mitteln beschrieben habe bedeutet:

Der Nachfolger kann erst beginnen, wenn der Vorgänger beendet ist.

In diesem Satz steckt mehr als man auf den ersten Blick entdeckt, daher lasst mich das eine oder andere noch
herausarbeiten.

Erstens: Das Wörtchen kann in obigem Satz bedeutet, es geht um einen kausalen Zusammenhang, nicht etwa um
einen temporalen. Also nur weil Modul1 ihrere Meinung nach vor Modul2 implementiert werden sollte, heisst dies noch
lange nicht, dass eine Vorgänger/Nachfolger Beziehung vorliegt. Außerdem sollten wir uns auf direkte kausale Beziehungen beschränken. Analyse ist ein Vorgänger der Implementierung, und diese ein Vorgänger des Tests. Natürlich ist auch die Analyse ein Vorgänger des Tests, dies wird man aber nicht explizit abbilden, da es schon implizit über die Implementierung berücksichtigt ist.

Zweitens: Wir reden von Ende und Anfang des Vorgängers, bzw. des Nachfolgers. Dies nennt man auch
Ende-Anfang-Beziehung oder Normalbeziehung, da es der Standardfall ist, der in den meisen Fällen benötigt wird. Es
gibt diverse Variationen dieser Beziehung.

Zum einen kann man Beziehungen zwischen Ende-Ende, Anfang-Ende oder Anfang-Anfang geben. Diese sind in 99% der Fälle
unnötig, und nach meiner Erfahrung in 95% der eingesetzten Fälle falsch, daher empfehle ich hier der Kürze halber
einfach: ignorieren und nur Ende-Anfang-Beziehungen verwenden.

Zum anderen können Zeitabstände definiert werden, die eingehalten werden müssen. Bei einem positiven Zeitraum kann
man sich gut vorstellen, wie so etwas sinnvoll einzusetzen ist. Beton zum Beispiel muss 28 Tage?
abbinden, bevor darauf aufbauend weiter gearbeitet werden kann. Um eine solche Zeitdauer in
MS-Project einzugeben, schreiben sie in das Vorgänger bzw. Nachfolgerfeld einen Ausdruck der Art: 42EA+28 Dies
bedeutet, der aktuelle Vorgang eine Ende-Anfangbeziehung mit Vorgang Nummer 42 hat, die mit einem minimalen
Zeitabstand von 28Tagen versehen ist. Das EA steht dabei für die Beziehungsart Ende-Anfang.

Negative Zeitabstände sind zwar anscheinend verlockend für viele, machen aber bei genauerer Betrachtung keinen Sinn.
Die Bedeutung wäre der Art, dass der Nachfolger z.B. 3 Tage vor Ende des Vorgängers beginnen darf, oder später, aber
nicht eher. Zu diesem Zeitpunkt ist das Ende des Vorgängers aber noch in der Zukunft, d.h. es kann immer noch etwas
dazwischen kommen, was das Ende des Vorgangs verzögert, oder womöglich ganz verhindert. Anders formuliert: die bisher
bekannte Physik verbietet kausale Abhängigkeiten von Ereignissen in der Zukunft, und da wir kausale Abhängigkeiten
definieren wollen, machen negative Zeitabstände keinen Sinn. Also Finger davon lassen, sonst löst sich euer Projekt
noch in ein Logikwölkchen auf.

Oft ist man dennoch versucht negative Zeitabstände zu verwenden. In meiner Erfahrung ist die Ursache oft ein fehlender
Meilenstein. Beispiel: Schon vor Abschluss der Analyse kann mit der Implementation begonnen werden. Wenn ich dies mit
Hilfe eines negativen Zeitabstandes definiere, stecke ich die Erwartung hinein, dass zu einem gewissen Zeitpunkt die
Analyse einen bestimmten Reifegrad hat, so dass die Implementierung beginnen kann. Dies lässt sich sauberer planen,
in dem man zusätzliche Meilensteine vorsieht, für die nach Möglichkeit Messbare Kriterien definiert werden, wann sie erreicht werden. Also zum Beispiel: Analysten und Entwickler beschließen gemeinsam, dass die Analyse ausreichend weit fortgeschritten ist um mit der Implementierung zu beginnen. Ein analoges Vorgehen ist auf jeden Fall auch für phasenorientierte Ablaufpläne zu empfehlen, da Phasen sich praktisch immer überlappen und ein klares Kriterium gegeben sein sollte, wann (und ob) eine neue Phase beginnt.

Mehrfach Abhängigkeiten

Oft gibt es Gruppen von Vorgängen, die gemeinsam Vorgänger für andere Gruppen von Vorgängen sind. Dadurch entstehen sehr viele Abfolgebeziehungen und es wird sehr schwierig zu beurteilen, ob alle Abhängigkeiten wirklich abgebildet wurden. Noch unangenehmer wird es wenn in der Planungsphase ständige Vorgänge hinzukommen oder wegfallen. Auch hier hilft ein Meilenstein, der den Abschluss der Vorgänger bündelt und als Vorgänger für die Nachfolger dient.

Abraten würde ich aber davon Beziehungen zwischen Sammelvorgängen zu machen, also den höheren Hierarchieebenen des Projektstrukturplans. Der Grund? Diese Ebenen sind per Definition abstrakte Gliederungskriterien, sie enthalten keine Aussage über die Reihenfolge von Vorgängen. Dieses Prinzip wird aufgebrochen, wenn zwischen Sammelvorgängen Abhängigkeiten definiert werden. Zu leicht kommt später ein Vorgang zu dem Sammelvorgang hinzu, der dann automatisch die Abhängigkeit erbt, egal ob gewünscht oder nicht.

Sanitycheck

Wenn auf diese Weise die Abhängigkeiten zwischen den Vorgängen definiert sind. Sollte es außer dem Meilenstein Projektbeginn keinen Vorgang geben, der keinen Vorgänger hat und keinen, der keinen Nachfolger hat, außer dem Meilenstein Projektende. Vorgänge ohne Vorgänger würde nicht zum Projekt gehören und würden daher auch nicht im Rahmen des Projektes geplant werden. Vorgänger ohne Nachfolger werden offensichtlich nicht für den Projektabschluss benötigt und sollten daher weggelassen werden. Natürlich gibt es auch immer noch die Variante, dass Vorgänge oder Abhängigkeiten vergessen wurden, diese sollten dann natürlich umgehend ergänzt werden.

Im nächsten Teil der Serie werde ich beschreiben, wie Arbeit und Dauer miteinander zusammenhängen, und wie man diesen Zusammenhang in Microsoft Project abbildet.