Seite 2: Was kann Controlling und was nicht?

Inhaltsverzeichnis

Die Rückkopplung sollte fachlicher Natur sein: Wo muss beispielsweise nachgebessert werden, damit sich die Anforderungen der Kunden effizient umsetzen lassen? Welche technischen Spezifikationen sind zu überdenken? Softwareprojekte unterliegen allerdings wie andere Projekte dem anfangs definierten Zeit- und Budgetrahmen. Dessen Einhaltung zu gewährleisten, ist die Kernaufgabe des Controllings, die üblicherweise über die reine "Kontrolle" hinausgeht. Viele Unternehmen verstehen Controlling jedoch nur als Kontrollmechanismus, der an bestimmten Meilensteinen prüft, wie viel Budget das Projekt bereits verschlungen hat und ob der Zeitplan eingehalten werden kann. Das ist jedoch zu kurz gedacht, denn Controlling kann mehr.

Projektbeteiligte sollte das Controlling eher als Steuerungsfunktion verstehen und nutzen. Nach der Anfangsplanung gehört es zu den Aufgaben des Controllers, den Projektfortgang laufend zu analysieren und, falls sich generelle Engpässe oder Veränderungen ergeben, entgegenwirkende Maßnahmen vorzuschlagen. Wichtig dabei ist, nicht nur den Status quo des Budget- und Zeitverbrauchs zu betrachten, sondern auch weitere Informationen zu sammeln. Hier schließt sich der Kreis: Je enger das Entwicklerteam und alle anderen Projektbeteiligten mit dem Controlling zusammenarbeiten, umso effizienter lässt sich der Projektverlauf steuern.

Ist beispielsweise frühzeitig absehbar, dass die Entwicklung wegen unterschätztem Integrationsaufwand länger dauert als geplant, muss dies nicht zwingend in mehr Zeitdruck für die Entwicklerinnen und Entwickler oder gar eine Verschiebung der Auslieferung münden. Das Controlling könnte auch zu dem Ergebnis kommen, dass es insgesamt vorteilhafter ist, zusätzliche Entwicklerkräfte in das Projekt einzubeziehen – oder andere Projekte mit geringerer Priorität vorübergehend zurückzustellen. Auch lassen sich die Kosten für ein benötigtes Tool gegebenenfalls als Effizienz-Maßnahme begreifen, die das gesamte Projekt voranbringt, und nicht als zusätzlichen Kostenaufwand. Solche Entscheidungen können Controller aber nur treffen, wenn sie frühzeitig und umfassend informiert sind.

Microcontrolling, ohne den kreativen Raum einzuengen

Wie kleinteilig muss das Controlling sein? Es gilt, die Balance zwischen harten Zahlen, Fakten und Steuerungsmaßnahmen auf der einen Seite und kreativem Freiraum für die Softwareentwicklung auf der anderen Seite zu wahren. Während zu viel Planung behindert, engt zu viel Standardisierung ein. Manche Probleme lassen sich nur mit kreativem Coding und flexiblen Methoden lösen. Die Bereitschaft, Dinge auch auf andere Weise anzugehen, gehört zum modernen Software-Engineering. Gerade in Zeiten der Containerisierung und des Cloud Deployments stehen viele Tools, Optionen und Workarounds zur Verfügung. Warum nicht auch einmal in der Gruppe vor dem Bildschirm sitzen und über Einzelheiten im Quellcode oder die richtige Interpretation von StackOverflow-Antworten diskutieren – wie es beim Mob-Programming vorgesehen ist. Den dafür nötigen Freiraum dürfen Controlling-Kriterien nicht zu stark einengen oder gar ausschließen.

In den agilen Entwicklungsprozess integriertes Microcontrolling empfiehlt sich als praktikabler Lösungsansatz. Die Idee dabei ist, die Variablen, die insbesondere für das Controlling wichtig sind, beim täglichen Ausbalancieren des Entwicklungsprozesses einzubeziehen. Wenn also das Dev-Team im Scrum-Meeting Sprints umplant oder Änderungen am Product-Backlog vornehmen muss, sollten auch die Auswirkungen auf die Zeit- und Kostenplanung beziffert werden – und zwar möglichst genauso kleinteilig, wie es für den Coding-Prozess erfolgt. Denn wenn sich im Sprint-Review ergibt, dass ein zusätzlicher Sprint angehängt oder weitere Anpassungen umgesetzt werden müssen, dann verschiebt sich alles Nachfolgende. Sobald es Entwicklerinnen und Entwicklern gelingt, solche Aspekte standardmäßig in ihre Planung zu integrieren und mit dem Controlling abzustimmen, lassen sich Abweichungen früher erkennen. Das wiederum erleichtert sinnvolles Gegensteuern, ohne die gesamte Planung über den Haufen werfen zu müssen.

Erwartungs- und Anforderungsmanagement: den Auftraggeber stärker einbinden

Sprint-Reviews sind eine Gelegenheit – und im Sinne der Methode auch dafür vorgesehen –, sämtliche Stakeholder eines Projektes an einen Tisch zu bringen. Auftraggeber und Nutzer können Features testen und ihre Funktionalität sowie praktische Anwendbarkeit beurteilen. In den Reviews treten regelmäßig gerade jene Probleme zutage, die nur im Zusammentreffen der verschiedenen Disziplinen entdeckt werden. Ein typisches Beispiel dafür ist eine Funktion in der Software, die auf dem Papier alle definierten Kriterien erfüllt, bei Anwenderinnen und Anwendern aber durchfällt, weil sie den entsprechenden Button nicht finden. Denn den hat das Entwicklerteam zwar an einer technisch sinnvollen, aber aus Sicht einer optimalen User Experience (UX) wenig geeigneten Stelle platziert. Dann entscheidet das Feedback in den Sprint-Reviews darüber, wie es weitergeht – mit den beschriebenen Auswirkungen auf die Dauer und die Kosten des Gesamtprojekts.

Andererseits haben dadurch auch Entwicklerinnen und Entwickler die Möglichkeit, ihrerseits auf erforderliche Anpassungen aufmerksam zu machen. Nicht selten schließen technische Notwendigkeiten bestimmte Funktionen gänzlich aus oder verändern sie so stark, dass die Nutzer unzufrieden sind. In der gemeinsamen Diskussion lässt sich Verständnis aufbauen und – in den meisten Fällen – eine angemessene oder sogar bessere, neue Lösung finden. Beinahe automatisch entwickelt sich dabei ein aktiv gelebtes Erwartungs- und Anforderungsmanagement: eine Balance zwischen dem Gewünschten und dem Möglichen – stets unter der Beobachtung des Controllings.

So früh wie möglich "positiv enttäuschen": Softwareprojekte wieder auf Kurs bringen

Dabei müssen Controller vor allem im Auge behalten, dass das Projektmanagement nicht zu agil über alle Planungsgrenzen hinweg arbeitet, damit sich die Auswirkungen von Änderungen im Projekt möglichst frühzeitig quantifizieren und mit der Gesamtplanung in Einklang bringen lassen. Unumgänglich ist, dass das Controlling auch bremsend eingreift. Wenn beispielsweise der Aufwand für eine neue, erweiterte Funktion im Verhältnis zum Nutzen zu groß wird, muss es die Möglichkeit geben, abzubrechen und einen neuen Ansatz zu entwerfen.

Je früher im Projektverlauf das geschieht, umso besser: Auch wenn solche Einschnitte sich im ersten Moment wie eine Enttäuschung oder Einschränkung anfühlen, bewahren sie das Gesamtprojekt häufig vor schlimmeren Folgen. Oft treten im Projektalltag Probleme erst zutage, wenn sie bereits hohen Aufwand und entsprechende Kosten verursacht haben. Häufig ist es dann zu spät, die Dinge zurückzurollen. Viel Arbeit ist vergebens getan, schlimmstenfalls muss das Projekt eingestellt werden. Frühes „positives Enttäuschen“ kann das verhindern. Mit geeigneten strategischen, organisatorischen und technischen Maßnahmen – von der Anpassung der Anforderungen über die Aufstockung der Ressourcen bis hin zum Erwerb weiterer Tools oder geeigneter Infrastruktur – lässt sich das Projekt besser aussteuern.