Kundenerwartungen, agile Aufwandsschätzungen und negative Skaleneffekte

Viele Softwareprojekte scheitern auch heute noch trotz Agilität in der Softwareentwicklung. Dies führt zu massiv ausufernden Kosten, zu erheblichen zeitlichen Verzögerungen, zu einem anderen Ergebnis oder gar zum Abbruch des gesamten Projektes. Daraus resultierende Rechtsstreite sind keineswegs eine Seltenheit.

Doch warum scheitern IT-Projekte eigentlich? Liegt es an dem Kunden, der seine Ziele und Wünsche nicht klar ausdrücken kann? Oder liegt es an dem Management, welches unzureichend mit den Entwicklern kommuniziert? Oder tragen doch die Entwickler selbst Schuld?

Abbildung 1: gefunden auf https://www.reddit.com/

Toll-Collect – der Pate gescheiterter IT-Projekte

Toll-Collect – das LKW-Maut System in Deutschland – sollte ursprünglich am 31. August 2003 starten. Nach einer 16 monatigen Verspätung wurde es in technisch reduzierter Form in Betrieb genommen [1]. Schätzungsweise 6.9 Milliarden Euro an Mehrkosten verursachte das Mautsystem dem Bund als Auftraggeber. Dies ist das 11.5-fache (!) der ursprünglich vereinbarten Summe [2]. Das deutsche Bundesministerium reichte Klage ein und es folgte ein 14-jähriger Rechtsstreit. Letztendlich stehen dem Bund nun rund 3.2 Milliarden Euro an Rückzahlungen zu [3]. Autsch!

Der Kunde hat keine Ahnung

Eine effektive Kommunikation während der Softwareentwicklung ist für den Projekterfolg von entscheidender Bedeutung. Sollten die Bedürfnisse des Kunden jedoch nicht korrekt erfasst werden, wirkt sich das negativ auf den Gesamterfolg des Projekts aus. Hierbei kann es eine Vielzahl von Missverständnissen zwischen Ihnen und dem Kunden geben:
  • Eine andere Denkweise

Es ist oftmals nicht leicht, mit einem anderen Menschen eine gemeinsame Basis der Verständigung zu finden. Gründe hierfür sind unterschiedliche Hintergründe und Kulturen. Je mehr man mit Menschen kommuniziert, desto einfacher wird es eine gemeinsame Basis zu finden. Jedoch hat man bei kundenspezifischen Softwareentwicklungsprojekten oft keine ausreichende Zeit dafür.

  • Sprachbarriere

Zwar ist es unter Softwareentwicklern üblich, Englisch zu sprechen. Jedoch variiert das Niveau der Sprachkenntnisse je nach Land und Kunde. Man kann ein wahrer Experte auf seinem Gebiet sein und über hervorragende Kommunikationsfähigkeiten verfügen, was jedoch nutzlos sein mag, wenn man Englisch sprechen muss.

  • Qualität der Kommunikation

Ein Kunde sollte seine Vision und Ziele konsequent vermitteln können. Inkonsistente Kommunikation, vermischte Botschaften, unklare Visionen und Ungewissheit führen zu Verwirrung [4].

  • Der Kunde weiß selbst nicht, was er will

Kunden wissen vor Projektbeginn oft ihre eigenen Anforderungen nicht. Sie erkennen erst im Laufe der Produktion ihre eigenen Ansprüche. Deshalb ist das häufige Ausliefern des Produktes an den Kunden (Stichwort Agilität) eine wichtige Methode, um das Feedback des Kunden zu berücksichtigen und umzusetzen [5].

Abbildung 2: Selbst erstellt mit https://imgflip.com/

Management vs. Entwickler

Die Entwickler müssen das Produkt umsetzen. Hierbei gibt es eine grundlegende Umstimmigkeit. IT-Manager verfügen möglicherweise über wenige bis keine Programmierkenntnisse und haben kein Verständnis für moderne Entwicklungsprozesse. Entwicklern hingegen fehlt die Fähigkeit, ihre Arbeit mit wenigen Ressourcen und knappen Fristen zu erläutern. Diese Fehlkommunkation zwischen beiden Parteien haben schwerwiegenden Folgen. Manager sind aufgrund ihrer technischen Unerfahrenheit anfällig für gefährliche Fehlkalkulationen. Unzureichende Ressourcen, verschwendete Zeit und verpasste Fristen sind die Folge [6].

Video 1: Ideal sieht anders aus. Quelle: https://www.youtube.com/watch?v=EOKHrc2wkug&ab_channel=CRAZYDeveloper

Agile Aufwandsschätzungen

Aufwandschätzungen nehmen im Projektmanagement eine zentrale Rolle ein und sind maßgeblich am Projekterfolg (oder Misserfolg) beteiligt [7]. Deshalb sollten die Schätzungen nicht von unqualifizierten Personen (wie dem zuvor erwähnten Management) getroffen werden. Schätzungen sollten nicht auf Termindruck oder Wunschdenken basieren, sondern auf dem zu erwartenden tatsächlichen Aufwand [8]. Dies hilft uns, den Projektfortschritt messen zu können.

Agile Aufwandsschätzungen finden, im Gegensatz zu den klassischen Schätzungen, zu Beginn jeder Planungsperiode statt [9]. Es wird nicht der Aufwand geschätzt, sondern die Komplexität des umzusetzenden Features. Darüber hinaus ist ein wichtiges Merkmal: An der Schätzung beteiligt sich das gesamte Team – die Schätzung findet im Dialog statt. Dafür gibt es verschiedene Methoden wie Planning Poker, welche die Teams anwenden können [10].

Negative Skaleneffekte

Es stellt sich die Frage, was man tun kann, wenn es doch zu Termindruck kommen sollte? Viele Manager möchten Verspätungen vermeiden, indem sie weitere Entwickler dem Team zur Verfügung stellen. Ist ja klar: mehr Arbeitskräfte heißt doch, dass mehr Leute an dem Projekt arbeiten können, oder? Nein! Laut dem „Brooks Law“ von Fred Brooks verringert sich die Arbeitsgeschwindigkeit durch mehr Arbeitskraft sogar. Dies liegt an dem zusätzlichen Koordinations- und Abstimmungsaufwand aufgrund der neuen Mitarbeiter. Sie müssen erst einmal auf den Stand der bestehenden Mitarbeiter gebracht werden, was noch mehr Koordinationsaufwand zur Folge hat [11].

Fazit

Softwareprojekte erfordern ein komplexes Zusammenspiel verschiedener Parteien und Funktionen (Management, Entwickler, Kunde), welches die Planung und Kostenabschätzung zu einer anspruchsvollen Aufgabe macht. Mechanismen, welche die regelmäßige und informative Kommunikation aller Parteien sicherstellen, können die Bewältigung dieser Aufgabe erleichtern.

Quellen

[1] https://dieprojektmanager.com/scheitern-von-it-projekten/
[2] https://www.manager-magazin.de/fotostrecke/kostenexplosion-die-flop-ten-der-deutschen-grossprojekte-fotostrecke-126747.html
[3] https://www.deutschlandfunk.de/maut-streit-bund-und-toll-collect-einigen-sich-100.html
[4] https://intersog.com/blog/communication-problems-in-software-development/
[5] https://www.matthiaskuchem.de/blog/der-kunde-weiss-nicht-was-er-will/
[6] https://www.castsoftware.com/blog/developers-vs-managers-closing-the-communication-gap-with-software-intelligence
[7] https://www.projektmanagementhandbuch.de/handbuch/projektplanung/aufwandsschaetzung-und-schaetzverfahren/
[8] https://link.springer.com/book/10.1007/978-3-8274-2752-6
[9] https://link.springer.com/chapter/10.1007/978-3-662-57699-1_10
[10] https://agile-verwaltung.org/2017/03/16/aus-der-agilen-methodenkiste-aufwand-schaetzen/#:~:text=Ein%20weiterer%20Unterschied%20des%20agilen,Sch%C3%A4tzung%20findet%20im%20Dialog%20statt.
[11] https://project-base.org/projektmanagement-glossar/brooks-law/