Als CIO können Sie sich dem Thema „agile“ heute nicht entziehen. Ursprünglich als Methodik für die Softwareentwicklung entstanden, wird sie zunehmend auch in klassischen Implementierungsprojekten angewendet. Welche Auswirkungen hat die Nutzung agiler Methoden in klassischen SAP-Projekten? Was müssen Sie als CIO beachten, wenn Sie mit dieser Methodik in ihrer Organisation arbeiten möchten?
Sowohl bei SAP-Projekten als auch bei Sales Force Einführung oder Bankensoftware liefert immer ein Software-Standardprodukt die Basis. Viele der notwendigen Funktionen sind bereits vorhanden, sie werden über Customizing oder andere Zusatzentwicklungen angepasst.
Wie gestalte ich diesen Prozess der individuellen Anpassung bei einer agilen Projektsteuerung?
Wir alle kennen die klassische Wasserfallmethode aus vielen IT-Projekten. Hier versuchen wir zunächst den gesamten Projekt Scope zu definieren und dann bis zur Feinspezifizierung festzulegen. Ist das erledigt, wird der quasi in Stein gemeißelte gesamte Verlauf freigegeben. Anspruch ist fortan, die definierten Schritte 1:1 umzusetzen. Veränderungen und Anpassungen sind lästig und nur in Change Request Boards durchzusetzen. Da Anforderungen und Use Cases zunehmend komplexer werden, erweist sich dieses Vorgehen als zu wenig flexibel.
Die agile Vorgehensweise hat einen komplett anderen Ansatz: hier wird Veränderung zum Bestandteil des Projektmanagements, sie ist integrativer Bestandteil. Wie funktioniert das?
Die Scoping Phase ist auch für agile Projekte substanziell. Zu Beginn müssen die Grundzüge der Lieferobjekte klar definiert werden. Das gemeinsame Verständnis für das zukünftige Produkt ist die Basis der späteren Projektarbeit.
Agile Projektsteuerung geht mit Komplexität anders um. Jahrelang in einer Organisation aufgebautes Wissen kann man nicht mal eben schnell nachlesen, verarbeiten und in eine perfekte Lösung gießen. Mag die Ablösung eines separaten Datev-Systems noch überschaubar gewesen sein, wird es viel komplexer, wenn verschiedene Firmen nach einem Merger in ein komplett neues integriertes System zusammengefügt werden. Auf diese Herausforderung gibt die agile Steuerung gute Antworten.
Im agilen Projekt sind Vertrauen und Transparenz der Schlüssel zum Erfolg.
Alle Businesspartner sind durch den gesamten Verlauf aktiv eingebunden. Die Kundenanforderung insgesamt, aber auch individuelle Anforderungen der Fachabteilungen werden in Use Cases „portioniert.“ Alle Beteiligten beschreiben konkret, welche Aufgaben sie abwickeln und welche Unterstützung sie dazu benötigen.
Die Qualität der so erarbeiteten Use Cases in der Scoping-Phase ist ein erfolgskritischer Faktor. Sie sind der rote Faden, der durch das Projekt leitet:
In der Anfangsphase hilft der Use Case, das Produkt – also das Ergebnis der Projektarbeit – wirklich zu verstehen. Später dient er als Implementierungshilfe beim Customizing. Er kann Anleitung für den Testleitfaden sein und Basis für die Konzipierung der Trainings.
Kritische Anforderungen, bspw. zum Datenschutz, können ergänzt werden. Alles wird funktional definiert. Prozessuale Anforderungen können aufgenommen werden.
Kurzum: Die agile Projektsteuerung modularisiert und clustert Anforderungen. Im Ergebnis entsteht der Leitfaden für ein prototypisches Vorgehen, heruntergebrochen auf einzelne Module oder Cluster: der Golive ist in einzelnen kleinen Schritten möglich.
Der „Big Bang“ nach dem Durchlauf aller Pakete einer „Wasserfall-Planung“ ist damit Vergangenheit. Bei agilen Projekten können wir durch laufende Diskussion der Anforderungen, gemeinsame Priorisierung und kontinuierliche Tests das eigentliche „Endprodukt“ ständig optimieren. Insofern hat diese Vorgehensweise auch eine qualitätssichernde Funktion. Zum festgelegten Termin muss das MVP (Minimum Viable Product) funktionieren. Dann arbeitet das Team inkrementell weiter und setzt nach und nach produktiv.
Ein weiterer Vorteil: wenn erste Funktionen zur Verfügung stehen, entfallen häufig zunächst von den Product Owern geforderte Sonderlösungen. In der Scoping Phase fehlt manchmal das Abstraktionsvermögen, wie Prozesse nach Umsetzung des Projektes wirklich laufen. Es werden Funktionen gefordert, deren – auch finanziellen – Aufwand man sich sparen könnte. Stakeholder lassen sich davon überzeugen, wenn sie verstehen, dass Anpassungen auch im Nachhinein noch möglich sind.
Stichwort Termin: wie plane ich bei Agilität überhaupt einen Termin? Und wie plane ich die Kosten? Ist das abschätzbar?
Lange wurde behauptet, 70 % aller IT Projekte schlagen fehl, reißen Termine und Budget. Die Ursache lag nicht selten in den Wasserfall-Methode, die dazu verführt, an jedem noch so unwichtigen Detail festzuhalten, nur weil es im Plan steht. Genaue, voluminöse Projektpläne, alles auf den Tag genau definiert, erwiesen sich als Makulatur. Die unbedingte Sicherheit war damals und ist heute Illusion.
Wie steht es um die Budgetplanung bei der agilen Projektsteuerung? In der klassischen Wasserfall-Welt glaubten wir an Festpreise und haben damit gelebt, dass diese regelmäßig in Change Requests angepasst wurden.
Die agile Vorgehensweise will den Scope mit den vorhandenen Rahmenbedingungen managen und den Fokus auf das Wichtigste richten. Die Termine sind fix, der Scope kann angepasst werden.
Gleiches gilt natürlich für die Kosten und Ressourcen. Sind diese Dimensionen vereinbart, bleibt gar nichts anderes übrig, als den Scope zu optimieren. Das stellt das klassische Projektmanagement-Dreieck auf den Kopf, führt aber zu guten Ergebnissen.
Der entscheidende Unterschied liegt in der Art, wie das Wichtigste definiert wird. Die Definition liegt nun bei allen Beteiligten, insbesondere bei den Product Ownern. Die Perspektive der Verantwortung dreht sich. Das Ergebnis fällt nicht mehr allein in den IT-Verantwortungsbereich, sondern ist ein gemeinsames Ergebnis. Das ändert die gesamte Zusammenarbeit.
Diese Arbeitsweise erfordert großes Vertrauen in das gesamte Team, Abschied von gewohnten Kontrollmechanismen und vor allem eine andere, eine neue Fehlerkultur.
Wo liegen die Stolperfallen für CIOs?
Der Einkaufsprozess solcher Projekte stellt die bisher üblichen Verfahren auf den Kopf! Das wird oft unterschätzt. Einfach vergleichbare Angebote mit Festpreisen gibt es nicht. Die Einkäufer müssen intensiv und früh eingebunden werden, um zu verstehen, was prototypisches Arbeiten heißt. Oft wird zu Beginn nur ein kleines Volumen für kleine Schritte verhandelt. Das widerstrebt dem Wunsch nach einem Gesamtbudget. Weit verbreitet ist auch die Befürchtung, dass ein einmal beauftragter Dienstleister nach dem ersten Schritt nicht mehr mit sich verhandeln lässt.
Mein Rat: unbedingt im Vorfeld mit allen Beteiligten diskutieren, wie das Arbeiten in anderer Herangehensweise funktioniert. Das finden nicht alle toll. Es ist teilweise unbequem für die Fachabteilungen, weil die Mitarbeiter mehr Zeit investieren müssen und konkret Verantwortung übernehmen. Früher hat die IT an externe Dienstleister delegiert.
Agile bedeutet, in Gesamtverantwortung zu gehen. Das ist ein Paradigmenwechsel, der sich lohnen kann! Der Anfang zu einer schrittweisen Veränderung kann die Umsetzung eines ersten geeigneten Projekts mit der neuen Methodik sein.
Für CIOs ist es wichtig, sorgfältig abzuschätzen, welche der Projektleiter für ein solches Pilotprojekt geeignet sind:
Stakeholder Management, Kommunikation, Führung von Mitarbeitern, Kunden und Dienstleistern … all dies sind Aufgaben, die Projektleiter bisher nicht in dem Umfang übernehmen mussten und oft noch nicht gut beherrschen. Da braucht es Unterstützung und Begleitung.
Ist das Ziel, komplett auf die agile Methodik umzuschalten?
Agiles Projektmanagement sollte auf keinen Fall als neue verbindliche und einzige PM-Methode eingeführt werden. Jeder CIO sollte sich fragen: Ist das geplante Projekt besser agil oder klassisch umzusetzen?
Wenn ich z.B. bei einem Roll-out- oder Releasewechsel-Projekt auf einen erprobten Masterplan zurückgreifen kann, empfehle ich nicht, auf agil umstellen, sondern entlang der erprobten Best Practise die Planung aufsetzen.
Wenn ich jedoch für komplexe und neue Anforderungen eine optimale Lösung erarbeiten möchte, ist agile eine gute Antwort.
Bei der Entwicklung einer komplexen neuen Anforderung stößt unser Gehirn unweigerlich an Kapazitätsgrenzen. Wir können uns häufig nicht vollumfänglich vorstellen, was passiert, wenn verzahnte und übergreifende Gesamtanforderungen miteinander in Verbindung geraten. Hier ist es unglaublich hilfreich, die Messpunkte eines prototypischen Vorgehens zu haben. So lassen sich Scope und Lernkurven sehr gut managen.
Zusammengefasst lautet mein Tipp an CIOs und IT-Führungskräfte:
wenn Sie sich für eine agile Projektsteuerung entscheiden, beginnen Sie mit einem Pilotprojekt, das in besonderer Weise geeignet ist. Nehmen Sie nur Mitarbeiter(innen) in das Team, die diese Arbeitsweise ausprobieren möchten und eine hohe Akzeptanz mitbringen, beziehen Sie die Fachbereiche, Product Owner und den Einkauf von Anbeginn und intensiv mit ein.
Der Erfolg gehört dann allen!
Fragen, Feedback und Kommentare zu diesem Beitrag senden Sie bitte an k.schoettel@acent.de
Katrin Schöttel | 16.05.2018
