Die ist ein weiterer Anfang zu einer Serie. In dieser soll es um MS-Project geht, und wie ich mit diesem Tool meine Projektplanung und Kontrolle unterstützen und dokumentieren kann. Um das von mir vorgeschlagene Vorgehen zu begründen, werde ich auch die eine oder andere theoretische Grundlage schaffen.

Alle Teile dieser Serie:
Der Projektstrukturplan
Der Ablaufplan
Arbeit und Dauer
Speichere früh, speichere oft, aber nicht automatisch.

MS-Project hat diverse Bugs, Unfeatures und fehlende Features. Ein Beispiel dafür ist die Undo Funktion. Diese funktioniert oft, aber nicht immer, und so kann es passieren, dass man mit ein paar Mausklicks sein Dokument zerstört und es mit MS-Project Mitteln nicht wieder hergestellt bekommt.

Daher sollte in regelmäßigen, nicht zu großen Abständen gespeichert werden und zwar so, dass man nicht nur auf die letzte sondern auf alle gespeicherten Versionen zugreifen kann. Dies erreicht man entweder in dem man einen Versionsverwaltung einsetzt, oder man versieht jede gespeicherte Datei mit einer Versionsnummer, die bei jedem speichern manuell erhöht wird:

MyProject-V003.mpp

An dieser Stelle ist man versucht diesen Prozess zu automatisieren, schließlich sind wir alle faul, nicht war? Die Autosave Option ist dafür aber definitiv die falsche Option, da nach Murphy’s Law Autosave direkt nach einer ungeschickten Aktion aktiv wird, und mit dem Datenmüll, den man soeben produziert hat, unwiederbringlich den letzten intakten Arbeitsstand überschreibt.

Wenn es eine Standardeinstellungen von Microsoft ist, dient es der Featuredemonstration, nicht dem sinnvollen arbeiten.

Wenn MS-Project gestartet wird, bietet es einem standardmäßig eine zweigeteilte Ansicht an:

Links ist eine Tabelle mit den Spalten:

• i wie Information oder Notiz
• Vorgangsname
• Dauer
• Anfang
• Ende
• Vorgänger
• Resourcennamen

Dies verleitet dazu viele Dinge auf einmal zu planen:

• was alles zu tun ist (Vorgangsname)
• wie lange es dauern wird (Dauer)
• wann es getan wird (Anfang, Ende)
• in welcher Reihenfolge es geplant wird (Vorgänger)
• und wer es tut

Die meisten Projektleiter sind erfahrungsgemäß männlich und sind per Definition nicht Multitasking fähig. Sie Sollten sich also lieber auf eine Aufgabe beschränken. Bei Frauen bin ich mir nicht so sicher, ich vermute aber, dass es ihnen auch nicht schadet. Also konfigurieren (s.u.) wir die Ansicht so um, dass wir nur noch die folgenden Spalten sehen:

• i wie Information (die kann man immer gut gebrauchen)
• Vorgangsname
• Notizen
• PSP-Code (s.u.)

Hier können wir nun den sogenannten Projektstrukturplan (PSP; engl. Workbreakdownstructure) erstellen. Der PSP ist eine hierarchisch geordnete Sammlung sämtliche Vorgänge, die in einem Projekt zu erledigen sind. Dabei entstehen früher oder später zwei Fragestellungen:

1. Wie detailliert soll ich planen?
Die Antwort ist so einfach wie unbefriedigend. Plane genau das, was du kontrollieren kannst und willst. Das heißt, man muss sich eine Vorstellung davon machen, wie oft man den Fortschritt später im Projekt kontrollieren möchte. Je nach Projekt kann dies extrem unterschiedlich ausfallen: Wenn ich eine große Weihnachtsfeier organisiere, kann die Vorbereitung durchaus ein halbes Jahr vorher beginnen, ich werde aber vermutlich nur gelegentlich (einmal pro Monat?) den Status kontrollieren, am Tag der Feier werde ich aber unter Umständen stündlich nach dem rechten sehen. Das wichtige Kriterium ist die Frage des tolerierbaren Risikos: Ich muss einen Vorgang so genau im Auge behalten, damit ich noch reagieren kann, wenn ich merke, dass etwas schief geht, ohne dass unakzeptabler Schaden am Projekt entsteht.

2. Wie strukturiere ich den Projektstrukturplan?
In Wirklichkeit stellen sich erschreckend wenige Projektleiter diese Frage, was zu Ergebnissen wie dem folgenden führt (nur die erste Hierarchieebene ist dargestellt):

Next Killer App

    GUI

    DB

    Business Logik

    testen

    dokumentieren

Wem noch nicht aufgefallen ist, was an dieser Struktur falsch ist, überlege sich wo denn die Gui dokumentiert wird, und wo die Datenbank getestet wird.

Das Problem ist, dass unterschiedliche Kriterien verwandt werden: Einerseits Schichten der Anwendung, andererseits Tätigkeiten. Dadurch ist für einen Vorgang nicht klar, wo er indieser Struktur einzuordnen ist. Und dies führt mindestens zu unnötiger Sucherrei, oft aber zu schlicht vergessenen oder doppelt geplanten Vorgängen.

innerhalb eines Sammelvorgangs, werden die Untervorgänge nach einem einheitlichen Kriterium strukturiert.

Kriterien könnten dabei sein:

• Projektphasen (Vorsicht, da Phasen sich meist überlappen)
• Objekte, d.h. Teile des zu erstellenden Projektergebnisses. Dies könnten Gebäudeteile in einem Bauprojekt sein, Module oder Schichten in einer Anwendung.
• Tätigkeiten (entwerfen, analysieren, anstreichen, reinigen, testen ...)
• Personengruppen / Abteilungen, die für die Vorgänge zuständig sind: (Maler, Architekten, Tester)

Welches das richtige Kriterium ist, hängt vom Projekt und vom Geschmack des Projektleiters ab.

Eine Sonderrolle nimmt häufig das Projektmanagement selbst auf der obersten Hierarchieebene ein. Projektmanagement darf (und sollte) auf der obersten Ebene seinen eigenen Zweig bekommen. Läuft dies der ausgewählten Strukturierung zuwieder ist es eine zulässige Ausnahme, wenn klar definiert ist, dass alle PM-Aufgaben unter diesem Zweig einzuordnen sind.

Der PSP Code
Der PSP Code ist ein Schlüssel, der jeden Vorgang eindeutig kennzeichnet. Er kann in MS-Project automatisch erzeugt werden, wobei stark beeinflusst werden kann wie der PSP-Code aussieht. Der PSP-Code ist kurz und kompakt, liefert aber dennoch eine Menge Information darüber wo der gekennzeichnete Vorgang im PSP wiederzufinden ist. Daher eignet er sich hervorragend um im Projekt Vorgänge zu referenzieren.

Das Aussehen des PSP-Codes lässt sich unter
Projekt->PSP-Code->Codedefinition...
konfigurieren. Ich persönlich bevorzuge:

• ein 3-4 Buchstabenkürzel für das Projekt
• 2-3 manuell vergebene Großbuchstaben für die oberste Gliederungsebene, die einen Hinweis auf die Gliederungsebene liefern
• abwechselnd Zahlen und Kleinbuchstaben, automatisch vergeben.

Konfiguration der Tabellenansicht in MS-Project
Per Click auf die Spaltenheader können Spalten zu der Tabelle hinzugefügt und entfernt werden. Meist ist es jedoch geschickter einen etwas anderen Weg zu gehen.

Ãœber das Menü
Ansicht -> Tabelle: xxx -> Weitere Tabellen...
können die Spalten in einer benannten Tabelle konfiguriert werden, bzw. weitere benannte Tabellen definiert werden. Diese Tabellen können dann per Menü ausgewählt werden. Auf diese Weise müssen nicht ständig Spalten hinzugefügt und entfernt werden.

Im nächsten Teil dieser Serie beschreibe ich, wie aus dem Projektstrukturplan ein Ablaufplan erstellt wird.