Projektauftrag: Was er ist und wie man ihn schreibt (Vorlage)

Ein Projektauftrag ist das einzige Dokument, das ein Projekt formal ins Leben ruft. Ihn zu überspringen ist eine der zuverlässigsten Methoden, um sicherzustellen, dass ein Projekt über Budget, über Zeit oder über die Geduld aller läuft.

Die meisten Teams stürzen sich direkt auf Aufgaben, bevor irgendjemand darüber einig ist, was das Projekt eigentlich erreichen soll. Der Projektauftrag existiert, um diese Lücke zu schließen. Er erzwingt das Gespräch über Zweck, Erfolgskriterien und Entscheidungsbefugnis, bevor die erste Aufgabe vergeben wird.

Was ist ein Projektauftrag?

Ein Projektauftrag ist ein formales Dokument, das ein Projekt autorisiert zu beginnen, dessen übergeordnete Ziele definiert und dem Projektmanager die Befugnis erteilt, organisatorische Ressourcen zu nutzen. Er ist der Gründungsvertrag zwischen dem Projektsponsor, dem Projektmanager und der Organisation.

Der Begriff stammt aus dem Project Management Body of Knowledge (PMBOK), wo PMI den Projektauftrag als Ausgabe der Initiierungsprozessgruppe definiert. In der Praxis beantwortet der Projektauftrag vorab vier Fragen: Warum machen wir das? Was werden wir produzieren? Wer ist verantwortlich? Und woran erkennen wir Erfolg?

Ein Projektauftrag ist kein detaillierter Zeitplan, keine Aufgabenliste und keine technische Spezifikation. Er ist ein kurzes, übergeordnetes Dokument von typischerweise zwei bis sechs Seiten, das einem Projekt seinen offiziellen Startpunkt gibt. Alles, was danach kommt, der Projektplan, der Projektstrukturplan, der Gantt-Chart, baut auf dem Fundament auf, das der Projektauftrag legt.

Wichtige Fakten

• Gemäß PMBOK 7th Edition ist der Projektauftrag das Dokument, das ein Projekt formal autorisiert zu beginnen, und dem Projektmanager die Befugnis erteilt, Ressourcen einzusetzen (PMI, 2021).
• Projekte mit einem dokumentierten Projektauftrag erfüllen ihre ursprünglichen Ziele und Geschäftsabsichten 2,5-mal häufiger (PMI Pulse of the Profession, 2023).
• Der durchschnittliche Projektauftrag ist in den meisten Unternehmen 2 bis 6 Seiten lang, mit Tendenz zu mehr Seiten in regulierten Branchen (PMI-Community-Umfrage, 2024).

Warum ein Projektauftrag wichtig ist

Projekte scheitern aus vorhersehbaren Gründen. Umfangsausweitung, falsch ausgerichtete Stakeholder, unklare Verantwortlichkeiten und vage Erfolgskriterien tauchen in Nachbetrachtungen immer wieder auf. Ein gut geschriebener Projektauftrag greift alle vier direkt an.

Abstimmung des Projektsponsors ist der erste Gewinn. Ein unterzeichneter Projektauftrag bedeutet, dass der Sponsor Zweck, Budgetrahmen und Erfolgskriterien gelesen und zugestimmt hat. Wenn später Umfangsstreitigkeiten entstehen, ist der Projektauftrag der Referenzpunkt, auf den alle zurückgreifen. Ohne ihn werden diese Gespräche zu Debatten über Erinnerungen und Absichten.

Stakeholder-Zustimmung entsteht natürlich, wenn der Projektauftragsprozess Meinungsverschiedenheiten frühzeitig ans Licht bringt. Verschiedene Abteilungen haben oft unterschiedliche Annahmen darüber, was ein Projekt liefern wird. Das Schreiben des Projektauftrags zwingt diese Annahmen ins Freie, wo sie gelöst werden können, bevor die Arbeit begonnen hat, statt nachdem sie läuft.

Klärung der Befugnis ist wichtiger als die meisten Teams zugeben. Der Projektauftrag erteilt dem Projektmanager ausdrücklich das Recht, Ressourcen zuzuweisen, Entscheidungen zu treffen und Blocker zu eskalieren. Das klingt selbstverständlich, aber in Matrixorganisationen, wo Ressourcen an funktionale Manager berichten, ist ein unterzeichneter Projektauftrag der Unterschied zwischen einem Projektmanager, der Dinge bewegen kann, und einem, der seine Zeit damit verbringt, um Zugang zu verhandeln.

Und die Daten belegen es. PMIs Forschung zeigt, dass Projekte mit Projektauftrag ihre ursprünglichen Ziele 2,5-mal häufiger erfüllen. Das ist keine marginale Verbesserung. Es ist der Unterschied zwischen einem Projekt, das liefert, und einem, das stillschweigend zur Abschreckungsgeschichte wird.

Die 10 Abschnitte eines Projektauftrags

Jeder effektive Projektauftrag deckt diese zehn Bereiche ab. Sie brauchen keine Vorlage mit starren Abschnittsüberschriften, aber Sie brauchen jedes Konzept, irgendwo im Dokument.

1. Projektname: Ein klarer, beschreibender Name, den das Team und Stakeholder konsistent verwenden werden. Vermeiden Sie interne Codenamen, die außerhalb des unmittelbaren Teams nichts bedeuten.

2. Zweck und Begründung: Warum wird dieses Projekt durchgeführt? Welches Geschäftsproblem löst es oder welche Chance nutzt es? Dieser Abschnitt sollte messbare Ausgangsdaten referenzieren: verlorener Umsatz, Compliance-Risiko, Kundenbeschwerden oder Markt-Timing.

3. Ziele und Erfolgskriterien: Was wird das Projekt erreichen, und woran erkennt man, dass es erfolgreich war? Ziele sollten dem SMART-Format folgen (spezifisch, messbar, erreichbar, relevant, terminiert). Vage Ziele wie „die Kundenerfahrung verbessern" funktionieren hier nicht. „Die durchschnittliche Onboarding-Zeit von 14 Tagen auf 7 Tage bis Q4 reduzieren" schon.

4. Übergeordnete Anforderungen: Die wesentlichen Bedingungen, die der endgültige Liefergegenstand erfüllen muss. Kein vollständiges Anforderungsdokument, aber genug Spezifität, damit Stakeholder darüber einig sind, was „fertig" bedeutet. Denken Sie daran als kurze Liste der Nicht-Verhandelbaren.

5. Umfang und Liefergegenstände: Was ist ausdrücklich im Umfang, und was ist ausdrücklich außerhalb des Umfangs. Beide Seiten der Grenze sind wichtig. Wenn etwas zweideutig ist, benennen Sie es. Das Nennen dessen, was außerhalb des Umfangs liegt, verhindert Umfangsausweitung genauso klar wie das Nennen dessen, was drinnen ist.

6. Meilensteine: Die wichtigsten Etappenpunkte im Projektzeitplan mit Zieldaten. Das ist kein vollständiger Zeitplan. Es sind die fünf bis zehn Momente, in denen das Projekt bedeutsamen Fortschritt demonstrieren wird: Ende der Erkundung, erster Prototyp, Pilot-Launch, vollständiges Deployment, Projektabschluss.

7. Budget: Der genehmigte Finanzierungsrahmen und wichtige Kostenkategorien. Manche Organisationen nennen nur den Gesamtbetrag; andere schlüsseln ihn nach Phase oder Ressourcentyp auf. Entscheidend ist, dass ein Sponsor eine spezifische Zahl, kein Band, unterzeichnet hat.

8. Stakeholder: Wer ein Interesse am Ergebnis hat, wer betroffen sein wird und wer konsultiert oder informiert werden muss. Das entspricht direkt der RACI-Matrix, die später bei der Planung kommt. Die Projektauftragsversion ist übergeordneter: Namen, Rollen und deren Beziehung zum Projekt.

9. Risiken und Annahmen: Bekannte Risiken, die das Projekt beeinflussen könnten, mit einer kurzen Notiz zu Wahrscheinlichkeit oder Auswirkung. Und Annahmen, Dinge, die Sie ohne vollständige Bestätigung als wahr behandeln. Beide verdienen Aufmerksamkeit, weil eine unbestrittene Annahme nur ein Risiko ist, das Sie noch nicht anerkannt haben.

10. Genehmigungsunterschriften: Die formelle Freigabe durch den Projektsponsor und weitere erforderliche Genehmiger. Das ist der Schritt, der das Dokument von einem Entwurf in eine Autorisierung verwandelt. Ohne Unterschriften ist der Projektauftrag empfehlend. Mit ihnen hat er organisatorisches Gewicht.

Projektauftrag vs. Projektplan vs. Umfangsbeschreibung

Diese drei Dokumente sind verwandt, dienen aber unterschiedlichen Zwecken. Sie zu verwechseln verursacht echte Probleme.

Der Projektauftrag kommt zuerst und ist absichtlich kurz. Er wird geschrieben, bevor das Team die Arbeit vollständig versteht, also kann er nicht detailliert sein. Der Projektplan wird während der Planung erstellt, sobald das Team genug analysiert hat, um verlässliche Verpflichtungen einzugehen. Die Umfangsbeschreibung lebt im Projektplan als Teil der Umfangs-Baseline, zusammen mit dem Projektstrukturplan.

Ein häufiger Fehler ist, den Projektauftrag zu schreiben, nachdem die Planungsarbeit erledigt ist, und ihn dann rückzudatieren. Das unterläuft den Zweck. Der Projektauftrag sollte zuerst geschrieben werden, mit den begrenzten Informationen, die zu Beginn verfügbar sind, und dann genutzt werden, um die Planungsarbeit zu autorisieren.

Wie man einen Projektauftrag schreibt: Schritt für Schritt

Das Schreiben eines Projektauftrags ist keine Einzelaktivität. Es erfordert Beiträge vom Sponsor, wichtigen Stakeholdern und dem Projektmanager. Hier ist die Reihenfolge, die funktioniert.

Schritt 1: Eingaben sammeln, bevor Sie anfangen zu schreiben

Sprechen Sie mit dem Sponsor und relevanten Stakeholdern, bevor Sie eine Vorlage öffnen. Sie müssen den Business Case, etwaige Einschränkungen (Budgetgrenze, regulatorische Anforderungen, harte Fristen) und die verfügbaren organisatorischen Ressourcen verstehen. Ziehen Sie vorhandene Dokumente hinzu: einen Business Case, eine Anfrage zur Angebotserstellung, einen Vorstandsbeschluss. Diese werden das Rohmaterial.

Schritt 2: Zweck und Begründung formulieren

Schreiben Sie zuerst das „Warum". Eine starke Zweckformulierung verbindet das Projekt mit der Organisationsstrategie oder einem konkreten Geschäftsproblem. Wenn Sie nicht artikulieren können, warum das Projekt in zwei oder drei Sätzen wichtig ist, ist das ein Signal, zum Sponsor zurückzukehren, bevor Sie fortfahren. Unklarer Zweck in der Projektauftragsphase wird zu unklarem Umfang in der Ausführungsphase.

Schritt 3: Ziele nach SMART-Kriterien definieren

Jedes Ziel sollte spezifisch genug sein, dass ein Dritter überprüfen könnte, ob es erreicht wurde. Überprüfen Sie jedes einzelne nach den SMART-Kriterien. „Das neue Mitarbeiterportal launchen" ist kein Ziel. „Das neue Mitarbeiterportal bis zum 31. März an alle 500 Mitarbeitenden launchen, wobei 80 % der Nutzer das Onboarding innerhalb der ersten zwei Wochen abschließen" schon.

Begrenzen Sie Ziele auf drei bis fünf. Mehr bedeutet normalerweise, dass der Projektumfang zu breit ist und in separate Initiativen aufgeteilt werden sollte.

Schritt 4: Umfang und wichtige Liefergegenstände auflisten

Schreiben Sie auf, was das Projekt produzieren wird, und was es entscheidend nicht produzieren wird. Die Liste dessen, was ausgeschlossen ist, ist oft wertvoller als die Liste dessen, was eingeschlossen ist. Bei einer CRM-Implementierung könnten Sie ausdrücklich notieren: „Phase 1 beinhaltet keine Integration mit dem Abrechnungssystem" oder „individuelles Reporting liegt außerhalb des Umfangs und wird in Phase 2 behandelt." Das verhindert, dass der Projektauftrag genutzt wird, um Arbeit zu rechtfertigen, die nie vereinbart wurde.

Schritt 5: Stakeholder abbilden und Sponsor bestätigen

Identifizieren Sie alle, die Entscheidungsbefugnis über das Projekt haben, vom Ergebnis betroffen sein werden oder informiert werden müssen. Bestätigen Sie, wer der Projektsponsor ist, denn diese Person wird den Projektauftrag unterzeichnen und zum primären Eskalationsweg für Probleme werden, die der Projektmanager nicht selbständig lösen kann. Ein Projekt ohne klaren, engagierten Sponsor kämpft fast immer.

Schritt 6: Freigabe vor Planungsbeginn einholen

Leiten Sie den Entwurf des Projektauftrags an alle erforderlichen Genehmiger weiter. Halten Sie ein kurzes Review-Meeting ab, wenn das Dokument Meinungsverschiedenheiten aufdeckt. Das Ziel ist kein perfektes Dokument, sondern ein unterzeichnetes. Sobald Sie die Freigabe haben, kann die Planung mit der Gewissheit beginnen, dass die Organisation dem Projektkurs verpflichtet ist. Alles im Projektlebenszyklus, was danach kommt, baut auf dieser Autorisierung auf.

Projektauftrags-Vorlage

Nutzen Sie das Folgende als Ausgangspunkt. Passen Sie Überschriften und Felder an die Normen Ihrer Organisation an.

PROJEKTAUFTRAG

Projektname: [Vollständiger beschreibender Name]
Projektmanager: [Name, Kontakt]
Projektsponsor: [Name, Titel]
Datum: [Datum des Projektauftrags]
Version: 1.0

---

ZWECK UND BEGRÜNDUNG
[Warum wird dieses Projekt durchgeführt? Welches Geschäftsproblem löst es?
Referenzieren Sie unterstützende Daten, finanzielle Auswirkungen oder strategische Priorität.]

---

ZIELE UND ERFOLGSKRITERIEN
Ziel 1: [SMART-Ziel: spezifisch, messbar, terminiert]
Ziel 2: [SMART-Ziel]
Ziel 3: [SMART-Ziel]

Erfolg wird gemessen an: [Schlüsselkennzahlen und Zielwerte]

---

ÜBERGEORDNETE ANFORDERUNGEN
- [Anforderung 1]
- [Anforderung 2]
- [Anforderung 3]

---

UMFANG
Im Umfang:
- [Liefergegenstand oder Arbeitsbereich 1]
- [Liefergegenstand oder Arbeitsbereich 2]

Außerhalb des Umfangs:
- [Ausdrücklich ausgeschlossene Arbeit 1]
- [Ausdrücklich ausgeschlossene Arbeit 2]

---

MEILENSTEINE
Meilenstein 1: [Beschreibung] | Ziel: [Datum]
Meilenstein 2: [Beschreibung] | Ziel: [Datum]
Meilenstein 3: [Beschreibung] | Ziel: [Datum]

---

BUDGET
Genehmigtes Gesamtbudget: [Betrag]
[Optional: Aufschlüsselung nach Phase oder wichtiger Kostenkategorie]

---

WESENTLICHE STAKEHOLDER
[Name] | [Rolle] | [Interesse/Einfluss]
[Name] | [Rolle] | [Interesse/Einfluss]

---

RISIKEN UND ANNAHMEN
Risiken:
- [Risiko 1]: [Kurze Notiz zu Wahrscheinlichkeit/Auswirkung]
- [Risiko 2]: [Kurze Notiz zu Wahrscheinlichkeit/Auswirkung]

Annahmen:
- [Annahme 1]
- [Annahme 2]

---

GENEHMIGUNGEN

Projektsponsor: _________________ Datum: _______
Projektmanager: _________________ Datum: _______
[Weiterer Genehmiger falls erforderlich]: _____ Datum: _______

Projektauftrags-Beispiele nach Branche

Das Format des Projektauftrags bleibt branchenübergreifend konsistent, aber der Inhalt sieht je nach Art der Arbeit unterschiedlich aus. So übersetzen sich dieselben zehn Abschnitte in vier gängigen Kontexten.

In jedem Fall sind die Ziele messbar und terminiert. Der Zweck ist mit einem Geschäftsergebnis verbunden. Und der Projektname ist beschreibend genug, dass ein neuer Stakeholder verstehen kann, was es ist, ohne ein Briefing zu erhalten.

Für Teams, die Waterfall-Methodik einsetzen, richtet sich der Projektauftrag direkt auf die erste Gate-Review des Projekts aus. Für Teams, die Agile oder Scrum einsetzen, deckt der Projektauftrag typischerweise die vollständige Produktinitiative ab, während einzelne Sprints innerhalb dieses autorisierten Umfangs operieren.

Häufige Fehler und wie man sie behebt

Best Practices

• Den Projektauftrag mit dem Sponsor schreiben, nicht für ihn. Zusammenarbeit beim Entwurf bringt Meinungsverschiedenheiten frühzeitig ans Licht und schafft gemeinsame Verantwortung für das Dokument.
• Einfache Sprache verwenden. Projektaufträge scheitern, wenn sie voller Fachjargon sind, den nicht-technische Stakeholder überspringen, ohne ihn zu lesen. Der Sponsor muss jedes Wort verstehen und dahinter stehen.
• Kurz genug halten, um es in 15 Minuten zu lesen. Wenn es länger dauert, ist es zu detailliert. Behalten Sie das Detail für Planungsdokumente.
• Jede Überarbeitung versionieren und datieren. Projektaufträge werden manchmal aktualisiert, wenn neue Informationen entstehen. Änderungen nachverfolgen, damit jeder weiß, welche Version aktuell ist.
• Den unterzeichneten Projektauftrag an alle wesentlichen Stakeholder verteilen. Es reicht nicht, eine unterzeichnete Kopie in einem Ordner zu haben. Die Menschen, die die Arbeit ausführen werden, sollten wissen, wozu sie autorisiert sind.
• Den Projektauftrag in Planungs-Kickoffs referenzieren. Jedes Planungsmeeting damit beginnen, die Projektziele des Projektauftrags zu überprüfen. Das hält die Planung an dem ausgerichtet, was tatsächlich genehmigt wurde.
• Den Projektauftrag an wichtigen Meilensteinen überprüfen. Wenn sich Projektumfang oder Ziele erheblich ändern, den Projektauftrag aktualisieren und erneut genehmigen lassen, statt stillschweigend von der ursprünglichen Autorisierung abzuweichen.
• Den Projektauftrag mit PERT-Chart und Gantt-Chart verknüpfen, die später kommen. Zu zeigen, wie der detaillierte Zeitplan auf die Meilensteine des Projektauftrags zurückgeführt werden kann, stärkt die Disziplin und macht Abweichungen sichtbar.

Häufig gestellte Fragen

Wer schreibt den Projektauftrag? Der Projektmanager entwirft den Projektauftrag in der Regel, aber der Projektsponsor liefert die Eingaben und muss ihn genehmigen. In der Praxis werden die besten Projektaufträge gemeinsam verfasst. Der Sponsor bringt den Business Case und die Budgetbefugnis ein. Der Projektmanager bringt die operative Struktur und stellt sicher, dass das Dokument umsetzbar ist. Manche Organisationen haben ein PMO, das eine Standardvorlage für den Projektauftrag besitzt, die der Projektmanager für jedes Projekt anpasst.

Wie lang sollte ein Projektauftrag sein? Zwei bis sechs Seiten decken die meisten Projekte ab. Einfache interne Projekte können auf einer Seite Platz finden. Große, funktionsübergreifende Initiativen in regulierten Branchen können aufgrund von Compliance-Anforderungen länger sein. Das Ziel ist Vollständigkeit, nicht Länge. Wenn Sie alle zehn Abschnitte auf zwei Seiten abdecken können, ist das besser als ihn auf sechs zu strecken.

Ist ein Projektauftrag dasselbe wie eine Umfangsbeschreibung? Nein. Der Projektauftrag wird in der Initiierungsphase geschrieben, bevor die Planung beginnt, und liefert eine übergeordnete Autorisierung. Die Umfangsbeschreibung wird während der Planung erstellt und geht detailliert auf Liefergegenstände, Abnahmekriterien und Ausschlüsse ein. Die Umfangsbeschreibung ist Teil der Umfangs-Baseline im Projektmanagementplan. Der Projektauftrag kommt zuerst und ist kürzer.

Verwenden Agile-Teams Projektaufträge? Ja, obwohl das Format manchmal leichter ist. Agile Teams verwenden oft einen „Projekt-Brief" oder „Team-Auftrag", der dasselbe abdeckt: Zweck, Ergebnisse, Stakeholder und Einschränkungen. Das Scrum-Framework schreibt keinen Projektauftrag vor, aber der zugrundeliegende Bedarf, Arbeit zu autorisieren und Stakeholder auszurichten, verschwindet nicht, nur weil man in Sprints arbeitet. Die meisten Agile-Organisationen schreiben einen Projektauftrag für die Initiative und überlassen der Sprint-Planung die Details.

Wer unterzeichnet den Projektauftrag? Mindestens unterzeichnet der Projektsponsor den Projektauftrag. Viele Organisationen verlangen auch die Unterschrift des Projektmanagers, und manche fordern die Freigabe eines funktionalen Managers oder eines PMO-Vertreters. Was zählt, ist, dass mindestens eine Person mit organisatorischer Befugnis das Projekt formal zum Fortfahren autorisiert und den genannten Zielen, dem Budget und dem Umfang zugestimmt hat.

---

Der Projektauftrag garantiert nicht, dass ein Projekt erfolgreich ist. Aber er schafft die Bedingungen, die Erfolg möglich machen. Teams, die ihn überspringen, verbringen die zweite Hälfte des Projekts damit, Entscheidungen neu zu verhandeln, die am Anfang hätten getroffen werden sollen. Den Projektauftrag unterzeichnen, verteilen und alles andere auf diesem Fundament aufbauen.

Und wenn Sie bereit sind, von der Autorisierung zur Ausführung überzugehen, ist der nächste Schritt, die übergeordneten Meilensteine des Projektauftrags in einen vollständigen Projektplan mit einem Projektstrukturplan und einem Zeitplan, der aus der Methode des kritischen Pfads abgeleitet wird, umzuwandeln.