Kein Projekt ist eine Insel. Jedes Projekt ist eingebettet in ein Umfeld, mit dem es in Wechselwirkung steht: Das Projekt betrifft das Umfeld und das Umfeld beeinflusst das Projekt. Das temporäre System Projekt effektiv zu führen und effizient zu gestalten, die Arbeit am System, ist absolut notwendig aber bei weitem nicht hinreichend für den Projekterfolg. Dazu braucht es noch den Blick auf das Gesamtsystem, also Projekt in Wechselwirkung mit dem Umfeld. Während man als Projektmanager auf das System Projekt noch direkten Einfluss hat, entzieht sich das Umfeld dem direkten Zugriff. Damit sind wir im Bereich der Projektpolitik angekommen.
Ganz allgemein bezeichnet Politik „jegliche Art der Einflussnahme und Gestaltung sowie die Durchsetzung von Forderungen und Zielen, sei es in privaten oder öffentlichen Bereichen.“ (Quelle: Wikipedia) Projektpolitik heißt demnach: Meinungen und Stimmungen Umfeld des Projekts günstig zu beeinflussen. So wie Politiker für Vorhaben Meinungsbildung betreiben und Mehrheiten in der Bevölkerung oder im Parlament schaffen, muss das auch für jedes Projekt gemacht werden. Wer das versäumt oder vernachlässigt riskiert Widerstand und gefährdet das Vorhaben (siehe Stuttgart 21).
Nehmen wir ein konkretes Beispiel: Ein Automobilhersteller möchte eine neue Software zur Planung der Montage einführen. Einerseits weil die bestehenden Systeme veraltet sind und andererseits weil die einzelnen Werke bisher unterschiedliche Altsysteme einsetzen. Ziel ist ein einheitliches System zur Planung der Montage für alle Werke. Ein sehr sinnvolles Vorhaben aus Sicht der IT (weniger Systeme = weniger Wartungs- und Betriebsaufwand) und aus Sicht des Vorstands (einheitliche Prozesse = einheitliche Kennzahlen). In diesem neuen System die Spezifika des eigenen Montageprozesses abzubilden ist bereits nicht trivial. Natürlich ist die geeignete Gestaltung des neuen Systems kritisch für den Projekterfolg und für die Projektbeteiligten eine Herausforderung, die eigentliche Gefahr lauert aber im Umfeld. In sämtlichen Werken ändert sich nämlich mit dem neuen System der über Jahrzehnte gewohnte Prozess der Montageplanung, der ja auch jeweils seine Vorteile hatte, und die Werke werden in ihren Kennzahlen untereinander besser vergleichbar, was nicht jeder gerne sieht. Ohne entsprechende Maßnahmen der Einflußnahme auf die einzelnen Werke wird das Projekt fast sicher in schwieriges Fahrwasser kommen, egal wie perfekt das neue System sein mag (was es am Anfang nicht sein wird).
Ich weiss nicht, ob es besser wird, wenn es anders wird. Aber es muss anders werden, wenn es besser werden soll.
– Georg Christoph Lichtenberg
Das Beispiel zeigt ein leider bekanntes Muster: Ein scheinbar reines IT-Projekt ist in Wahrheit ein verkapptes Veränderungsprojekt. In solchen Fällen wäre es tatsächlich oft besser das Projekt auch als Veränderungsprojekt aufzusetzen mit der Systemgestaltung als Teilprojekt. Egal wie, jemand muss diesen Veränderungsanteil, der in jedem Projekt vorhanden ist, managen. Als Projektleiter bin ich jedenfalls im Rahmen des Risikomanagements dafür verantwortlich, dass es passiert und muss mir geeignete Maßnahmen der Einflußnahme und des Marketings überlegen und einfordern (u.a. vom Projektsponsor oder Auftraggeber). Der erste Schritt dafür ist aber den eigenen Horizont auf das Umfeld des Projekts zu erweitern. Insofern ist „Arbeite am System“ in Grundprinzipien des Projektmanagements als „Arbeite am Gesamtsystem (Projekt und Umfeld)“ zu verstehen.
Bildnachweis
Das Artikelbild wurde von Melissa Thereliz unter dem Titel „Reichstagsgebäude – Cúpula del Reichstag“ auf Flickr unter einer Creative Commons Lizenz (CC BY-SA 2.0) veröffentlicht (Bestimmte Rechte vorbehalten).
Jetzt erhältlich
Das Manifest für menschliche Führung wird erwachsen. Komplett überarbeitet und deutlich erweitert sind die 6 Thesen und 14 Prinzipien für eine neue Führung im Zeitalter der Digitalisierung ab 14. Februar 2024 als Hardcover in hochwertiger Leinenbindung erhältlich.
6 Kommentare
Hallo Marcus,
es gibt keine Projekte ohne Politik, ich habe es mehrfach ‑auch leidvoll – erfahren. Aber es gibt Abhilfemöglichkeiten:
1.ich behandle seit Jahren alle IT-Projekte, insbesondere die Einführung neuer SW, selbst ein neues Release, als Veränderungsprojekt.
Das schafft einen verbesserten Ansatz, denn Veränderungsprojekte haben eigene, meist schwierigere Regeln.
2. bei allen großen und wichtigen Projekten empfehle ich, immer eine Stakeholderanalyse durchzuführen. Damit wird das Umfeld des Projektes transparenter und man kann neben den Unterstützern auch die Feinde und Gegner des Projektes identifizieren. „Heimliche“, mächtige Gegner, die scheinbar das Projekt unterstützen, richten in der Regel den größten Schaden an.
Beide Ansätze sind natürlich keine Garantie für den Projekterfolg, aber die Wahrscheinlichkeit steigt.
Hallo Klaus, Deine Vorgehensweise finde ich vorbildlich und spricht für Deine langjährige Erfahrung. Leider übersehen manch junge Projektleiter diese Veränderungsanteile im scheinbar harmlosen IT-Projekt und daran scheitert dann das Projekt. Man muss ja nicht gleich ein Veränderungsprojekt daraus machen, auch wenn das manchmal sinnvoll wäre, solange man sich bewusst ist, dann man die Veränderung managen muss.
Den Ansatz, das Projekt hauptsächlich als Veränderungsprojekt aufzusetzen mit der Applikationsentwicklung als Teilprojekt finde ich sehr interessant. Die Applikationsentwicklung könnte dann Inkremente ausliefern, die den Veränderungsprozess unterstützen. Als erfahrener Projektleiter behaupte ich aber, dass kaum eine Geschäftleitung dem zustimmen wird, da so der Aufwand für die Applikationsentwicklung höher sein wird und das Change Projekt sehr stark das Tagesgeschäft negativ beeinflusst. Viel zu viele Personen sind involviert und dadurch weniger effizient. Kurzfristige Ziele können somit nicht erreicht werden. Führungskräfte, die ihre Quartals- oder Jahresziele erreichen wollen, werden hier wohl (leider) blockieren.
Da gebe ich Dir recht: leider wird auch seitens der Auftraggeber gerne übersehen, dass neben der reinen Applikationsentwicklung auch Veränderung stattfindet und gemanaged werden muss und daher der Aufwand dafür nicht gern gesehen wird. Für den Projekterfolg aber unerlässlich und ein erfahrener Projektleiter wird in diesem Punkt die Diskussion mit dem Auftraggeber frühzeitig suchen.
Hallo Marcus
Ähnliche Verhältnisse, wie Du in den Beispielen beschrieben hast, treffe ich öfters an. Ich stelle dem Auftraggeber gerne die Frage, was er eigentlich erreichen will. Um bei den Beispielen zu bleiben: IT-System-Wechsel oder zuerst einheitlicher Montageprozess unter gleichem System? Aus meiner Sicht müsste zuerst geprüft werden, ob der Montageprozess in allen Werken identisch ist. Wenn ja, ob es möglich wäre ein Alt-System in kurzer Zeit (Preisfrage) flächendeckend einzuführen. Erst dann sehe ich ein Grundlage für eine neues System. Aber ich bin kein IT-Mensch. :) Sicher kann das neue System auch zuerst an einem Standort eingeführt werden und dann via „Roll-Out“ installiert werden. Aus praktischer Erfahrung erlebe ich hier jedoch zu häufig, dass das Neusystem einfach „draufgeklatscht“ wird – ohne einheitliche Anpassung der eigentlichen Basis. Aber genau hier spielt die Projektpolitik eine sehr grosse Rolle, in welche Richtung es gehen soll/wird.
Gruss Frédéric
Hallo Frédéric,
Du hast vollkommen recht: erst muss geklärt werden, was eigentlich gewünscht wird. Im vorliegenden Beispiel, war das die Vereinheitlichung des Montageprozesses (denn der war ganz und gar nicht gleich, noch nicht mal mit Kennzahlen vergleichbar). Aber anstatt das in den Vordergrund zu stellen und sich der Diskussion darüber zu stellen, zog man es vor, das durch die Hintertür über die Einführung eines neuen Systems zu machen. Wasch mich aber mach mich nicht nass …
Grüße,
Marcus