Plötzlich Projektleiter

Kennen Sie den Film „Plötzlich Prinzessin“? Ein amerikanisches Mädchen wird durch absurden Zufall Prinzessin eines europäischen Staates – über Nacht. Eigentlich geht es im Film um die Herausforderungen des Erwachsenwerdens, und eigentlich ist dies eine Teenie-Highschool-Komödie.

Uneigentlich fühlt sich der ein oder andere Informatiker oder Ingenieur aber ziemlich genau so: das Projekt ist wichtig für die Firma (nicht das imaginäre europäische Land, aber immerhin), böse Kräfte (Termine und zugesagte Eigenschaften) bedrohen die Harmonie, plötzlich muss man gesellschaftliche Ereignisse wahrnehmen wie Geschäftsessen in italienischen Restaurants, wo es nicht einmal Pizza gibt.

Meist passiert dies in den „goldenen Zeiten“: viele Projekte, viel Umsatz, kaum verfügbare Leute mit Erfahrung – alle anderen Optionen scheiden für den Chef aus. Denn wer ein guter Software-Entwickler, Architekt oder Tester ist: der ist ja auch ein guter Projektleiter! Dies nennt man in der PM-Literatur übrigens den „Halo-Effekt“ und meint den „Heiligenschein“-Effekt: wenn jemand viel geleistet hat, trauen wildfremde Menschen ihm plötzlich alles zu. 

Wie überlebt man die an sich ja erfreuliche Beförderung? Da hilft ein Tipp aus einem anderen Film, Highlander: „Verlier’ nicht Deinen Kopf, Highlander!“ Im Film ist der Tipp mehrdeutig – Highlander sind unsterblich, es sei denn, ihr Kopf ist weg. Wenn Sie frisch gebackener Projektleiter sind, heißt dies: verlieren Sie vor allem nicht die Übersicht! 

Wo fängt man an? Wie fängt man an? Das ist natürlich in jeder Situation unterschiedlich... Aber: Einarbeiten ist notwendig – haben Sie als Entwickler auch gemacht, als Sie das erste Mal für einen JBoss Application Server entwickelt haben! Nehmen Sie sich die Zeit und verlangen Sie diese auch! Niemand kann von jetzt auf gleich produktiv sein, bei Politikern gesteht man in neuen Ämtern nach Wahlen sogar 100 Tage zu!

Um das Ruder übernehmen zu können, müssen Sie den Standort bestimmen: welche Themen sind relevant? Welchen Zustand hat das Projekt gerade? Wo müssen Sie mehr Aufwand reinstecken und was kann warten? Ich habe Projektleiter erlebt, die sich mit den Risiken des Projektes nicht beschäftigen wollten, weil man Risikomanagement ja sowieso implizit dauernd macht  – logisch! Dafür wurden unrealistische Termine als unveränderbar verkauft...

Hier ein einfacher Vorschlag für eine Übersicht: die neun Bereiche stammen aus dem ANSI-Standard für Projektmanagement, dem so genannten PMBoK (Project Management Body of Knowledge®, Marke und Copyright des Project Management Institute):

Scope: Was?

Was bauen Sie da überhaupt? Und wo ist die Grenze, welche goldenen Wasserhähne können Sie vermeiden?

Tipp: Scope mit den Stakeholdern klären... möglichst früh... auch wenn’s manchmal schwierig ist. Wenn gar nichts klar ist - weder Umfang noch Kosten - führen Sie ein Projekt-Scoping durch (dazu später mal mehr).

Time: Wann?

Wann ist die Software fertig – und wann wird sie gebraucht? Gibt es da womöglich eine Differenz?

Gibt es offensichtliche Engpässe (critical chain) in Ihrem Plan? Kann man etwas parallelisieren – verschränken – beschleunigen? Gibt es überhaupt einen Zeitplan?

Welche Zeitpuffer sind im Plan enthalten und reichen sie aus?

Cost: Was darf’s denn kosten?

Hat eigentlich schon jemand daran gedacht, dass nach Inbetriebnahme womöglich noch Pflegeaufwand benötigt wird für die ersten dramatischen Fehler?

Beinhaltet das Budget wenigstens Puffer?

Wenn Sie noch sehr früh dran sind mit dem Projekt – beinhaltet das Budget dann auch die Vorbereitungen?

Human Resources (HR): Wer?

Sie haben ein Projekt und sogar ein Team vorgefunden – aber wer sind die Leute, auf die Sie sich verlassen müssen? Welche Fähigkeiten haben die und welche fehlen ihnen?

Haben Sie Mitarbeiter – oder haben Sei ein Team?

Tipp: in größeren Organisationen unbedingt mit den Linien-Vorgesetzten absprechen – sonst müssen die Leute plötzlich im Tagesgeschäft „dringendste“ Aufgaben erledigen.

Risk: Wird es klappen?

„Ich weiß schon, was ich tue!“ – „Die Risiken habe ich auch so im Blick.“ – „Wir sind hier ja nicht im Selbstfindungsseminar?“

Was soll man da noch zu sagen? Wer seine Risiken – und Chancen – nicht rational behandelt... Oder, wie man vielleicht den Kapitän der Titanic hätte sagen hören können: „Eisberg? Welcher Eisberg?“.

Tipp: Ihr Budget muss Puffer für bekannte Risiken enthalten, das ist noch relativ naheliegend. Puffer für „unknown unknowns“ brauchen Sie auch! Oft wird dies auch als „management reserve“ gesehen, weil nur das Management das Budget dafür im Ernstfall freigeben kann.

Quality

„Gratluation! Se haben erworben BAnduhr für Arm von highste Qualitaet!“ – warum nur ähneln alle Qualitätsparolen in Projekten diesem erfundenen, aber nicht unüblichen Versprechen? Vielleicht, weil man sich meist keine Gedanken zur Messung von Qualität machen möchte?

Tipp: setzen Sie auf Automation, wo Sie nur können:

• Statische Code-Analysatoren wie Checkstyle, PMD, FindBugs, Sonar, ...
• Unit-Tests für separierte Module (ja, im Prinzip macht die immer jeder und vollständig...)
• Unit-Tests als Integrationstests für interagierende Module, also quasi direkt unter der GUI
• GUI-Tests: ok, das ist manchmal sehr aufwändig und nervig, vor allem bei Rich Clients. In Projekten habe ich schon Java-basierte Scripting Sprachen gesehen, die effektiver als teure Tools den Entwicklern eine Automatisierung erlaubten.

Communication: Mit wem reden Sie eigentlich?

Sie wissen sicher schon, dass Kommunikation mal locker 80% der Zeit des Projektmanagers beanspruchen kann. Damit Sie überhaupt noch zu irgendwas kommen, müssen Sie herausfinden: mit wem kommunizieren Sie wie über was? Also, gefragt sind mal wieder die Stakeholder:

Das PMO will jede Woche einen Bericht per e-Mail, basierend auf dem Excel-Template. Die „friendly user“ möchten einmal im Monat einen Status präsentiert bekommen.

Das Management möchte einmal im Monat von Ihnen am Kaffeeautomaten hören, dass es gut läuft...

Tipp: Identifizieren Sie die Stakeholder – gründlich und vollständig. Nicht alle erkennt man gleich!

Procurement: Wer liefert?

In Ihrem Team haben Sie einen Freelancer – wie lange ist der eigentlich noch da? Reicht das Budget für die Zeit?

Arbeitsintensiv ist auch die Steuerung von Zulieferern wie z.B. Design- und Web-Agenturen! Wann sollen die noch mal was liefern – und in welcher Qualität?

Integration: Und jetzt?

Alle Einzelteile müssen zusammenwirken: wenn Sie die absurden Kosten- und Zeit-Schätzungen Ihrer Vorgänger korrigieren (mit dem Team) und das Projekt dann länger läuft: ist dann eigentlich noch der Freelancer dabei? In welche Risiken können Sie laufen?

Tipp: gehen Sie die Integration iterativ an – dann können Sie korrigieren und optimieren!

Demnächst hier: wie Sie anhand der Bereiche sich auch „on the flight“ überprüfen können.