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

Jeder von uns hat wohl schon ein Horror-Projekt erlebt. Eins, bei dem so ziemlich alles schief gelaufen ist: die Kosten sprengten jeden Rahmen, die Features waren voller Bugs und die Abgabe erfolgte viel zu spät. Am Ende waren alle Beteiligten unzufrieden: der Auftraggeber, die Mitarbeiter und natürlich auch der Projektleiter.

Die systemimmanenten Ursachen für diese Unzufriedenheit liegen auch in der klassischen Definition des Projekterfolgs. Das magische Dreieck des Projektmanagements beschreibt die Parameter Scope (Umfang), Kosten und Zeit. Je näher wir am Ende der ursprünglichen Planung kommen, desto erfolgreicher war das Projekt.

Allerdings birgt der Ansatz des Wasserfall-Ansatzes ein großes Problem. So wird vorausgesetzt, dass der Scope, also der tatsächliche Umfang, am Anfang des Projekts bekannt und festgesetzt ist. Um den Umfang zu definieren, werden zunächst die Anforderungen detailliert aufgenommen und in Lastenheften niedergeschrieben. Trotzdem sind die Anforderungen nie wirklich komplett. Hierfür gibt es viele Ursachen. 

Der Fachbereich kann sich auch schlichtweg nicht vorstellen, wie eine Lösung am Ende aussehen soll. Wird nun das User Interface nicht klar genug definiert, kommt am Ende des Projekts das berühmte „Das habe ich mir aber anders vorgestellt“.

So ist der Fachbereich erst einmal überfordert, seine Wünsche in Anforderungen zu formulieren und kritische Funktionalitäten überhaupt nicht erwähnt. Andererseits werden viele optionale „nice-to-have“ Funktionalitäten ins Lastenheft gequetscht. Denn der Fachbereich hat ja im klassischen Wasserfall nur eine Möglichkeit, seine Wünsche zu äußern. So packt er möglichst viel rein. Oft sind die Anforderungen auch nur schwammig definiert.

Wenn nun der Autor des Lastenhefts nicht die notwendigen Kompetenzen besitzt, nicht nachhakt und die Anforderungen nicht hinterfragt, ist das Desaster komplett. Oft werden die Anforderungen auch von einer Management-Beratung erstellt und die IT-Beratung soll es nun implementieren. Dabei kann man die Anforderungen eigentlich in die Tonne treten und neu anfangen. Ich habe schon ein Lastenheft von einer renommierten Management-Beratung in den Händen gehabt, in dem wörtlich „Dieses Problem muss irgendwie gelöst werden“ stand.

Oft möchte auch der Kunde die Erstellung eines ausführlichen Lastenhefts und die damit verbundene Phase für die Aufnahme der Anforderungen nicht bezahlen. So wird angefangen, einfach mal blind ins Blaue hinein zu entwickelt. Wer aber nicht weiß, wohin er will, der darf sich nicht wundern, wenn er ganz woanders ankommt. Das wusste man schon zu Mark Twains Zeiten.

Außerdem ist die Softwareentwicklung schlichtweg zu komplex, um von vornherein alle Eventualitäten bis ins letzte Detail vorauszuschauen. Viele Fragen fallen einem erst während der Implementierung auf. Wie soll sich die Software verhalten, wenn der Fall X oder Y eintritt? Die Antworten auf diese Fragen bringen ggf. neue Anforderungen ans Tageslicht.

Sind die Anforderungen erstmal abgesteckt, werden die Kosten und der Zeitbedarf geschätzt. Davon abgesehen, dass es immer nur eine Schätzung ist, tuen wir immer so, als ob das Budget in Stein gemeißelt ist. In der Realität weichen die tatsächlichen Aufwände jedoch meistens nach oben ab. Anschließend werden detaillierte Projektpläne erstellt, die eigentlich nach dem ersten Tag des Projekts schon obsolet sind. Wenn nun während der Entwicklung Änderungen hinzukommen, sind Streitigkeiten vorprogrammiert. Denn dann sind entweder mehr Projektmitglieder notwendig, um den Liefertermin zu halten, oder der Termin muss verschoben mehr.

Der Projektleiter ist also angehalten, alle Änderungen erst einmal abzublocken und Nein zu sagen. „Nein, das ist ein Change Request“, „Nein, das war nicht so spezifiziert“ und so weiter. Bei diesen Grabenkämpfen werden die zähsten Projektleiter aufgerieben und die Beziehung zum Kunden leidet.

Hat aber der Projektleiter nicht die nötige Durchsetzungskraft, kommt es zum gefürchteten Scope Creep. Der Umfang wächst immer mehr, während das Budget und der Abgabetermin gleich bleiben. Die mangelhafte Planung wird auf dem Rücken der Entwickler ausgetragen. Es stellt sich jedoch heraus, dass schlaflose Nächte während des Death Marchs (Todesmarsch) nicht gerade zur Aufhellung der Stimmung im Projektteam beitragen. Die Projektmitglieder resignieren schnell – „das schaffen wir sowieso nicht“. Darüber hinaus schleichen sich durch die Überarbeitung vermehrt Fehler ein.

Unter Zeitdruck und mit endlosen Überstunden werden einige Funktionalitäten doch fertiggestellt. Viele Features werden jedoch ersatzlos gestrichen, um den (ggf. mehrmals) verschobenen Abgabetermin halten zu können. Entwicklertests und Dokumentation müssen auch auf später verschoben werden, denn das Projekt muss schnell in die Stabilisierungsphase. Aber hey, aufgeschoben ist nicht aufgehoben, richtig? Schließlich wird ja in der Testphase ausgiebig getestet. Da über viele Monate hinweg entwickelt wurde, gibt es auch viel zu testen, was eine lange Testphase mit vielen Testern notwendig macht.

Und tatsächlich, bei den ersten Tests stellt sich heraus, dass die unter Zeitdruck entwickelten Features nicht funktionieren. Die Entwicklung beginnt zu flicken. Hier und da werden Krücken gebaut, damit man die Software doch irgendwie zum Laufen bekommt. Dass solche Lösungen in der Zukunft die Kosten der Wartung vervielfachen, wird entweder nicht bedacht oder stillschweigend in Kauf genommen.

Es stellt sich schnell heraus, dass einige der bereits als fertig bezeichneten Funktionalitäten noch erhebliche Mängel aufweisen. Der Projektfortschritt existierte die ganze Zeit nur auf dem Papier.

Bei jedem eingetragenen Fehler wird gestritten. Die Entwickler argumentieren, dass sich alles wie spezifiziert verhält. Die Tester sind anderer Meinung. Wegen Zeitdruck hat der Entwickler die Spezifikation so implementiert, wie er sie versteht. Nachfragen würden ihn nur von seiner Arbeit abhalten und den Projektplan in Gefahr bringen. Häufig deckt sich aber das Verständnis des Entwicklers nicht mit dem des Verfassers des Lastenheftes. Und erst recht nicht mit den tatsächlichen Wünschen des Kunden.

Leider hat auch bei der Aufnahme der Anforderungen oft niemand hinterfragt, ob die jeweilige Spezifikation wirklich sinnvoll ist. Unvermeidliche Missverständnisse kommen nun, viele Monate später, ans Tageslicht.

Leider stellen sich einige der gemeldeten Fehler als konzeptionelle Probleme heraus. Für eine saubere Lösung ist es leider viel zu spät, da der bereits verschobene Abgabetermin sonst nicht zu halten wäre. Also werden weitere, größere, Krücken gebaut, damit die einzelnen Komponenten zusammen funktionieren.

Solche Workarounds und Fehlerbehebung nehmen aber unnötig viel Zeit in Anspruch. Die Entwickler haben die jeweilige Funktionalität schon vor mehreren Monaten abgeschlossen und müssen sich nun wieder in die Details einarbeiten. Leider gibt es auch keine Dokumentation, die dabei helfen könnte. Diese wurde wegen Zeitdruck auf „später“ verschoben.

Am Ende gleicht die ausgelieferte Anwendung einem Flickenteppich und der Kunde ist auch noch unzufrieden. Er musste auf viele Features verzichten und die ausgelieferten Features funktionieren nicht so, wie er es sich vorgestellt hat.

Und auch die Projektmitarbeiter sind völlig am Boden und dem Burn Out nahe. Sie leisten unmenschliche Stunden ab und haben dabei nur sehr wenige Gestaltungsmöglichkeiten. Meist wird von dem Projektleiter vorgegeben, welche Aufgaben der einzelne Entwickler erledigen muss und wie viel Zeit er dafür hat. Dadurch kommt es zur natürlichen Abwehrhaltung – „In fünf Tagen schaffe ich das niemals!“. Da die Schätzung auch nicht vom Entwickler selbst stammt, fühlt er sich auch nicht verpflichtet, den Zeitplan einzuhalten. Wenn man jedoch den Entwickler selbst gefragt hätte, hätte er oft weniger geschätzt. Und würde auch alles tun, um sein Versprechen zu halten.

In der Kapazitätsplanung werden auch die Aufgaben teilweise willkürlich an die Mitarbeiter verteilt. Gerade wenn das Projektteam aus verschiedenen Abteilungen zusammengestellt wird, kennt der Projektleiter die Stärken und Vorlieben einzelner einfach noch nicht. Während jedoch eine Aufgabe für den einen ein Gräuel ist, übernimmt ein anderer sie gerne.

Welche Erkenntnisse können wir nun aus den beschriebenen Problemen gewinnen? Im klassischen Projektmanagement werden die Probleme viel zu spät entdeckt. Wenn wir es schafften, Probleme früher sichtbar zu machen, können wir besser gegensteuern. Denn die Probleme werden immer auftreten.

Dabei bringt es nichts, seine Zeit mit der Erstellung von unnötigen Dokumenten und detaillierten Projektplänen zu verschwenden, die lediglich der Befriedigung irgendwelcher Prozesse dienen. Direkte Kommunikation bringt immer mehr Klarheit und vermeidet Frust.

Schließlich müssen wir auch die Projektmitglieder befähigen, sich von stupiden Aufgabenempfängern zu selbstständigen Projektteilnehmer zu entwickeln, die motiviert sind, das Projektziel zu erreichen.

Im nächsten Beitrag möchte ich Ihnen einige Wege aufzeigen, wie Sie den Problemen mit Methoden wie zum Beispiel durch agiles Projektmanagement für SAP BI-Projekte entgegen treten können.

Bildquellen:

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