Projektmanagement on FISI Lernzettel

Agile Methoden

Mon, 01 Jan 0001 00:00:00 +0000

Agile Methoden#

Agile Methoden sind iterative, flexible Vorgehensmodelle für die Projektdurchführung — im Gegensatz zum klassischen Wasserfallmodell, bei dem alles vorab geplant wird.

1. Agiles Manifest (4 Werte)#

Das Agile Manifest (2001) formuliert vier Kernwerte:

Agile bevorzugt…	…statt…
Individuen und Interaktionen	Prozesse und Werkzeuge
Funktionierende Software	Umfassende Dokumentation
Zusammenarbeit mit dem Kunden	Vertragsverhandlungen
Reagieren auf Veränderung	Befolgen eines Plans

Beide Seiten haben Wert — aber die linke Seite wird höher bewertet.

Klassisches Projektmanagement (Wasserfall)

Mon, 01 Jan 0001 00:00:00 +0000

Klassisches Projektmanagement (Wasserfall)#

Im Gegensatz zu agilen Methoden plant das klassische (plangetriebene) Projektmanagement ein Projekt vollständig im Voraus und arbeitet die Phasen sequentiell ab.

Das Wasserfallmodell#

flowchart TD
 A[Anforderungsanalyse] --> B[Planung/Design]
 B --> C[Umsetzung]
 C --> D[Test]
 D --> E[Abnahme/Einführung]
 E --> F[Wartung]

Jede Phase wird vollständig abgeschlossen, bevor die nächste beginnt — ein Rücksprung in eine vorherige Phase ist im klassischen Modell nicht vorgesehen (im Gegensatz zu iterativen/agilen Modellen).

Merkmale#

Merkmal	Beschreibung
Planung im Voraus	Anforderungen werden zu Beginn vollständig erhoben und fixiert
Sequentieller Ablauf	Phasen werden nacheinander, nicht parallel/iterativ durchlaufen
Klare Meilensteine	Jede Phase endet mit einem definierten, abnehmbaren Ergebnis
Umfangreiche Dokumentation	Lasten-/Pflichtenheft, Spezifikationen vor Projektstart

Wasserfall vs. Agil#

Kriterium	Klassisch (Wasserfall)	Agil (Scrum/Kanban)
Anforderungen	Zu Beginn fixiert	Können sich während des Projekts ändern
Kundenfeedback	Erst am Ende (Abnahme)	Fortlaufend, nach jedem Sprint
Änderungen	Aufwendig, da spätere Phasen betroffen sind	Eingeplant, Teil des Prozesses
Eignung	Klar definierte, stabile Anforderungen (z. B. Bauprojekte, gesetzlich vorgeschriebene Systeme)	Unklare/sich ändernde Anforderungen, Softwareentwicklung
Dokumentation	Umfangreich, vorab	Schlanker, “working software over documentation”

Wasserfall eignet sich, wenn Anforderungen von Anfang an klar und stabil sind (z. B. Behörden-Projekte mit festen gesetzlichen Vorgaben). Bei unsicheren/sich ändernden Anforderungen ist ein agiles Vorgehen geeigneter.

Magisches Dreieck & Risikomanagement

Mon, 01 Jan 0001 00:00:00 +0000

Magisches Dreieck & Risikomanagement#

Jedes Projekt bewegt sich im Spannungsfeld dreier miteinander konkurrierender Ziele — und muss zugleich mit Unsicherheiten und Risiken umgehen.

Das Magische Dreieck#

flowchart TD
 Q["Qualität /<br/>Leistungsumfang"]
 Z["Zeit"]
 K["Kosten"]
 Q --- Z
 Z --- K
 K --- Q

Die drei Zieldimensionen stehen in einem Zielkonflikt: Wird eine Dimension verändert, wirkt sich das zwangsläufig auf mindestens eine der anderen aus.

Dimension	Beispiel für Verschlechterung, wenn…
Zeit	… das Projekt schneller fertig sein soll → mehr Personal (Kosten↑) oder weniger Funktionsumfang (Qualität↓)
Kosten	… das Budget gekürzt wird → weniger Zeit für Tests (Qualität↓) oder längere Laufzeit (Zeit↑)
Qualität	… mehr Funktionen gefordert werden → mehr Zeit und/oder mehr Kosten nötig

Merksatz: “Schnell, billig, gut — wählen Sie zwei.” Alle drei Ziele gleichzeitig zu optimieren ist praktisch unmöglich; gutes Projektmanagement bedeutet, diesen Zielkonflikt bewusst zu steuern und mit dem Auftraggeber zu priorisieren.

Netzplantechnik & Gantt-Diagramm

Mon, 01 Jan 0001 00:00:00 +0000

Netzplantechnik & Gantt-Diagramm#

Beide Werkzeuge visualisieren den zeitlichen Ablauf eines Projekts — die Netzplantechnik zeigt Abhängigkeiten zwischen Vorgängen, das Gantt-Diagramm den zeitlichen Verlauf als Balkenplan.

Gantt-Diagramm#

Ein Gantt-Diagramm stellt Projektvorgänge als horizontale Balken auf einer Zeitachse dar.

gantt
 dateFormat YYYY-MM-DD
 title Projektplan (Beispiel)
 section Planung
 Anforderungsanalyse :a1, 2026-01-01, 5d
 Konzept :a2, after a1, 4d
 section Umsetzung
 Entwicklung :a3, after a2, 10d
 Test :a4, after a3, 5d
 section Abschluss
 Abnahme :a5, after a4, 2d

Vorteile	Nachteile
Übersichtlich, leicht verständlich	Komplexe Abhängigkeiten schwer darstellbar
Zeigt Zeitverlauf und Parallelität	Kritischer Pfad nicht direkt ersichtlich
Gut für Statusberichte/Kommunikation	Änderungen bei vielen Abhängigkeiten aufwendig zu pflegen

Netzplantechnik#

Ein Netzplan stellt Vorgänge als Knoten dar und verbindet sie mit Pfeilen, die Abhängigkeiten (welcher Vorgang muss vor welchem abgeschlossen sein) zeigen.

Projektorganisationsformen

Mon, 01 Jan 0001 00:00:00 +0000

Projektorganisationsformen#

Ein Projekt muss organisatorisch in die bestehende Unternehmensstruktur eingebettet werden — dafür gibt es drei klassische Formen, die sich im Grad der Weisungsbefugnis des Projektleiters unterscheiden.

1. Reine Projektorganisation#

Projektmitarbeiter werden vollständig aus ihren Fachabteilungen herausgelöst und arbeiten nur noch im Projekt, dem Projektleiter direkt unterstellt.

Geschäftsleitung
 │
 Projektleiter ← volle Weisungsbefugnis
 │
 ┌─────┼─────┐
 MA1 MA2 MA3

Vorteile	Nachteile
Klare Verantwortlichkeiten, volle Entscheidungsgewalt des PL	Mitarbeiter nach Projektende ggf. schwer wieder einzugliedern
Hohe Identifikation mit dem Projekt	Doppelte Ressourcenvorhaltung (Fachabteilung + Projekt)
Schnelle Entscheidungswege	Teuer bei kurzen/kleinen Projekten

2. Matrix-Projektorganisation#

Mitarbeiter bleiben in ihrer Fachabteilung und arbeiten zusätzlich im Projekt — sie haben zwei Vorgesetzte: den Fachvorgesetzten und den Projektleiter.

Projektphasenmodelle

Mon, 01 Jan 0001 00:00:00 +0000

Projektphasenmodelle#

Unabhängig davon, ob klassisch oder agil gearbeitet wird, durchläuft praktisch jedes Projekt dieselben vier grundlegenden Phasen.

Die vier Grundphasen#

flowchart LR
 A[1. Initiierung] --> B[2. Planung]
 B --> C[3. Durchführung /<br/>Steuerung]
 C --> D[4. Abschluss]

1. Initiierung (Projektstart)#

Projektidee wird geprüft und grob bewertet (Machbarkeit, Nutzen)
Projektauftrag wird formuliert: Ziele, Rahmenbedingungen, grober Umfang
Projektleiter wird benannt, erste Stakeholder identifiziert

2. Planung#

Detaillierte Ziel-, Termin-, Kosten- und Ressourcenplanung
Erstellung von Netzplan/Gantt
Risikoanalyse (siehe magisches Dreieck & Risiko)
Ergebnis: Projektplan, der als Referenz für die Durchführung dient

3. Durchführung & Steuerung#

Eigentliche Umsetzung der geplanten Arbeitspakete
Laufende Soll-Ist-Vergleiche (Termine, Kosten, Qualität)
Bei Abweichungen: Steuerungsmaßnahmen (Nachsteuern, Eskalation, Änderungsantrag)
Läuft parallel zur Durchführung, nicht danach

4. Abschluss#

Formale Abnahme des Projektergebnisses durch den Auftraggeber
Projektdokumentation wird vervollständigt
Lessons Learned: Was lief gut, was kann beim nächsten Projekt verbessert werden?
Freigabe der Projektressourcen (Mitarbeiter, Budget)

“Durchführung” und “Steuerung” laufen gleichzeitig, nicht nacheinander — Steuerung ist die begleitende Kontrolle während der gesamten Durchführungsphase.

Ablauf eines Systemintegrationsprojekts

Mon, 01 Jan 0001 00:00:00 +0000

Ablauf eines Systemintegrationsprojekts#

Ein Systemintegrationsprojekt bringt IT-Komponenten unterschiedlicher Herkunft (Hardware, Software, Netzwerk) beim Kunden zu einer funktionierenden Gesamtlösung zusammen. Anders als das allgemeine Projektphasenmodell ist der Ablauf hier stark kundenbezogen: Vor-Ort-Termine, individuelle Ist-Aufnahme und eine enge Abstimmung mit dem Auftraggeber prägen jede Phase.

Die Phasen im Überblick#

flowchart TD
 A["1. Anforderungsanalyse /\nIst-Aufnahme vor Ort"] --> B["2. Konzepterstellung /\nLösungsvarianten"]
 B --> C["3. Angebotserstellung"]
 C --> D["4. Umsetzung /\nInstallation"]
 D --> E["5. Test / Abnahme"]
 E --> F["6. Übergabe"]

1. Anforderungsanalyse / Ist-Aufnahme#

Der Techniker verschafft sich vor Ort beim Kunden einen Überblick über die bestehende Infrastruktur (Ist-Zustand), erhebt Anforderungen im direkten Gespräch mit den Fachabteilungen und hält die Ergebnisse fest — meist im Lastenheft. Diese Phase ist das Fundament des gesamten Projekts: Fehler oder Lücken in der Ist-Aufnahme wirken sich auf alle folgenden Phasen aus und sind dort nur mit deutlich höherem Aufwand zu korrigieren.

Lastenheft & Pflichtenheft

Mon, 01 Jan 0001 00:00:00 +0000

Lastenheft & Pflichtenheft#

In Systemintegrationsprojekten mit externem Kunden ist die saubere Trennung zwischen Kundenanforderung und technischer Lösung vertraglich entscheidend. Das Lastenheft hält fest, was der Kunde braucht, das Pflichtenheft beschreibt, wie der Auftragnehmer das umsetzt — beide Dokumente sind nach DIN 69901 definierte Bestandteile des Projektmanagements. Für die einfache Beschaffung einzelner Geräte reicht meist ein kurzer Abgleich (siehe bedarfsanalyse); bei einem größeren Systemintegrationsprojekt bilden Lasten- und Pflichtenheft dagegen die formale Vertragsgrundlage für das gesamte Vorhaben.

Migrations- und Rollout-Strategien

Mon, 01 Jan 0001 00:00:00 +0000

Migrations- und Rollout-Strategien#

Eine Migration ist die Umstellung von einem bestehenden System bzw. einer bestehenden Umgebung auf eine neue — etwa der Wechsel auf einen neuen Server, ein neues ERP-System oder eine neue Netzwerkinfrastruktur. Die Wahl der richtigen Migrationsstrategie entscheidet maßgeblich darüber, wie stark der laufende Betrieb des Kunden während der Umstellung beeinträchtigt wird.

Big-Bang vs. schrittweise Migration#

Grundsätzlich stehen zwei Strategien zur Wahl:

Kriterium	Big-Bang-Migration	Schrittweise (stufenweise) Migration
Vorgehen	Umstellung auf einmal, zu einem festen Stichtag (Cutover)	Umstellung in mehreren Teilschritten/Etappen
Parallelbetrieb	Nicht vorgesehen	Altes und neues System laufen zeitweise parallel
Vorteil	Schnell abgeschlossen, kein Doppelbetrieb nötig	Geringeres Risiko, Fehler betreffen nur einen Teilbereich
Nachteil	Hohes Risiko — Fehler betreffen sofort den gesamten Betrieb	Länger und komplexer, da zwei Systeme parallel gepflegt werden müssen
Geeignet für	Kleinere, gut testbare Systeme mit kurzer Ausfalltoleranz	Große, kritische Systeme mit hohem Risiko bei Ausfall

flowchart LR
 subgraph BB["Big-Bang-Migration"]
 direction LR
 B1["Altsystem\naktiv"] --> B2["Stichtag:\nkompletter Umstieg"] --> B3["Neusystem\naktiv"]
 end
 subgraph SW["Schrittweise Migration"]
 direction LR
 S1["Altsystem\naktiv"] --> S2["Parallelbetrieb:\nTeilbereich 1 migriert"] --> S3["Parallelbetrieb:\nTeilbereich 2 migriert"] --> S4["Neusystem\nvollständig aktiv"]
 end

Je kritischer das System für den Kundenbetrieb ist, desto eher lohnt sich der höhere Aufwand einer schrittweisen Migration mit Parallelbetrieb — das Risiko eines Totalausfalls sinkt deutlich.