Das Scheitern von Softwareprojekten ist oft schon im Vertrag angelegt

ResearchBlogging.orgSeit vielen Jahren stellen Studien fest, dass der Anteil der Softwareprojekte, die letztlich als gescheitert gelten, auf einem hohen Niveau konstant bleibt, so etwa der jährliche Chaos-Report der Standish Group. Auch wenn dieser Report immer wieder kritisch kommentiert wird, kommen andere Forscher weltweit zu ähnlichen Ergebnissen. Das Softwareprojekte aller Größenordnungen und unabhängig von der Erfahrung der beteiligten Unternehmen seit Jahrzehnten immer wieder in Schwierigkeiten kommen, überrascht umso mehr, wenn man bedenkt, wie viel Aufwand in Forschungen und Verbesserungen zum Softwareprojektmanagement und zum Software-Engineering gesteckt wird.

Zeit, die Blickrichtung zu wechseln. Wir sollten, gerade, wenn das Softwareprojekt durch ein externes Softwarehaus realisiert wird, die Vertragsbeziehung zwischen dem Kunden und dem Softwarehersteller in den Blick nehmen. Ist das Scheitern des Projektes vielleicht oft schon in der Vertragsbeziehung angelegt? Werden Pflichten und Anreize möglicherweise schon dort so festgeschrieben, dass das Projekt in Gefahr geraten muss, sobald auch nur „Kleinigkeiten“ schief gehen? Das ist die Frage, der das Forschungsprojekt von Cornelia Gaebert nachgeht. Die ersten Ergebnisse wurden von ihr im August auf einer Internationalen Konferenz in Wien vorgestellt. Die Resultate gelten prinzipiell auch für Projekte, die innerhalb des Unternehmens durchgeführt werden, wenn die Verantwortlichkeiten und die zu tragenden Kosten durch klare Regeln (einen Vertrag) zwischen den Abteilungen festgelegt sind.

Anforderungslücken in der Softwarespezifikation

Anforderungslücken, also die unvollständige Spezifikation und die Änderung von Anforderungen, werden von allen Studien als wichtige Gründe des Scheiterns von Softwareprojekten angesehen. Deshalb wird auch viel Kraft in die Verbesserung der Methoden des Requirement Engineering investiert. Es ist aber plausibel, dass Anforderungen niemals zu Projektbeginn vollständig spezifiziert werden können. Deshalb muss man sich fragen, wie mit Anforderungslücken während des Projekts umgegangen wird. Wer ist für das Schließen der Lücken verantwortlich? Wer muss den Aufwand leisten?

Es sagt sich leicht hin, dass am besten beide Partner, Kunde und Softwarehersteller, diesen Aufwand am besten gemeinsam tragen. In der Praxis müssen beide Seiten Kosten sparen, insbesondere, wenn ein Festpreis für die Erstellung sdes Systems vereinbart wurde, und das Schließen von Anforderungslücken verursacht kosten, Experten werden benötigt, die oft keine Zeit haben, Informationen müssen beschafft werden. Um Kosten zu sparen, versuchen oft beide Seiten, den eigenen Aufwand zu reduzieren und die Arbeit den anderen Partner machen zu lassen.

Das Dilemma zwischen Softwarehersteller und Kunden

Man kann zeigen, dass die Projektpartner sich in einer so genannten Dilemmasituation befinden, die in der ökonomischen Forschung als Gefangenendilemma bekannt ist. Im Ergebnis findet im Projekt keine Kooperation zwischen den Parteien statt – obwohl Kooperation zum besten Ergebnis für beide führen würde. Am Ende stehen beide Seiten mit leeren Händen da, weil das Projekt scheitert.

Die Forschung zum Gefangenendilemma kann aber auch den Ausweg weisen. Sie können Wege aufzeigen, wie der Vertrag zu gestalten ist, damit beide Seiten zur Kooperation bereit sind. Das ist natürlich besonders schwierig, wenn es sich um einen autoritären Festpreisvertrag handelt, den der Kunde dominiert. Aber auch dann gibt es Wege, die Beistellungen des Kunden so zu bestimmen und die Anreize so zu setzen, dass Kooperation nicht ausschließlich auf dem guten Willen der Beteiligten basiert, sondern auf ökonomischen Nutzenskalkülen. Dann legt der Vertrag den Grundstein für den Projekterfolg, und ist nicht länger ein Risiko.

Cornelia Gaebert (2014). Dilemma Structures between Contracting Parties in Software Development Projects Proceedings of the 9th International Conference on Software Engineering and Applications DOI: 10.5220/0004996405390548

Den kompletten Text des Forschungsartikels als PDF finden Sie hier.