Neben der unklaren Vertragstypologie (Teil II dieses Blogs) sind es insbesondere die unklare Projektstruktur und Unklarheit bei der Erstellung und dem Inhalt des Sollzustandes (also dem Dokument, das gemeinhin Pflichtenheft, Lastenheft, etc. genannt wird), die zu einem Scheitern des Projektes führen können.
Im Einzelnen werden hier aufgeführt
– fehlende Projektstruktur
– ein fehlendes unvollständiges oder unklares Pflichtenheft
– fehlender Prozess zur Erstellung des Pflichtenheftes, fehlende Verantwortlichkeit für den Inhalt des Pflichtenheftes
– im Pflichtenheft fehlen Abnahmeprozesse und Abnahmekriterien
– im Pflichtenheft fehlen Mitwirkungspflichten zur Erstellung der Software und zur Mitwirkung bei der Erstellung des Pflichtenhefts selbst
– die Change Management-Prozesse sind meistens nicht mit der Projektmethodik kombiniert
– der Prozess selbst ist mangelhaft dokumentiert.
In der Computerwoche (Verspohl 38/11) wird unter anderem angeführt, dass missverständliche Projektaufträge eine Kernursache für das Scheitern von Projekten seien.
Als Informatiker muss man sich zunächst einmal daran gewöhnen, dass der Jargon des BGH von dem der IT abweicht. Man hat ein wenig das Gefühl, dass die Richter des BGH, die sich nun mit dem IT-Recht befasst hatten, Ausleihen im Baurecht gemacht haben, ohne auf die besondere Ausprägung des IT-Rechts Rücksicht zu nehmen. Jedenfalls ist das, was der ITler Lastenheft nennt, das, was der BGH als Pflichtenheft bezeichnet. Darauf ist stets hinzuweisen, wenn mit Gerichten kommuniziert wird. Im Folgenden werde ich gleichwohl dann vom Pflichtenheft, wenn der ITler von einem Pflichtenheft spricht und das Wort Lastenheft verwenden, wenn der ITler das Wort Lastenheft verwenden würde.
Das Lastenheft
Das Lastenheft beinhaltet das fachliche Anforderungsprofil des Kunden. Im Englischen wird es Requirement Specification genannt. Und wichtig und klar ist: Nach der Rechtsprechung des BGH ist grundsätzlich der Auftraggeber dazu verpflichtet, das Lastenheft zu erstellen und zur Grundlage des Projektes zu machen. Die Entscheidungen des BGH zu dem Thema sind teilweise alt. Im technischen Fortschritt ist auf der juristischen Seite nicht Rechnung getragen worden. Der BGH sagt, dass das Pflichtenheft (gemeint Lastenheft) die generelle Problemlösung beinhaltet und in der zweiten Phase bei der Erstellung des Pflichtenheftes (gemeint Lastenheft) die Projektion der Problemlösung erfolge. Die entsprechende Entscheidung Inkassoprogramm stammt aus dem Jahre 1985 und lässt sich auf die heutige Zeit nur sehr schwer übertragen. Man muss aber als Jurist im IT-Recht gewahr sein, dass die Standardliteratur des IT-Rechts immer noch auf diese uralten Entscheidungen preferiert, die an der Praxis vorbeigehen. Wichtig ist aber, dass der BGH schon in der Entscheidung „Inkassoprogramm“ aus dem Jahre 1985 erkannt hat, dass zwischen der fachlichen Planungsphase und der technischen Planungsphase Unterschiede bestehen. Im Jahre 1988 hat der BGH in der Entscheidung Regristrierkassen angeführt, dass der Kunde selbst die „Beistellung der Programmvorgaben“ zu erfüllen habe. Mit anderen Worten: Der Kunde ist dafür verantwortlich, das Lastenheft zu erstellen. Falls der Kunde das Lastenheft nicht stellt oder die von ihm gemachten Angaben nicht ausreichend sind, so führt der BGH in den Entscheidungen auf, dass
– ein fehlendes Lastenheft bedeutet, dass der Kunde die ihm obliegenden Mitwirkungs- und Beistellungspflicht nicht erfüllt hat
– und falls der Kunde Probleme bei der Erstellung des Lastenheftes hat, er den ITler darum bitten muss, ihn bei der Erstellung des Lastenheftes zu unterstützen. Wenn das nicht ausreicht, soll die Unterstützung durch einen Sachkundigen geleistet werden (Registrierkassen, CR 1989, 102).
Die meisten ITler werden an dieser Stelle kritisch bemerken, dass der Kunde in den seltensten Fällen ein ausreichend konkretes Lastenheft präsentiert, welches die wesentlichen Funktionen und Eigenschaften des Programmes sowie die einzuhaltenden Prozesse in ausreichender Weise beschreibt.
Das mag in sehr vielen Fällen so sein, nur ist der Schluss, den die meisten IT-Unternehmen in dieser Situation ziehen, nicht richtig: Die meisten IT-Unternehmen beginnen in einer solchen Situation das Projekt, ohne den Kunden auf die Schwächen des Lastenheftes hinzuweisen, und realisieren die vom Kunden erwarteten Konkretisierungen später im Rahmen von Changes. So jedenfalls wird ein Auftraggeber argumentieren, der von den Kosten überrollt ist. Der ITler wird gewiss zu Recht einwenden, dass viele Unklarheiten des Lastenheftes ohne bösen Willen erst zu einem späteren Moment im Projekt auftreten.
