Kommentare zu: Projektpolitik

Von: Marcus Raitner

Marcus Raitner — Mon, 09 Apr 2012 15:53:51 +0000

Als Antwort auf Frédéric Jordan. 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

Von: Frédéric Jordan

Frédéric Jordan — Mon, 09 Apr 2012 11:03:51 +0000

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

Von: Marcus Raitner

Marcus Raitner — Sat, 07 Apr 2012 18:06:19 +0000

Als Antwort auf wissensarbeiter. 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.

Von: Marcus Raitner

Marcus Raitner — Sat, 07 Apr 2012 18:03:46 +0000

Als Antwort auf Klaus-L. Schiff-Stilbauer. 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.

Von: wissensarbeiter

wissensarbeiter — Sat, 07 Apr 2012 09:46:37 +0000

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.

Von: Klaus-L. Schiff-Stilbauer

Klaus-L. Schiff-Stilbauer — Fri, 06 Apr 2012 18:01:43 +0000

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.