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?

Und was sind die Lehren daraus? 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...