IT-Projektmanagement

L05 Organisation und Struktur von IT-Projekten

Einleitung

In dieser Lektion werden die ausgewählten Managementmodelle Scrum, PITPM und PRINCE2 für die Organisation und Struktur von IT-Projekten gegenübergestellt.

LERNZIELE

• Welche Managementebenen in PRINCE2 unterschieden werden.
• Welche Managementprozesse es in PRINCE2 gibt und welche Ergebnisse in diesen Prozessen erzeugt werden.
• Welche Projektphasen es in PITPM gibt.
• Zu welchen Aspekten der Projektleitung entsprechende Managementpläne erstellt werden müssen.
• Mit welchen Aktivitäten die Projektleitung in PITPM ein IT-Projekt steuert.

ZUSAMMENFASSUNG

Scrum ist ein adaptives Managementmodell, das Vorhaben in kurzen Zyklen organisiert, in denen ein sich selbst organisierendes Scrum Team wirkt. Ein Scrum Team ist eine kleine Gruppe von interdisziplinären Fachleuten, die zusammen alle Kompetenzen haben, um das Produkt zu erstellen. In einem Scrum Team gibt es die drei Rollen: Product Owner, Scrum Master und Developer. Ein Zyklus in Scrum heißt Sprint, dauert höchstens einen Monat und ist strukturiert durch die Events Sprint Planning, Daily Scrum, Sprint Review sowie Sprint Retrospective. Die zentralen Elemente in Scrum sind Product Backlog, Sprint Backlog sowie das Increment.

PRINCE2 ist eine Methode für das IT-Projektmanagement für mittlere bis sehr große Projekte. Die Kernelemente von PRINCE2 sind die detaillierte Beschreibung von sieben Hauptmanagementprozessen, die daran beteiligten Rollen mit ihren Aufgaben und Zuständigkeiten sowie die im Rahmen der Aktivitäten zu erstellenden Managementartefakte. PRINCE2 unterscheidet im Rahmen eines Projekts vier verschiedene Managementebenen: Programmmanagement, Projektlenkungsausschuss, Projektleitung und Teamleitung. Jede dieser Ebenen ist dabei konkreten Managementprozessen zugeordnet.

---

5.1 Ausgewählte Managementmodelle für IT-Projekte: Scrum, PITPM und PRINCE2

	Scrum	PRINCE2	PITPM
Grundprinzip	in kurzen Zyklen organisiertes, adaptives Managementmodell	Rahmenwerk mit Prozessen, Gremien und Rollen zum Projektmanagement	Pragmatischer Managementprozess für ITProjekte auf Basis von PMBOK
Typisches Einsatzgebiet	Entwicklung komplexer Produkte in Teams bis zu zehn Personen	Steuerung mittlerer bis sehr großer Projekte	Steuerung mittelgroßer IT-Projekte
Kernelemente	- selbstorganisiertes Scrum Team - Scrum Sprint mit Scrum Events - Product-Backlog	- sieben Prozesse zur Steuerung - vier Managementebenen	- fünf Projektphasen mit Aktivitäten und Kontrollpunkten - neun Wissensgebiete
Spezifisch für IT-Vorhaben	nein	nein	ja

---

5.2 Überblick Scrum: Rollen, Events und Artefakte

Ist ein iteratives¹, inkrementelles² und stark adaptives Managementmodell, es basiert auf kurzen Zyklen und einem sich selbst organisierenden Team.

• Für die Erstellung eines komplexen "Produkts", auch außerhalb von IT-Projekten (z.B. Marketing, Forschung, Bildung).
• Es basiert auf den drei Säulen Transparenz, Überprüfung und Anpassung.

Das Scrum Team

Ist klein (max. 10 Personen), interdisziplinär und selbstorganisiert — ohne Teilteams oder Hierarchien.

Rolle	Verantwortung
Developer (im sinne von Produkt Entwickler & nicht nur Softwareentwickler)	Konstruktive Arbeit am Produkt (Konzeption, Entwicklung, Qualitätssicherung, Inbetriebnahme)
Product Owner	- Maximiert den Produktwert - erstellt, pflegt und priorisiert die Backlock-Elementen im Product Backlog - Entwicklung und Kommunikation des Produktziels - Sicherstellung von Transparenz und Verständlichkeit des Backlogs
Scrum Master	Setzt Scrum in Theorie & Praxis um; coacht das Team und beseitigt Hindernisse

Events (innerhalb eines Sprints)

Ein Sprint (Zyklus) dauert maximal einen Monat und wird ohne Pause vom nächsten gefolgt.

Event	Dauer (bei 1-Monat-Sprint)	Zweck
Sprint Planning	max. 8 Std.	- Sprint-Ziel festlegen, Product-Owner schlägt vor und Team formuliert es - Backlog-Elemente auswählen, werden im Gespräch mit dem Product-Owner von den Developern ausgewählt - Arbeit planen, Analyse der ausgewählten Backlog-Elemente durch die Developer
Daily Scrum	max. 15 Min. (täglich)	- tägliche zur selben Zeit und Ort mit alle Developer - Fortschritt prüfen und Hindernisse überwinden - geplante Arbeit aufgrund der gewonnenen Erkenntnisse anpassen, - umsetzbaren Plan für nächsten Tag erstellen
Sprint Review	max. 4 Std.	- Scrum Team stellt den relevanten Stakeholdern die Ergebnisse vor - Überprüfung der Ergebnisse - grobe Planung was als nächstes passiert und Backlog Anpassung
Sprint Retrospective	max. 3 Std.	- Team reflektiert Sprint (positive & negative Erlebnisse) - Maßnahmen zur allgemeinen Verbesserung (Zusammenarbeit & Produktqualität)

Scrum-Artefakte

Artefakt	Beschreibung
Product Backlog	- geordnete, emergente3 Liste aller zu erledigenden Arbeit - einzige quelle für alle Aufgaben - Product Backlog Refinement: Product-Owner fügt nötige Informationen zur Umsetzung den Backlog-Elementen zu
Sprint Backlog	- Backlog-Elemente für Sprint + Sprint-Ziel + Arbeitsplan für den Sprint - Developer passen kontinuierlich an
Increment	- Sprint-Backlog-Element abgeschlossen + Definition of Done erfüllt → neues Increment - am Ende des Sprints muss das Increment insgesamt verwendbar sein und wird im Sprint Review präsentiert - Elemente, die die Definition of Done nicht erfüllen, dürfen im Review nicht präsentiert werden und wandern zurück ins Product Backlog

---

5.3 Überblick und Managementebenen von PRINCE2

PRINCE2 steht für „Projects in Controlled Environments" und wurde ursprünglich als britischer Regierungsstandard für IT-Projektmanagement entwickelt. Es eignet sich vor allem für mittlere bis sehr große Projekte und beschreibt detailliert:

• 7 Hauptmanagementprozesse
• 4 Managementebenen mit klaren Rollen und Zuständigkeiten
• Konkrete Managementartefakte, die zwischen Ebenen ausgetauscht werden

Für kleine Projekte kann der administrative Aufwand aber unverhältnismäßig hoch sein.

Die 4 Managementebenen

1. Ebene: Programmmanagement / Geschäftsführung

• Externe Führungsebene (nicht Teil des eigentlichen Projektteams)
• löst das Projekt mit dem Projektmandat aus

2. Ebene: Projektlenkungsausschuss PLA (Project Board)

• Oberstes Entscheidungsgremium (kann das Projekt jederzeit beenden)
• verantwortlich für Projekterfolg (Eingesetzte Mittel -> bestmögliche Ergebnis)
• nimmt Ergebnisse ab
• Rollen:

  Projektauftraggeber (Executive):

  • Hauptverantwortlich für das Projekt
  • geben Rahmenbedingungen vor (Kosten, Zeit, Qualität, Kundenerwartung)

  Hauptnutzer (Senior User):

  • verantwortlich für Systemspezifikation, Qualität und Abnahmetest
  • Priorisierung der Anforderungen & Informationsbeschaffung

  Hauptlieferant (Senior Supplier):

  • Erstellung des Systems nach Kundenanforderung
  • überprüft Anforderungen der Hauptnutzer auf Umsetzbarkeit und Risiken

3. Ebene: Projektleitung PL (Project Manager):

• Für Leitungsaufgaben des Tagesgeschäfts verantwortlich
• Umsetzung des Projekts innerhalb der vorgegebenen Rahmenbedingungen

4. Ebene: Teamleitung TL (Team Manager):

• In kleinen Projekten optional (wird dann von Projektleitung übernommen)
• Für Erstellung der Ergebnisse verantwortlich (nur hier werden Ergebnisse erstellt)

Die 7 Managementprozesse

Vorbereiten eines Projekts (SU "Start up a Project" Ebene 2 & 3)

Aktivitäten:

• Besetzten des Managementteams (Ebene 2-4 Projektlenkungsausschuss, Projektleitung, Teamleitung)

Dokumentation:

• Erfahrungen aus vorhergehenden Projekten
• Projektsauftrag, Projektplan, Kurzversion des Business Case
• Plan-der-Phase-Projektinitiierung (Plan für die erste Phase)

Initiieren eines Projekts (IP "Initiating a Project" Ebene 3)

Aktivitäten:

• Strategien erstellen:
  • Risikomanagement (wie auf Risiken reagieren)
  • Steuerung, Erstellung und Änderung von Produkten und Artefakte
  • Qualitätsmanagement (wie Ergebnisqualität sicherstellen)
  • Kommunikationsmanagement (wie & wann Stakeholder einbinden)
  • Projektsteuerung (wer Info Projektstand; welche Managementebene wie & wann Einfluss auf Fehlentwicklungen)
• Auf basis des Projektleitdokuments entscheidet der Projektlenkungsausschuss ob das Projekt weitergeführt wird!

Dokumentation:

• Projektplan, Ausarbeitung des Business Case
• Zusammenstellung des Projektleitdokuments

Managen von Projektphasenübergängen (SB "Managing a Stage Boundary" Ebene 3)

Jedes mal nach Abschluss einer Phase und dem Beginn einer neuen Phase.

Aktivitäten:

• Aktualisieren:
  • Projektplan und Business Case
• Lenkungsausschuss über den aktuellen Projektstatus informieren.

Dokumentation:

• Phasenabschlussreport
• Phasenplan für die nächste Phase
• falls nötig Ausnahmeplan

Steuern eines Projektes (DP "Directing a Project" Ebene 2)

Erstreckt sich über mehrere Phasen.

Hauptaktivitäten:

1. "Genehmigen der Phase 'Projektinitialisierung'":
   • Lenkungsausschuss prüft Projektauftrag, Plan-der-Phase-Projektinitiierung und Business Case.
   • Erst danach startet die Phase "Projektinitiierung".
2. "Genehmigen des Projekts" (nach Phase "Projektinitiierung"):
   • Lenkungsausschuss bestätigen, dass die Projektziele und die angestrebten Ergebnisse ausreichend beschrieben und verstanden sind.
   • erst danach darf die erste produktive Projektphase starten
   • Projektleitdokument wird frei gegeben und Programmmanagement über Projektstart informiert
3. "Genehmigen des Phasen-/ Ausnahmeplans":
   • von der Projektleitung gelieferten Daten zum aktuellen Projektstatus werden geprüft und anschließend entschieden, ob das Projekt die nächste geplante Phase beginnen kann.
     • Vergleich der erzielten mit geplanten Ergebnissen
     • Prüfung der Toleranzbereiche zu Kosten, Zeit und Qualität
     • Aktualisierung des Business Case und der Projektrisikoliste
     • Begutachtung des Phasenplans zur nächsten Phase
4. "Bestätigen des Projektabschlusses"
   • Projektreview = Vergleich ursprüngliche Pläne & Ziele mit Ergebnissen
   • Auswertung des Business Case (Nutzer, Kosten, Risiken, Return of Investment)
   • Erfahrungsbericht ("Lessens learned")
   • Empfehlung für Folgeaktivitäten für die Betreuung des erstellten Systems

Steuern einer Projektphase (CS "Controlling a Stage" Ebene 3)

Zu jeder Phase.

Arbeitspakete managen:

• Arbeitspakete beauftragen
• Statusberichte prüfen
• Arbeitspakete abnehmen

Monitoring und Reporting: (um Probleme vorher zusehen)

• Prüfen des Phasenstatus
• Regelmäßiger Bericht an Lenkungsausschuss

Problemlösung:

• Probleme und Risiken aufnahmen und untersuchen
• Gegenmaßnahmen
• Eskalation an Lenkungsausschuss

Managen der Produktlieferung (MP "Managing Product Delivery" Ebene 4)

Teamplan erstellen:

• Anforderungen/Ziele mit Projektleiter verhandeln
• Teamplan zur Bearbeitung des Arbeitspakets erstellen

Regelmäßige Prüfung:

• Reporting an übergeordnete Ebene mit Standardbericht

Qualitätsgesicherte Ergebnisse erstellen:

• Vermerken der erstellten/geprüften Ergebnisse in Qualitätsbericht ("Quality Register")

Ergebnisse übergeben:

• Projektleitung nimmt Ergebnisse ab und beendet Arbeitspakete

Abschließen eines Projekts (CP "Closing a Project" Ebene 3)

Dokumente für Lenkungsausschuss:

• Projektabschlussbericht
• Erfahrungsbericht
• Entwurf für die Benachrichtigung an alle relevanten Stakeholder

Informationen für Betrieb:

• Empfehlungen für Folgeaktivitäten
• Produktinformation

Footnote

---

Footnotes

1. iteratives: in mehreren Zyklen (Sprints) ↩

2. inkrementelles: das "Produkt" wird stückweise weiter entwickelt, muss aber immer funktionsfähig bleiben ↩

3. emergente: wird kontinuierlich angepasst (niemals vollständig oder fertig) ↩