Es gibt mehrere Szenarien mit denen Unternehmen und deren IT-Leiter mit einem bereits gescheiterten Software-Projekt auf uns zukommen. In vielen Fällen werden diese jedoch unter den Tisch gekehrt bzw. in ein Prototypen-Projekt umbenannt. Eine weitere Variante ist, man definiert die Ziele des gescheiterten Softwareprojekts einfach neu. Also man passt die Anforderungen im Nachhinein so an, dass das Projekt als entsprechend erfolgreiches den Stakeholder (Geldgebern) präsentiert werden kann.
Beide Varianten helfen im Idealfall das Gesicht zu wahren, jedoch dient nicht der eigentlichen Problemlösung.
Am individuellen Softwareentwickler liegt es in der Regel nicht. Ich habe in mehr als 20 Jahren Berufserfahrung noch nie erlebt, dass ein einzelner Softwareentwickler ein großes Projekt zu Fall bringt.
Die Aufgaben sind im Regelfall auf sehr viele Schultern verteilt.
Es 5 Faktoren in zusammenspielen:
- kein einheitliches Requirements Engineering
- keine Zeit für einen MVP
- man unnötige im Unternehmen bereits vorhandene und eingeschleifte Prozesse unbedingt in die neue Softwareentwicklung mit aufnehmen, auch wenn diese keinen Sinn ergeben.
- keine Entflechtung bestehender Fleckenteppiche von Softwarelösungen und Datensilos
- kein Echo Chamber aufgrund kompletten Outsourcings der IT und Softwareentwicklung, es gibt in manchen Unternehmensstrukturen keine zentralen IT-Leiter mehr die aufpassen, dass die Projekte auch im Unternehmen aktuell gebraucht werden und nach wie vor Sinn ergeben.
✅ Flexibel und lösungsorientiert Projekteinteilung nach Ihren Wünschen
Achtung ein Hinweis!
Vielleicht kann man bestehende Prozesse verschlanken?
Gründe warum Software Projekte scheitern
Häufig kommen dann größere KMU’s in den absurden Kreislauf, das externe Berater, Consultant eingekauft werden, da niemand mehr im
Unternehmen ist der die Pamphlete an Anforderungskatalogen versteht. Diese Berater sind zwar objektiv, kennen aber nicht das ganze Unternehmen und sind häufig aus Kostengründen nur für einen kurzen Zeitraum mit involviert. Diese häufig sehr zwar sehr objektiven IT-Berater hinterlassen dann gerne auch sehr gute und seröse jedoch sehr umfassende Dokumente (Strategiepapiere), die im Unternehmen dann wieder keiner wirklich versteht. Deswegen verlässt man sich dann gerne auf Entscheider Ebene auf die Management Summaries, die wiederum zwar sehr kurz und verständlich sind aber im Regelfall viel zu oberflächlich. Im schlimmsten Fall werden dann strategische IT-Projekte entschieden aufgrund von Zusammenfassungen, die nicht in Gänze verstanden werden. Dies gilt es zu vermeiden. Eine sehr gefährliche Situation denn an dieser Stelle können Unternehmen sehr viel Geld verbrennen und Ressourcen versenken.