Warum SAP BI-Projekte scheitern (Teil 2/2)

In einem früheren Beitrag haben Sie gelernt, welche Probleme beim klassischen Projektmanagement lauern. In diesem Artikel möchte ich Wege aufzeigen, wie wir es besser machen können. Dabei müssen wir das Rad nicht neu erfinden, sondern können uns an agilen Methoden wie Scrum orientieren.

Wir haben festgestellt, dass die klassischen Ansätze wie das magische Dreieck im Falle von SAP BI-Projekten hinterfragt werden müssen. Bei dem klassischen Ansatz gehen wir davon aus, dass der Umfang des Projekts, also der Scope, bekannt und fix bleibt. In der Realität ist es nicht der Fall. Der tatsächliche Umfang ist nur in groben Zügen umrissen und ändert sich zudem ständig.

Daher wählen agile Projektmanagement Methoden wie Scrum einen radikal anderen Ansatz. Es wird anerkannt, dass der Scope sich ständig ändert. Daher werden die Kosten und Zeit fixiert, der Scope dagegen ist variabel. Als Resultat bekommt der Kunde mit den gegebenen Zeit- und Geldressourcen das bestmögliche Produkt.

Dabei wird ein iterativer Ansatz gewählt. Statt einer großen Big Bang-Einführung nach monatelanger Entwicklung, werden bei jeder Iteration mehrere, kleinere, Zwischen-Releases angefertigt. Hierbei wird auch die Zeit beschränkt – nach maximal vier Wochen muss ein funktionierendes Feature geliefert werden. So wird vermieden, dass sich die Entwicklung unendlich in die Länge zieht.

Nach jedem Release werden die entwickelten Funktionalitäten dem Kunden vorgestellt. So erhalten wir unmittelbar Feedback des Kunden. Oft kann sich dieser nur ein Bild von einem Feature machen, wenn er es tatsächlich sieht und anfassen kann. Dabei kommen ihm auch Ideen für neue Funktionen, die die gesamte Anwendung einfacher und benutzerfreundlicher machen.

Durch die häufigen Zwischen-Releases wird also sichergestellt, dass wir nicht an tatsächlichen Anforderungen des Kunden vorbei entwickeln. Es wird früh festgestellt, ob Änderungen der ursprünglichen Anforderungen notwendig sind. Außerdem werden auch generelle Annahmen der Lösung überprüft. So habe ich von Anwendungen gehört, die nach einem halben Jahr Entwicklung als Totalschaden abgeschrieben werden mussten. Bei dem iterativen Vorgehen würden Fehlentwicklungen bereits nach wenigen Wochen auffallen. Durch das frühe Feedback können wir entsprechend früh gegensteuern.

Dabei wird der Kunde in den Entwicklungsprozess einbezogen und übernimmt die Führung. Er hat die Wahl, ob eine bestimmte Funktion beibehalten oder neu entwickelt werden soll. Im letzteren Fall hat er die Wahl, auf andere Funktionen zu verzichten, um den Liefertermin zu halten, oder die Projektdauer, und somit auch die Kosten, zu erhöhen. Am Ende wird jedoch eine maßgeschneiderte Lösung kreiert, die auch wirklich zum Einsatz kommt und nicht von Anwendern boykottiert wird.

Bei dem traditionellen Wasserfall-Ansatz erhält der Kunde in der Regel nicht das, was er erwartet. Er darf das Produkt erst am Ende des Projekts, nach monatelanger Entwicklungs- und Testphase, ausprobieren. Zu diesem Zeitpunkt ist es meistens bereits zu spät, um Änderungen vorzunehmen. Der Kunde ist unzufrieden und die Anwender wissen nichts mit der Lösung anzufangen.

Innerhalb jeder Iteration werden auch sämtliche Tätigkeiten fertiggestellt: Entwicklung, Tests und die Dokumentation. Wir erinnern uns – bei dem Wasserfall-Modell werden die Tests erst am Ende der Entwicklungsphase durchgeführt. Um konzeptionelle Probleme und eventuelle Abweichungen zwischen den Erwartungshaltungen frühzeitig erkennen zu können, müssen wir die Tests jedoch früher durchführen.

So wird im Scrum jedes Feature direkt nach der Entwicklung getestet. Die frühzeitige Erkennung von Fehlern ermöglicht es, konzeptionelle Probleme von Anfang an aus der Welt zu schaffen. Dabei fallen auch eventuelle Korrekturen leichter, da der Entwickler noch die ganzen Details kennt. Die erneute Einarbeitung in den Code, dessen Erstellung schon lange zurückliegt, wird erspart. Außerdem kann auf eine ausufernde Dokumentation verzichtet werden, da die Übergabe an den Tester zeitnah und persönlich erfolgt.

Durch das kontinuierliche Testen ist am Ende des Projekts keine lange Testphase mehr notwendig. Allerdings sollten Sie trotzdem eine kurze Phase für Systemintegrations-, Last- und Performance-Tests einplanen. Insgesamt steigt damit die Qualität der ausgelieferten Software.

Die erfolgreich getesteten Funktionen können als tatsächlich fertig betrachtet werden. Durch begleitende Dokumentation werden technische Schulden vermieden. Der Fortschritt erfolgt also nicht nur zum Schein auf dem Papier und wir erhalten einen deutlich akkurateren Überblick über den Status des Projekts.

Durch kurze Iterationen werden kontinuierliche Meilensteine definiert. Das Team setzt alles daran, das für die nächste Iteration vorgenommene Ziel zu erreichen. Und wenn man sich mal übernommen und das Ziel nicht erreicht hat, ist es auch nicht schlimm. Durch Fehler lernt man. Und die Scrum-Methode zwingt einen quasi maximal alle vier Wochen über seine Fehler zu reflektieren. Somit bleibt der Projektplan stets realistisch und der Todesmarsch am Ende eines Projekts wird vermieden.

Insgesamt steigt auch die Zufriedenheit (und dadurch die Leistung) der Mitarbeiter. Statt stupider Aufgabenempfänger setzt Scrum auf selbstbestimmte, eigenverantwortliche Mitarbeiter. Während im klassischen Projektmanagement der Projektmanager die Aufgaben verteilt, wird in agilen Projekten ein Pool von Aufgaben bereitgestellt. Aus diesem dürfen sich die Mitarbeiter dann selbst bedienen.

So können die Mitarbeiter Ihre Stärken und Vorlieben ausspielen. Dadurch wird die Abarbeitung von Aufgaben beschleunigt und die Motivation erhöht. Außerdem werden mögliche Konflikte bei unliebsamen Aufgaben entschärft. Neben der selbstständigen Verteilung von Aufgaben übernimmt das Team auch die Schätzung der benötigten Zeit. Und wenn die Mitarbeiter die Aufwände selbst schätzen, fühlen Sie sich auch verantwortlich, diese einzuhalten.

Ich denke, das sind alles gewichtige Argumente, um agile Methoden wie Scrum in Betracht zu ziehen. Haben Sie Scrum in Ihren Projekten schon ausprobiert oder denken Sie darüber nach? Teilen Sie Ihre Erfahrungen in den Kommentaren.

Bildquellen:
Photo by bruce mars from Pexels, CC0 License
Photo by rawpixel.com from Pexels, CC0 License