Prüfung des Pflichtenheftes
a) Pflichten des Kunden
Sollten Sie meinem Ratschlag folgen, werden Sie versuchen, dem Kunden eine Prüfungspflicht für das Pflichtenheft aufzuerlegen. Dabei ist natürlich zu berücksichtigen, dass die Kunden häufig überhaupt nicht in der Lage sind, die technischen Voraussetzungen für die Richtigkeit des Pflichtenheftes zu überprüfen. Das Pflichtenheft regelt aber viele Inhalte. Nicht nur die Frage, ob eine Software überhaupt in der Lage ist, eine bestimmte Funktion zu realisieren wird geregelt. Auch die Funktionalität selbst wird benannt. Es wird häufig übersehen, dass Kunden davon ausgehen, dass eine Software, die einmal festgelegten Organisationsabläufe im Unternehmen richtig aufnehmen und effizienter gestalten kann. Manchmal und gar nicht so selten tritt der Fall auf, dass bestimmte Funktionalitäten, die zur Steigerung der Effizienz oder sonstiger Abläufe erforderlich sind, im Pflichtenheft überhaupt nicht genannt werden. Die juristische Frage lautet deswegen, ob dem Kunden eine Prüfungspflicht des Pflichtenheftes auferlegt werden kann und bejahendenfalls welchen Umfang diese Prüfungspflicht hat.
In jedem Fall wird man dem Kunden die Pflicht auferlegen können, zu überprüfen, ob im Pflichtenheft die richtigen Mengengerüste, Testdaten, Funktionalitäten, Systemumgebung und Zielvorstellungen richtig abgebildet sind. Damit aber enden die Prüfungspflichten des Kunden.
b) Pflichten des Auftragnehmers
Den Auftragnehmer trifft in jedem Fall die Prüfungspflicht, die Zielvorgaben des Kunden auf ihre Plausibilität hin zu überprüfen. Man darf nicht vergessen, dass viele IT Unternehmen Aufträge nur deswegen erhalten, weil sie mit brancheninternen Kenntnissen ausgestattet sind. Der Wettbewerbsvorsprung, den Ihr Unternehmen vermutlich vor denen der Konkurrenz hat, wird sich auch danach bemessen, in welchem Umfang Sie einmal erworbenes Know How an den Kunden weitergeben können. Branchenspezifische Beratung ist ein Topos, mit dem sich nicht nur gute Werbung schalten lässt; er muss eben auch in der praktischen Arbeit bewiesen werden.
Die Gerichte[1] gehen davon aus, dass der Auftragnehmer dazu verpflichtet ist, das Pflichtenheft auf seine Eignung für das Erreichen der geplanten und offenkundigen Ziele zu überprüfen. In diesen Entscheidungen kommt auch zum Ausdruck, dass der Auftragnehmer verpflichtet ist, etwaig fehlende Informationen vom Kunden einzuholen. Ob das in der heutigen Zeit noch so Geltung haben kann, bleibt abzuwarten. Man darf nicht vergessen, dass die wenigen zitierbaren Entscheidungen schon einiges an Alter mit sich bringen und mithin vermutlich wenig abstraktionsfähig sind.
Der Auftragnehmer ist verpflichtet, einen einmal vom Auftraggeber vorgegebenes Pflichtenheft wie folgt zu überprüfen:
Offensichtliche Fehler wie etwaig fehlende Schnittstellenspezifikationen, Systemanforderung, Mengengerüste etc. sind vom Auftragnehmer zu hinterfragen und begründen Aufklärungspflichten. Ich kann in diesem Zusammenhang nur dazu raten, dem Auftraggeber jeweils ein Formular zu überreichen, auf dem er erklärt, welche Informationen im Pflichtenheft eigentlich vorhanden sein sollen.
Schwieriger einzuordnen sind die so genannten erkennbaren und versteckten Fehler. Auch hier ist die Literatur wie auch Judikatur überaus lückenhaft, so dass hier nur Anhaltspunkte wiedergegeben werden können: Nach Schneider[2] soll es darauf ankommen, dass und wie weit die Fehler in dem Pflichtenheft des Kunden für den Auftragnehmer erkennbar sind. Diese sehr weit reichende Ansicht führt für den Kunden zu der bequemen Erkenntnis, dass Fehler in einem von ihm erstellten Pflichtenheft durchaus dazu führen können, dass der Auftragnehmer kostenlos change request durchführen muss, weil er den Fehler entweder aufgrund einer fehlenden Prüfung nicht kennt oder infolge einer fehlerhaften Prüfung hätte erkennen müssen. Jedenfalls ist zu raten, dass im Falle des Erkennens von Fehlern des Pflichtenheftes Fehlerhaftigkeit, Unvollständigkeit, mangelnde Ausführbarkeit oder objektiv nicht ausführbare Funktionalitäten sofort zu rügen sind. Wenn genügend Ressourcen vorhanden sind, wird eine ausführliche Prüfung des Pflichtenheftes des Auftraggebers kein Problem sein. Insofern kann ich nur empfehlen, dass der Auftragnehmer den Prüfungsumfang über den Inhalt eines vom Auftraggeber gelieferten Pflichtenheftes vertraglich fixiert. Mängel in der vertraglichen Vereinbarung führen dazu, dass die vom Gesetz (maginal) und der Literatur festgelegten oben dargestellten Maßstäbe Geltung erlangen. Die Folge kann in der Geltendmachung von Schadenersatzansprüchen (selten) oder in dem Verlangen zur Durchführung kostenloser change request (häufig) bestehen.
c) Einzelne Projektschritte:
Natürlich sind die klugen Ausführungen von Juristen über den Ablauf von Projekten kaum geeignet, die Praxis richtig wiederzugeben. Die nachfolgenden Ausführungen betreffen insofern einen Idealfall, der kaum jemals Realität werden kann. Als ein solches Muster sind sie zu werten und dienen als Anregung für die Praxis.
Orientieren kann man sich an den Vorlagen der öffentlichen Hand, namentlich der BVB-Planung und -Erstellung. Die „Vorstudie“ lässt sich wohl leicht mit der Phase der „Verfahrensidee“ bei den BVB-Planung und –Erstellung vergleichen. Die Phase (1.1 in der BVB-Nummerierung) umfasst:
1.1.1 Erstellung der Problembeschreibung
– Auslösende Momente für das Vorhaben
– Bereits erkannte Schwachstellen
– Randbedingungen (finanziell, gesetzlich, personell)
1.1.2 Abgrenzung
– Zu bearbeitende/nicht zu bearbeitende Aufgaben
– Einbettung in die organisatorische und technische Umgebung
1.1.3 Festlegung von Zieldefinition und –bewertung
– Geschäftspolitische Ziele
– Verfahrenstechnische Ziele
– DV-technische Ziele
– Prioritätenvergabe für die Ziele
Stefan G. Kramer / Rechtsanwalt
