Im Kapitel 1.1 haben wir bereits definiert, was ein Projekt nach DIN ist. Damit entsteht in unserem Kopf eine gewisse Klarheit. Sie schützt uns davor Fehler zu machen, wenn wir unüberlegt losarbeiteten.

Erschwerend kommt hinzu, dass Sie auch mal ein Projekt bekommen, die Sie gar nicht überblicken können. Konsequenz: Ahnungslosigkeit und Unverständnis lassen das Projekt scheitern oder wie es allgemein gesagt wird: „Sage mir wie dein Projekt beginnt und ich sage dir, wie es endet“[1].

Aus diesen Überlegungen heraus ist es sinnvoll, vor der Projektbeauftragung festzustellen, was wir für ein Projekt vor der Nase haben. Dies ermitteln wir mittels sog. Dimensionen wie Projektgröße, Projektlänge, wer der Kunde ist, der Projektart und der Projektorganisation.

Sicher gibt es auch weitere Kriterien, aber wenn Sie diese fünf vor dem Projekt wissen, sind Sie gewappnet.

Betrachten wir die Dimensionen näher.

• Projektgröße (klein, mittel, groß)’Nicht die absolute Größe des Budgets ist hier gemeint, sondern das Niveau. Je geringer das Budget desto übersichtlicher ist die Aufgabe.

• Projektlänge (klein, mittel, groß)
  Es gibt keine verbindlich Einteilung, wann ein Projekt als z. B. „klein“ zu bezeichnen ist. Ich habe für mich die Einteilung gewählt: bis drei Monate (klein), bis sechs Monate (mittel) und darüber hinaus (groß).

• Kundenprojekt (extern, intern)
  Basiert das Projekt auf einen Kundenwunsch? Kunde können von extern, aber auch von intern kommen. Obwohl diese Einteilung keine Rolle in der Bearbeitung des Projektes spielt, wird damit oft abgeleitet, dass externe Projekte wichtiger sind, weil sie von einem Kunden bezahlt werden.

• Projektart
  Projekte werden nach dem Projektgegenstand eingeteilt: Wird eher eine Sachanlage gebaut (Investitionsprojekt) oder muss das Unternehmen umgebaut werden (Organisationsprojekt) oder haben wir ein Forschungs- und Entwicklungsprojekt vor uns?

• Projektorganisation
  Es wird unterschieden, welche Weisungsbefugnis der Projektleiter hat und wie viel Zeit die Kernteammitglieder im Projekt arbeiten (Einfluss-, Matrixprojektorganisation, Autonome Projektorganisation).

Beispiel Lagerhalle

Beim Bau einer neuen Lagerhalle eines 35-Mann Betriebes in Brandenburg sieht die Bewertung folgendermaßen aus:

• Projektgröße: groß
• Projektlänge: mittel
• Kundenprojekt: intern
• Projektart: Investitionsprojekt
• Projektorganisation: Matrix

Mit welchem Projekt sollten Sie als Anfänger beginnen? Ich empfehle immer meinen Schulungsteilnehmer als erstes einen Drucker zu kaufen. In der obigen Einteilung hieße das: kleine Projektgröße und –länge, internes Investitionsprojekt und eine Einflussorganisation. Zusammengefasst: es ist einfach, übersichtlich und wir werden weniger Fehler machen!

Die Initialisierungsphase kann über Jahre gehen und Millionen kosten. Nämlich dann, wenn das danach folgende Projekt die entsprechende Größe hat.

Darüber hinaus ist noch in Erweiterung des bisherigen Einzelprojektbezugs die Auswahl der Projektideen eines Unternehmens zu betrachten.

Die nachfolgenden Aufgaben für die Initialisierungsphase sind eine Sammlung von Aufgaben, die nicht immer und in jedem Projekt vorkommen:

• Machbarkeitsstudie
• Pflichten- und Lastenheft
• Make-or-Buy.

Am Ende der Initialisierungsphase müssen alle Informationen vorhanden sein, damit eine Projektbeauftragung möglich ist.

Betrachten wir die Aufgaben näher.

Machbarkeitsstudie

Eine Machbarkeitsstudie ist manchmal die Grundlage für ein internes Projekt. Daher muss sie in der Initialisierungsphase erstellt werden. Man kann sich aber gut vorstellen, dass die Machbarkeitsstudie selbst so groß ist (z. B. für ein neues Automodell), dass sie als eigenes Projekt bearbeitet wird.

Pflichten- und Lastenheft

Soll ein Projekt auf einen Vertrag mit einem externen Kunden basieren, ist es wichtig, eine genaue Beschreibung des Vertrages zu haben. Dafür dienen Pflichten- und Lastenheft.

• Lastenheft
  Im Lastenheft beschreibt der Kunde „was“ erstellt werden soll und „wofür“.
  Das Dokument kann in einer einfachen, muss aber vor allem in der Sprache des Kunden erstellt werden.
  Es ist durchaus möglich, manchmal sogar sinnvoll, dass ein Berater den Kunden bei der Erstellung des Dokuments hilft (natürlich gegen eine angemessene Aufwandsentschädigung). Nicht sinnvoll ist es, dass der mögliche Lieferant dies tut. Der Lieferant wird dem Kunden beschreiben, was er liefern möchte, nicht was der Kunde braucht.

• Pflichtenheft
  Das Pflichtenheft ist der Realisierungsvorschlag des Auftragnehmers auf Grund des Lastenheftes.

Beide Dokumente werden bei der späteren Projektbeauftragung einen Teil der Rahmenbedingungen ausmachen.

Wenn das Pflichten- und Lastenheft abgestimmt sind, werden sie Bestandteil eines Vertrages. Durch Angebot und Annahme entsteht ein Vertrag zwischen dem Kunden (externes Unternehmen / Organisation) und dem liefernden Unternehmen.

Dieser Vertrag darf nicht mit der Projektbeauftragung verwechselt werden!

Make-or-Buy

Eigentlich stammt die Entscheidung die Software selbst zu erstellen oder einzukaufen aus den 1980er – 90er Jahren. Damals war Standardsoftware noch nicht so verbreitet wie heute. Nachdem aber immer mal wieder Seminarteilnehmern von dieser Entscheidung berichten, habe ich sie aufgenommen.

Manchmal ist es sinnvoll, nicht auf Standardsoftware zurückzugreifen; insbesondere dann, wenn Ihre Businessprozesse so besonders sind, dass Standards sie nicht abbilden können.

[1] Andere PM Sprüche finden Sie unter [PM SPRÜCHE]

Nach dem Roten Faden findet die Initialisierungsphase vor dem Projekt statt. Sie hat die Aufgabe, den Projektauftrag vorzubereiten. Mit dem Projektauftrag wird das Projekt gestartet.

Ich werde Ihnen in den nachfolgenden Phasen sämtlich Tätigkeiten aufzählen, die benötigt werden. Dabei unterscheide ich die Menge an Informationen nach der Bedeutung für das Projektmanagement.

Kernteam zusammenstellen

Das Kernteam sind die Mitarbeiter des Projektmanagers – die Mannschaft, die das Projekt vom ersten bis zum letzten Tag begleitet, alle Arbeiten planen und steuern werden.

Daher ist es notwendig sehr sorgsam die Auswahl der Mitarbeiter zu betreiben. Doch nach welchen Kriterien sollten wir das Kernteam zusammenstellen? Grundsätzlich ist es sinnvoller, erst sachliche Aspekte zu betrachten und dann soziale.

Der Projektleiter wird sich mehrere Rollen überlegen und diese Rollen beschreiben müssen: Tätigkeiten, Fähigkeiten und Befugnisse. Mit dieser Beschreibung geht der Projektleiter zu den entsprechenden Linienvorgesetzten und lässt sich die in Frage kommenden Mitarbeiter „zeigen“.

Gibt es die Chance, dass mehrere Mitarbeiter zur Auswahl stehen, sollte der Projektleiter dann nach sozialen Erwägungen entscheiden.

Beispiel Kernteam

Wir befinden uns in einem Marketingprojekt. Der Projektleiter braucht für sein Kernteam einen Mitarbeiter, der sich mit Facebook-Kampagnen auskennt. Es ist sinnvoll, diese Anforderung deutlich aufzustellen.

Sollte die Anforderung an einen Mitarbeiter nicht klar sein, wird der Linienvorgesetzte in der Marketingabteilung vermutlich denjenigen in das Projekt schicken, der entbehrlich ist.

Ob dieser Mitarbeiter seine Projektmanagementaufgaben erfüllen kann, ist fraglich.

Im Zuge der Mitarbeiterauswahl muss geklärt werden, in welcher Projektorganisationsform gearbeitet wird. Die Projektorganisation unterscheidet im Wesentlichen die Länge der Arbeitszeit der Kernteammitglieder und die Weisungsbefugnis des Projektleiters.

• Autonome Projektorganisation
  Die Kernteammitglieder wie der Projektleiter arbeiten zu 100% im Projektmanagement. Der Projektleiter hat disziplinarische Weisungsbefugnis.

• Matrix-Projektorganisation
  Die Kernteammitglieder arbeiten nur zu einem Prozentsatz kleiner 50% im Projektmanagement. Der Projektleiter hat fachliche Weisungsbefugnis.

• Einfluss-Projektorganisation
  Die Kernteammitglieder arbeiten nur zu einem Prozentsatz weniger als 10% im Projektmanagement. Der Projektleiter hat keine Weisungsbefugnis. Er muss sein Team so führen, dass es mit ihm „freiwillig“ zusammenarbeiten will.

Für klein und mittelständische Unternehmen wird selten bis nie die autonome Projektorganisation sinnvoll sein. Diese Unternehmen haben zu wenige Mitarbeiter, um sie zu 100% in die Verwaltung von Projekten zu stecken. In Deutschland treffe ich am häufigsten die Matrixorganisation an.

Bei der Auswahl der Kernteammitglieder sollte der Projektleiter darauf achten, dass die Mitarbeiter die eigenen Schwächen ausgleichen. Prüfen Sie, was Sie können, und seien sie mutig auch zuzugeben, dass Sie Bereiche haben, die nicht Ihre Stärke sind. Selbstreflexion gehört zu den Stärken eines Projektleiters. Für die Auswahl nach sozialen Aspekten bieten sich einige Rollenmodelle an: Belbin[1], Quinn[2] oder das DISG persolog[3].

Regelkommunikation im Projekt

Ab dem ersten Tag eines Projektes muss der Projektleiter aus dem Projekt berichten. Anfänglich sind die Adressaten der Projektbeauftrager, die neuen Mitarbeiter und vielleicht ein externer Kunde. Im weiteren Verlauf des Projektes werden weitere Adressaten dazu kommen.

Schaffen Sie sich Templates an, um Ihre Berichte zu standardisieren. Der bekannteste Bericht ist der Projektstatusbericht. Er ist ein hochverdichteter, einseitiger Bericht und wird häufig mittels Ampeln oder Cockpit-Graphiken visualisiert.

Ein guter Projektleiter plant sein Berichtswesen von Anfang an. Damit ist gewährleistet, dass alle am Projekt interessierten Menschen genau die Informationen erhalten, die sie wünschen oder benötigen.

Im Berichtsplan werden

• alle Interessierten aufgeführt,
• die zu vermittelnden Informationen und
• die Art der Übermittlung

geplant. Nutzen Sie dabei moderne Kommunikationswege. Persönliche Berichte kosten viel Zeit (Beispiel: Sie arbeiten in Berlin und müssen in München reporten).

Woher wissen Sie, welches die richtigen Informationen sind für einen bestimmten Menschen. Fragen Sie ihn, aber schlagen Sie ihm dabei einen Informationsumfang vor, den Sie bewältigen können.

Umfeldanalyse

Jetzt haben wir uns genug mit uns selbst beschäftigt, schauen wir uns das Umfeld unseres Projektes an.

Ein Projekt arbeitet nicht im luftleeren Raum. Es hat viele Schnittstellen zu anderen Akteuren. Akteure können Menschen sein, Organisationen, Gesetzte und Verordnungen oder das Wetter. Ich benutze absichtlich den Begriff Akteur, um eine gewisse Abstraktionshöhe in diesem Werkzeug zu erreichen.

Häufig konnte ich beobachten, dass sich Kernteams sehr schnell in Details verlieren und damit Dinge / Akteure übersehen.

Beispiel Hausbau

Sie errichten ein Einfamilienhaus und entdecken in der Umfeldanalyse, dass Sie Genehmigungen brauchen. Vermutlich fällt Ihnen sofort das Bauamt ein – oder sogar gleich Frau Müller vom Bauamt. Wenn Sie sich im weiteren Verlauf des Projektes auf diese Dame konzentrieren, übersehen Sie, dass Ihr Haus im Wasserschutzgebiet liegt oder eine Straßenanbindung notwendig ist.

Um nichts zu übersehen gestalten wir die Umfeldanalyse so, dass sie sehr abstrakte Umfelder findet: nicht das Bauamt, sondern die darüber liegende Gemeinde ist ein gutes Umfeld.

Nach dem Sammeln der Umfeldern teilen wir sie gleich auch in Kategorien ein:

• Soziale und sachliche Umfeldfaktoren
  • Soziale Umfeldfaktoren sind die Menschen in unserem Projekt. Zur Unterscheidung zu den sachlichen Umfeldfaktoren sage ich immer, das sind die, denen die Projektleitung den Bauch streicheln kann.
  • Sachliche Umfeldfaktoren lassen sich in unterschiedliche Kategorien aufteilen: ökologische, technische, gesetzliche u.a.
• Interne und externe Umfelder
  • Interne Umfeldfaktoren sind alle die, die zur Organisation des Projektleiters gehören (das eigene Unternehmen). Sie werden gerne, wie bei den Schildbürgern, übersehen.
  • Externe Umfeldfaktoren sind der Rest.

In welcher Verteilung die Umfeldfaktoren vorkommen, hängt völlig vom Projekt ab und ist nicht vorhersehbar. Scheuen Sie sich nicht, viele Umfelder zu finden. Die Umfeldanalyse ist eine Sammlung. Ob Sie später die richtigen Umfelder gefunden haben, wird sich in den folgenden Arbeitsschritten zeigen.

Soziale Umfeldfaktoren werden im Stakeholdermanagement und sachliche Umfeldfaktoren im Risikomanagement bearbeitet.

Stakeholdermanagement

Den Begriff Stakeholder werden Sie bereits gehört haben[4].

Lt. DIN-Norm 69901-1:2009 sind Stakeholder interessierte Parteien, und wie folgt definiert:

Stakeholder sind Personen oder Personengruppen, die

• am Projekt beteiligt sind,
• am Projektverlauf interessiert sind oder
• vom Projektergebnis betroffen sind.

Jedes der größeren Projektmanagementwerkzeuge hat ein eigenes kleines Vorgehensmodell. Das ist beim Stakeholdermanagement auch so. Wir unterscheiden die Arbeitsschritte: Stakeholder ermitteln, Stakeholderinformationen sammeln und analysieren, Maßnahmen entwickeln und Monitoring.

• Stakeholder ermitteln
  Beim Ermitteln, welche Stakeholder am Projekt beteiligt sind, nehmen wir die Umfeldanalyse in die Hand und gehen ins Detail.

Beispiel Stakeholderermittlung

Beim Bau eines Spielplatzes für eine Kita haben wir festgestellt, dass die Anrainer (die Bewohner rund um den zukünftigen Spielplatz) ein soziales Umfeld sind. Jetzt müssen wir überlegen, ob es ausreicht, die Anrainer als Personengruppe gemeinsam zu sehen oder ob es Einzelpersonen gibt, die anders denken als der Rest.

• Sammeln Sie so viele Stakeholder wie möglich, nur wenn wir sie erkennen, können wir sie in die spätere Maßnahmenplanung einbeziehen.
• Stakeholderinformationen sammeln und analysieren

In diesem Teil geht es darum zu bestimmen, welches Interesse die Stakeholder an unserem Projekt haben werden.

Wie bekomme ich die Informationen? Fragen Sie die Stakeholder! Bisher hat noch jeder Stakeholder eine vernünftige Auskunft gegeben, wenn ich vernünftig gefragt habe.

Allerdings benötigen wir viel Zeit (nicht unbedingt viel Arbeit) für diese Stufe des Projektmanagements. Oft müssen wir mit den Menschen persönlich sprechen, was Terminabsprachen und Reiserei bedeutet.

Mittels der Analyse stellen wir fest, wieviel Einfluss (manchmal wird auch „Macht“ gesagt) die Stakeholder auf unser Projekt haben. Einfluss bedeutet, dass der Stakeholder das Projekt stark verzögern oder gar stoppen kann. Allerdings muss nicht jeder auch den Wunsch haben seine Macht auszuüben (Einflusswille). Dafür gibt es Stakeholder, die keinen Einfluss haben, aber einen starken Willen am Projekt beteiligt zu sein. Auch dies müssen wir analysieren.

• Maßnahmen entwickeln
  Stakeholdermaßnahmen sind teuer. Deshalb ist es sinnvoll, die Stakeholder einzuteilen, um die knappe Ressource Geld sinnvoll einzusetzen. Wir nutzen dazu das Stakeholderportfolio. Das Stakeholderportfolio ist ein 4-Quadranten-Diagramm mit den Achsen Einfluss und Einflusswille.

Durch die Clusterung der Stakeholder ergeben sich unterschiedliche Mengen an Stakeholder in den Quadranten I – IV. Je Quadrant sind unterschiedlich Maßnahmen vorgesehen.

Abbildung 4: Stakeholderportfolio mit Stakeholder (als A – K nummeriert)

• Quadrant I
  informieren durch moderne Kommunikationsmittel
  Beispiel: Projekt-Website

• Quadrant II
  persönliche Betreuung, ohne die Stakeholder in Entscheidungsaktivitäten zu involvieren
  Beispiel: Baustellenbesichtigungen

• Quadrant III
  wir sehen Stakeholder als Partner im Projekt an und involvieren sie in unsere Entscheidungen
  Beispiel: Kaminabende im Adlon Hotel

• Quadrant IV
  Umgang mit Stakeholdern erfordert Konfliktmanagement
  Beispiel: öffentliche Anhörung

• Monitoring
  Während der Laufzeit des Projektes muss regelmäßig geprüft werden, ob die Maßnahmen die gewünschten Auswirkungen bei den Stakeholdern haben.

Risikomanagement

Auf Grund der Ableitung der sachlichen Umfelder aus der Umfeldanalyse, können wir mit dem Risikomanagement beginnen.

Viele Projektmanagementsysteme betreiben hier einen erheblichen Aufwand. Wichtig ist vor allem aus meiner Sicht überhaupt Risiken zu finden und ihre Auswirkungen zu akzeptieren. Berufsanfängern fällt dies auffällig oft schwer.

Das Risikomanagement ist eine strukturierte Aufgabe und hat mehrere Stufen:

• Risiken analysieren
  Zuerst müssen wir die Risiken erkennen und benennen. Die Arbeit wird uns durch eine Einteilung in handhabbare Kategorien wie kaufmännische, technische, terminliche oder Ressourcenrisiken erleichtert.

• Risikowerte berechnen
  Risiken lassen sich durch die Eintrittswahrscheinlichkeit (in %) und die Tragweite (in €), das ist die monetäre Auswirkung des Schadens, bewerten. Die Multiplikation beider Werte ergibt den Risikowert in Euro. Durch die Höhe jedes Risikowertes erkennen wir die auswirkungsreichsten Risiken des Projektes.

Beispiel Risikoermittlung

Beim Bau des o.g. Spielplatzes ergeben sich folgende Risiken:

• Maßnahmen planen
  Jedes Risiko hat genau eine Maßnahme, die am sinnvollsten ist. Um die richtige Maßnahme entwickeln zu können, bedienen wir uns des Risikoportfolios, dass genauso aussieht wie das Stakeholderportfolio, aber die Achsenbenennung Eintrittswahrscheinlichkeit und Tragweite hat.

• Quadrant I
  Risikostrategie akzeptieren: keine Maßnahmen zur Risikoeindämmung

• Quadrant II
  Risikostrategie übertragen: die hohe Tragweite wird mittels Versicherungen oder Verträge auf Dritte übertragen

• Quadrant III
  Risikostrategie vermeiden: Eintrittswahrscheinlichkeit und Tragweite sind so hoch, dass wir den Risikoeintritt auf keinen Fall stattfinden lassen dürfen

• Quadrant IV
  Risikostrategie vermindern: die Tragweite ist gering, aber die Eintrittswahrscheinlichkeit ist zu hoch, wir müssen sie vermindern

Abbildung 5: Risikoportfolio mit Beispiel-Risiken

• Restrisiko bewerten
  Bei den Strategien „akzeptieren“ und „vermindern“ bleibt ein Rest an Risiko übrig. Dieser Rest kann uns Geld kosten. Das Restrisiko kann aber nicht beplant werden, da es ja nicht eintreten muss. Daher eröffnen wir eine Art Schattenkasse, Risikobudget genannt, das allerdings wie das normale Budget vom Projektbeauftrager genehmigt werden muss.
  
  Das Risikobudget muss immer gesondert ausgewiesen werden und darf nicht im Gesamtbudget abhandenkommen. Dieser Budgettopf kommt nur zur Anwendung, wenn die restlichen Risiken doch eintreten.
  Das Projektbudget sollte nicht mehr als 10% bis 15% des Gesamtbudgets betragen.
  
  

• Maßnahmen einplanen
  Sobald wir die Strategie bestimmt haben und damit auch die passende Maßnahme, muss die Maßnahme geplant, budgetiert und in die Projektmanagementaktivitäten aufgenommen werden.

Zielsystem erstellen

Ein Ziel ist ein in der Zukunft gewünschter Zustand. Dieser Zustand muss erarbeitet werden und kostet damit Ressourcen, Zeit und damit Geld. Je genauer ich weiß, welchen Zustand wir uns erarbeiten müssen, desto besser kann ich meine Aktivitäten darauf abstimmen. Allerdings muss der Einsatz der Ressourcen effizient sein.

Die Ziele eines Projektes lassen sich in vier Kategorien einteilen:

• die Ecken des magischen Dreiecks (Zeit, Kosten, Leistung) sowie
• die sozialen Interessen der Stakeholder.

Diese Ziele müssen untersucht und vergleichbar gemacht werden.

Es gibt eine anerkannte Methode zur Beschreibung von Zielen: die SMART-Methode. Die SMART-Methode erfüllt den Anspruch, Ziele operationable zu machen.

SMART ist ein englischsprachiges Akronym:

Abbildung 6: Das Akronym SMART

Es werden häufig auch andere Begriffe verwendet und dann auch noch ins Deutsche übersetzt oder interpretiert[5].

In meiner Praxis hat sich die folgende Interpretation als hilfreich bewiesen:

• S (engl.: specific): Das Ziel muss eindeutig beschrieben sein. Es dürfen keine Interpretations-spielräume bleiben.
• M (engl.: measurable): Das Ziel muss gemessen werden können. Am einfachsten wird es, sich eine Gleichung vorzustellen. Links vom Gleichheitszeichen steht das Messkriterium und rechts der Wert, den er annehmen soll (Beispiel: Temperatur = 25°; Luftfeuchtigkeit <= 45%; Fenster > 6).
• A (engl.: achievable): Das Ziel muss in der Projektlaufzeit erreicht werden. Danach ist der Projektleiter nicht mehr verantwortlich und kann nichts mehr zur Zielerreichung beitragen.
• R (engl.: relevant): Das Ziel muss von hoher Bedeutung für das Projekt sein. Besonders Stakeholder bringen ihre Interessen am Projekt ein, bewerten diese aber öfters zu hoch. Unsere Aufgabe ist es, diese Interessen für das Gesamtprojekt zu bewerten.
• T (engl.: timely): Der Zeitpunkt, an dem die Zielerreichung erstmals überprüft werden kann.

Ein Beispiel für ein „SMART“es Ziel finden Sie im Kapitel 10.4.

Die Interessen, welche die Überprüfung mit SMART bestehen (sie sind messbar, in der Projektlaufzeit erreichbar und von hoher Bedeutung) werden als Projektziele bezeichnet.

Projektziele sind die nach außen darstellbare Ziele, nach denen unser Projekterfolg am Ende bewertet werden wird. Damit alle Stakeholder ein gleiches Verständnis zu diesen Zielen haben, ist der Prozess inkl. der Veröffentlichung notwendig.

Phasenplan erstellen

Nachdem wir bereits viele Dinge erarbeitet haben, benötigen wir jetzt eine zeitliche Einteilung unseres Projektes. Der Phasenplan ist die grafische Darstellung einer sehr groben Abfolge von Aufgabenblöcken in Kombination mit Meilensteinen.

Eine Projektphase ist ein grober Abschnitt des Projektes, der sowohl inhaltlich wie zeitlich von anderen Abschnitten unterschieden werden kann[6]. Als erste Phase sollte immer mind. eine Projektmanagementphase vorhanden sein (Definitions- und Planungsphase oder eine zusammengefügte Phase). Das Projekt wird durch die Projektmanagementphase Abschlussphase beendet. Dazwischen liegen die fachorientierten Phasen des Projektes (Beispiele: Bauausführung, Herstellung, Einführung, Roll-out, Installation oder Service und Betreuung).

Fünf bis acht Phasen haben sich in der Praxis bewährt.

Ein Meilenstein ist ein Ereignis von besonderer Bedeutung[7]. Es gibt zwei Meilensteine, die immer benannt werden: der Projektstarttermin und der Projektendetermin. Meilensteine haben ein Datum (im Phasenplan sehr grob) und sind in Zielsprache formuliert. Zielsprache bedeutet, dass wir den Abschluss eines Ereignisses / Vorgangs heraushören können.

Nachdem wir Phasen und Meilensteine benannt haben, erstellen diese Graphik:

Abbildung 7: Phasenplan mit Phasen und Meilensteinen

Zum aktuellen Zeitpunkt sind seit Projektbeginn bestimmt einige Tage, manchmal auch Wochen vergangen. Trotzdem haben die Kernteammitglieder unterschiedliche Vorstellungen, wie das Projekt abgearbeitet wird. Mit der Erstellung des Phasenplans werden diese Vorstellungen vereinheitlicht.

Woher kommen die Unterschiede in der Vorstellung?

Die Menschen sind unterschiedlich ausgebildet / geschult und haben unterschiedlich viel Berufs-erfahrungen gesammelt – damit denken sie auch unterschiedlich. Manche können in rein sequenzieller Art Abläufe betrachten, andere denken (und tun) alles auf einmal. Genau die richtige Mischung macht es!

Beispiel Entwicklung eines Handys

Muss ich in meinem Projekt ein Handy entwickeln, kann ich mit dem Marketing beginnen, wenn ich die ersten Informationen dazu habe (einige technische Features + ein Bild vom Gehäuse), aber nicht sofort mit dem Entwicklungsstart.

Die Zusammenhänge werden im Phasenplan das erste Mal besprochen und geklärt und sind Grundlage für die Detaillierung während des 2. Teils – der Projektplanung.

In der nächsten Phase erkläre ich Ihnen die Werkzeuge, von denen Sie bisher vermutet haben, das sei Projektmanagement. Nehmen Sie sich aber in Ihren Planungen ausgiebig Zeit die vorgenannten Projektmanagementmaßnahmen durchzuarbeiten. Alles Folgende basiert auf dem aktuellen Wissensstand!

[1] [WIKIPEDIA], Belbin

[2] [QUINN], Quinn

[3] [PERSOLOG]

[4] Bitte verwechseln Sie Stakeholder nicht mit Shareholder; das sind Anteilseigentümer einer Aktiengesellschaft.

[5] [WIKIPEDIA], SMART

[6] [WIKIPEDIA], Projektphase

[7] [WIKIPEDIA], Meilenstein

In der Planungsphase setzen wir unser Wissen über das Projekt in Zeiten und Kosten um. Dabei fügen wir auch Informationen über die Facharbeit hinzu.

Haben Sie gemerkt? Wir haben uns zuerst nicht um Facharbeit, sondern um viele andere Aspekte des Projektes gekümmert. Und das ist auch gut so! In den meisten Fällen werden die Aspekte der Definitionsphase übersehen und am Ende wundern wir uns, warum keiner das Projekt als erfolgreich ansieht, obwohl wir doch so einen „schönen“ Projektgegenstand gebaut haben.

Projektstrukturplan erstellen

Der Projektstrukturplan (PSP) ist die grafische Darstellung aller Tätigkeiten im Projekt. Er wird als Baumstruktur dargestellt und ist häufig codiert.

Die hierarchischen Elemente eines PSP sind das Wurzelelement, die Teilaufgabe und das Arbeitspaket. Manchmal finden Sie auch die Bezeichnung „Teilprojekt“. Dieses Element kann man bei sehr großen Projekten einbinden, z. B. bei der Besiedlung des Mars (aber wer hat schon solche Projekte vor der Nase).

Die vorgenannten drei Elemente sind folgendermaßen definiert:

• 1. Ebene des PSP: Wurzelelement
  Im Wurzelelement steht der Kurzname des Projektes und die Projektnummer

• 2. Ebene des PSP: Teilaufgabe
  Die Teilaufgabe (TA) teilt Arbeitspakete (und andere Teilaufgaben) und hat selbst keine Tätigkeiten in sich Arbeitspaket

• 2. Ebene des PSP: Arbeitspaket
  Ein Arbeitspaket (AP) ist ein Bündel guthandhabbarer Tätigkeiten, das leicht zu planen und zu steuern ist.
  Jedes Arbeitspaket wird durch einen Arbeitspaketverantwortlichen (APV) verantwortet. Dieser ist für die Planung und die spätere Umsetzung zuständig.

• N. Ebene
  Am Ende jedes PSP Astes dürfen nur noch Arbeitspakete stehen.

Der PSP umfasst in der Regel 20 – 100 Arbeitspakete. Bei größeren Projekten ist es sinnvoll auch mehr Arbeitspakete zu benutzen. Wie viele Ebenen dabei benötigt werden, ist nicht vorherzusagen.

Es gibt unterschiedliche Hilfestellungen, um einen PSP zu erstellen. Der PSP kann

• nach den Teilen des Projektgegenstandes strukturiert werden,
• nach den Funktionen oder
• nach eigenen Kriterien.

Die einfachste und effizienteste Art ist die Phasenorientierung. Alle Phasen im Phasenplan werden weiter benutzt und in Teilaufgaben umbenannt.

Häufig werden Arbeitspakete sehr ähnliche Namen tragen. Um die Identifizierung der APs in einer Multi-Projekt-Umgebung zu erleichtern, sollten Projektstrukturpläne codiert werden. Die an den häufigsten verwendeten Codierungen sind die numerische und die alpha-numerische. Darüber hinaus gibt es noch die alphabetische, die dekadische und Mischformen von Codierungen.

Ab der Ebene 2 des PSP beginnt die Codierung.

• Numerische Codierung
  Bei der rein numerischen Codierung werden die Elemente nur mit Ziffern versehen.
  
  

• Alpha-numerische Codierung
  Es gibt unterschiedliche Arten der Umsetzung. Die einfachste und von mir verwendete, ist die Codierung mit Buchstaben auf der 2. Ebene. Danach wird weiter numerisch codiert.

Ablaufplanung mit Netzplan

Die Netzplantechnik ist eine recht alte Art, einen Projektablauf visuell darzustellen. Mit der DIN-Norm 69900 wurde auch die Netzplantechnik standardisiert.

Nach dieser Norm ist der Netzplan die graphische oder tabellarische Darstellung von Abläufen und deren Abhängigkeiten. Die Netzplantechnik fasst alle Verfahren zur Analyse, Planung, Steuerung und Überwachung von Abläufen zusammen, wobei Zeit, Kosten, etc. berücksichtigt werden können.

Heute wird die Netzplantechnik mittels Software abgebildet, daher werde ich in diesem Buch nicht zu intensiv auf die Möglichkeiten eingehen, die die Netzplantechnik bietet.

Abbildung 9:  Beispiel eines Netzplans

Ich möchte aber die beiden wichtigsten Aspekte darstellen.

• Durchdenken des Projektes
  An manchen Stellen eins Projekts stehen wir da und wissen nicht, was als nächstes zu tun ist. Das gilt sowohl für den Teil des Projektmanagements wie für die Facharbeit.
  
  Den ersten Teil können wir getrost ausblenden, weil wir dafür jetzt eine Methode haben. Für die Facharbeit fehlt uns aber die genaue Kenntnis über die Zusammenhänge.
  
  Wenn wir uns aber die Mühe machen, vor dem Bau des Projektgegenstandes zu überlegen, in welcher Reihenfolge und mit welchen Abhängigkeiten einzelne Aufgaben zu erledigen sind, wird unser Projekt leichter durchschaubar und später leichter steuerbar.
  
  

• Länge des Projektes
  Es ist sehr einfach, im Netzplan die Länge eines Projektes in Projekttage – das sind die Tage an denen gearbeitet wird – zu errechnen.
  
  Das erste Arbeitspaket ist nach seiner Dauer an einem bestimmten Projekttag fertig. Ein fünf Tage dauerndes Arbeitspaket ist auch am 5. Tag fertig. Da die Netzplantechnik auf volle Tage rechnet, kann diese Paket auch am Vormittag fertig sein, somit kann das folgende Arbeitspaket am gleichen Tag beginnen. Addieren Sie nun die Dauer, z. B. drei Tage, dann ergibt sich der Fertigstellungstag für dieses Arbeitspaket von acht.

Selbstverständlich berücksichtigt damit die Netzplantechnik nicht Wochenende, Feiertage oder technische Stillstandstage. Aber sie lässt eine realistische Prognose über die Gesamtlänge zu.

Einsatzmittelplanung

Sie wissen jetzt an welchem Projekttag, welche Arbeitspakete bearbeitet werden. Damit ist es an der Zeit, den Arbeitspaketen Ressourcen zu zuweisen. Wir kennen Personal- und Sachressourcen[1].

• Personalressourcen
  Bei Personalressourcen handelt es sich um die Menschen, die in ihrem Projekt arbeiten – sowohl die Projektmanagementmitarbeiter als auch das Fachpersonal.
  
  Es ist hier insb. zu beachten, dass Sie zwar als Projektmanager diese Ressourcen einplanen können, aber nur die Linienverantwortlichen können die Ressourcen freigeben. Das gleiche gilt auch für Sachressourcen.
  
  Weiterhin geht es zu beachten, dass die Personalressourcen zu ihren tatsächlichen Kosten in das Projekt eingearbeitet werden. Bei internen Mitarbeitern bedeutet dies, dass wir rund 20% auf den Bruttolohn aufschlagen müssen.

• Sachressourcen
  Bei Sachressourcen ist zu beachten, dass es nicht ausreicht, nur den Listenpreis als Kosten in das Projekt mit einzuplanen, sondern auch die damit verbundenen Bestell-, Liefer-, Lager- und Abrechnungskosten.

Es ist ebenfalls notwendig, dafür zu sorgen, dass die Sachmittel auch an der richtigen Stelle sind, wenn wir sie benötigen. Wenn Sie einen Kran benötigen, reicht es nicht aus, dass der Kran in 50 Meter Sichtweite steht, sondern er muss genau an der Stelle zur Verfügung sein, an der die Sachressource auch arbeiten soll.

Die Planung der Ressourcen ist meistens ein längeres Werk. Denn es kann ständig vorkommen, dass Arbeitspakete, die relativ spät im Projekt stattfinden sollen, bereits geplant sind, aber durch das Fehlen von Ressourcen in den vorgelagerten Arbeitstakten neu geplant werden müssen.

Zur Unterstützung insbesondere der Personalressourcen ist es sinnvoll die Personalabteilung mit einzuschalten.

Terminplanung mit GANTT

Die Terminplanung von Projekten wird zumeist mit dem sogenannten GANTT-Diagramm durchgeführt. „Thomas Gantt“[2] war ein US-amerikanischer Ingenieur, der diese Art der Visualisierung von Abläufen erfunden hat.

Ein GANTT-Diagramm ist ein Balkendiagramm, das die Arbeitspakete auf einen Kalender darstellt. Wir erhalten damit eine Visualisierung der Länge des Projektes. Dabei dürfen Sie nicht übersehen, dass die Balkenlänge sich durch Wochenende oder Feiertage verlängert. Es ist damit etwas Vorsicht geboten in der Betrachtung des GANTT-Diagramms.

Durch aktuelle Software lassen sich im Diagramm neben der reinen Terminplanung auch noch weitere Informationen zur Verfügung stellen. Wir erhalten Informationen,

• welche Ressourcen, in welchen Arbeitspakten vertreten sind,
• zu welchem Prozentzahlen sie arbeiten,
• welche Kosten – aufgeteilt in Sach- und Personalkosten – zum Arbeitspaket gehören.

Sie können Arbeitspakete zu Teilaufgaben zusammenfassen und mittels sogenannter RollUps die Kosten berechnet lassen.

Aber Vorsicht: Überladen Sie die Graphik nicht, es ist weiterhin nur eine Terminplanung.

Abbildung 10: GANTT-Diagramm mit Beispiel-Arbeitspaketen

Kostenplanung

Die Kostenplanung ist im Projektmanagement im Grunde ein einfaches Geschäft. Aufgrund der Tatsache, dass wir in der Ressourcenplanung bereits alle Arbeitspakete mit den Ressourcen gefüllt haben und wir damit auch alle Kosten haben, müssen wir diese nur noch in unsere Software eintragen.

Exkurs Softwareeinsatz

Ein Wort zum Thema Software:

Auch wenn das Thema Softwareentwicklung in diesem Buch einen großen Anteil am Umfang einnimmt, bin ich eher kein Freund von Softwareeinsatz.

Ich habe beobachtet, dass in Unternehmen der Glaube herrscht, dass, eine Software zu haben und diese zu benutzen, auch bedeutet Projektmanagement installiert zu haben. Aus meiner eigenen schmerzlichen Erfahrung in meiner Anfängerzeit, darf ich Ihnen versichern, dem ist nicht so.

Software ist dumm und erspart uns nicht das eigene Denken!

Bitte benutzen Sie keine Software bis Sie den Netzplan erstellt haben.

Wenn wir aber in diesem Stadion unserer Planung Software benutzen, dann wird uns die Software automatisch eine Kostenplanung erstellen. Denn die Software ist mittlerweile so ausgereift, dass die einzelnen Kosten der Arbeitspakete summiert werden können und als Gesamtkosten, auch aufgeteilt in Sach- und Personalkosten, dargestellt werden kann.

Bei den Kosten ist zu beachten, dass wir selbstverständlich nicht selbst Rechnungen bezahlen und Löhne überweisen. Diese unterstützenden Prozesse werden weiterhin von der dafür verantwortlichen Abteilung durchgeführt. Was wir im Projektmanagement machen, ist eine Schattenbuchhaltung zu führen. Wir rechnen und kalkulieren genau die Kosten, die wir im Projekt verbrauchen.

Warum ist es so wichtig, dass wir die Kosten – und zwar sämtliche Kosten – auch die sogenannten EhDa-Kosten[3] berechnen?

Am Ende des Planungszeitraums – genauer gesagt der Planungsphase – haben wir Kosten und Zeit des Projektes kalkuliert. Es kommt häufig vor, dass diese beiden Werte sehr wenig mit den Werten der Projektbeauftragung zu tun haben. Ich denke, dies ist auch nachvollziehbar, da wir am Anfang eines Projektes lediglich grobe, geschätzte Werte in Ansatz bringen. Zum aktuellen Zeitpunkt haben wir aber eine viel bessere, weil genauere und kalkulierte Datenbasis.

Was mache ich nun damit?

Ich muss zum Projektbeauftrager gehen und für das Delta zu den Daten beim Projektstart einen Nachtrag stellen.

Jetzt kann ich auch die Frage beantworten, warum es so wichtig ist, kalkulierte Daten zu haben. Der Projektbeauftrager hat jetzt – erstmalig – folgende Möglichkeiten zu reagieren:

• Der Projektbeauftrager genehmigt den Nachtrag und das Projekt wechselt in die Steuerungsphase.
• Der Projektbeauftrager gibt das „HB Männchen“[4]. In diesem Fall können Sie mit ihren Kalkulationen dem Projektbeauftrager zeigen, dass Sie genau diesen Betrag / diese Zeit benötigen. Auch hier wird der Projektbeauftragter den Nachtrag genehmigen.
• Der Projektbeauftrager lehnt den Nachtrag ab. Damit endet das Projekt oder es müssen sich neue Gedanken darüber gemacht werden, welchen Umfang das Projekt haben soll.

Was nicht geht, aber sehr häufig im Management von uns verlangt wird, ist mit der gleichen Menge Geld oder Zeit entweder eine höhere Qualität oder höhere Leistung zu erbringen oder eine Leistung zu erbringen, aber mit weniger Kosten oder in einer kürzeren Zeit[5].

Wenn der (optionale) Nachtrag genehmigt wurde, kann mit der Facharbeit begonnen werden. Dafür wechseln wir in die Steuerungsphase.

[1] Einsatzmittel und Ressourcen werden synonym genutzt.

[2] [GANTT]

[3] EhDa-Kosten sind Kosten die „eh“ „da“ sind, wie z. B. Kosten für Angestellte oder Räume.

[4] In den 60er und 70er Jahren des letzten Jahrhundert war das HB-Männchen eine Werbeikone für eine Zigarettenmarke, die gerne mal in die Luft gegangen ist.

[5] [ANGERMEIER]

Die Steuerungsphase ist für uns Projektmitarbeiter eine einfache Phase, denn unsere Aufgabe besteht „lediglich“ darin, den Plan zu überwachen. Denn wir können sicher sein, wenn es Abweichungen vom Plan gibt, gibt es sie nur an dieser Stelle, alles andere läuft wie geplant weiter.

Selbstverständlich ist diese Darstellung sehr vereinfacht, aber sie trifft den Kern.

Beispiel Segelturn nach New York

Wenn ein Segler von Berlin nach New York segeln möchte, würde er nicht die Segel hissen und loslegen, sondern er wird sich einen genauen Plan machen.

Der Plan berücksichtigt Winde, Strudel und das Bermuda-Dreieck. Aber in diesem Plan gehören auch Informationen über mitzunehmendes Wasser, Getränke, Essen und Kleidung. All das mit den richtigen Mengen an der richtigen Stelle deponiert, legt der Segler ab.

Nehmen wir an, er ist mitten auf dem Atlantik. Der Wind sollte heute von links kommen, aber er kommt von rechts. Wir haben eine Abweichung vom Plan.

Der Segler wird jetzt nicht sofort versuchen auf seinen geplanten Weg zurückzufinden, indem er z. B. den „Wasser-ADAC“ anruft und sich abschleppen lässt, sondern er wird sich überlegen, wie er trotz dieser Abweichung, das Ziel erreichen wird.

Dabei wird ihm egal sein, ob er auf seinen Weg Heute, Morgen oder erst in 10 Tagen zurückkommt. Wichtig ist ihm nur, dass er es mit geringen Aufwand schafft.

Wir haben im Projekt dieselbe Situation. Ich beobachte, dass in der Praxis, ein „Feuerwehr-Controlling“ betrieben wird. Wir rennen dorthin, wo es brennt oder wo zumindest der größte Rauch ist und machen irgendetwas, ohne über die Folgen nachzudenken. Das liegt daran, weil wir schon wieder auf dem Weg zur nächsten Brandstelle sind.

Warum handeln wir so?

Weil wir keinen Plan haben. Ab sofort haben wir einen Plan und wir gehen davon aus, dass dieser Plan funktioniert. Wenn jetzt eine Abweichung erfolgt, können wir sicher sein, dass der Rest des Projektes weiterläuft. Damit bekommen wir eine neue Ruhe, mit der wir überlegen können,

• was läuft da schief,
• warum läuft es schief und
• wie können wir, ohne den Projekterfolg zu gefährden, agieren?

Projektcontrolling

Die vorgenannten Überlegungen machen das Projektcontrolling für uns zu einer einfachen Aufgabe.

Projektcontrolling teilt sich in zwei Hauptarbeitspunkte auf,

• wir müssen regelmäßig den Zustand unseres Projektes überprüfen, um daraus z. B. Berichte erstellen zu können, und
• wir müssen ständig die Abarbeitung des Planes steuern.

Die kontinuierliche Steuerung erfolgt über Meetings bzw. über die Begehung des Erstellungsortes. Dies meint: Wir besuchen z. B. die Baustelle oder die Dienstleister, die für uns arbeiten.

Stichtagsorientiert erstellen wir einen besonderen Bericht über den Zustand unseres Projektes.

Wir nutzen dazu die Idee des Controlling-Kreises[1], um regelmäßig valide Kennzahlen aus unserem Projekt zu bekommen. In der Graphik sehen Sie, dass zuerst bestimmte Kennzahlen des Projektes erhoben werden müssen. Die wichtigsten Kennzahlen sind

• der Grad der Leistungserstellung in Prozent beziehungsweise Euro und
• die verbrauchten Geldmittel.

Abbildung 11: Controlling-Kreis

Beides gegenübergestellt, lässt uns interpretieren, ob Einsatzmittelverbrauch und der Geldmittel-einsatz übereinstimmen.

Beispiel Ressourcenverbrauch

Wir sind ein Solo-Selbständiger Fliesenlegermeister und haben einen Auftrag innerhalb von 5 Tagen einen Fliesenboden zu legen.

Wir planen jeden Tag einen gleichen Anteil von 20% der Leistung zu erbringen. Damit haben wir am Montag 20%, am Dienstag 40%, am Mittwoch 60% usw. erbracht. Da unsere liquiden Mittel nicht so hoch sind, wollen wir jeden Tag im Baumarkt die entsprechende Tagesmenge an Fliesen und Kleber einkaufen. Somit haben wir hier auch kostenseitig am ersten Tag 20% der Kosten ausgegeben, am zweiten 40% und so weiter. Der Plan sieht gut aus!

Am ersten Tag lesen wir im Baumarkt, dass es ein Sonderangebot gibt: beim Kauf von drei Säcken Kleber und drei Einheiten Fliesen wird jeweils eine Einheit geschenkt. Selbstverständlich lassen wir uns dieses Angebot nicht entgehen.

Sehen wir uns jetzt den Verlauf von Kosten und Leistung an. Am Montag haben wir durch den Einkauf 40% der Kosten erbracht, aber nur 20% der Leistung. Wenn Sie sich vorstellen, dass Sie das Ihrem Projektbeauftrager berichten, können wir uns alle den Aufschrei vorstellen.

Am Dienstag haben Sie dann allerdings bei 40% der Leistung auch 40% der Kosten erbracht und sind somit wieder auf dem geplanten Pfad. Wenn Sie dies berichten, dann sind Ihre Stakeholder sehr zufrieden mit Ihnen.

Am Mittwoch sind wir bereits bei 60% der Leistung, haben aber durch den guten Einkauf weiterhin 40% der Kosten. Jetzt trägt man Sie auf Händen!

Am Donnerstag und am Freitag wird sich allerdings alles wieder relativieren, weil wir durch eine Preiserhöhung im Baumarkt am Freitag sowohl 100% der Leistung als auch 100% der Kosten haben.

An diesem Beispiel können Sie sehen, das nackte Zahlen einen falschen Eindruck Ihres Projekts machen können.

Wir müssen einen Statusbericht erstellen und dieser sollten immer – gerade bei Abweichungen – erklärt werden. Aber vor allem müssen die Abweichungen auch erklärbar sein!

Änderungsmanagement

Veränderungen gehören zum Standardgeschäft eines Projektes, und wir werden viele Veränderungen in unseren Projekten haben. Im klassischen Projektmanagement hat sich diese Disziplin sehr verbreitet, weil wir aufgrund von festgeschriebenen und damit unveränderlichen Dokumenten unsere Planung durchgeführt haben.

Methodisch ist es im Grunde nicht vorgesehen, dass Änderungen am Projektgegenstand erfolgen, leider schert sich die Praxis nicht um Methoden.

Es können unterschiedliche Änderung vorkommen:

• im Vertragsrecht sowie
• in den organisatorischen Gegebenheiten Ihres Projektes und
• in der Konfiguration des Projektgegenstandes.

Wenn es zu Änderungen kommt, ist es notwendig, dass Sie diese Änderung nicht nur technisch bearbeiten und dokumentieren, sondern sich die Auswirkung auf das Projekt ansehen. Zum Teil ist es notwendig, dass wir die gesamte Projektplanung noch einmal neu aufziehen. Die damit verbundenen Änderungen können zu Nachträgen führen.

Diese Komplexität ist meines Erachtens der größte Schwachpunkt des klassischen, sequenziellen Projektmanagements.

[1] [DPA]

Nachdem der Projektgegenstand komplett erstellt ist, das bedeutet auch, die Dokumentation zum Projektgegenstand ist erstellt, können wir in die letzte Phase des Vorgehensmodells nach DIN eintreten.

Die Abschlussphase beginnt mit der Übergabe des Projektgegenstandes an den Projektbeauftrager.

Beachten Sie dabei, dass nicht Sie als Projektmanager den Projektgegenstand an den Kunden übergeben, denn Sie sind möglicherweise nicht für Ihr Unternehmen vertretungsberechtigt. Dieser Akt erfolgt durch den Geschäftsführer, Prokuristen oder eine andere benannte Person.

Da Übergabe in manchen Projekten mehrere Tage dauern kann (z. B. die Übergabe von großen industriellen Maschinen), werden beide Akte zeitgleich erfolgen. Kunde, Projektbeauftrager und der Projektmanager gehen zusammen um die Maschine herum.

Für unser Projekt ist die Abnahme des Projektgegenstandes deshalb wichtig, weil wir erst dann das Projekt abschließen können.

Sachlicher Projektabschluss

Im sachlichen Projektabschluss führen wir eine Nachkalkulation des Projektes durch.

Es wird geprüft, ob

• alle Kosten den Arbeitspaketen zugeordnet sind, sowie
• keine doppelte Buchung erfolgt sind.

Mit einer sauberen Aufarbeitung dieser betriebswirtschaftlichen Daten können wir Schlüsse ziehen, die uns helfen werden, im nächsten Projekt besser zu arbeiten.

Sozialer Projektabschluss

Im Teil des sozialen Projektabschlusses, kümmern wir uns um die Menschen des Projektes. Wir führen eine „lessons learned“-Sitzung durch – in diesem Meeting wollen wir unsere Erfahrungen aus dem Projekt aufarbeiten und für weitere Projekte lernen.

Dann sollte es ein Projektfest geben, als Dank und Abschluss des Projektes für das Kernteam, aber auch mit weiteren Stakeholdern zusammen. Da der Mensch Rituale braucht[1], ist es zudem notwendig, dass wir ritualisiert das Kernteam auflösen.

Über diese Vorgänge muss selbstverständlich eine Dokumentation erstellt und veröffentlicht werden. Wir geben damit anderen die Möglichkeit, aus unseren Erfahrungen zu lernen.

Das Ende des Projektes markiert die sogenannte Projektauflösung. Die Projektauflösung umfasst drei Arbeitsschritte:

• Der Projektmanager wird von der Verantwortung des Projektes entlastet.
• Die projektbezogenen Vereinbarungen im Kernteam werden aufgehoben.
• Die Mitarbeiter werden in ihre alten Positionen zurückgeführt.

Damit ist Ihr Projekt beendet.

Im Kapitel über das klassische Projektmanagement habe ich Ihnen erläutert, mit welchem Vorgehensmodell Sie arbeiten sollten.

Der Rote Faden des DIN ist ein eingängiges, bewährtes System, dass Ihnen helfen wird, in Ihrem mittelständischen Unternehmen, effizient Projekte zu bearbeiten.

Die Dokumentation der Projektmanagementergebnisse können sehr einfach mit einer Textver-arbeitung erstellt werden. Selbst Grafiken lassen sich durch Templates gestalten und leicht einbinden.

Trotzdem finden Sie auf dem Markt diverse Projektmanagement-Software. Es stellt sich damit die Frage: ist es sinnvoll ein Projektmanagementtool zu benutzen und wenn ja welches?

Dieser Frage stellen wir uns im nächsten Kapitel.

[1] vgl. Tuckmann, Kapitel 5.6