Zurück zur Methodenübersicht

Projektauftrag

Projektauftrag: Basis

Einleitung Projektauftrag

Welche Erkenntnisse zu welchem Zeitpunkt auf Basis welcher Methoden für den Auftrag/Vertrag verwendet werden, variiert in der Praxis stark. Beispiel:

Ein Projektauftrag ist ein offizielles Dokument, das den Start eines Projekts genehmigt und dessen Ziele, Inhalte, Verantwortlichkeiten, Ressourcen und Rahmenbedingungen festlegt. Er dient als verbindliche Grundlage zwischen Auftraggeber und Projektleiter für die Durchführung des Projekts.

Ein Projektauftrag enthält die Essenz am besten als “Onepager” und wird mit geeigneten Anlagen ergänzt

Der Projektauftrag in Steckbriefform sollte als „Onepager“ bzw. sollte nur zusammenhängend auf genau einer Seite dargestellt werden, um dem Auftraggeber einen schnellen Überblick zu geben. Die Planungsgrundlagen, deren Essenz Eingang in den Steckbrief gefunden hat, werden oft als Anlagen zur Verfügung gestellt.

💡 Vorteile eines schriftlichen Projektauftrags

  • Symbolischer Akt zur gegenseitigen Verpflichtung
  • Als klare Bezugsbasis Reduktion Gefahr Moving Targets im Projektverlauf
  • Reduktion Interpretationsvielfalt Stakeholder
  • Entlastung am Projektende
  • Auftragstemplate erhöht Chance auf interne Auftraggeberrolle
  • Hebel für Projektleitung (Ablehnung Projektauftrag)
  • Kundenauftragsprojekt: Interner Projektauftrag ermöglich faire Beurteilung Projektleitung
  • Einheitliches Verständnis einer zwischenzeitlichen Basis für die weitere Detailplanung

Projektauftrag: Vertiefung

Weitere Erläuterungen zum Projektauftrag

  • Ein unterschriebener Projektauftrag ist ein nicht zu unterschätzender symbolischer Akt zu Betonung der gegenseitigen Verpflichtung von Auftraggeber und Projektleitung.
  • Nur wenn mit einem (schriftlichen) Auftrag eine klare Bezugsbasis vorliegt, können Änderungs- oder Zusatzwünsche über Change Requests strukturiert in das Projekt gebracht.
  • Ebenso kann die Projektleitung die individuelle Interpretationsvielfalt wichtiger Stakeholder und den damit verbundenen Ärger reduzieren. Das Argument, der aktuelle Wunsch sei ja keine Änderung sondern nur eine Konkretisierung der bereits getroffenen Vereinbarung, kann so leichter abgewehrt werden.
  • Die Projektleitung hat einen Anspruch darauf, von einer relevanten Instanz (in erster Linie der Auftraggeber) eine “Entlastung” zu bekommen. Ich höre immer wieder von Organisationen, dass sich hier Verantwortliche ihre Projekte selber aussuchen können, wenn diese inhaltlich zu ihrem Jobprofil passen. Hier sieht man wieder die Bedeutung einer sinnvollen Projektdefinition: Wenn bei solchen Vorhaben andere Mitarbeiterinnen und Mitarbeiter benötigt werden, also teure “Ressourcen” in Anspruch genommen werden, sollte aus meiner Sicht immer eine Instanz aus der Organisationshierarchie eine Genehmigung erteilen oder organisieren und die Auftraggeberrolle übernehmen. Neben anderen Vorteilen (wie die Ausübung einer Kontrollfunktion über die hoffentlich sinnvolle Verwendung des anvertrauten Budgets) ist es erfahrungsgemäß auch motivierend, wenn aus der Hierarchie über einen Standardprozess Feedback zum Ergebnis von größeren Vorhaben wie Projekten organisiert ist.
  • Ein offizieller Prozess inklusive Auftragstemplate erhöht die Chance auf Besetzung der oft fehlenden wichtigen internen Auftraggeberrolle, die wie gesagt in manchen Organisationen gar offiziell besetzt wird. Neben der Entlastung- bzw. Kontrollinstanz kann der Auftraggeber auch eine wichtige Beratungs- und Sparringspartnerfunktion übernehmen. Auftraggeber und Lenkungsausschuss haben mir bei meinen vielen Berichten schon oft durch konstruktive Vorschläge in meinem Projekt weitergeholfen und auf so eine Hilfe aus dem Top-Management würde ich nicht freiwillig verzichten.
  • Durch den offiziellen Projektauftrag kann die Projektleitung – vor allem bei Unterschriftsfeldern – einen Auftrag abzulehnen, wenn wichtige Voraussetzungen fehlen. Beispiele:
    • Noch nicht konkret genug beschriebene Ziele
    • fehlende Einigung im Umgang mit Top-Risiken
    • namentlich noch nicht benannte Ressourcen.
  • Oft ist es Auftraggeberverantwortung, für diese noch fehlenden Voraussetzungen zu sorgen. Die Ablehnung des Projektauftrags kann insofern den Druck auf den Auftraggeber erhöhen, die klassische Auftraggeberrolle auszuüben. Also z.B. auf die Ressourcenmanager Druck auszuüben, die entgegen einer grundsätzlichen Einigung im Portfolioboard keine Ressourcen namentlich benennen wollen. Die Projektleitung riskiert bei Auftragsübernahme ohne diese Voraussetzungen den Projekterfolg. Wenn sich die Projektleitung am Ende eines gescheiterten Projekts auf diese fehlenden Voraussetzungen zu Projektbeginn beruft, nützt das meist wenig. Häufige Auftraggeber-Argumentation: „Sie sind doch der PM-Profi. Sie hätten mich führen und herausfordern müssen. Wenn Sie deutlicher auf diese Missstände hingewiesen hätten, hätte ich mich selbstverständlich gekümmert.“
  • Bei Kundenauftragsprojekten erlaubt ein schriftlich formulierter interner Projektauftrag eine größere Flexibilität bei der internen Auftragsformulierung und damit auch eine fairere Beurteilung der Projektleitung. Wenn z.B. mit niedrigen Preisen als Dienstleister versucht wird, den Fuß in die Tür eines interessanten Marktes zu bekommen, ist die offizielle Vorgabe eines unrealistischen Budgets für die Projektleitung problematisch, weil demotivierend.
  • Durch die zwischenzeitliche Präsentation, Diskussion und Fixierung eines Zwischenstands mit dem Auftragsinhalts und einer Grobplanung erhöht man die Qualität der Detailplanung und verringert die eventuell erforderlichen Korrekturen am Ende der Detailplanung. **Begründung, warum bei Aufwand und Kosten oft differenziertere Informationen geliefert werden also in der eigentlichen Zielhierarchie
  • An anderer Stelle habe ich ja erwähnt, dass als Grundprinzip der Auftrag die Essenz der Methoden zur Auftragsklärung und Planung darstellt und deshalb konsistent sein sollte. In vielen Projektsteckbriefen werden Aufwände und Kosten oft deutlich differenzierter dargestellt als in der Zielhierarchie. In meinem Beispiel habe ich das auch so gemacht.
  • Wenn man so will, ist das eine pragmatische Ausnahme vom Prinzip, eher die Essenz differenzierter Methoden darzustellen und nicht umgekehrt im Steckbrief grobe Methoden differenzierter darzustellen.
  • Für diese Ausnahme gibt es aus meiner Sicht die folgenden guten Gründe:
    • Unterschiedliche Abstraktionsebene – Ziel vs. Ressourcenplanung. Die Zielhierarchie formuliert was erreicht werden soll (Outcome), der Steckbrief dokumentiert auch womit (Input/Ressourcen). Kosten- und Aufwandsdetails sind streng genommen Ressourcen- und Kostenplanung, kein Projektziel im engeren Sinne. Das Kostenziel lautet: „Das Projekt kostet maximal X €.” Wie sich das zusammensetzt, ist Planungsdetail. Das Kostenziel in der Zielhierarchie ist das “committete” Gesamtbudget – das ist die Messlatte für Zielerreichung. Die Aufschlüsselung im Steckbrief ist Ressourcenplanung und Steuerungsinformation für den PM, aber kein eigenständiges Ziel. Konsistenz heißt hier: Die Zahlen dürfen sich nicht widersprechen – aber sie müssen nicht auf gleicher Granularität sein. Die Differenzierung zum Beispiel in interne und externe Kosten ist steuerungsrelevant für den PM, aber kein eigenständiges Projektziel. Es dürfte eher selten sein, dass jemand „feiert”, dass die internen Kosten genau x € betragen, wenn aber das Gesamtbudget deutlich gerissen wurde.
    • Praktikabilität der Zielhierarchie Die Zielhierarchie würde schnell unhandlich, wenn jede Ressourcenkategorie einzeln als Ziel formuliert würde. Sie lebt von Übersichtlichkeit. Der Steckbrief hingegen ist explizit das Dokument für diese Detailtiefe. An anderer Stelle habe ich bereits erwähnt, dass die Zielhierarchie ein wertvolles Instrument zur Kommunikation und Auftragsabstimmung mit dem Auftraggeber ist und sich deshalb die Projektleitung überlegen sollte, welche Informationen sie auf dieser “Helikopterebene” anbietet. Besonders teure Einzelkomponenten, bei denen man davon ausgeht, dass ihre Kostenwirksamkeit dem Auftraggeber eher nicht bekannt sind, werden dann z.B. fallweise ausgewählt. Aber eine standardmäßige Aufschlüsselung in verschiedene Einzelkomponenten sind in der Regel nicht hilfreich bei der Auftragsklärung und verringern nur die Übersichtlichkeit. Ausnahme ist natürlich, wenn der Auftraggeber - aus welchen Gründen auch immer - eine klare Vorgabe macht, dass ganz bestimmte und ihm wichtige Aufwands- oder Kostenbestandteile eine klare Obergrenze haben. Dann muss ich natürlich als Projektleiter in der Zielhierarchie dokumentieren, dass ich den Wunsch des Auftraggebers verstanden habe und ihn mit dieser Methoden widerspiegeln.
    • Der Steckbrief wiederholt also nicht nur, sondern ergänzt auch fallweise. In diesem Sinn kann man Steckbrief und Zielhierarchie als komplementäre Dokumente verstehen. Die Zielhierarchie liefert schwerpunktmäßig das Was und Warum als gewünschten Outcome, der Steckbrief ergänzt vor allem bezüglich Ressourcen als grobe Steuerungsinformation das Wie viel und Womit. Konsistenz bedeutet dann nicht Redundanz, sondern Widerspruchsfreiheit.