„Wir sollten die Wartungsberichte digitalisieren.“ Ein solcher Satz kann ein sinnvolles Vorhaben anstoßen. Als Arbeitsgrundlage reicht er aber nicht: Geht es um eine neue Software, weniger Rückfragen oder einen einheitlichen Freigabeprozess? Wer darf Entscheidungen treffen? Und wann wäre das Projekt wirklich abgeschlossen?
Wenn Du einen Projektauftrag erstellst, übersetzt Du die erste Idee in einen abgestimmten Rahmen. Dieser Beitrag zeigt das an einem durchgehenden Beispiel aus dem technischen Prozessmanagement. Du lernst, wie Du Ziel, Umfang, Ergebnisse und Freigabe so beschreibst, dass offene Entscheidungen sichtbar bleiben. Alle Unternehmen, Zahlen und Vereinbarungen im Beispiel sind fiktiv.
Projektauftrag, Business Case und Projektplan: drei verschiedene Aufgaben
Der Projektauftrag hält fest, welches Vorhaben im Unternehmen freigegeben wird und welchen Entscheidungsspielraum die Projektleitung erhält. Das Project Management Institute erläutert diese Funktion des Project Charter: Es schafft die Grundlage für die autorisierte Arbeit, nicht bereits deren vollständige Detailplanung. Die konkrete Freigabe richtet sich nach den Regeln Deiner Organisation.
Die PM²-Übersicht der Europäischen Kommission unterscheidet ergänzend zwischen wirtschaftlicher Begründung im Business Case, übergeordnetem Projektrahmen im Charter und detaillierten Arbeitspaketen, Terminen und Budget im Projektarbeitsplan.
Für Dein Vorhaben bedeutet das: Die Entscheidung, ob sich die Investition lohnt, ist eine andere als die Zustimmung zum Projektumfang. Beides wiederum ersetzt nicht die spätere Ablaufplanung. Ein Projektauftrag sollte deshalb verständlich und entscheidungsfähig sein, ohne jede einzelne Besprechung oder Tätigkeit vorwegzunehmen.
Vom unscharfen Wunsch zum konkreten Arbeitsauftrag
Im Beispiel erhält eine Instandhaltungsabteilung Wartungsberichte in verschiedenen Dateiformaten. Mitarbeitende fragen wiederholt nach, welche Fassung geprüft wurde. Die Abteilungsleiterin möchte zunächst einen einheitlichen Ablauf für eine ausgewählte Maschinenlinie testen.
Eine geeignete Arbeitsfassung lautet:
Für Maschinenlinie A wird ein digitaler Ablauf zur Erstellung, Prüfung und Freigabe von Wartungsberichten eingerichtet und im Pilotbetrieb erprobt. Das Projekt liefert eine abgestimmte Berichtsvorlage, einen nachvollziehbaren Freigabeablauf und eine dokumentierte Übergabe an die Instandhaltung. Über einen späteren Rollout wird separat entschieden.
Diese Formulierung benennt einen Bereich und konkrete Ergebnisse. Sie behauptet noch nicht, dass dadurch eine bestimmte Kostensenkung sicher erreicht wird. Den erwarteten Nutzen würdest Du im Beispiel zusätzlich begründen, etwa durch eine vorherige Auswertung der Rückfragen und einen Vergleich nach dem Pilotbetrieb.
Den Umfang begrenzen, ohne wichtige Schnittstellen auszublenden
Für die fiktive Maschinenlinie gehören die Berichtsvorlage, die Abstimmung mit ihren Nutzern, die Einrichtung im vorhandenen System und der Pilotversuch zum Auftrag. Als Nicht-Ziele stehen ausdrücklich dabei: keine Ablösung des gesamten Wartungssystems, keine Einführung an weiteren Standorten und keine Neugestaltung aller Instandhaltungsprozesse.
Stell Dir nun vor, der Einkauf bittet zusätzlich um eine Lieferantenbewertung im selben Formular. Das klingt zunächst nach einer kleinen Ergänzung. Im Beispiel verändert es aber Nutzerkreis, Datenbedarf und fachliche Zuständigkeit. Die ausgeschlossenen Themen helfen, diesen Wunsch als Erweiterung zu erkennen und nicht stillschweigend mitzuerledigen.
Die Grenze darf zugleich keine Ausrede sein, notwendige Schnittstellen zu ignorieren. Die IT muss beispielsweise klären, ob das vorhandene System den geplanten Ablauf unterstützt. Diese Prüfung gehört zum Pilotprojekt, auch wenn die Beschaffung eines neuen Systems nicht freigegeben ist. Falls die technische Grundlage fehlt, braucht es eine neue Entscheidung.
Lieferergebnisse und Abnahme zusammen formulieren
„Der Prozess ist besser“ wäre für unser Beispiel kein überprüfbares Abschlusskriterium. Schreibe stattdessen bei jedem Ergebnis dazu, wie und durch wen es geprüft wird:
- Berichtsvorlage: Instandhaltung und Qualitätsverantwortliche prüfen anhand dreier vereinbarter Testfälle, ob die benötigten Angaben enthalten sind.
- Freigabeablauf: Im Pilotversuch lässt sich für jeden Testbericht erkennen, wer ihn erstellt, geprüft und freigegeben hat. Die Abteilungsleiterin bestätigt das dokumentierte Testergebnis.
- Übergabe: Eine benannte Betreuungsperson erhält die Anleitung und bearbeitet einen Beispielbericht selbstständig; offene Punkte werden protokolliert.
Die PM²-Vorlagensammlung bietet einen eigenen Deliverables Acceptance Plan. Das verdeutlicht die Trennung zwischen Ergebnisbeschreibung und organisierter Abnahme. Für das kleine Beispiel könntest Du zunächst eine gemeinsame Liste verwenden und die Testdetails später ergänzen.
Die drei Testfälle wären hier eine Vereinbarung des Beispielteams, kein allgemeiner Qualitätsstandard. Ebenso beweist eine abgenommene Vorlage noch nicht den langfristigen Nutzen. Wenn weniger Rückfragen das gewünschte Ergebnis im Betrieb sind, muss das später anhand einer passenden Messung beurteilt werden.
Ressourcen und Befugnisse auf Widersprüche prüfen
Im fiktiven Entwurf sind zunächst 40 interne Arbeitsstunden für die Planung vorgesehen. Das ist eine frühe Schätzung, keine bestätigte Kapazität. Die Abteilungsleiterin soll mit den beteiligten Führungskräften klären, welche Zeit tatsächlich verfügbar ist. Ein Gesamtaufwand für die Umsetzung wird erst nach Prüfung der technischen Möglichkeiten geschätzt.
Auch die Befugnisse brauchen eine konkrete Grenze. Die Projektleiterin darf im Beispiel Abstimmungstermine koordinieren und Varianten der Berichtsvorlage entwickeln. Sie darf jedoch weder zusätzliche Software einkaufen noch Mitarbeitende anderer Abteilungen ohne deren Zustimmung einplanen. Darüber entscheidet die Auftraggeberin im jeweils zuständigen Freigabeweg.
Für die erste Prüfung würde ich im Beispiel drei offene Punkte markieren: Unterstützt das vorhandene System die Freigabe? Steht die IT-Fachperson zur Verfügung? Sind alle vorgesehenen Nutzer im Pilot vertreten? Neben jedem Punkt steht, wer ihn bis wann klärt. Ein ungeprüftes „wird schon funktionieren“ wird dadurch nicht als gesicherte Grundlage behandelt.
Ein fertig ausgefülltes Dokument ist noch keine Freigabe
Die Arbeitsfassung wird mit Instandhaltung, IT und Qualitätsverantwortlichen besprochen. Angenommen, dabei zeigt sich, dass zunächst nur die technischen Möglichkeiten untersucht werden können: Dann sollte der Auftrag vorerst genau diese Untersuchung umfassen. Die Einrichtung des Ablaufs wäre ein späterer Entscheidungsschritt.
Dokumentiere im Beispiel die freigegebene Fassung mit Datum, Verantwortlichen und den tatsächlich genehmigten Ressourcen. Halte auch fest, wann eine erneute Entscheidung nötig ist, etwa beim Wechsel auf ein neues System. Änderungswünsche werden mit ihren Auswirkungen auf Umfang und Aufwand vorgelegt. Diese Vorgehensweise folgt der PM²-Übersicht zur abgestimmten Bewertung von Projektänderungen; die betrieblichen Zuständigkeiten bleiben maßgeblich.
FAQ: Projektauftrag erstellen
Wie lang muss ein Projektauftrag sein?
Es gibt dafür keine universelle Seitenzahl. Für unser Pilotprojekt wäre eine kurze Arbeitsfassung mit ergänzender Ergebnisliste denkbar. Maßgeblich sind die Vorgaben Deiner Organisation und die Verständlichkeit der Entscheidung, nicht die Länge allein.
Wer schreibt und wer genehmigt ihn?
Nach PMI kann die Projektleitung den Entwurf vorbereiten; die Freigabe braucht eine dazu befugte Person. Im Beispiel wäre das die Auftraggeberin im vorgesehenen betrieblichen Verfahren. Ein selbst erstelltes Dokument verleiht der Projektleitung keine zusätzlichen Befugnisse.
Was mache ich, wenn das Ergebnis noch nicht genau feststeht?
Im Beispiel würdest Du zuerst einen begrenzten Untersuchungsauftrag formulieren: technische Optionen prüfen, Aufwand abschätzen und eine Entscheidungsvorlage liefern. Damit werden Unsicherheiten bearbeitet, ohne schon die gesamte Umsetzung als beschlossen darzustellen.
Fazit: Klarheit entsteht vor der Detailplanung
Ein guter Projektauftrag macht deutlich, welches Problem bearbeitet wird, was geliefert werden soll und wo der Auftrag endet. Unser Beispiel zeigt besonders: Ergebnis, Abnahme, Kapazität und Befugnisse müssen zusammenpassen. Fehlende Informationen gehören als offene Punkte auf den Tisch.
Wenn Du technische Abläufe mit Qualitäts- und Prozessmanagement verbinden möchtest, informiere Dich über das Angebot Spezialist: Technisches Management – Qualitäts- & Prozessmanagement. Auf der öffentlichen Angebotsseite ist auch Projekt- und Prozessmanagement aufgeführt. Für Fragen zur Passung und zum aktuellen Kursaufbau kannst Du GrandEdu Media kontaktieren.