Wie schon im 10-Minuten-Artikel zum dritten Wertepaar aus dem agilen Manifest „Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung“ erwähnt, ist es aus verschiedensten Gründen sehr wichtig auf Änderungen reagieren zu können. Ich selbst habe mal bei einem Softwareprojekt mitgearbeitet, welches ursprünglich über einen Zeitraum von 5 Jahren geplant war. Aufgrund des großen Erfolgs war nach ein paar Jahren schon klar, dass die Projektlaufzeit auch noch verlängert wird. In diesem Zeitraum wird sich der Markt des Kunden, der dieses Projekt in Auftrag gegeben hat ändern. Das Projektteam hätte zu Beginn des Projekts nicht sinnvoll planen können, was genau gemacht werden muss und wie das fertige Endprodukt aussieht, weil sich über den Zeitverlauf einfach Änderungen und Wünsche ergeben werden. Wenn die Benutzer das erste mal die Software nutzen, wird sich auch erst noch herausstellen, was wirklich so funktioniert wie geplant und wo vielleicht noch optimiert werden kann.
Ein Projektplan hat grundsätzlich die Vorannahme, dass ich den gesamten Projektverlauf prognostizieren kann. Das ist in dieser komplexen Welt einfach nicht möglich. Das Wort „komplex“ ist dabei eine bewusste Abgrenzung gegenüber kompliziert im Sinne des Cynefin-Frameworks, über das ich hier im Blog auch unbedingt noch schreiben möchte. Darüber hinaus gibt es zahlreiche Untersuchungen die belegen, dass Schätzungen in Projekten einfach unglaublich schlecht sind. Mehr dazu findest du unter dem Stichwort „Cone of Uncertainty“, über den ich auch noch schreiben will.
Wenn ich also Pläne nutze, muss ich bereit sein diese fortlaufend anzupassen. Alternativ hilft es nur noch sehr kurze Zeitabschnitte zu beplanen. Dann kann ich leichter umplanen, wenn es Änderungen gibt oder einfach den Plan ganz verwerfen ohne viel verschwendet zu haben. Das ist sinngemäß z.B. der Ansatz der bei Scrum genutzt wird. Natürlich können auch Pläne im klassischen Sinne einfach über Board geworfen werden, wie es sinngemäß bei Kanban gemacht wird.
Schreibe einen Kommentar