⭳ Download: Checkliste Projektauftrag

Hier klicken, um die Checkliste herunterzuladen ⭳

Die Bandbreite der in der Praxis anzutreffenden Formate für den Projektauftrag reicht vom einfachen mündlichen Zuruf ("Maier, Sie übernehmen das Projekt '0815'!") bis hin zum mehrere hundert Seiten starken Vertragswerk, das zwischen den Juristen der Vertragsparteien über Monate, wenn nicht sogar Jahre ausgehandelt wird, z.B. bei der Vergabe von Großprojekten im Aerospace- oder Verteidigungsbereich.

Es ist daher nicht verwunderlich, wenn die vorhandenen PM-Richtlinien recht unterschiedliche Inhalte aufzählen, die ein Projektauftrag haben sollte und im Internet eine verwirrende Vielfalt von Vorlagen für dieses Dokument kursiert.

Wenn Sie, z.B. als Auftraggeber oder als Projektleiter, einen Projektauftrag formulieren müssen, stehen Sie vor der Aufgabe, die erforderlichen Inhalte vollständig zusammenzustellen. Die folgenden Überlegungen sollen Ihnen dabei helfen, die für Ihren Projektauftrag notwendigen Punkte zu identifizieren und sie im richtigen Detaillierungsgrad auszuformulieren.

Wozu ein Projektauftrag?

Der wichtigste Zweck eines Projektauftrags ist es, die Arbeiten im Projekt zu autorisieren und dafür zu sorgen, dass die Geschäftsführung die Projekte ihres Unternehmens steuern kann. Wenn z.B. ein Konstrukteur eine brillante Idee für ein neues Produkt hat und ohne entsprechenden Projektauftrag mit dessen Entwicklung beginnt, so schadet er mit diesem "U-Boot-Projekt" seinem Unternehmen gleich in zweifacher Hinsicht, denn:

• Arbeiten, die ohne Freigabe durch die Geschäftsführung stattfinden, beeinträchtigen die Leistungsfähigkeit der Organisationseinheit, da sie die verfügbare Ressourcenkapazität verringern.
• Die Geschäftsführung kann Projekte, über die sie nicht informiert wird, auch nicht nutzbringend für das Unternehmen steuern.

Daher gilt uneingeschränkt: Kein Projekt darf ohne Projektauftrag durch eine dafür befugte Autorität begonnen werden!

Darüber hinaus sollte der Projektauftrag die Grundlagen der Projektdurchführung definieren. Je klarer dies geschieht, umso weniger Reibungsverluste wird es in der Zusammenarbeit der Projektbeteiligten geben.

Der Weg von der Idee bis zum Projektauftrag

Wenn der Auftraggeber dem Projektmanager den Auftrag zur Projektdurchführung erteilt, ist dies einerseits der Startpunkt des Projekts, andererseits der Abschluss der Projektvorbereitung bzw. Projektinitiierung. Die Prozessmodelle der PM-Richtlinien, hier sind vor allem der PMBOK® Guide (PMI, 2008), PRINCE2™ (OGC 2009), der PM3 (GPM, 2009) und die DIN 69901 (DIN, 2009) zu nennen, beschreiben den Weg von der Idee bis zum Projektauftrag mit unterschiedlichen Begriffen und in verschiedenen Stufen. Übergreifend lassen sich jedoch drei wesentliche Zustände für den Projektauftrag definieren:

Stufe 1: Projektidee / Projektmandat / Projektanstoß

Irgendjemand innerhalb einer Organisationseinheit hat eine Idee für eine Veränderung. Dies kann z.B. ein Verkäufer sein, der eine neue Kundenanforderung aufnimmt, ein Ingenieur, der ein neues Material vorschlägt, oder ein Vorstandsmitglied, das neue Märkte erschließen will. Aber aus einer Idee für eine Veränderung wird noch lange kein Projekt.

Selbst das Vorstandsmitglied hat nicht automatisch die Autorität, ein Projekt zu initiieren. Innerhalb der Organisation muss diese Idee zuerst der Autorität mitgeteilt werden, die dazu befugt ist zu entscheiden, ob die Idee weiterverfolgt wird oder nicht. Dies kann z.B. eine Stabsstelle (die über Projekte entscheidet), der Vorstand, der Projektportfoliomanager oder der Geschäftsführer sein. Überzeugt die Idee den Entscheider, wird dieser jemanden damit beauftragen, die Machbarkeit der Idee zu überprüfen und den Projektauftrag zu entwerfen. Diese erste Beauftragung wird im PM3 "Projektanstoß", in der DIN 69902-5 "Projektidee" und bei PRINCE2 "Projektmandat" genannt. Der PMBOK Guide erwähnt diese Vorstufe lediglich.

Stufe 2: Entwurf des Projektauftrags / Projektbeschreibung

Bevor ein endgültiger Projektauftrag dem Lenkungsausschuss zur Freigabe vorgelegt werden kann, wird eine Reihe von Zwischendokumenten benötigt, wie z.B. eine Spezifikation der Projektergebnisse oder der Business Case. PRINCE2 widmet der Vorbereitung des Projekts einen eigenständigen Prozess (Starting up a Project / Vorbereiten eines Projekts), der explizit nicht Bestandteil des Projekts ist und in der gemeinsamen Verantwortung von Auftraggeber und Auftragnehmer liegt. Ergebnis dieses Prozesses ist der Entwurf des Projektauftrags, den PRINCE2 "Projektbeschreibung" nennt.

Der PMBOK Guide beschreibt das Vorbereiten des Projekts nicht, fordert aber folgenden Input, um einen Projektauftrag zu erstellen: Projektleistungsbeschreibung (Statement of Work), Business Case, Vertrag (bei externen Projekten), Faktoren der Unternehmensumwelt, Eingangs- und Ausgangswerte von Organisationsprozessen. Auch diese Dokumente zu erstellen bzw. diese Informationen einzuholen, stellt einen nicht unerheblichen Aufwand dar.

DIN 69901 sowie PM3 beschreiben zwar einzelne Prozesse, Vorgänge und Ergebnisse, die vor dem Erstellen des Projektauftrags durchgeführt werden bzw. vorliegen müssen, ziehen aber keine klare Grenze zwischen Tätigkeiten vor dem Projekt und im Projekt. Dementsprechend gibt es auch kein eindeutig bezeichnetes Entwurfsdokument für den Projektauftrag.

Stufe 3: Projektauftrag / Project Charter / Projektleitdokument

Eine gewisse Übereinstimmung innerhalb der verschiedenen Standards gibt es erst bei der Erstellung des endgültigen Projektauftrags. Die Aufwände hierfür sind bei allen Prozessmodellen Teil des Projekts. Ebenfalls Einigkeit herrscht darüber, dass der Projektauftrag vom Auftraggeber freigegeben werden muss, bevor der Projektmanager mit der Durchführung des Projekts beginnen darf.

Vor dieser Freigabe durch den Auftraggeber wird der Projektauftrag auch oft "Projektantrag" ("Project Proposal") genannt. Dies ist immer dann der Fall, wenn der Auftragnehmer das Projekt selbst definiert und dem Auftraggeber nur zur Genehmigung und zur Freigabe des Budgets vorlegt.

Der Projektauftrag in den PM-Richtlinien

Alle gängigen Richtlinien für Projektmanagement beschreiben den Projektauftrag, allerdings in unterschiedlicher Form. Wesentlicher Grund für diese Uneinheitlichkeit ist, dass sich die Richtlinien bereits in ihrer grundlegenden Herangehensweise unterscheiden. Während das PM3, das Standardwerk der GPM, einen wissensbasierten Ansatz verfolgt und dementsprechend den Rahmen für die Gestaltung des Projektauftrags sehr weit steckt, gibt das britische PM-System PRINCE2™ mit der sog. "Projektleitdokumentation" detailliert die obligatorischen Inhalte für den Projektauftrag vor. Der PMBOK® Guide (US-amerikanische Norm) liegt hinsichtlich der Ausformulierung des Projektauftrags, dort "Project Charter" genannt, in etwa zwischen PM3 und PRINCE2, da er ihn zwar einerseits in den festen Rahmen seines Prozessmodells einbindet, aber die Integration des Projektmanagements in die Unternehmensorganisation nicht so strikt handhabt wie PRINCE2.

Wenn am Projekt mehrere Organisationseinheiten beteiligt sind, klären Sie als erstes ab, welche Anforderungen an den Projektauftrag aufgrund verpflichtender Standards zu erfüllen sind! Beachten Sie: Selbst innerhalb eines Unternehmens können die verschiedenen Abteilungen nach verschiedenen PM-Standards arbeiten.

Als Basis für die folgenden Ausführungen habe ich zum einen die genannten PM-Richtlinien verwendet, zum anderen habe ich versucht, aus meiner Erfahrung die typischen Fragen zu beantworten, die sich ein Projektmanager beim Verfassen eines Projektauftrags stellt.

Rahmenbedingungen klären

Bevor Sie daran gehen, den ersten Entwurf für Ihren Projektauftrag zu erstellen, klären Sie die Rahmenbedingungen des Projekts, um den angemessenen Detaillierungsgrad und Umfang für den Projektauftrag abzuschätzen. Auf diese Weise vermeiden Sie als Projektleiter, dass Sie z.B. nach einer Woche Arbeit mit einem fünfzigseitigen Dokument bei Ihrem Auftraggeber vorstellig werden und dieser Ihnen kopfschüttelnd zu verstehen gibt, dass für dieses einfache, interne Projekt auch eine DINA-4-Seite gereicht hätte.

Vorhandene Informationen und Dokumente zusammentragen

Projekte fallen nicht vom Himmel. Wenn ein Projektauftrag erstellt werden soll, liegen mit Sicherheit bereits Dokumente vor, wie z.B. Spezifikationen, Wirtschaftlichkeitsrechnungen oder grobe Pläne. Die Aufgabe, einen Projektauftrag zu erstellen, besteht in der Regel darin, die vorhandenen Informationen über das Projekt zusammenzutragen und sie auf Vollständigkeit und Konsistenz zu überprüfen. Wenn dabei Widersprüche auftauchen, z.B. weil der Kostenplan weit höhere Kosten als die Wirtschaftlichkeitsrechnung ausweist, können Sie den Projektauftrag noch nicht fertigstellen. Zuerst müssen Sie "den Ball" an die zuständigen Experten "zurückspielen", damit sie diese Widersprüche beseitigen. Genauso verhält es sich, wenn wesentliche Punkte für die Projektdurchführung nicht geklärt sind. Wenn z.B. keine Aussagen über das Risikomanagement vorliegen, muss hier zumindest die Aussage der Vertragsparteien eingeholt werden, dass sie bewusst darauf verzichten, die Projektrisiken zu berücksichtigen.

Auch bei der formalen Gestaltung des Projektauftrags sollten Sie nicht "das Rad neu erfinden", sondern als erstes nach bestehenden Vorlagen, z.B. aus den PM-Handbüchern der Vertragspartner, oder nach alten Projektaufträgen fragen. Dieser Artikel und die beigefügte Checkliste dienen in erster Linie dazu, bestehende Vorlagen zu überprüfen und zu optimieren.

Download: Checkliste Projektauftrag ⭳

Wenn Sie die Aufgabe haben, eine Vorlage für einen Projektauftrag ohne jegliche Vorgabe neu zu entwickeln, bedeutet dies, dass in der betreffenden Organisationseinheit noch keinerlei Erfahrungen mit systematischem Projektmanagement vorliegen. In diesem Fall muss zuerst ein PM-System eingeführt werden, ansonsten hat ein Projektauftrag keine Basis. Ohne ein solides organisatorisches Fundament ist selbst ein perfekt formulierter Projektauftrag nur ein wertloses Stück Papier.

Internes oder externes Projekt?

Ein grundlegender Unterschied besteht beim Projektauftrag zwischen internen und externen Projekten. Während bei einem internen Projekt im Normalfall der Projektauftrag keine Rechtsverbindlichkeit, sondern nur den Charakter einer Betriebsvereinbarung hat, stellt der Projektauftrag bei externen Projekten einen Vertrag zwischen zwei (oder mehr) Parteien dar, der juristisch verbindlich ist und dessen Erfüllung Gegenstand einer gerichtlichen Auseinandersetzung sein kann. Bei einem externen Projekt sind deshalb alle Elemente des Projektauftrags besonders sorgfältig dahin gehend zu überprüfen, welche vor Gericht durchsetzbaren Ansprüche sie zwischen den Vertragsparteien bewirken.

Projektart und Branche berücksichtigen

Bei bestimmten Projektarten oder Branchen gelten fachlich oder gesetzlich bedingte Rahmenbedingungen für die Ausgestaltung des Projektauftrags. Bei öffentlichen Bauprojekten bestehen z.B. strenge Regeln für die Ausschreibung von Bauleistungen. In der Finanzdienstleisterbranche ist z.B. das Risikomanagement nach Basel II (bald Basel III) zu gestalten. Und natürlich ist bei einem Organisationsentwicklungsprojekt der Nutzen des Projekts anders darzustellen als bei einer Produktentwicklung.

Inhalte eines Projektauftrags

Auf den ersten Blick erscheinen die im Folgenden aufgeführten Inhalte sehr umfangreich. Es bedeutet aber keinen übertriebenen Aufwand, diese Themen bereits beim Projektauftrag zu klären und verbindlich festzulegen. Ganz im Gegenteil: Ein sorgfältig erstellter und vollständiger Projektauftrag vereinfacht die Projektdurchführung erheblich, da er viele unnötige Reibungsverluste und Zusatzaufwände von vornherein vermeidet. Stellen Sie sich z.B. vor, dass der Auftraggeber während der Abnahme für die entwickelte elektronische Schaltung ein Prüfzertifikat für Funktionale Sicherheit verlangt und dies als Selbstverständlichkeit ansieht, während die Entwickler dies als unnötigen Zusatzaufwand betrachten.

Innerhalb einer projektorientierten Umgebung können die meisten der folgenden Inhalte mit einem Satz erledigt werden: Der Verweis auf ein bestehendes Dokument, z.B. auf das Lastenheft, genügt bereits. Selbst ein inhaltlich sehr umfangreicher Projektauftrag kommt mit zwei bis drei DINA-4-Seiten aus; die vollständigen Informationen sind dann in den entsprechenden Dokumenten enthalten.

Zusammenfassung

Der Projektauftrag dient zu Beginn des Projekts den Vertragsparteien als Grundlage für die Entscheidung, ob sie das Projekt durchführen wollen oder nicht. Er ist die wichtigste Referenz für alle Entscheidungen im Projekt, für die Abnahme des Projekts und für eine evtl. Revision nach dessen Abschluss. Deshalb muss der Projektauftrag mit einer sorgfältig erstellten Zusammenfassung beginnen, die dem Leser knapp und präzise die wesentlichen Informationen über das Projekt bietet.

Dieser einleitende Text ist zudem das einzige Inhaltselement des Projektauftrags, das nicht durch einen Verweis auf ein bestehendes Dokument ersetzt werden kann, sondern vollständig ausformuliert werden muss. In der Literatur und im allgemeinen Sprachgebrauch gibt es für diesen Text verschiedene Bezeichnungen: "Projektdefinition", "Kurzbeschreibung", "Projektbeschreibung". Verwirrend ist, dass diese Bezeichnungen zudem in mehrfachen Bedeutungen verwendet werden. Z.B. ist bei der DIN 69901-2 "Definition" die Phase, in der die Rahmenbedingungen für das Projekt festgelegt werden, während PRINCE2 mit "Projektdefinition" genau die Zusammenfassung der Projektleitdokumentation bezeichnet. Im allgemeinen Sprachgebrauch wird die Kurzdarstellung des Projekts häufig "Projektbeschreibung" genannt, PRINCE2 bezeichnet damit die Vorstufe des gesamten Projektauftrags.

Die Zusammenfassung sollte knappe Antworten auf die folgenden Fragen geben:

• In welchem Rahmen wird das Projekt durchgeführt (z.B. innerhalb eines Programms)?
• Warum wird das Projekt durchgeführt? Hier sollten die Gründe, nicht die Ziele angegeben werden.
• Was sind die Zielsetzungen des Projekts (evtl. das Mission Statement des Projekts)?
• Welche Ergebnisse werden angestrebt und welche Toleranzen gibt es ggf. hierfür?
• Was ist der Projektgegenstand?
• Wie ist das Projekt gegen anderen Vorhaben abgegrenzt?
• Was sind die Voraussetzungen für das Projekt?
• Wer sind die wesentlichen Stakeholder des Projekts?
• Welche Annahmen wurden für die Durchführung des Projekts getroffen?
• Wie groß ist das Projektbudget und wie wird es finanziert?
• Wie lange ist die geplante Projektdauer?
• Was sind die wichtigsten Risiken?

Beispiel

Eine einfache Zusammenfassung könnte z.B. so aussehen wie für das fiktive Software-Entwicklungsprojekt "AIDA":

Das Projekt "AIDA" (Allgemeine Integration der Datenanalyse) findet im Rahmen des Programms "ProDat II" statt. Da es keine kommerzielle Lösung für die dort bestehenden Anforderungen an die Produktdatenanalyse gibt, wird ein entsprechendes Statistikmodul neu in Java zur Integration in die bestehende Software-Suite "ODySSeUs" (Online Dynamic Statistics for Senior Users) erstellt. Die Projektdauer beträgt 6, maximal 8 Monate, das Budget darf 32.000 Euro nicht überschreiten. Die Finanzierung erfolgt über das Programm-Budget. Vorausgesetzt wird, dass das unternehmensweite Produktdatenmodell vor Projektbeginn vorliegt. Das größte Risiko der Entwicklung ist, dass die Analysen zu lange dauern, so dass ein effizientes Arbeiten mit dem System nicht möglich ist. Es wird angenommen, dass durch den Einsatz eines besonders leistungsfähigen Rechners die Antwortzeiten auf ein akzeptables Niveau gedrückt werden können. Das Produktmanagement führt die fachliche Abnahme durch, die formelle Abnahme erfolgt durch den Programm-Manager. Noch nicht innerhalb des Projekts umgesetzt werden Auswertungsgrafiken, diese sind Inhalt des anschließenden Projekts "ProPrä" im Rahmen von ProDat II.

Die Reihenfolge dieser Punkte ist grundsätzlich beliebig, schließlich stehen sie in enger Wechselwirkung zueinander. Zu empfehlen ist, die für eine Entscheidung wichtigsten Informationen möglichst an den Anfang zu stellen. Wenn sich also z.B. die Dringlichkeit einer Produktentwicklung aus der Annahme ergibt, dass ein Konkurrent ein ähnliches Produkt auf den Markt bringen könnte ("Welche Annahmen wurden für die Durchführung des Projekts getroffen?"), sollte diese Information möglichst früh in der Zusammenfassung stehen.

In der Zusammenfassung sollen lediglich Fakten genannt werden. Die Begründungen und Herleitungen für diese Fakten stehen in den anderen Abschnitten des Projektauftrags oder in externen Dokumenten, auf die der Projektauftrag verweist.

Rechtfertigung des Projekts (Business Case)

Jedes Projekt stellt eine Investition dar. Dies gilt selbst dann, wenn kein Geld fließt, sondern "nur" ohnehin vorhandene personelle Ressourcen eingesetzt werden, die auch im Leerlauf dieselben Kosten verursachen würden. Schließlich könnte man diese Ressourcen ja auch für eine andere Tätigkeit einsetzen, die möglicherweise einen höheren Nutzen bewirkt.

Sie müssen im Projektauftrag möglichst genau darlegen, welchen Nutzen dieses Projekt für den Auftraggeber stiften soll. Im einfachsten Fall soll das Projekt einen monetären Nutzen erzielen, z.B. durch den gewinnbringenden Verkauf von Produkten. Nutzen kann aber auch nicht-monetär sein. Wenn ein Unternehmen eine Betriebskindertagesstätte einrichtet, dann besteht der erwartete Nutzen u.a. darin, qualifizierte Mitarbeiter und Mitarbeiterinnen im Betrieb zu halten. Auch eine Steigerung des Bekanntheitsgrads einer Marke, die Herstellung von Chancengleichheit für Migranten in der Gesellschaft oder das Erfüllen einer gesetzlichen Vorgabe sind Beispiele für nicht-monetäre Nutzen unterschiedlicher Projekte.

Business Case | Checkliste Word & PDF

Überzeugen Sie Entscheider:innen und Stakeholder:innen Ihres Projekts von seinem Nutzen! Diese ultimative Checkliste führt Sie durch den gesamten Lebenszyklus Ihres Business Cases – von der Vorbereitung bis zum anschließenden Nutzenmanagement!

Weiterlesen

Die umfangreichste Möglichkeit, die Rechtfertigung eines Projekts darzustellen, ist ein vollständiger Business Case. Am Beispiel des Business Case lassen sich zudem sehr schön die unterschiedlichen Philosophien von PMBOK Guide und PRINCE2 aufzeigen: Während der PMBOK Guide den Business Case als von der Projektumgebung vorgegebenen Input für den Project Charter beschreibt, ist der Business Case bei PRINCE2 selbst zentraler Inhalt des Projektauftrags und stellt für alle Entscheidungen im Projekt die entscheidende Referenz dar.

Wie Sie einen vollständigen Business Case erstellen, lesen Sie in der Serie "So schreiben Sie einen Business Case" (Schmidt; Ritter, Projekt Magazin 04/2010).

Projektziel (Projektendprodukt, Projektgegenstand, Werk, Deliverable)

Ganz allgemein formuliert besteht ein Projekt darin, den "Zustand A" in einen vorab definierten "Zustand B" zu überführen. Es gibt recht unterschiedliche Herangehensweisen, um diesen "Zustand B" zu definieren. In der deutschsprachigen Literatur dominiert die Vorstellung, dass ein Projekt ein mehr oder weniger komplexes Projektziel zu erreichen hat. Die angelsächsische Literatur spricht meist pragmatisch von "Liefergegenständen" (PMBOK Guide) oder "Produkten" (PRINCE2). Beide Standards bezeichnen damit allgemein die Ausgangsgrößen von Projektprozessen, d.h. sowohl gegenständliche Produkte als auch erbrachte Dienstleistungen.

Je nach verwendetem Standard und abhängig von den zu berücksichtigenden Projektkulturen kann es also sein, dass Sie hier komplexe Zielhierarchien, Leistungsverzeichnisse oder strategische Anforderungen zu dokumentieren haben. Die Vorstellungen der befragten Stakeholder davon, wie ein Projektziel zu beschreiben sei, können sehr umfangreich und abstrakt werden. Um die dadurch möglicherweise entstehenden Diskussionen zu vereinfachen, stellen Sie die Leitfrage, die für die Formulierung dieses Abschnitts im Projektauftrag ausschlaggebend ist:

"Welche überprüfbaren Kriterien müssen erfüllt sein, damit das Projekt abgenommen werden kann?"

Im einfachsten Fall genügt hierfür der einfache Satz: "Im Rahmen des Projekts müssen die im Lastenheft aufgeführten Leistungen erbracht werden." Das genannte Lastenheft wird damit Bestandteil des Projektauftrags.

Oftmals wird in diesem Zusammenhang das Argument vorgebracht, dass es nicht möglich sei, das Projektergebnis hinreichend genau im Vorhinein zu bestimmen. Ich schlage in diesem Fall vor, dann eben nur den Schritt zu beauftragen, den man überblicken kann, z.B. die Analyse des Status Quo, die Erhebung von Anforderungen sowie die Entwicklung von Handlungsempfehlungen. Wenn der Auftraggeber aber unbedingt sofort das noch nicht genau definierbare "Unternehmensweite Managementinformationssystem für KPIs" beauftragen will, dann bleibt Ihnen nur übrig, eben auch die Abnahmekriterien entsprechend vage auszudrücken. Z.B. können Sie darauf hinweisen, dass die Leistungsmerkmale des Managementinformationssystems im Laufe des Projekts einvernehmlich mit den Stakeholdern entwickelt werden – und entsprechend auch die Abnahmekriterien. Ich rate von einem solchen Vorgehen aber dringend ab, da meiner Erfahrung nach eine ungenaue Definition von Abnahmekriterien stets zu schleichendem Funktionszuwachs und Konflikten zwischen Auftraggeber und Auftragnehmer führt.

Zahlreiche Methoden und Empfehlungen, wie Sie bei der Zieldefinition und der Vereinbarung von Ergebnissen vorgehen können, finden Sie im Themenbereich "Methoden > Planung > Ergebnis / Ziel" des Projekt Magazins.

Herangehensweise (Projektlösungsansatz)

Meist gibt es mehrere Möglichkeiten, um die beschriebenen Leistungen zu erbringen. Wenn ein Unternehmen z.B. ein neues Produkt schnell auf den Markt bringen will, ist der einfachste Lösungsansatz, es selbst zu kaufen. Andere Möglichkeiten sind, es in Lizenz zu produzieren, ein eigenes Produkt weiterzuentwickeln oder es vollständig neu zu erstellen.

Der Projektauftrag sollte die grundsätzliche Herangehensweise (bei PRINCE2 wird sie "Projektlösungsansatz" genannt) klar benennen, sofern dies nicht ohnehin schon im Lastenheft geschehen ist. Ansonsten besteht das Risiko, dass der Auftragnehmer zwar die aus seiner Sicht beste Lösung wählt, um die Abnahmekriterien zu erfüllen, diese aber für den Auftraggeber nicht gangbar ist. Einfache Beispiele für "falsche" Lösungsansätze sind die Wahl einer mit der Betriebsumgebung des Auftraggebers nicht kompatiblen Programmiersprache bei Software-Entwicklungen oder die Beauftragung von nicht im Lieferantenverzeichnis des Auftraggebers aufgeführten Lieferanten.

Projektorganisation

Der Projektauftrag an sich erzeugt bereits eine neue Organisationseinheit, sei es innerhalb eines Unternehmens, über Unternehmensgrenzen hinweg oder sogar als eigenständige Projektgesellschaft. Das Zusammenspiel von Auftraggeber und Auftragnehmer in einem Projekt wird selbst dann nicht von den bestehenden Regeln einer Linienorganisation abgedeckt, wenn der Auftraggeber der direkte Vorgesetzte des Auftragnehmers ist. Denn der Inhalt eines Projekts steht außerhalb der sich wiederholenden Linientätigkeit. Ansonsten läge auch kein Projektauftrag vor, sondern lediglich ein Arbeitsauftrag, für den keinerlei zusätzliche Vereinbarungen benötigt würden.

Meist sind in ein Projekt mehrere Organisationseinheiten eingebunden, sodass sich die Rollen der Projektbeteiligten nicht mehr intuitiv ergeben, sondern explizit definiert werden müssen. So ist auch die Projektorganisation im Projektauftrag festzuhalten, denn ohne Benennung von Verantwortlichkeiten und Befugnissen für die Projektdurchführung würde er völlig wirkungslos bleiben: Niemand wäre für das Erreichen der Ergebnisse verantwortlich und es gäbe niemanden, der das Projekt abnehmen und für beendet erklären könnte.

Der Projektauftrag sollte somit mindestens die beiden wichtigsten Rollen im Projekt, den Auftraggeber und den Projektleiter, namentlich benennen. Weiterhin sollten im Projektauftrag die Zusammensetzung des Projektmanagementteams und die Rollenbeschreibungen geklärt werden. Wenn im PM-Handbuch bereits die Rollen innerhalb der Projektorganisation verbindlich festgelegt sind, so brauchen im Projektauftrag nur noch die Anpassungen, z.B. an die Projektgröße, beschrieben werden.

Beispiel

Wenn das PM-Handbuch für große Projekte optional einen Änderungsausschuss vorsieht, muss im Projektauftrag geklärt sein, ob für dieses Projekt ein solcher Ausschuss eingerichtet werden soll oder nicht.

Übliche Rollen in PM-Teams sind u.a.:

• Auftraggeber / Sponsor / Kunde (DIN 69901, PM3, PMBOK Guide, PRINCE2)
• Lenkungsausschuss (DIN 69901, PM3, PRINCE2)
• Änderungsausschuss (PM3, PMBOK Guide, PRINCE2)
• Projektcontrolling (PM3)
• Projektsicherung (PRINCE2)
• Projektmanager / Projektleiter (DIN 69901, PM3, PMBOK Guide, PRINCE2)
• Teilprojektleiter (PM3)
• Teammanager (PRINCE2)
• Projektbüro (PM3), Projektunterstützung (PRINCE2)

In dieser beispielhaften Aufzählung ist jeweils gekennzeichnet, welche Richtlinien die spezifische Rollenbezeichnung verwenden.

Abhängig von speziellen Anforderungen eines Projekts können noch zahlreiche weitere Rollen hinzukommen, z.B. ein Pressesprecher oder ein Risikomanager. PRINCE2 fordert z.B. obligatorisch einen Benutzer- und einen Lieferantenvertreter als weitere Mitglieder des Lenkungsausschusses.

Ausführliche Informationen über die Rollen innerhalb eines Projekts finden Sie im Themenbereich "PM im Unternehmen > Rollen / Verantwortlichkeiten" des Projekt Magazins.

Kommunikationsplan (Kommunikationsmanagementstrategie)

Die beste Projektorganisation ist handlungsunfähig, wenn nicht jeder Projektbeteiligte stets die von ihm benötigten Informationen in aktueller Form vorliegen hat. Wenn Kommunikationswege sowie Berichts- und Informationspflichten nicht vereinbart sind, sind die Konflikte zwischen den Projektbeteiligten über Hol- und Bringschuld von Informationen vorprogrammiert. Entsprechende Reibungsverluste führen zu Verzögerungen oder lassen das Projekt sogar scheitern.

Im Projektauftrag sind daher mindestens die Informations- und Berichtspflichten der Beteiligten festzulegen, am besten wird ein vollständiger Kommunikationsplan (PM3, PMBOK Guide) bzw. eine Kommunikationsmanagementstrategie (PRINCE2) erstellt, worauf verwiesen werden kann.

Einen sehr einfachen Kommunikationsplan können Sie z.B. in die Verantwortlichkeitsmatrix integrieren. Wie dies geht ist im Tipp "Die RACI-Matrix als einfacher Kommunikationsplan" (Angermeier, Projekt Magazin 15/2009) beschrieben.

Übersichtsinformationen der Projektplanung (Projektplan)

Der Projektauftrag sollte auch die für die Entscheider, d.h. die Geschäftsführung oder das Programm-Management, wesentlichen Plandaten enthalten, um ihn sachgerecht beurteilen und mit ihm sinnvoll arbeiten zu können. Wenn das Projekt z.B. Teil eines Programms ist, müssen seine Phasen und Meilensteine mit den anderen Projekten dieses Programms abgestimmt sein.

Zu den Planinformationen auf Projektebene gehören:

• die obersten (meist zwei bis drei) Ebenen des Projekt- oder Produktstrukturplans
• die Phasenaufteilung des Projekts
• Meilensteine, die wesentliche Entscheidungen erfordern oder wichtige Kontrollpunkte sind
• wesentliche Schnittstellen zu anderen Projekten
• das Projektbudget und seine Aufteilung nach Phasen
• der Ressourcenbedarf und seine Aufteilung nach Phasen
• der Zeitrahmen

Anforderungen an das Projektmanagement

Im einfachsten Fall genügt es, auf das geltende PM-Handbuch zu verweisen und ggf. projektspezifische Anpassungen aufzuführen. Verweise auf allgemeine Standards, wie z.B. "Das Projekt ist nach DIN 69901:2009 durchzuführen", wirken zwar beeindruckend, sind aber sinn- und nutzlos, da jeder allgemeine Standard umfassend auf die konkrete Projektumgebung angepasst werden muss.

Wie bei allen anderen Managementsystemen (s.u.) gilt natürlich auch für das anzuwendende PM-System, dass es nur so gut ist, wie seine Umsetzung. Im Projektauftrag sollte daher unbedingt definiert werden, wie die Qualität des vorgeschriebenen Projektmanagements gesichert wird. Dies kann z.B. durch eine Auditierung des Projektmanagements zu bestimmten Zeitpunkten oder bei bestimmten Ereignissen, z.B. Phasenübergängen, gewährleistet werden.

Wenn es kein PM-Handbuch gibt, das man zu Rate ziehen könnte, sollten hier zumindest folgende Punkte definiert werden:

• Planungsmethoden (z.B. Aufwandsschätzverfahren)
• Überwachungsmethoden (z.B. Plan-Ist-Vergleich)
• Steuerungsmethoden (z.B. Änderungsmanagementverfahren)
• einzusetzende Werkzeuge (z.B. Planungssoftware)

Anzuwendende Managementsysteme

Projektmanagement ist eine Querschnittsaufgabe, die sich nicht auf die Verwaltung von Vorgängen, Meilensteinen und Plänen beschränken darf. Dementsprechend muss der Projektauftrag Informationen enthalten, welche anderen Managementdisziplinen in welcher Ausprägung zu berücksichtigen sind. Mindestens zu berücksichtigen sind das Risikomanagement, das Konfigurationsmanagement und das Qualitätsmanagement.

Risikomanagement

Eine Einigung über das anzuwendende Risikomanagement wird in der Praxis häufig versäumt, das Prinzip "Augen zu und durch" scheint noch sehr weit verbreitet zu sein. Spätestens, wenn ein vorhersehbares Risiko eintritt, ist jedoch schnell der Streit zwischen den Vertragsparteien im Gange, wer die Auswirkungen zu tragen hat. Im Projektauftrag sind daher mindestens die Hauptrisiken und die Verantwortlichkeiten bezüglich der Risiken zu regeln.

Risikomanagementverfahren

Integrieren Sie das Risikomanagement nahtlos in die Projektarbeit! Managen Sie aktiv die Bedrohungen und Chancen Ihres Projekts!

Weiterlesen

Ebenfalls im Projektauftrag sollte die Risikobereitschaft der beteiligten Organisationseinheiten dokumentiert sein, denn diese hat wesentlichen Einfluss auf die Projektdurchführung, z.B. bei der Beurteilung von Änderungsanträgen. Wenn z.B. der Endtermin unbedingt gehalten werden muss, sollten Sie in diesem Projekt tunlichst keine innovativen Ideen austesten.

Konfigurationsmanagement

Ursache für viele Missverständnisse und Reibungsverluste ist ein fehlendes Konfigurationsmanagement. Vielleicht ist das unhandliche Wort "Konfigurationsmanagement" daran Schuld, dass es manche als lästig empfinden, die erbrachten Leistungen (je nach Standard auch "Liefergegenstände", "Werke" oder "Produkte" genannt) überprüfbar zu verwalten. Pragmatisch gesehen geht es ganz einfach darum zu definieren, wie die Projektergebnisse so verwaltet werden, dass sich jeder Projektbeteiligte stets aktuell darüber informieren kann, welchen Status welches Ergebnis hat und wo es zu finden ist. Wenn Sie das Vorgehen nicht bereits im Projektauftrag festlegen, kann ich Ihnen nur noch viel Spaß beim Suchen wünschen.

Ebenfalls zum Konfigurationsmanagement gehört das Änderungsmanagement, d.h. die Beschreibung des Prozesses, wie Änderungsanträge zu erfassen, zu bewerten, zu behandeln und zu dokumentieren sind.

Qualitätsmanagement

Das Qualitätsmanagement im Projekt definiert letztendlich, wie die im Projekt erstellten Werke überprüft und abgenommen werden. Dies liegt im beiderseitigen Interesse des Auftraggebers und des Auftragnehmers. Da Qualitätsmanagementsysteme nahezu flächendeckend in Unternehmen und anderen Organisationen etabliert sind, genügt meist der Verweis auf das anzuwendende Qualitätsmanagementsystem, ggf. ergänzt um Spezifika, die für das betrachtete Projekt gelten.

Weitere Managementsysteme nach Bedarf

Ggf. sind bei bestimmten Projektarten oder Branchen noch weitere Managementsysteme zu berücksichtigen. Dies könnte z.B. das Umweltmanagement oder das Öffentlichkeitsmanagement sein. Bei Bauprojekten gibt es z.B. den SiGe-Koordinator (Sicherheits- und Gesundheitskoordinator), der für das Management der Arbeitssicherheit und des Gesundheitsschutzes auf der Baustelle verantwortlich ist.

Vertragsbezogene Inhalte

Wenn der Projektauftrag zugleich ein Vertrag zwischen Projektbeteiligten ist, dann sind bei seiner Gestaltung auch die üblichen vertragsrechtlichen Aspekte zu berücksichtigen.

Speziell bei Projekten können zusätzlich folgende vertragsrechtlich relevanten Punkte zu klären sein:

• Durchführung der Abnahmen (z.B. Regeln für stillschweigende Abnahmen)
• Zahlungspläne
• Behandlung von Nachforderungen (Claims-Management)
• Konventionalstrafen
• Mediationsverfahren bei Konflikten

Formale Aspekte

Aufgrund der Bedeutung des Projektauftrags ist es wichtig, bestimmte formale Aspekte zu berücksichtigen. Dabei geht es nicht um Layoutfragen, sondern um Dokumenteneigenschaften, die das Arbeiten mit dem Projektauftrag unterstützen.

Selbstverständlichkeit: Schriftform

Natürlich ist die Schriftform keine gesetzliche Pflicht, schließlich kann ein Vertrag auch mündlich abgeschlossen werden. Aber aus der bisherigen Darstellung sollte hinreichend klar geworden sein, dass ein Projektauftrag seinen Sinn nur in schriftlicher Form erfüllen kann, selbst wenn es sich lediglich um ein internes Projekt handelt.

Versionierung, Paginierung und Gliederung

Bis zu seiner endgültigen Version durchläuft ein Projektauftrag üblicherweise viele Stationen. Er ist ein Arbeitsdokument, an dem viele Personen mitwirken und dessen Bestandteile mehrfach verändert werden können. Um diesen Entstehungsprozess effizient managen zu können, ist es unbedingt notwendig, dass der Projektauftrag in sauber definierten Versionen erstellt wird und dass es möglich ist, seine einzelnen Elemente leicht zu zitieren und zu identifizieren. Neben der Versionierung sollte der Projektauftrag deshalb durch geeignete Zwischenüberschriften gegliedert sein. In Kopf- oder Fußzeile muss neben der Version auch die Seitennummer stehen. Und er sollte ein Inhaltsverzeichnis haben, sobald er mehr als fünf Seiten umfasst.

Deckblatt

Normalerweise haben Sie die Situation, dass in Ihrem Unternehmen mehrere Projekte gleichzeitig durchgeführt werden. Wenn Sie also schnell den Auftrag für ein bestimmtes Projekt finden wollen, dann genügt es nicht, wenn auf jedem Deckblatt lediglich das Wort "Projektauftrag" steht. Um eine schnelle Orientierung zu ermöglichen, sollten mindestens folgende Informationen auf dem Deckblatt zusammengestellt sein:

• Name des Projekts
• ggf. die Projektnummer bzw. der Projektcode
• Versionsnummer und Erstelldatum

Fazit: Der Aufwand lohnt sich

Ein in der Literatur oft hervorgehobenes Charakteristikum von Projekten ist, dass sie risikobehaftet sind. Viele der Projektrisiken haben externe Ursachen, wie z.B. die Wetterbedingungen bei Bauvorhaben. Eines der größten Risiken für den Projekterfolg ist aber der unsachgemäß erstellte Projektauftrag. Dieses Risiko können Sie nun beseitigen, wenn Ihr Projektauftrag die in diesem Artikel beschriebenen Anforderungen erfüllt. Dies bedeutet zwar einen gewissen Aufwand, aber er ist weit geringer, als wenn Sie sich mit den Auswirkungen einer verweigerten Abnahme aufgrund eines unklaren Projektauftrags auseinandersetzen müssen.