Ist eine explizite Top-Management-Unterstützung wirklich zwingend notwendig, um agiles IT-Projektmanagement in Großunter-nehmen zu etablieren? In manchen Fällen haben Projektleiter genügend Handlungsspielraum, um agile Strukturen in ihren nach außen hin klassisch gemanagten Projekten einzuführen - auch ohne explizite Zustimmung des Top-Managements. Damit können sie einen Prozess starten, an dessen Ende mitunter die komplette Umwandlung der Organisation steht: Klassische Hierarchien und Konzernstrukturen werden aufgebrochen und durch eine Organisation mit größerer Kundennähe, flexiblem Anforderungsmanagement und besserem Überblick über Projektfinanzen ersetzt.

In der Praxis kommt der Wunsch nach einer neuen Vorgehensweise meist aus den Projekten selbst, ausgelöst etwa durch einen Alltag voll aufreibender Diskussionen mit dem externen Auftraggeber darüber, was noch zum Projektumfang gehört und was nicht. Anstöße ergeben sich auch aus Konflikten über Änderungsbudgets, bei deren Schätzung Projektleiter und Klient naturgemäß häufig auseinanderliegen. Darüber hinaus gehören Mitarbeitereng-pässe bei gleichzeitigem Termindruck in etlichen Firmen und Projekten zum Alltag.

Die agile Methode scheint da vielen ein Ausweg, unter anderem dadurch, dass sich die Planung an der tatsächlichen Leistungsfähigkeit der Teams orientiert. Die kurzen Entwicklungszeiträume von meist zwei bis vier Wochen geben den Auftraggebern die Möglichkeit, Prioritäten und Anforderungen in schnellem Rhythmus zu korrigieren, so dass Änderungsbudgets der Vergangenheit angehören. Zudem können die regelmäßigen Kundenrückmeldungen wichtige Impulse für die weitere Entwicklungsarbeit geben.

Das Beste aus zwei Welten

Verfügen Projektleiter über ausreichende Kompetenzen, sind sie in der Lage, eine agile Arbeitsweise in ihren Projekten einzuführen und gleichzeitig noch "klassisch" an das Management zu berichten. Das ist vor allem dann interessant, wenn im Management Skepsis gegenüber Scrum oder Kanban herrscht. In diesem Fall kann es für Projektleiter ein vielversprechender Weg sein, eine grundsätzliche Genehmigung beziehungsweise Duldung des Managements einzuholen und auch dann zu starten, wenn keine wirkliche Unterstützung durch die Organisation zu erwarten ist.

Praxisbeispiel: In einem Projekt zur Entwicklung einer Web-Applikation nach Kanban übernimmt der Projektleiter die Rolle des Product Owners und Kanban-Verantwortlichen. Wie vorher in der klassischen Struktur nimmt er als Projektleiter an Sitzungen des Lenkungsausschusses teil und berichtet direkt an das Management. Auf Basis der Informationen zur Anzahl der durchschnittlich erledigten Aufgaben kann er dort wie im klassisch geführten Projekt explizite Angaben zum Projektfortschritt und der geplanten Fertigstellung machen - im Idealfall sogar genauere als früher. Der Begriff "Kanban" muss dabei nicht unbedingt fallen.

Falls die agilen Methoden im Projektverlauf überzeugen - zum Beispiel dadurch, dass Projektbudgets nun effektiver eingesetzt werden und die Kundenrückmeldungen positiv ausfallen - ist es wahrscheinlich, dass Mitarbeiter anderer Projekte im Unternehmen darauf aufmerksam werden und früher oder später ebenfalls den Einsatz von Scrum oder Kanban verlangen. Auf diese Weise kann sich die neue Methode in der Organisation verbreiten.

"Leise" Einführung agiler Methoden

Allerdings gibt es eine Reihe von Voraussetzungen dafür, dass die auf diese Art eingeführten agilen Methoden tatsächlich den gewünschten Erfolg bringen: Zum einen sollte vorher überprüft werden, ob agile Methoden überhaupt vielversprechend für das Projekt sind. Sind etwa die Projektanforderungen schon genauestens definiert und nicht viele Änderungen zu erwarten, bietet sich ein klassischer Projektmanagementansatz an. Auch in Fällen, in denen das Projektziel überwiegend durch einfache und sich wiederholende Arbeitsschritte zu erreichen ist (Beispiel: Digitalisierung eines Aktenbestandes), sollte von agilen Methoden Abstand genommen werden.

Zum anderen muss die Projektleiterin oder der Projektleiter wirklich überzeugt von der einzusetzenden agilen Methode sein und genügend Handlungsspielraum haben, um neue Strukturen im Projekt einzuführen. Das schließt insbesondere die Hoheit über Budget und Personaleinsatz ein.