Ein in der Projektmanagement-Literatur verbreiteter Hinweis ist: „Don’t put people to late projects.“ Das heißt so viel wie: Wenn zum Ende eines Projekts auffällt, dass die Zeit zu knapp ist für den eigentlich noch umzusetzenden Umfang, dann bringt es in der Regel nichts, kurzfristig noch andere Personen in das Team zu stecken.
Diese Maßnahme wird zwar von Projektmanagern immer wieder ergriffen – vielleicht um ein ruhigeres Gewissen zu haben (weil man ja noch etwas unternommen hat) – löst aber auch meiner Erfahrung nach nicht das Problem. Ich habe noch kein Team erlebt, das nach einer solchen zu spät ergriffenen Maßnahme den geforderten Umfang geschafft hat.
Kurze Projekt sind späte Projekte
Abhängig von der Projektgröße gibt es zudem die Herausforderung, dass kurzfristige Projekte schon zu Beginn „späte Projekte“ sind und man eigentlich auf personeller Ebene schon zu Beginn keine Möglichkeit hat, Maßnahmen zu ergreifen, um das meistens zu kurz gesteckte Ziel vielleicht doch zu erreichen. Ein Problem dabei ist nämlich, dass neu zusammengestellte Teams immer eine gewisse Zeit brauchen, um sich zu finden und nach den Phasen „1. Forming“ und „2. Storming“ mal mindestens in die „Norming“ oder gar die „Performing“ Phase zu kommen. Deswegen gehe ich einen Schritt weiter wenn ich sage: Don’t put people to projects. Put projects to people.
Beste Ergebnisse
Die besten Ergebnisse liefert ein Team in der „Performing“-Phase, insofern ist das Beste, was man machen kann um effizient und effektiv Projekte oder Produkte zu entwickeln, auf gestandene und gebildete Teams zurück zu greifen. Es ist also nicht (nur) eine Frage des Personalmanagements, sondern auch der Projektorganisation, die Rahmenbedingungen für eine gute Softwareentwicklung zu schaffen.
Teamwork statt neues Spezialistenteam
Häufig habe ich es erlebt, dass man der Ansicht war, es sei besonders gut, abhängig von den technischen Rahmenparametern eines Projekts Spezialisten innerhalb oder außerhalb des Unternehmens zu finden, um mit geballter Spezialisten-Power Ergebnisse möglichst schnell liefern zu können. Bessere Erfahrungen habe ich damit gemacht, wenn man Projekte bestehenden Teams zugewiesen hat, auch wenn hier nicht die ganze technische Expertise vorhanden war (Mehr dazu auch in meinem Blogbeitrag “Experte oder nicht Experte, das ist hier die Frage“). Ein Team in der „Norming-“ oder „Performing-Phase“ wird komplexe Anforderungen einer Softwareentwicklung schneller und besser umsetzen, als ein Spezialisten-Team in der ersten „Forming-Phase“.
Projekte statt Teams zerteilen
Wenn ein „crossfunktionales“ Team nicht ausreicht, um alle Anforderungen umzusetzen und Spezialisten aus anderen Teams oder anderen Unternehmen benötigt werden, dann kann man auch das Projekt zerteilen und einzelne Teile konstanten Teams zuweisen oder von Spezialisten außerhalb des Teams zuliefern lassen. Meiner Erfahrung nach sollte es in der Regel für eine möglichst effiziente und effektive Softwareentwicklung das oberste Ziel sein, ein funktionierendes Team als Ganzes einzusetzen und nicht für jedes Projekt neu Teams zusammenzustellen.
In seinem Artikel „Projects Are Not The Problem“ beschreibt Autor Mike Cottmeyer eine ähnliche Situation.
(Das Bild ist von Scott Adams – Vielen Dank!)