01. Planungsgrundlagen

Lernziele

Nach diesem Kapitel können Sie: - Die Grundlagen der Projektplanung nach ISO 21500 und PMBOK erklären - Die Dualität der Planung (Produkt- vs. Projektplanung) unterscheiden - Die Bedeutung der Reihenfolge im Planungsprozess begründen - Typische Planungsfehler in IT-Projekten identifizieren und vermeiden

Lesezeit

ca. 15-20 Minuten

1. Einführung: Warum strategische Planung in IT-Projekten?

In der IT-Beratung ist die strategische Planung das Fundament für den Projekterfolg. Eine fundierte Planung nach internationalen Standards wie ISO 21500 und dem PMBOK-Guide minimiert Risiken und maximiert die Wahrscheinlichkeit der Zielerreichung.

IT-Projekte unterscheiden sich durch ihre Komplexität und Dynamik von klassischen Bauprojekten. Während bei einem Hausbau die Anforderungen zu Beginn meist klar definiert sind, ändern sich in IT-Projekten Anforderungen, Technologien und Rahmenbedingungen oft während der Umsetzung. Dies macht eine sorgfältige, methodische Planung umso wichtiger.

1.1 Die Rolle des IT-Beraters im Planungsprozess

Als IT-Berater nehmen Sie eine Schlüsselposition im Planungsprozess ein. Ihre Aufgaben umfassen:

flowchart TD
    A[IT-Berater] --> B[Anforderungserhebung]
    A --> C[Methodenberatung]
    A --> D[Risikoanalyse]
    A --> E[Entscheidungsvorbereitung]

    B --> F[Verständnis der fachlichen Ziele]
    C --> G[Anwendung internationaler Standards]
    D --> H[Identifikation von Planungsrisiken]
    E --> I[Fundierte Empfehlungen an Management]

    F --> J[Erfolgreiche Projektumsetzung]
    G --> J
    H --> J
    I --> J

2. Internationale Standards für die Projektplanung

2.1 ISO 21500 - Guidance on Project Management

Die ISO 21500 (International Standard for Project Management Guidance) provides umfassende Leitlinien für das Projektmanagement. Sie wurde 2012 veröffentlicht und bietet einen universellen Rahmen, der branchenübergreifend anwendbar ist.

Kernelemente der ISO 21500:

Bereich	Beschreibung	Relevanz für IT-Projekte
Themenbereiche	39 Themenbereiche vom Projektstart bis zum Abschluss	Strukturierte Vorgehensweise
Prozesse	Prozessorientierte Darstellung der Projektmanagement-Tätigkeiten	Wiederholbare Qualität
Stakeholder	Systematisches Management aller Beteiligten	Einbeziehung aller Interessen
Integration	Zusammenführung aller Management-Disziplinen	Ganzheitlicher Ansatz

Die ISO 21500 ist bewusst technologie- und methodenneutral gestaltet. Sie beschreibt WAS zu tun ist, nicht WIE es zu tun ist. Dies ermöglicht es Organisationen, den Standard an ihre spezifischen Bedürfnisse anzupassen.

2.2 PMBOK Guide - Project Management Body of Knowledge

Der PMBOK Guide (Project Management Body of Knowledge) des Project Management Institute (PMI) ist der weltweit am weitesten verbreitete Standard für das Projektmanagement.

PMBOK Process Groups:

flowchart LR
    PG[Project Management Process Groups] --> IP[Initiating]
    PG --> PP[Planning]
    PG --> EX[Executing]
    PG --> M[Monitoring & Controlling]
    PG --> CL[Closing]

    IP --> PP
    PP --> EX
    EX --> M
    M --> CL
    M --> PP

Die 5 Wissensgebiete mit hoher IT-Relevanz:

Scope Management - Definition und Steuerung des Leistungsumfangs
Time Management - Zeitplanung und Meilenstein-Management
Cost Management - Kostenschätzung und Budgetsteuerung
Quality Management - Qualitätssicherung und -kontrolle
Risk Management - Identifikation und Behandlung von Risiken

Vergleich ISO 21500 vs. PMBOK:

Aspekt	ISO 21500	PMBOK Guide
Fokus	Guidance, kein Zertifizierungsstandard	Umfassendes Wissenssystem
Anwendung	Universell, alle Branchen	Starker US-Fokus, breit akzeptiert
Zertifizierung	Nein	Ja (PMP, CAPM)
Detaillierungsgrad	Kompakt, übersichtlich	Sehr detailliert
Praxisorientierung	Hoch	Mittel bis hoch

2.3 Anwendung in der IT-Beratung

In der IT-Beratung ist es üblich, Elemente beider Standards zu kombinieren. Ein typischer Ansatz:

Struktur: PMBOK für die prozessuale Gliederung
Leitlinien: ISO 21500 für die inhaltliche Ausrichtung
Anpassung: Unternehmensspezifische Methoden und Templates

3. Die Dualität der Planung: Produkt- vs. Projektplanung

3.1 Konzeptuelle Unterscheidung

Ein zentraler Aspekt der strategischen Planung ist die Dualität der Planung: Die Trennung zwischen der Produktplanung (Was bauen wir?) und der Projektplanung (Wie setzen wir es um?).

flowchart TD
    A[Planungsprozess] --> B[Produktplanung]
    A --> C[Projektplanung]

    B --> B1[Leistungsumfang definieren]
    B --> B2[Architektur entwerfen]
    B --> B3[Anforderungen spezifizieren]
    B --> B4[Technologieentscheidungen treffen]

    C --> C1[Zeitplan erstellen]
    C --> C2[Ressourcen planen]
    C --> C3[Kosten schätzen]
    C --> C4[Risiken identifizieren]

    B1 --> D[Stabiles Produktkonzept]
    B2 --> D
    B3 --> D
    B4 --> D

    D --> C1
    D --> C2
    D --> C3
    D --> C4

3.2 Produktplanung - "Was bauen wir?"

Die Produktplanung konzentriert sich auf den zu erstellenden Gegenstand (Produkt, Service, Ergebnis). Sie beantwortet die Frage nach dem funktionalen Zielbild.

Elemente der Produktplanung:

Komponente	Beschreibung	Beispiel
Produktziele	Strategische und operative Ziele	"Automatisierung der Rechnungsprüfung um 50%"
Funktionale Anforderungen	Was muss das System können?	"Import von PDF-Rechnungen", "Validierung gegen Stammdaten"
Nicht-funktionale Anforderungen (NFRs)	Qualitätsmerkmale	"Antwortzeit < 3 Sekunden", "Verfügbarkeit 99.9%"
Architektur	Struktur des Systems	"Microservice-Architektur mit API Gateway"
Schnittstellen	Integrationen zu anderen Systemen	"Schnittstelle zum ERP-System", "Bankdaten-Anbindung"
Datenmodell	Struktur der Daten	"Kundenstammdaten", "Rechnungspositionen"

Best Practice in der Produktplanung:

Agile Iteration: Produktplanung ist nicht statisch, sondern wird iterativ verfeinert
Early Prototyping: Schnelle Visualisierungen für besseres Verständnis
Stakeholder-Validation: Regelmäßige Abstimmung mit Fachbereich und Management
MVP-Fokus: Konzentration auf Minimal Viable Product für schnelleren Markteintritt

3.3 Projektplanung - "Wie setzen wir es um?"

Die Projektplanung fokussiert auf die operative Umsetzung. Sie beantwortet die Frage nach dem Weg zum Ziel.

Elemente der Projektplanung:

Komponente	Beschreibung	Beispiel
Arbeitspakete	Konkrete Aufgaben	"Entwicklung PDF-Parser", "Integrationstests"
Meilensteine	Bedeutende Zwischenziele	"Abnahme Konzept", "Go-Live"
Zeitplan	Zeitliche Abfolge	"Monat 1-2: Konzeption", "Monat 3-5: Entwicklung"
Ressourcen	Personen, Rollen, Skills	"2 Senior Developer", "1 Tester"
Kosten	Budgetierung	"Software-Lizenzen: €50k", "Externe Beratung: €120k"
Risikomanagement	Identifikation und Behandlung	"Risiko: Skill-Mangel", "Maßnahme: Training"

3.4 Die Gefahr der falschen Reihenfolge

Ein häufiger Fehler in der Praxis ist der verfrühte Start der Projektplanung bei noch vagem Produktkonzept.

flowchart LR
    A[Start Projektplanung<br>bei vagem Konzept] --> B[Unzuverlässige Schätzungen]
    A --> C[Falsche Ressourcenplanung]
    A --> D[Unrealistischer Zeitplan]

    B --> E[Nacharbeiten]
    C --> E
    D --> E

    E --> F[Projektverzögerung]
    E --> G[Budgetüberschreitung]
    E --> H[Motivationsverlust]

    F --> I[Projektfailure]
    G --> I
    H --> I

Das Problem "Building the wrong thing right":

Wenn Sie mit der Projektplanung beginnen, bevor das Produktkonzept stabil ist, riskieren Sie, die falsche Sache perfekt zu bauen.

Beispiel: - Ein Unternehmen möchte ein neues CRM-System einführen - Die Projektplanung beginnt sofort: 12 Monate, €500k Budget, 5 Mitarbeiter - Nach 6 Monaten stellt sich heraus: Die Anforderungen wurden falsch verstanden - Das geplante System entspricht nicht den Bedürfnissen des Vertriebs - Ergebnis: Monate Entwicklung verschwendet, Budget verbraucht, System muss komplett neu geplant werden

3.5 Empfohlener Planungsprozess

Der empfohlene Prozess folgt einem sequentiellen Ansatz mit Rückkopplungsschleifen:

stateDiagram-v2
    [*] --> Produktvision
    Produktvision --> Anforderungsanalyse
    Anforderungsanalyse --> Konzeptentwicklung
    Konzeptentwicklung --> Architekturplanung

    Architekturplanung --> Validierung: Fachbereich-Abstimmung
    Validierung --> Architekturplanung: Anpassungen
    Validierung --> Projektplanung: Konzept stabilisiert

    Projektplanung --> Detaillierung: Zeitplan
    Projektplanung --> Detaillierung: Ressourcen
    Projektplanung --> Detaillierung: Budget

    Detaillierung --> Finalisierung: Freigabe durch Management
    Finalisierung --> Umsetzung
    Umsetzung --> [*]

Checkliste für den Übergang zur Projektplanung:

Produktziele sind klar definiert und von allen Stakeholdern akzeptiert
Funktionale Anforderungen sind vollständig dokumentiert
Nicht-funktionale Anforderungen sind spezifiziert
Architektur ist definiert und dokumentiert
Technologien sind ausgewählt (oder die Auswahl ist bewusst offen)
Schnittstellen zu bestehenden Systemen sind identifiziert
Risiken auf Produktebene sind identifiziert und bewertet

4. Typische Planungsfehler und wie man sie vermeidet

4.1 Übersicht häufiger Fehler

Fehler	Beschreibung	Auswirkung	Vermeidung
Verfrühte Projektplanung	Projektplanung bei unklarem Produkt	"Wrong thing right"	Konzept stabilisieren vor Planung
Scope Creep	Unkontrollierte Anforderungen	Zeit- und Budgetüberschreitung	Änderungsmanagementprozess
Detailverliebtheit	Zu früh zu detailliert	Verlust der Agilität	Iterative Verfeinerung
Ignorieren von NFRs	Fokus nur auf Funktionale	Probleme in Produktion	NFRs von Anfang an einbeziehen
Mangelnde Stakeholder-Einbindung	Entscheidung im Stillen	Widerstand, Nacharbeiten	Regelmäßige Kommunikation
Over-Engineering	Zu komplexe Lösungen	Hohe Kosten, schwierige Wartung	MVP-Ansatz, YAGNI-Prinzip

4.2 Deep Dive: Scope Creep

Scope Creep bezeichnet die unkontrollierte Ausweitung des Projektumfangs über die ursprünglich definierten Anforderungen hinaus.

Typische Ursachen:

Mangelnde Anforderungsdokumentation: Anforderungen sind nicht klar und vollständig definiert
Mangelnde Kommunikation: Anforderungen ändern sich, aber alle Beteiligten werden nicht informiert
Mangelndes Änderungsmanagement: Änderungen werden nicht systematisch bewertet
Gold-Plating: Team führt zusätzliche Features ein, die nicht angefordert wurden
Druck von Stakeholdern: Anforderungen werden nachträglich ergänzt

Beispiel aus der Praxis:

Ein Unternehmen plant die Einführung eines neuen Intranets mit folgenden Anforderungen: - Mitarbeiterverzeichnis - News-Seite - Dokumentenbibliothek

Während des Projekts kommen sukzessive hinzu: - "Könnten wir auch ein Forum hinzufügen?" - "Wir bräuchten auch einen Kalender für Team-Events" - "Es wäre toll, wenn man auch Blogs schreiben könnte" - "Für das Onboarding neuer Mitarbeiter bräuchten wir noch..."

Ergebnis: Aus einem 3-Monats-Projekt mit €100k Budget wird ein 9-Monats-Projekt mit €350k Budget - mit entsprechend höherem Risiko für das Scheitern.

Vermeidungsstrategien:

Klarest Anforderungsmanagement
Anforderungen schriftlich dokumentieren
Priorisierungen vornehmen (Must-have vs. Nice-to-have)
Abnahmekriterien definieren
Formalisierte Änderungsprozesse
Änderungsantrag dokumentieren
Auswirkungen analysieren (Zeit, Kosten, Qualität, Risiko)
Entscheidung durch Projektlenkungsausschuss
Kommunikationsmanagement
Regelmäßige Updates an alle Stakeholder
Transparente Darstellung von Auswirkungen
Klare Priorisierung bei Ressourcenkonflikten

4.3 Deep Dive: Ignorieren von NFRs (Nicht-funktionale Anforderungen)

Nicht-funktionale Anforderungen (NFRs) beschreiben, WIE das System funktionieren soll, nicht WAS es tut. Sie werden oft als "zweitrangig" angesehen, sind aber entscheidend für den Projekterfolg.

Wichtige NFR-Kategorien:

Kategorie	Beispiele	Konsequenzen bei Nichtbeachtung
Performance	Antwortzeiten, Durchsatz	Unzufriedene Benutzer, Verlust von Geschäftswert
Sicherheit	Authentifizierung, Verschlüsselung	Datenlecks, Compliance-Verstöße
Verfügbarkeit	Uptime, Recovery-Zeiten	Produktionsausfälle, Umsatzverluste
Skalierbarkeit	Lastverteilung, Speicherwachstum	Systemausfall bei Peak-Lasten
Usability	Bedienbarkeit, Accessibility	Geringe Akzeptanz, Fehlbedienungen
Wartbarkeit	Code-Qualität, Dokumentation	Hohe Folgekosten, Schwierigkeiten bei Erweiterungen
Compliance	DSGVO, ISO 27001, SOX	Rechtliche Konsequenzen, Bußgelder

Beispiel: Performance ignoriert

Ein E-Commerce-Unternehmen entwickelt ein neues Bestellsystem: - Fokus: Alle funktionalen Anforderungen (Produktsuche, Warenkorb, Bezahlung) werden perfekt implementiert - Ignorierte NFR: "Antwortzeit bei Produktliste < 2 Sekunden bei 1.000 gleichzeitigen Benutzern"

Ergebnis nach Go-Live: - Während der Black-Friday-Kampagne brechen die Seitenlastzeiten auf >10 Sekunden ein - 40% der Benutzer brechen den Kaufvorgang ab - Umsatzverlust: schätzungslich €500.000 an diesem Wochenende - Reputationsverlust: Negative Bewertungen in sozialen Medien - Folgekosten: Notfall-Optimierung, Hardware-Umrüstung

Best Practice für NFRs:

flowchart TD
    A[Anforderungserhebung] --> B[Funktionale Anforderungen]
    A --> C[Nicht-funktionale Anforderungen]

    B --> D[User Stories / Use Cases]
    C --> E[Qualitätsattribute]

    E --> F[Performance]
    E --> G[Sicherheit]
    E --> H[Verfügbarkeit]
    E --> I[Usability]

    F --> J[Quantifizierte Ziele<br/>z.B. "Antwortzeit < 2s bei 1.000 Usern"]
    G --> J
    H --> J
    I --> J

    J --> K[Architektur-Design]
    K --> L[Technologieentscheidung]
    L --> M[Implementierung]
    M --> N[Testen & Validieren]
    N --> O[Monitoring in Produktion]

5. Die Rolle der Planung im Projekt-Lebenszyklus

5.1 Phasenmodell

Ein IT-Projekt durchläuft typischerweise verschiedene Phasen, in denen die Planung unterschiedliche Ausprägungen hat:

Phase	Planungsfokus	Planungsart	Typische Ergebnisse
Initiierung	Machbarkeit, Rahmenbedingungen	Strategisch	Projekt Charter, Vorstudie
Konzeption	Was bauen wir?	Produktplanung	Soll-Konzept, Lösungskonzept
Planung	Wie bauen wir es?	Projektplanung	Projektplan, Budget, Ressourcen
Umsetzung	Detaillierung und Anpassung	Taktisch	Sprint-Planung, Detail-Design
Abschluss	Lessons Learned, Transition	Reflexiv	Abschlussbericht, Übergabedokumentation

5.2 Iterative Planung (Agile vs. Wasserfall)

Die Art der Planung hängt stark von der gewählten Projektmethode ab.

Wasserfall (V-Modell):

flowchart TD
    A[Anforderungen] --> B[Design]
    B --> C[Implementierung]
    C --> D[Testen]
    D --> E[Betrieb]

    style A fill:#e1f5ff
    style B fill:#e1f5ff
    style C fill:#fff4e1
    style D fill:#fff4e1
    style E fill:#ffe1e1

Charakteristik: Sequenzielle Phasen, umfassende Planung vor Start
Vorteile: Klarer Überblick, gut planbare Kosten und Termine
Nachteile: Geringe Flexibilität, späte Rückmeldung
Einsatz: Feste Anforderungen, kritische Systeme (z.B. medizinische Geräte)

Agil (Scrum):

flowchart LR
    subgraph Iteration ["Sprint (2-4 Wochen)"]
        A[Planning] --> B[Development]
        B --> C[Review]
        C --> D[Retrospective]
    end

    D --> A

Charakteristik: Kurze Iterationen, kontinuierliche Planung
Vorteile: Flexibel, schnelle Rückmeldung, höhere Kundenzufriedenheit
Nachteile: Unklarer Gesamtaufwand, erfordert Disziplin
Einsatz: Unsichere Anforderungen, innovative Produkte

Hybrid-Ansätze:

In der Praxis ist eine Kombination oft sinnvoll:

Phase	Ansatz	Begründung
Produktplanung	Initial umfassend, dann iterativ	Klare Vision, aber Flexibilität für Anpassungen
Projektplanung	Rolling Wave Planning	Detaillierung "just in time"
Anforderungen	MoSCoW-Priorisierung	Fokus auf Wichtiges, Flexibilität für Änderungen

6. Zusammenfassung und Praxis-Checklisten

6.1 Kernpunkte dieses Kapitels

Internationale Standards (ISO 21500, PMBOK) bieten bewährte Leitlinien für die Projektplanung
Dualität der Planung: Produktplanung (Was?) und Projektplanung (Wie?) müssen getrennt werden
Reihenfolge ist entscheidend: Projektplanung sollte erst bei stabilem Produktkonzept starten
NFRs nicht vergessen: Nicht-funktionale Anforderungen sind entscheidend für den Erfolg
Agilität vs. Kontrolle: Wählen Sie die Planungsmethode passend zum Projekttyp

6.2 Praktische Checklisten

Checkliste: Produktplanung vollständig?

Checkliste: Projektplanung sinnvoll starten?

Produktkonzept ist stabil und akzeptiert
Umfang ist klar begrenzt (Scope definiert)
Änderungsmanagement ist etabliert
Stakeholder sind informiert und eingebunden
Ressourcen sind grob geschätzt
Risiken auf Projektebene sind identifiziert

6.3 Reflexionsfragen für IT-Berater

Bevor Sie mit der Planung eines neuen Projekts beginnen, stellen Sie sich folgende Fragen:

Ist das Produktkonzept wirklich stabil? Oder gibt noch offene Fragen?
Sind alle Stakeholder identifiziert? Wer könnte noch betroffen sein, den wir nicht kennen?
Sind die Anforderungen wirklich verstanden? Haben wir Use Cases oder User Stories erstellt?
Sind die NFRs spezifiziert? Wie lautet die Performance-Anforderung quantifiziert?
Welche Planungsmethode passt zum Projekt? Wasserfall, Agil oder Hybrid?
Haben wir Lessons Learned aus ähnlichen Projekten betrachtet? Was lief dort gut/schlecht?
Wann werden wir die Planung validieren? Gibt es Meilensteine für Review-Schleifen?

Schlüsselbegriffe

Begriff	Definition
ISO 21500	Internationaler Standard für Projektmanagement-Leitlinien, technologie- und methodenneutral
PMBOK Guide	Project Management Body of Knowledge, umfassendes Wissenssystem des PMI
Produktplanung	Planung des zu erstellenden Produkts (Was bauen wir?), Fokus auf Funktionen und Architektur
Projektplanung	Planung der Umsetzung (Wie bauen wir es?), Fokus auf Zeit, Kosten und Ressourcen
Dualität der Planung	Trennung von Produkt- und Projektplanung, um "building the wrong thing right" zu vermeiden
NFR (Non-Functional Requirements)	Nicht-funktionale Anforderungen (Performance, Sicherheit, Verfügbarkeit etc.)
Scope Creep	Unkontrollierte Ausweitung des Projektumfangs ohne Anpassung von Zeit und Budget
Rolling Wave Planning	Iterative Planungsmethode, bei der Details erst kurz vor der Umsetzung festgelegt werden
MVP (Minimal Viable Product)	Minimale produktfähige Version mit den wichtigsten Funktionen
YAGNI (You Aren't Gonna Need It)	Prinzip, keine Funktionen zu implementieren, die nicht aktuell benötigt werden

Verständnisfragen

Frage 1: Reihenfolge der Planungsphasen

Ein Kunde möchte ein neues Portal für seine Mitarbeiter entwickeln. Er fordert, dass Sie sofort mit der Zeitplanung, Ressourcenplanung und Budgetierung (Projektplanung) beginnen, obwohl die funktionalen Anforderungen noch nicht vollständig geklärt sind. Erklären Sie ihm methodisch fundiert, warum dies problematisch ist und welcher Ansatz empfohlen wird.

Lösung: Dies ist ein klassischer Fehler in der IT-Projektplanung. Die Projektplanung baut auf den Ergebnissen der Produktplanung auf. Ohne geklärte Anforderungen sind Schätzungen zu Zeit, Kosten und Ressourcen höchst unzuverlässig. Es besteht ein hohes Risiko, "das Falsche richtig zu bauen" (Building the wrong thing right), was zu massiven Nacharbeiten führt.

Der empfohlene Ansatz: 1. Zuerst Produktplanung: Klärung der Anforderungen, Erstellung des Soll-Konzepts, Definition der Architektur 2. Validierung: Abstimmung mit Stakeholdern,确保 das Konzept die Bedürfnisse trifft 3. Dann Projektplanung: Erst nach stabilisiertem Produktkonzept beginnen mit Zeitplan, Ressourcen und Budget

Begründung: "So wie ein Architekt erst den Bauplan erstellt, bevor der Rohbau geplant und kalkuliert wird, müssen wir zuerst klären, WAS wir bauen, bevor wir planen können, WIE und WANN wir es bauen."

Frage 2: NFRs vs. Funktionale Anforderungen

Sie beraten ein E-Commerce-Startup bei der Entwicklung einer neuen Bestellplattform. Das Entwicklungsteam fokussiert sich ausschließlich auf die funktionale Umsetzung (Produktkatalog, Warenkorb, Bezahlung). Welche nicht-funktionale Anforderungen (NFRs) könnten für dieses Projekt kritisch sein und warum sollten sie nicht ignoriert werden?

Lösung: Für ein E-Commerce-System sind folgende NFRs kritisch:

Performance: "Antwortzeit < 2 Sekunden bei 1.000 gleichzeitigen Benutzern" - Langsame Ladezeiten führen zu hoher Abbruchrate bei Bestellungen
Verfügbarkeit: "Uptime 99.9% (max. 8h Ausfall pro Jahr)" - Jeder Ausfall bedeutet direkten Umsatzverlust
Sicherheit: "DSGVO-konforme Datenhaltung, PCI-DSS-Compliance für Zahlungsdaten" - Datenschutzlecks führen zu Bußgeldern und Reputationsschäden
Skalierbarkeit: "Lastverteilung möglich für 10.000 gleichzeitige Benutzer" - Das System muss mit Wachstum skalieren können
Usability: "Mobile-Friendly, Accessibility nach WCAG 2.1" - Gute Usability steigert die Konversionsrate

Ignorieren dieser NFRs führt typischerweise zu Problemen in der Produktion, die teuer zu beheben sind und das Geschäft gefährden können. Ein Produkt mit perfekten Funktionen, aber schlechter Performance oder Sicherheit, ist im Markt nicht konkurrenzfähig.

Frage 3: Agile vs. Wasserfall

Ein Kundenunternehmen entwickelt eine neue Software für die Logistik-Steuerung. Es handelt sich um ein System mit harten Sicherheitsanforderungen und Compliance-Vorgaben. Beraten Sie das Unternehmen, welche Planungsmethode (Wasserfall, Agil oder Hybrid) am besten geeignet ist und begründen Sie Ihre Empfehlung.

Lösung: Für dieses Projekt empfiehlt sich ein Hybrid-Ansatz mit folgenden Elementen:

Gründe für teilweise Wasserfall-Elemente: - Harte Sicherheitsanforderungen erfordern umfassende Planung und Validierung vor Implementierung - Compliance-Vorgaben (z.B. für Logistik-Systeme in regulierten Branchen) benötigen klare Dokumentation - Fehlende Flexibilität bei Sicherheitsaspekten (können nicht "im Nachhinein" ergänzt werden)

Gründe für agile Elemente: - Unklare Anforderungen im Detail (Logistik-Prozesse sind komplex) - Schnelle Rückmeldung der Anwender aus der Praxis - Risiko: Falsche Annahmen im Konzept, die erst spät entdeckt werden

Empfohlener Hybrid-Ansatz: - Phase 1 (Wasserfall): Detaillierte Produktplanung für Sicherheit und Compliance (Sicherheitskonzept, Datenschutzkonzept, Compliance-Checkliste) - Phase 2 (Agil): Iterative Entwicklung der funktionalen Logistik-Features mit regelmäßigen Sprints - Phase 3 (Wasserfall): Formale Validierung und Zertifizierung nach Funktionalitätserfüllung

Begründung: Die kritischen, unflexiblen Aspekte (Sicherheit, Compliance) werden im Voraus geplant, während die komplexen, unklaren Aspekte (Funktionalität) iterativ entwickelt werden. Dies kombiniert die Vorteile beider Ansätze.