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