¶ Vorprojektphase
Die Vorprojektphase legt die verbindlichen Rahmenbedingungen und Leitplanken für den Projektstart fest und ist strikt von der anschließenden Initialisierungs-/Planungsphase abzugrenzen. Eine detaillierte Beschreibung der Abgrenzung des Projekts sowie der Analyse seines organisatorischen und fachlichen Umfelds erfolgt im Kapitel „Projektabgrenzung und Kontextanalyse“. Die Vorprojektphase endet erst, wenn alle relevanten Entscheidungs- und Planungsgrundlagen vorliegen: eine formale Auftragserteilung mit zugewiesenem Budget und Sponsor, eine Projektskizze (Grobplanung), ein geprüfter Business Case, eine vollständige Stakeholderliste, eine erste dokumentierte Risikobewertung, eine Empfehlung zur geeigneten Vertragsform sowie eine Go-/No-Go-Entscheidungsvorlage inklusive Entscheidungsprotokoll. Ergänzend sollten in dieser Phase Machbarkeitsannahmen, grobe Lösungsansätze, benötigte Kompetenzen und zeitliche Rahmendaten festgehalten sowie alle Ergebnisse versionsgesichert in der zentralen Projektablage hinterlegt werden. Die Entscheidung über den Übergang in die Planungsphase trifft der Sponsor bzw. der Lenkungskreis auf Basis der vorliegenden Unterlagen; das PMO unterstützt mit Templates, Reviews und Qualitätssicherung.
¶ Geschichte
Jedes Projekt bringt eine eigene „Geschichte“ mit sich. Diese Geschichte ist die Basis der Vorprojektphase und Entscheidungen und Ereignisse dieser Phase können direkte Einschränkungen oder zumindest Vorbestimmungen auf das Projekt haben. Somit gibt es einen bestimmten Handlungsspielraum und alle relevanten Informationen dieser Geschichte sollten im Rahmen der Vorprojektphase beschrieben sein.
¶ Projektübergabe vom Vertrieb
Es wird unterschieden zwischen kleinen Projekten (<1000PT) ohne Checkliste in BCS, mittleren Projekten (>1000PT) mit Checkliste in BCS und großen Projekten (>1000PT) mit Checklisten in mehrstufigen Teilprojekten. Der Projektleiter sollte im BCS die einzelnen Teilaufgaben der Checklisten prüfen und aktualisieren.
Zusätzlich wird grundsätzlich unterschieden zwischen Dienstleistungs- und Werkverträgen im Projekt. Der wesentliche Unterschied hierbei ist, dass Dienstleistungsverträge nur die Mitarbeiterkompetenzen auf bestimmte Zeit buchen, während bei einem Werksvertrag am Ende des Projektes das „Werk“ ausgeliefert werden muss. Bei Werken ist die nachfolgende Gewährleistung der Funktionen verbindlich, während bei einem Dienstleistungsvertrag die Dienstleistung nach Beendigung des Projektes vollständig beendet ist.
Die Größe des Projektes beeinflusst zusätzlich die Anzahl der Elemente und Artefakte die innerhalb des Projektes benötigt werden. Grundsätzlich gilt für alle Projekte jeglicher Größe die Bereitstellung der Pflichtelemente. Bei großen Projekten können außerdem weitere Elemente nötig sein, die den Projektfluss positiv beeinflussen.
¶ Vorgehensweise & Anforderungsermittlung
Vor der Projektplanung sollte feststehen nach welcher Vorgehensweise das Projekt bearbeitet wird. Die Anforderungen an das Projekt sollten dafür bereits klar und kommuniziert sein, da sich die Vorgehensweise maßgeblich auf die Qualität beziehungsweise auf die Strenge der Anforderungen bezieht. Sind die Anforderungen starr und wenig flexibel, eignet sich die klassische Vorgehensmethode. Sind die Anforderung noch unklar beziehungsweise flexibel, eignet sich eine agile Vorgehensmethode oder eine hybride Variante.
Die Stacey‑Matrix bietet eine erste Einordnung von Projekten anhand der Stabilität der Anforderungen und der technischen Unsicherheit. Sind Anforderungen und eingesetzte Technologien bekannt und stabil, ist ein klassisches Vorgehen meist am besten; bei unklaren, sich ändernden Anforderungen und unbekannter Technik eignet sich Agilität. Dazwischen empfiehlt sich eine hybride Vorgehensweise, die gezielt Bausteine aus klassischem und agilem Projektmanagement kombiniert. Für die Entscheidung sollte systematisch geprüft werden, wie stabil Anforderungen sind und wie hoch die technische Unsicherheit ist; darauf basierend wird die passende Methode gewählt. Da viele Projekte Zwischenstellungen aufweisen, ist eine individuelle Prüfung der Kriterien erforderlich—eine eindeutige Zuordnung ist nicht immer möglich. Für die genauere Prüfung der Kriterien kann folgende Tabelle als Leitlinie gesehen werden.
| Kriterium | Klassisch | Agil | Hyrid |
|---|---|---|---|
| Planungsansatz | Vollständig abgeschlossen, linear | Iterativ, inkrementell | Kombination aus linearem Rahmen + iterativen Zyklen |
| Flexibilität | Gering | Hoch | Mittel bis hoch |
| Zieldefinition | Früher festgelegt, schwer veränderbar | Flexibel, kann angepasst werden | Grobe Ziele festgelegt, Details agil |
| Rollen | Projektleiter, Sponsor, Team | Product Owner, Scrum Master, Team | Kombination: PL + PO + agile Teams |
| Artefakte | PSP/WBS, Meilensteine, Statusberichte | Backlogs, Inkremente, Definition of Done | PSP + Backlog, hybride Dokumentation |
| Reporting | Formal, Meilenstein-orientiert | Iterativ, Sprint Reviews |
Beide Ebenen kombiniert |
| Einsatzszenarien | Klare Anforderungen, feste Rahmenbedingungen, hohe Dokumentation | Dynamische Anforderungen, inkrementelle Entwicklung, enge Zusammenarbeit | Projekte mit Teilsystemen oder Stakeholdern, die unterschiedliche Methoden erfordern |