Klare Definition im Projektauftrag

Im dritten Teil unserer Reihe zum Thema „Projektmanagement im Unternehmen einführen“ geht es heute um das Thema, den Projektauftrag als Dokumentvorlage für das Unternehmen zu formulieren, um mitten in der Abwicklung oder zum Schluss hin kein böses Ende zu erleben.

Viele Missstände und Probleme in Projekten entstehen, weil der eigentliche Auftrag für das Projekt nicht klar ist. Wir alle kennen die Situationen, wo der Chef oder andere „höher bezahlte Weisheit und Einsicht“ (so hat ein früherer Kollege höhergestellte Führungskräfte genannt) einem – oft im Vorbeigehen oder in der Kaffeeküche – mal einen Auftrag rüberschiebt, der strenggenommen ein ordentliches Projekt darstellt.

Ich nenne das auch gerne die „Mach mal“-Projekte: als ordentlicher Untergebener solle man das doch bitte eben schnell erledigen. Dabei ist der Führungskraft nicht immer bewusst, dass sie gerade in die Rolle des Auftraggebers schlüpft und mich als Projektleiter mit einem ordentlichen Projekt mit einem gewissen Umfang beauftragt hat. Sprich: Die „kleine Aufgabe“ entpuppt sich als Projekt mit einer gewissen Laufzeit, einem ordentlichen Aufwand, der Zuarbeit mehrerer KollegInnen aus anderen Abteilungen und last but not least: einem Budget, das der Auftraggeber bereitstellen muss.

Projektauftrag oder Projektantrag?

Um genau solche Schwierigkeiten zu verhindern, empfehle ich meinen Seminar-TeilnehmerInnen, sich für das Projekt einen ordentlichen Auftrag geben zu lassen. Am besten gleich mit unserer Dokumentvorlage „Projektauftrag“. Und damit kommen wir schon zur ersten Frage, wie wir sie auch neulich in einem Workshop bei einem Kunden zum Thema „Professionalisierung des Projektmanagements“ hatten. Ist das jetzt ein Projektauftrag oder ein Projektantrag? Gute Frage, denn hier drückt sich meist schon das Führungsverständnis und die gelegentlich mangelnde Verantwortungsbereitschaft aus.

Wenn im Unternehmen Projekte „beantragt“ werden müssen, muss sie auch jemand freigeben, der damit zusätzlich mehr Verantwortung übernimmt als in meinen Augen sinnvoll ist. Ein Auftrag wird hingegen wie eine Art Vertrag zwischen zwei gleichberechtigten Partnern auf Augenhöhe geschlossen, nämlich Auftraggeber und ProjektleiterIn. Zur Bedeutung der Rollen im Projekt empfehlen wir Ihnen unseren Blogbeitrag zur Projektorganisation. Daher ist es in meinem Verständnis ein Projektauftrag und so können Auftraggeber und ProjektleiterIn ihre jeweilige Verantwortung für das Projektergebnis übernehmen.

In unserer Vorlage zum Projektauftrag, die Sie zusammen mit anderen nützlichen Vorlagen und Beispielen herunterladen können, findet sich dann noch ein Dokumentkopf mit Angaben zur Dokumentversion. Dieser listet den Status des Dokuments auf (z.B. Entwurf oder freigegeben), den Autor (in der Regel der Projektleiter, allerdings tatkräftig unterstützt vom Auftraggeber), die Dateiablage und den Verteiler für das Dokument (Standard: Auftraggeber, Projektleiter, Team – falls weitere Stakeholder oder die Geschäftsführung, Personal, Organisationsentwicklung etc. informiert werden sollen, bitte ebenso auflisten).

Schnelle Übersicht auf dem Deckblatt

Wenn es sinnvoll erscheint, kann hier auch noch kurz die Entstehungsgeschichte des Projektauftrags mit ein paar Stichworten nachvollzogen und beschrieben werden. Also z.B.

Version 0.1: Erstellung, Einpflegen der Infos aus Erstgespräch mit dem Auftraggeber,
Version 0.2: Einpflegen des Projekthintergrunds, Budgets und Fertigstellungstermin,
Version 1.0: Finalisierung, offizielle Beauftragung des Projekts durch AG an PL und Team.

Im Workshop hat unser Kunde noch ein paar hilfreiche Ideen auf der Titelseite ergänzt. So wurde zum Beispiel eine Kurzbeschreibung des Projekts aufgenommen, damit man gleich erkennen kann, worum es im Projekt geht. Auch wurde die Projektorganisation (konkrete Besetzung der Rollen Auftraggeber, Projektleiter und Team) mit aufs Deckblatt genommen. Das sind alles sinnvolle Anpassungen. Ich empfehle Ihnen, einfach mit ein paar erfahrenen Projektleitern und vielleicht der Geschäftsführung hier die Vorlage so anzupassen, wie sie Ihnen im Unternehmen nützlich erscheint. Manche Kunden nehmen an dieser Stelle auch noch gleich die Projektart mit auf, also z.B. IT-Projekt, Infrastrukturprojekt, Organisationsentwicklungsprojekt. Alles, was Ihnen hilfreich erscheint, ist erlaubt und gut.

Die Grundidee der Dokumentvorlage ist nicht, den Projektleitern mit Bürokratie die Arbeit zu erschweren, sondern ihnen mit dem Dokument eine echte Arbeitshilfe im Sinne einer erweiterten Checkliste an die Hand zu geben. Wenn ein Punkt Ihnen als Projektleiter nicht sinnvoll erscheint und auch keinen Nutzen bringt, dann ändern Sie bitte die Vorlage so ab, wie es Ihnen hilfreich erscheint.

Konkrete Inhalte des Projektauftrags

So, nun soll es um die konkreten Inhalte des Projektauftrags gehen. Erster Punkt im Dokument ist der Projekthintergrund. Letztlich geht es hier um die Frage, warum wir das Projekt überhaupt angehen. Erläutern Sie kurz die Idee, die hinter dem Projekt steht – der Inhalt dazu sollte vom Auftraggeber kommen. Schließlich kann dieser selbst am Klarsten beschreiben, warum das Projekt gemacht wird.

Als nächstes kommen die Ziele und Abgrenzung. Tragen Sie hier die Projektziele ein, am besten gemäß der SMART-Formel: schriftlich und spezifisch, messbar, attraktiv, realistisch und terminiert. Aber auch die Nicht-Ziele bzw. die Abgrenzung des Projekts können hier erwähnt werden, also: Wo hört das Projekt auf? So kann z.B. das Projekt die Entwicklung eines neuen Produkts umfassen. Die Markteinführung hingegen soll nicht mehr Teil des Projekts sein, sondern wird als Folgeprojekt bzw. Tagesgeschäft im Bereich Marketing / Vertrieb durchgeführt.

Bei den Anforderungen an das Projektergebnis nennen Sie die Anforderungen, die das Projektergebnis (in Abgrenzung von den Projektzielen) leisten muss. Beispiele können sein: Gesetzliche Vorgaben, Normen (z.B. Qualitätsnormen), die Kompatibilität mit bestimmten Systemen oder Abläufen/Prozessen, die Eignung im Rahmen der Unternehmenskultur. Dazu kommen eventuell auch rein qualitative Angaben wie: „soll zu keiner Verschlechterung einer Situation oder der Zufriedenheit führen“.

Schnittstellen mit anderen Bereichen

Nun kommen die Schnittstellen des Projekts. Diese können sich auf Organisationseinheiten (andere Abteilungen), andere Projekte, (technische/IT-) Systeme oder Prozesse im Unternehmen beziehen. Wo immer hier Berührungspunkte vorhanden sind, sollten Sie diese aufführen und die Ausgestaltung der Schnittstelle mit den jeweiligen Verantwortlichen klären.

Ich gebe Ihnen gerne ein paar Beispiele dafür:

Organisation: Bei der Markteinführung sind Vertrieb und Marketing miteinzubeziehen (ist erfüllt durch Benennung der Teammitglieder A und B, Chef C wird 14-tägig mit Statusreport versorgt). Oder: Die Abstimmung mit dem Personalwesen wird sichergestellt durch einen 14-tägigen Jour fixe mit der Personalleiterin.
Projekte: Wir pflegen einen regelmäßigen Austausch mit dem „Nachbarprojekt Super 2“ durch gegenseitiges Reporting und wöchentlichen Projektleiter-Jour fixe.
Systeme: Das Projekt betrifft das Produktionsplanungs-System „SuperProd“, die technische Schnittstelle wird im Rahmen des Projekts entwickelt. Oder: Das Projekt wird in das bestehende SAP-System integriert.
Prozesse: Die Abstimmung mit dem bestehenden Prozess der Investitionsfreigabe ist im Projekt zu klären. Oder: Vermutlich bedingt das Projekt eine Änderung der Produktionsprozesse im Werk Z – der Werkleiter nimmt regelmäßig am Projekt-Jour fixe über Skype teil (Prozess und Organisation).

Als nächstes kommt eine kurze Beschreibung der groben Vorgehensweise. Falls man aus heutiger Sicht die Vorgehensweise im Projekt grob beschreiben kann und diese Schilderung sinnvoll erscheint, dann bitte kurz skizzieren. Beispiel: Marktrecherche – Entwicklung des Produkts – Erste Testläufe und Prototypen in der Produktion – Übergabe an Partner. Alle Punkte des Projektauftrags können stichpunktartig sein, das reicht in aller Regel auch aus. Machen Sie sich und den Lesern nicht die Mühe, zuviel Text auszuformulieren. Es geht darum, kurz und knapp die Inhalte zu beschreiben und keinen Projektroman.

Die „Lebensversicherung“ für den Projektleiter

Ein wichtiger Punkt für Sie als ProjektleiterIn sind die Rahmenbedingungen und Voraussetzungen, die erfüllt sein müssen, damit Sie überhaupt das Projekt ordentlich „fahren“ können. Ich nenne das auch gerne „die Lebensversicherung“ als Projektleiter. Hier liste ich als Projektleiter alle Bedingungen und Voraussetzungen auf, die wir als Team benötigen, um das Projekt überhaupt durchführen zu können. Das beginnt bei Ressourcen und Budget, beinhaltet oft die regelmäßige (!) Mitwirkung des Auftraggebers, geht weiter über organisatorische Themen wie Projektarbeitsräume, Zugang zu Informationen, Gebäuden, vielleicht die Nutzung eines Fahrzeugs, aber auch technische Voraussetzungen wie Logins für IT-Systeme. Bitte listen Sie hier wirklich alles auf, was für die ordentliche Arbeit im Projekt bereitgestellt werden muss. Verantwortlich für die Erfüllung der Punkte ist der Auftraggeber. Deswegen teilen Sie dem Auftraggeber das auch alles mit und besprechen die Punkte mit ihm oder ihr.

Kein Projekt ohne Risiko, deswegen führen wir als nächstes die möglichen Risiken auf. Zu diesem frühen Zeitpunkt wird eine detaillierte Risiko-Analyse oft schwierig sein, gleichzeitig zeichnen sich manche Risiken aber oft schon zu Beginn eines Projekts ab. Beispiele dafür sind: Widerstände aus der Belegschaft gegen die neue Lösung, fehlende Zuarbeit einer anderen Abteilung oder eines anderen Standorts, knappe Ressourcen und daraus resultierende Konflikte. All das, was Ihnen heute als möglich bis wahrscheinlich erscheint, darf hier genannt werden.

Die Lösungsalternativen wären der nächste Punkt im Projektauftrag. Natürlich kann man über dessen Notwendigkeit diskutieren. Wenn es für Sie wenig Sinn macht, nehmen Sie den Punkt aus Ihrer Dokumentvorlage heraus. Falls es für das konkrete Projekt aber sinnvoll erscheint, beschreiben Sie einfach kurz in Stichworten die möglichen Alternativen. Die Klassiker wären hier „kaufen vom Händler/Dienstleister“ oder „selbst machen/entwickeln“.

Wirtschaftlichkeit und Begründung des Projekts

Nun kommt noch ein sehr wichtiger Teil: die Wirtschaftlichkeit bzw. Projektbegründung. Jedes Projekt stellt eine Investition in Form von Budget und Aufwand dar, die sich aus Unternehmenssicht irgendwann auch wieder rechnen sollte. Daher kann an dieser Stelle eine zumindest grobe Berechnung stehen, wie sich die Investition in das Projekt auch monetär wieder rechnet. Etwa durch höhere Umsätze, schnellere Durchlaufzeiten, mehr Output in der Produktion. Schwieriger wird es bei „weichen Faktoren“ wie besserer Zusammenarbeit. Dennoch empfehle ich, auch diese Faktoren hier aufzulisten.

Manchmal müssen Projekte auch durchgeführt werden, die sich monetär nicht rechnen – weil gesetzliche Vorgaben zu erfüllen sind oder weil man übergeordnete bzw. strategische Ziele damit verfolgt. Diese Ziele begründen natürlich ebenso ein Projekt, auch wenn sie sich – kaufmännisch gesehen – nicht rechnen. Beispiele dazu können sein:

die Erfüllung gesetzlicher Auflagen bzw. Vorschriften,
eine Gesetzesänderung,
der Neubau einer Produktionsanlage, um für die nächsten 20 Jahre gut aufgestellt zu sein,
die Erschließung eines komplett neuen und strategisch wichtigen Markts,
die Einführung einer komplett neuen Produktlinie (mit unklaren Erfolgsaussichten),
die Einführung eines ERP-Systems oder
die Ablöse eines langjährigen Zulieferers/Dienstleisters aufgrund zahlreicher Mängel.

Besetzung der Projektrollen

Als nächstes beschreiben wir die Projektorganisation anhand der Projektrollen:

Auftraggeber: die Person, die das Projekt beauftragt, für Budget und Ressourcen sorgt und das Projektergebnis am Ende auch wieder abnimmt.
Lenkungskreis: nur falls sinnvoll und im Unternehmen definiert – der Lenkungskreis wird üblicherweise mit der nächsthöheren Management-/Entscheiderebene aller am Projekt beteiligten Unternehmensbereiche besetzt, oft ergänzt durch die Geschäftsführung.
Projektleiter: ähnlich wie bei Auftraggeber und Highlandern, bitte um Nennung des Namens einer einzelnen Person.
Team: hier sind alle Teammitglieder aufzuführen, auch ihre Mitwirkung am Projekt, vor allem mit Blick auf die benötigte Kapazität. Bitte beachten: Bei einer Vollzeitstelle bedeutet z.B. 20% der Arbeitsleistung einen Tag in der Woche. Die Kapazität ist zu klären und mit dem disziplinarischen Vorgesetzten zu vereinbaren (obliegt dem Auftraggeber, gerne unterstützt vom Projektleiter).

Wir sind fast fertig. Zum Schluss kommt noch die erste und eher grobe Projektplanung:

Meilensteine/Termine: soweit heute schon bekannt und grob geplant, finden sich hier einige wichtige Meilensteine (z.B. Markteinführung ab Juli).
Budget: Soweit heute schon bekannt und zumindest grob geplant, sollten beim Budget üblicherweise alle extern anfallenden Kosten (= Eingang einer Rechnung von extern) erfasst werden, nicht die internen Aufwandskosten – es sei denn, man will diese erfassen und controllen. Das ist z.B. typisch bei der Aufteilung des Unternehmens in Profitcenter.
Eigenleistung: üblicherweise als Aufwand angegeben, Ergebnis der Planung, typischerweise in einer bestimmten Menge an Personentagen/-monaten. Macht nur Sinn, wenn die Zahl auch erhoben und gemessen wird.
Fremdleistung: falls Fremdleistung erhoben und überwacht wird (z.B. Zuarbeit oder Beratung auf Basis von Time & Material-Verträgen)

Der Projektauftrag schließt, wie jeder ordentliche Vertrag, mit der Unterschrift der beiden Vertragspartner, hier also von Auftraggeber und Projektleiter. Ob Sie hier wirklich das Dokument unterschreiben lassen, ist ein wenig Stilfrage – aber die händische Unterschrift verleiht dem Projektauftrag noch ein ordentliches Stück mehr an Verbindlichkeit.

Unsere Dokumentvorlage (Word) für den Projektauftrag können Sie gerne zusammen mit weiteren Vorlagen in Ihrem Unternehmen nutzen.

Sie wollen mit uns gemeinsam in einem Workshop die Dokumentvorlage an die Besonderheiten Ihres Unternehmens anpassen? Gerne, sprechen Sie uns an, am besten per Mail an info@drblaschka.de

Foto: clipdealer