Agile E-Akten-Projekte: Wie das Projektteam arbeitsfähig wird

Ich möchte heute Erfahrungen aus Projekten vorstellen, in denen ich in der Rolle des externen Beraters Verwaltungen bei der Einführung von Dokumentenmanagementsystemen (DMS) begleitet habe. In diesen Projekten bin ich von einer agilen Standardmethode ausgegangen, dem sogenannten „Scrum“. Aber diese Methode ist für Projekte in der Softwareentwicklung entwickelt worden, in dem ein Team aus 3 bis 9 Fachleuten 8 Stunden am Tag in einem Projekt arbeitet. In einem 3-Wochen-Intervall (einem typischen „Sprint“) werden da locker 400 bis 1.000 Arbeitsstunden geleistet.

In unseren DMS-Projekten erbringen die meisten Projektbeteiligten (bis auf den Projektleiter, pardon: den „Product Owner“) die Projektarbeit „nebenbei“ – also mit vielleicht zwei bis vier Stunden pro Woche. Das ändert alles im Projekt. Und deshalb haben wir – die anderen Projektbeteiligten und ich  – Scrum kräftig an die Situation „Organisationsprojekte in Verwaltungen“ anpassen müssen.

Eine dieser Anpassungen betrifft die Zusammensetzung und Arbeitsweise des Projektteams. Das ist mein Thema heute.

Cross-funktionale Teams bilden

Wir beziehen uns hier auf die Situation „DMS-Software ist beschafft und wird nun in den Abteilungen Schritt für Schritt eingeführt“.

Dafür sieht Scrum die Bildung eines „cross-funktionalen Teams“ bzw. „Umsetzungsteams“ vor. Dieses Team erledigt selbstständig alle Arbeiten und trifft alle dafür notwendigen Entscheidungen.

Das klingt ganz einfach, beruht aber in der Praxis auf ganz ungewohnten und auch nicht ganz einfachen Voraussetzungen.

Die erste Voraussetzung ist, dass alle Fachkenntnisse vorhanden sind, um eine Aufgabe abzuschließen. Deshalb muss das Team folgende Fähigkeiten umfassen, die in der Regel drei unterschiedlichen Spezialistengruppen entsprechen:

1. Kenntnisse über das DMS-Projekt aus Sicht der Gesamtorganisation. Also Leute, die wissen, warum eine Verwaltung DMS einführt, welchen Nutzen sie sich davon verspricht, welche Anforderungen das Lastenheft definiert hat, welche Potenziale das DMS hat und welche Wünsche sich alles unter dem Himmel des Möglichkeitsraums tummeln dürfen.
   Meistens sind das Kollegen aus einem Stabsbereich der Verwaltung, aus einer Orga-Abteilung und/oder aus der IT.
2. Kenntnisse über die spezifischen Prozesse in einem Funktionsbereich (Amt, Fachbereich, Sachgebiet). Wer muss mit wem zusammenarbeiten, um eine Aufgabe (einen Vorgang) abzuschließen? Welche Hilfsmittel (Tools, Vorlagen usw.) gibt es dafür schon? Wie sind die Prozesse grob strukturiert (Meilensteine, verzahnte Prozesse)?
   Das sind fast immer Anwendervertreter aus dem Funktionsbereich selbst.
3. Schließlich Experten des Customizings und der Programmierung im DMS. Diese Fachleute müssen im gegebenen DMS Masken anpassen, Wertelisten von Metadaten anlegen und (wenn das DMS das vorsieht) Skripte schreiben können.
   Diese Rolle wird häufig von Vertretern des DMS-Lieferanten gespielt, zum Teil auch in Arbeitsteilung mit Key Usern aus der Verwaltung selbst (die zwar Masken designen können, aber keine Skripte programmieren oder ähnliche Konstellationen).

Diese drei Gruppen müssen in direkter Kommunikation an einem Tisch sitzen (wobei das auch ein virtueller Tisch sein kann, also in Form von Videokonferenzen organisiert). Zum Beispiel muss Programmierer Christian direkt mitbekommen, wenn Anwendervertreterin Bianca beschreibt, wie sie die Ergebnisse eines Serienbriefs schon bislang im Outlook in eine Ordnerstruktur nach Empfängern einsortiert. Nur wenn Christian das gut versteht, kann er sich Lösungen überlegen, wie das im DMS gehen könnte. Und Optimierungsvorschläge machen.

Hindernis 1: Die klassische Arbeitsteilung

Selbstverständlich ist das überhaupt nicht. Oft haben wir nämlich in Software-Projekten Kommunikationswege wie in Abbildung 2:

• Nicht die Anwendervertreter aus dem Fachbereich („Prozess-Spezialisten“) sitzen im Umsetzungsteam, sondern jemand aus der zentralen Stabsstelle („Orga-Spezialist“). Er – nennen wir ihn Alexander – erfasst die Anforderungen und gibt sie an den Lieferanten weiter. Dabei übersieht und vergisst Alexander aber regelmäßig Dinge. Dafür ist nicht die Zeit, und außerdem weiß er sowieso viel mehr über Prozesse als Bianca.
• Die Lieferanten sind auch nicht darauf eingestellt, direkt ihre Programmier-Spezialisten ins Umsetzungsteam zu entsenden. Sie schalten auf ihrer Seite einen Projektleiter dazwischen, Dennis in unserem Falle, der dann wiederum seine Informationen an Eric, den Programmierer im Back-Office weitergibt.

Abbildung 2: Ein cross-funktionales Nicht-Team

Das ist alles kein böser Wille, sondern beruht auf vorhandenen Strukturen. Hersteller sind intern oft nicht nach Prozessen, sondern nach Funktionen organisiert. Es gibt beim Lieferanten also nicht einen einzigen Eric, der die Software programmiert und customized, sondern fünf oder zehn. Einer ist zuständig für das Handling von E-Mails, eine anderer für das Hinterlegen von Vorlagen und Eric Nr. 3 für die Maskengestaltung. Agile Projekte funktionieren dann besser, wenn der jeweilige DMS-Hersteller schon intern in cross-funktionalen Teams arbeitet.

Hindernis 2: Missverständnis über die Führungsrolle

Ein weiteres erhebliches Hindernis ist die fehlende Klarheit aller Beteiligten über ihre Rollen.

In einem DMS-Projekt gibt (vor allem) drei Rollen:

• Eine Führungskraft, die dem Projekt oder dem Teilprojekt einer Abteilung, den Auftrag erteilt. Dazu gehört, dass sie den beabsichtigten Nutzen definiert und das Budget in Form von Geld und Zeit zur Verfügung stellt.
• Die Anwender als „Endkunden“ des Projekts, die ihre Anforderungen definieren.
• Das Umsetzungsteam, das Lösungen für die Anforderungen sucht und realisiert.

Wird diese Konstellation eingehalten, kann das Projekt eine hohe Geschwindigkeit erreichen. Im schnellen Ping-pong zwischen Team und Anwendern werden schnell optimierte Lösungen realisiert.

Schwierig wird es, wenn die Führungskraft sich in die Lösungssuche einmischt. In einigen Projekten habe ich erlebt, dass die Führungskraft zu jedem Review kommt (das ist positiv, drückt Interesse und Wertschätzung aus) und dort alle gefundenen Lösungen in Frage stellt (ist eher hinderlich). „Sie haben festgelegt, dass die Dateinamen künftig nicht mehr mit dem Datum beginnen? Das finde ich aber völlig ungewohnt, und das haben wir doch in der Richtlinie von 2011 ganz anders festgelegt. Da sollten Sie noch mal drüber schauen!“

Hier argumentiert die Führungskraft aus ihrer Rolle als Anwender, der Dateien ablegt und sucht. Sie argumentiert nicht aus ihrer Rolle als Auftraggeber. Aus ihrer Rolle als Auftraggeber kann sie einen Nachweis des Nutzens verlangen: „Wenn die neue Regel umgesetzt wird, übersteigt dann der künftige Nutzen den Aufwand der Umgewöhnung? Wie könnte man das messen?“ Aber sie kann nicht bestimmte Lösungen einfordern, auf deren Umsetzung sie besteht. Denn als Anwender ist die Führungskraft einer unter vielen – und da gilt die Regel, dass man es nicht allen Recht machen kann. Also muss das Umsetzungsteam Entscheidungen treffen dürfen, die am Anfang vielleicht nur 70% der Anwender einleuchten. In diesem Falle wäre die Führungskraft eben unter den 30% Zweiflern – und müsste das akezptieren.

Denn alles andere – die Führungskraft als der Super-Anwender, dessen Meinung alle anderen überstimmt – führt zu Endlosschleifen im Projekt und zu einem demotivierten Umsetzungsteam, das irgendwann entnervt hinwirft, weil nichts vorwärts geht. Teams aber, denen man Entscheidungskompetenz bezüglich der Lösungen einräumt, erfahren ein überwältigendes Gefühl der Selbstwirksamkeit – und sie beginnen, zu fliegen.