Kurze Einführung in Projektmanagement und Blockchain

Projektmanagement ist eine Arbeits- und Organisationsform, ein geplantes Vorhaben in einer gewissen Zeit, mit einem gewissen finanziellen Budget zu einem definierten Ergebnis zu kommen.

Blockchain ist ein digitales Verfahren, Transaktionen in Computersystemen dezentral so zu speichern, dass ein nachträgliches Verändern der Transaktionen (fälschen, manipulieren) nicht möglich ist.

Wie hängen diese beiden Themen zusammen? 

Projektplanungen sind die Grundlage von Verträgen. In schriftlichen Verträgen zwischen Unternehmen, werden Elemente aus einer Projektplanung juristisch bindend vereinbart. Das sind häufig Termine und Liefermengen, Zusicherungen von Personen mit bestimmten Fähigkeiten, Qualitätssicherungsmaßnahmen und Dokumentationspflichten. Am besten lässt sich der Zusammenhang mit Terminen in Verträgen beschreiben. In den Werk- oder Projektverträgen werden Termine für bestimmte Lieferungen von Teil- und Endergebnissen vertraglich festgelegt. Diese Termine verpflichten den einen Vertragspartner diese einzuhalten und unter normalen Umständen nicht zu verschieben. Damit wird ein Projektrisiko vom Auftraggeber auf den Projektauftragnehmer übertragen. Bei Nichteinhaltung dieser Termine, folgen manchmal Vertragsstrafen, die der Auftragnehmer zu schultern hat, wenn er die Termine nicht einhält.

Diese vertraglichen Termine werden nicht von den Juristen oder Managern willkürlich in die Verträge übernommen. Vielmehr wird in Zusammenarbeit zwischen den beiden Parteien eine gemeinsame Projektplanung erstellt. Ergebnis dieser Planung sind Meilensteintermine und Projektendetermine. Erst nach dieser Planung kommen diese Termine in den Vertrag. Weiterhin wird vertraglich vereinbart, dass der Auftraggeber gewisse Rahmenbedingungen des Projekts nicht so verändern darf, dass der Auftragnehmer deswegen die Meilensteine nicht einhalten kann. Das wird durch Änderungsprozesse denen beiden Parteien zustimmen müssen (Change Request) geregelt. Dies alles juristisch und methodisch so zu beschreiben, dass jede Abweichung nicht zu einem Konflikt führt, ist schwierig und vor allem umfangreich. Bei einer signifikanten Abweichung solcher Vereinbarungen wird dann häufig im laufenden Projekt die Schuld zwischen den Parteien hin- und hergeschoben.

Vor allem der Auftragnehmer ist hier manchmal sehr nervös, liegt doch der Druck erst einmal bei ihm. Er muss vor Beginn des Projekts eine so gute, teilweise detaillierte Planung anfertigen, dass er alle vertraglichen Vereinbarungen auch einhalten kann.

Dies führt zu zwei Effekten: 

Es wird vor dem Projektstart jedes Risiko und jede Anforderung so detailliert wie möglich analysiert, um keine böse Überraschung im Projekt zu erleben.

Zweitens werden Puffer eingebaut, die für den Auftragnehmer nicht sichtbar sind, sondern durch den Auftragnehmer genutzt werden, wenn etwas nicht Vorhersehbares passiert das die Termine oder den Lieferumfang gefährdet. Das Ergebnis ist also, ein sehr hoher Aufwand an Detailplanung und Annahmen bevor das Projekt überhaupt gestartet wurde plus eine „manipulierte“ Planung mit Puffern.

Es entsteht durch das Sicherheitsbedürfnis des Auftraggebers aber noch ein inhaltliches Problem im laufenden Projekt. Der Auftragnehmer sperrt sich so weit wie möglich, Änderungen im Projekt zuzulassen, auch wenn diese fachlich sinnvoll wären. In diesem Fall muss der Auftragnehmer wieder eine detaillierte Anpassung der Planung, mit den oben genannten Risiken, durchführen und einer Änderung der vertraglichen Termine und Aufwänden zustimmen.

Er nimmt also im Zweifelsfall ein schlechteres Projektergebnis in Kauf, bevor er das Risiko eingeht, Vertragsstrafen zu bezahlen. Das Projektergebnis wird dadurch möglicherweise schlechter als es sein könnte.

Auftraggeber neigen dazu, immer mehr Bedingungen vorzuschreiben um möglichst nie für eine Verspätung – die sie vielleicht selbst verursacht haben – verantwortlich gemacht zu werden.

Allerdings sind in Projektplänen eine Vielzahl weiterer Daten enthalten, die dann umständlich in die Verträge geschrieben werden. Dies sind beispielsweise spezielle Projektmitarbeiter des Auftragnehmers die für das Projekt verpflichtet werden. Weiterhin gibt es Mitwirkungspflichten des Auftraggebers. Dieser muss Arbeitsergebnisse testen und abnehmen und muss dazu auch das passende Personal zur Verfügung stellen. Die Liste lässt sich noch lange fortsetzen und alles führt zu einer entscheidenden Frage.

Warum wird der Projektplan nicht als Vertragsgrundlage festgelegt? 

Das hat mehrere Ursachen, diese alle umfassend zu beschreiben würde den Umfang dieses Aufsatzes sprengen, daher will ich nur wenige Gründe darstellen.

Die Planung muss eine gewisse Qualität haben. Dazu muss zwingend eine professionelle Projektmanagementsoftware eingesetzt werden die vor allem beim Auftraggeber auch die Risiken – beispielsweise durch Überlastung von Ressourcen – realistisch anzeigt. Ein schicke Powerpoint-Präsentation oder ein Excel-File sind hier absolut nicht geeignet.

Weiterhin hat der Auftragnehmer ein gewisses Interesse Puffer im Projekt zu „verstecken“, dies ist auch bei einer Projektmanagementsoftware möglich. Dies hätte aber den negativen Effekt in der Firma des Auftragnehmers, dass eine solche Planung vielleicht eben auch zu viele Ressourcen zu lange bindet.

Ein viel größeres Problem ist aber die Beweisfähigkeit eines solchen Plans, egal wie detailliert er ist.  Häufig werden Ausdrucke oder PDF-Dateien als Anhang zu den Verträgen genommen. Ein Projektplan ist aber viel mehr als nur die „Grafik“ einer Ablauf- oder Epic-Planung. Dahinter stehen Ressourcenmengen, ungenaue Planungen, Budgetpositionen, Risiken zum Zeitpunkt des Ausdrucks etc. Es ist also eher eine digitale Menge von Daten zu diesem Zeitpunkt, und zwar nicht nur von diesem Projekt, sondern auch von allen anderen Aktivitäten im Unternehmen des Auftraggebers zu einem gewissen Zeitpunkt.

Die Qualität der Planung muss stimmen, um eine solide Vertragsgrundlage zu haben

Eine detaillierte genaue Planung mit hunderten von Arbeitspaketen ist dazu nicht sinnvoll. Dafür sind Projekte grundsätzlich zu schwer vorherzusehen und zu volatil. Eine eher grobe, phasenorientierte Planung, die mit ungenauen Daten arbeitet, hat hier einfach einen höheren Realitätsgrad und kann von allen Seiten akzeptiert werden.

Eine ungenaue Planung, in der für einen Meilenstein eben nicht der 1.6. steht, sondern Juni 2022 lässt einen für alle Seiten vertretbaren Spielraum zu.  Anstelle einer namentlichen Planung von Schlüsselressourcen könnten geforderte Fähigkeiten (Skills) hinterlegt werden, die im Projekt durch verschiedene Menschen erfüllt werden können.

Die notwendigen Kapazitäten des Auftraggebers können auch dann hinterlegt werden, wenn die Verfügbarkeiten nicht im Detail bekannt sind. Vielmehr wird einfach eine (ungenaue) Mindestmenge von Fähigkeiten, die der Auftraggeber zur Verfügung stellen muss, eingeplant.

Manipulation der Daten – was ist ein Basisplan? 

Natürlich liegt es nahe, einen sogenannten Basisplan in dem Moment zu erstellen in dem die Projektvereinbarung getroffen wird. Ein Basisplan ist eine nicht mehr änderbare Kopie eine Projektplans in dem Moment, in dem der Basisplan erstellt wird. Wie eine Kopie einer Excel-Datei die nicht mehr verändert wird, nur nicht als flache Datei, sondern viele Datensätze oder Objekte,  je nach Projektmanagementsystem.

Die meisten Projektmanagementsysteme speichern aber nicht alle Daten in den Basisplänen, die das System über das Projekt hat, sondern nur einige wenige. Häufig werden lediglich Termine für den Basisplan herangezogen.

Weiterhin ist eine solche Kopie nicht frei von Manipulationen. Der Basisplan ist auch nur eine Sammlung von Datensätzen in einer Datenbank, die durchaus nachträglich verändert werden kann. Es gibt sogar, Projektmanagementsysteme, die das ganz regulär zulassen.

Letztendlich müssten eigentlich alle Daten in einem Multiprojektmanagementsystems zu diesem Zeitpunkt „eingefroren“ und gesichert werden, um eine spätere Validierung ordentlich zu erlauben. Diese spätere Überprüfung muss dann selbst wieder durch Programme erfolgen, eine manuelle Überprüfung wäre viel zu aufwendig.

Das Weiterreichen von Verantwortung 

In der modernen vernetzten Welt werden Arbeiten eines Projekts durch den Auftragnehmer häufig an Subunternehmer weitergereicht. Entweder weiß der Auftraggeber das und duldet es oder er weiß das gar nicht. Diese Kette „nach unten“ kann beliebig tief reichen. In umfangreichen Projekten wird die Nachvollziehbarkeit durch teilweise gigantische Projektdokumentation hergestellt. Eigentlich ist das unnötig.

Ein Beispiel soll das verdeutlichen. Im Projektverfahren PRINCE2 gibt es Handlungsanweisungen beispielsweise an den Projektleiter wie er gewisse Planungen regelmäßig prüfen und optimieren muss. Das der Projektleiter dies auch getan hat, muss er dokumentieren, am liebsten in einem Formular, in dem er Haken setzt. Ob er das getan hat, egal welchen Nutzen, das hatte, lässt sich nicht prüfen, er setzt einfach den Haken.

In einer Projektmanagementsoftware, die solche PRINCE2-Dokumentationen unterstützt, wird das ebenfalls vermerkt. Nicht vermerkt wird allerdings, ob Risiken in der digitalen Planung überhaupt vorhanden waren und ob der Projektleiter die Planung im Rechner überhaupt angeschaut oder angepasst hat. Er setzt schlicht nur einen Haken mit der Maus.

Blockchain zur Absicherung einer Basisplanung als Vertragsgrundlage 

Der erste naheliegende Ansatz wäre es, jedes Planungselement als einen Eintrag in die Blockchain zu schreiben. Eine nachträgliche manipulative Anpassung eines dieser Datenelemente würde die Blockchain für dieses Element quasi zerstören.

Die Datenmenge der Blockchain wäre aber sehr groß, wenn das für wirklich jedes Planungselement gemacht wird. Daher liegt es näher, einen einzigen Blockchain-Eintrag für dies gesamte Planungsmenge zu erzeugen. Später lässt sich dann feststellen, wenn der Basisplan geändert wurde, aber eben nicht was genau. Das ist völlig ausreichend, weil der Basisplan eben grundsätzlich nicht geändert werden darf.

Blockchain zur Absicherung der Projektdokumentation 

In jeder Projektplanung gibt es Planungselemente, die aus vertraglicher Sicht relevant sind und – viel mehr – die es nicht sind. Meilensteine sind solche Elemente, während Kommentare für Arbeitspakete dies sicher nicht sind.

In der Software würde dann durch die Vertragsparteien einfach markiert, welche Elemente automatisch einen Teil des Vertrags darstellen. Zum Zeitpunkt des Vertragsabschlusses wird dann für diese Elemente eine Blockchain erstellt und alle Daten des Planungselements als erster Block eingetragen. Um diesen ersten Eintrag abzusichern, sollte die Projektmanagementsoftware über einen Algorithmus einen den Block absichern (Proof of Work).

Moderne Projektmanagementsysteme sind revisionssicher und dokumentieren im Datenbestand jede Änderung eines Planungselements. Die muss sich nicht zwingend auf die nativen Daten des Elements selbst beschränken, sondern kann auch Zustände abbilden, die durch fremde Plandaten entstehen. Das Risiko eines Arbeitspakets kann sich auch dadurch ändern, dass in einem anderen Projekt die gleiche Ressource zur gleichen Zeit überlastet wird, somit auch in diesem Projekt.

Jede Anpassung der Datenelements und jegliche relevante Zustandsänderung erzeugt dann in der jeweiligen Blockchain einen neuen Block, der durch die vorangehenden Blöcke abgesichert wird (Proof of Stake) und könnte zusätzlich durch ein Proof of Work Algorithmus ergänzt werden (um sicherzustellen, dass die Daten mit der Projektmanagementsoftware und nicht auf andere Wege verändert wurde). Eine nachträgliche Manipulation ist ausgeschlossen oder nur mit unrealistisch hohem Aufwand möglich.

Auswertung im Streitfall 

Da der Projektplan und alle anderen notwendigen Daten überhaupt nicht in schriftlicher Form als Anhang des Vertrags vorliegen, muss im Streitfall der digitale Datenbestand herangezogen werden. Dieses Auditing kann von jeder Person durchgeführt werden, also auch von Anwälten oder Gutachtern.

Gibt es also Meinungsunterschiede über den Termin eines Meilensteins, können die Streitparteien durch den ersten Eintrag in der Blockchain die Vertragsdaten heranholen. Die aktuelle Planung im System ist nicht relevant. Weiterhin kann genau in der Blockchain verfolgt werden, wann der Meilenstein wie verändert wurde und vor allem durch wen (das wird ebenfalls in der Blockchain abgesichert).

Ist dieser Ansatz realisierbar? 

Aus technischer Sicht ist die Umsetzung wenig aufwendig. Das liegt daran, dass Anbieter wie AWS (Amazon Web Service) und andere komfortable Dienste den Umgang mit der Blockchain ermöglichen. Die Projektmanagementlösung muss diese Dienste lediglich nutzen und zusätzlich eine frei verfügbare Auditsoftware in der Cloud anbieten, mit der jeder die Blockchain überprüfen kann. Damit ist natürlich nicht gemeint, dass jede Person die Blockchain beliebig auslesen kann. Vielmehr wird autorisierten Personen, wie beispielsweise Anwälten oder Gutachtern, die digitale Interpretation der Blockchain des Streitobjekts gewährt.

Ob ein solches Verfahren auch vor Gerichten standhält, müssen Juristen entscheiden. Es muss sicher Verfahren geben, die die Softwarehersteller und ihren Code in diesem Bereich zertifiziert, bzw. offenlegt.

Eine allgemeine, international juristische Gültigkeit festzulegen, würde wahrscheinlich ewig dauern. Es würde aber – meiner Meinung nach – ausreichen, wenn es eine Zertifizierung der Software, vergleichbar mit TISAX oder ISO, gäbe und sich die Vertragsparteien darauf einigen.

Welche Vorteile hätte die Blockchain für die Projektarbeit 

Natürlich gibt es als erstes einen psychologischen Effekt. Da alle Beteiligten wissen, dass eine Manipulation der Projektplanung nicht unentdeckt bleibt, würde die Manipulation schlicht unterlassen werden.

Viel wichtiger wäre aber Nutzen für das Projektmanagement und die notwendige Bürokratie. Die Vertragsparteien einigen sich auf einen digitalen gemeinsamen Datenbestand der durch die Blockchain abgesichert ist. Im Vertrag beider Parteien wird das lediglich festgelegt, eine schriftliche juristische Ausformulierung ist nicht mehr notwendig. Das spart Aufwand und wäre nur für Anwälte schlecht.

Die vereinbarten Pflichten aller Parteien, wie einzusetzende Personen, Termin oder Aufwände müssen ebenfalls nicht im Vertrag ausgeführt werden. Dies ist alles im digitalen Datenbestand abgelegt, der eben nicht gefälscht werden kann. Die aufwendige Dokumentation der Projektleitung dem Auftraggeber gegenüber wie Leistungsnachweise, Statusberichte etc. müssen nicht manuell in Texten oder Excel-Dateien erstellt werden. Die Dokumentation entsteht durch die Arbeit des Projektleiters und alle Mitarbeiter automatisch.

Ergonomische Software für alle Beteiligten kann Pflichtverletzungen einfach aufzeigen und dann der Absicherung durch die Blockchain glauben auch alle an diese Information. Vergisst ein Mitarbeiter beispielsweise die Zeiterfassung für eine abzurechnende Arbeit am Ende eines Monats, können beide Parteien einer nachträglichen Erfassung gemeinsam zustimmen und das Problem damit aus der Welt schaffen. Das beide Parteien zugestimmt haben, ist in der Blockchain vermerkt.

Aussichten 

Die Blockchain erlaubt es digitale Informationen und – vor allem – Transaktionsdaten revisions- und fälschungssicher zu verwalten. Durch die firmenübergreifende Zusammenarbeit auf Plattformen, haben alle Beteiligten nicht nur den gleichen Informationsstand, sondern können eben auch sicher sein, dass die Informationen auch verlässlich und gerichtsfest sind.

Durch übliche Aktionen in diesem Datenbestand – wie dem Verschieben eines Meilensteins oder einer Zeiterfassung – werden Informationen automatisch digital erzeugt. Es wird also vor allem bürokratischer Aufwand gespart, da diese Daten nicht mehr manuell in Projektstatusberichte oder Vertragsprotokolle übertragen werden müssen.

Dieses Beispiel in der kooperativen Projektarbeit ist nur ein Anwendungsbereich für die Blockchain. Firmenjustitiare, Notare und alle anderen Stellen die fachlichen Informationen und Regeln in einen Vertrag übernehmen können dadurch stark entlastet werden und sind nicht mehr mit solchen Informationen konfrontiert, die sie selbst fachlich gar nicht beurteilen können.

Wenn der Ansatz der Blockchain in diesem Kontext konsequent weitergedacht wird, sieht man die Dimension dieser Erfindung die dann ein Meilenstein der digitalen Transformation im 21. Jahrhundert darstellen wird.