Eine Vielzahl von IT-lern hat es sicher schon einmal miterlebt: Trotz bester Voraussetzungen und eines top qualifizierten und gebrieften Teams stellt sich gegen Ende des Projekts heraus, dass das Budget überzogen wurde und/oder die Entwicklung deutlich länger dauert als geplant. „Wie konnte das passieren?“, heißt es dann, wo doch zunächst alles so gut und unproblematisch aussah. Dabei müsste die richtige Frage an dieser Stelle lauten: „Wenn alles glatt und ruhig verlief – warum ist dann nicht schon viel eher jemand misstrauisch geworden?“ Denn Softwareentwicklung ist ein komplexes Unterfangen mit unzähligen Risiken und potenziellen Fallstricken – nur zu selten läuft hier wirklich alles wie am Schnürchen. Kommen also keine größeren Probleme auf, heißt das meistens nur, dass sie bisher noch niemand erkannt hat. Je später sie allerdings zutage treten, desto schwieriger wird es, die Erwartungen und Ressourcen entsprechend anzupassen, und das Projekt läuft nach hinten heraus aus dem Ruder.

Wie lässt sich das Problem lösen? Klar: durch gutes Controlling. Wie lässt sich das aber wirklich effektiv umsetzen und was unterscheidet letztlich „gutes“ von „schlechtem“ Controlling? Schauen wir uns dafür zunächst an, wie Controlling oftmals fälschlicherweise verstanden und gehandhabt wird: Häufig liegt der Fokus lediglich darauf, den Überblick über das Gesamtbudget und die bisherigen Ausgaben zu behalten sowie die Differenz herauszufinden, um die verbleibenden Anstrengungen richtig zuzuordnen. Meist erfolgt diese Art des Controllings periodisch, zum Beispiel monatlich, zweiwöchentlich oder um Projektmeilensteine herum. Account-Manager teilen und diskutieren die Ergebnisse mit Projekt-Stakeholdern, um das weitere Vorgehen auszuhandeln. Klingt relativ einfach – ist es aber in Wirklichkeit leider nicht.

Gutes Controlling hat stattdessen zum Ziel, so früh wie möglich „positiv zu enttäuschen“. Das heißt: auf Probleme hinzuweisen, bevor sie sich manifestieren, und sie sofort zu deeskalieren. Hierfür braucht es sehr strenge und detaillierte Statusupdates – und das jeden Tag. Denn im Gegensatz zur flexiblen Planungsphase verläuft das eigentliche Controlling des Entwicklungsprozesses alles andere als agil. Das bedeutet, dass das Entwicklerteam kontinuierlichen Input gibt, um Restschätzungen vornehmen zu können. Dabei sollte nicht nur die aufgewendete Zeit für jede Aufgabe, sondern auch für jede Teilaufgabe und Unteraufgabe getrackt werden. Immer wieder müssen Entwickler neu abschätzen, wie viel Aufwand in Zukunft erforderlich sein wird. Diese Variable ändert sich ständig, denn je länger die Entwickler an einem Projekt arbeiten, desto mehr lernen sie und desto besser können sie vorhersehen, wie lange etwas dauern wird.

Controlling ist also eine kontinuierliche Übung, die während des gesamten Projekts und nicht nur periodisch durchgeführt werden sollte. Das Team sollte jeden Tag dazu in der Lage sein, ein genaues Statusupdate zu geben – wenn schon nicht für jedes Ticket, so doch zumindest auf dem Epic-Level. Kontinuierliches Mikro-Controlling erlaubt es, Warnsignale so früh wie möglich zu erkennen – und nicht erst am Monatsende oder im schlimmsten Fall, wenn ein Projekt fast abgeschlossen ist.

Was passiert aber nun, wenn ein zukünftiges Problem durch gutes Controlling frühzeitig erkannt wurde? Zunächst liegt es natürlich in der Verantwortung des Entwicklerteams, den Projektaufbau intern entsprechend anzupassen und durch Ressourcenverlagerungen den Risiken entgegenzuwirken. Gleichzeitig muss der Account-Manager den Status quo mit den Auftraggebern besprechen sowie – und hierauf kommt es an – schonungslos und transparent ihre Erwartungen managen. Jegliche Inszenierung ist hier fehl am Platz. Schließlich geht es um den Erfolg des Projekts – und es gibt nur wenig Schlimmeres als geschönte Statusupdates. Neben zeitlichen und finanziellen Engpässen kann es dabei zusätzlich auch vorkommen, dass sich bestimmte Feature-Ideen, die sich der Auftraggeber zunächst gewünscht hat, in der praktischen Umsetzung als nicht sinnvoll erweisen und keinen echten Mehrwert bringen.

Hier kommen die Vorteile eines agilen Anforderungsmanagements zum Tragen, bei dem der Kunde gleich von Beginn an dafür sensibilisiert wird, dass das Projekt auch dann den gewünschten Erfolg bringen kann, wenn es nicht alle ursprünglich geplanten Features beinhaltet. Softwareprojekte sind agile Projekte, die im Idealfall einer klar definierten Gesamtvision folgen und für alles andere einen anpassungsfähigen Plan haben. Geht es zum Beispiel um die Entwicklung einer Plattform, sollten zu Anfang 30 bis 40 Kernanforderungen definiert und konkretisiert werden – allerdings auf hohem Niveau und nicht durch eine Unterteilung in 600 Unterfunktionen. Ein gutes Projekt baut nicht nur auf einer soliden Strategie auf – es geht auch darum, taktisch flexibel zu bleiben. Anforderungen auf hoher Ebene öffnen so den Weg zu agilen Entscheidungen, weil sie im Licht neuer Fakten, Zahlen und Entwicklungen ständig neu interpretiert werden können.

1. In der Planungsphase eine Liste an Kernanforderungen definieren.
2. Auftraggeber für agile Entscheidungsfindungen sensibilisieren.
3. Täglich detaillierte Statusupdates durchführen:
   a. Zeit und Kosten für Teil- und Unteraufgaben tracken.
   b. Schätzung des Restaufwands kontinuierlich aktualisieren.
4.  Engpässen durch Ressourcenverlagerungen entgegenwirken.
5. Anpassungen von Features und des Projektplans mit Auftraggeber abstimmen.