S. 45128. Legal as a Project

28.1. Anwaltliche Arbeit als Projekt

28.1.1. Warum brauchen wir Projektmanagement in der Anwaltskanzlei?

Juristische Projektmanagerin ist eine der neuen Rollen, die insbesondere im Legal-Tech-Bereich immer mehr gesucht wird. Das bedeutet nicht, dass auch jede Anwaltskanzlei eine dedizierte Projektmanagerin oder mehrere haben muss - obwohl gerade Großkanzleien dies oft schon haben - aber es ist sehr hilfreich, die Skills und Tools aus dem Projektmanagement zu kennen und zu können. So kann die Rolle der Projektmanagerin auch von unternehmerisch denkenden Anwältinnen übernommen werden. Viele Anwältinnen setzen bereits, ohne es zu wissen, eine Form des Projektmanagements ein, sei es bei der Aufgabenzuweisung, der Zeiterfassung oder der Organisation ihrer Dokumente. Die Tatsache, dass die Arbeit von Anwältinnen oft projektorientiert ist - zB ein Gerichtsverfahren, eine Vertragsverhandlung -, hilft dabei, die Methoden aus dem Projektmanagement zu implementieren.

Projektmanagement-Tools und -Skills helfen Anwältinnen beispielsweise darin, große Arbeitsaufgaben besser zu planen, die Aufgaben zu verteilen und Aufgaben besser zu beschreiben und definieren, was wiederum für alternative Abrechnungsmodelle (Kapitel 9.) essenziell ist. In diesem Kapitel gehen wir auf verschiedenste Aspekte sowohl des klassischen als auch agilen Projektmanagements ein, und wie diese in der anwaltlichen Arbeit einen Mehrwert bieten können.

Wichtig ist auch festzuhalten, dass die Skills und Methoden aus diesem Kapitel nicht nur nützlich sind, wenn man ein Projekt umsetzen will, sondern auch in der täglichen Arbeit einen Mehrwert bringen können.

Zusammengefasst lernen wir aus dem Projektmanagement, um unsere Arbeit besser und effizienter zu gestalten, unser Team besser zu informieren, Risiken zu minimieren und natürlich auch besser mit unseren Mandantinnen zusammenzuarbeiten.

28.1.2. Was ist ein Projekt?

Ein Projekt wird definiert als

S. 452Projekte sind ein beliebtes Vehikel, um Aufgaben zu bewältigen, die sich nicht als Teil etablierter Organisationsstrukturen abbilden lassen, zum Beispiel, weil mehrere Practice Groups/Teams zusammenarbeiten müssen, die dies nicht standardmäßig tun. Auch für Aufgaben, die wenig Standardisierung zulassen (wie beispielsweise komplexe Mandate mit mehreren relevanten Stakeholdern), ganz unabhängig davon, ob organisationseinheitsübergreifend gearbeitet werden muss, kann Projektarbeit eine nützliche Art der Arbeitsorganisation sein.

28.1.3. Klassisches vs agiles Projektmanagement

In den folgenden Abschnitten werden wir sowohl einen Blick auf Elemente des klassischen wie auch des agilen Projektmanagements werfen und sie auf ihre Nützlichkeit hin untersuchen. Doch bevor wir in die Details abtauchen wollen wir uns mit der grundsätzlicheren Frage nach den zentralen Unterschieden der beiden Ansätze befassen.

Die Frage nach agil vs klassisch sollte unserer Ansicht nach funktional und kontextgerecht beantwortet werden. Für die Praxis bedeutet das: Am Anfang steht ein tiefes Verständnis für die Aufgabe, um die es geht. Voraussetzung für eine solche Einschätzung ist die notwendige Feldkenntnis. Fachexperten sind notwendig, um eine möglichst akkurate Einschätzung des Vorhabens vornehmen zu können. Mit Blick auf die Passung der unterschiedlichen Vorgehensweisen interessieren uns hier vor allem erst einmal folgende Fragen:

• Was ist das Ziel unseres Vorhabens? Welches Ergebnis soll erreicht werden?

• Welche Stakeholder sind involviert?

• Wer muss am Ende mit dem Ergebnis leben können?

• Welche Ressourcen haben wir zur Verfügung?

• Wissen wir, was zu tun ist, um unser Ziel zu erreichen?

• Wie hoch schätzen wir den grad an Unvorhersehbarkeit ein?

• ...

Als Methode kann man hier zu einer der vielen frei verfügbaren Project-Canvas greifen, um den eigenen Prozess ein wenig zu strukturieren. Welche Variante ist letztlich nicht entscheidend, da eigentlich immer die gleichen Dimensionen abgefragt werden.

Jetzt haben wir also ein detailliertes Verständnis davon, was wir genau vorhaben. Wie kommen wir jetzt zu einer Einschätzung, ob wir uns eher am klassischen oder am agilen Projektmanagement orientieren wollen? Um eine Antwort auf diese Frage zu finden, kann das altbekannte VUCA-Modell hilfreich sein. Das VUCA-Modell benennt vier Dimensionen: Volatility, Uncertainty, Complexity S. 453und Ambiguity. Als grundlegende Leitlinie kann hier eine Einschätzung des Projekts auf diesen Dimensionen helfen. Wie viel Volatilität, Unsicherheit, Komplexität und Ambiguität haben wir zu erwarten? Je mehr wir mit diesen Dimensionen zu tun haben, desto eher empfiehlt sich ein agiles Vorgehen, da es schnelle Anpassung erlaubt. Ist eine hohe Ausprägung dieser vier Dimensionen allerdings nicht zu erwarten, könnte ein eher klassisches Vorgehen passend sein und effizientere Prozesse ermöglichen.

Letzten Endes geht es immer um die Frage nach Funktionalität im entsprechenden Kontext. Daher lässt sich die Frage nach klassisch vs agil auch nicht allgemeingültig beantworten. Ein und dieselbe Aufgabenstellung kann in dem einen Kontext mit viel Komplexität und Unsicherheit kommen, während sie sich in einem anderen Kontext (zB ein anderes Projektteam) als völlig trivial darstellt. Die genannten Leitlinien können aber dabei helfen, eine für den jeweiligen Kontext funktionierende Einschätzung zu erhalten.

28.1.4. Beispiele anwaltlicher Tätigkeiten als Projekte

Für Anwältinnen kann ein Projekt daher alles sein, was zu einem bestimmten Zeitpunkt als abgeschlossen definiert werden kann. Dazu kann eine einzelne Anfrage, eine bestimmte Transaktion, ein ganzer Rechtsstreit, der Entwurf und die Verhandlung eines Vertrags und vieles mehr gehören. Es können aber auch kanzleiinterne Projekte als solche aufgesetzt werden, zB die Suche und Implementierung eines neuen Tools, Optimierung der Mandantinnen-Onboarding-Prozesse und vieles mehr. Die anwaltliche Tätigkeit als Projekt zu definieren, hilft auch, die Inhalte, den Ablauf und das Ende klarer festzulegen.

Das Ziel ist, mit juristischem Projektmanagement die Angelegenheit so strukturiert zu managen, dass die Erwartungen der Mandantinnen oder internen Kundinnen in Bezug auf Qualität, Budget und Zeit erfüllt werden. Komplexe juristische Projekte, zB die Umsetzung eines neuen Rechtsrahmens in einem Unternehmen, erfordern multidisziplinäre Fähigkeiten (zB Recht, IT und Projektmanagement), eine Möglichkeit, die kommerziellen Anforderungen eines solchen Projekts (Pauschalhonorare, Kostenlimits usw) zu verwalten, und schlussendlich auch die Instrumente, die Aufgaben zu verwalten und auszuführen.

Bei der Planung eines juristischen Projekts sollten diese Punkte berücksichtigt werden:

• klar definierte, vereinbarte und dokumentierte Auftragsbedingungen;

• wie Zeit, Gebühren und Kosten gehandhabt werden;

• transparenter Arbeitsumfang und Ausschlüsse, die sich auf das vereinbarte Honorar beziehen, sowie die Frage, wie sich zusätzliche Arbeiten, die über den Umfang hinausgehen, auf Kosten auswirken;

• S. 454wann und wie die Mandantin über Fortschritte und Kosten informiert wird;

• wie alle Änderungswünsche, die sich auf Umfang, Zeitplan, Kosten oder Ergebnisse auswirken, mitgeteilt, erörtert und vereinbart werden;

• wie ein Projekt gestartet und beendet wird (inkl Nachbesprechung); und

• ein einfacher Plan mit Zeitplan und Ressourcen.

Nicht jede Rechtsdienstleistung lässt sich ohne weiteres als Projekt definieren. Oft haben Unternehmen eine feste Anwältin und eine längere Beziehung, die auch Projekte umfassen kann, aber das ist nicht immer der Fall. Manchmal ist es erforderlich, eine laufende Beziehung aufzuschlüsseln, um ein oder mehrere Projekte zu definieren, aber manchmal wäre ein Projekt auch eine zu aufwendige Definition für eine einfache einmalige Aufgabe. Ein Projekt kann auch klein sein, solange es in sich abgeschlossen ist.

Zusammenfassend lässt sich sagen, dass die meisten Tätigkeiten von Rechtsanwältinnen als (Teil eines) Projekt(s) eingestuft werden können.

S. 45528.2. Was können wir aus klassischem Projektmanagement lernen?

28.2.1. Fixiertes Scoping

Wer sich in irgendeiner Art und Weise schon einmal genauer mit Projektmanagement beschäftigt hat, dem dürften die Begriffe Lastenheft und Pflichtenheft begegnet sein. Wie diese beiden Konzepte funktionieren, werden wir uns gleich ansehen. Vorab aber noch ein paar Vorbemerkungen: Bei klassischen Projektmanagementansätzen dreht sich oft viel darum, den Scope eines Projektes und die erwünschten Ergebnisse direkt zu Beginn möglichst genau zu definieren, um dann einen effizienten Weg der Zielerreichung auszuarbeiten. Dieses Vorgehen ergibt insbesondere dort Sinn, wo es möglich ist, das zu erreichende Ziel präzise zu formulieren, ohne dass ein besonders großes Risiko besteht, dass sich die Zielvorstellung ändern könnte. Das bedeutet, Klarheit über die zugrundeliegenden Annahmen, auf denen eine Zielvorstellung beruht, ist notwendig. Ferner sollten diese Annahmen überprüft worden sein und sie sollten keiner Dynamik unterworfen sein, die während der Dauer des Projekts gewichtige Veränderungen verursachen könnte. Dieses hohe Maß an Klarheit ist die Grundlage für die darauf aufbauende Projektplanung. Der Vorteil ist in diesem Fall, dass eine kleinteilige, präzise Planung, oft in voneinander unabhängigen Projektphasen, erfolgen kann. Dadurch können die zur Verfügung stehenden Ressourcen im Idealfall so effizient wie möglich eingesetzt werden. In all den Kontexten, in denen wir also verhältnismäßig wenig mit der VUCA-Welt zu tun haben, ist dieses Vorgehen eine gute Grundlage, um möglichst ressourcenschonend zum Ziel zu kommen. Allerdings besteht eine erhöhte Anfälligkeit bei zu vielen Veränderungen während der Projektlaufzeit. Das Anpassen von Scope und Projektplan frisst dann besonders viele Ressourcen und kann das gesamte Vorhaben aufhalten oder sogar zum Scheitern bringen.

28.2.2. Detailliertes Planen

Schauen wir uns jetzt eine typische Vorgehensweise im Projektmanagement an, um detaillierte Pläne zu erstellen: Das Lastenheft und das Pflichtenheft. Das Lastenheft wird typischerweise vom Auftraggeber/Kunden/Mandanten erstellt und umfasst alle Anforderungen an die zu erbringende Leistung. Es ist damit der Ausgangspunkt für die Ausgestaltung und Vertragsverhandlung eines Mandats. Ist ein Lastenheft erstellt, folgt die Ausarbeitung eines Pflichtenheftes. Das Pflichtenheft wird von der Partei ausgearbeitet, die die angeforderte Leistung zu erbringen hat und umfasst, wie die im Lastenheft beschriebenen Anforderungen genau umgesetzt werden sollen. Das Pflichtenheft bildet also, sofern es von allen Parteien bestätigt wurde, die inhaltliche Grundlage für die Fachexperten. Man könnte auch sagen: das Lastenheft beantwortet die Frage „Was soll getan werden?“ und das Pflichtenheft beantwortet die Frage „Wie wird das umgesetzt?“. Sind diese beiden Grundlagen erst einmal klar, kann mit dem Zerlegen in Projektphasen, S. 456Teilprojekte und konkrete Arbeitspakete begonnen werden. Das Ziel des Ganzen ist es, am Ende einen detaillierten Projektplan zu haben, der genau beschreibt, wer, wann, was zu tun hat. Das Ergebnis wird dann gerne visualisiert, zum Beispiel mittels des allseits bekannten Gant-Charts. Der Vorteil eines detaillierten Projektplans liegt auf der Hand: möglichst effizienter Einsatz von Ressourcen, indem Arbeitspakete genau in der notwendigen Reihenfolge bearbeitet werden, und dort wo es möglich ist, parallelisiert wird. Alles, was nicht im Projektplan vorgesehen ist, spielt keine Rolle und verbraucht keine Ressourcen.

Nun wissen wir alle, dass selbst die bestgeplanten Projekte nicht immer exakt nach Plan verlaufen. Also braucht es einen Mechanismus, um trotz relativ starrer und detailreicher Projektpläne Anpassungen im Vorgehen zu ermöglichen. Ein Change Request ist genau das. Sollten sich im Laufe eines Projektes zentrale Annahmen verändern oder aus sonst irgendeinem Grund Änderungen im geplanten Vorgehen notwendig werden, kann ein Change Request angefragt werden. In diesem Sinne ist ein Change Request einfach nur eine formalisierte Anfrage, etwas am Projektplan zu verändern. Typischerweise sind Change Requests mit Nachverhandlungen verbunden. Dieses Vorgehen soll außerdem dabei helfen, das Risikomanagement im Blick zu behalten und mögliche Kommunikationsstrategien up to date zu halten, was natürlich deutlich einfacher ist, wenn es eine Liste mit vereinbarten Change Requests gibt, die dokumentiert, welche Anpassungen im Laufe des Projektes vorgenommen wurden.

28.2.3. Das Projektmanagement-Dreieck

Das Dreieck ist eines der grundlegenden Konzepte im Projektmanagement und behandelt die drei zentralen Dimensionen Kosten (Cost), Zeit (Schedule) und Umfang (Scope). Beizeiten wird der Umfang auch als Qualität bezeichnet, für unseren Anwendungsfall gehen wir aber davon aus, dass die Qualität jedenfalls gegeben ist.

Diese drei Dimensionen beeinflussen einander und haben auch auf die anwaltliche Arbeit großen Einfluss. Insbesondere wenn es um die Kalkulation eines ProS. 457jekts geht oder der Umgang genau beschrieben werden muss (Kapitel 9.), sollte man dieses Dreieck im Kopf haben.

Was bedeutet das im anwaltlichen Kontext?

Kosten: Die Kosten scheinen klar - diese beinhalten das anwaltliche Honorar, aber können auch, je nach Projekt, Ausgaben wie Spesen oder Gerichtsgebühren enthalten. Die Höhe der Kosten hängt also auch davon ab, wie schnell ein Projekt abgeschlossen werden muss und welchen Umfang es hat. Weiters ist klar, wenn sich die Dimensionen Zeit oder Umfang ändern, ändern sich auch die Kosten.

Zeit: Der Zeitplan ist insbesondere bei Prozessanwältinnen von den Gerichten fremdbestimmt. Aber auch andere Projekte haben Fristen; von einem Produktlaunch der Mandantin zu einer Firmengründung zu Vertragsverhandlungen. Wenn es nicht klar ist, sind die Fragen „Wann soll es fertig sein? Reicht es in der nächsten Woche?“ zentral auch für das erwähnte Expectation Management.

Umfang: Da an der Qualität nicht gedreht wird, kann es vorkommen, dass über den Umfang geredet werden muss. Genau geht es beim Umfang um die Definition der Leistung - was ist inkludiert und was nicht. Das ist besonders wichtig, wenn die Kosten der Leistung oder des Projekts bestimmt werden sollen, aber auch um Mandantinnen klar den Leistungsumfang aufzuzeigen.

Reichen diese drei Dimensionen wirklich aus?

Eine Frage stellen sich viele Anwältinnen, wenn sie dieses Dreieck sehen: Was ist mit dem Risiko und der dazugehörigen Haftung? Eine kurze Antwort, die im Umfang auch klein ist, kann ein riesiges Haftungsrisiko bedeuten. Aus diesem Grund fügen wir dem Dreieck eine Seite hinzu - das Risiko. Das Risiko kann sowohl auf Seiten der Mandantin eine relevante Dimension sein, aber auch auf Seite der Anwältin. Will die Mandantin beispielsweise eine konkrete Empfehlung in einer unklaren Rechtsfrage, die potenziell einen hohen Schaden, Strafe, oder ähnliches auslösen kann, ist es sinnvoll, dieses Risiko zu beachten - mindestens im Preis.

Das Risiko auf anwaltlicher Seite kann aus vielen Faktoren bestehen, unklare Rechtslage, keine Erfahrung im Rechtsgebiet, aber auch eine große Menge an Projekten, die miteinander konkurrieren. Hier ist die Dimension „Zeit“ ein wichtiger Faktor, aber es kann auch die Entscheidung getroffen werden, dass ein Risiko zu groß ist.

Abb 38: Cost-Scope-Schedule-Risk

S. 45828.2.4. Kommunikationspläne

Projektmanager müssen nicht nur Arbeit und Zeitpläne koordinieren, sondern auch Menschen, wie wir im Stakeholdermanagement gesehen haben. Wurden die Stakeholder definiert, muss auch abgeklärt werden, wer mit wem kommuniziert. Aus diesen Tools lernt man, sich zu notieren, wer von wem und wie informiert wird. Der Kommunikationsplan kann beispielsweise als Tabelle erstellt werden und folgende Spalten enthalten:

• Name

• Rolle: Mandantin/Gericht, Rolle im Unternehmen

• Kontaktperson: Wer ist Ansprechpartner für diese Person bzw wer kontaktiert die Person? ZB geht die Kommunikation ausschließlich von der jeweiligen Rechtsanwältin aus, können Teammitglieder diese Person direkt kontaktieren, wenn ja, wer (Rolle oder Person)?

• Form: Gibt es besondere Formvorschriften oder Gepflogenheiten, die eingehalten werden müssen? ZB die kollegiale Ansprache bei Kolleginnen, wird die Person geduzt? Dies ist auch wichtig, wenn ein Teammitglied beispielsweise die Kommunikation vorbereitet. Müssen immer weitere Personen in CC genommen werden? Von welcher E-Mail-Adresse werden E-Mails gesendet?

• Frequenz: Werden regelmäßige Updates übermittelt? Ist eine regelmäßige Kontaktaufnahme gewünscht/erwartet?

• Kanal: Wie möchte/muss die Person kontaktiert werden? Telefonisch? E-Mail? Elektronischer Rechtsverkehr?

• Freigabe: Gibt es Themen, wo die Freigabe dieser Person erforderlich ist? ZB Freigabe der Klage durch die Geschäftsführerin der Mandantin.

• Information: Gibt es Themen, über die die Person informiert werden muss (zB Status, Zeitplan, Budget)? Kann dies automatisiert implementiert werden?

• Meetings: Sind regelmäßige Treffen oder besondere Termine vereinbart? Gibt es etwas, dass bei Meetings beachtet werden soll (zB lieber online)?

Diese Pläne können natürlich im ersten Schritt auf Rollen (zB Mandantinnen, Gegnervertreterinnen) ausgelegt werden, das hilft auch im Team, klare Regeln über Kommunikation aufzustellen.

Die Basis für solche Kommunikationspläne bildet ein solides Stakeholdermanagement. Es ist also durchaus sinnvoll, zu Beginn eines Projektes eine Stakeholderanalyse zu machen, um festzustellen, wer die relevanten Stakeholder sind. Dazu kann auch eine Risikoeinschätzung gehören: Wer steht dem Vorhaben eher kritisch/eher offen gegenüber? Kann dieser Stakeholder das Projekt verlangsamen oder sogar zum Scheitern bringen? Auf dieser Basis kann dann für jeden Stakeholder die passende Kommunikationsstrategie ausgearbeitet werden.

S. 45928.3. Was können wir aus agilem Projektmanagement lernen?

28.3.1. Kanban

Es ist keine Überraschung, dass wir große Kanban-Fans sind. Kanban ist die vielleicht versatilste Methode, die wir aus dem Projektmanagement lernen können, und kann ohne große Aufwände oder Tools sehr einfach genutzt werden. Es hilft, Transparenz zu schaffen, Arbeit zu visualisieren und kann auch für sich allein außerhalb eines agilen Kontextes eingesetzt werden. Es geht also primär darum, die Aufgaben zu visualisieren und leichter zu verfolgen, als es auf einer (gefühlt unendlich langen) To-do-Liste der Fall ist.

Um Kanban einzusetzen, nutzt man ein Kanban-Board. Dieses Board kann auf einem Flipchartpapier an der Wand umgesetzt werden oder am anderen Ende des Komplexitäts-Spektrums mit komplexen Software-Tools. Ein Kanban-Board kann in Teams verwendet werden, aber auch allein, wenn man die eigene Arbeit besser visualisieren möchte.

In seiner einfachsten Form besteht ein Kanban-Board aus drei Spalten: „Offen/To do“, „In Arbeit/ In progress“ und „Erledigt/Done“. Diese Spalten stellen den Prozess dar, der durchlaufen wird. Das bedeutet auch, dass diese Spalten je nach Anwendungsfall geändert oder erweitert werden können. Als erstes wird meist eine „Warten/Wait“-Spalte eingefügt, wenn man auf externen Input - zB der Mandantin - warten muss. Teilt man sich das Board mit Mandantinnen, kann der externe Input die Gegnervertreterin oder das Gericht sein. Die Spalten können aber auch einen komplexen Prozess zeigen (Ablauf eines Gerichtsverfahrens?), das würde aber im Kanzleikontext nur dann Sinn machen, wenn der Prozess oft genug vorkommt, was beispielsweise in hochspezialisierten Kanzleien der Fall ist.

Aufgaben werden auf Karten (von Post-its zu digitalen Tasks) geschrieben und auf dem Board angebracht. Jede Karte beginnt in der Spalte „Offen“ und wird nach rechts über das Board bewegt, bis sie erledigt ist.

Auf der Karte können sich folgende Informationen befinden:

• Titel

• Aufgabe/Beschreibung

• Zuständige Person

• Frist/Deadline

• Checklisten/To-do-Listen innerhalb der Aufgabe

In digitalen Kanban-Boards können natürlich auch Dateien angehängt werden, Links eingefügt etc.

S. 460Bei Teams helfen Kanban-Boards, die Aufgaben übersichtlich zu gestalten und gleich zu sehen, wer wieviel zu tun hat. Je größer Teams und je umfangreicher die Aufgaben werden, umso komplexer wird auch das Board ausgestaltet. So können beispielsweise Tasks einzelner Teammitglieder gruppiert oder die Aufgaben bestimmten Zeitraumen zugeordnet werden (zB Tasks für KW 31).

Abb 39: Kanban Board

28.3.2. Schätzen

Im agilen Projektmanagement wird jede einzelne Aufgabe geschätzt. Die Schätzung erfolgt nicht in Euro pro Aufgabe, sondern in Punkten (Storypoints). Diese stellen den Aufwand, die Komplexität und den Wert der Aufgabe dar. Im agilen Team ist dieses entfernt von den eigentlichen kommerziellen Entscheidungen, was natürlich in einer Anwaltskanzlei nicht der Fall ist. Es kann aber auch zwischen Anwältin und Mandantin Sinn machen, die Aufgaben vom Preis zu entkoppeln. All diese Methoden helfen, alternative Abrechnungsmodelle (Kapitel 9.), wie Fixpreise und Abos, zu kalkulieren.

Folgende Maßstäbe können zur Schätzung anwaltlicher Aufgaben herangezogen werden:

• Größe/Wert ähnlicher Aufgaben (was war es anderen Mandantinnen wert?)

• Aufwand (Zeit) für ähnliche Aufgaben

• Umfang der Aufgabe genau definieren und gegebenenfalls limitieren (siehe auch Projektmanagement-Dreieck)

• Budget/Wert für die Mandantin

• Als Wert können nur bestimmte Zahlen gewählt werden, was bei der Schätzung hilft. Es ist leichter, zwischen 8 und 13 zu entscheiden, als zwischen 8 und 9. Hierfür werden zB eine modifizierte Fibonacci-Sequenz (0, 1, 2, 3, 5, 8, 13, 20, 40, 100) oder T-Shirt-Größen (XS = 1, S = 2, M = 4, L = 6, XL = 10) hergenommen.

Das Wichtigste in Zusammenhang mit Schätzen ist jedoch immer: Teilen Sie eine Aufgabe in so kleine Elemente, dass diese (Teil-)Aufgaben schätzbar sind!

S. 46128.3.3. DoD

Die DoD - Definition of Done - sind die Kriterien, die eine Aufgabe erfüllen muss, um als „fertig“ zu gelten. In der Softwareentwicklung sind das allgemeingültige Kriterien, die auf jedes Arbeitspaket angewendet werden können. In der anwaltlichen Arbeit sind die Leistungen, die erbracht werden, unterschiedlicher, insofern können sowohl für bestimmte Aufgabentypen Kriterien erstellt werden als auch für einzelne Aufgaben.

Von dem System der DoD können wir insbesondere lernen, konkrete Kanzleistandards zu etablieren, aber auch, Aufgaben an unsere Mitarbeiterinnen oder Dritte besser zu kommunizieren. Es ist daher am einfachsten, mit allgemeinen Kriterien zu beginnen, und die DoD dann an verschiedene Anwendungsfälle anzupassen:

Beispiele für DoD:

• Die Dokumente sind im Kanzleiformat.

• Die zuständige Rechtsanwältin hat das Dokument geprüft und freigegeben.

• Die Mandantin hat das Dokument geprüft und freigegeben.

Geht es um Gerichtsverfahren, können noch spezifische DoD hinzukommen, zB:

• Die Parteien wurden geprüft (Aktiv- und Passivlegitimation, Daten).

• Gerichtszuständigkeit wurde geprüft.

• Kostenverzeichnis wurde hinzugefügt.

• Allfällige Voraussetzungen einer Klagseinbringung wurden geprüft.

• Fristen (insbes Verjährung) wurden geprüft.

Die Frage ist also: Was erwarten wir vom Ergebnis unserer Aufgaben? Dass es rechtlich richtig ist (oder vertretbar argumentiert natürlich), scheint klar. Aber wissen immer alle beteiligten Personen, was die Standards sind, die Qualitätskriterien, die bei Arbeitsaufgaben erfüllt werden sollen? Ganz zu schweigen von den fachlich-inhaltlichen Punkten, die natürlich auch definiert werden können. Dieser Punkt soll dazu inspirieren eine Kanzleilinie zu finden, die gut dokumentiert dann von allen betroffenen Personen umgesetzt werden kann.

28.3.4. Variables Scoping & dynamische Priorisierung

Im Gegensatz zu klassischem Projektmanagement, wo wir versuchen würden, den Scope eines Projekts direkt zu Beginn zu definieren, beispielsweise mittels eines Lasten- und Pflichtenheftes, gehen wir im agilen Projektmanagement anders vor. Am Anfang eines Projektes steht hier ein einfacher Backlog - eine Liste mit Aufgaben, die zu erledigen sind. Dieses Backlog beinhaltet zu Beginn lediglich die Aufgaben, die in den ersten Wochen erledigt werden sollen, und noch nicht alle Arbeitspakete des gesamten Projektes. Das Projektteam entscheidet S. 462dann zyklisch (typischerweise alle 2-4 Wochen) immer wieder neu, was gerade am wichtigsten ist, was als nächstes getan werden soll, und wie viel geleistet werden kann. Auf diese Art und Weise werden aus einem großen Projektplan viele kleine Plannings, die sich auf sehr viel kürzere Zeiträume beziehen, typischerweise eben 2-4 Wochen. Aufgrund der jetzt sehr viel kleineren Zeiträume können trotz aller Komplexität, mit der umgegangen werden muss, relativ belastbare Pläne entstehen. Zusätzlich bieten die kurzen Planungszeiträume regelmäßige Gelegenheiten zur Überprüfung (siehe nächster Abschnitt).

Damit das Backlog immer up to date ist, gibt es typischerweise eine Product Ownerin, deren Aufgabe es ist, permanent mit allen relevanten Stakeholdern in Kontakt zu sein und herauszuarbeiten, welche Aufgaben wie priorisiert werden sollten. Um sicherzustellen, dass die Perspektive der einzelnen Fachexperten einfließt, veranstaltet sie regelmäßige Refinements. Das sind Meetings, in denen das Team zusammenkommt und die Aufgabenpakete gemeinsam so lange bespricht, bis klar ist, was getan werden muss und wie viel Ressourcen dafür vermutlich benötigt werden. So ist unsere Product Ownerin auch gegenüber Stakeholdern dazu aussagefähig, was das Team in den nächsten Wochen leisten kann, und was nicht.

Damit das Backlog nicht einfach zufällig vor sich hin wächst, wird zu Beginn eines Projektes eine Zielvorstellung, möglichst präzise, formuliert. Die Kernfragen dabei sind:

Die Antworten auf diese Fragen bilden die Basis für unser variables Scoping und sollen dabei unterstützen, dass der Scope nicht beliebig wird.

28.3.5. Iterative Prozess- und Fortschrittskontrolle

Bei aller Dynamik und laufender Anpassung brauchen wir natürlich auch im agilen Arbeiten klare Kontrollmechanismen, um sicherzustellen, dass wir in die S. 463richtige Richtung laufen. Letzten Endes geht es bei agilem Arbeiten vor allem darum, so schnell wie möglich so viel Mehrwert wie möglich zu erzeugen.

Um zu verstehen, wie in agilen Projekten die Steuerung und Kontrolle des Projekts funktioniert, müssen wir als erstes eine Unterscheidung verstehen, die bei fast allen agilen Frameworks und Methoden eine zentrale Rolle spielt. Es geht um den Unterschied zwischen Inhalt („Was wird gemacht?“) und Prozess („Wie wird vorgegangen?“). Typischerweise gibt es für jede Ebene sogar eine eigene Rolle. Im wohl bekanntesten Framework, Scrum, hat die Product Ownerin den Hut auf für alle Fragen rund um Priorisierung und die Frage nach den wichtigsten Arbeitspaketen (→ Inhalt), während der Scrum Master damit beschäftigt ist, laufend die Arbeitsprozesse zu optimieren und die Geschwindigkeit zu erhöhen (→ Prozess).

Wenn wir in agilen Projekten von Kontrollmechanismen sprechen, dann legen wir als erstes genau diese Unterscheidung zugrunde. Kontrolle auf Inhaltsebene funktioniert anders als Kontrolle auf Prozessebene.

Beginnen wir mit der inhaltlichen Ebene. Da wir im agilen Modus laufend neu priorisieren und entsprechend auch immer wieder neu entscheiden, was als nächstes getan werden soll, braucht es eine passende Überprüfung dieser Entscheidungen. Dafür gibt es das agile Format Review. Eine Review findet typischerweise alle 2-4 Wochen statt und dient ausschließlich der inhaltlichen Überprüfung des Projektfortschritts. Sie wird von der Person, die die inhaltliche Verantwortung hat, geleitet (im agilen wäre das die PO) und besteht aus drei Phasen:

Eine Review ergibt logischerweise nur Sinn, wenn dabei auch Personen beteiligt sind, die nicht ohnehin Teil des Projektteams sind. Schließlich wollen wir ja echtes Feedback, von echten Stakeholdern, haben, um überprüfen zu können, ob wir in die richtige Richtung laufen. Die Review nimmt mit ihrer Regelmäßigkeit eine zentrale Rolle beim agilen Stakeholdermanagement ein. Keine Review ohne Stakeholder!

Damit bleibt noch die Prozessebene übrig. Auch dafür gibt es ein Format, welches ebenfalls in regelmäßigen Abständen von ca 2-4 Wochen stattfindet: die RetrosS. 464pektive (kurz: Retro). Ziel der Retro ist es, die Performance des Teams zu erhöhen. Dazu wird gemeinsam ausgewertet:

Beim agilen Arbeiten spielt also die Frage nach kontinuierlicher Verbesserung, auch auf der Metaebene, der Zusammenarbeit und der Prozesse laufend eine Rolle. Alle paar Wochen wird gemeinsam überlegt, was noch verbessert werden kann. Daher rührt vermutlich auch die häufige Assoziation von agilen Teams mit hoher Geschwindigkeit. Das kommt nicht von alleine, sondern ist stringent in den Arbeitsablauf eingebaut. Die Retro bietet außerdem einen geschützten Raum (ohne Stakeholder!), in dem das Team mögliche Konflikte frühzeitig besprechen und ausräumen kann, bevor sie zum ernsthaften Problem werden. Und davon, dass sich Konflikte ergeben, dürfen wir ausgehen, insbesondere in sehr komplexen Projekten, die auf gute Zusammenarbeit und Kommunikation angewiesen sind, in denen nicht einfach nebeneinanderher gearbeitet werden kann.

Das Grundprinzip, das beiden Formaten zugrunde liegt, lautet empirische Prozesskontrolle. Sowohl auf inhaltlicher wie auch auf prozessualer Ebene wird laufend auf Basis neuer Erfahrungen und Informationen überprüft, wie der Stand ist und wo Optimierungspotentiale liegen. Die strikte Trennung in zwei getrennten Formaten hilft dabei, den Fokus zu halten und zu konkreten Maßnahmen zu kommen, die direkt umgesetzt werden können.