Im Vergleich zu industriellen Produktionsprozessen, bei denen jeder Arbeitsschritt in Dauer und Ressourcenbedarf exakt eingeplant werden kann, ist eine vergleichbar präzise Planung bei industriellen Software Engineering Projekten in der Regel nicht möglich. Insbesondere lassen sich sowohl die genauen Kosten, der konkrete Funktionsumfang und das technische Design eines Softwaresystems erst am Ende eines Projektes genau bestimmen.
Wesentliche Einflussfaktoren für Projektrisiken von Softwareprojekten sind die Komplexität und die Immaterialität von Softwaresystemen. Darüber hinaus ist Softwareentwicklung ein stark erkenntnisgetriebener Prozess.
Beispiel:
Industrielle Softwareprojekte werden oft mit übergeordnetem fachlichen Ziel gestartet, z. B. "Einführung
eines Self-Care Portals für Kunden einer Versicherung". Welche konkreten Funktionen das System jedoch im Einzelnen erfüllen soll,
welche Bildschirmdialoge benötigt werden und auf welche Weise andere Softwaresysteme integriert werden können, lässt sich zu
Beginn des Projekts noch nicht genau spezifizieren.
Ein Merkmal des Software Engineerings ist es, dass Anforderungen an das zu erstellende System erst im Verlauf des Softwareprozesses erkannt werden. Allerdings bilden die Anforderungen an das System den Ausgangspunkt für alle weiteren Aktivitäten innerhalb eines Softwareprojekts. In der Regel werden relevante Anforderungen von Anwendern und Kunden erst erkannt, nachdem sie eine erste Version des Systems gesehen haben.
Ein Software Engineer steht nun vor folgendem Dilemma: Fängt man an, ein System zu entwickeln, zu dem die Anforderungen nicht klar sind, geht man ein hohes Risiko ein, dass die erstellte Anwendung nicht die gewünschten Funktionen umsetzt. Ein Anwender kann jedoch zu Beginn oft nicht genau sagen, welche Funktionen benötigt werden. Denn er erkennt wichtige und relevante Funktionen oft erst dann, wenn er eine erste Version des Systems ausprobieren kann.
Zusammenspiel zwischen erkannten Anforderungen und dem Softwareprozess:
Das Dilemma der Erkenntnisgetriebenheit wird in der Praxis noch dadurch verstärkt, dass es in der Regel nicht nur einen Beteiligten (einen sogenannten Stakeholder) gibt, der Anforderungen an das System liefert, sondern viele Stakeholder, oft verteilt über mehrere Organisationseinheiten. Das hat wiederum zur Folge, dass nicht nur ein Stakeholder während des Softwareprozesses weitere Anforderungen erkennt, sondern eben viele.
Neben den Stakeholdern können während eines Softwareprojektes auch neue rechtliche Vorgaben, technologische Entwicklungen oder die Marktsituation maßgeblichen Einfluss auf die Anforderungen an Softwaresystemen nehmen. Das führt direkt zu einer typischen Ursache für gescheiterte Softwareprojekte: sich ändernde und widersprechende Anforderungen.
Neben branchenübergreifender Standardsoftware, wie zum Beispiel Software für Textverarbeitung, Tabellenkalkulation, E-Mail, Kalender oder Bildverwaltung, gibt es auch branchenspezifische Softwaresysteme, die nur für ganz bestimmte Industriezweige relevant sind, wie zum Beispiel eclipse für Softwareentwicklung oder AutoCAD für Architekten. Darüber hinaus gibt es auch hoch spezialisierte Individualsoftware, die gezielt für bestimmte Aktivitäten der Wertschöpfungskette von einzelnen Unternehmen konzipiert und entwickelt wird. Insbesondere für branchen- oder unternehmensspezifische Software ist fehlendes Fachwissen auf der Seite der Softwareentwickler eine weitere Ursache für gescheiterte Projekte.
Das Entwicklungsteam muss die von den Stakeholdern formulierten Anforderungen fachlich verstehen, damit es ein benutzbares Softwaresystem ausliefern kann. Weil industrielle Softwaresysteme der heutigen Zeit in der Regel über eine Vielzahl technischer Schnittstellen in komplexe Anwendungslandschaften eingebunden sind, muss das Entwicklungsteam außerdem in der Lage sein, die fachlichen Zusammenhänge über Systemgrenzen hinweg zu erkennen. Außerdem kann ein Projektteam mit Fachwissen über den Anwendungsbereich sicherer mit unklaren Anforderungen zurechtkommen, da es Lücken oder Fehler in den Anforderungen selbstständig identifizieren und den Stakeholdern zielgerichtet Lösungen anbieten kann.
Falls in Softwareprojekten ein zu starker Fokus auf die eingesetzte Technologie gelegt wird und darüber hinaus der Nutzen für die Anwender in den Hintergrund tritt, spricht man von Technologiezentriertheit. Softwareprojekte, in denen Fragen und Probleme der Technologie in den Vordergrund gestellt werden, bringen ebenfalls ein hohes Risiko für das Scheitern des Projekts mit sich. Oft ist es für die Entwickler spannender und bequemer, sich über Technikthemen zu unterhalten und sich auf den Einsatz neuester Technologien zu konzentrieren, als sich aktiv mit den fachlichen Problemen der Anwender auseinanderzusetzen. Als Resultat wird dann ein System ausgeliefert, das womöglich alle neuen Technologietrends aufgegriffen hat, jedoch am tatsächlichen Bedarf der Anwender vorbeiprogrammiert wurde.
Abschließend soll an dieser Stelle noch die mangelnde Kommunikation beziehungsweise die mangelnde Koordination der Beteiligten als typische Ursache für gescheiterte Projekte genannt werden. In Entwicklungsprojekten für industrielle Softwaresysteme sind in der Regel verschiedene Abteilungen beteiligt, zum Beispiel Marketing, Vertrieb, Revision, IT-Anwendungsentwicklung, IT-Betrieb, externe Berater, Personalrat und Rechtsabteilung. Jede Organisationseinheit hat dabei eigene Vorstellungen und Zielsetzungen in Bezug auf das Softwaresystem. Unter Umständen gibt es innerhalb einzelner Abteilungen Unterschiede. Diese Diversität wird häufig um nicht klar abgegrenzte Verantwortungsbereiche und mangelnde Fachkompetenz ergänzt.
Ein vernachlässigtes Kommunikationsmanagement führt in solchen Softwareprojekten schnell zu unterschiedlichen Zielvorstellungen, dem Nicht-Treffen bzw. Verschieben von wichtigen Entscheidungen und dem Austragen von persönlichen Konflikten. Damit steigt ebenfalls das Projektrisiko.