IT- Recht: Projektgeschäft – Der Unterschied zwischen agiler und nicht agiler Projektmethodik

Die Theorie zieht eine Grenze zwischen der agilen und der nicht agilen Welt, die für mich so nicht besteht. Die Grenzziehung hat aber zwei Auswirkungen, die wichtig sind.

I Unterscheidung

Die Theorie besagt, dass agile Arbeitsweisen sich von den herkömmlichen Prozessen unterscheiden. Ich möchte jetzt nicht im Detail agile Manifeste und dergl. zitieren und bewerten und den herkömmlichen Methodiken gegenüberstellen. Im Prinzip geht es schwerpunktmäßig um die Bewertung der Planungsphase. Die agilen Methodiken erkennen die Schwächen des (nicht-agilen) Ansatzes an, dass eine Planungsphase an einem bestimmten Punkt abgeschlossen ist und in ausreichender Klarheit durch Dokumente etc. perpetuiert ist und stellen diesem (nicht-agilen) Ansatz einen Ansatz entgegen, der einen gesteigerten Abgleich zwischen dem aktuell gewünschten Ergebnis und einem aktuell zu verändernden Ist- Zustand vorsieht. Interessanterweise kann man diesen Unterschied ganz gut (mit Einschränkungen, kein Vergleich passt komplett) darstellen: Während man im Dienstvertragsrecht einen groben Korridor der Tätigkeiten vertraglich regeln kann (Arbeitszeiten und Skilllevel, Aufgabenbereich), aber eben nicht den Umstand, ob ein bestimmtes Ergebnis zu einem bestimmten Zeitpunkt realisiert wird, ist letzteres genau Gegenstand des Werkvertragsrechts. Das Dienstvertragsrecht setzt die Erkenntnis des Gesetzgebers um, dass Arbeitsverhältnisse eben lange dauern können und es schier unmöglich ist, zum Zeitpunkt der Eingehung des Arbeitsvertrags genau zu beschreiben, wann was fertig gestellt werden kann/ fertig zu stellen ist. Das Werkvertragsrecht dagegen funktioniert wie eine Wette: Der Unternehmer gibt die Zusage, dass eine abgeschlossene Planung innerhalb einer bestimmten Zeitspanne auch umgesetzt werden kann, häufig genug verbunden mit weitergehenden Zusagen über die eingesetzten Ressourcen.

Auf der Basis des deutschen Rechts vermitteln die herkömmlichen – nicht agilen Projektmethodiken – genau diese scheinbare Sicherheit.  Tatsächlich vermitteln sie nur den Schein, denn der Einsatz der herkömmlichen Methodiken setzt voraus, dass in der Planungsphase ein Ergebnis erstellt wurde, dass in Inhalt, Qualität, Detailtiefe und auch Unveränderbarkeit so gut ist, dass die Planung bis zum Ende der Arbeiten nicht mehr hinterfragt oder verändert werden muss. – Und so ist die Praxis schlicht nicht.-  Ich kann keine wissenschaftlich belastbaren Zahlen nennen, aber ich gebe seit mehr als 10 Jahren Seminare für das Projektgeschäft vor etwa 300 Personen pro Jahr. Meine ewig wiederkehrende Frage lautet, ob ein Kursteilnehmer schon einmal ein Projekt ohne Veränderung der Planung (Changes) erlebt habe. Ganz wenige Teilnehmer aus dem Bereich der rein technischen Umsetzung von Anforderungen erklärten, solche Projekte seien denkbar. Das Gros jedoch – wir sprechen von wirklich mehr als 98% sagt: Ein Projekt ohne Changes gibt es schlicht nicht.

II Die Praxis der Anwendung der „herkömmlichen“ Projektmethodiken

In der Praxis wird diesem Umstand begegnet, in dem Vergleichsverfahren an die Stelle eines strukturierten Prozesses treten. Wo Streitigkeiten über die Qualifikation eines „echten“ oder „unechten“ Changes auftreten, geht es meistens im Kern um die Frage, ob Dinge, die in der Planungsphase eben genau nicht in der ausreichenden Tiefe erfasst und geplant wurden, von dem Auftraggeber kostenlos gefordert werden können oder vom Auftragnehmer nur gegen Zahlung einer gesonderten Vergütung zu leisten sind. Diese Streitigkeiten werden durch Gespräche beigelegt. Und solche Verfahren nennt der Jurist dann Vergleichsverfahren.

Agile Methodiken erkennen genau an diesem Punkt an, dass die Planung zum Zeitpunkt des Vertragsabschlusses nicht/ nie abgeschlossen ist. Sie erheben keinen Anspruch auf eine Planungsphase in einer bestimmten Qualität zum Zeitpunkt des Vertragsabschlusses, sondern strukturieren die Zusammenarbeit der Parteien, um die Planungsphase zu verbessern oder gänzlich nachzuholen.

Das ist der große Vorteil der agilen Projektmethodik. Das Wissen darum, dass die fachlichen Anforderungen noch nicht abschließend dokumentiert sind, vielleicht niemals abschließend dokumentiert werden können und die Umsetzung dieses Wissens in ein strukturiertes Verfahren, in dem die Parteien in Anerkenntnis dieses Umstandes zusammenarbeiten.

Denn es sei klar gesagt: Die Praxis hilft sich beiderseits, in dem sie die Problemfelder umkreist.

II Relevanz für die Praxis

1.) In der Praxis werden Werkverträge häufig so gestaltet, dass man den Prozess des Werkvertragsrechts nicht mehr richtig erkennt, um der Anforderung nach einer nachvertraglichen Flexibilität beizukommen. Bsp: Die Projekthoheit wird geteilt oder der Auftraggeber kann jederzeit Changes verlangen. Der Auftragnehmer seinersetis verlangt Risikozuschläge für die Realisierung von Changes, die er sonst nicht verlangen würde. Solche Margen liegen zwischen 15% und 30%. iese Methodiken sind dann nicht risikoreich, wenn die Planungsphase eine gute Qualität erreicht hat und man das Werkvertragsrecht auch im Prozess so lebt, wie es im BGB beschrieben ist. Dazu gehört, dass Changes nur die letzte Ausnahme sein sollten, und dass die Projekthoheit nur auf der Seite des Auftragnehmers ist. Wenn eine dieser beiden Voraussetzungen nicht gegeben ist, ist man mit dem Dienstvertragsrecht und einer agilen Projektmethodik besser aufgehoben.

3.) In öffentlich-rechtlichen Vergabeverfahren sind die materiellen Ausführungen für die Leistung häufig nicht gut. Nach den Haushaltsordnungen der Länder müssen die EVB-IT Vorlagen herangezogen werden. Diese sind aber nur dann anwendbar, wenn sie die Komplexe abdecken, die geregelt werden sollen. Die Anwendbarkeit ist nicht gegeben für die Bereiche Cloud, Agile Erstellung/Anpassung, Open Source und komplexe Systeme. De facto entscheidet sich der Auftragnehmer mit EVB-IT für einen Vertragstyp, der das Bestehen einer sehr guten Planungsphase voraussetzt. Angesichts des oft beklagten Zustand der öffentlich-rechtlichen Ausschreibungen kann man sich hier seinen eigenen Reim machen. Falls man das Glück hat, dass Verhandlungsverfahren über Agile Projektmethodiken stattfinden sollen, sollte man sich die Frage stellen, ob der Anwalt des Auftraggebers wirklich der Richtige ist, die Arbeitsweise des Auftragnehmers zu bestimmen.

 

Weitere Beiträge

Programmieren und KI und Urheberrecht Teil II

Im Teil I hatte ich die generellen Probleme dargelegt, die sich daraus ergeben dass der Output eines KI Systems grundsätzlich nicht als urheberrechtsähiges Werk qualifiziert werden kann. Ganz konkret gehen wir in diesem Teil mal der Frage nach, was das

Mehr lesen »
Nach oben scrollen