Für bessere Pläne

30.07.2006 Permalink

Ein paar Jahre ist es schon her, da durfte ich als Teilprojektleiter an dem Versuch teilnehmen, einen vollständigen, detailierten Plan für ein Projektteam von 40 Personen zu erstellen. Es war aufgeteilt in die Teilprojekte Requirements+Test, QM+Tools+Methoden, Entwicklung Client und Entwicklung Server. Der Zeithorizont reichte über ein Jahr. Es war ein irrwitziges Unterfangen.

Das Ergebnis war ein sehr feingranularer, optisch beeindruckend wirkender Projektplan mit Arbeitspaketen, Plan-Aufwänden, Abhängigkeiten, Meilensteinen und Mitarbeiterzuordnung. Der Plan hielt ungefähr zwei Wochen, dann war das mühsam errichtete Werk schon sturmreif. Die Realität kann ja so genadenlos sein, wenn man sich ihr plump zu nähern versucht. Ein gern gewählter Spruch von Skeptikern für diese Gelegenheit ist: Planung ist der Versuch, die Unwissenheit durch den Irrtum zu ersetzen.

Der im obigen Spruch anklingende totale Zweifel am Sinn einer Planung ist jedoch nicht gerechtfertigt. Ich setze mal dagegen: ein Plan ist eine vernünftige Hypothese, wie die Arbeit erledigt werden soll. Können wir ihm nicht folgen, so signalisiert das ein Problem, denn unsere Hypothese ist offensichtlich nicht zutreffend. Wir müssen den Kurs ändern.

Heute weiss ich im übrigen aus praktischer Erfahrung, dass sich operativ einsetzbare Pläne erstellen und pflegen lassen, ohne ein riesiges Project-Office damit zu beschäftigen. Sie geben große Sicherheit für Berichte und sind das wirksamste Mittel einer Projektsteuerung. Es lohnt sich, wenn man es richtig anpackt.

Was ist also damals schief gelaufen?

Size does matter. Der Brocken war für einen einzigen Plan zu groß. Vernünftigerweise erhält jedes Teilprojekt seinen eigenen Plan. Die Kopplung entsteht über Meilensteine, die gemeinsam abgestimmt und festgehalten werden und in allen beteiligten Teilprojektplänen auftauchen.
Apropos Kopplung: so wie zwischen Software-Komponenten löst ein hoher Grad an Kopplung auch in Organisationen (und mithin in Plänen) keine Freude aus. Viele Abhängigkeiten zwischen Teilprojekten sind ein Warnsignal für eine schlechte Verteilung von Aufgaben.
Auch war die Zeitstrecke zu lang. Einem detaillierten Plan, der einen Zeitraum von mehr als vier Monaten abdeckt, traue ich allein deshalb nicht, weil das Projekt dafür sehr viele Informationen parat haben muss. Selten ist genaues Wissen in großer Menge verfügbar, viel wahrscheinlicher ist dann viel Halbwissen, womit die Planqualität fraglich wird.
Im Bereich der Entwicklung entstand der Plan nicht auf Basis eines Grob-Designs, sondern mehr durch Aneinanderreihung von bekannten Features. Dieser Ansatz führt nicht zu einem brauchbaren Plan.
Der Plan wurde nicht konsequent und regelmässig an die Mitarbeiter kommuniziert, das Wissen um Meilensteine reicht auf der Arbeitsebene nicht. Auch hier hilft Automatisierung, z.B. durch tägliche Generierung von Auszügen, die jeder Mitarbeiter einsehen kann.
Die Aufwandsschätzungen für Arbeitspakete waren nicht seriös.
Die Rückkopplung zwischen Plan- und Ist-Aufwänden, das regelmässige Erfassen von Restschätzungen und die erforderlichen Korrekturen wurden wegen hohen manuellen Aufwands unterlassen. Ohne Automatisierung für solche Aufgaben ist ein Plan nicht beherrschbar.

Und was sind die Lehren daraus?

Small is beautiful. Das verträgt sich auch wunderbar mit kurzen Release-Zyklen, die die Basis eines agilen Ansatzes sind.
Teams so entkoppeln wie Software. Je Teilprojekt ein eigener Plan.
Nur planen, was man übersehen kann. Ohne fachliches Konzept und Grob-Design gibt's eben keine Basis für die Planung der Entwicklung. Was man nicht planen kann, wird durch einen einzelnen, seriös geschätzten Balken ersetzt... und beizeiten ausdetailliert.
Ein Projektplan ist ein Werkzeug für alle. Mitarbeiter sind an der Erstellung beteiligt und haben stets lesenden Zugriff auf den Plan.
Ehrlich und handwerklich sauber schätzen. Die schöne Illusion platzt sonst beim nächsten Bodycheck der wirklichen Welt.
Möglichst viele Arbeitsschritte bei der Pflege des Plans automatisieren.

Tatsächlich lassen sich so Teams steuern, die aus mehr als zehn Personen bestehen. Der Witz ist, dass durch Prüfung von akkurat erfassten Ist- und ehrlich geschätzten Restaufwänden gegen geplante Aufwände die Arbeitspakete mit Problemen herausgefiltert werden. Man wird geradezu mit der Nase auf sie gestoßen. Um den Rest muss man sich nur stichprobenartig kümmern. Das entlastet den Kopf.

Eines nimmt einem die Steuerung via Projektplan allerdings nicht ab: flächenddeckende Qualitätsprüfungen. Sonst gelingt es dem Team, in-time und -budget atemberaubend schlechte Software zu bauen...