Auf Basis der User Stories – oder auf Basis der erfassten Features, Use Cases oder anderer Einheiten – wird die Anforderungsliste gebildet. Dabei handelt es sich um eine einfache Tabelle mit allen bekannten User Stories, die um alle bekannten Anforderun-gen und Arbeitsergebnisse ergänzt wird, die zur Erreichung der Projektziele umgesetzt bzw. erbracht werden müssen.

Durch den Projektauftrag wird ein Projekt offiziell autorisiert. Er ermöglicht in erster Linie dem Projektleiter, auf Ressourcen zuzugreifen und die Projektarbeit zu beginnen. Der Projektleiter wird möglichst innerhalb dieses Prozesses bestimmt oder steht schon vorher fest. Herausgeber des Projektauftrags und damit verantwortlich für das Dokument und seinen Inhalt ist der Sponsor. Es deckt folgende Themen ab:

• Motivation für das Projekt, z.B. aus wirtschaftlichen, rechtlichen oder sonstigen Anforderungen heraus
• Bestehende Anforderungen, Wünsche und Vorstellungen an den Projektverlauf und das Projektprodukt
• Sofern bereits vorhanden Vorstellungen über das Projekt-Produkt Benennung des Projektmanagers und der Teile der Organisation, die zur Umsetzung beitragen. Dazu gehören auch interne Dienste wie Controlling, Travelmanagement etc.
• Sehr grobe Meilensteinplanung, in erster Linie Wunschtermine des Kunden
• Stakeholder, die das Projekt beeinflussen können, bzw. auf deren Interessen Rücksicht genommen werden muss
• Organisatorische Rahmenbedingungen, etwa die verpflichtende Nutzung von Shared Services des Kunden, Einschränkungen in der Rollenbesetzung usw.
• Gesamtplanbudget des Projektes in groben Zahlen

Der Projektauftrag ist ein integraler Bestandteil der gesamten Methodik, da sich letztlich jede Entscheidung im Projekt an diesen Vorgaben orientieren muss.

Anhand des erteilten Projektauftrages erarbeitet der Projektmanager einen Vorschlag für die Projektorganisation. Dabei wird in diesem Schritt noch keine Rücksicht auf die Verfügbarkeit von Ressourcen genommen, es werden lediglich die Rollen festgelegt, die im Projekt besetzt werden müssen. Das Diagramm soll frühzeitig darlegen, welche Fähigkeiten im Projekt benötigt werden und wie sie eingesetzt werden sollen.

Die Projektumfangsbeschreibung ist ein Dokument, das die Zielsetzungen, eine Übersicht zu den zu erstellenden Projektergebnissen sowie die wesentlichen Annahmen zum Projekt zusammenfasst. Durch die offizielle Abnahme wird der darin beschriebene Projektumfang verbindlich festgelegt und dient damit allen Beteiligten als Referenz. Änderungen des Projektumfangs sind über ein „Change Request“-Verfahren zu berücksichtigen. Die Definition des Projektumfangs („Scope“) ist elementar für den Erfolg des Projektes, da anhand der Vorgaben kontrolliert werden kann, ob am Ende alle Aufgaben erfüllt wurden. Die Projektumfangsbeschreibung vertieft den in Kapitel 1.4 der Projekt Charter definierten Projektumfang wird daher maßgeblich durch folgende Kriterien beschrieben:

• Projekt- und Projektprodukt-Ziele
• Produktannahmekriterien
• Projektgrenzen, -anforderungen und –liefergegenstände
• Für das Projekt getroffene Annahmen und Einschränkungen
• Initial erkannte Risiken
• Initiale Work Breakdown Structure (WBS)
• Definition der Freigabeprozesse für Projektliefergegenstände und das Endprodukt

Die Definition des Projektumfangs wird in der Planungsphase verfeinert. Das Dokument ist mit Abnahme der jeweiligen Version gültig, die Inhalte gelten als vereinbart und sind damit bezüglich des Projektumfangs verbindlich. Darüber hinaus dient dieses Dokument als Basis zur Information aller relevanten Beteiligten.

Nach Möglichkeit sollte vor der Schätzung ein erstes Risikoregister zusammengestellt werden, das die rein projektbezogenen Risiken beschreibt und nach Möglichkeit auch finanziell bewertet. Das Ergebnis kann eine unmittelbare Auswirkung auf die Schätzung haben, denn Risiken müssen im geschätzten Gesamtaufwand entsprechend berücksichtigt werden.