In letzter Zeit erreichen uns vermehrt Anfragen zum Thema „Agiles Projektmanagement“. Zum Beispiel sollen wir vor Führungskräften einer Verwaltung oder auch erstmal eines Dezernats einen Vortrag darüber halten oder auch schon gleich einen Workshop dazu moderieren.
Aus unserer Sicht ist das eine gute Methode, agiles Arbeiten erst einmal zu „beschnuppern“. Projekte sind zeitlich und vom Ressourcenbedarf her begrenzt. Man muss nicht gleich die ganze Organisation umkrempeln.
Heute möchte ich den Unterschied zwischen „klassischem“ und „agilem“ Projektmanagement an einem aktuellen Beispiel vorstellen – der Einführung eines Dokumentenmanagement-Systems (läuft auch unter dem Stichwort „Digitalisierung“ oder „E-Akte“).
Herkömmliches Projektmanagement
Das klassische Vorgehen bei der Einführung eines DMS Software funktioniert folgendermaßen:
- Jemand möchte DMS einführen. Zum Beispiel hat der OB vom eGovernment-Gesetz des Landes gehört. Oder das Rechenzentrum hat Werbung gemacht. Oder ein Dezernent hat an einer Fachkonferenz teilgenommen, auf der DMS als das ultimative Mittel zur Rationalisierung aller Prozesse mittels Worksflows gepriesen wurde. /1/
- Die IT-Abteilung wird beauftragt, die Beschaffung in die Hand zu nehmen. Sie erfasst alle Anforderungen und erstellt ein Lastenheft. Oder jemand von der IT geht auf eine IT-Messe und lässt sich von drei, vier Herstellern Prospekte geben. Daraus wird dann eine Art Anforderungsliste erstellt.
- Es wird ein Endtermin festgelegt, bis wann das DMS flächendeckend im Einsatz sein soll.
- Die IT legt der obersten Führung (OB, Landrat …) einen Antrag vor, der die Anzahl der benötigten Lizenzen, die ungefähren Kosten und die benötigten Stellen enthält. Daraus ergibt sich ein Budgetrahmen.
- Die Leitung genehmigt das Budget, evtl. nach längeren Verhandlungen mit der Kämmerei, die den Nutzen bezweifelt.
- Die Projektphasen werden in Produktauswahl, Implementierung (d.h. Aufbau der Hard- und Software und Anpassung der Software, Testen ihrer Funktionsfähigkeit), Schulen der Anwender und Roll-Out der Software eingeteilt.
Diese Art des Projektmanagements nennt man das „Wasserfallmodell“, weil der Projektfluss wie bei einer Kaskade von einer abgeschlossenen Projektphase in die nächste strömt.
Symptome des Scheiterns
Solche Projekte scheitern sehr häufig.
Dabei ist „Scheitern“ nicht immer absolut zu verstehen. Vielmehr unterscheiden wir drei Stufen des Scheiterns:
Stufe 1: Software wird für alle Prozesse eingesetzt, erzielt aber nur einen Teil des möglichen Nutzens.
Stufe 2: Software deckt nur einen Teil der Prozesse ab, für die sie angeschafft wurde.
Stufe 3: Software wird überhaupt nicht eingesetzt.
Stufe 1 ist eigentlich die gefährlichste, weil die Projektverantwortlichen das Scheitern gar nicht richtig merken oder sich zumindest nicht eingestehen wollen. Natürlich, die IT sieht auch, dass viele Anwender am neuen DMS „vorbei“ arbeiten: die Datenmengen auf den Windows-Laufwerken wachsen nach wie vor. Auch im DMS gibt es keine wirklichen Teamräume, vielmehr hat jeder Einzelne oder jedes Sachgebiet noch „seine Dokumente“, die es eifersüchtig gegen Zugriff von außen schützt.
Aber das DMS ist doch flächendeckend ausgerollt! Jeder Anwender hat eine Lizenz, die Updates werden regelmäßig eingespielt. Das Wasserfallmodell ist zuverlässig abgearbeitet worden Na ja, und ein paar Rückständige, die an alten Arbeitsmethoden festhalten und mit dem DMS nicht richtig warmwerden, gibt es doch überall.
So reden sich die Verantwortlichen ihren Misserfolg schön.
Dass sie das tun können, liegt an einer fragwürdigen Definition von Erfolg. Wir sprechen oft von Erfolg, wenn wir alle ToDo-Listen abgehakt haben. Das heißt, wenn die Datenbank-Server richtig installiert, 400 Client-Lizenzen ausgerollt und die gleiche Anzahl von Anwendern in der Software-Bedienung geschult wurden.
Aber Software per se hat überhaupt keinen Nutzen. Ein DMS-Programm auf einem Client ist erst einmal nur verbrauchter Massenspeicher. Erst wenn das neue System dazu beiträgt, dass Anwender ihre Arbeitsweisen verbessern können, stiftet es einen Nutzen /2/. Das Ändern von Arbeitsweisen und Abläufen führt dazu, dass die Verwaltung Geld und die Mitarbeiter Stress und Ärger sparen. Erst wenn dies gelingt, kann man von einer erfolgreichen Softwareeinführung sprechen.
Jeder Prozess ist anders, und nur die Mitarbeiter kennen ihn
Die erste Erfahrung in DMS-Projekten ist: nur die künftigen Anwender wissen, wo der Nutzen eines DMS liegen kann. Dazu zwei Beispiele:
- Das Personalamt will den Prozess „Stellen besetzen“ im DMS abbilden. Die Abläufe sind hier durch aufwendigen E-Mail-Verkehr gekennzeichnet: eingehende Bewerbungen werden ans Leitung des Fachamtes geschickt, von dort kommen Erstbeurteilungen per Mail zurück usw. Alles wird doppelt und dreifach abgelegt, und Rückfragen seitens der Fachämter sind häufig: „Gibt es denn schon interessante Bewerbungen?“ Usw. Also dauernde Störungen im Arbeitsablauf.
Die Anwender wünschen sich für jede ausgeschriebene Stelle einen Teamraum gemeinsam mit den Führungskräften des Fachamtes. So können alle Beteiligte auf die Dokumente zugreifen; aus der Bringschuld für Informationen wird ein Holrecht. Für das DMS besteht die Herausforderung vor allem in einem differenzierten und gleichzeitig einfach zu bedienenden Berechtigungskonzept, weil auf jeden Teamraum ein anderes Fachamt zu berechtigen ist. - Das Gebäudemanagement der Stadt erstellt häufig Neu-, Um- und Erweiterungsbauten in Eigenregie. Dabei fallen viele Verträge (mit verschiedensten Gewerken), Leistungsverzeichnisse, Pläne usw. an. Es gibt eine Unmenge von Vorlagen, die teilweise individuell gespeichert werden, dann aber nicht aktuell sind.
Im DMS sollen diese Vorlagen übersichtlich geordnet werden. Jedes Musterdokument soll einer Projektart, einer Leistungsphase nach HOAI, ggfls. einem Gewerk und einer Dokumentenart zugeordnet werden. Und es soll nur noch eine gemeinsame Teamversion geben, wenn der Grund der individuellen Speicherung („ich finde ja nie das, was ich suche“), einmal entfallen ist.
Die technische Aufgabe besteht also vor allem in einer Verschlagwortungsmaske im DMS, in dem die einzelnen Merkmale nur noch angeklickt werden müssen, um eine Vorlage eindeutig zu benennen. Die Mitarbeiter versprechen sich eine immense Zeitersparnis, vor allem durch vermiedene Fehlerbeseitigung und Nacharbeit.
Es geht an dieser Stelle gar nicht darum, die Beispiele im einzelnen nachzuvollziehen. Es geht nur um den Eindruck, wie verschieden die Belastungen an den Arbeitsplätzen und damit die Anforderungen an die Verbesserungspotenziale des DMS sind. Und dass nur die betroffenen Mitarbeiter beurteilen können, wo für sie der größte Nutzen liegt.
Die agile Erfahrung, die dem entspricht ist: „Beteilige die Kunden an der Produktentwicklung, entwickle nicht an ihnen vorbei.“ Die „Kunden“ des DMS sind die Anwender, und sie müssen bestimmen dürfen, was gemacht wird und wie es gemacht wird.
Dann gibt es auch keine Akzeptanzprobleme. In beiden Fällen waren die Mitarbeiter total heiß auf das DMS und haben begeistert mitgeholfen, alle nötigen Dokumente und Informationen ranzuschaffen.
Gründe für das Scheitern traditioneller Projekte
Wie kann es dazu kommen, dass die Nicht-Akzeptanz durch die Nutzer als das größte Risiko von DMS-Projekten gilt, wie zum Beispiel das Bundesinnenministerium in seinem Projektleitfaden vermerkt? /3/
Ganz einfach. Nach dem Wasserfallmodell wird der Personalabteilung gesagt:
„Dort gibt es ein Aktenzeichen Stellenausschreibungen, Bewerbungen. Da legen Sie künftig Ihre Dokumente ab. Und vielleicht kommen wir in ein paar Jahren irgendwann dazu, einen Workflow zu programmieren. Aber bis dahin arbeiten Sie einfach weiter wie unter Windows gewohnt.“
Und genauso beim Gebäudemanagement.
Es wird einfach eine neue Software an einem Tag geschult (vielleicht auch an zwei Tagen). Dabei wird auch der Aktenplan gezeigt, der die oberste Windows-Ebene ersetzt (und meist als Korsett empfunden wird). Und darüber hinaus ändert sich – gar nichts.
Agil hingegen heißt, nach und nach die Prozesse einzeln ins neue DMS zu überführen und dabei alte Zöpfe abzuschneiden, Teamabsprachen zu treffen und gleich im DMS abzubilden usw. Dabei bewährt sich eine zweite agile Methode: das Vorgehen in festen Zeitintervallen à 2 bis drei Wochen, den „Sprints“. In jedem Sprint wird ein Prozess ins DMS aufgenommen und praktisch erprobt. Die Anwender können dem Projektteam und dem Lieferanten schnelles Feedback geben und sorgen so für ständige Verbesserung.
Dieses Vorgehen dauert deutlich länger, trifft bei den Software-Lieferanten auf großes Erstaunen – und lässt die Mitarbeiter ihre eigenen Erfolge erzielen.
Anmerkungen
/1/ Zum „Mythos Workflows“ siehe https://agile-verwaltung.org/2016/03/24/mythos-workflows-das-ewige-unerfuellte-versprechen/
/2/ Ward, John ; Daniel, Elizabeth: Benefits Management : Delivering Value from IS and IT Investments. 1. Auflage. New York: Wiley, 2006.
/3/ Bundesministerium des Innern, Referat O 1: Organisationskonzept elektronische Verwaltungsarbeit, http://www.verwaltung-innovativ.de/DE/E_Government/orgkonzept_everwaltung/orgkonzept_everwaltung_node.html
Agile Verwaltung 