Viele unserer Kunden empfinden es fast als magisch, wenn sie verstehen, dass die Projektmanagement-Komponente in Confluence nicht nur für die tatsächliche Abstimmung im Projekt selbst hilfreich ist, sondern dass die daraus resultierenden Seiten eine hervorragende Grundlage für eine Projektdokumentation bilden. Allein die Möglichkeit, sämtliche Konzepte, Dokumente, Dateien, Meeting-Agendas und Protokolle und auch sonst alle wichtigen Zwischenstände und Diskussionen an einem Ort gebündelt zu finden, ist für die meisten Unternehmen ein enormer Gewinn. 

Natürlich ist das reine “Abfallprodukt” des Projektmanagements im Wiki-Intranet noch keine perfekte Dokumentation. Aber wenn sich ein Projektteam nun hinsetzt und eine kurze, gut lesbare und sinnvolle Dokumentation mit den Erkenntnissen und dem Lernpotenzial für die Zukunft aufbereiten will, ist dieses Abfallprodukt eine unschätzbar wertvolle Basis, um sich den Projektverlauf noch einmal vor Augen zu führen und die relevanten Schritte für die Diskussion zusammenzustellen. Natürlich lassen sich die Protokolle, Zwischenstände und Dokumente auch verlinken.

Diesen Punkt kann ich kaum fett genug unterstreichen. Jetzt mal Hand aufs Herz: Tatsächlich wird in Ihren Projekten gar keine Dokumentation angefertigt, oder? Die meisten Ihrer Projekte sind schon ein Erfolg, wenn die Projektziele erreicht werden. Damit sind Sie nicht allein. Nach einer Dokumentation wird bei vielen unserer Kunden nur dann gefragt, wenn alles schiefgelaufen ist oder wenn das Projekt auditiert wird und schon bald der Auditor vor der Tür steht.

Ich will nichts schönreden. Auch bei uns ist die sauber aufbereitete Dokumentation mit den Erkenntnissen und Lehren für die Zukunft eine Rarität. Keine Frage: Auch wir sollten darin besser und disziplinierter werden. Aber zumindest besteht die Grundlage dafür. 

Ich selbst bin ja eher so ein Hans Dampf in allen Gassen bei uns. Das bedeutet, dass ich mich öfter mal in anderer Leute Projekte eindenke und einlese, wenn ich nach etwas gefragt werde oder sich Energie für die Unterstützung bei mir sammelt. Dann wühle ich meist in der Wiki-Dokumentation der Meetings und Konzepte herum. Der Chat ist mir zu voluminös und detailliert. Die Aufgaben in Jira sind mir meist zu knapp und zu wenig mit Kontext angereichert. Dort schaue ich nur kurz rein. Den Quellcode unserer Software verstehe ich in den meisten Bereichen nicht. Und oft finden solche Orientierungsphasen meinerseits außerhalb der regelmäßigen Arbeitszeiten der Teammitglieder statt. Ich kann also niemanden fragen. Aber es klappt erstaunlich gut. Natürlich wünsche ich mir auch immer, dass mir jemand die Dokumentation mundgerecht aufbereitet. Und es gibt Teams, die sehr akribisch dokumentieren, und welche, die eher lax arbeiten. Aber ich komme in der Regel zum Ziel. Ich erhalte einen groben Überblick über das Projekt, seine Herausforderungen und den aktuellen Stand. Das ist eine wirklich gute Vorbereitung für ein persönliches Gespräch mit dem Team. 

Was ich tue, wenn ein Projekt ins Stocken kommt

Ein anderes Beispiel: Wenn in einem Projekt eine Blockade herrscht und sich keiner mehr nach vorn oder zurück bewegen kann, werden Dinge manchmal zu mir oder anderen Gesellschaftern eskaliert. In der Regel existiert dann schon eine Seite, auf der die Blockade, die Gründe dafür und die Positionen dokumentiert sind. Aber drum herum gibt es oft noch sehr interessante und hilfreiche zusätzliche Informationen. Mit ein bisschen Zeit und Konzentration treten unheimlich viele Details zutage, die dabei helfen, eine sinnvolle Unterstützung anzubieten. Ich wüsste nicht, wie wir das machen sollten, wenn wir kein aktiv genutztes Wiki hätten.

Die fast schon natürliche Reaktion von Führungskräften in einer solchen Situation ohne Informationen und Dokumentation ist das Durchregieren mit Macht. Es erspart nämlich das mühselige Informieren. Man müsste sich eigentlich jetzt von allen Seiten informieren lassen und dann mit Fragen dabei helfen, dass die Protagonisten selbst die Blockaden aufheben können. Ich kann das im Zweifel von unterwegs mit dem Handy über Tage hinweg mit Fragen und Kommentaren begleiten. Das kostet mich nur wenig Energie und so habe ich da viel Ausdauer. Sie müssten dafür möglicherweise wichtige Meeting-Zeit während Ihrer Kernarbeitsstunden verbrauchen, die Sie eigentlich für strategische Aufgaben, die Ihnen selbst wirklich wichtig sind, verwenden möchten.

Die Rolle von Asynchronität in der Kommunikation haben wir schon beleuchtet (siehe “Wann synchrone Kommunikation sinnvoll ist”). Hier wird sie auch noch einmal deutlich. Wenn ich etwas nebenbei von unterwegs erledigen kann, schaffe ich das möglicherweise noch zusätzlich neben meinen sonstigen Aufgaben. Aber mitten in mein Kerngeschäft passt in der Regel nichts Zusätzliches hinein. Auch meine Bereitschaft, diese Zeit widerstandslos freizuräumen, ist sehr gering. Und so regiert dann ohne digitale Unterstützung an vielen Stellen doch die Macht. Und zwar nicht aus Bosheit, sondern einfach weil es nicht anders geht. Wenn Sie keine Zeit haben, müssen Sie halt schnell entscheiden. Und wenn Sie schnell entscheiden, können Sie keinen Kontext berücksichtigen. Und wenn Sie die Situation nicht einzuschätzen vermögen und Ihnen Details zur Entscheidungsgrundlage fehlen, werden Ihre Entscheidungen eben oft auch schlecht sein.

Es gibt womöglich talentierte und erfahrene Manager, die auch dann ins Schwarze treffen, wenn sie sich gerade erst umgedreht haben und überhaupt keine Zeit zum Zielen hatten. So wie Lucky Luke, der schneller schießt als sein eigener Schatten. Aber in der Realität der meisten Organisationen schießen die Mitarbeiter eben doch besser. Sie haben Zeit zum Zielen. Sie laufen auch noch mal zur Zielscheibe hin, um ihre Ausrichtung zu justieren und sie geradezurücken. Sie stellen Windberechnungen an und validieren die Voreinstellung mit einem Computerprogramm. Was ich sagen will: In den meisten Szenarien treffen die Mitarbeiter mit all den Informationen, Details und Vorbereitungen besser als die Chefs, die nicht lange nachdenken und schnell aus dem Bauch entscheiden. Kurz gesagt: Vergessen Sie Lucky Luke. Das ist was für Comics.

Projektmanagement nebst Aufgaben klar von Konzepten, Berichten und Dokus trennen

In diesem Zusammenhang möchte ich mich grundsätzlich auf meine Erfahrungen mit Atlassian Confluence und Jira beziehen. Aber ich glaube, dass diese Überlegungen auch für Kollegen von Ihnen interessant sein könnten, die die beiden Systeme nicht nutzen. 

Confluence ist ein Wiki, das Teams vor allem für die Zusammenarbeit an jedweder Form von Text und zur Dokumentation und als Referenz nutzen. Zum Beispiel bereiten sie hier Meetings vor und dokumentieren sie anschließend. Aus solchen Treffen gehen eigentlich fast immer Aufgaben hervor, die irgendwer umsetzen muss.

Lassen Sie uns über diese Art von Aufgaben, die mehr oder weniger spontan aus dem Kontext heraus entstehen, mal genauer diskutieren. Die Erledigung solcher ungeplanten Aktivitäten spielt eine enorm wichtige Rolle bei der erfolgreichen Umsetzung von Projekten. Ob Wasserfall (sequenziell, deterministisch geplant) oder agil (schrittweise, sich anpassend): Ein bisschen wollen wir uns alle auf die Zukunft vorbereiten und durchdenken, was im Laufe des Projekts so an Aufgaben auf uns zukommen könnte.

Im Rahmen der ersten Grobplanung wird bei manchen unseren Kunden immer noch ein Gantt-Diagramm erstellt, um zu überlegen, wie lange sich das Projekt wohl hinziehen wird und welche großen Aufgaben darin zu erledigen sind. Dass diese Planung eigentlich immer falsch ist, wissen wir alle. Und das ist auch den Konzernen meist bewusst. Entscheidend für den Erfolg ist aus meiner Sicht viel eher, wie Sie nun auf die neuen Informationen reagieren, die sich im Laufe des Projekts ergeben. 

Der Lieferant, mit dem Sie maßgeblich geplant hatten, sagt Ihnen ab, weil die Auftragsbücher voll sind. Der nächste geht mitten im Projekt pleite und das Vorhaben muss umgeplant werden. Es tauchen alle naselang neue Anforderungen und detaillierte Informationen auf, die zu weiteren Aufgaben im Projekt führen.

Ein modernes Intranet muss in der Lage sein, diese komplexe Welt zu erfassen und den Menschen im Projekt dabei zu helfen, mit dieser Komplexität umzugehen. Eine zentrale Anforderung besteht für mich darin, dass man den Text von den Aufgaben trennt. Es gibt also an einer Stelle die Informationen und den Kontext – sozusagen das Wissen über das Projekt und über das, was passiert ist. Und dann gibt es die Aufgabenliste. 

Wir haben uns vorhin schon kurz darüber unterhalten, wie wir intern nach Vorlage des SAFe-Vorgehensmodells unter anderem die Priorisierung mit WSJF durchführen. Sie müssen sich im Projekt nämlich überlegen, was jetzt gerade wirklich wichtig ist. Es bringt nichts, dem längst obsolet gewordenen Gantt-Chart hinterherzuhecheln, wenn an einer ganz anderen Stelle das gesamte Projekt in die Luft zu fliegen droht. Und das gilt auch dann, wenn der Vorstand sich eigentlich nur für den Gantt-Chart und kein Stück für Details interessiert. Oder nein: Das gilt nicht auch dann, sondern gerade dann. “Liebe Frau Vorstand, möchten Sie von den Details des Projekts verschont werden und einfach nur regelmäßig einen neuen Status haben? Dann schlage ich vor, dass Sie dem Projektteam die Freiheiten geben, selbst zu entscheiden, welche Dinge angegangen werden müssen und wie umgeplant werden soll. Sie lassen sich regelmäßig den Stand der Ergebnisse melden. Und wir berichten natürlich auch über die Wahrscheinlichkeit, dass alles in die Binsen geht, und was wir tun, um das zu vermeiden.” Das wäre ein guter, für alle Seiten sinnvoller Kommunikationsansatz.

Aber lassen wir uns nicht von Hierarchiepolitik in Großkonzernen ablenken. Ihr autarkes und starkes Projektteam will ständig mit den Aufgaben arbeiten. Sie werden analysiert. Sie werden diskutiert. Sie werden kommentiert. Sie werden priorisiert. Sie werden in Sprints eingeplant. Sie werden hinsichtlich ihrer Komplexität oder vielleicht sogar in Sachen Aufwand beschätzt. Sie werden mit tatsächlichen Arbeitsschritten oder Arbeitszeiten bebucht. Der Status wird berichtet. Die Daten werden aggregiert und auf Teamebene (oder sogar auf den höheren Ebenen des SAFe-Frameworks) zusammengefasst. Kurz gesagt: Wir betreiben Projektmanagement. Die einen agiler, die anderen weniger agil.

Hier stellen Confluence und Jira im Zusammenspiel eine ihrer großen Stärken unter Beweis: Die Systeme unterstützen uns sehr schön dabei, die jeweiligen Arbeitsergebnisse und Zwischenstände anzuzeigen und zu teilen. Sie können auf einer Confluence-Seite sogenannte Jira-Gadgets (also Übersichtsgrafiken auf unterschiedlichen Aggregationsebenen) einbinden und mit meinem Inhalt zusammen präsentieren. Sie haben auch die Möglichkeit, einzelne Aufgaben oder Aufgabenlisten aus dem Projekt oder seinen Teilprojekten zu integrieren. Diese Informationen sind immer dynamisch. Das bedeutet, dass sie sich automatisch verändern, wenn die Quelle sich verändert. Auf diese Weise lassen sich zum Beispiel Berichte und Übersichten zum Projekt erstellen, die sich stets automatisiert aktualisieren.