Die Projektmanagement Lessons Learned heute kommen ursprünglich aus der IT, aber ich habe festgestellt, dass sie sich problemlos auch auf die meisten anderen Entwicklungsprojekte übertragen lassen. In meinen Projektteams finden sich die unterschiedlichsten Menschen, Charaktere, Pragmatiker, Nerds, Teamplayer – allesamt tolle Spezialisten in ihrem jeweiligen Fach. Wir alle haben das gleiche Ziel, nämlich unser Projekt möglichst gut und schnell abzuliefern. Aber jeder hat eine andere Geschichte, wie er dahin gekommen ist, wo er heute steht, welche Vorbilder er hatte und was er daraus für sich gezogen hat. Also hat auch jeder seinen eigenen Stil, seine Arbeit zu erledigen.
Damit muss ein Projektmanager umgehen und jeden Einzelnen mit seinen Leistungen integrieren. Und/oder die Dinge konsequent einfordern, die individuell ins Hintertreffen zu geraten drohen. Bestes Beispiel ist die bei Entwicklern allseits hohe Abneigung gegen das Dokumentieren. Entwickler wollen entwickeln, tüfteln, großartige Ergebnisse erschaffen. Der Schreibkram aber ist öde, langweilig, zeitraubend und außerdem: „Das kann man doch alles aus dem Code oder der Zeichnung ersehen !“ Seltsam dann, dass es selbst den „Erzeugern“ ohne eine klare Aufgabenstellung und Entwicklungsdokumentation meist schwerfällt, brauchbare Prüfkriterien und Testfälle zu definieren. Und das verursacht spätestens bei den Testern und Prüfingenieuren erhöhten Aufwand – zulasten des Projektbudgets.
Unabhängig davon muss der Projektmanager immer darauf achten, dass die Projektergebnisse nachvollziehbar und nachstellbar sind. Dass also andere, die später (vielleicht in einem ganz anderen Projekt) einmal wieder daran arbeiten und eventuell etwas verändern müssen, sich ohne größere Verständnisprobleme zurechtfinden und an ihre Arbeit gehen können.
Schließlich sollten ja nicht nur funktionierende Projektergebnisse, sondern auch deren langfristige Verwendbarkeit das Ziel sein.
Lesen Sie mehr Lessons Learned…