Contact Info

Löberenstrasse 47

Phone: +41 44 586 5018

Web: EFEXCON Homepage

Rufen Sie an: +41 44 586 5018 oder +49 711 518 66 990|info@efexcon.com

Softwareprojekte scheitern häufig

Softwareprojekte scheitern zu häufig und es gibt dafür viele Gründe. Wann man jedoch von Scheitern sprechen muss, ist nicht leicht zu fassen. Es ist völlig normal, dass der “ursprüngliche Plan” durch Erkenntnisse im Projekt gewollt verworfen wird und dass gewollt Änderungen am ursprünglichen Plan umgesetzt werden. Unter Scheitern verstehen wir also, wenn am Ende des Projekts keiner Zufrieden ist.

Damit Ihr Projekt gute Erfolgschancen hat, müssen ein paar Dinge beachtet werden, die leider häufig übersehen oder unterschätzt werden:

Softwareprojekte kämpfen mit unterschiedlicher Projektmotivation

Für Führungskräfte sind Softwareprojekte meist unerwünschte Ausgaben, wenn es sich nicht gerade um Vorhaben handelt, die der eigenen Karriere dienen. Deshalb neigen Führungskräfte dazu, Projekte “klein reden zu wollen”.

Für Projektmitarbeiter sind Softwareprojekte oft Karriere-Chancen und eine Abwechslung zum Alltag, deshalb neigen potentielle Projektmitarbeiter ebenfalls dazu, Projekte zu Beginn “klein zu reden”, um den Start des Projekts nicht zu gefährden.

Eine ideale Symbiose, um Projektvorhaben von Beginn an unrealistisch zu bewerten.

Projekterfahrung

Führungskräfte bewerten Softwareprojekte oft ohne inhaltliche Auseinandersetzung und bewerten die Projekte mit üblichen “Management-Alibi-Fragen”, die in den meisten Entscheidungssituationen erfahrender Manager einwandfrei funktionieren, da das Bauchgefühl meist stimmt.

Für Softwareprojekte schlägt dieser Weg gründlich fehl, da ohne echtes inhaltliches Verständnis für Projektabläufe und -Herausforderungen Bauchgefühle völlig in die Irre leiten. Softwareprojekte sind VIEL komplexer als Entscheider das annehmen, denn der vermutete Projektumfang “Entwicklung und Anpassung” macht meist kaum mehr als 15% des Gesamtprojekts aus.

Die restlichen 85% sind dann Management-Blindflug.

Das wäre nicht schlimm, wenn sich das Management auf seine Projektleiter und Software-Experten verlassen würde oder das könnte, denn hier wäre ja das natürliche Korrektiv zum Blindflug.

Da selten genügend erfahrene Projektmanager an Bord von Softwareprojekten sind, ebenso wenig wie erfahrende Software- und Integrations-Experten, findet die erforderliche Korrektur leider nur selten, wenn überhaupt statt. Sei es, weil keine Führungskraft die Diskussion mit den Fachexperten führen will .. oder weil diese die Diskussion mit den Führungskräften nicht führen wollen.

Schließlich ist es mehr als unpopulär und nicht konsequent karrierefördernd, wenn man seine Vorgesetzten mit unangenehmen Themen belästigt.

Kommunikationskultur

Dem Unkenrufer dieses Artikels zum Trotz gibt es Softwareprojekte, bei denen der Start perfekt verläuft. Zwischen Start und erfolgreichem Einsatz verbleibt jedoch unglücklicherweise eine kurze Phase, in der Veränderungen und unerwartete Erkenntnisse den Projektfrieden trüben können.

Beliebt sind dabei nicht funktionierende Eskalationsstufen. Dazu gibt es viele Möglichkeiten, ein paar der beliebten Ursachen sollen hier erwähnt werden:

  • geänderte Anforderungen werden berücksichtigt, aber nicht als Änderung registriert
  • unklare Anforderungen werden ungeklärt umgesetzt und nicht berichtet
  • berichtete Probleme werden in der Eskalation “getarnt”
  • unerwartete Probleme werden nicht berichtet, sondern ohne Meldung “gefixed”

In allen Fällen ist das Ergebnis der sukzessive Kontrollverlust im Projekt, da die vorliegenden Informationen sich sukzessive von den Realitäten entfernen, ohne dass das Management “Wind davon bekommt”.

Eine falsch verstandene Kommunikationskultur des “ich erledige das erst mal selber, bevor ich was sage” ist ein regelmäßiger Projekt-Killer.

Vergessene oder übersehene Projektphasen

Wenn wir übliche Projektpläne ansehen, dann finden wir im besten Fall die Phasen “Vorklärung” bis zur “Abnahme”. Im Kopf der Entscheider und Projekt-Teams ist also fest verankert, dass die Aufgabe darin besteht, ein funktionierendes Softwareprodukt zu erzeugen.

Da ist aber leider gerade einmal die halbe Wahrheit. Software-Projekte müssen auch eingeführt werden und erst wenn die Software tatsächlich den geplanten Zweck im Fachbereich erfüllt, sollte dann auch ein echter Abschluss des Projekts erreicht sein. Aber auch das reicht nicht für 100%.

Es gibt vermutlich kaum Softwareprojekte, die nicht für “zukünftige Prozessabläufe” entwickelt werden. Mit Softwareprojekten werden nicht nur zusätzlich Organisations-Projekte fällig, um die Voraussetzungen für den erfolgreichen Einsatz der zukünftigen Software zu schaffen.

Es müssen in aller Regel auch Schnittstellen und Prozesse mit umliegenden Systemen, mit Systembetreibern und ggf. auch mit neuen Datenlieferanten geführt werden, um den späteren Betrieb und das Veränderungsmanagement von Projekten im produktiven Betrieb beherrschbar zu machen.

Deshalb lohnt es sich, das eigene Projektphasenmodell mal genauer anzusehen, um evtl. Lücken zu schließen.

Sparen am falschen Fleck

Mit allem Verständnis für Budget-Engpässe und Spar-Versuche möchte ich am Ende dieses Posts noch eine Lanze für “richtiges Sparen” brechen.

Aus eigener Erfahrung bin ich seit fast 30 Jahren dadurch genervt, dass Einkäufer und Controller mit uns über Preise verhandeln wollen. Oder von Diskussionen mit Entscheidern, die Projektphasen oder Tätigkeiten in Softwareprojekt-Angeboten streichen oder kürzen wollen, um “einfach mal was optimiert” zu haben.

Entscheidend in Projekten sind nicht 5% Discount vom Preis pro Stunde oder 3% Discount vom Lizenzpreis. Diese Diskussionen führen zu schlechter Stimmung, nicht zu Kosteneinsparungen. Es bringt auch nichts, sinnvolle Tätigkeiten zu streichen oder Phasen einfach wegzulassen.

Es bringt was, am richtigen Fleck zu sparen und Projekte wirklich erfolgreich ins Ziel zu bringen. In dem man z.B. mit Software-Experten über den tatsächlichen Wirkungsgrad von Software-Unterstützung in einem Prozess spricht. In dem man Prozessbarrieren beseitigt und Prozesse clever verkürzt und Aufgaben neu verteilt., In dem man Software-Architekturen clever gestaltet, um Integration und Veränderung kostengünstiger zu ermöglichen.

Sparen Sie einfach, indem Sie wirkungsarme Projekte gar nicht erst starten. Und wirksame Projekte dafür durch kluges Management und gute Software erfolgreich ins Ziel bringen.

r.gros
CEO at EFEXCON AG
Ich schreibe über Customer Relationship Management (CRM), Customer Service, Customer Journey, Inbound Marketing, Content Marketing, Social Media, Software, SharePoint, Office 365, über Projekterfahrungen, Projekt-Turnarounds und Startups.
Ansonsten bin ich Trailrunner, Mountainbiker, Zuhörer, Erzähler, Startup-Macher und CEO
2016-10-20T21:27:26+00:00