1000 Fehler in der Projektleitung: 20
„Haben das Ziel aus den Augen verloren, kommen aber gut voran“
Im Nachbarhaus meiner Eltern wohnte jemand, der Modellflugzeuge baute. Ich durfte als Kind einige Male mitfahren, wenn er seine Flugzeuge auf einem Feld fliegen ließ.
In ganz seltenen Momenten durfte ich auch mal die Fernsteuerung halten (vermutlich dann, wenn der Bau des Fliegers nicht länger als 5000 Stunden gedauert hat). Dabei gab es eine einfache, aber eiserne Regel: Wenn du das Flugzeug nicht mehr sehen kannst, zieh‘ es sofort runter zum landen. Ich fand das doof. Wenn der Flieger hinter einer Kuppe oder einigen Bäumen verschwand, hätte ich viel lieber das Gerät mit einer eleganten Wendung wieder in sichtweite geflogen. Aber das durfte ich nicht. Ich habe irgendwann auch verstanden, wieso: Besser, das Flugzeug landet unsanft auf dem Boden, als das man im Blindflug jemanden erschlägt oder ein parkendes Auto demoliert.
Lustigerweise wird diese Regel bei Projekten eher selten beachtet. Die Anforderungen der Fachabteilung sind voller Lücken und Widersprüche? Egal, mittels misserstandenem agilen Projektmanagement schreibt man schon mal das Pflichtenheft – und wickelt das Projekt trotz unklarer Anforderungen dann per Wasserfallmethode ab. Mit dem Ergebnis kann zwar keiner etwas anfangen, aber da muss man halt leider auf Release 2 warten.
Es ist eher unklar, ob das Projekt überhaupt Sinn macht? Na und! Der Projektplan sieht den Start vor, also halten wir uns dran. Später wird klar, dass das Projekt keinen Sinn macht. Aber weil man schon mal so weit gekommen ist, bringt man es irgendwie zuende und beerdigt es stillschweigend.
Dabei helfen auch keine agilen Methoden mehr. Agile Methoden helfen mir dabei, wenn ich ein Auto baue und die Farbe erst in letzter Minute fest steht. Oder wenn ich das Fahrwerk kurz vor Auslieferung noch mal modifiziere und was auch immer.
Es hilft mir aber herzlich wenig, wenn ich ein Auto plane und eigentlich ein Flugzeug hätte bauen sollen …
‹ Marathonvorbereitung Woche 8 Blackberry ›
…naja, abetr geht nicht bei der landung erst oft was schief?
ausserdem hab ich den eindruck, dass bei it-projekten noch viel zu sehr so getan wird, als liesse sich überhaupt irgendetwas klar und allgemeinverständlich abgrenzen. – das ist eben der vorteil von guter software: man plant gar kein auto, sondern etwas, mit dem mehrere leute mit gepäck bis zu 180 sachen fahren können. – wenn keiner dazu gesagt hat, dass den leuten drin auch warm sein soll, kanns scho passieren, dass man dan auch ohne fenster, dach und heizung unterwegs ist, nur seh ich kaum, wie man das durch projektmanagement abfangen können sollte…
> …naja, abetr geht nicht bei der landung erst oft was schief?
Ja, aber das ist das kleinere übel (Risikoabschätzung)
> man plant gar kein auto, sondern etwas, mit dem mehrere leute mit gepäck
> bis zu 180 sachen fahren können. – wenn keiner dazu gesagt hat, dass den
> leuten drin auch warm sein soll, kanns scho passieren, dass man dan auch
> ohne fenster, dach und heizung unterwegs ist,
Schönes Beispiel, muss ich mir merken.
> nur seh ich kaum, wie man das durch projektmanagement abfangen können sollte…
Das ist schon machbar. Im Bereich Anforderungsmanagement gibt es mittlerweise meiner Meinung nach genug Techniken um solche Dinge in den Griff zu bekommen. Leider wird das in vielen Projekten vernachlässigt.