Projektplanung als anti-proportionale Funktion

Projektplanung

[ich bin bei dieser Aufgabe aus dem Thema anti-proportionale Kurven zugegeben etwas „quellenschwach“: Soweit ich weiß, ist sie aus einem Schulbuch aus Nordrhein-Westfalen für die 8. Klasse. Ich habe es als Scan unter Kollegen kennengelernt (man kann sich die Begleitkommentare vorstellen), und [Update 2017] meine Validierungsversuche haben mich damals zu einem inzwischen gelöschten Hilferuf in einem Schülerforum geführt. Die Aufgabe scheint es also tatsächlich gegeben zu haben]

Eine Aufgabe, für die Sie von vielen SchülerInnen der achten Klasse wohl schneller eine Antwort bekommen als von jedem Mitarbeiter der ViaMira.

Ja – diese Aufgabe im Jahr 37 nach Brooks (The Mythical Man-Month) ! (Aber: in der Schule wurde mir ja auch das Bohrsche Atommodell von 1913 als gültig nahe gebracht, obwohl man es ab 1925 schon besser wusste, und nur ganz böse Kollegen erklären das mit meinem Alter …)

Ich verzichte hier mal auf jegliches verallgemeinernde Manager-Bashing und passende Manager-Witze, denn ich habe in meinem Berufsleben beides kennengelernt: Sowohl die desinteressierten und uninformierten Delegierer, die direkt dem Dilbert-Comic entsprungen zu sein scheinen, nur der Haarschnitt passte nicht, als auch gewissenhafte Lenker, die aus externen Gründen genau vor solchen extern verursachten Herausforderungen standen und in längeren Diskussions- und Planungsphasen versuchten, das beste Ergebnis zu erzielen.

Hier soll auch nicht Brooks nacherzählt werden (obwohl ich es jedem nur empfehlen kann, sich regelmäßig eines der hochqualitativen Bücher unserer Zunft als Weiterbildung oder Auffrischung auf den Nachttisch zu legen), eher nur zwei der vielen Gedanken, die mir nach dem ersten Lachen durch den Kopf gingen:

Erstens: Sind wir uns sicher, dass wir wirklich eine Idee haben, wie die Kurve in der Realität aussieht? Natürlich wissen wir (okay – die meisten :-)), dass es keine bessere Möglichkeit gibt, ein Team zum Stillstand zu bringen, als es zu verdoppeln. Andererseits ist es immer zumindest einen abwägenden Gedanken wert, einen hochqualifizierten Kollegen zusätzlich einzuphasen, wenn die aktuelle Prognose sagt, dass am Tag des Meilensteines noch so viel Projekt über sein wird.

Qualitativ scheinen hier schnell die zusätzlichen Parameter durch, z.B.

  • Verbleibende Zeit, um einen nennenswerten Pay-Off der Einarbeitung zu erzielen
  • Vorhandenes Wissen über Fachlichkeit, Tool-Umgebung und eingesetzte Methodik beim zusätzlichen Mitarbeiter
  • optimale Teamgröße und maximale Teamgröße bis zum Split
  • Separierbarkeit der Aufgaben

aber diese qualitativen Diskussionen sind schnell eher akademischer Natur. Wer hat es schon einmal erlebt, dass sie vom Projektmanagement quantitativ analysiert wurden, BEVOR aufgrund eines verpassten / verschobenen Meilensteins die Antwort binnen 24 Stunden „nach oben“ gegeben werden muss? Vielleicht ein Anstoß zu proaktivem Risiko-Management, das mehr macht als Excel-Ampeln bunt einzufärben.

Auch wenn die armen Kollegen, die dann später die häufig unsinnigen Entscheidungen ausbaden müssen, es nicht immer wahrhaben wollen: Auch ich habe schon häufiger die Erfahrungen gemacht, dass eine Umplanung nun einmal zwingend notwendig ist. Dann ist es hilfreich, schon mal die ersten, besseren Gedanken in der Schublade zu haben als ein einfaches „wir verdoppeln das Team“.

Zweitens (und jetzt wird es wirklich für manche provokativ und teilweise schmerzhaft): ich habe schon länger das Gefühl, dass die „anonymen“ Schätzverfahren mehr Unsicherheit einbringen als alles diskutierte Unwissen über die benötigte Fachlichkeit.

Wie lange brauchen Sie von Duisburg nach Frankfurt?

  • 1,5 h? (mit dem ICE)
  • 2,5 h? (mit dem Auto)
  • 1 – 2 Tage (mit dem Fahrrad)

Wieso soll die Frage nicht fair sein? Ich bin überzeugt, bei Development-Kollegen innerhalb einer Firma schon einen Produktivitäts-Faktor von 10 erlebt zu haben (vgl. Brooks), und das ist auch nicht unterschiedlicher als ICE gegen Fahrrad. Zugegeben wirkt sich dieser Unterschied fast noch mehr in der Anzahl Bugs und im Bug-Fix-Aufwand aus, also in der Testphase und danach.

Das Hoffen auf eine durchschnittliche Produktivität hilft hier auch nicht weiter: Ich habe kürzlich das schöne Beispiel gelesen, wie sich der Durchschnitt aller Insassen eines Bus verändert a) im Körpergewicht, wenn der schwerste Mensch Deutschlands zusteigt und b) im Vermögen, wenn der reichste Mensch Deutschlands zusteigt. Wenn Sie es mal im Kopf überschlagen, werden sie sehen, dass bei a) noch eine sinnvolle Aussage herauskommt, bei b) aber nur ein virtuelles Millionen-Vermögen, das keinerlei Aussagekraft als Durchschnitt hat.

Wie soll ein armer Projektleiter (oder ein Entwickler) den Aufwand für ein Projekt gesichert vorab schätzen („mit Blut unterschreiben“)? Es mögen alle Fakten über die Aufgabe bekannt und durchdrungen sein. Wenn aber nicht bekannt ist, ob das Verhältnis ICE- gegen Auto- gegen Fahrrad-Entwickler seinen Annahmen entspricht, oder wenn ihm sogar explizit verboten wird, hier Annahmen zu treffen, bleibt eine hohe Unsicherheit. In der Realität wird dies dann meistens durch Rescoping, Mehrarbeit etc. aufgefangen, ohne sich der eigentlichen Diskussion zu stellen.

Andersherum habe ich auch schon „Monster-Teilprojekte“ zur Überraschung vieler in time / under estimate beendet: nicht, weil ich mit einem Zauberstab geplant hätte, sondern weil das Management sich vorab um diese Teilprojekte Sorgen machte und mir deshalb wenige ICEs statt vieler Fahrräder zur Verfügung stellte. Ich habe auch nie ein Lessons-learned hierzu erlebt. In diesem wären meine Teilprojekt-Leiter-Kollegen von dem Makel befreit worden, dass sie (dann natürlich mit geringerem ICE-Anteil) over estimate abgeschlossen haben, was ja eigentlich nur natürlich war.

 

Zusammengefasst: Einen wirklich guten Projektleiter zeichnet es aus, dass er sein Team zusammenstellt, wie ich es bei der Mannschaftswahl beim Sportunterricht kannte (und damit sind wir wieder bei der Schule …): Nach und nach, den richtigen Mix, und die richtigen Spieler für die richtigen Aufgaben (im Projekt: zur richtigen Zeit). Wenn er dabei Prognosen aufstellt „wenn ich zum Zeitpunkt X den Kollegen Y für die Aufgabe Z bekomme“, idealerweise iterativ für jede Mannschaftsveränderung, wird er sein Projekt viel tiefer verstehen. Wenn er dies alleine oder mit Kollegen macht, ist dies schon ein Gewinn. Wenn sein Management dies aktiv und interessiert begleiten würde, erhielte es viel bessere, verlässlichere Planungen, aber jetzt komme ich doch zu nah an das oben angesprochene Management-Bashing …