Projektbegriff: Manche werden sagen, die Frage sei akademisch. Lassen Sie sich überraschen, was man dazu sagen kann – und welche Auswirkungen das für die Praxis hat. Denn wie wir ein Projekt definieren, entscheidet vorab darüber, worauf wir den Blick richten, wen wir in die Verantwortung nehmen und welche Steuerungsgrößen wir überhaupt für relevant halten.
Ich möchte den Projektbegriff von vornherein einschränken auf Projekte, die von Organisationen, von Unternehmen durchgeführt werden. Der Auslöser für ein Projekt ist in der Regel ein Umsetzungsauftrag. Irgendeine Veränderung soll umgesetzt werden, hoffentlich zum Besseren. Schon hier liegt eine erste Weichenstellung verborgen: Geht es um die Veränderung selbst – oder um das, was nach der Veränderung anders und besser sein soll?
Es macht einen großen Unterschied, ob ich ein Projekt definiere als temporäres Vorhaben, um gemeinsam ein Lieferergebnis herzustellen, oder ob ich ein Projekt als temporäre Organisation definiere, mit dem Ziel, Produkte zu liefern, die einen Business Case erfüllen. Im ersten Fall fokussiere ich auf die Lieferung, im zweiten auf die Organisation und den Geschäftszweck. Die erste Definition endet, sobald das Ergebnis übergeben ist. Die zweite fragt weiter: Wofür eigentlich? Welcher Nutzen rechtfertigt den Aufwand – und tut er das noch, wenn sich die Rahmenbedingungen ändern?
Wenn ich ein Projekt als Lieferaufgabe betrachte, bin ich bei den Vorgängen, der work. Sehe ich das Projekt ganzheitlich als Kunden-Lieferanten-Beziehung, bin ich bei Produkten (products) bzw. Ergebnissen. Im einen Fall ist der Projektplan eine Abfolge von Tätigkeiten, im anderen eine Abfolge von übergebenen, abgenommenen und qualitätsgeprüften Ergebnissen. Im einen Fall bin ich vorgangsorientiert, im anderen ergebnisorientiert.
Was macht das für einen Unterschied? Einen riesigen! Wenn ich das Projekt als reine Lieferaufgabe betrachte, komme ich mit drei Parametern hin: Zeiten, Kosten, Qualität (Ziele). Damit bin ich in der Welt des amerikanischen Projektmanagements, bei MS-Project und dem berühmten „magischen Dreieck“. Wenn ich das Projekt hingegen als Kunden-Lieferanten-Beziehung auffasse, gibt es mehr Parameter: Umfang, Nutzen, Risiken, Nachhaltigkeit. Sechs, sieben Steuerungsgrößen statt drei. Und das ist kein Zierat: Genau diese zusätzlichen Größen entscheiden darüber, ob ein Projekt überhaupt sinnvoll ist. Ein Vorhaben kann pünktlich, im Budget und in tadelloser Qualität abgeschlossen werden – und trotzdem ein Fehlschlag sein, weil der erwartete Nutzen ausbleibt oder die Risiken den Ertrag auffressen. Wer nur auf Zeit, Kosten und Qualität schaut, kann diesen Misserfolg gar nicht erkennen, geschweige denn steuern.
Daraus folgt unmittelbar die entscheidende Frage der Verantwortung. Im ersten Fall ist der Projektmanager für die Lieferung verantwortlich, im zweiten der Lenkungsausschuss für das Projekt. Das ist mehr als eine Formalie. Der Projektmanager kann liefern, was bestellt wurde – über die Frage, ob das Bestellte noch das Richtige ist, kann er gar nicht entscheiden. Diese Entscheidung gehört auf die Ebene derer, die den Business Case verantworten. Ein Projekt, das seinen Nutzen verloren hat, sollte abgebrochen werden – und das ist eine Management-, keine Projektmanager-Entscheidung.
Für die Praxis hat das handfeste Konsequenzen. Vorgangsorientierte Organisationen messen Fortschritt in abgearbeiteten Tätigkeiten und geraten leicht in die Falle, „beschäftigt“ mit „erfolgreich“ zu verwechseln. Ergebnisorientierte Organisationen messen Fortschritt an abgenommenen Produkten und halten den Geschäftszweck als Maßstab dauerhaft präsent. Sie planen anders, sie berichten anders, sie treffen Abbruch- und Fortführungsentscheidungen bewusster. Und sie verteilen Verantwortung dort, wo sie hingehört: Lieferung beim Projektmanager, Geschäftszweck beim Auftraggeber.
Das unterscheidet modernes (Kunden-Lieferanten-Beziehung) vom traditionellen (Projekt als Lieferaufgabe) Projektmanagement. Die vermeintlich akademische Definitionsfrage entscheidet also ganz praktisch darüber, ob Sie ein Projekt managen – oder nur abarbeiten.
Hervorragende Skills des Trainers, fundierte Beantwortung aller Fragen rund ums Projektbusiness machen Fachmethoden und Praxiskenntnisse des Trainers deutlich. Meine Erwartungen wurden übererfüllt!
Markus Fäth, Deutsche Telekom