Der Projektauftrag ist ein vermutlich regelmäßig unterschätztes Dokument im täglichen Projektgeschäft. Das mag zum Teil daran liegen, dass dieses Dokument entsteht wenn es noch gar kein richtiges Projekt gibt. Zu Unrecht – liegt in ihm neben dem formalen Auftrag an den Projektleiter doch von Anfang an der sprichwörtliche Kern des Projekt-Pudels.

„Ein Projekt ist ein einmaliges, zielgerichtetes Vorhaben unter zeitlichen, ressourcen- und qualitätsseitigen Vorgaben“ sagt eine der zahlreichen Definitionen. Hier steckt naturgemäß eine Menge von dem drin, was dem Projektleiter und seinem Team im Lauf eines Projekts den Schlaf rauben wird. Aber wie gelangt eine Organisation denn von einer Idee oder einem Bedarf zur Definition von Zielen und Vorgaben? Richtig, über den Projektauftrag.

KISS

Der kürzeste denkbare Projektauftrag benennt das Projekt „Einkaufen gehen“ und den Projektleiter „Ehemann“. Wie so manche Ehefrau aus eigener leidvoller Erfahrung wissen wird, reicht das jedoch nicht immer aus, um den Erfolg dieses Projekts sicherzustellen. Unabhängig davon ob der Mann diese Aufgabe bereits ausgeführt hat,  macht es sehr oft Sinn ihm noch einige weitere Vorgaben zu machen, unter anderem:

• Auftraggeber .. „Die Frau, und damit ist klar, dass Snacks und Bier nicht für den Wochenendeinkauf ausreichen.“
• Projektbeginn und –ende .. „Fahre jetzt los, und sei heute Nachmittag wieder hier.“
• Unternehmensbedarf und Ziele .. „Du musst nicht wissen was wir brauchen, ich sage es dir.“
• Projektergebnisse .. „Die Waren sollen bezahlt, nach Hause gefahren und in die korrekten Schränke (ja, auch Kühlschränke) verstaut werden.“
• Projektbudget .. (selbsterklärend)
• Projektleiter, evtl. Projektteam .. „Bitte nimm die Kinder mit, die wissen wo die Dinge stehen. Und bring sie bitte wieder mit zurück.“
• Annahmen und Beschränkungen .. „Bitte nur in der Innenstadt bewegen. Wenn Sie Margarine nicht haben, bring Olivenöl.“
• Ressourcenzuweisung .. „Nimm das Auto, den Anhänger kannst du jedoch hier lassen.“
• Terminvorgaben .. „Sei bis 12 Uhr beim Fleischer, denn danach ist er geschlossen. Tiefkühlwaren bitte maximal 30 Minuten vor deiner Rückkehr kaufen.“

Theoretisch ist es auch möglich diesen Projektauftrag ausschließlich mündlich zu formulieren. Im täglichen Leben hat sich jedoch bewährt, es dabei nicht zu belassen. Das hat so manchen Vorteil für den Projektablauf, vor allem in Bezug auf den Beginn (klares und gemeinsames Verständnis der Aufgabe), die Ausführung („Wann schließt nochmal der Fleischer?“) und auf die Abnahme („Danke. Und jetzt hole bitte die Kinder wieder aus dem Supermarkt ab.“)

Manche Projektleiter dokumentieren auch die Projektprozesse (wie bspw. Kommunikationswege) im Projektauftrag, und das ist sicher auch nicht falsch. Ich persönlich bin eher der Ansicht, den formellen Auftrag und dessen Rahmenbedingungen im Auftrag, und das Prozessmodell (Changes, Kommunikation, ..) im Project Management Plan festzuhalten. Das hilft, die Übersicht zu bewahren und grenzt beide Dokumente klar voneinander ab.

Ziele voraus!

Noch ein Wort zu den Zielen eines Projekts. Sehr häufig spricht man hier von SMARTen Zielen, die sicherstellen sollen dass man im Projekt nicht zu schwammig um einen schlecht definierten Fokus herumschleicht. Das macht auch unbedingt Sinn, hat jedoch einen Nachteil.

Wenn ein Aspekt des Projektumfangs nicht eindeutig terminierbar (oder noch beliebteres Problem: messbar) ist, kommt man mit dem Projektauftrag schon in Erklärungsnot. So ist es also mit SMART wie mit allen griffigen Konzepten: sie funktionieren nicht in jeder denkbaren Situation. Bevor Sie also Stakeholder, Team und Sponsor mit Forderungen nach messbaren Zielen wahnsinnig machen, weil jene eher nicht-funktionale Ziele wie Einfachheit oder Best Practice-Umsetzung im Sinn haben, drücken Sie lieber mal ein Auge zu.

Genügen alle Ziele den SMART Kriterien, ist das sehr gut. Fallen jedoch einzelne Ziele aus diesem Raster, diskutieren Sie diese ausführlich und schreiben Sie die Annahmen und Rahmenbedingungen in die Zieldefinition. Je genauer Sie dabei sind, desto mehr Missverständnisse vermeiden Sie im Nachhinein.

Wer schreibt, der bleibt

Sie hören also davon, dass irgendwo ein Problem besteht. Das kann im einfachsten Fall auch nur eine Idee sein, die ein einflussreicher, potentieller zukünftiger Sponsor Ihnen gegenüber äußert. Wenn es hier konkreter wird, sollten Sie aktiv werden.

Ermitteln Sie, wer zu dieser Idee beitragen kann und wer von der Umsetzung betroffen wäre. Haben Sie und Ihr Sponsor-in-spe alle Stakeholder ermittelt, machen Sie die Runde und nehmen Sie Anforderungen auf (idealerweise verfolgt in einer entsprechenden Anforderungsmatrix). Diese Phase ist sehr wichtig, um einerseits die Idee (und ein wenig Gemeinschaftsgefühl) zu verbreiten und andererseits verschiedene Sichten auf das Thema zu erhalten. Aus den Anforderungen bauen Sie dann ein grobes Zielmodell zusammen, bei dem Sie sicherstellen sollten dass das Projekt groß genug ist um etwas bewegen zu können, aber nicht so groß dass es unüberschaubar wird. Im Umfeld SAP hat sich eine Kern-Laufzeit zwischen 6 Monaten und 2 Jahren bewährt. Ist ihr Projekt wesentlich größer, denken Sie über eine Portionierung nach, beispielsweise in Form eines Programms.

Stimmen Sie die Ziele mit dem Sponsor und Ihren Stakeholdern ab, um sicherzustellen, dass alle das gleiche Verständnis haben. Anschließend begeben Sie sich in die Planung, definieren den konkreten Projektumfang, die dazu notwendige Projektorganisation, den zeitlichen Ablauf und die voraussichtlichen Kosten. Gehen Sie anschließend nochmal in die Abstimmung und stellen Sie sicher, dass alles gut verstanden wurde. Arbeiten Sie im ersten (konstruktiven) Teil mit den wohlgesonnenen Stakeholdern, und wenn das Dokument dann Hand und Fuß hat, stellen Sie sich den Skeptikern. Von letzteren kommt oft wertvoller Input zu Themen, die Ihnen sowieso früher oder später begegnen werden – dann also lieber früher.

Der Lebenszyklus

Alles drin im Auftrag, und alle einverstanden mit der Marschrichtung? Dann folgt ein letztes Gespräch mit dem Sponsor, und das Dokument kann offiziell abgenommen werden. Kommunizieren Sie die finale Dokumentenversion an alle Stakeholder. Legen Sie das Dokument außerdem zentral ab, damit das Team jederzeit darauf zugreifen kann.

Hängen Sie elementare Projektauftrags-Bestandteile (grobe Zielmatrix, Zeitplanung, Projektorganigramm) in ihrer jeweils aktuellsten Version in den Projekträumen aus. Veranstalten Sie ein Kickoff wo Sie dem Projektteam im Wesentlichen die Auftragsinhalte erläutern, und Fragen beantworten. Es hat sich außerdem bewährt, Ihren regelmäßigen Jour Fixe von Zeit zu Zeit dazu zu verwenden, die Auftragsinhalte in den Köpfen wieder aufzufrischen.

Wenn Sie einen Newsletter versenden, stellen Sie immer den Bezug zum Auftrag her. Die Empfänger hängen im Normalfall nicht im Projektgeschehen, und müssen tatsächlich bei jeder Kommunikation daran erinnert werden worum es gleich nochmal ging. Auch für Gespräche mit dem Sponsor ist der gelegentliche Blick in den Auftrag hilfreich. All das soll verhindern, dass im Projektverlauf die ursprünglich klar definierte Zielrichtung bei einigen der Beteiligten in Vergessenheit gerät.

Das Ende

Wenn Sie bisher alles richtig gemacht haben, haben Sie eine klare Vorstellung von den Erwartungen des Auftraggebers, und das Team, die Stakeholder und der Sponsor haben diese über den Projektverlauf hinweg auch nicht vergessen. Zum Projektende hin dient der Projektauftrag dann als finaler Grenzstein. Sind alle Anforderungen berücksichtigt worden? Wie steht es mit der Zielerreichung? Sind die Vorgaben in zeitlicher, qualitativer und ressourcenseitiger Hinsicht erfüllt?

Projektabschluss-Termin und finales Sponsorgespräch sollten sich diesen Fragen widmen, um auch zum Schluss eine gemeinsame Wahrnehmung auf den Projekterfolg herzustellen. Lessons Learned Sessions beschäftigen sich u.a. auch dann mit den Inhalten des Projektauftrags, wenn diese als nicht klar, oder als nicht klar kommuniziert wahrgenommen wurden. Hören Sie zu, und lernen Sie daraus für das nächste Mal.

Dabei viel Erfolg,