Wenn wir uns bei gescheiterten IT-Großprojekten ansehen, wie der Aufwand sich verteilt, entdecken wir einige Gemeinsamkeiten. Bis zu 30% Prozent das Gesamtaufwands werden in die Evaluierung von Tools und Methoden gesteckt. Da geht es vor Beginn der eigentlichen Arbeit um Fragen wie
Darüber hinaus werden für jede nur denkbare Anwendung unzählige Templates entwickelt, z.B. zur Beschreibung von Anforderungen, zur Aggregation von Anforderungen, für Statusberichte. Dokumentation darf natürlich auch nicht vergessen werden. Alles wird getan für die große Vereinheitlichung.
Diese Methodik-Erhebung mit anschließender Anpassung an das jeweilige Großprojekt kann sich schon mal auf 6 Monate erstrecken. Der beschriebene Formalismus dient natürlich der Absicherung aller Beteiligten. Wenn es schief geht, kann man sich dahinter zurückziehen, dass man formal nach “Best Practices” gearbeitet und ausführlichst Risikoprävention betrieben hat.
Damit wir uns richtig verstehen–in gewissem Maße sind Vereinheitlichung und standardisiertes Vorgehen sinnvoll. Aber muss das für jedes Großprojekt neu entwickelt werden? Muss man für den Formalismus auch noch Berater anheuern?
Erfolgreiche Großprojekte nutzen nach meiner Erfahrung mehr Bordmittel für den unvermeidlichen Projekt-Overhead. Statt umständlich Methoden zu evaluieren, fokussieren sie sich frühzeitig auf die risikoreichsten Themen–die sind fachlicher und/oder technischer Natur. Ich habe noch kein IT-Großprojekt gesehen, das an Mängeln im Formalismus gescheitert wäre. Ich möchte sogar die These aufstellen:
Je methodenlastiger die Projektsteuerung, desto höher die Wahrscheinlichkeit des Scheiterns.
Das bedeutet natürlich nicht, dass man Projekte ohne jede Methodik nur ad hoc “steuern” sollte. Methodik sollte nur nicht missbraucht werden, um die Auseinandersetzung mit den wirklich schwierigen Themen des Projekts zu vermeiden.
Christoph Lefkes