Artikel

Veröffentlichte Artikel und interessante Anwendungsfälle

Transparenz in Projekten: Blicken Sie hinter die Zahlen!

 „Wer freitags einen SPI unter 90 reportet, ist doch selber Schuld“. Diese Aussage stammt von einem Projektleiter und ist keine Seltenheit. Und sie zeigt, was alle wissen und dennoch nicht wahrhaben wollen: Zahlen sind eine notwendige Bedingung für Projektsteuerung, aber bei weitem keine hinreichende. Die realistische Einschätzung von erwartbarem menschlichen Verhalten macht ein Projekt erst wirklich transparent.

Große internationale Projekte sind ein perfektes Spielfeld für Gruppendynamik. Projektsponsor und Projektleiter stehen in einem komplexen Gefüge aus Interessen – den eigenen, denen der Stakeholder und denen des Unternehmens. Beide wollen das Projekt zum Erfolg führen, müssen sich nach oben absichern und nach unten den möglichst reibungslosen Ablauf sicherstellen. Entsprechend groß ist die Nervosität und entsprechend groß der Wunsch nach Sicherheit. Gute Projektzahlen dienen kurzfristig Projektsponsor und Projektleiter. So ist die Verlockung enorm, unbewusst Handlungsspielräume zu nutzen und Kennzahlen schönzuschreiben – die Sofortbelohnung ist sichergestellt. Spätestens seit dem Marshmallow-Experiment wissen wir, wie deutlich unsere Kurzzeitorientierung unser Verhalten steuert.

Daran ändert auch die Forderung nach noch mehr Zahlenwerk und Controlling wenig: Risikomanagement, detailliertere Planung, Fortschrittstracking, MTA, kurze Planungszyklen beherrschen die Beteiligten längst. Die Zahl der Problemprojekte ist dennoch nicht kleiner geworden.

Echte Transparenz kann entstehen, wenn mindestens folgende Maßnahmen hinzukommen:

1. Akzeptieren, dass menschliches Verhalten immer auftritt, egal wie ehrenhaft und bemüht alle Beteiligten sind
Es gibt in IT-Projekten selten einen wirklich objektiven, messbaren Maßstab für das Erreichte, den Fertigstellungsgrad. In allen Werten steckt jede Menge Subjektivität, die noch dazu über viele verschiedene Schätzer kumuliert wird. D.h. es gibt eine große Bandbreite möglicher Projektstati, von denen jeder subjektiv „wahr“ ist. Sie repräsentieren nicht nur unterschiedliche Infomationsstände, sondern auch unterschiedliche innere Einstellungen zu Risiken und Veränderungen. Dies zu interpretieren und zu gewichten verlangt vom Projektmanager ein hohes Maß an Empathie und Urteilsvermögen. Nur in regelmäßiger, intensiver Kommunikation mit seinen Teammitgliedern kann er deren individuelle Risikoneigung kennenlernen und so die „alles wird gut“-Typen von den „alles ist immer ganz fuchtbar“-Charakteren unterscheiden. Durch individuelle Zu- und Abschläge entsteht eine gewichtete Gesamteinschätzung, in der der erfahrene Projektleiter seinen intuitiven Durchschnitt bildet. Wenn der größte Pessimist im Team sagt: „unter günstigsten Voraussetzungen könnte es eventuell sein, dass wir doch noch fertig werden“ – ja dann ist das Projekt auf einem guten Weg.

2. Basisannahmen müssen systematisch überprüft werden, egal wie stark das Projekt in der Krise ist und die Zeit drängt
Fehler werden sehr häufig am Anfang gemacht, und es wird nicht besser, indem man eine initiale Fehlentscheidung durch weitere Fehler zu kaschieren versucht. All dem können objektiv falsche, zum Planungszeitpunkt nicht als solche erkennbare, Annahmen zugrundeliegen. Häufiger wird aber einfach zu optimistisch geplant um ein Projekt besser verkaufen zu können.
Daher ist es für tief in der Krise steckende Projekte plausibel, von grundlegenden Fehlannahmen im Setup erst einmal auszugehen. Diese müssen identifiziert, offengelegt und bekannt gemacht werden, auch wenn das weh tut und sich jemand auf den Schlips getreten fühlt.

3. Wirksame Gegenstromverfahren müssen ein Projekt verproben
Kommt man auf zwei unterschiedlichen Wegen zu einem ähnlichen Ergebnis, erhöht das seine Plausibilität ungemein. Führen Top-Down-Planung durch das Management und Bottom-Up-Schätzung des Projektteams zu zumindest ähnlichen Zeit- und Kostengrößen, sind die Werte relativ valide und liefern eine solide Basis, auf der ein starkes Committment erwartet werden kann. Führen sie zu gravierenden Abweichungen, liefert ihre Analyse und Diskussion wertvolle Hinweise über möglicherweise implizit verwendete Annahmen und schafft zusätzliche Transparenz.

4. Dezentrales Wissen muss früh verfügbar sein
Team-Mitglieder haben üblicherweise ein feines Gespür dafür, wo sie in ihrem Projekt stehen und welche „Knackpunkte“ es gibt. Mögen das auch nur partielle Ansichten und Beurteilungen sein, so sind sie doch meistens inhaltlich begründet und oft gibt es bereits auch Lösungsideen. Dafür muss vielleicht an Schrauben gedreht werden, die für die Teammitglieder nicht erreichbar sind (oder zu sein scheinen), aber es gibt sie. Dieses dezentrale Basiswissen kann aktiviert werden und die Chance erhalten, gehört zu werden. Der berühmte informelle Plausch am Kaffeeautomaten, die –vielleicht sogar überraschende- Teilnahme an Standups und Team-Meetings oder ein schönes Abendessen mit dem Team aktivieren abseits der offiziellen Meeting- und Statusagenda einen Informationsschatz, der oft verborgen bleibt.

5. Projektleiter müssen auf die richtige Weise involviert sein
Es gibt zwei extreme Positionen zu den Anforderungen an einen guten Projektleiter. Auf der einen Seite steht ein technokratischer Ansatz, der die Rolle des Projektleiters auf intime Kenntnis des jeweiligen Vorgehensmodells und seiner obligatorischen Ergebnistypen reduziert und von ihm in erster Linie eine saubere Durchorganisation des Projektkörpers erwartet. Für das Inhaltliche sind Spezialisten verantwortlich. Am anderen Ende der Skala steht der beste Fachexperten für ein Thema, der zum Projektleiter ernannt wird, ohne über Projektmanagementkenntnisse und -erfahrungen zu verfügen. „Das lernt er/sie dann schon on the job“. In beiden extremen Ausprägungen sind Schwierigkeiten vorprogrammiert. Ein guter Projektleiter bringt ein ausgewogenes Portfolio mit und ist bereit, sich in neue Business-Prozesse soweit hinein zu denken, dass er zu eigenen, fundierten Urteilen über Relevanz und Kritikalität des Scopes in seinem Projekt gelangen kann. Nicht nur die Akzeptanz des Auftraggebers auf der Business-Seite, sondern auch sein Standing im Team hängen davon ab, dass er inhaltlich im Bilde ist und die Tragweite fachlicher Entscheidungen beurteilen kann.

Wie sich zeigt: Zahlen sind wichtig, aber als alleinige Grundlage für Transparenz ungeeignet. Der Faktor Mensch liefert nötige Zusatzinformationen, wenn er nicht nur aus dem Bauch heraus erfasst wird – sondern systematisch und strukturell Teil des Projektmanagements wird.

 

Project Turnaround eines agilen IT-Großprojekts

Erstes Release verschoben, Team verunsichert, Ampeln rot, Budgetnachforderung

Ein agiles IT-Großprojekt zur Weiterentwicklung eines Rechnergestützten Betriebsleitsystems (RBL) blieb bereits sechs Monate nach Start weit hinter Plan zurück – trotz 18-monatiger Anforderungsspezifikation und Proof-of-Concept, externer Projektleitung durch eine namhafte Beratung und viel zugekaufter Expertise in Form von Scrum-Coaches und Spezialisten. Der Projekterfolg war geschäftskritisch, denn der überwiegende Teil der rund 200 Anforderungen wurde von der Fachseite als entscheidend für Erfolgschancen in den bevorstehenden Ausschreibungen großer Teile des Stammgeschäfts gesehen. Nach Eskalation der Situation im Lenkungskreis war das Vertrauen des CIOs in die Projektleitung gestört. Ein Scheitern des Projektes hieße eine Bedrohung großer Teile von Umsatz und Arbeitsplätzen und damit letztlich auch seiner Reputation und Karriere. Wie konnte der CIO die Schieflage eingestehen, ohne selbst in der Kritik zu stehen, und gleichzeitig ein objektives Bild der Situation erhalten?

 

Pter Linnebach

Der CIO als Krisenmanager: Beauftragung eines Projekt Reviews
Unter dem Banner „Qualitätssicherung“ konnte Transparenz über Potentialquellen im Projekt geschaffen werden, ohne Personenkritik üben zu müssen. Stakeholder und Projektbeteiligte wurden offen in die Problemsuche und Lösungsidentifikation eingebunden. So entstand die Lösung aus dem Projekt heraus und wurde nicht durch eine interne Revision „aufgezwungen“.

„Durch die rechtzeitige, proaktive Beauftragung des Projekt Reviews kam unser Kunde einer von oben angeordneten Revision zuvor. Dies wurde vom Vorstand als gutes Krisenmanagement gewertet, die Schieflage wurde dem CIO zu keiner Zeit angelastet. Durch seine aktive Beteiligung saß er weiter im „Driver‘s Seat“ und konnte die Geschicke des Projekts aktiv beeinflussen. Im Rahmen einer internen Revision im Auftrag des Konzernvorstands wäre das anders gewesen: Dort hätte man auch ihn ‚reviewt‘ “. Peter Linnebach, Senior Consultant CORIVUS.

 

Schnell handlungsfähig werden und nicht „gutem Geld schlechtes hinterherwerfen“Prffelder CAG Projekt Review

Ein dreiköpfiges Team konnte auf Basis des CORIVUS-Ansatzes (Abb.1) binnen vier Wochen

ein transparentes Bild über Defizite und notwendige Maßnahmen schaffen.

 

Primäre Defizite:

1. Auffallend geringe und heterogene Entwicklungsproduktivität (Benchmark)

2. Ineffiziente Vertrags- und Verantwortlichkeitsstrukturen

3.  Invalide Projektausgangsschätzung und damit unrealistischer Projektauftrag

 

 

Turnaround durch „Good Practices“ im Projekt-management und stringentes Scope Management

CORIVUS übernahm die Projektleitung und setzte notwendige Maßnahmen in den Prüffeldern (Abb.1) um. Als besondere Herausforderung musste ein realistisches Zielbild „fit-to-budget“ mit den Stakeholdern erarbeitet werden. Jede Anforderung wurde auf ihren Business-Nutzen überprüft und gefiltert durch ein Scope Management in das neue Zielbild aufgenommen.

Vergleich korrigierter Plan und neues Zielbild:

 

Vergleich Projekt Parameter

 

 

 

 

 

Fazit:

Das realistische Zielbild schuf neues Vertrauen in den Erfolg des Projekts. Durch die Maßnahmen konnte Scrum endlich wirken und die Entwicklungsproduktivität erreichte das zu erwartende Niveau. Die Anforderungen aus den Ausschreibungen werden heute erfüllt. Der CIO profilierte sich als Krisenmanager und kam der internen Revision zuvor.

Log in