Project Charter (Projektauftrag)

Du sollst ein neues Projekt starten – vielleicht ein CRM-System einführen oder einen Digitalisierungsprozess begleiten. Alles klingt erstmal vielversprechend. Aber beim genaueren Hinsehen merkst du: Es gibt keinen klaren Startpunkt. Kein offizielles Go, kein gemeinsames Verständnis, kein Budget. Jeder hat eine Meinung, aber niemand hat das Projekt wirklich „beauftragt“.

Was fehlt? Ganz einfach: der Projektauftrag.

Der Projektauftrag – international oft als Project Charter bezeichnet – ist weit mehr als ein formelles Startsignal. Er ist die strategische Basis, auf der jedes erfolgreiche Projekt ruht. Ohne ihn fehlt nicht nur die Autorität, sondern auch die Richtung. Und genau deshalb schauen wir uns dieses Dokument heute einmal richtig genau an: Was ist es, warum ist es so wichtig, was gehört rein – und wie unterscheidet es sich in klassischen, agilen und hybriden Umfeldern?

In der Startphase eines Projekts begegnen dir meist drei zentrale Dokumente: der Business Case, der Projektauftrag und später der Projektplan. Sie alle sind wichtig – aber sie erfüllen unterschiedliche Rollen:

• Der Business Case liefert die geschäftliche Begründung: Warum investieren wir in dieses Projekt? Welcher Nutzen wird erwartet? Wie sieht die strategische Passung aus?

• Der Projektauftrag ist die formale Autorisierung. Er nimmt die wichtigsten Punkte des Business Case auf, benennt Projektleitung und Sponsor, legt Ziele und Umfang fest und gibt einen groben Rahmen für Budget, Zeit und Stakeholder-Kommunikation.

• Der Projektplan schließlich beschreibt, wie das Projekt im Detail abläuft: Aufgaben, Zeitpläne, Abhängigkeiten, Ressourcen. Er basiert auf dem Projektauftrag – aber er geht tiefer in die Umsetzung.

Diese klare Trennung hilft, typische Fehler zu vermeiden – etwa die Vermischung von Strategie, Autorisierung und operativer Planung.

Wenn ein Projektauftrag fehlt oder nur oberflächlich abgehandelt wird, fehlt dem Projekt das Rückgrat. Das zeigt sich oft erst später – in Missverständnissen, Zielkonflikten oder eskalierenden Anforderungen. Deshalb lohnt es sich, hier sorgfältig zu arbeiten.

Ein guter Projektauftrag erfüllt drei zentrale Aufgaben:

• Schafft eine gemeinsame Vision. Alle Beteiligten – vom Management über die Fachabteilungen bis hin zum Projektteam – verstehen, worum es geht und was das Ziel ist.

• Definiert Autorität und Grenzen. Wer entscheidet? Wer gibt Ressourcen frei? Was gehört zum Projekt – und was ist ausdrücklich nicht enthalten?

• Und er bildet die Grundlage für Governance. Er ist die erste Baseline für das magische Dreieck bzw. das magische Sechseck: Zeit, Kosten, Umfang, Qualität, Risiko und Nutzen. Ohne diese Ausgangswerte lassen sich spätere Abweichungen weder messen noch bewerten.

Gerade in Zielkonflikten zeigt sich der Wert des Projektauftrags. Du wirst irgendwann abwägen müssen: mehr Umfang oder schneller fertig? Weniger Risiko oder niedrigere Kosten? Wenn du weißt, was im Projektauftrag als Priorität festgelegt wurde – etwa Time-to-Market oder Budgettreue – kannst du strategisch richtige Entscheidungen treffen, statt ad hoc zu reagieren.

Ein vollständiger Projektauftrag enthält mehrere klar abgegrenzte Elemente, die gemeinsam ein konsistentes Bild ergeben.
Dazu gehören:

• Projektzweck und Rechtfertigung
  Was ist das Ziel des Projekts – und warum ist es strategisch sinnvoll? Die Antwort muss greifbar und quantifizierbar sein, z. B.: „Einführung eines neuen CRM-Systems zur Steigerung der Vertriebseffizienz um 15 %.“

• Messbare Ziele und Erfolgskriterien
  Ziele sollten SMART formuliert sein: Spezifisch, messbar, erreichbar, relevant und terminiert. Ansonsten bleibt der Erfolg Interpretationssache.

• Grobe Anforderungen und Umfang
  Was ist im Projekt enthalten – und was nicht? Diese klare In-/Out-of-Scope-Abgrenzung ist der erste Schutz gegen Scope Creep, also die schleichende Ausweitung des Projektinhalts.

• Stakeholder-Identifikation
  Wer ist betroffen? Wer entscheidet mit? Wer muss informiert werden? Tools wie das Power/Interest Grid helfen dabei, Einfluss und Interessen zu analysieren.

• Grobe Risikobewertung
  Welche Risiken drohen – und welche Chancen bestehen? Es geht nicht um ein vollständiges Risikoregister, sondern um ein Bewusstsein für die größten Unsicherheiten.

• Budgetrahmen und Meilensteine
  Eine erste grobe Schätzung, oft als „Order of Magnitude“ bezeichnet, plus die wichtigsten Projektphasen und Zeitpunkte.

• Abnahmekriterien und Erfolgsmessung
  Wer entscheidet, ob das Projekt abgeschlossen ist? Und woran wird das gemessen?

• Projekt-Governance und Rollen
  Wer ist Projektleitung? Wer ist Sponsor? Wer sitzt im Lenkungsausschuss?

Ein gut strukturierter Projektauftrag bringt all diese Elemente auf den Punkt – klar, nachvollziehbar, verbindlich.

Je nach Projektumfeld verändert sich die Rolle des Projektauftrags:

In klassischen Projekten ist der Projektauftrag formell, verbindlich und nicht verhandelbar. Er wird zu Beginn erstellt, genehmigt und bildet die stabile Basis für die gesamte Planung und Steuerung.

In agilen Projekten, etwa mit Scrum, gibt es keinen festen Projektauftrag im klassischen Sinn. Stattdessen sprechen wir von Chartering – also einem kontinuierlichen Prozess der Ausrichtung. Produktvision, Product Goal, Sprint Goals und das Backlog übernehmen hier die Steuerungsfunktion.

In hybriden Projekten, z. B. im Water-Scrum-Fall-Modell, ist der Projektauftrag besonders wertvoll. Er schafft den Rahmen, innerhalb dessen agile Teams arbeiten können. Budget, Governance und strategische Zielsetzung werden geklärt – ohne das „Wie“ der Umsetzung festzulegen.

Gerade in hybriden Modellen fungiert der Projektauftrag als Übersetzer zwischen Managementlogik (Zahlen, Meilensteine, Risiken) und agiler Praxis (Kundennutzen, inkrementelle Entwicklung). Er verbindet Welten.

Ein nützliches Werkzeug zur Entscheidung, wie formell oder flexibel der Projektauftrag gestaltet werden sollte, ist die Stacey-Matrix. Sie hilft einzuschätzen, ob ein Projekt einfach, kompliziert, komplex oder chaotisch ist – und welcher methodische Ansatz (klassisch, agil, hybrid) am besten passt.

In der Praxis gibt es ein paar typische Stolperfallen, die man mit etwas Aufmerksamkeit leicht umgehen kann:

• Die Ambiguitätsfalle:
  Ziele wie „Optimierung der Plattform“ oder „Verbesserung der Prozesse“ sind zu unkonkret. Jeder versteht etwas anderes – und das führt zu Konflikten.
  
  

• Das „Schreiben-und-Vergessen“-Syndrom:
  Der Projektauftrag wird einmal erstellt und dann nie wieder verwendet. Dabei ist er die Basis für jede Änderungsentscheidung und sollte regelmäßig überprüft werden.
  
  

• Fehlende Zustimmung der Stakeholder:
  Wenn das Dokument im Alleingang geschrieben wird, fehlt die Akzeptanz. Ohne echte Beteiligung gibt es später keinen Rückhalt.
  
  

• „Gold-Plating“:
  Das Gegenteil von vage ist überladen. Ein Projektauftrag, der schon die spätere Umsetzung im Detail beschreibt, nimmt dem Team die Luft zum Atmen. Das „Wie“ gehört in den Projektplan – nicht in das Mandat.

• Das „Umfang-als-Wunschliste“-Problem:
  Gerade in klassischen Umfeldern besteht die Versuchung, schon im Projektauftrag eine Liste konkreter Features festzuschreiben. Doch damit raubst du agilen Teams die Chance, im Projektverlauf zu lernen und den besten Weg zum gewünschten Nutzen zu finden. Statt Features sollten Outcomes im Fokus stehen.

Ein Projektauftrag ist kein Verwaltungsakt. Er ist die strategische Startplattform für dein Projekt – und damit der erste echte Projekterfolg. Mit ihm schaffst du Klarheit, Autorität und Ausrichtung. Du setzt den Rahmen, in dem dein Team arbeiten kann. Und du gibst dir selbst ein starkes Steuerungsinstrument an die Hand.

Wenn du Projekte leiten willst – egal ob klassisch, agil oder hybrid – führt kein Weg an einem sauber aufgesetzten Projektauftrag vorbei. Alles andere ist Bauchgefühl. Und das reicht heute nicht mehr.