Fünf Dinge, die in Ihrem Projektauftrag stehen sollten

So schaffen Sie Klarheit in Ihrer Projektbeschreibung

Am Anfang war das Wort. So sollte es auch in Projekten sein. Der Projektauftrag, auch auch als Projektcharta oder im Neudeutschen als Statement of Work (SoW) bezeichnet, beschreibt Ihr Projektvorhaben mit allen wesentlichen Faktoren. Vor allem bei der Einführung von IT-Systemen sollte ein Projektauftrag sehr präzise formuliert sein, da sonst Projektumfänge und damit Budgets und Zeitpläne unkontrolliert wuchern.
Die folgenden Bestandteile gehören mindestens in einen Projektauftrag. Weil es mit einem IT-Projekt viel leichter ist, Businesskomponenten von Projektkomponenten abzugrenzen, wähle ich einen Dauerbrenner, also eine SAP-Einführung, weil Unternehmen sich die so gerne viel schwerer machen, als sie es sein müsste.

Projekt- und Businessziele

In eine ordentliche Präambel gehören ein Hinweis auf den den Kontext, die Motivatoren und Treiber des Projektes und eine Zuordnung zur Auftraggeberebene. Wenn Sie ein Haus bauen, dann schließt ja auch nicht ihr minderjähriges Kind die Verträge ab, sondern der Chef im Haus. Genau so sollte es auch bei Projekten sein.
Businessziele sind die übergeordneten Ziele aus Sicht des Business. Sie schaffen den Kontext für das Projekt. So ist es zum Beispiel kein Businessziel, SAP einzuführen. Genau genommen ist es nicht einmal ein gutes Projektziel. Kein Mensch führt Software ein, ohne einen triftigen Grund dafür zu haben. Dieser triftige Grund ist das Businessziel. Das könnte in diesem Fall beispielsweise lauten:
„Ziel ist es, die internen Prozesse zu vereinheitlichen und die Systemlandschaft zu bereinigen, indem die Prozesse in Einkauf, Logistik, Finanzen und Vertriebsinnendienst auf SAP migriert werden.“
Dieses Beispiel verdeutlicht, dass das übergeordnete Ziel eines sein sollte, das aus Sicht des Geschäftes einen Mehrwert bietet. Weiterhin adressiert es Abläufe und organisatorische Komponenten, den es geht um die betroffenen Bereiche und um die zugehörigen Prozesse.
Projektziele adressieren die Umsetzung der übergeordneten Ziele. Für sauber definierte Projektziele gelten klar definierte Regeln.
Ein Beispiel für ein ungenügend präzisiertes Projektziel ist der folgende Satz:
„Ziel ist es, die Systeme im Einkauf, der Logistik, der Buchhaltung und dem Vertriebsinnendienst durch SAP abzulösen.“
Um aus diesem schwammigen Ziel ein einigermaßen präzises zu machen, fehlen noch einige Komponenten:

  • Die Zeitkomponente: In welchem Zeitraum soll das geschehen?
  • Messbarkeit: qualitative und quantitative Messbarkeit, so zum Beispiel eine Liste der Systeme und der Prozesse sowie ein Ausschluss der Themen, die nicht behandelt werden. (Beispiel: „Schnittstellen zu den Systemen X, Y, Z sind im ersten Schritt ausgeschlossen.“)
  • Verantwortlichkeiten: Wer macht es?
  • Konsens: Ziele, für die sich niemand starkmacht, werden nicht oder nur unter größten Schmerzen erreicht.
  • Realistisch: Die Wahrscheinlichkeit, dass die Ziele im Beispiel in 60 Tagen umgesetzt sind, ist nicht groß. Ziele sollten also erreichbar sein. Das klingt banal, aber jedes Projekt, dass ich „retten“ musste, krankte an unrealistischen Zielen oder die Ziele waren so schwammig, dass die Projekte unkontrolliert gewuchert sind.

Der Umfang

Ein ordentlich begrenzter Umfang lebt einerseits von einer Positivliste, also der Liste der der Maßnahmen oder Themen, die im Umfang enthalten sind. Andererseits gehört in den Umfang auch die Negativliste, also die Liste der Dinge, die explizit nicht enthalten sind. Das ist immer wichtig, aber besonders dann, wenn ein Projekt mehrere Niederlassungen oder Standorte betrifft. Bedenken Sie, dass der Projektleiter und das Team sonst völlig unnötige Diskussionen führen müssen. Ein kleines Beispiel: In einem globalen IT-Projekt sollen über 40 Niederlassungen weltweit auf ein einheitliches ERP-System migriert werden. Jede dieser Niederlassungen bringt andere Systeme und Schnittstellenanforderungen ein. Da das Ziel innerhalb eines gesetzten Zeitraums und Budgets erreicht werden soll, wird nach einer umfangreichen Analyse bis auf Niederlassungs-Ebene im Projektauftrag festgelegt, dass bestimmte Schnittstellen in der ersten Phase ausgeschlossen werden sollen. Im ersten Schritt sollen alle Niederlassungen ihre Kernprozesse so weit wie möglich vereinheitlichen. Durch den expliziten Ausschluss von Schnittstellen und Sonderfunktionalitäten erspart das Management Team dem Projektteam die zu erwartenden lokalen Diskussionen über „Extrawünsche“ und nebenbei auch die damit verbundenen Reibereien und Konflikte.
In unserem Beispiel würden wir also in der Projektcharta oder im Projektauftrag eine Liste von Prozessen und Schnittstellen finden, die in SAP abzubilden sind. Darüber hinaus würden wir aber auch eine Liste der Prozesse und Schnittstellen finden, die nicht berührt sind. Dieser Ausschluss verhindert, dass das Projektteam sich im Laufe des Projektes verzettelt und Sonderwünsche erfüllt, die zulasten des Budgets oder des Zeitplans gehen.
In den Umfang gehören übrigens auch die Liste der betroffenen Abteilungen, Bereiche oder Niederlassungen. Der Umfang markiert die Grenzen des Projektes. Wenn diese schwammig sind, dann kann man sich eigentlich nicht beklagen, wenn sie immer wieder ausgedehnt werden. Bedenken Sie, dass Neues auch Begehrlichkeiten weckt. Das mag positiv für die Akzeptanz sein, aber es birgt auch immer das Risiko, dass plötzlich alle mehr wollen, als das Projekt liefern kann.

Annahmen und Rahmenbedingungen

Projekte finden nicht im luftleeren Raum statt. Eine klare Beschreibung der Annahmen und Rahmenbedingungen, unter denen das Projekt stattfindet, schützt sie vor teuren Enttäuschungen.
Es gehört zum Projektmanagement- und Controllingprozess, diese Annahmen und Rahmenbedingungen regelmäßig zu validieren und gegebenenfalls im Lenkungsausschuss Korrekturen vorzunehmen. Dies gilt insbesondere für Vorhaben, bei denen die Rahmenbedingungen zum Beispiel durch gesetzliche Richtlinien oder sonstige Faktoren bestimmt sind, die außerhalb der Kontrolle der Beteiligten liegen.

Risiken und Einschränkungen

Diesem Kapitel widmen viele Unternehmen einfach nicht die Sorgfalt, die es verdient. Ich will einmal eine Liste von Dauerbrennern benennen, die einfach ignoriert werden. Mein Lieblingsthema ist die Ressourcenverfügbarkeit. Irgendwie verstehen Führungskräfte einfach nicht, dass Projektaufgaben zum Tagesgeschäft hinzukommen. Das Thema Freistellungen in Projekten ist ein scheinbar nicht auflösbares Paradox. Irgendwie scheinen ansonsten geistig gesunde Menschen bei Projekten eine kognitive Hemmung zu haben. Oder es besteht ein Missverständnis, was die Anzahl der Stunden angeht, die ein Mensch am Tag leisten kann. Das ist ähnlich wie mit Flugzeugen. Die werden seltsamerweise auch nicht größer, wenn jeder seinen Koffer als Handgepäck mitführt. Ressourcenverfügbarkeiten wirken sich unmittelbar auf die Qualität und die Erfüllung von Projektzielen aus. Trotzdem kenne ich kein Projekt, in dem die Mitglieder des Projektteams von ihren Führungskräften ausreichend freigestellt werden. Oft sind es die Kollegen, die die Last einfach mittragen. Das Thema wird oft einfach vergessen, sodass die jeweils Verantwortlichen oft gar nicht aktiv einplanen können, dass ihre Mitarbeiter nicht voll produktiv am Tagesgeschäft teilhaben können, wenn sie im Projekt tätig sind. Aber auch andere Themen, die sich einschränkend auswirken oder sogar ein Risiko darstellen können, werden gerne vergessen. Dazu gehören:

  • Wechsel im Management
  • Wirtschaftliche Faktoren: Kränkelt ein Bereich, so kann ein Projekt als zusätzliche Belastung eventuell riskant sein.
  • Wichtige Ereignisse, die Ressourcen beanspruchen
  • Strategische Faktoren wie Zukäufe, Fusionen oder Umstrukturierungen
  • Abgrenzung zu anderen Projekten

Auch diese Faktoren gehören auf die Watchlist des Lenkungsausschusses, weil sie sehr stark auf ein Projekt wirken können.

Projektbeteiligte

Auch die wichtigsten Beteiligten gehören mit einer Kurzbeschreibung ihres Verantwortungsbereiches und ihrer Rolle in den Projektauftrag.
Vor allem die Entscheiderstruktur sollte hier beschrieben sein. Das gesamte Steuerungsmodell zu beschreiben würde den Rahmen sprengen, aber vor allem wenn Externe beteiligt sind, sollte das Innen- und Außenverhältnis der Beteiligten geklärt sein.
Der Projektauftrag sollte durch den Auftraggeber mit den Beteiligten besprochen werden, damit diese entsprechend planen können. Weiterhin sollten Einwände der betroffenen Abteilungen oder Bereiche frühzeitig besprochen werden, damit keine Blockadehaltungen entstehen.

Bildnachweis: jock+scott/photocase.de
Sie wollen keinen Beitrag mehr verpassen? Abonnieren Sie diesen Blog als Email-Newsletter.
Der Artikel hat Ihnen gefallen? Wir freuen uns, wenn Sie ihn in diesem Fall teilen.

Share on LinkedInTweet about this on TwitterGoogle+Share on FacebookPrint this pageEmail to someone