Große und komplexe Vorhaben sind zum Normalfall im betrieblichen Alltag geworden. Für die Umsetzung solcher Vorhaben genügt nicht mehr nur ein Projekt, sondern es ist oft eine Vielzahl von Projekten erforderlich. Jedes dieser Projekte leistet einen definierten Beitrag zu diesem Vorhaben. Eine oft eingesetzte Methode, solche Vorhaben zu planen und zu steuern, sind Roadmaps. In einer Roadmap werden die gewünschten Produktivsetzungen für die einzelnen Leistungsstufen festgelegt. Die Umsetzung der Leistungsstufen kann dann in einem oder mehreren Projekten, durch ein Projektportfolio oder durch ein Programm erfolgen. Zur Steuerung solcher komplexer Vorhaben wird eine adäquate Fortschrittskontrolle benötigt, um im Bedarfsfall frühzeitig steuernd eingreifen zu können – zum Beispiel, wenn die Rentabilität des Vorhabens aufgrund gestiegener Projektkosten sinkt oder einzelne Projekte im Portfolio zeitlich oder inhaltlich nicht planmäßig fertiggestellt werden können.

Andererseits sollten die Projekte auch nicht zu detailliert geplant werden, um flexibel auf Änderungen reagieren zu können. Deshalb werden Projekte immer häufiger agil durchgeführt. Trotz aller Agilität bleiben aber eine klare Vorstellung über die Projektziele, die Terminierung der Projekte und eine laufende Fortschrittskontrolle essenziell für den Erfolg des Vorhabens.

Eine erfolgreiche Fortschrittskontrolle ist nur mit einem in das Projektvorgehen integrierten Projektcontrolling möglich. Der Zweck des Projektcontrolling ist nicht nur, Informationen über den Projektfortschritt zu bekommen, sondern damit auch möglichst frühzeitig Steuerungsimpulse für das Portfoliomanagement und zur Steuerung der Roadmap zu erhalten. Die im Controlling ermittelten Zahlen sind als Indikatoren zu verstehen und müssen für den agilen Projektkontext „übersetzt“ werden. Dieser Artikel beschreibt Ansätze aus der Praxis, mit denen ein klassisches Projektcontrolling ohne größere Eingriffe in agilen Projekten erfolgen kann. Beim Aufsetzen des Projektcontrollings ist auf die Angemessenheit der Controlling-Aktivitäten und der damit einhergehenden Aufwände zu achten. Dies schließt nicht aus, dass einzelne Ansätze durchaus auch für kleinere Projekte sinnvoll zum Einsatz kommen können.

Earned-Value-Analyse (Fertigstellungswertmethode)

Die am weitesten verbreitete Methode zur Fortschrittskontrolle ist die Earned-Value-Analyse (EVA), die einen guten Einblick in den aktuellen Projektstand erlaubt. Zentrale Elemente sind die Plankosten, die Istkosten und der Arbeitsfortschritt zur Ermittlung des Fertigstellungswertes (Earned Value).

Die Kosten für einen Projekttag (PT) sind abhängig von den Kosten der ausführenden Projektmitarbeitenden und/oder der eingesetzten Hilfsmittel. Lassen sich diese für die Projektleitung nur schwer oder gar nicht ermitteln, können folgende Vereinfachungen verwendet werden:

• Anstelle der tatsächlichen Kosten können die Aufwände in PT oder in Stunden angesetzt werden.
• Aus den Aufwänden werden durch Multiplikation mit einem festen Mischkostensatz (zum Beispiel aus der Angebotserstellung) die tatsächlichen Kosten geschätzt.

Das vereinfacht die Erstellung einer EVA und hilft, Planabweichungen einfacher zu erkennen. Effekte, etwa die Verlagerung von Arbeitspaketen auf preisgünstigere oder teurere Ressourcen, werden damit aber nicht berücksichtigt. Wie aber lassen sich die Kenngrößen agiler Projekte in diese „klassische“ Controlling-Welt übersetzen?

Istaufwände

Die Ermittlung der Istaufwände ist problematisch, wenn die Aufwände für das Projekt und seine Arbeitspakete nicht systematisch erfassen werden. Sollte eine systematische Erfassung nicht möglich sein, kann mit folgenden Näherungen gearbeitet werden:

• Rückrechnung aus dem Fertigstellungsgrad und dem Restaufwand

Voraussetzung für eine Näherung ist eine Ermittlung des Fertigstellungsgrads über Restaufwandsschätzung durch das Team oder durch ein Burn-Down-Chart. Eine Fertigstellungsgrad-Ermittlung beispielsweise über Mikromeilensteine oder ähnliche Methoden, bei denen mit festgelegten Stufen gearbeitet wird (z. B.: 0 % – 50 % bei Start bis 100 % bei Beendigung), ist dabei zu ungenau.

• Zeitproportionale Ermittlung des Istaufwands

Hier wird der Planaufwand proportional zur verstrichenen Zeit als Istaufwand angenommen. Damit lässt sich sehr einfach eine grobe Näherung erstellen. Dabei gehen folgende Annahmen in die Ermittlung ein: Das Arbeitspaket ist zum Planzeitpunkt gestartet, und es arbeiten alle Mitarbeiter zu ihrem geplanten Anteil an dem Arbeitspaket.

Da in beiden Fällen der Istaufwand ein Schätzwert ist, dient er nur als grobe Hilfsgröße zur Ermittlung eines Fortschrittswertes. Mit einem so geschätzten Istaufwand sind weder die Projekteffizienz noch der Mitarbeitereinsatz präzise ermittelbar und somit als potenzielle Ursachen für Planabweichungen auch nicht mehr erkennbar. Sowohl Projekteffizienz wie auch Mitarbeitereinsatz können jedoch in agilen Projekten über die Team-Velocity und das Burn-Down-Chart nachvollzogen werden. Deshalb kann in Ausnahmefällen, wenn eine systematische Aufwandserfassung nicht erfolgt, mit diesen Näherungen gearbeitet werden.

Bewertung der ermittelten Zahlen

Die so ermittelten Controlling-Zahlen sind Indikatoren, anhand derer eine Planabweichung überprüft werden kann. Die Überprüfung dieser Zahlen auf ihre Korrektheit ist für die Qualität des Controllings des Vorhabens essenziell. Ursachen für eine falsche Zahlenbasis können sein:

• zum Stichtag noch nicht erfasste Istaufwände
• Nicht-Erfassung von Istaufwänden, etwa wegen kurzfristigem Ausfall eines Mitarbeitenden,
• vergessene Aktualisierung der Restaufwände,
• falsche Annahmen bezüglich der Ermittlung des Fertigstellungsgrades sowie
• falsche Erfassung von Istaufwänden, wie Einarbeitungsaufwände, die auf Projektleistungen gemeldet wurden, oder Meldung von Aufwänden auf ein falsches Arbeitspaket.

Wenn sichergestellt ist, dass die Zahlenbasis für die Ermittlung der Ist- und Restaufwände keine systematischen Fehler mehr enthält, erfolgt die Klärung der Ursachen für Abweichungen. Im Folgenden beispielhaft eine Auswahl häufiger Ursachen in großen Vorhaben. Da die so ermittelte Zahlenbasis unabhängig von einem klassischen oder agilen Projektvorgehen ist, sind die aufgeführten Ursachen nicht spezifisch für agile Projekte:

• Der Aufwand für ein Arbeitspaket wurde unter- oder überschätzt

Solange sich die Abweichung im Risikokorridor bewegt (üblicherweise 10 %), ist diese methodisch bedingt zu akzeptieren. Wichtig ist zu prüfen, ob im Projekt vorwiegend Über- oder Unterschätzungen vorkommen. Bei laufend signifikanten Abweichungen ist die eingesetzte Schätzmethode durch den Scrum Master zu justieren, etwa durch eine Erweiterung der T-Shirt-Größen oder Adjustierung der Referenz-Arbeitspakete für den Planning-Poker.

• Die Schätzungenauigkeit ist, je nachdem, zu welchem Zeitpunkt die Schätzung erfolgt, unterschiedlich hoch

In diesem Fall sollte versucht werden, die Schätzmethode im Projektverlauf, zum Beispiel in den Refinement-Meetings und den Sprint-Plannings, zu überprüfen und eventuell anzupassen.

• In der Aufwandsschätzung wurden der Arbeitspaketinhalt, die ursprünglich angedachte Lösungsidee oder die Akzeptanzkriterien nicht berücksichtigt

Dies kann auch durch späte Änderungen, beispielsweise durch agilen Anforderungstausch im Projekt, verursacht werden, deren Tragweite im Refinement oder Planning falsch eingeschätzt wurde.

• Das Scrum-Team besitzt nicht alle erforderlichen Fähigkeiten, das Sprint-Ziel zu erreichen

Möglicherweise ist das Grundprinzip des „interdisziplinären Teams“ verletzt, was entsprechende Auswirkungen auf die Sprintplanung und die Priorisierung in den Backlogs hat. Es müssen zusätzliche Spezialisten zu festen Zeiträumen eingeplant werden und die für ihren Einsatz notwendigen Voraussetzungen zu diesem Zeitpunkt vollständig geschaffen sein.

• Schleichende Änderungen oder Missverständnisse, die weder dem Product Owner, dem Scrum Master, noch dem Projekt team aufgefallen sind

Häufig geschieht dies bei Personalwechseln im Scrum-Team. Selbst gut beschriebene Lösungsideen und fachliche Anforderungen bieten Raum für Interpretation. Deshalb sollte der Wechsel von Mitarbeitern in Scrum-Teams auf das absolut notwendige Minimum reduziert werden.

• Vermeintlich aufwandsneutraler agiler Anforderungstausch, der entgegen der ursprünglichen Erwartung aller Beteiligten doch Mehraufwände verursacht

Diese Mehraufwände lassen sich minimieren, indem auch beim Anforderungstausch allen Beteiligten die Möglichkeit gegeben wird, die Auswirkungen der Änderung zu bewerten, um zu schelle und unüberlegte Änderungen zu vermeiden.

• Der ursprünglich angedachte Lösungsansatz trägt nicht, oder ist unvollständig

Häufig wird diese Situation erst während der Umsetzung im Sprint erkannt. Hier kann teilweise mit projektspezifischen Musterlösungen oder Blaupausen gegengesteuert werden. Beide Möglichkeiten führen auch zu einer homogeneren Umsetzung.

 

Um aus Abweichungen für die weitere Umsetzung der Roadmap oder auch neue Vorhaben zu lernen, hat sich in der Praxis bewährt, Abweichungen in folgende zwei Typen einzuteilen:

• systemische / systematische Abweichungen, also Abweichungen, die sich laufend summieren (zum Beispiel durch die eingesetzte Vorgehensweise) und sich immer weiter auf ein Projekt auswirken. Sie sind schnellstmöglich zu korrigieren.
• einzelne Ausreißer, die nur in einem fallspezifischen Kontext auftreten. Bei diesen Ausreißern sind (nur) die konkreten Auswirkungen einzudämmen und zu minimieren.

Die ermittelten Indikatoren sind Frühwarnindikatoren, die, richtig angewendet, frühzeitig Steuerungsimpulse zur Umsetzung der Roadmap geben. Diese Frühwarnindikatoren spiegeln immer auch die Gesamtperformance und das Zusammenspiel aller Projektbeteiligter wider, also des Programm- oder Portfolio-Managements, des Product Owners und des agilen Teams:

• Werden trotz frühzeitigem Aufzeigen von Entscheidungsbedarfen Entscheidungen durch das Portfolio-Management oder das Programm-Management erst spät getroffen, können sie zu Übergangslösungen oder dem Abbrechen oder Verschieben einzelner Arbeitspakete führen. Trotz guter Performance im agilen Team können dadurch Mehraufwände wie Rückbauzeiten oder zusätzliche Rüstzeiten für Übergangslösungen entstehen.

• Hat ein agiles Projektteam durch Mikromanagement zu geringen Entscheidungsspielraum, führt dies zur Behinderung bei der Ausführung von Umsetzungsentscheidungen. Hier kann eine Ausweitung des Entscheidungsspielraums für das Projektteam zu einer besseren Projektperformance führen.

• Managemententscheidungen, die, getrieben durch den Business Case oder Kundenanforderungen, zentrale Ziele oder Inhalte des Projektes so verändern, dass umgesetzte Lösungen oder Lösungsideen nicht mehr tragfähig sind, sind zu vermeiden. Solche Entscheidungen dürfen nur über den Product Owner in das Projekt einfließen. Im Einzelfall kann eine Projektzäsur mit einer Neubewertung des Projektes, also ein sogenannter „Kassensturz“, bei dem die zugrundeliegende Wirtschaftlichkeitsbetrachtung überprüft wird, sinnvoll sein.

• Falsche Annahmen zum Einspar- oder Umsatzpotenzial des Projektes führen in der Regel zu einer Kurskorrektur im Projekt. In diesem Fall ist eine Zäsur des Projekts und dessen Neubewertung sinnvoll.

• Sehr häufige Änderungswünsche binden Mitarbeiterkapazitäten, meist sogar die Kapazität zentraler Projektmitarbeiter. Diese im Projekt nicht eingeplanten Tätigkeiten können nur in sehr begrenztem Umfang durch Puffer aufgefangen werden. Häufige Änderungen sind ein Indikator, dass die im Projektauftrag genannten Ziele oder die Projektrahmenbedingungen sich maßgeblich verändert haben.