Projektmanagement

Agil versus plangetrieben, eine Übersicht

Definition¹
Die DIN 69901 definiert Projektmanagement (PM) als Gesamtheit von Führungsaufgaben, -organisation, -techniken und -mittel für die Abwicklung eines Projekts.

Definition²
Das Project Management Institute (PMI) definiert PM als Anwendung von Wissen, Fähigkeiten, Methoden und Techniken auf die Vorgänge innerhalb eines Projekts.

Projektmanagement hat zum Ziel, einen Projektauftrag so umzusetzen, dass der Nutzen für das Unternehmen im Vordergrund steht. Auf dem Weg dorthin nehmen Faktoren wie die Organisationsstruktur und die Unternehmenskultur großen Einfluss auf die Projektgestaltung und Durchführung.
Diese Faktoren beeinflussen die Art und Weise wie mit Risiken umzugehen ist, oder auch das Vorgehensmodell, also ob ein agiler, hybrider oder plangetriebener Ansatz gewählt werden sollte.
Das Vorgehensmodell wiederum bestimmt die umzusetzenden Projektplanungsaktivitäten, die Kommunikation innerhalb und außerhalb eines Projektes und vieles mehr.

Projekte sind in aufeinander aufbauende Phasen unterteilt. Prozesse sorgen entsprechend den obigen Definitionen für die Abwicklung.
Im weiteren Verlauf werden die Prozesse und Unterschiede zwischen den Ansätzen detailliert.

Agil versus planbarsiert, eine Übersicht
     Projektinitialisierung, Definition und Auftrag
     Projektorganisation
          Projektablage
          Projektplanung
     Kick-Off
     Projektdurchführung, weitere Schritte
          Durchführung des „planbarsierten“
               Meilensteine und Qualitätskontrolle
               Statusverfolgung, Besprechungen und Reports
          Durchführung „agil“
               Iteration
               Prüfpunkte und Qualitätskontrolle
               Statusverfolgung
Eine Gegenüberstellung, auf einige Aspekte beschränkt
Weitere Aspekte

Projektinitialisierung, Definition und Auftrag

Bevor Projektmanagement zum Einsatz kommt, muss zu aller erst ein Projekt definiert werden. Eine Projektinitialisierung kann aus vielerlei Gründen angestoßen werden, etwa

• abgeleitet aus dem Produktportfolio Management
• zur Umsetzung einer Produktidee oder Kundenanfrage
• als Verbesserungsmaßnahme (Prozess, Qualität, Kundenzufriedenheit)
• aus regulatorischen Auflagen (zum Beispiel DSGVO)

und etlichen weiteren. Unabhängig davon ist ein klares Projektziel in Form einer Projektdefinition³ zu erstellen. Ein Titel allein ist nicht ausreichend, vielmehr soll die Projektdefinition ein klares Bild von dem zu erreichenden Ziel vermitteln. Die Antwort auf die Fragestellung Was soll Wie und Wozu umgesetzt werden kann hierzu als Hilfestellung dienen.

• Was, zum Beispiel ein neues Produkt
  
• Wie, zum Beispiel durch einen neuen oder veränderten Geschäftsprozess mit Software Unterstützung, Werbekampagnen, etc. sowie die Rahmenbedingungen, unter denen ein Projekt durchzuführen ist
  
• Wozu, zum Beispiel für die Einführung eines neuen Produktes zur Umsatzsteigerung, für verbesserte Kundenbindung oder zur Effizienzsteigerung

Die Projektdefinition bildet die Grundlage weiterer Aktivitäten, mit dem Fokus auf Erstellung einer Entscheidungsvorlage. Diese wiederum ist Basis für eine „Go / no Go“ Entscheidung, also der Einleitung der nächsten Projekt-Phase, oder der Einstellung aller weiteren Aktivitäten bezüglich des neuen Vorhabens.

Der Aufwand für eine Entscheidungsvorlage variiert von gering für Standardvorhaben bis zu aufwendig für Vorhaben mit einer großen Unsicherheit und zu erwartetem großem Umfang. Letzteres kann zu einer Initiierung eines vorgeschalteten Evaluierungsprojektes führen.
Mögliche Maßnahmen zur Ermittlung von Daten zur Entscheidungsfindung:

• Marktanalyse, Risiken und Chancen
• Kundenbefragung
• Klärung technischer, rechtlicher, regulatorischer und ethischer Machbarkeit
• Tool oder HW Evaluierung / Auswahl versus Eigenentwicklung
• Verfügbarkeit von Ressourcen
• grobe Budgetabschätzung

Zur Erarbeitung einer Entscheidungsvorlage sind die Stakeholder der frühen Stunde und der Sponsor mit einzubeziehen. Je nach Vorhaben zählen unter anderen Ansprechpartner aus dem Marketing, Vertrieb, Finanzen, Einkauf, Recht, Regulierung, Sicherheit, Architektur, Qualität, Betrieb, Systemverantwortliche und eventuell auch Arbeitnehmervertreter dazu.

Die Zielsetzung: frühzeitiges Aufdecken von Hindernissen, Risiken und Aufwandstreibern, sowie ein erster Eindruck, wie das Projektvorhaben durch die eingebundenen Stakeholder aufgenommen wird.

Alternativ ermöglicht das Instrument Project Canvas⁴ als Projektdefinition und Entscheidungsvorlage zu dienen. Der Ansatz geht auf die Idee des Business Model Canvas⁵ zurück. Im Wesentlichen werden die oben erwähnten Fragestellungen auf einer strukturierten Seite zusammengefasst. Die Strukturvorgabe, angereichert mit themenspezifischen Fragestellungen, stellt dabei sicher, dass alle relevanten Themenfelder erfasst werden.

Ein Project Canvas unterstützt durch die auf einen Workshop ausgerichtete Form die frühe Einbindung der Stakeholder und damit die oben formulierte Zielsetzung.

Nach einer „Go“ Entscheidung startet nach der Formulierung des Projektauftrages die Projektplanung und die zu Beginn wesentliche Anforderungserhebung.
Der Projektauftrag⁶ setzt sich aus der Projektdefinition und den Angaben zu

• Ressourcen (Budget, Team, Maschinen, Räume, …)
• Zeitplanung inklusive Basis-Meilensteine
• Qualität
• Risiken und Chancen
• Stakeholder

aus der Entscheidungsvorlage zusammen. Wurde das Instrument Project Canvas gewählt, kann das Ergebnis direkt als Projektauftrag Verwendung finden.

In einer nach agilem Vorgehensmodell gesteuerten Organisation ist die Projektinitialisierung Teil des Modells. Gründe bzw. Vorhaben, die zu einer Projektinitialisierung führen, werden in Form von Epen im Portfolio- oder Produkt Backlog verwaltet. Ein Prozess zur Bewertung von Epen soll dazu führen, die jeweils für das Unternehmen wertvollsten für eine Umsetzung auszuwählen. Die Maßnahmen für eine Bewertung können dabei die selben, wie schon oben beschrieben sein. Ein wesentlicher Unterschied ist die relative Bewertung der im Backlog befindlichen Vorhaben zueinander. Eine relative Bewertung, ohne absolute Zahlen, ist für den hohen Abstraktionsgrad, den ein Epos beschreibt, leichter und schneller zu ermitteln, als eine Schätzung mit Ressourcen- und Zeitangaben.

Ein Epos aus dem Portfolio Backlog ist noch am ehesten mit einer Projektdefinition bzw. dem Projektauftrag vergleichbar, insbesondere wenn die Instrumente Project- bzw. Product Canvas eingesetzt wurden.

Projektorganisation

Als einer der ersten Schritte, eventuell auch schon im Projektauftrag festgehalten, ist eine Projektorganisation zu erstellen. Dies betrifft die Rollen und einzubeziehenden Stakeholder, das Vorgehensmodell und die Ablagestrategie.

Die Projektorganisation ist dynamisch und verändert sich je nach Projektphase, wobei eine Kernorganisation vom Anfang bis zum Ende stabil bleiben sollte. Den Kern bildet der Auftraggeber mit dem benannten Projektleiter, eventuell einem Qualitäts- und Sicherheitsbeauftragten, sowie den Teilprojektleitern aus Entwicklung, Test und Betrieb, oder den jeweiligen Systemverantwortlichen.
In den einzelnen Phasen kommen dann Experten aus Fachbereichen der eigenen Organisation oder des Kunden, als auch Architekten, Entwickler, Tester und der Betrieb hinzu.
Weitere Experten aus den Fachbereichen können sich zum Beispiel aus den Themen Recht, Regulierung, Finanzen, Einkauf, Marketing oder Vertrieb rekrutieren. Wobei jeder dieser Fachbereiche auch Auftraggeber sein kann.
Als Form eignet sich ein Organisationsdiagramm, oder auch eine einfache Liste. Letztere mit Attributen zur Rolle und Kommunikation angereichert, kann gleichzeitig als Projektorganisationsplan, Kommunikations- und Stakeholder-Management-Plan dienen (siehe Beispiel)

Die Durchführung in agilen Organisationen unterscheidet sich insofern, als das interdisziplinär zusammengestellte Teams zusammen mit dem Product Owner die Kernorganisation bilden. Die Rolle Product-Owner kümmert sich um die Anforderungen (Product-Backlog). Zusammen mit dem agilen Team erarbeitet der Product-Owner vor und während der Implementierung an der Detaillierung der Anforderungen, auch unter Einbeziehung weiterer Expertise.

Prinzipiell ist die agile Organisationsform schlanker und zielgerichteter, da eingespielte Teams mit weniger „Overhead“ auskommen und Aufgabenwechsel verringert werden.

Projektablage

Schon sehr früh im Projekt stellt sich die Frage nach der Ablagestrategie. Die Ablagestrategie definiert wie, wo und für wen zugänglich welche Informationen abzulegen sind. Um Transparenz herzustellen, sollten alle im Projekt erzeugten Dokumente so offen zugänglich sein wie möglich.
Den Fragen nach dem „wie“ und „wo“ stehen Anforderungen bezüglich Datensicherheit, Kosten und eventuell schon etablierte Lösungen gegenüber.

• Kann eine Cloud Lösung fremd- oder selbst- betrieben mit Ablage in der EU oder weltweit in Betracht gezogen werden?
• Stehen schon Lösungen wie Microsoft Sharepoint^®, Atlassian Jira^® in Verbindung mit Confluence^® oder andere „Team Collaboration“ Alternativen zur Verfügung?
• Wird eine Versionsverwaltung oder ein Dokumenten-Management-System eingesetzt?

Je nach gewählter Lösung sind vordefinierte Strukturen, Schlagwörter und Verlinkungen anzulegen. Des weiteren ist sicherzustellen, das Zugriffsrechte erteilt werden und alle involvierten Personen mit dem Umgang der eingesetzten Lösung vertraut sind, beziehungsweise eine Einführung (Leitfaden, HowTo, Wiki) zur Verfügung steht.

Projektplanung

Die Projektplanung erfolgt einmal initial und dann fortlaufend zur Projektdurchführung und abgestimmt auf vorgegebene Meilensteine. Die Vorgabe kann aus dem Projekt heraus oder von außen kommen. So werden die Projektpläne nach und nach detailliert. Die Projektplanung … setzt sich aus folgenden Kompetenzfeldern zusammen:

• Projektdefinition
• Anforderungsmanagement
• Budget- und Ressourcenmanagement
• Zeitmanagement
• Qualitätsmanagement
• Kommunikationsmanagement (Stakeholder)
• Risikomanagement
• Beschaffungsmanagement

Grundvoraussetzung für jede Planung ist das Aufbrechen von Komplexität in verständliche, greifbare Teile. Die Projektpläne beschreiben dann alle notwendigen Aktivitäten zur Lösung der Teile und die Zusammenführung aller Teile zum Gesamtbild, dem Projektziel.
Dabei ist die Projektplanung ein dynamischer Prozess, der genau wie das zu steuernde Projekt Änderungen unterliegt.
Pläne bilden einen Soll-Zustand ab. Verändern sich Voraussetzungen, müssen die Pläne den aktuellen Gegebenheiten angepasst werden.

Diese Betrachtungsweise hat für die plangetriebenen Vorgehensmodelle Wasserfall und V-Modell eine größere Bedeutung, als für ein agiles Vorgehen. Das plangetriebene Vorgehensmodell stellt die Gesamtheit der Anforderungsdefinitionen und die von Anfang bis zum Ende geplante Umsetzung in den Mittelpunkt.

Der agile Ansatz⁷ stellt hingegen eine schnelle Umsetzung einzelner Anforderungen in funktionierende wertvolle Funktionalitäten, also sinnvoll für den Kunden nutzbare Teile in den Vordergrund.
Damit verändert sich nicht nur die Verteilung der Aufgaben und Verantwortlichkeiten. Es verändern sich auch die Planungsgrundlage, Organisationsformen und wesentlich, die Interaktion der Projektbeteiligten. Letzteres wird durch Bildung interdisziplinärer Teams, das iterative Vorgehen und die Rückkopplungsschleifen zum Auftraggeber forciert.

Eine mögliche Transformation von der plangetriebenen Organisation hin zur agilen Organisationsform beschreibt zum Beispiel SAFe^®8 in einem Rahmenwerk.

Auf die konkreten Projektplanungsaktivitäten und Unterschiede zwischen der agilen und den plangetriebenen Vorgehensmodellen wird auf der Seite Projektplanung eingegangen. Daher finden die einzelnen Planungsschritte im Folgenden nur Erwähnung und sind entsprechend verlinkt.

Kick-Off

Das Kick-Off als Veranstaltung dient der Projektteam-Zusammenführung. Es gilt die Projektidee und Ziele zu transportieren und die Teammitglieder dafür zu gewinnen. Jedes Teammitglied muss letztendlich von der Projektidee und den Zielen überzeugt sein, um diese mitzutragen.
Je nach Vorgehensmodell und Phase kann auch mehr als eine Kick-Off Veranstaltung durchgeführt werden. Insbesondere wenn mit der Phase zur Kodierung und Test das Team eine Veränderung erfährt, ist die Durchführung einer zweiten Kick-Off Veranstaltung empfehlenswert.

Nach einer kurzen Vorstellungsrunde ist neben der Projektidee, eine übergeordnete Einordnung in die Unternehmensziele und eine detaillierte Projektbeschreibung inhaltlicher sowie organisatorischer Art zu präsentieren und Raum für Fragen und Diskussion einzuplanen.

Als Quellen zur Verfügung stehen

• Projekt – Auftrag
• Projekt – Organisation

und so weit schon vorhanden,

• Projekt – Meilensteine
• Business Case
• Budget – Vorgaben
• Anforderungsdokument oder Prodcut Backlog

Projektdurchführung, weitere Schritte

Die Projektdurchführung unterscheidet sich je nach Vorgehensmodell fundamental voneinander. Während sich die Planungen und das Nachverfolgen für Qualität, Risiken, Kommunikations- und Stakeholdermanagement noch ähnlich darstellen, sind insbesondere das Anforderungs-, Zeit- und Ressourcenmanagement auf das jeweilige Vorgehensmodell zugeschnitten.

Das obige Schaubild soll dies verdeutlichen. Im oberen Teil ist das planbare und im unteren das agile Vorgehensmodell skizziert. Die Mitte ziert ein Balken mit den Kompetenzfeldern Qualität, Risiko, Kommunikation und Stakeholder-Management.
Übergeordnete Qualitätsziele und Vorgaben spielen ebenso wie ein Risiko- oder Stakeholder-Kommunikations-Verzeichnis unabhängig vom Vorgehensmodell eine Rolle. Die Auswirkungen oder die Ausprägung wiederum mag unterschiedlich sein.
Ein Risiko, welches zu einer Änderung von Anforderungen führt, kann erhebliche Auswirkungen auf die sequentielle Ausführung, bis hin zur Neuplanung haben. Das agile Vorgehen hingegen ermöglicht durch die Integration des Anforderungsmanagements (Backlog) in den iterativen Prozess, ohne Irritation auf solch eine Anforderung zu reagieren.

Durchführung des „planbarsierten“

Das obige Schaubild ist bewusst einfach gehalten und verzichtet darauf, Optimierungen einzubeziehen. Dies betrifft sowohl die Besonderheiten des V-Modells, als auch Möglichkeiten zur Parallelisierung.
Auch wenn das Wasserfallmodell ein starres Vorgehen vorgibt, so sind durchaus flexible Variationen möglich. Zum einen behandeln Projekte häufig Änderungen an mehreren Komponenten und zum anderen hat nicht jede Änderung fatale Auswirkungen.
Unter Berücksichtigung von Abhängigkeiten der einzelnen Komponenten untereinander, können so Entwicklungen parallelisiert werden. Und je weniger Abhängigkeiten eine Komponente aufweist, je einfacher sind verspätete Änderungswünsche umsetzbar.

Das kontinuierliche Anforderungsmanagement behandelt Änderungswünsche während der Projektdurchführung. Jede neue oder geänderte Anforderung ist zu analysieren, um die Auswirkungen auf Zeit, Ressourcen und Qualität zu ermitteln. Basierend auf den so gewonnenen Erkenntnissen, kann eine Entscheidung zu einer möglichen Umsetzung getroffen werden.
Dieses formale Vorgehen dient der Vermeidung schleichender Anforderungserweiterung bzw. Änderung. Der formale Aufwand kann sehr gering ausfallen, wenn eine Änderung im Kontext einer Besprechung von allen involvierten Parteien ohne nennenswerten Einfluss auf Zeit, Ressourcen und Qualität akzeptiert wird. Andererseits kann eine vermeintlich kleine Anforderung erhebliche Irritationen auslösen.

Akzeptierte Änderungen mit Auswirkungen auf Zeit, Ressourcen und Qualität nehmen Einfluss auf die Projektpläne und nach Anpassung auf den geplanten SOLL Zustand.
Die Akzeptanz einer neuen oder geänderten Anforderung ist im Rahmen des Anforderungsmanagements formal einer Genehmigung zu unterziehen. Der Informationsaustausch mit allen Stakeholdern ist zu gewährleisten.

Meilensteine und Qualitätskontrolle

Meilensteine, die über Abbruch oder Weiterführung eines Projektvorhabens bestimmen, dienen zur Portfolio Steuerung. Projekte werden sukzessive des Fortschritts und daraus neu gewonnener Erkenntnisse zum Aufwand überprüft und bewertet. Entspricht ein Projekt den prognostizierten Erwartungen nicht mehr, kann es so frühzeitig im Umfang eingeschränkt oder beendet werden.

Dem positiven Steuerungseffekt steht dieser Art Kontrolle der zusätzliche Aufwand gegenüber. Sowohl die Vorbereitung der Unterlagen inklusive Schätzungen, als auch die oft starr terminierte Durchführung der Genehmigungsgremien kosten Zeit und Ressourcen. Dabei wird für die Zielerreichung konkret nichts erreicht, im Gegenteil, das Projekt wird ausgebremst.
Daher sollten Genehmigungs-Meilensteine auf ein Minimum reduziert und durch ein entsprechend autorisierten Lenkungsausschuss, welcher die kontinuierliche Projektentwicklung begutachtet, ersetzt werden.

Hingegen sind Qualitätsprüfpunkte für die Zielerreichung förderlich. Je früher Unstimmigkeiten oder gar Fehler entdeckt werden, je kostengünstiger lassen sich diese beheben. Daher sind erzeugte Liefergegenstände (Deliverables) wie Spezifikationen und Design-Dokumente einer Prüfung zu unterziehen.
Eine geeignete Form dieser Qualitätsprüfung sind Review-Portale, auf denen alle relevanten Stakeholder ihre Kommentare zu dem jeweiligen Liefergenstand mit Verweis auf die Version, Kapitel und Textstelle abgeben können. Die überwiegende Anzahl der Kommentare wird so zwischen Autor und Review Teilnehmer geklärt. Komplexere Anmerkungen, oder solche die einer breiteren Diskussion bedürfen, werden in einer Review-Session behandelt.
Ein zusätzlicher Nutzen ergibt sich aus der Betrachtung der Lösungsbeschreibung, aus den unterschiedlichen Sichtweisen der einzelnen Stakeholder heraus. Damit wird das gemeinsame Verständnis gefördert und die Erwartungshaltung angeglichen.

Die Qualitätsprüfpunkte sind zu planen und der Aufwand in der Ressourcenplanung zu berücksichtigen. Dies gilt auch für eventuelle Ausschreibungen.

Eine andere Maßnahme der Qualitätskontrolle ist das Testen, auf die hier aus Sicht des Projektmanagements eingegangen wird. Einen Einstieg in das Thema Testen mit Verweisen auf weiterführende Literatur bietet Wiki Pedia⁹. Darüber hinaus existieren eine Vielzahl von Theorien, Konzepten und Praxisleitfäden.
Die Aufgaben rund um das Testen setzen sich, wie die Entwicklung auch, aus unterschiedlichen Phasen zusammen. Die Testvorbereitung startet parallel zur Entwicklung mit der Erstellung von

• Testkonzept
• Testfällen
• Testautomatisierung
• Anpassung von Regressionstestfällen
• Testdaten
• und der Vorbereitung der Testumgebungen

Basis für die Testentwicklung der Teststufen System-, Integrations- und Abnahmetest sind die Anforderungen, denn neben der rein funktionalen Prüfung ist zu zeigen, dass die Realisierung den Anforderungen genügt.
Eine andere Definition besagt, dass der „Test […] der überprüfbare und jederzeit wiederholbare Nachweis der Korrektheit eines Softwarebausteines relativ zu vorher festgelegten Anforderungen“¹⁰ ist.
Auf die Teststufen Funktions-, Modul- und Komponenten-Test wird an dieser Stelle nicht weiter eingegangen, da diese Tests Teil der Umsetzung hin zu einem funktionierendem System sind und aus Projektmanagementsicht in der Regel eine untergeordnete Rolle spielen. Bei Projekten mit besonderer Sicherheitsrelevanz kann dies allerdings anders aussehen.
Aus Aspekten der Qualitätssicherung können Funktions-, Modul- und Komponenten-Test bei entsprechender Dokumentation ebenfalls eine Rolle spielen. Allerdings ist zu berücksichtigen, dass
der Fokus bei diesen Tests üblicherweise auf der korrekten Umsetzung der IT-Spezifikation und einer möglichst hohen Abdeckung liegt, um spätere Fehler nicht ausgeführten und damit nicht getesteten Codes zu vermeiden.

Die Liefergegenstände Testkonzept und Testfallbeschreibungen sind wie oben beschrieben durch Reviews zu prüfen.

Nach erfolgter Fertigstellung von Modulen, Komponenten und Systemen steht die Testausführung für die jeweilige Teststufe Systemtest, Integrationstest und Abnahmetest an.
Zur Dokumentation ist für die Testdurchführungsphase ein Bericht aufzusetzen, in dem Fortschritt, Probleme und die Problemnachverfolgung (Bug Tracking) dargestellt werden.
Ein Werkzeug zur Problemmeldung und Nachverfolgung muss übergreifend allen Beteiligten zur Verfügung stehen. Probleme sind entsprechend ihrer Kritikalität zu bewerten und zur Steuerung der Fehlerbehebung zu berücksichtigen. Mindestens mit den Testphasen System-, Integrations- und Abnahmetest ist ein Lieferprozess einzuführen. Der Lieferprozess stellt sicher, dass zu jeder Zeit Klarheit über Testausführung und Testgegenstand vorliegt.
Nachdem eine neue Version mit Fehlerkorrekturen zur Prüfung ansteht, müssen viele Testfälle erneut durchgeführt werden, um auszuschließen, das eine Korrektur an anderer Stelle Probleme bereitet. Automatisierte Tests, angelegt als Regressionstest sind das Mittel der Wahl, um dieser Aufgabe gerecht zu werden.

Über die Qualitätssichernden Maßnahmen hinaus, beschäftigt sich Qualitätsmangement mit übergeordneten Qualitätszielen wie

• der Einhaltung von Standards, Auflagen und Vorgaben,
• der kontinuierlichen Verbesserung: PDCA (plan, do, check, act nach Deming), Total Quality Management, Six Sigma
• und Fragen zur Bewertung von Qualität durch Audits, Benchmarking, Kosten-Nutzen-Analyse und weiteren

Statusverfolgung, Besprechungen und Reports

Die Projektdurchführung bedarf einer stetigen Überprüfung des IST Zustandes. Als Prüfbasis dient der geplante SOLL Zustand. Diese Prüfung kann im Wesentlichen auf die Parameter Zeit, Kosten, Umfang und Qualität abgebildet werden. So reduziert sich der hier betrachtete SOLL – IST Vergleich auf die Prüfung des bereits verwendeten Budgets in Bezug auf die erledigten Aufgaben und Ausgaben für Anschaffungen, Lizenzen, Miete, etc.
Passende Metriken und Berechnungen zum Prüfzeitpunt (t) sind

• PV (Planned Value), geplante Kosten für geplante Arbeit (Umfang)
• EV (Earned Value), geplante Kosten für die fertiggestellte Arbeit
• AC (Actual Cost), entstandene Kosten für die fertiggestellte Arbeit

CV (Cost Variance)	CVt = EVt – Act
CPI (Cost Performance Index)	CPIt = EVt / Act
SV (Schedule Variance)	SVt = EVt – PV
SPI (Schedule Performance Index)	SPIt = EVt / PV
ES (Earned Schedule)11
SPIv2 (Schedule Perf. Index)	SPIv2t = ESt / durationt

Je nach Abweichung führen die so gewonnenen Erkenntnisse zu einem Alarmsignal, das analysiert werden muss und mindestens über den Statusbericht kommuniziert wird.
Der Parameter Qualität ist schwieriger zu fassen und bedarf gesonderter Metriken zum Vergleich von SOLL und IST.

Ein ergänzender Baustein zur Statusverfolgung ist das Statusmeeting. Es dient zusätzlich zum kontinuierlich statt findenden Austausch der Projektbeteiligten untereinander, einem mehr formalisiertem und periodisch durchgeführtem Informationsaustausch. Am Statusmeeting sollten mindestens alle Teilprojektleiter, Auftraggeber und Vertreter übergeordneter Funktionen wie Qualitätsmanagement teilnehmen. Bei Bedarf ist der Teilnehmerkreis zu erweitern. Das Ziel ist

• den Projektfortschritt, also den IST-Zustand bezüglich erledigter Aufgaben zu ermitteln,
• neue / alte „offene Punkte“ zu besprechen und Maßnahmen zu beschließen,
• neue / alte „Risiken und Chancen“ zu besprechen und Maßnahmen zu beschließen,
• eine moderierte Plattform für den Informationsaustausch und zur Konfliktbewältigung zu bieten

Das dazu angelegte Protokoll (Meeting Minutes), sowie auch die „offene Punkte Liste“ und das Risikoverzeichnis sollten allen Projektbeteiligten zur Verfügung stehen, damit ein transparenter Informationsfluss auch über die Teilnehmer hinaus gewährleistet wird. Eine entsprechende Ablage wird zum Projektstart eingerichtet.

Eine weitere periodisch durchzuführende Besprechung ist die für den Lenkungsausschuss (SteerCO). Hier präsentiert der Projektleiter den Status bestehend aus Projektfortschritt, Kosten (IST / SOLL), Qualität und Risiken. Weitere Themen sind Entscheidungsvorlagen, so denn Entscheidungen zu treffen sind, als auch Eskalationen zu Problemen, die aus dem Projekt heraus nicht lösbar sind.
Eine Präsentationsvorlage hilft, die Informationen in einem einheitlichen Rahmen darzustellen. Zusätzlich zu einer kurzen textuellen Zusammenfassung, dient eine Ampel der anschaulichen, wenn auch sehr vereinfachten Darstellung. So präsentiert, können die Parameter Zeit, Inhalt, Kosten, Qualität und Risiken unkompliziert zu einem Statusbericht zusammengefasst und vermittelt werden.

Weitere Besprechungen werden je nach Bedarf und teils sehr kurzfristig eingestellt, um schnell auf Veränderungen, Probleme oder sonstige Ereignisse reagieren zu können.
Besprechungen leiten sich häufig auch aus der „offene Punkte Liste“, oder dem Risikoverzeichnis als Reaktion auf das Statusmeeting ab. Für eine Besprechung werden alle notwendigen Teilnehmer, die zur Lösung beitragen können eingeladen.

Alle Besprechungen sollten protokolliert werden. Zusammenhängende Themen verlinkt oder als Thread geführt, ermöglichen einen schnellen Überblick über den aktuellen Sachstand. Einige Projektmanagement-, Team Collaboration, oder auch Blog Werkzeuge bieten hierzu technische Unterstützung.
E-Mail Threads sind weniger hilfreich, da sie nur den Kommunikationspartnern zur Verfügung stehen, oder mit langen Verteilerlisten viel unnötige Informationsfluten erzeugen.

Durchführung „agil“

Die weiteren Schritte nach dem agilen Ansatz beginnen mit der initialen Erstellung eines „Product Backlogs“. Ein „Product Backlog“ beschreibt die für ein Produkt notwendigen Funktionen aus Anwendersicht. Der Begriff Anwender ist hierbei nicht auf natürliche Personen beschränkt.
Ein weit verbreitetes Format¹² zur Beschreibung ist

Als [Anwender] wünsche ich [ein Ziel], damit [ein Grund]

Je nach Abstraktionsgrad beschreibt eine so verfasste Funktionsbeschreibung ein Epos, oder eine User Story. Ein Epos zeichnet sich durch die höhere Abstraktion und die damit verbundene Notwendigkeit der Verfeinerung aus. Aus einem Epos werden weitere Epen und / oder User Stories abgeleitet, so dass der jeweils beschriebene Funktionsumfang kleiner wird. Letztendlich müssen alle Epen in User Stories überführt werden, um so innerhalb einer Iteration (Sprint) umgesetzt werden zu können.
Der Vorteil des agilen Vorgehens liegt jedoch darin, nicht schon im Vorfeld alle erdenklichen Funktionen erfassen und die zu Beginn erstellten nicht komplett auf User Stories runter brechen zu müssen. Die Detaillierung findet von Iteration zu Iteration statt und legt den Fokus so auf die zum aktuellen Zeitpunkt wertvollsten Anforderungen.
Das „Product Backlog“ entwickelt sich also dynamisch über die Laufzeit und nimmt keinesfalls nur ab. Zusätzliche und auch Änderungen an bestehenden Anforderungen können jeder Zeit hinzukommen und werden so Teil des Backlogs, das iterativ abgearbeitet wird.

Der agile Ansatz stützt sich unter anderem darauf, mit der Umsetzung der wertvollsten Funktionen⁷ zu beginnen. Die Auswahl der wertvollsten Funktionen setzt eine entsprechende Bewertung voraus. Dies kann allgemein durch Festlegung einer Priorität erfolgen.
SAFe^® nutzt dazu die Kriterien „Business Value“ und „Story Points“. Ersteres beziffert eine relative Wertigkeit für den Nutzen, das zweite Kriterium einen relativen Aufwand. Relative Werte, wie sie auch in Scrum Verwendung finden, verkürzen die Schätzung erheblich. Die Einschätzung eines Epos oder einer User Story relativ zu den anderen Epen und / oder User Stories ist einfacher zu realisieren, als absolute Werte zu ermitteln.

Iteration

Ist eine Menge umzusetzender User Stories aus dem „Product Backlog“ ausgewählt, beginnt die Umsetzung während einer Iteration (Sprint). Jeder Iterationsabschluss kann als Meilenstein mit überprüfbaren Ergebnissen angesehen werden. Eine Iteration definiert sich bevorzugt durch

• eine fixe Zeitspanne (Timebox, zum Beispiel 2 Wochen)
• in der ein interdisziplinäres Team
• alle erforderlichen Maßnahmen zur Umsetzung der ausgewählten User Stories durchführt

Eine fixe Zeitspanne im Zusammenhang mit einem stabilen interdisziplinären Team bringt mit wachsender Erfahrung Planungssicherheit. Planungssicherheit im Bezug auf die Teamleistung und der davon abhängigen Umsetzung von User Stories (evt. Aufwand in Story Points) pro Iteration.

Für eine Iterationsplanung ist der Aspekt der „Product Backlog“ Pflege zu berücksichtigen. Eine kontinuierliche Aneinanderreihung von Iterationen erfordert eine kontinuierliche Versorgung mit User Stories und damit die Wandlung von Epen in priorisierte User Stories.

Während einer Iteration wird parallel an der Detaillierung der zu bearbeitenden User Stories, der Kodierung, der Testfallentwicklung und Testausführung (Unit- und Modul-Test) gearbeitet. Für die Detaillierung setzt das agile Vorgehen auf intensive Besprechung der jeweiligen User Story. Durch den aktiven Austausch zwischen Product Owner und dem Team, wird so die zugrunde liegende Anforderung präzisiert und wenn notwendig durch Business Analyse und weitere Experten ergänzt. Die interdisziplinäre Team Zusammensetzung ermöglicht währenddessen eine Umfassende Betrachtung aller Aspekte, angefangen mit dem User Interface, über Architektur, Schnittstellen, Implementierungsdetails, Test und Betrieb.
Ergebnisse können die User Story in Form von Gesprächsnotizen ergänzen. Weiter gehende Dokumentation wird durch kommentierten Quelltext, erstellte Testfälle und Testfallbeschreibungen erzielt. Der Aufwand für eine darüber hinaus gehende Dokumentation wird in der Regel vermieden.

Prüfpunkte und Qualitätskontrolle

Durch Zusammenlegung der Phasen, die Fokussierung auf wenige, aber wertvolle Anforderungen und das iterative Vorgehen, erzielt der agile Ansatz eine hohe Flexibilität und die Vermeidung von Missverständnissen durch Interpretation von dritten geschriebener Spezifikationen. Zusätzlich können Ergebnisse am Ende jeder Iteration (Sprint) durch den Kunden oder Product Owner begutachtet und Unstimmigkeiten in Form von Korrekturen ins „Product Backlog“ aufgenommen werden. Die so entstandene Rückkopplungsschleife sorgt für ein zügiges Aufdecken und Beheben von Abweichungen zwischen Implementierung und Anforderung bzw. Erwartungshaltung.

Das agile Vorgehensmodell zwingt durch den iterativen Ansatz und der damit verbundenen Häufigkeit von Funktionslieferungen, zu einer weitreichenden Testautomatisierung.
Jede neue Lieferung ist in die bestehenden Systeme zu integrieren, deren Auswirkungen auf bestehende Funktionen, sowie die neue Funktionalität zu überprüfen. Ein manuelles Testvorgehen würde hier sehr schnell an die Grenzen des machbaren stoßen, da sowohl Ressourcen als auch das Zeitfenster für die Testdurchführung einen engen Rahmen vorgeben.
Soll nicht jede Funktionslieferung sofort im Produktivsystem zur Verfügung stehen, bietet sich die Trennung von „Deployment“ und „Release“ an. Neue Funktionen werden eingespielt und integriert (deployed) aber noch nicht allgemein freigeschaltet (released).
Dies ermöglicht zusätzliche Qualitätsprüfungen im Produktivsystem und eine flexible Funktionssteuerung. Andererseits erfordert solch ein Vorgehen ein weitreichendes Konzept zur Trennung von „Deployment“ und „Release“, bei der nahezu jede Funktion mit einem Schalter versehen werden muss. Bevorzugt einzusetzen, wenn kein explizites Testsystem ähnlich oder identisch dem Produktivsystem zur Verfügung steht.

Statusverfolgung

Der transparente Ansatz der agilen Entwicklungsmethode zeigt zu jedem Zeitpunkt nachvollziehbar den aktuellen Status an. Ein gut gepflegtes „Product Backlog“ offenbart die noch zu bewältigende Arbeit, ein Scrum- oder Kanban-Board die aktuell in Entwicklung befindlichen Funktionen (User Stories) und die Historie der abgeschlossenen Iterationen die bereits zur Verfügung stehende Funktionalität. Die aufgewendete Zeit ergibt sich aus der Anzahl erfolgter Iterationen und die Kosten, bei fixen Teamgrößen, egeben sich entsprechend linear zur Zeit.
Zusätzlich sind Aufwände für die „Product Backlog“ Pflege, Prozess-Verbesserungen oder auch Lernzyklen und das „Refactoring“¹³ zu berücksichtigen, wenn diese nicht während der regulär geplanten Iterationen stattfinden.

Eine Gegenüberstellung
auf einige Aspekte beschränkt

Modell Prozess	plangetrieben	agil
Planung	intensiv	aufs notwendigste beschränkt
Umfang	nach erreichen der Anforderungsklarheit fix, definiert im Anforderungsdokument	Epen und User Stories, eher Abstrakt, offen, die wertvollsten Funktionen werden zu erst umgesetzt
Kosten	geschätzt auf Basis der bekannten Anforderungen	geschätzt, Basis abstrakt, daher größere Unsicherheit, bei festen Teamgrößen linear zur Zeit
Zeit	geplant auf Basis der bekannten Anforderungen, fixer Zeitplan	geschätzt, Basis abstrakt, festes Iterationsraster, Anzahl Iterationen bestimmt den Funktionsumfang
Qualität	Dokumentenprüfung, Tests am Ende der Entwicklung, umfangreiche Dokumentation	Tests mit jeder Iteration, Testautomatisierung notwendig, stetige Überprüfung durch den Kunden oder stellvertretend durch den Product Owner, Dokumentation auf das notwendige beschränkt
Risiken	prinzipiell erhöht, da Änderungen zur kompletten Neuplanung und erheblichem Rework führen können, Ausfall eines Spezialisten kann zu erheblichen Verzögerungen führen	prinzipiell geringer, Änderungen können schnell integriert werden, Rework findet in dem Sinne nicht statt, Änderungen werden als neue Anforderung umgesetzt, interdisziplinäre gut eingespielte Teams können Ausfälle leichter kompensieren
Kunden- zufrieden- heit	abhängig vom Ergebnis, Kunde muss bis zum Schluss auf das Ergebnis warten; stimmen Spezifikation und Implementierung mit den Vorstellungen des Kunden überein?	groß, Kunde kann iterativ prüfen, ob die Entwicklung seinem Anspruch gerecht wird und jederzeit Änderungen einbringen
Reporting	explizites Reporting notwendig, die Entwicklung ist über weite Zeiträume eine Black Box	transparenter Fortschritt durch iterative und prüfbare Funktionsfertigstellung
Besprech- ungen	Status und SteerCo nach festem Raster, zusätzlich nach Bedarf	daily Standup, Ergebnis-Präsentation am Ende jeder Iteration mit Kunden-Feedback, zusätzlich nach Bedarf
Kommuni- kation	schwierig, über Abteilungs- und Bereichsgrenzen hinweg (Stichwort Silodenken)	einfach, Teams werden entsprechend interdisziplinär zusammengesetzt (alle arbeiten und sprechen miteinander)

weitere Aspekte

• Business Case
• On Boarding
• KPIs / Metriken / Messungen / Benchmarks
  • Budget:
    • NPV (Net Present Value, Netto-Kapitalwert) https://de.wikipedia.org/wiki/Kapitalwert
    • IRR (Internal Rate of Return, Interner Zinsfuß) https://de.wikipedia.org/wiki/Interner_Zinsfu%C3%9F
    • PBP (Pay Back Period) https://www.computerwoche.de/a/der-roi-sagt-nur-die-halbe-wahrheit,569697,2
      
  • Leistung (im agilen Umfeld):
    • Anzahl User Stories (Story Points) pro Team (stabile Teamgröße) pro Sprint
    • Anzahl gelieferter Features pro Zeitintervall (über mehrere Teams)
    • Burn Down Chart
  • Qualität
    • Anzahl Änderungen, Auswirkungen und Umfang
    • Anzahl Fehler pro Kritikalität und Entwicklungsaufwand pro Teststufe und in Produktion
    • Anzahl Kommentare pro Kritikalität, pro Dokument und Umfang
    • Anzahl projektspezifischer Risiken pro Kritikalität
    • Anzahl Eskalationen nach Auswirkung und Dauer
    • kontinuierliche Verbesserung in Form der Sprint Retrospective oder allgemein als PDCA (plan, do, check, act)
• Schulung (Vertrieb, Support, Anwender, …)
• Kampagnensteuerung (Werbung für ein neues Produkt, eine neue Dienstleistung, …)
• Überführung in den Betrieb
  • Deploy / Release
  • Bug-Fixing (vor, während und nach der Inbetriebnahme)
  • zurückdrehen der Änderungen
  • Betriebskonzept
• Projektabschluss
  • Lessons Learned
  • Dokumentation / Archivierung
  • kommerzielle Bewertung, Budget-Abschluss
  • Abschluss Qualitätsmanagement
  • Abschlussbericht

…weiter mit Projektplanung

---

1) PM Definition I
https://wirtschaftslexikon.gabler.de/definition/projektmanagement-pm-46130

2) PM Definition II, Project Management Institute: A guide to the project management body of knowledge, PMBOK Guide, 6th Edition, PMI 2017

3)Prof. Dr. Harald Wehnes: Professionelles Projektmanagement in der Praxis
https://wuecampus2.uni-wuerzburg.de/moodle/pluginfile.php/537187/mod_resource/content/1/2015-04-20-2-Projektinitialisierung1x.pdf

4) Project Canvas
https://overthefence.com.de/project-canvas/ und https://de.wikipedia.org/wiki/Project_Canvas

5) Business Canvas
Alexander Osterwalder, Yves Pigneur: Business Model Generation: A Handbook for Visionaries, Game Changers, and Challengers. Wiley, Hoboken 2010

6) Projektauftrag
https://www.kayenta.de/projektmanagement-glossar-lexikon/begriffserklaerung/projektauftrag.html

7) agiles Manifest, die deutsche Übersetzung
https://agilemanifesto.org/iso/de/principles.html

8) SAFe^® – Scaled Agile Framework for Lean Enterprises
https://www.scaledagileframework.com/#

9) Softwaretest, eine Übersicht
https://de.wikipedia.org/wiki/Softwaretest

10) Softwaretest, Definition, Ernst Denert: Software-Engineering. Methodische Projektabwicklung. Springer, Berlin u. a. 1991

11)Earned Schedule and Schedule Performance Index
https://www.controlling-wiki.com/de/index.php/Schedule_Performance_Index

12) Agile Softwareentwicklung, Mike Cohn: Succeeding with Agile. Addison Wesley 2010

13) Refactoring
https://www.it-agile.de/wissen/agiles-engineering/refactoring/