Die Blockchaintechnologie wird das Projektmanagement grundlegend verändern: So steht es in ersten Fachartikeln und Publikationen, die zu diesem Thema zu finden sind. Aber ist das wirklich so? Beide Themen haben schließlich auf den ersten Blick wenig bis nichts miteinander zu tun. Der Gründer und CEO von Can Do, Thomas Schlereth, geht der Sache nach – und findet interessante Anwendungsmöglichkeiten.
Beginnen wir aber zunächst mit einer kurzen Einführung in das Projektmanagement sowie in die Blockchain-Technologie:
Projektmanagement ist eine Arbeits- und Organisationsform, um bei einem geplanten Vorhaben in einer gewissen Zeit und mit einem finanziellen Budget zu einem definierten Ergebnis zu kommen.
Blockchain ist ein digitales Verfahren, um 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 nun PM und Blockchain 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 beide 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 erstens 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, selbst 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 im Unternehmen 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 handelt sich also eher um 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 als 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 Multiprojektmanagementsystem zu diesem Zeitpunkt „eingefroren“ und gesichert werden, um eine spätere ordentliche Validierung 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 eine 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. Dass 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 vorhanden waren und ob der Projektleiter die Planung im Rechner überhaupt angeschaut oder angepasst hat. Wie geschrieben: 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 würde. 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 davon genau. Das ist völlig ausreichend, weil der Basisplan eben grundsätzlich nicht geändert werden darf.
Ausblick
Im zweiten Teil von Thomas' Betrachtungen zur Blockchain im Projektmanagement geht es unter anderem um die Absicherung der Projektdokumentation, eine mögliche Auswertung im Streitfall und die allgemeinen Vorteile der Blockchain für die Projektarbeit. Außerdem wagt er einen Ausblick auf die Anwendungs-Szenarien im Projektmanagement und bewertet die Auswirkungen der Blockchain-Technologie auf die digitale Transformation im 21. Jahrhundert.
Du möchtest schon jetzt alles über Hybrides Projektmanagement, Can Do und neue Technologien im PM wissen? Lass Dich von uns unverbindlich beraten – nimm einfach Kontakt auf!
Unser Blogpost-Zweiteiler in der Übersicht:
Beginnen wir aber zunächst mit einer kurzen Einführung in das Projektmanagement sowie in die Blockchain-Technologie:
Projektmanagement ist eine Arbeits- und Organisationsform, um bei einem geplanten Vorhaben in einer gewissen Zeit und mit einem finanziellen Budget zu einem definierten Ergebnis zu kommen.
Blockchain ist ein digitales Verfahren, um 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 nun PM und Blockchain 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 beide 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 erstens 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, selbst 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 im Unternehmen 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 handelt sich also eher um 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 als 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 Multiprojektmanagementsystem zu diesem Zeitpunkt „eingefroren“ und gesichert werden, um eine spätere ordentliche Validierung 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 eine 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. Dass 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 vorhanden waren und ob der Projektleiter die Planung im Rechner überhaupt angeschaut oder angepasst hat. Wie geschrieben: 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 würde. 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 davon genau. Das ist völlig ausreichend, weil der Basisplan eben grundsätzlich nicht geändert werden darf.
Ausblick
Im zweiten Teil von Thomas' Betrachtungen zur Blockchain im Projektmanagement geht es unter anderem um die Absicherung der Projektdokumentation, eine mögliche Auswertung im Streitfall und die allgemeinen Vorteile der Blockchain für die Projektarbeit. Außerdem wagt er einen Ausblick auf die Anwendungs-Szenarien im Projektmanagement und bewertet die Auswirkungen der Blockchain-Technologie auf die digitale Transformation im 21. Jahrhundert.
Du möchtest schon jetzt alles über Hybrides Projektmanagement, Can Do und neue Technologien im PM wissen? Lass Dich von uns unverbindlich beraten – nimm einfach Kontakt auf!
Unser Blogpost-Zweiteiler in der Übersicht:
- Teil 1: Manipulationsgeschützte Daten als Vertragsgrundlage (dieser Beitrag)
- Teil 2: Mehr Sicherheit bei weniger Verwaltungsaufwand fürs PM
