Der Projektauftrag – ein Vorhaben präzise definieren

Als Projektleiter, Programmmanager oder Sponsor bzw. deren Berater bist Du mit folgenden Fragen konfrontiert:

• Welche Ergebnisse und welchen Ablauf würde ein Änderungsprojekt besitzen?
• Wie stellen wir sich, dass wir während der Projektdurchführung am geplanten Kurs festhalten?
• Wie stellen wir zwischen verschiedenen Projektvorschlägen eine Vergleichbarkeit her?

Unterstützung findest Du im Projektauftrag und der Projektauftragserstellung.

---

Ergebnis: Definition der Ziele, Vorgehen, Kosten, Nutzen und Zeitplan eines Projektes

Teilnehmer: mind. 1 Person (besser: zukünftiges Projektteam)

Dauer: ab 60 Minuten (je Projektumfang)

Utensilien: Notebook & Office Software

Zweck

Mit einem Projektauftrag definierst Du ein Projekt, also ein zielgerichtetes einmaliges Vorhaben, welches den bestehenden Ist-Stand eines Unternehmensteils (Geschäftsprozesse, IT-Systeme, Organisationseinheit etc.) in einen zukünftigen Ziel-Stand überführt.

Der Projektauftrag fasst die Erkenntnisse und das Wissen über ein Projekt vor seinem Start in einem Papier zusammen. Als Grundstein eines Vorhabens erfüllt die Unterlage drei Aufgaben:

• Planung: Basierend auf dem Kenntnisstand zu Beginn eines Vorhabens definiert er die Projektziele, die Randbedingungen, den Nutzen sowie das grobe Vorgehen.
• Freigabe: In vielen Organisationen ist der Projektauftrag die Voraussetzung für den Start in mittlere und große Vorhaben. Eine Freigabe auf Basis des Auftrags verhindert U-Bootinitiativen, also Projekte, die ohne Zustimmung der Entscheider losgetreten wurden.
• Orientierung: Zusätzlich zu dieser planerischen Komponente besitzt ein Projektantrag eine Sicherungsfunktion. Während der Durchführung schützt das Papier den Projektleiter von einem schleichend wachsenden Umfang, dem sogenannten Scope Creep. Damit fungiert der Projektauftrag als ein Orientierungsstern und Richtschnur, speziell für zeitlich lange Projekte mit volatilem Umfeld in denen die Anforderungen nicht eindeutig sind.

Gegenüber dem Projektsteckbrief und dem Project Canvas fällt der Projektauftrag deutlich umfangreicher aus. Ergebnisse, Ziele und Vorgehen sind viel präziser beschrieben. Diese Genauigkeit hat natürlich ihren Preis. So ist die Erstellung eines Projektauftrags um ein vielfaches aufwendiger und zeitintensiver.

Synonyme für den Projektauftrag sind Projektvereinbarung, Projektauftrag oder Project Charter.

---

Aufbau

Projektauftrag – „Was liefert und benötigt das Projekt zu welchem Zeitpunkt?“

Struktur, Format und Inhalt eines Projektauftrages sind nicht standardisiert. Sie variieren von Unternehmen zu Unternehmen. Untere Kapitel sind in der Regel in einem Projektauftrag zu finden.

Versehe Deinen Auftrag mit Meta-Infos wie einem prägnanten Titel, den Autoren sowie das Datum der letzten Aktualisierung. Gerne kannst Du Felder wie das Datum der Abzeichnung und den Abzeichner ergänzen.

Inhalte – „Was enthält ein Projektauftrag?“

1. Ausgangssituation (‚Warum?‘)
Das qualitative ‚Warum‚ für das Projekt. Enthalten im Ist-Stand sind Hintergrundinfos zu aktuellen Schmerzpunkten, erforderlichen Handlungen und zukünftigen strategischen Herausforderungen. Ebenso zu finden ist die Kritikalität (= Wichtigkeit) des Projektes für den Unternehmenserfolg.

• Worin besteht die Ausgangslage für das Projekt?
• Welche Maßnahmen wurden bereits umgesetzt?
• Was passiert, falls das Projekt nicht auf den Weg gebracht wird?

2. Ziele (‚Wohin?‘)
Angestrebte Ziele des Projektes. Formuliere SMART, damit spezifisch, messbar und zeitlich befristet sowie lösungsneutral. Sowohl…

• allgemeine Unternehmensziele (zum Beispiel ‚Erhöhung Qualität‘) als auch
• spezifische Fachziele (zum Beispiel ‚Umsetzung rechtlicher Anforderungen‘)

sind möglich und definieren das ‚Wozu‚ des einmaligen Vorhabens. Halte auch die Nicht-Ziele fest.

• Welche Ziele bestehen im Projekt?
• Welche Ziele werden vom Projekt nicht verfolgt?
• Bei welchen möglichen Zielen besteht noch Uneinigkeit, ob diese erreicht werden sollen?

3. Messgrößen (‚Wodurch?‘)
Woher weiß ein Unternehmen, ob es die durch ein Projekt angestrebten Ziele auch erreicht hat? Abhilfe schaffen hier konkrete Messgrößen, die quantifizieren, ob und zu welchem Grad ein Ziel erfüllt werden konnte.

• Nach welchen objektiven Kriterien erfolgt die Zielmessung?
• Anhand welcher eindeutiger Faktoren ist klar, dass die Ziele erreicht wurden?
• Welche Key Performance Indicators (KPIs) geben Auskunft über die Zielerfüllung?

4. Umfang (‚Wo?‘)
Definiert den Scope des Projektes, das ‚Was‘. Inhalt sind zum Beispiel betroffene Prozesse, Organisationen, Standorte, Verträge, IT-Systeme, Technologien, Geschäftsobjekte. Nicht im Scope befindliche Elemente solltest Du im Zweifel explizit ausschließen.

• Was liegt innerhalb des Betrachtungsbereiches?
• Was wird vom Projekt nicht betrachtet?
• Bei welchem Elementen sind wir unsicher, ob diese im Scope liegen oder nicht?

5. Ergebnisse (‚Was?‘)
Die erwarteten Projektergebnisse. Das können beispielsweise Fachspezifikationen sein, implementierte IT-Systeme oder Analyseberichte.

• Welche Liefergegenstände sollen nach Projektende vorliegen?
• Wer erwartet welche Resultate vom Projekt?
• Welcher Output kommt nicht vom Projekt?

6. Anforderungen (‚Wonach?‘)
Umfasst grobe fachliche und technische Anforderungen sowohl an die Projektergebnisse (zum Beispiel Qualitätseigenschaften) als auch an das Projekt (zum Beispiel Anlauftermine) selbst.

• Über welche Eigenschaften und Funktionen verfügt das vom Projekt gelieferte System?
• Was wünschen sich die Nutzer/Kunden/Empfänger vom Projekt?
• Im welchen zeitlichen, finanziellen und qualitativen Rahmen bewegt sich das Projekt?

7. Schnittstellen (‚Mit wem?‘)
Ein Projekt verläuft nie im Vakuum. Dieses Kapitel beinhaltet sowohl organisatorische (zum Beispiel Nachbarabteilungen, Prozesse, Parallelprojekte, externe Dienstleister und Partner) als auch technische (zum Beispiel IT-Systeme) Abhängigkeiten, die Du und Dein Team bei der Durchführung berücksichtigen müsst.

• Mit welchen Organisationseinheiten hat sich das Projekt zu koordinieren?
• Welche Voraussetzungen müssen von anderer Stelle für das Projekt geschaffen werden?
• Welchen Schnittstellenpartner hat das Projekt zu bedienen?

8. Vorgehensweise (‚Wie?‘)
Das generelle Vorgehensmodell (Wasserfallmodell, Scrum etc.), also das ‚Wie‘ eines Projektes. Du beschreibst die Phasen, Aktivitäten, Ergebnistypen, Rollen, Kommunikation, Softwarewerkzeuge sowie (Zwischen-)Abnahmen beispielsweise in einer Roadmap und einem Kommunikationsplan, losgelöst von einem konkreten Terminplan bzw. einer spezifischen Projektorganisation.

• Welche Projektmethodik verfolgt das Team?
• Nach welchen Spielregeln arbeiten die Teilnehmer?
• Wie erfolgt die Wertschöpfung durch das Projekt?

9. Aufwandsschätzung (‚Wie hoch‘)
Erforderlicher Zeit- und Ressourcenbedarf pro Ergebnistyp und Projektphase in Personentagen sowie sachlogische und zeitliche Abhängigkeiten.

• Wie viel Personalkosten verursacht das Projekt?
• Welche Sachkosten entstehen mit dem Projekt?
• Welche Verteilung zwischen unternehmensinterne – und externe Kosten hat das Projekt?

10. Projektorganisation (‚Wer?‘)
Erforderliche Besetzung der Rollen durch interne und externe Personen inklusive derer erforderlichen Kapazitäten. Beinhaltet zudem die Aufbauorganisation mit disziplinarischen und fachlichen Hierarchien sowie ggf. Beschreibung der Aufgaben, Kompetenzen und Verantwortlichkeiten. Bereits in dieser Phase können Gremien (zum Beispiel Lenkungskreis) und ein Kommunikationsplan (zum Beispiel Jour Fixe) aufgeführt werden um das ‚Wer‘ eines Projektes noch expliziter zu präzisieren.

• Wer ist am Projekt beteiligt?
• Welche sonstigen betroffenen oder interessierten Parteien sind zu berücksichtigen?
• Wie ist das Projektteam organisiert?

11. Projektplanung (‚Wann?‘)
Das ‚Wie‘ eines Projektes als Synthese aus Vorgehensweise, Aufwandsschätzung sowie Projektorganisation. Das Kapitel beinhaltet die Projekttermine (Start, Ende etc.), Meilensteine, Zeitpuffer, Arbeitsstränge mit konkreten Kalenderdaten und ggf. auch Personen und Leistungsstufen.

• Wie lange läuft das Projekt im Best, Average und Worst Case?
• Zu welchem Zeitpunkt liefert Projekt einen ersten Wert?
• Wann ist die arbeitsintensivste Zeit im Projekt?

12. Rahmenbedingungen (‚Worunter?‘)
Ungewissheit und Unsicherheit gehören zum Projektalltag. Das Kapitel nimmt sich diesem Umstand an, indem es fachliche (z.B. Fähigkeiten der Mitarbeiter), organisatorische (z.B. Projektressourcen, Beistellleistung) und technische (z.B. IT-Equipment) Voraussetzungen und Annahmen auflistet.

• Von welchen Unterstützungsleistungen geht das Projekt aus?
• Welche Unternehmenstermine berücksichtigt das Projekt in der Planung?
• Welche Entscheidungen sieht das Projekt als gegeben an?

13. Risiken (‚Wobei‘)
Kein Projekt ohne Risiko. Diese werden an dieser Stelle im Projektauftrag aufgezeigt und mit Eintrittswahrscheinlichkeit, Auswirkungen und konkreten Linderungsmaßnahmen (Delegation, Akzeptanz etc.) konkretisiert.

• Welche Entwicklungen könnten das Projekt aus der Bahn werfen?
• Wo zeichnen sich bereits heute „dunkle Wolken“ für das Projekt ab?
• Welche potentiellen Ereignisse sorgen beim Projekt für Zeitverzug bzw. Budgetübertritt?

14. Business Case (‚Wie viel?‘)
Zu guter Letzt – das ‚Wieviel‘ des Projektes. Anders ausgedrückt: die erwartete Projektrendite und -kosten, kurzum der messbare Return-on-Investment (RoI) des Projektes. Eine Nutzenpotentialanalyse quantifiziert die Rendite. Bei den Kosten werden sowohl einmalige Aufwände (Projektbudget und ggf. Investition) als auch laufende Aufwände für Betrieb und Wartung betrachtet.

• Welchen Nutzen hat das Projekt?
• Wann werden sich die Investitionen ausgezahlt haben?
• Welche Chancen können sich durch das Projekt eröffnen?

Mögliche weitere Kapitel sind Lösungsalternativen oder Auswirkungen auf die Organisation, Prozess- oder Systemlandschaft. Natürlich nur, falls Dir diese Parameter bereits bekannt sind.

Informationsquellen – „Woher stammen die Infos für den Projektauftrag?“

Ein Projektauftrag ist schnell geschrieben. Der Knackpunkt liegt vielmehr in der Beschaffung der enthaltenen Fakten. Prinzipiell kommen für Dich zwei Informationsquellen in Frage:

• Dokumente, zum Beispiel Strategiepapiere, Prozess- und IT-Richtlinien, Auftragsbeschreibungen, Lastenhefte, Verfahrensanweisungen, Steckbriefe und Projektunterlagen ähnlicher Vorhaben.
• Stakeholder, zum Beispiel das Management, der Auftraggeber, der Sponsor, die Nutzer, die Kunden, die Prozessverantwortlichen und die Systemadministratoren.

Infos aus diesen Quellen gießt Du in den Projektauftrag.

---

Anwendung

Einen Projektauftrag erstellst Du allein oder – falls möglich – in Zusammenarbeit mit dem designierten Projektteam. Gebe so den zukünftigen Teilnehmern die Möglichkeit sich mit ihrem Vorhaben auseinanderzusetzen.

1. Befragen

Befrage die zuvor identifizierten Stakeholder im Rahmen von Workshops und Interviews. Führe zudem eine Analyse der verfügbaren Dokumente durch, am besten mittels einer Dokumentenliste.

2. Dokumentieren

Halte die gewonnenen Erkenntnisse im Projektauftrag fest. Schließe offene Lücken durch zusätzliche Befragungen der Stakeholder und/oder vertiefende bzw. erneute Analyse vorhandener Dokumentation.

3. Abstimmen

Stimme das Ergebnis mit dem Auftraggeber ab, je nach Deinem Auftrag und Rolle zum Beispiel mit dem Projektsponsor, Management, Auftraggeber und/oder Projektleiter.

4. Freigeben

Lasse den Projektauftrags von Projektleiter, Projektsponsor, Auftraggeber etc. durch Unterschriften formal freigeben und initiiere damit das Vorhaben.

5. Nutzen

Ziehe den Projektauftrag während der Durchführung als roten Faden der ursprünglichen Planung heran.

---

Beispiele

Als Wissensarbeiter wirst Du früher oder später einen Projektauftrag formulieren. Sei es…

• als Teil der Akquisephase,
• für eine unternehmensinterne Initiative oder
• im Auftrag des Vorgesetzten bzw. Kunden.

---

Vor- & Nachteile

Pro

• Ein Projektauftrag fasst übersichtlich den Zweck, den Umfang sowie das Vorgehen eines Änderungsvorhabens an einer Stelle zusammen.
• Die Redaktion vor Projekt Kick-Off zwingt zur detaillierten Auseinandersetzung mit Sinn und Zweck eines Vorhabens.
• Das Dokument eignet sich für unklare Situationen in denen das Ziel-Bild, der Ist-Stand bzw. der Weg vom Ist zum Ziel im Nebel liegen und erst erkundet werden müssen.
• Als zu einem spezifischen Zeitpunkt verfasster Plan, dient der Auftrag als Entscheidungsgrundlage sowie als Orientierung während der Projektdurchführung.

Contra

• Wie alle Planungsdokumente altert auch ein Projektauftrag. Das Papier verliert deutlich an Wert, falls das tatsächlich Projekt und der ursprüngliche Plan auseinandertriften. Zumindest fungiert der Projektauftrag dann weiterhin noch als Warnbotschaft „Das hatten wir ursprünglich geplant!“.
• Ein Projektauftrag bleibt ein Ergebnis des Projektmanagements. Er erfasst, umschreibt, strukturiert und bewertet Zustände und erforderliche Transformationsaufgaben. Die eigentliche inhaltliche Gestaltungsarbeit steht weiterhin aus.
• In agil geführten Projekten die auf konstante Änderungen der Anforderungen ausgelegt sind, verliert die Vorabplanung mittels eines Projektauftrages an Relevanz.

---

Praxistipps

Tipp 1 – Schwerpunkt auf den Projektüberblick legen

Die Kunst bei der Erstellung eines Projektauftrages besteht im Spagat zwischen ungenauer vs. zu detaillierter Beschreibung des Vorhabens.

Auf der einen Seite soll der Auftrag möglichst präzise das Projekt umschreiben. Auf der anderen Seite sollen die dafür erforderlichen Analysen aber nicht zu umfangreich ausfallen.

Das Augenmerk liegt auf dem dokumentierten ‚Was‘, nicht auf dem ‚Wie‘.

Tipp 2 – Abteilungsgrenzen gezielt überwinden

Nicht immer liegen die Informationsquellen für einen Projektauftrag innerhalb der Abteilung des Auftraggebers. Insbesondere für die Kapitel ‚Schnittstellen‚ und ‚Risiken‚ solltest Du den Blick über die Organisationsgrenzen schweifen lassen.

Fordere Verfügbarkeiten und Informationen ein. Verläuft bereits die Auftragserstellung an den Schnittstellen holbrig, wird es im bevorstehenden Projekt nicht einfacher werden.

Tipp 3 – Schweigen als Zustimmung werten

Um die Erstellung eines Projektantrages zu beschleunigen, kannst Du Dich in der Phase der Abstimmung folgender Beschlusstaktik bedienen:

„Schweigen ist Zustimmung!“

Daher: Meldet sich ein Stakeholder nicht auf Deine Info-Nachricht mit dem angehängten Projektantrag, so zählst Du das als Zustimmung. Natürlich sollten die Stakeholder diesem Vorgehen zustimmen. Anders verpackt aber die gleiche Intention verfolgt die zweite Beschlusstaktik:

„Wer beim Beschluss nicht dabei ist, trägt die Entscheidung der Anwesenden.“

Bleibe bei der Redaktion des Auftrags auf jeden Fall hartnäckig und lasse Dich nicht abwimmeln. Es ist in aller Interesse vor Start eines Projektes ein gemeinsames Verständnis über dessen Ziele, Anforderungen und Vorgehensweise zu erlangen.

Tipp 4 – Anforderungsquellen bewusst abgrenzen

Eine weitere Stellschraube, um rascher zum Projektauftrag zu gelangen, ist die Erfassungsphase. Hier kommunizierst Du, dass die Anforderungen von nicht befragten Stakeholdern bzw. nicht analysierten Dokumenten nicht im Projektauftrag berücksichtigt werden.

Kurzum: Der Auftraggeber und die Stakeholder sind für die Kommunikation ihrer Bedarfe verantwortlich.

„Wer schweigt wird nicht gehört!“

Natürlich auch wieder in Abstimmung mit Deinem Auftraggeber.

Tipp 5 – Vorhandene Unternehmensvorlagen nutzen

Etablierte Unternehmen führen für Standardprojektergebnisse feste Vorlagen. Sprich Deinen internen Projektleiter auf eine vorhandene Schablone an und verwende diese Struktur als Grundlage.

Tipp 6 – Auftrag eines gestarteten Projekts erfragen

Stelle in Deinem nächsten Engagement die Frage nach dem Projektauftrag. Zum Einen, um Deine Professionalität zu untermauern. Zum Anderen, um einen schriftlichen Beleg für die Ziele und den Umfang eines Projektes in der Hand zu haben. Bereits das Vorhandensein und die Qualität des Dokuments zeigen Dir, wie es um ein Projekt bestellt ist.

---

Ursprung

Der Ursprung der Methode ist mir nicht bekannt. Gerne Deine Hinweise per E-Mail an mich.

---

Bonusmaterial

• Sven Dort: Der Projektauftrag: So legst du den Grundstein für ein erfolgreiches Projekt – viele weitere Details zum Dokument
• Projektmagazin: Der Projektauftrag – das muss drinstehen! – Infos, Beispiele, Literaturhinweise und Checkliste – ausführliche Beschreibung des Projektauftrags samt einem einfachen Beispiel