Den Projektauftrag klären 4 Kernfragen, die ein Projektauftrag beantworten muss

Ein erfolgreiches Projekt beginnt mit einem vollständig und präzise formulierten Projektauftrag. Wenn Sie nur vier Kernfragen beantworten, sind alle wichtigen Informationen gebündelt. Alin Javorsky zeigt in seinem Beitrag und einer Checkliste, welche vier Fragen das sind und wie Sie Ihr Projektziel nicht aus den Augen verlieren.

Management Summary

Download ZIPDownload ZIP
Download PDFDownload PDF
Download EPUBDownload EPUB

Den Projektauftrag klären 4 Kernfragen, die ein Projektauftrag beantworten muss

Ein erfolgreiches Projekt beginnt mit einem vollständig und präzise formulierten Projektauftrag. Wenn Sie nur vier Kernfragen beantworten, sind alle wichtigen Informationen gebündelt. Alin Javorsky zeigt in seinem Beitrag und einer Checkliste, welche vier Fragen das sind und wie Sie Ihr Projektziel nicht aus den Augen verlieren.

Management Summary

Wie hat Ihr letzter Projektauftrag ausgesehen? Hat er ein klares Bild geliefert oder mehr offene Fragen hinterlassen als beantwortet? Erkennen Sie im Nachhinein einen Zusammenhang zwischen dem Projektauftrag - also der Art, wie er erteilt wurde, dessen Inhalt und Form - und dem Projektverlauf?

Selbst bekannte Normen und Standards des Projektmanagements sind sich bei diesem entscheidenden Projektbestandteil nicht einig, was denn ein Projektauftrag genau ist und welche Inhalte ihn zu einem vollständigen Projektauftrag machen.

Es geht in diesem Artikel nicht um Vorlagen oder Methoden. Das Ziel ist, die Essenz eines Projektauftrags zu erfassen und Ihnen praktische Tipps für eine präzise Auftragsklärung an die Hand zu geben. In Beispielen beziehe ich mich auf meine Erfahrung aus zehn Jahren in der Automotive-Branche.

Der Projektauftrag als "Leuchtturm" des Projekts

Im Projektauftrag beschreibt der Auftraggeber das Ergebnis, das er bei Projektende "in den Händen" halten will. Damit kann er seinen Wunsch verbindlich einem Projektteam übertragen. Der Projektauftrag dient dazu, den Projektumfang (engl. project scope) zu definieren, also die Ziele und Aufgaben im Projekt gegenüber anderen Vorhaben abzugrenzen. Er ist Orientierungspunkt für die Ausrichtung der Aktivitäten im Projekt, für die Bewertung des Fortschritts und für die Priorisierung der Aufgaben während der Projektdurchführung – er hat eine Leuchtturmfunktion.

Noch vor Projektstart dient der Projektauftrag den Entscheidern als Entscheidungsgrundlage bei der Projektgenehmigung. Bei Projektabschluss ist der Projektauftrag üblicherweise der Maßstab für die Bewertung des Projekterfolgs. Er enthält die Vorgaben, die bei Projektabnahme dem Ergebnis gegenübergestellt werden. Er wirkt weiterhin als Vertrag zwischen Projektmanager und Auftraggeber. Nicht zuletzt bildet ein gemeinsamer und verstandener Projektauftrag den Kitt für die Teambildung. Ein fest umrissener Projektauftrag ist also unverzichtbar.

Der Projektauftrag als Startpunkt

Ein Projektauftrag ist das Fundament der Projektplanung und in aller Regel der Startpunkt für das Projekt. Dessen Inhalte, insbesondere die darin enthaltenen Vorgaben und Anforderungen, definieren das Projekt. "Planning begins with requirements that define the product and project", heißt es im Prozess-Referenzmodell CMMI for Development 1.3 (CMMI 1.3 2010, S. 44). Bei der Projektplanung werden die Inhalte des Projektauftrags in konkrete Arbeitsaufträge übersetzt. Darum sollte die Planung eines Projekts stets mit der Klärung und Präzisierung des Projektauftrags beginnen.

Für den Projektmanager ist der Projektauftrag die erste "Standortbestimmung" und die Legitimation für die Ausübung seiner Rolle.

Vier Kernfragen für einen vollständigen Projektauftrag

Der Projektauftrag hat also mehrere Funktionen in Bezug auf die Projektinitiierung, die Projektplanung und die Projektdurchführung. Daraus ergeben sich Ansprüche an den Inhalt des Projektauftrags. Hier sind nur einige wenige Beispiele für Fragen, die diese Ansprüche widerspiegeln und in jedem Projekt unabhängig von der Branche – vor Projektbeginn – beantwortet werden müssen:

  • Was ist das Ziel?
  • Welche Ergebnisse werden erwartet?
  • Wie ist die Priorität der Ergebnisse?
  • Wann sollen die Projektergebnisse vorliegen?
  • Was darf das Projekt kosten?
  • Warum ist das Projekt wichtig? Welchen Nutzen bringt das Projektergebnis?
  • Wie ist der heutige Ist-Zustand, und warum ist dieser unbefriedigend?
  • Gibt es bereits Vorgängerprojekte oder Erfahrung mit ähnlichen Projekten?
  • Welches Budget, welches Personal und welche Einsatzmittel stehen ungefähr zur Verfügung?
  • Welche Einschränkungen müssen bei der Umsetzung des Vorhabens berücksichtigt werden?

Sieht man sich die einzelnen Fragen an, stellt man fest, dass sich jede einer (oder mehrerer) der folgenden vier Kernfragen zuordnen lässt:

  • Welche Ziele sollen mit dem Projekt erreicht werden?
  • Welche Motivation steht hinter dem Projekt?
  • Wie sieht die Ausgangssituation aus?
  • Welche Randbedingungen gelten?

Die zahlreichen Fragen, die sich Auftraggeber und Projektteam vor einer Projektbeauftragung stellen, sind Teilaspekte einer oder mehrerer dieser vier Kernfragen. Sie bilden den Mittelpunkt, um den sich die Diskussion der Frage "Was muss unbedingt im Projektauftrag enthalten sein?" dreht.

Das könnte Sie auch interessieren

Alle Kommentare (3)

Guest

Vielen Dank für den ausführlichen und hilfreichen Beitrag. Nach genau diesen Kriterien schreibe ich meine Projektaufträge. Für mich stellt der Projektauftrag zusammen mit den Abnahmekriterien die wichtigsten Dokumente eines Projekts dar. Es ist absolut zentral, dass der Auftraggeber und der Projektleiter in diesen Punkten einig sind.

 

Wolfgang
Weber
Dr.

Der Aussage, dass ein sauber geklärter Projektauftrag als Start-(Fix-)Punkt für ein Projekt unabdingbar ist, wird wohl niemand ernsthaft widersprechen. Daher danke für den ausführlichen Artikel. Dennoch ein paar Anmerkungen meinerseits: 1. Es mag Situationen geben, in denen das zeitliche Projektziel unverrückbar ist (z.B. ein SOP). Meistens ist jedoch der Leistungsumfang fix, und die beiden anderen Ecken das mag. Dreiecks müssen sich dann (oft zähneknirschend) anpassen. Wem z.B. nützt ein zu 90% fertig entwickelter Motor, wenn die geplante Zeit abgelaufen ist... 2. Bzgl. der Zielformulierung verwende ich ein sehr erfolgreich ein einfacheres Muster: Ein Ziel ist ein anzustrebender Zustand (und keine Tätigkeiten), dessen Spezifikationen häufig in einem Lastenheft (LH) dargestellt werden. Und dann genügt eine kurze, klare Formulierung, die allerdings nicht immer rasch und im Konsens gefunden wird. Ein Beispiel: "Eine neue Fräsmaschine mit den im LH beschriebenen Anforderungen ist entwickelt und vom Kunden abgenommen". Damit ist alles gesagt. Natürlich zu akzeptablen Herstellkosten und innert nützlicher Frist. Doch dies sind keine Ziele, sondern Randbedingungen, welche den gewünschten Anwendungsbereich beschreiben. Dazu eine kleine Analogie aus der Physik: eine Differentialgleichung beschreibt ein System (also gewissermassen das Ziel), ihre Randbedingungen beschreiben aber nicht nochmals das System, sondern engen nur den Anwendungsbereich der Gleichung ein. 3. Es ist m.E. im Gegensatz zur Aussage im Artikel durchaus immer möglich, Ziele und Randbedingungen klar voneinander zu trennen: das Ziel ist der angestrebte Zustand (s.o.), Randbedingungen sind, wie es der Name schon sagt, keine Ziele, sondern zusätzliche Forderungen, die möglichst zu erfüllen sind, das Ziel selber aber nicht infrage stellen. Häufig sind dies finanzielle oder zeitliche Rand-Bedingungen, wie z.B. angestrebte Herstellkosten, Lieferzeitpunkte usw. Aber wenn die oben erwähnte neue Maschine erfolgreich abgenommen ist, jedoch z.B. in der Herstellung teurer als geplant ist, sinkt zwar die Verkaufsmarge, aber das Ziel selber ist erreicht. Die Maschine steht da und funktioniert. Etwas überspitzt formuliert: wenn man statt dessen einfach gar nichts entwickeln würde, wäre man instantan fertig und hätte das zeitliche "Ziel" (wenn es eines wäre) bei sogar weitem übererfüllt. Und das der Kosten auch gleich noch. Nur hat man dann dummerweise keine neue Maschine. Und dafür hatte man das Projekt ja gestartet. 4. Man unterschätze den Nutzen der nicht-Ziele nicht: einem soliden Projektauftrag sieht man seine Solidität an, wenn die Liste der nicht-Ziele deutlich länger als die der Ziele ist. Dann hat man sich im Vorfeld des Projekts offensichtlich gründlich Gedanken über die Projektabgrenzung gemacht (was ist 'drin und was nicht?). Und spätestens bei der obligatorischen finalen Auftragsklärung mit dem Projektauftraggeber liefern die nicht-Ziele fast immer unerwartet viel Diskussionsstoff und klären die gegenseitigen Erwartungen dadurch unerbittlich. Und genau das soll ja vor(!) Projektstart erreicht werden. Beste Grüsse W. Weber