"Wenn du den Hals noch so lang machst, du kannst doch nicht hinter den Berg schauen."
(Tao Chi)

Wozu MS-Project?

Microsoft Project ist eine Software für das PC-gestützte Projektmanagement. Ein solches Tool begleitet naturgemäß das gesamte Projekt von Anfang bis Ende. Daher möchte ich diesen Aspekt genauso wie die UML direkt am Anfang meiner Abhandlung erläutern.

Sie können in einer Projektmanagementsoftware Vorgänge zeitlich festlegen und zu Sammelvorgängen zusammenfassen. Darüber hinaus können Sie Ressourcen (Mitarbeiter) zuordnen und über hinterlegte Stundensätze Kosten berechnen. Abhängigkeiten zwischen den Vorgängen sorgen für automatische Verschiebungen ganzer Vorgangsketten bei unerwarteten Ereignissen. Mit Meilensteinen können Sie wesentliche Zeitpunkte des Projekts definieren und deren Einhaltung bzw. Überschreitung prüfen. Unterstützt wird dies durch das Anlegen von Basisplänen, die Sie jederzeit zum Vergleich der aktuellen Situation heranziehen können. In verschiedenen Ansichten können Sie beispielsweise überlastete Mitarbeiter ermitteln oder Kostenverteilungen darstellen. Letztendlich können Sie MS-Project über die integrierte Programmiersprache VBA (Visual Basic for Applications) auch um eigene Funktionalitäten erweitern. Die Version 2003 erlaubt sogar die Anbindung an einen zentralen Project-Server, der Mitarbeiter über Web-Services zusammenbringen kann. Weitere Infos zum Produkt MS-Project erhalten Sie direkt von Microsoft [L15].

Hier einfach mal ein paar Screenshots, damit Sie sich einen kleinen Eindruck von dem Programm verschaffen können:

Es sieht also ganz so aus, als sei eine Projektmanagementsoftware so etwas wie der Zauberstab des Projektleiters. In einem Software-Projekt dient MS-Project sicherlich immer wieder zur Beruhigung des Managements, das in der Regel keinen genügenden technischen Hintergrund besitzt, um sich selbst ein Bild über den Projektstand machen zu können. Ganz sicher ist ein solches Tool auch phantastisch zum Controlling eines Projekts geeignet. Aber es ist und bleibt ein Tool, und einer meiner Lieblingssprüche ist: "A fool with a tool remains a fool!" (dt. "Ein Dummer mit einem Werkzeug bleibt noch immer ein Dummer!"). Denken Sie also bitte bei all der Begeisterung über die Möglichkeiten von MS-Project daran, dass ein Tool nicht die Erfahrung eines Projektleiters ersetzen, sondern allenfalls ergänzen kann!

Gehen Sie bei der Einführung von MS-Project am besten stufig vor: Nutzen Sie es beim ersten Mal nur zur nachträglichen Dokumentation Ihres Projekts, bilden also nur im nachhinein mal das Projekt ab. Beim zweiten Mal protokollieren Sie einfach die aktuellen Geschehnisse als Vorgänge - wie ein Tagebuch. Erst beim dritten Projekt sollten Sie MS-Project dann zur aktiven Kontrolle bzw. für Vorhersagen nutzen. Dazu nutzen Sie die Erfahrungen der beiden ersten Durchläufe und tragen die Vorgänge am Projektanfang ein und passen diese sehr detailliert im Laufe des Projektes an die Realität an. Beim vierten Mal werden Sie MS-Project als aktives Steuerungsinstrument in Ihrem Projekt nicht mehr missen wollen.

Level   1. Dokumentation     2. Protokollierung     3. Kontrolle     4. Steuerung

Aber auch dann noch gilt der oben auf der Seite genannte Spruch, denn die Zukunft wird immer ungewiss bleiben - auch mit einem Projektmanagementtool! Ein Projektplan ist daher etwas sehr dynamisches und sollte in einem Steuerungsprozess ständig wieder an die neuen Gegebenheiten der Realität angepasst werden. Dies ist nicht ein Zeichen mangelnder Erfahrung, sonder ein Akzeptieren der Realität! Controlling setzt sich schließlich zusammen aus "Planen", "Kontrollieren" und "Steuern".

Sie sollten immer auch einen Plan B und ggf. auch einen Krisenplan in der Tasche haben. Gemäß Iacocca in [B6] sollte man schließlich nie eine Entscheidung treffen, wenn man nicht mindestens die Wahl zwischen Vanille und Schokolade hat. Es hat sich tatsächlich gezeigt, dass Menschen mehr riskieren, wenn sie glauben, dass die Zukunft vorherbestimmbar ist. Dies wirkt sich auch auf Projekte aus, die mit scheinbar viel Erfahrung und tausenden von Teilvorgängen minutiös im voraus geplant werden. Ich erinnere hier gerne noch mal an den Spruch meiner Seite Design der Modelle: "Je planmäßiger die Menschen vorgehen, desto wirksamer trifft sie der Zufall!"

Wenn Sie eine hinreichend große Zahl von Vorgängen haben (oft haben Projekte deutlich mehr als 200 Vorgänge) und die Vorgänge eine gleichmäßige Granularität besitzen, können Sie ja mal das ganze Projekt mit allen Vorgängen über die gesamte Laufzeit auf eine einzelne DIN A4 Seite drucken und den Verlauf der Kurve betrachten:

Der erste Verlauf ist top, weil Sie viel am Anfang des Projekts weghauen und das Risiko am Ende auf wenige Vorgänge konzentriert ist. In der Praxis ist dies eher unrealistisch und daher immer verdächtig. Der mittlere Verlauf ist optimal, weil die Vorgänge (und höchstwahrscheinlich auch der Ressourceneinsatz) gleichmäßig über das Projekt verteilt sind. Der rechte Verlauf ist leider sehr oft zu sehen: am Anfang läuft die Zeit weg und am Ende schieben sich alle Vorgänge zusammen. Ich habe in einem solchen Projekt mal nach dem ersten Drittel der Zeitachse eine Krisensitzung einberufen und die Projektleitung niedergelegt (es ging um sehr viel und war obendrein abhängig von der Verabschiedung von Gesetzestexten mit der Umsetzung der dazugehörigen technischen Anlagen). Zum Glück war der Auftraggeber sehr einsichtig und hat das Projekt direkt eingestampft. Ein Jahr später war die Gewissheit da, das dieses Projekt niemals hätte erfolgreich beendet werden können.

Das nebenstehende Beispiel zeigt ein Projekt (bei dem ich Projektleiter war) mit knapp 150 Vorgängen über fast zwei Jahre, bei dem es zu Verschiebungen durch notwendige technische Reviews kam: Das eingesetzte Framework sowie die Basisprodukte wurden durch das Projekt sehr strapaziert und so musste mehrmals angepasst werden. Nachdem wir die Technik im Griff hatten, kamen in den letzten Iterationsstufen noch Änderungswünsche des Kunden hinzu, so dass es mit geringerem Tempo voranging. Nach der Präsentation dieser Graphik auf der großen Chill-Out-Party am Projektende sprachen auch die Entscheider von einem erfolgreichen Projektverlauf - trotz der Verschiebungen!

Sie sollten übrigens bei aktiver Steuerung des Projekts schon direkt nach dem Tailoring des Vorgehensmodells den Projektplan aufstellen, also so früh wie möglich. Sie wissen dann ja schon, ob Sie viel am Projektanfang in einer dedizierten Analysephase analysieren oder ob Sie alle Analysen an die Anfänge der Konstruktionsiterationen legen. Sie wissen auch schon, ob Sie eine umfangreiche Endabnahme haben werden oder stattdessen Zwischenabnahmen am Ende einer jeden Iterationsstufe. Sie wissen also schon eine Menge wesentliche Vorgänge und Meilensteine. Wenn Sie so früh schon den Projektplan aufstellen, können Sie auch bereits so früh äußere Fixtermine als Meilensteine oder Vorgänge eintragen, z.B. Messeauftritte, operative Engpässe beim Kunden, Weihnachten, etc. Auch die Vorgänge, die es in jedem Softwareentwicklungsprojekt gibt, wie beispielsweise das erste Aufsetzen der technischen Infrastruktur (inkl. Datenbankschema), die Einarbeitung der Kunden-Admins oder Projektlenkungskreissitzungen, können bereits früh geplant werden. Überhaupt sollten Sie als Analytiker gerade in den ersten kontaktintensiven Phasen die Kundentermine so früh wie möglich planen: Wenn Sie bereits mehrfach Geschäftsprozessanalysen, wie ich sie hier in dieser Abhandlung beschreibe, in Projekten durchgeführt haben und daher wissen, das Sie mindestens fünf Kundentermine dafür benötigen, dann sollten Sie nicht warten, bis die Termine jeweils fällig sind, sondern bereits ganz am Anfang alle Kalender zusammenlegen und diese fünf Termine festzurren. So lässt sich die Dauer der Phase verkürzen und auch zuverlässiger planen. Durch das Fixieren von Eckdaten über die gesamte Projektdauer ergibt sich ein Raster, welches auch die Planung der Konstruktionsiterationen vereinfacht und Sie können dann aus dem Projektplan auch einen Releaseplan oder einen Einsatzplan viel einfacher ableiten. Schließlich können Sie auch die geschätzten Aufwände der Anwendungsfälle direkt in den Projektplan eintragen und daraus die Kosten für die zugrunde liegenden Anforderungen ableiten. Durch eine frühe Planung können Sie insbesondere auch früh herausfinden, ob Sie sich in einem "Scheißprojekt" [L10] befinden ;-)

Sie sollten anhand des Projekttyps (s. Tailoring) am Anfang entscheiden, ob Sie die Vorgänge basierend auf der Arbeit oder der Dauer (Informationen zum Vorgang / Spezial / Vorgangsart: "Feste Arbeit" oder "Feste Dauer") eintragen. Wenn Sie ein starres Iterationsraster planen und Termine als äußere Zwänge haben, sollten Sie verstärkt mit Meilensteinen arbeiten und auf der Basis der Dauer kalkulieren. Wenn Sie das Projekt hingegen anhand des Inhalts steuern und nicht so terminlastig unterwegs sind, sollten Sie die Vorgänge besser anhand der erforderlichen Arbeit kalkulieren und dann über eine prozentuale Zuordnung der Ressourcen (Informationen zum Vorgang / Ressourcen / Einheiten-Spalte) die Dauer mitsamt der echten Kosten automatisch berechnen lassen. Wenn Sie dann noch die Kosten-Spalte einblenden, können Sie auch die echten finanziellen Aufwände der Sammelvorgänge immer auf einen Blick sehen. Bei Korrekturen können Sie dann die Arbeit oder Einheit der Ressource beeinflussen und erhalten immer wieder die korrekten Dauern und Kosten berechnet.

Wenn Sie dann noch Abhängigkeiten zwischen den Vorgängen definieren (mit dem Verkettungssymbol), werden bei Änderungen an den Vorgängen auch alle abhängigen verknüpften Vorgänge korrekt verschoben. Ich warne allerdings davor, in eine Verknüpfungseuphorie zu verfallen und zu versuchen, möglichst viele Vorgänge miteinander zu verknüpfen. Die ordentliche Pflege eines Plans ist eine Menge Handarbeit; so definiere ich immer eine Menge Meilensteine (beispielsweise "GO" für eine Konstruktionsiteration, "Code Complete" für den Beginn des Codetests, "Close Shop" für das Brennen eines neuen Builds, "Gold" für den Übergang an den Kunden oder "Point of no Return" für die erste Pressekonferenz). An diese Meilensteine verknüpfe ich dann immer eine Handvoll Vorgänge, damit ich sie mit dem Meilenstein zusammen von Hand verschieben kann. Dies führt durch die Konzentration auf die Meilensteine zu einer strikt ergebnisorientierten Arbeitsweise und stellt bei der Toolarbeit meines Erachtens einen guten Kompromiss aus automatischer Unterstützung und bewusster Handarbeit dar.

Sie sollten noch beachten, dass Microsoft Project keine Feiertage kennt und diese frühzeitig eintragen. Ich habe wegen diesem Patzer meinem Team dieses Jahr Ostern versaut. Der Reaktion nach wird mir das nicht noch mal passieren ;-)

Über das Management von Terminen, Ressourcen, Kosten und Vorgängen hinaus sollten Sie einfach auch mal prüfen, welche der folgenden offenen Fragen (W-Fragen) Ihr Projektmanagementtool beantworten kann; das hilft bei der realistischen Einordnung eines solchen Tools:

  Wann wird dieses Projekt wirklich fertig sein?
  Was wird dieses Projekt wirklich kosten?
  Worin besteht die Leistung dieses Projekts?
  Welche Prioritäten gibt es in diesem Projekt?
  Welchen Teil des Geschäftsmodells des Auftraggebers deckt dieses Projekt ab?
  Welche Rolle spiele ich in diesem Projekt?
  Wer ist alles wann an diesem Projekt beteiligt?
  Welche Bedeutung hat dieses Projekt für die Beteiligten?
  Welche Prozesse welcher Iterationsstufen werden wann von wem durchlaufen?
  Worin unterscheidet sich dieses Projekt von den anderen?
  Welche Kennzahlen liefert mir dieses Projekt zur Abschätzung späterer Projekte?

Sie werden feststellen, dass Sie auch mit Projektmanagementsoftware kein Schema F für alle Fragen finden werden, denn jedes Projekt, jeder Kunde und jeder Mitarbeiter ist anders - und das ist gut so, denn das macht die Projekte interessant!

Der Umgang mit Projekten ist übrigens ein ganz anderer, als wir es von Komsumerprodukten mittlerweile gewohnt sind: Während unser Zuhause, unser Auto und unsere sonstige Umgebung mehr zum Selbstporträt wird, das unseren Lebensstil widerspiegelt und wir mit den Produkten eigentlich eher eine Geschichte kaufen, die zu uns passt (und dann die Armbanduhr als "Seamaster Chronometer" oder das Auto zur "Freude am Fahren" dazu bekommen), werden in Projekten die Anforderungen aus verschiedenen Geschäftsbereichen zu einem messbaren und bewertbaren Ziel montiert. Bei dieser Objektivität und Fremdsteuerung ist in den Projekten darauf zu beachten, dass für die Projektteilnehmer die Arbeit dennoch eine Herausforderung darstellt, die mitsamt der Unternehmenskultur zu den persönlichen Werten passen und eine weitere Geschichte darstellten muss; denn die Bezahlung stellt heute längst nicht mehr alles dar, was anspruchsvolle Menschen von ihrem Lebensstil im Alltag erwarten. In dem Essay 3 von [B26] wird "Die Ära der Geschichtenerzähler" sehr interessant dargestellt.