Experience

Eine Sammlung von Erfahrungen aus der Projektarbeit

Auf dieser Seite werden in größeren zeitlichen Abständen Erfahrungen aus meiner Projekttätigkeit veröffentlicht. Natürlich können hier keine Interna aus aktuellen Projekten erzählt werden – das behalte ich mir vor, wenn ich vielleicht später im Ruhestand ein amüsantes Buch schreiben werde. Unter den nachfolgenden Überschriften finden Sie Beiträge zu den Rubriken “ Theorie und Praxis“ und zu „Rezepten“, die einfach nur angewandt werden müssen.
Die wichtigste Erfahrung jedoch vorweg:

Unabhängig von der Aufgabe und dem Umfeld kommen folgenden Eigenschaften einer herausragenden Bedeutung zu:

  • Loyalität, Ehrlichkeit, Verlässlichkeit
  • Zielstrebigkeit
  • Disziplin
  • Teamfähigkeit und Kompromissfähigkeit


“ Manche leben mit einer so erstaunlichen Routine, dass es schwerfällt zu glauben, sie lebten zum ersten Mal“ (Stanislaw Jerzy Lec)

„Der Berater kann zwar oft nichts bewirken, aber er kommt nie umsonst“ ( Graf Metternich, St Gallen Consult)

„Lernen ist wie schwimmen gegen den Strom – wer damit aufhört, wird unweigerlich abgetrieben“ (Laotse)

Administration

Der durch die notwendige Projektadministration entstehende Overhead muss in einer vernünftigen Relation verlaufen. Bei der Bestimmung der Administration muss auf die knappen Ressourcen der Projektmitarbeiter Rücksicht genommen werden. Insbesondere ist zu vermeiden, dass Doppelbelastungen entstehen (z.B. neben der Rückmeldung mit PlanView, parallel Aktivitäten in Excel erfassen, Teilnahme an „unnötigen“ Telefonkonferenzen, überdimensionierte Testberichte etc).

Hier ist die Projektleitung in Abstimmung mit allen hausinternen Gremien (z.B. Revision) gefordert, ein dosiertes Maß festzulegen. Es wird dadurch unnötiges Unzufriedenheitspotential bei den Projektmitarbeitern vermieden.

Projektampel

Es hat sich mittlerweile eingebürgert, dass sowohl Zwischen- als auch Endergebnisse von Projekten mit den drei Ampelfarben „signalisiert“ werden. Hierbei wird aus der Summe von Einzelergebnissen zu einem Arbeitspaket die zutreffende Farbe gemeldet. In den Projekten, wo ich selbst mit dieser visuellen Statusbestimmung konfrontiert wurde, musste ich in der Mehrzahl feststellen, dass die ursprünglich von der Projektbasis gemeldete Farbe definitiv abweichend von der an den Lenkungsausschuss präsentierten Farbe war. Und dies lag durchaus nicht am simplen Versehen bei der Bedienung von PowerPoint. Die im Internet kursierenden Cartoons geben – wenn auch leicht übertrieben – die Realität wider. Wird z.B. vom Teilprojekt ‚Rot‘ gemeldet, jedoch eine Tendenz zu ‚Orange‘ eingeräumt, so ist dies für den Projektleiter bereits ‚Gelb‘. Neigt der Projektleiter zur

Spielernatur und will den Lenkungsausschuss nicht verärgern, meldet er ein sattes ‚Grün‘, und spielt hierbei auf Zeit.

Trotz aller Vorteile, welche eine einfache Visualisierung von den Zuständen OK, Achtung und Stopp mit sich bringt (der Lenkungsausschuss muss keine aufwendigen Berichte lesen und persönliche Schlüsse hieraus ziehen), muss gewährleistet sein, dass die ursprünglich gewählte Farbe dem realen Zwischenstand entspricht (ähnlich einer Polaroid-Aufnahme) und dass durch die Instanzen keine farbliche Änderung erfolgen darf.

In den wenigen Fällen, wo dies gewährleistet war, wurde die Farbbestimmung durch ein externes Beratungsunternehmen, durch den QS-Beauftragten und in einem Fall durch die Projektrevision durchgeführt.

Harte und weiche Faktoren

Harte Faktoren dominieren in einem Projekt – dies dürfte unumstritten sein. Ressourcen, Meilensteine und Ergebnisse aus Entscheidungen bilden hierbei den Rahmen. Ebenfalls stellen sie die Basis für eine ex post Betrachtung eines Projektes dar: „Die Durchführung hat uns unter dem Strich x EUR gekostet, nahezu alle Meilensteine wurden entsprechend der Gesamtplanung im Zeitfenster gemeistert, die vorgegebenen Ziele konnten erfüllt und in Teilen gar übererfüllt werden!“

Nicht zu vernachlässigende Triebfedern sind aus meiner Erfahrung jedoch ganz wesentlich die weichen Faktoren. Die Summe ihrer Auswirkungen spiegeln sich im Endeffekt in den harten Faktoren wider. Sie sind nicht direkt messbar, sie sind eher nur spürbar, und werden in vielen Fällen nur zu gerne von den Entscheidern und Leitern ignoriert. Hierzu einige Beispiele:

Beispiel 1: Für ein Projekt müssen vom Fachbereich und der IT Mitarbeiter bereitgestellt werden. Oft verbergen sich hinter diesem Auswahlprozess politische Ränkespielchen, so dass sich das gesamte Team schlussendlich nicht ausschließlich aus 1 a Kandidaten zusammensetzt. Die Quoten sind dann zwar faktisch erfüllt, aber stimmt auch die Qualität?

Beispiel 2: Innerhalb der Projektorganisation ist eine Hierarchie festgelegt. Diese Hierarchie funktioniert analog der Hierarchie im operativen Betriebsablauf. Während in der Unternehmenshierarchie die Führungsqualität einer leitenden Person dominiert, ist bei einer Rolle innerhalb der Projektorganisation eher die fachliche Qualifikation ausschlaggebend. Aus diesem Grund ist die „Führung“ von Teams in manchen Fällen nicht optimal ausgeprägt. Die Auswirkungen hieraus sind selbsterklärend.

Beispiel 3: Welche Werte bzw., Charaktereinstellungen bringen die Team-Mitglieder mit? Verlässlichkeit ist hierbei die herausragende Eigenschaft, die ein Team-Mitglied einbringen sollte.

Ein Projekt bildet mit der Zeit eine eigene Sub-Unternehmenskultur. Ist dies eine von allen Mitgliedern positiv empfundene Kultur, so hat dies wiederum eine nicht zu unterschätzende positive Auswirkung auf die harten Projektfaktoren und somit auf ein positives Resultat.

Projektpsychologie

Ein erfahrener Projektleiter hat die These aufgestellt: „80% der Projektarbeit ist Psychologie!“

Ein Ausspruch, der nicht unkommentiert bleiben sollte: Man muss hierzu wissen, dass es sich bei diesem Projekt um ein Migrationsprojekt handelte, in dem zwei Gesellschaften eine neu zu realisierende, gemeinsame Anwendungsplattform nutzen sollten. Die prozentuale Größe ist sicher eine „Bauchzahl“, über die sich diskutieren lässt. Unstrittig ist jedoch, dass die Psychologie im Projekt keine unbedeutende – und damit keinesfalls zu vernachlässigende – Rolle spielt.

In diesem Projekt prallten zwei unterschiedliche Unternehmenskulturen aufeinander und fanden sich in einem Projektteam wieder. Ziel und Planung waren die eine Sache, die Umsetzung hierbei die andere. Innerhalb der gesamten Konzeptionsphase dominierten offene und verdeckte „Kleinkriege“, weil die einzelnen Gesellschaftvertreter nicht bereit waren, Eigeninteressen dem Gesamtziel unterzuordnen. Insbesondere, da immer wieder einmal getroffene Entscheidungen in Frage gestellt wurden, lief der zeitliche Rahmen zunehmend aus dem Ruder.

Durch die „Neutralität“ von externen Beratern konnte diese Entwicklung abgefangen werden, sukzessive wurden auch die Entscheidungen akzeptiert und es entstand eine „sachliche Solidarität“, sodass auch dieses Projekt schlussendlich erfolgreich umgesetzt wurde.

Die Anwendung der 80/20 Regel

Die Effizienz eins Projekts ist häufig sehr stark von der strikten Beachtung der 80/20 Regel bestimmt. In der Praxis wird diese Regel auch als „Perfektionskurve“ bezeichnet:

Hierbei beinhaltet die X-Achse die Projektkosten und die Y-Achse den Nutzen. Der vom Nullpunkt ausgehende Graph steigt zunächst proportional steil an, krümmt sich dann stark und verläuft nahezu parallel zur X-Achse. Daraus folgt, um ein Nutzendelta von ca. 20 % zu schließen, entsteht ein ungleich höherer Aufwand, als der für die Realisierung von 80 % angefallen ist.

Das bedeutet auch, dass ca. 4/5 der 100 %-Lösung harmonisch verlaufen und für 1/5 Schlachten geschlagen werden müssen. Denn destruktive Personen werden nicht müde werden, immer wieder Ausnahmen aufzuzeigen, die durch den konzipierten Prozess nicht abgedeckt werden. Diese „Störungen“ müssen aus dem stromlinienförmigen Verlauf heraus gekapselt werden, und durch Change Request (oder Offene Punkte) separat behandelt werden.

Es versteht sich von selbst, dass aufgrund von Projekten, welche durch Dritte angeordnet sind (z.B. Änderungen im rechtlichen Datenkranz), diese Regel nicht uneingeschränkt angewendet werden kann.

Prozesse und die hierfür notwendige Systemunterstüzung

In einem Versicherungskonzern wurde die prozesstechnische Verantwortung für eine nichtversicherungstechnische Funktion neu festgelegt. Es wurde zunächst eine Service Gesellschaft gegründet, welche die bisher in den einzelnen Konzerngesellschaften dezentral angesiedelten Funktionen am Standort der Holding zentral bündeln sollte. Hierfür wurden die notwendigen aufbauorganisatorischen Maßnahmen konsequent vorangetrieben: Bestimmung der Linienvorgesetzten und Besetzung der Planstellen. Letzteres gestaltete sich – nicht zuletzt aufgrund der örtlich weit auseinanderliegenden Standorte – als größeres Problem, so dass vorübergehend auch eine verbleibende „Restdezentralisierung“ in Betracht gezogen wurde. Parallel zu der oben beschriebenen Gemengelage wurde ein Projekt gestartet, welches die systemtechnischen Voraussetzungen für einen operativen Betrieb am Standort der Service Gesellschaft schaffen sollte. Ergänzend muss erwähnt werden, dass die einzelnen Konzerntöchter dieselben Funktionen mit unterschiedlichen Anwendungsplattformen bis dato bearbeitet hatten. Durch VVG nF bestand allerdings unmittelbarer Handlungsbedarf: Entweder die notwendigen Anpassungen in allen Systemen umzusetzen oder die Schaffung eines neuen, einheitlichen Systems? Als weiterer erschwerender Faktor kam in diesem Projekt hinzu, dass die fachlichen Projektmitarbeiter nicht optimal motiviert waren, da sie sich gedanklich und faktisch mit Alternativen zu einem sonst notwendigen Ortswechsel befassten. Es ist für Außenstehende zwar schwer nachvollziehbar, aber auch solche Projekte können zu einem objektiv erfolgreichen Abschluss gebracht werden. Wie? Das bleibt das Betriebsgeheimis eines guten Beraters.

Die Kommentarfunktion ist geschlossen.