Neu als Projektleiter*in: Fit in einem Tag E-Book

Simon Stäuber

• Herausgeber: dastus trainings - Dr. Simon Stäuber
• Kategorie: Fachliteratur
• Sprache: Deutsch

Veröffentlichungsjahr: 2022

Beschreibung

In diesem Buch lernen Sie sämtliche Bereiche kennen, die Sie für ein professionelles Projektmanagement benötigen. Sowohl der agile als auch der klassische Ansatz werden detailliert erklärt und miteinander verzahnt. Außerdem lernen Sie, wann der agile und wann der klassische Ansatz zielführender ist. Der agile Ansatz wird am Beispiel der Methode "Scrum" erklärt. Alle Inhalte sind so beschrieben, dass Sie diese möglichst einfach und schnell in Ihren eigenen Projekten einsetzen können. Das Buch ergänzt und vertieft das 1-Tages-Seminar “Neu als Projektleiter*in”, kann jedoch auch zum Selbststudium genutzt werden. Inhalte: - Projektauftrag und Projektablau - Vorgehensmodell: agil oder klassisch? - Skakeholder und Kommunikation - Projektplanung: Inhalte, Termine, Budget (klassisch und agil) - Team, Teambuilding und Konfliktmanagement - Risikomanagement - Projektcontrolling - Änderungsmanagement - Umgang mit Projektproblemen - Projektabschluss

Leseprobe

Über dieses Buch und den Autor

In diesem Buch lernen Sie sämtliche Bereiche kennen, die Sie für ein professionelles Projektmanagement benötigen. Sowohl der agile als auch der klassische Ansatz werden detailliert erklärt und miteinander verzahnt. Außerdem lernen Sie, wann der agile und wann der klassische Ansatz zielführender ist. Der agile Ansatz wird am Beispiel der Methode "Scrum" erklärt.

Alle Inhalte sind so beschrieben, dass Sie diese möglichst einfach und schnell in Ihren eigenen Projekten einsetzen können. Das Buch ergänzt und vertieft das 1-Tages-Seminar “Neu als Projektleiter*in”, kann jedoch auch zum Selbststudium genutzt werden.

Inhalte:

Projektauftrag und Projektablauf

Vorgehensmodell: agil oder klassisch?

Skakeholder und Kommunikation

Projektplanung: Inhalte, Termine, Budget (klassisch und agil)

Team, Teambuilding und Konfliktmanagement

Risikomanagement

Projektcontrolling

Änderungsmanagement

Umgang mit Projektproblemen

Projektabschluss

Dr. Simon Stäuber ist Betriebswirt und Linguist mit mehr als 12 Jahren Erfahrung in diversen Projektmanagementrollen, als Führungskraft und Consultant. Insbesondere in den Bereichen agiles und klassisches Projektmanagement und Organisationsentwicklung hat er zahlreiche Seminare und Beratungen durchgeführt, seine Expertise gibt er außerdem in Veröffentlichungen und an der Universität Hohenheim weiter. Er ist u.a. zertifiziert als Project Management Professional (PMP), Professional Scrum Master, Professional Scrum Product Owner und Ausbilder (IHK).

Inhaltsverzeichnis

Über dieses Buch

1. Projektmanagement: Wozu und wie starten wir?

2. Zum Starten: Klären des Projektauftrags

3. Gestalten des Projekts: Was benötigen wir? Agil oder klassisch?

4. Modul 1: Stakeholder erfassen und einbinden

5. Modul 2a: Klassische Projektplanung: Projektinhalte, Termine und Budget

6. Modul 2b: AGILE Projektplanung nach SCRUM: Projektinhalte, Termine und Budget

7. Modul 3: Team, Teambuilding und Konfliktmanagement

8. Modul 4: Risikomanagement

9. Modul 5: Projektcontrolling: Budget, Termin und Qualität im Blick behalten

10. Modul 6: Änderungen im Projekt managen

11. Modul 7: Wenn alles schief läuft: Umgang mit Problemen im Projekt

12. Modul 8: Projektabschluss

13. Ergänzende Literatur und Links (Auswahl)

Impressum

Projektmanagement: Wozu und wie starten wir?

Projektmanagement ist etwas, das vor allem auffällt, wenn es nicht funktioniert. Offensichtlich für eine breite Öffentlichkeit war das etwa beim Bahnprojekt Stuttgart 21 oder beim Flughafenneubau Berlin-Brandenburg. Doch auch bei einem misslungenen Sommerfest überlegen Gäste gerne, was alles bei der Organisation, also im Projektmanagement, falsch gelaufen ist.

Doch was ist überhaupt ein Projekt? Unabhängig von der Größe zeichnet es sich dadurch aus, dass es ein einzigartiges Vorhaben ist, das zeitlich begrenzt ist. Wiederholbare Elemente können vorkommen, doch das Vorhaben soll sich von vergleichbaren unterscheiden. Zum Beispiel ist die Organisation eines Sommerfests üblicherweise einzigartig, auch wenn es vorher schon Sommerfeste gab, da andere Gäste eingeladen werden, andere Speisen zubereitet werden etc. Wer ein solches Vorhaben planvoll angeht, betreibt Projektmanagement.

Professionelles Projektmanagement ist allerdings erst ab einer gewissen Projektgröße sinnvoll. So kann man sich folgendermaßen orientieren: Bei mindestens drei Monaten Dauer oder mehr als drei Teammitgliedern lohnt sich der Aufwand für ein Projektmanagement. Planvolles Vorgehen ist natürlich auch für kleinere Projekt sinnvoll, dann reicht jedoch meist eine einfache To-Do-Liste.

Hier finden Sie sämtliche Module beschrieben, die Sie für ein professionelles Projektmanagement benötigen. Sowohl der agile als auch der klassische Ansatz werden detailliert erklärt und miteinander verzahnt. Jedes Modul wird aus Sicht von Praktikern beschrieben und mit Beispielen aus der Praxis dargestellt, so dass Sie es sofort und einfach in Ihren eigenen Projekten anwenden können. Eine Annahme gibt es dabei: Sie als Projektmanager, Product Owner oder Scrum Master sind motiviert und fühlen sich dafür verantwortlich, Ihr Projekt zum Erfolg zu bringen.

„Projektmanager“, „Product Owner“ und „Scrum Master“ bezeichnen in diesem Buch die weibliche und männliche Form der jeweiligen Rolle. „Projektmanager“ (auch, je nach Organisation: Projektleiter/in, Projektkoordinator/in, Projektverantwortliche/r) ist eine Rolle im sogenannten klassischen Vorgehensmodell. „Product Owner“ und „Scrum Master“ sind Rollen im sogenannten agilen Vorgehensmodell nach Scrum. Im Folgenden wird zusammenfassend für alle Rollen zur besseren Lesbarkeit meist nur der Begriff „Projektmanager“ verwendet. Die Aufgabenteilung von Product Owner und Scrum Master ist Thema im Kapitel zur agilen Projektplanung.

Wir starten zunächst mit der Klärung des Projektziels und des Auftrags. Danach entscheiden wir uns für den grundsätzlichen Ablauf und – je nach Projektrahmenbedingungen – für eine agile Vorgehensweise (hier: Scrum) oder eine klassische. Dann startet das eigentliche Projektmanagement, beschrieben in den Modulen 1 bis 8. Für jedes Modul gibt es eine Checkliste, in der alle wichtigen Punkte zusammengefasst sind.

Zum Starten: Klären des Projektauftrags

Bevor ein Projektmanager mit dem eigentlichen Projekt startet, müssen grundlegende Ziele des Projekts und Erwartungen an die Projektergebnisse geklärt werden. Ansonsten besteht das Risiko, Budget, Ressourcen und menschliche Lebenszeit für etwas zu verbrauchen, das nicht benötigt wird.

Üblicherweise gibt es einen Projektauftraggeber, also jemanden, der möchte, dass ein bestimmtes Ergebnis erreicht wird und der dafür Budget und/oder Ressourcen zur Verfügung stellt. Der Projektauftraggeber wird je nach Projekt und Organisation auch „Projektsponsor“, „Projektinitiator“ oder „Kunde“ genannt.

Hier nun die Informationen, die Sie vor dem Start eines Projekts benötigen. Diese bilden den sogenannten Projektauftrag (je nach Organisation auch genannt: „Project Charter“, „Projektdefinition“, „Erwartungen an das Projekt“):

Projektname

Projektziel

Begründung für die Notwendigkeit des Projekts

Projektinhalte (Kurzbeschreibung)

Rahmenbedingungen: Termin und Budget

Projektmanager

Optional: Chancen & Risiken

Optional: Wichtige Stakeholder

Am einfachsten ist es, wenn der Projektauftraggeber von sich aus die erforderlichen Informationen für den Projektauftrag vollständig zur Verfügung stellt. In der Praxis ist dies jedoch selten der Fall. Dann ist es die Verantwortung des Projektmanagers, diese Informationen abzufragen und schriftlich zusammenzufassen. Der Projektauftraggeber muss zwingend den Projektauftrag bestätigen, bevor der Projektmanager mit dem Projekt starten kann. Die Bestätigung sollte der Projektmanager zur Vermeidung späterer Missverständnisse schriftlich vorliegen haben. Falls die Bestätigung in einem Meeting oder Telefonat erfolgt, führt der Projektmanager zur Dokumentation im Gesprächsprotokoll den Projektauftrag auf und schickt dieses an den Projektauftraggeber.

Checkliste Klären des Projektauftrags

Folgende Punkte klärt der Projektmanager mit dem Projektauftraggeber vor Beginn des Projekts (schriftlich fixieren!):

Projektname

Projektziel

Begründung für die Notwendigkeit des Projekts

Projektinhalte (Kurzbeschreibung)

Rahmenbedingungen: Termin und Budget

Projektmanager

Optional: Chancen & Risiken

Optional: Wichtige Stakeholder

Gestalten des Projekts: Was benötigen wir? Agil oder klassisch?

Wenn der Projektauftrag geklärt ist, legt der Projektmanager fest, wie genau er das Projekt managen möchte. Dies heißt auch: Gehen wir agil oder klassisch vor?

Entscheidung für ein klassisches oder agiles Vorgehen

Im Projektmanagement gibt es zwei grundsätzlich unterschiedliche Vorgehensweisen, um Projektinhalte zu managen: Das „agile“ und das „klassische“ Projektmanagement. Die größten Unterschiede sind:

Beim agilen Vorgehen versuchen wir, möglichst schnell und regelmäßig Zwischenergebnisse zu präsentieren, die nutzbar für den Auftraggeber sind. Beispiel: Wir haben den Auftrag erhalten, eine Website zu erstellen. Wir erstellen zunächst die voll funktionsfähige Startseite. Der Auftraggeber kann sie nutzen und uns Rückmeldung über seine Zufriedenheit geben. Dann erstellen wir die erste Unterseite und übergeben diese ebenfalls an den Auftraggeber. Danach die nächste Unterseite und so weiter.

Dadurch erhalten wir während der Projektdurchführung viel Feedback. Änderungen des Projektinhalts können wir mit wenig Aufwand während des Projektverlaufs umsetzen, da wir uns in der Detailplanung nur für eine relativ kurze Zeitspanne in der Zukunft festlegen. Typisch für das agile Vorgehen ist, dass wir am Anfang nicht sicher sagen können, wann wir welche Ergebnisse liefern werden und wie teuer es wird. Dafür entsprechen die gelieferten Ergebnisse meist genauer den Vorstellungen des Auftraggebers als beim klassischen Vorgehen.

Beim klassischen Vorgehen hingegen versuchen wir, die Projektinhalte am Anfang möglichst genau zu erfassen, um zu einem bestimmten Termin das gewünschte Ergebnis liefern zu können. Änderungswünsche bedeuten hier häufig, dass sich der Projekttermin verschiebt oder zusätzliche Kosten entstehen. Haben wir jedoch eine überschaubare Anzahl von Änderungen oder einen kurzfristigen Termin, ist das klassische Vorgehen erfolgreicher und günstiger, da es weniger Abstimmungsrunden und Unklarheiten gibt. Im Beispiel des Website-Projekts gehen wir zunächst mit dem Auftraggeber im Detail durch, wie alles aussehen und funktionieren soll. Dann stellen wir die Website komplett fertig und übergeben diese an den Auftraggeber zur Prüfung. Möchte der Auftraggeber nun bestimmte Teile der Website ändern, weil sich seine Wünsche geändert haben, entstehen weitere Kosten.

Um zu entscheiden, welcher Ansatz sich am besten für Ihr Projekt eignet, ist es wichtig, zwei Fragen zu beantworten:

Ist der Projektinhalt im Detail klar zu benennen? (d.h. fällt es Ihnen vom Projektziel ausgehend relativ einfach zu definieren, welche Aufgaben erledigt werden müssen, um zum Projektziel zu gelangen?)

Vermuten Sie im Projekt viele heute noch nicht absehbare Impulse, Entscheidungen oder Änderungen von Rahmenbedingungen, d.h. insgesamt viele Überraschungen? (d.h. gibt es viele beteiligte Akteure oder äußere Einflüsse, die Sie nur schwer steuern können?)

Wenn Sie diese Fragen beantwortet haben, können Sie folgende Matrix zur Einschätzung des geeigneten Vorgehens nutzen:

EntscheidungsmatrixKlassisch – Agil

Wenige Überraschungen erwartet(kompliziert)

Viele Überraschungen erwartet(komplex)

Projektinhalt eher eindeutig

Klassisch ohne Komplexität

Klassisch mit Komplexität

Projektinhalt eher unklar

-

Agil

Tabelle 1: Entscheidungsmatrix Klassich - Agil

In folgender Übersicht sind Beispiele für Projekteinschätzungen aufgeführt.

A. Die Projektinhalte sind eher klar und es werden wenige Überraschungen erwartet:

1. Eine Familie möchte ein Einfamilienhaus bauen mit 200qm, 6 Zimmern, davon das Wohnzimmer mindestens 35qm. Zwei Stockwerke, Flachdach, Keller (= klarer Projektinhalt). Den Auftrag führt ein erfahrener Bauträger aus, der schon 500 ähnliche Häuser in der Region gebaut hat (= wenige Überraschungen erwartet).

2. Ein Anwaltsbüro möchte einen alten Aktenbestand digitalisieren. Dazu sollen die einzelnen Akten eingescannt und anschließend vernichtet werden (= klarer Projektinhalt). Die digitale Dateistruktur ist bereits bekannt (= wenige Überraschungen erwartet).

B. Die Projektinhalte sind eher klar und es werden viele Überraschungen erwartet:

1. Eine Familie möchte ein Einfamilienhaus bauen mit 200qm, 6 Zimmern, davon das Wohnzimmer mindestens 35qm. Zwei Stockwerke, Flachdach, Keller (= klarer Projektinhalt). Den Auftrag führt ein Architekt aus, der in der Region noch nicht gebaut hat. Beim Baugrundstück handelt es sich um ein Hanggrundstück, das noch nicht erschlossen ist (= viele Überraschungen möglich).

2. Ein Anwaltsbüro möchte einen alten Aktenbestand digitalisieren. Dazu sollen die einzelnen Akten eingescannt und anschließend vernichtet werden (klarer Projektinhalt). Es ist noch unklar, wo und wie die digitalisierten Akten abgelegt werden, dies muss von den 25 Partnern der Anwaltskanzlei einstimmig beschlossen werden. Zudem ist noch ungeklärt, ob datenschutzrechtlich besondere Erfordernisse einzuhalten sind (= viele Überraschungen möglich).

C. Die Projektinhalte sind eher unklar und es werden viele Überraschungen erwartet:

1. Erstellung einer Website, die die Kultur des Auftraggebers möglichst gut repräsentiert (= eher unklarer Projektinhalt). Die Organisation besteht aus 100 Personen, 20 davon müssen als Stakeholder eingebunden sein (= viele Überraschungen erwartet).

2. Gewünschte Funktionserweiterung eines Roboterarms zur besseren Sicherung des Arbeitsbereichs, um Arbeitsunfälle zu verhindern (= eher unklarer Projektinhalt). Der Roboterarm ist weltweit 20.000 Mal im Einsatz. Es liegen keine Daten dazu vor, in welchen Ländern und Betrieben der Roboterarm eingesetzt wird. Auch ist unbekannt, welche Arbeitsunfälle am häufigsten auftreten (= viele Überraschungen möglich).

Bei einem unklaren Projektinhalt ergeben sich tendenziell mehr Überraschungen als bei klaren Projektinhalten. Deshalb tritt die Kombination „Projektinhalt eher unklar“ und „wenige Überraschungen erwartet“ in der Praxis nicht auf.

Ist die Einschätzung getroffen, gehören zu einem idealtypischen Projektmanagement folgende Bereiche, hier getrennt dargestellt für die Phasen „Start“, „Planung“, „Durchführung“ und „Abschluss“. Je nach Projektgröße sind manche Bereiche wichtiger oder unwichtiger. Diese Einschätzung trifft der Projektmanager, am besten in Abstimmung mit erfahrenen Kolleginnen und Kollegen.

.

1. START

Projektauftrag klären und vom Auftraggeber bestätigen lassen.

Kernteam für die Projektplanung zusammenstellen (je nach Größe des Projekts reicht manchmal auch nur der Projektmanager)

2. PLANUNG

Stakeholder ermitteln und Kommunikationsstrategie definieren (Modul 1).

Projektplanung: Inhalte definieren, Abhängigkeiten sowie Aufwand ermitteln und einen Zeitplan erstellen. Den Projektalltag organisieren (Modul 2a: klassisch oder Modul 2b: agil).

Teamauswahl und Teambuilding (Modul 3)

Risiken erfassen und das Risikomanagement planen (Modul 4).

Falls bei der Projektplanung gravierende Abweichungen zum Projektauftrag festgestellt werden (etwa höheres benötigtes Budget): Rücksprache mit Projektauftraggeber halten, ansonsten direkt Kick-off Meeting.

Kick-off Meeting mit allen Projektbeteiligten und Freigabe der Projektplanung durch den Projektauftraggeber (Modul 2a/b).

3. DURCHFÜHRUNG

Arbeit an Projektinhalten

Regelmeetings, Regelkommunikation und Konfliktmanagement durchführen (Modul 3).

Projektcontrolling: Fortschritt und Abweichungen bei Ergebnissen, Budget und Termin bemerken und gegebenenfalls korrigieren (Modul 5).

Änderungen managen (Modul 6).

Probleme analysieren und lösen (Modul 7).

4. ABSCHLUSS

Team auflösen, aus Erfahrungen lernen und das Projekt schließen (Modul 8).

Wenn sich der Projektmanager für ein Vorgehen entschieden hat, kann es mit der eigentlichen Projektvorbereitung losgehen, üblicherweise mit der Zusammenstellung des Kernteams für die Projektplanung. Ist das Projekt klein, besteht das Kernteam häufig nur aus dem Projektmanager.

Modul 1: Stakeholder erfassen und einbinden

Vor der eigentlichen Projektplanung ist es wichtig zu wissen, welche Personen und Organisationen in das Projekt eingebunden werden sollten. Alle vom Projekt auf irgendeine Art betroffenen Personen und Organisationen werden Stakeholder genannt. Stakeholder, die wir nicht angemessen berücksichtigen, können den Projekterfolg gefährden. Beim Bahnprojekt Stuttgart 21 wurde zum Beispiel der Stakeholder „Öffentlichkeit“ nicht adäquat eingebunden mit der Folge, dass es über Jahre starken Widerstand gab, der das Projekt behinderte.

Beim Stakeholdermanagement geht es zunächst darum, alle zu erfassen, die Einfluss auf das Projekt nehmen können. Anschließend folgt die Kommunikationsplanung, also das Festlegen von „Wann kommunizieren wir wie und mit wem?“. Das ist sinnvoll, damit wir als Projektleiter die Kommunikation steuern können und sicherstellen, dass jeder, der informiert sein sollte, informiert ist.

Wann/wie oft beschäftige ich mich damit?

Zu Beginn des Projekts sollen die Stakeholder erfasst und der Kommunikationsplan erstellt werden. Bei Bedarf kann der Projektleiter die Stakeholder-Übersicht und den Kommunikationsplan im Projektverlauf anpassen.

So funktioniert es im Detail

Kommunikationsplan für das Projekt “Jubiläumsfeier im Sommer” (Auszug)

Stakeholder 1: Auftraggeber

Besondere Erwartungen/Bedürfnisse: Frühe Benachrichtigung bei Problemen im Projekt

Art der Kommunikation: Per E-Mail, bei wichtigen/dringenden Anliegen persönlich oder per Telefon

Zeitpunkt der Kommunikation: Alle zwei Wochen: Zwischenergebnisse per E-Mail durch den Projektmanager

Stakeholder 2: Projektteam

Besondere Erwartungen/Bedürfnisse: Über alles Relevante im Projekt informiert sein

Art der Kommunikation: Internes Wikipedia und täglicher persönlicher Austausch

Zeitpunkt der Kommunikation: täglich

Stakeholder 3: Anwohner

Besondere Erwartungen/Bedürfnisse: Das Fest soll nicht zu laut sein

Art der Kommunikation: Persönlich und per E-Mail

Zeitpunkt der Kommunikation: Einladen der Anwohner zum Informationstermin. Beantworten von E-Mail-Anfragen von Anwohnern innerhalb von 24 Stunden

Checkliste 1: Stakeholder und Kommunikation

Zum Start

Erfassen aller relevanten Stakeholder und ihrer Bedürfnisse (Stakeholder-Matrix)

Festlegen der Kommunikationsstrategie (Kommunikationsplan)

Einigen auf Kommunikationsstandards, zum Beispiel für Pünktlichkeit, Agenda und Protokolle

Während des Projekts

Aktualisierung der Stakeholder-Matrix und des Kommunikationsplans bei Bedarf

Durchführen der Kommunikation laut Kommunikationsplan

Einhalten und gegebenenfalls Anpassen der Kommunikationsstandards.

Modul 2a: KLASSISCHE Projektplanung: Projektinhalte, Termine und Budget

Bei der Projektplanung geht es darum zu entscheiden, welche Inhalte wir umsetzen, um das Projektziel zu erreichen. Wir schätzen die Dauer der Aufgaben, gliedern das Projekt in Phasen und kommen so zu einer Vorstellung, wie der Zeitplan idealerweise aussieht. Zur Auswahl, ob ein klassischer oder agiler Ansatz geeigneter ist, siehe das Kapitel Gestalten des Projekts: Ablaufplan und Entscheidung für Vorgehensmodell.

 

Wozu ist das nützlich?

Durch die Planung bekommen wir zum einen Informationen über die Dauer des Projekts und wann wir was benötigen. Zum anderen erhalten wir ein Gefühl der Kontrolle und Sicherheit. In jedem Projekt wird es Abweichungen vom Plan geben – es geht nie darum, dem Plan 100% zu folgen. Sondern darum, ihn immer wieder so anzupassen, dass das Projektziel erreicht wird.

So funktioniert es im Detail:

1. Definieren der Projektinhalte (=Anforderungen)

Um möglichst alle Projektinhalte zu erfassen, nutzen wir einen sogenannten Projektstrukturplan. Das heißt, dass wir – am besten gemeinsam im Team – versuchen, sämtliche Bestandteile eines Projekts zu erfassen und dabei große Aufgaben in kleinere herunterbrechen. Das kann in einem gemeinsamen Workshop geschehen, bei dem die einzelnen Aufgaben auf Karten geschrieben werden. Es funktioniert meist besser, dies physisch zu machen, anstatt gleich am Computer zu arbeiten.

Beispiel:

Abbildung 2: Beispiel eines Projektstrukturplans

Zusätzlich zum Namen der Aufgabe auf den Karten sind in vielen Projekten weitere Informationen erforderlich, um die Aufgabe so zu definieren, dass jeder im Projekt versteht, was genau das Ergebnis sein soll. Das können zum Beispiel technische Beschreibungen sein, Skizzen oder Checklisten. Diese Informationen werden entweder in einem eigenen Dokument (beispielsweise einer Spezifikation) erfasst, in einem Dokumentenverwaltungssystem (zum Beispiel Confluence) oder in einem Projektmanagement-Tool (zum Beispiel OpenProject) zusammengestellt.

Für das Beispielprojekt oben könnte das für die Aufgabe „Prüfen notwendiger Versicherungen“ wie folgt aussehen:

Prüfen notwendiger Versicherungen

Nachsehen, was wir bei der letzten ähnlichen Veranstaltung für Versicherungen und Haftungsfälle hatten.

Versicherungsbedarf und möglichen Schutz mit unserem Makler XY checken.

Deckungssumme sollte mindestens 50 Millionen Euro sein.

Die Versicherung(en) müssen kurzfristig erweiterbar sein, falls wir mehr Gäste einladen sollten

2.

---ENDE DER LESEPROBE---