Präsenzseminar IT-Projektmanagement

Fallbeispiel Projekt ZEIT

Das Lernprinzip: Parallele Welten erleben

Gleicher Kontext, zwei Methoden

Alle Übungen basieren auf demselben Fallbeispiel (Projekt ZEIT) – Unterschiede werden direkt spürbar, nicht nur theoretisch erklärt.

Mindset vor Methode

Jede Übung endet mit strukturierter Reflexion: „Was hat sich anders angefühlt?"

Vielfalt in der Gruppe nutzen

Die bestehenden Gruppen bewusst aktivieren: Unterschiedliche Erfahrungshintergründe werden zur Ressource – Anfänger stellen Fragen, Erfahrene erklären und reflektieren dadurch selbst.

Ablauf: PM -klassisch (Wasserfall)

Das klassische Projektmanagement, oft als Wasserfallmodell bezeichnet, verläuft in sequenziellen Phasen. Jede Phase muss abgeschlossen sein, bevor die nächste beginnen kann.

Dieser Ansatz legt Wert auf eine detaillierte Planung und Dokumentation im Voraus. Änderungen sind im späteren Verlauf des Projekts aufwendig, daher ist eine umfassende Vorbereitung entscheidend für den Erfolg.

Ablauf: Scrum (agil)

Der agile Ansatz, insbesondere Scrum, setzt auf iterative Zyklen, genannt Sprints, und kontinuierliche Anpassung. Im Mittelpunkt stehen das Product Backlog als dynamische Prioritätenliste und das Sprint Planning, das die Arbeit für jeden Zyklus festlegt.

Sprint Planning

Aufgaben für den Sprint aus dem Produktbacklog auswählen und planen

Durchführung

Arbeitspakete im Sprint umsetzen (Daily Scrum)

Test

Qualität prüfen, Definition of Done sicherstellen

Ausliefern

Inkrement bereitstellen und deployen

Sprint Review + Retrospektive

Inkrement demonstrieren, Feedback von Stakeholdern einholen

Im Team über Verbesserungen nachdenken

Diese Vorgehensweise fördert Flexibilität, schnelle Lieferungen von funktionsfähigen Inkrementen und die enge Zusammenarbeit mit dem Kunden. Änderungen sind willkommen und können nach jedem Sprint in die Planung einfliessen.

Rollen und Verantwortlichkeiten im klassischen PM

Im traditionellen Projektmanagement sind Rollen und Hierarchien klar definiert, um eine strukturierte und nachvollziehbare Projektabwicklung zu gewährleisten.

Projektleiter

Die zentrale Figur, verantwortlich für die Gesamtplanung, Koordination und Überwachung. Stellt sicher, dass das Projekt im Zeit- und Kostenrahmen sowie mit der erforderlichen Qualität abgeschlossen wird, bzw holt sich die Zustimmung des Auftraggebers, wenn es Änderungen gibt.

Auftraggeber

Der Initiator und Hauptfinanzier des Projekts. Definiert die Business-Anforderungen, stellt Ressourcen bereit und trifft wichtige Entscheidungen. Nimmt die Projektergebnisse ab und entlastet den PL oder auch nicht.

Projektteam-Mitglieder

Fachkräfte, die die eigentliche Arbeit leisten. Sie setzen die geplanten Aufgaben um, berichten über Fortschritte und Herausforderungen an den Projektleiter.

Stakeholder

Personen oder Gruppen, die vom Projekt betroffen sind oder ein Interesse daran haben. Sie werden regelmässig informiert und ihre Erwartungen werden berücksichtigt.

Rollen und Verantwortlichkeiten im agilen PM (Scrum)

Im agilen Projektmanagement, insbesondere bei Scrum, sind die Rollen dynamischer und fördern Selbstorganisation sowie enge Zusammenarbeit, um schnell auf Veränderungen reagieren zu können.

Product Owner

Definiert die Produktvision und maximiert den Wert des Produkts. Er ist verantwortlich für das Product Backlog und die Priorisierung der Anforderungen.

Scrum Master

Ist der Prozess-Coach des Teams. Er sorgt dafür, dass Scrum-Prinzipien eingehalten werden, entfernt Hindernisse und fördert die Zusammenarbeit und kontinuierliche Verbesserung.

Entwicklungsteam

Das selbstorganisierende, funktionsübergreifende Team, das die Arbeit erledigt. Es ist für die Entwicklung, das Testen und die Lieferung des Produktinkrements verantwortlich.

Stakeholder

Alle Personen und Gruppen, die ein Interesse am Produkt oder Projekt haben. Sie geben regelmässig Feedback, das in die Produktentwicklung einfliessen kann.

PSP vs. Product Backlog + Sprint Planning

Im IT-Projektmanagement begegnen uns zwei fundamentale Ansätze: der klassische, planorientierte Ansatz und der agile, iterative Ansatz. Beide haben ihre Berechtigung und spezifischen Vorteile.

In dieser Einheit vergleichen wir die Kerninstrumente beider Welten: den Project Structure Plan (PSP) als Grundlage klassischer Projekte und die Kombination aus Product Backlog und Sprint Planning als Herzstück agiler Vorgehensweisen.

Klassisch: PSP

Detaillierte Vorabplanung, sequenzielle Phasen und feste Meilensteine.

Agil: Product Backlog + Sprint Planning

Iterative Entwicklung, Flexibilität bei Anforderungen und kontinuierliche Lieferung.

Übung 1

PSP vs. Product Backlog + Sprint Planning

Vollständige Vorab-Planung trifft auf inkrementelle Priorisierung – am selben Projektszenario erlebt.

Übung 1 – Ziel & Zeitrahmen

Lernziel

Unterschied zwischen vollständiger Vorab-Planung (PSP) und inkrementeller Priorisierung (Backlog) am selben Projektszenario direkt erleben.

Zeit

PSP Teil 1 + 2: 90 min | Backlog + Sprint Planning: 45 min

Material

Moderationskarten, Metaplanwand, Marker, vorbereitete User Stories aus der Selbstlernphase

Bewertung

PSP + Backlog/Sprint Planning sind Studienleistung – Fotos der Metaplanwände werden nach dem Seminar eingereicht.

PSP erstellen – Projekt ZEIT (Arbeitsblatt)

Initiierung

[ Arbeitspakete eintragen ]

Planung

[ Arbeitspakete eintragen ]

Ausführung

  • Arbeitspakete bearbeiten
  • Features entwickeln
  • Qualität prüfen
  • Tests durchführen
  • Dokumentation erstellen

Überwachung und Steuerung

  • Fortschritt messen
  • Abweichungen korrigieren
  • Änderungen genehmigen
  • Kommunikation steuern
  • Qualität sichern

Abschluss

  • Produkt übergeben
  • Feedback einholen
  • Projekt abschließen
  • Team entlasten
  • Erfahrung sammeln

Product Backlog + Sprint Planning – Projekt ZEIT (Arbeitsblatt)

Product Backlog erstellen & priorisieren

Fügt eure User Stories aus der Selbstlernphase hier ein. Priorisiert die Stories (z.B. nach dem MoSCoW-Prinzip oder als nummerierte Liste). Jede Story sollte eine Schätzung in Story Points erhalten ). Die Storypoints werden aber erst im Rahmen der Übungen zur Aufwandschätzung ergänzt.

Beispiel:

  • Als Admin möchte ich X, damit Y (3 SP)
  • Als User möchte ich A, damit B (5 SP)

Sprint 1 planen (wird ggf erst nach der Aufwandschätzung durchgeführt)

Wählt die Top-Stories aus eurem priorisierten Product Backlog für den ersten Sprint aus. Die Gesamtkapazität des Sprints beträgt 5 Story Points.

Definiert ein klares und fokussiertes Sprint Goal.

Stories für Sprint 1:

  • [Story 1]
  • [Story 2]

Sprint Goal: [Definiert hier das Ziel für Sprint 1]

Überlegt Euch, wann Ihr konzeptionelle und/oder technische Grundlagen des Backends (zu Grunde liegende Datenbank) umstzen müsst.

Übung 2

Aufwandsschätzung – Klassisch vs. Planning Poker

Erleben, wie unterschiedliche Schätzmethoden zu verschiedenen Ergebnissen und Diskussionen führen – und warum das gewollt ist.

Übung 2 – Ziel & Zeitrahmen

Lernziel

Erleben, wie unterschiedliche Schätzmethoden zu verschiedenen Ergebnissen und Diskussionen führen – und warum das gewollt ist.

Zeit

60 min (laut Agenda 14:45–15:45 Uhr)

Material

Planning-Poker-Karten (oder Zettel mit Fibonacci-Zahlen), vorbereitete Arbeitspaket-Beschreibungen aus dem PSP

Bewertung

Schätzergebnisse aller drei Stufen sind Studienleistung – Dokumentation (Foto oder Tabelle) wird nach dem Seminar eingereicht.

Ablauf: Dreistufige Schätzrunde (Arbeitsblatt)

1

Klassisch

Schätzung (20 min)
Arbeitspaket: Kick-off Meeting – Projekt ZEIT: Ergebnis dokumentieren.

  • Vorbereitung (Agenda, Einladungen, Raumplanung): __ Personen × __ Tage = __ PT
  • Kick-off Tag (Durchführung des Meetings, was gehört dazu, auch kennenlernen): __ Personen × __ Tage = __ PT
  • Nachbereitung (Protokoll, Aufgabenverteilung, Kommunikation der Ergebnisse): __ Personen × __ Tage = __ PT

Gesamt: __ PT

2

Agil

Planning Poker (20 min)
Das 2. Teammeeting (Kontext: das der PL und das Team sollen die PM-Methodik in diesem Meeting selber festlegen) soll per Planning Poker in Story Points geschätzt. Ein Storypoint ist gleich der Dauer des Kick off.

  1. Ihr nehmt Euch die ersten drei Userstorys Eures Pruduct backlogs und schötzt die benötigten Storypoints. Ein Storypoint entspricht der Durchführung des 2. Teammeetings.
3

Schnellrunde

T-Shirt-Größen (10 min)
Alle verbleibenden Backlog-Items einteilen – Zeitlimit: 30 Sekunden pro Item.

Kriterien: Komplexität + Klarheit + Abhängigkeiten – nicht nur die Dauer allein.

  • XS – Sehr klar, kaum Abhängigkeiten, in wenigen Stunden erledigt
  • S – Gut verstanden, wenig Abstimmungsbedarf, 1–2 Tage
  • M – Mittlere Komplexität, einige Abhängigkeiten, ca. 3–5 Tage
  • L – Hohe Komplexität oder Unklarheiten, mehrere Beteiligte, > 1 Woche
  • XL – Zu groß oder zu unklar – sollte weiter zerlegt werden (Epic)
Übung 3

Kommunikationslabor

Klassische Kommunikationspläne trifft auf Daily Standups und Sprint Reviews – strukturell verschiedene Kommunikation direkt erleben.

Übung 3 – Ziel & Zeitrahmen

Lernziel

Erleben, wie Kommunikation im klassischen PM (Kommunikationsplan, formelle Berichte) und im agilen PM (Daily Standup, Sprint Review, direkte Kommunikation) strukturell verschieden ist.

Zeit

75 min (Tag 1, 15:45–17:00 Uhr)

Material

Rollenkarten (Herr Leiter, Frau Besserwich, Betriebsrat, Team PMP), Kommunikationsplan-Vorlage

Ablauf: Rollenspiel in zwei Akten

Akt 1 – Klassisch (25 min)

Gruppe erstellt Kommunikationsplan für Projekt ZEIT: Wer bekommt welche Info, wann, in welchem Format?
Anschließend: Rollenspiel „Statusmeeting mit Herrn Leiter" (5 min).

Akt 2 – Agil (25 min)

Dieselbe Gruppe simuliert ein Sprint Review mit Herrn Leiter als Stakeholder. Das Team präsentiert den Prototyp der Eingabemaske, Herr Leiter gibt direktes Feedback.

Debriefing (25 min)

Plenum: Was hat Herr Leiter in Akt 1 vs. Akt 2 erfahren? Was wurde verschwiegen? Was wurde sichtbar?

Übung 4

Risikomanagement – Klassisch vs. Agil

Zwei grundlegend verschiedene Philosophien: Risiken dokumentieren und planen – oder Risiken durch frühe Lieferung und Transparenz auflösen.

Übung 4 – Ziel & Zeitrahmen

Lernziel

Verstehen, dass klassisches RM Risiken dokumentiert und plant, während agiles RM Risiken durch frühe Lieferung und Transparenz reduziert.

Zeit

Klassisch: 90 min (Tag 2, 09:15–10:45 Uhr)
Agil-Input: 15 min

Material

Risikomatrix-Vorlage, Moderationskarten in zwei Farben (Eintrittswahrscheinlichkeit / Auswirkung)

Bewertung

Risikomatrix, Top-Risiken und Maßnahmenplan sind Studienleistung – Foto der Metaplanwand + agiler Kontrast werden eingereicht.

Ablauf: Klassisches Risikomanagement

Impulse für das Brainstorming: Stakeholder, Technik, Prozesse, Betriebsrat, Datenmigration. Für die Maßnahmenplanung gelten die vier Strategien: Vermeiden / Vermindern / Übertragen / Akzeptieren.

Bewertungsschema: Risikowert = Eintrittswahrscheinlichkeit (%) × Auswirkung (1–4)

Risikowert = Eintrittswahrscheinlichkeit (%) × Auswirkung (1–4)
Minimum: 20 × 1 = 20 | Maximum: 80 × 4 = 320

Agil-Kontrast: Risiken durch Lieferung auflösen

Dozenten-Input (15 min)

Wie behandelt Scrum Risiken implizit?

  • Sprint Reviews als Frühwarnsystem
  • Definition of Done als Qualitätssicherung
  • Kurze Feedbackzyklen statt Risikoregister

Gruppenaufgabe (10 min)

Welche der identifizierten Top-3-Risiken würden sich durch agiles Vorgehen von selbst erledigen – und welche nicht?

Moderationshinweise – Risikomanagement

Fallbeispiel-spezifische Risiken nutzen

Betriebsrat

Widerstand und fehlende Kooperation (Frage 03) – greifbares, reales Risiko

Frau Besserwich

Single Point of Knowledge – Ausfall würde kritisches Wissen vernichten

Unvollständige Doku in Firma B

Datenmigration wird zum Blindflug

Herr Leiter – neu im Amt

Geringe Autorität, mögliche Prioritätswechsel

Differenzierung nach Niveau