Jusletter IT

In allen Bereichen der öffentlichen Verwaltung werden organisatorische Abläufe durch den Einsatz der Informationstechnologie (nachfolgend auch kurz: IT) unterstützt, genauso wie dies in allen anderen Wirtschaftszweigen der Fall ist. Was für die Privatwirtschaft E-Business oder E-Commerce¹ sind, wird in der Verwaltung mit den Begriffen Verwaltungsinformatik und E-Government² beschrieben. Für die Justizverwaltung kann man auf den spezifischen Begriff der Rechtsinformatik zurückgreifen; in diesem Bereich ist die österreichische Justizverwaltung mit IT-Anwendungen wie dem Grundbuch und dem Firmenbuch international führend, wobei sich diese Anwendungen dadurch auszeichnen, dass sie sowohl verwaltungsintern als auch –extern mit einer einzigen technischen Basis funktionieren. Vergleichbare Privatunternehmen wie z.B. Banken und Versicherungen so wie auch andere Bereiche der öffentlichen Verwaltung müssen hingegen für die internen Geschäftsprozesse auf technologisch ältere Systeme zurückgreifen und nach außen separate, technologisch modernere Lösungen einsetzen, die allerdings einen gegenüber den internen Systemen eingeschränkten Funktionsumfang aufweisen. Die österreichische Justizverwaltung erspart sich so, zwei Welten über mehr oder minder komplexe Schnittstellen miteinander zu verbinden und die Daten zu synchronisieren, was stets mit Aufwand verbunden und fehleranfällig ist.

Es ist völlig klar, dass die Justizverwaltung in ihrem Handeln durch den Stufenbau der Rechtsordnung determiniert ist und sein muss. Da allerdings rechtliche Normen auch Verfahrensregeln beinhalten, kann nicht gesagt werden, dass die Informationstechnologie keinen Einfluss auf die Rechtsnormen hat. So wäre etwa die Festlegung, dass das Firmenbuch ebenso wie das Grundbuch in seiner elektronischen Form das Original darstellt (und im Gegensatz zur Vergangenheit Ausfertigungen auf Papier als Kopien zu werten sind) ohne die Verfügbarkeit entsprechender Technologien nicht möglich.

Auch für die Rechtsinformatik gilt daher eine wechselweise Beeinflussung von Recht und Informationstechnologie als Herausforderung, die im Interesse der übergeordneten rechtsstaatlichen Zielsetzungen konstruktiv gestaltet werden muss. Technik darf allerdings nicht zum Ausschluss von Bürgerinnen und Bürgern von der Inanspruchnahme ihrer Rechte führen.³ Tatsächlich kann für die österreichische Rechtspraxis festgestellt werden, dass der Zugang zum Recht durch die führende Stellung der österreichischen Justizverwaltung bei der Nutzung der Informationstechnologie insgesamt sogar deutlich verbessert und erleichtert wurde. Wer will ernsthaft behaupten, dass die Publikation von Rechtsnormen im Amtsblatt der Wiener Zeitung oder von Versteigerungsedikten am Schwarzen Brett eines Amtshauses etc. der jederzeitigen und dauerhaften Verfügbarkeit solcher Texte im Internet dem Ideal des (auch aus sozialer Sicht) barrierefreien Zugangs zum Recht besser entsprochen hätte.

Wir müssen also davon ausgehen, dass die Informationstechnologie nicht nur vorgegebene rechtliche Vorgaben umsetzt, sondern selbst auch auf die Inhalte rechtlicher Normen und Verfahren maßgeblichen Einfluss ausübt.

Häufig finden wir in den IT-Bereichen von Unternehmen und Organisationen folgende Überzeugung: Zuerst soll sich der Anwender entscheiden, was er tun will und wie ihm dabei die EDV helfen kann. Dann entwickeln wir ein Informationssystem, das diese Anforderungen erfüllt. Wenn der Anwender das Pflichtenheft oder ein anderes Spezifikationsdokument unterschrieben hat, darf er – eigentlich – nichts mehr ändern. Leider tut er das immer wieder und deshalb – so die Meinung der IT-Bereiche – laufen auch die meisten IT-Projekte nicht optimal. Kurz und ein wenig polemisch zusammengefasst: «Das einzige, was stört, ist der Anwender». Die Anwender hingegen beklagen regelmäßig eine mangelnde Serviceorientierung der IT und fühlen sich von dieser unzureichend informiert oder sogar eingeengt.

Tatsächlich können innovative und im Sinne übergeordneter Ziele optimale Lösungen auf diese Weise nicht entstehen. Zweifellos ist es unverzichtbar, dass die Anwender, in unserem Fall wären das die juristisch ausgebildeten und in ihrem angestammten Fachgebiet tätigen Mitarbeiterinnen und Mitarbeiter der Justizverwaltung, ihre Zielvorstellungen und damit verbundene organisatorische und personelle Maßnahmen formulieren. Allerdings ist es von Vorteil, diese möglichst früh mit den zur Verfügung stehenden informationstechnologischen Möglichkeiten abzugleichen. Denken wir etwa daran, dass die Übermittlung von Informationen über größere Entfernungen vor nicht allzu langer Zeit mit erheblichen Kosten verbunden war, die mit der Entfernung stiegen. Heute ist das kein variabler Kostenfaktor mehr, die für erhöhte Sicherheitsanforderungen notwendigen Maßnahmen können gerade im Justizbereich erheblich sein, sind allerdings weitgehend einmalige Fixkosten. Welchen Wert hätte ein detailliert ausgearbeitetes Pflichtenheft von Anwendern, das hier von technisch und wirtschaftlich veralteten Prämissen ausginge. Während in diesem Fall wohl jeder Anwender über die aktuellen Rahmenbedingungen Bescheid weiß, stehen mit mobilen Lösungen (insbesondere Tablets) oder neuen Methoden der Datenanalyse (Stichwort «Big Data») heute Optionen im Raum, die hinsichtlich ihrer Auswirkungen auf das, was man sich realistisch zum Ziel setzen könnte, nur im Dialog von Juristen und Technikern voll ausgelotet werden können.

Der Lösungsversuch, die von Informatikern als wankelmütig oder unpräzise empfundenen Anwender mit immer detaillierteren Anforderungsbeschreibungen quasi festzunageln, folgt dem von Watzlawick beschriebenen Lösungsprinzip: Mehr desselben. Die theoretisch und praktisch fundierte Empfehlung Watzlawicks lautet allerdings: Weniger desselben! Wenn es ohnehin nicht möglich ist, den Anwender an Anforderungsänderungen zu hindern, sollten wir diese nicht nur (passiv) einplanen, sondern ihn (aktiv) anregen, seine bisherigen Anforderungen immer wieder im Verlauf eines Projektes zu überdenken und zu ändern.

Immer mehr Unternehmen und Organisationen haben aus den oben beschriebenen Problemen die Konsequenz gezogen, sogenannten agilen Vorgehensmodellen zu folgen, deren gemeinsame Basis das «Agile Manifest» aus dem Jahr 2001 ist. Dieses wurde von einer Gruppe erfahrener Softwareentwickler in einer mehrtägigen Klausur in einer Lodge in den Wasatch Mountains von Utah formuliert. Das Manifest trifft Aussagen zu vier Wertepaaren, die zueinander in einem natürlichen Spannungsverhältnis stehen und nennt zwölf Prinzipien, die das Wesen agiler Softwareentwicklung ausmachen. Hier die Aussagen zu den Werten, denen sich agile Softwareentwicklung verpflichtet fühlt.

Abbildung 1: Das agile Manifest – die Werte (Quelle:www.agilemanifesto.org)

Das agile Manifest lässt viel Spielraum für die Umsetzung, wenn auch zwölf Prinzipien genauere Leitlinien für die Projektarbeit vorgeben. Hier zitiere ich fünf dieser Prinzipien, auf der Website (www.agilemanifesto.org) können auch die anderen sieben nachgelesen werden:

• Liefere funktionierende Software regelmäßig innerhalb weniger Wochen oder Monate und bevorzuge dabei die kürzere Zeitspanne.
• Funktionierende Software ist das wichtigste Fortschrittsmaß.
• Heiße Anforderungsänderungen selbst spät in der Entwicklung willkommen. Agile Prozesse nutzen Veränderungen zum Wettbewerbsvorteil des Kunden.
• Fachexperten und Entwickler müssen während des Projektes täglich zusammenarbeiten.
• Die effizienteste und effektivste Methode, Informationen an und innerhalb eines Entwicklungsteams zu übermitteln, ist im Gespräch von Angesicht zu Angesicht.
• Die besten Architekturen, Anforderungen und Entwürfe entstehen durch selbstorganisierte Teams.
• In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann und passt sein Verhalten entsprechend an.

Noch weiter ins Detail gehen verschiedene «Schulen» der Agilität, auf die hier nicht im weiter eingegangen werden kann.⁴

Die österreichische Justizverwaltung unter Leitung ihres CIO Dr. Martin Schneider nimmt bei der Umsetzung agiler Vorgehensmodelle in der öffentlichen Verwaltung eine Vorreiterrolle ein. Der Autor dieses Beitrages hatte Gelegenheit, bei drei solchen Projekten in einer beratenden Rolle mitzuwirken und konnte sich so aus erster Hand über die praktische Umsetzung informieren.

Hier ist nur von Projekten die Rede, in denen Software zwecks Unterstützung von Geschäftsprozessen entwickelt und/oder angepasst wird. Rein technisch ausgerichtete Migrationsprojekte oder Infrastrukturprojekte bleiben außer Betracht, sie sind auch kein relevantes Anwendungsgebiet für agile Methoden.

Agiles Vorgehen nimmt die Tatsache ernst, dass kein Anwender sich die ideale Software vorweg in allen Details vorstellen kann und dass kein Informatiker die Anforderungen der Anwender, seien diese auch noch so detailliert beschrieben, zu Beginn eines Projektes hinsichtlich der damit verbundenen Konsequenzen zur Gänze versteht. Die agile Methodik in ihrer puristischen Ausprägung verzichtet in der Planungsphase auf die Erarbeitung eines detaillierten Pflichtenheftes, was ihr immer wieder den Vorwurf eines ungeplanten und damit riskanten Vorgehens einbringt. Hier beschreitet die österreichische Justizverwaltung durchaus eigenständige Wege, da sehr wohl zu Beginn sehr detailliert geplant wird und auch die Anwenderanforderungen, allerdings bereits in gemeinsamen Arbeitsgruppen von Juristen und Informatikern, sehr detailliert erarbeitet werden. Dieser Dialog allein bringt schon wichtige Erkenntnisse auf beiden Seiten und sichert die Machbarkeit der Lösungskonzepte ungleich besser ab als ein von Anwenderseite allein erarbeitetes Lasten- oder Pflichtenheft.

Allerdings wird dieses derart detaillierte Spezifikationsdokument als Grundlage der weiteren Projektarbeit gesehen, nicht jedoch als endgültige und detaillierte Vorgabe. Im Planungsdokument zur Weiterentwicklung des Grundbuches (Projekt GB Neu, Rel. 1.6) war eine interdisziplinäre Arbeitsgruppe über einen Zeitraum von drei Monaten in insgesamt 29 ganztägigen Workshops tätig und erarbeitete ein umfangreiches Anforderungsdokument mit zahlreichen grafischen Darstellungen von Prozessabläufen, Bildschirmlayouts etc.. In der Präambel formulierte die Arbeitsgruppe, der Grundbuch-Rechtspfleger und Informatiker der BRZ GmbH sowie der Autor dieses Beitrages als Moderator und Methodenberater angehörten, wie folgt: «Dieses Dokument stellt die fachlichen Anforderungen an GB neu Rel. 1.6 aus Sicht der Mitglieder der Arbeitsgruppe nach bestem Wissen vollständig dar. Durch die intensive gemeinsame Arbeit im Team wird das Dokument als gemeinsames Ergebnis gesehen, mit dem sich alle Mitglieder der Arbeitsgruppe identifizieren. Die jedem Teammitglied eingeräumte Möglichkeit der Dokumentation einer abweichenden Meinung wurde nicht in Anspruch genommen. Nach Genehmigung durch das Bundesministerium für Justiz ist diese Feinspezifikation die verbindliche Grundlage für die weitere Projektarbeit. Der Komplexität der zu bearbeitenden Materie entsprechend können natürlich Unklarheiten und sogar Lücken oder Fehler nicht ausgeschlossen werden. Die Mitglieder der Arbeitsgruppe stehen daher während der weiteren Arbeiten für Rückfragen und Abstimmungen gerne zur Verfügung, um den Erfolg des Realisierungsprojektes zu sichern». Mittlerweile ist dieses Projekt mit einer Durchlaufzeit von nahezu 3 Jahren und einem Planaufwand von zirka 8.600 Personentagen termingerecht und mit einem Gesamtaufwand von zirka 7.000 Personentagen erfolgreich abgeschlossen werden.

Dieses Beispiel zeigt, wie gut die österreichische Justizverwaltung diese Art des Vorgehens mittlerweile beherrscht.

Wenn der Autor, der nicht Jurist ist, die agile Vorgehensmethodik hier auch aus einer vertraglichen Perspektive betrachtet, ist dies in diesem Umfeld riskant. Wenn er dies trotzdem tut, so aus der Erfahrung der interdisziplinären Zusammenarbeit mit den Experten des österreichischen Bundesministeriums für Justiz, die immer zu einem konstruktiven Dialog bereit und am Austausch komplementärer Erfahrungen interessiert sind. Daher mögen diese Gedanken als Anstoß zu einer weiterführenden Diskussion verstanden werden, denn wer wäre berufener, zu diesen Fragen abschließend Stellung zu nehmen als Dr. Martin Schneider, der als hochrangiger Jurist die IT des österreichischen Justizressorts seit vielen Jahren erfolgreich leitet.

Jedes Projekt agiert auf Grundlage von Vereinbarungen zwischen den beteiligten Organisationseinheiten bzw. Unternehmen, wobei diese mehr oder minder explizit und formalisiert sein können. Ob diese Vereinbarungen tatsächlich als schriftlicher und detaillierter Vertrag vorliegen oder nicht, ist unwesentlich. Professionelle Verträge sind immer ein wesentlicher Erfolgsfaktor, wenn allerdings ein Vertrag in Widerspruch zum tatsächlichen Vorgehen im Projekt steht, behindert dies die Projektarbeit ebenso schwerwiegend, wie ein guter Vertrag diese wesentlich erleichtert. Daher wird hier von einer Vertragsphilosophie gesprochen, die dem Handeln aller Beteiligten zugrunde liegen sollte, wenn ein Projekt mit sinnvoll eingesetzten agilen Elementen abgewickelt werden soll.

Zunächst muss festgehalten werden, dass für wesentliche Teile eines typischen IT-Projektes klassische Vertragsmodelle sinnvoll und notwendig sind, so z.B. für Planungsleistungen, Lizenzen, Infrastrukturleistungen etc. Ebenso gilt dies für die Schätzung des Gesamtaufwandes des Vorhabens (z.B. anhand eines Lastenheftes). Dies ist ja schon eine notwendige Grundlage für die Entscheidung, ob ein Projekt überhaupt gestartet werden soll.

Für jene Teile des Projektes, in denen die Entwicklung und/oder die Anpassung von Software erfolgt, gelten teilweise andere Regeln. So wird für die agil abzuwickelnden Teile des Vorhabens ein passendes Leistungsvolumen (Skills, Kapazitäten, Durchlaufzeit) eingekauft. Die Laufzeit des Entwicklungsprojektes wird in gleich lange Intervalle («Iterationen/Sprints») aufgeteilt, wobei in jeder Iteration Software geliefert wird, die vom Kunden/Anwender getestet werden kann.

Die Feinsteuerung erfolgt aufgrund einer Aufwandsbewertung der Features («Story Points»/Planaufwand). Die konkreten Iterationsinhalte werden zu Beginn nur grob geplant, nach jeder Iteration erfolgt eine Aktualisierung, die Inhalte der jeweils nächsten und meist auch übernächsten Iteration werden im Detail fixiert.

Ein Spezifikum agiler Projekte ist auch die unveränderliche Iterationsdauer («Time Boxing»), innerhalb einer Iteration nicht realisierte Features werden nicht durch Terminverschiebung nachgeliefert, sondern zurück in den «Backlog» gestellt und in einer späteren Iteration eingeplant.

Auf Grundlage der tatsächlichen Iterationsergebnisse wird eine regelmäßige Hochrechnung durchgeführt, die je Iteration abgearbeiteten Features («User Stories») werden in dem für agile Projekte typischen «Burn-Down-Chart» dargestellt. Letztlich ist dies die allgemein bekannte Earned-Value Darstellung, wenn auch mit umgekehrten Vorzeichen: man zeigt, wie die noch zu leistende Arbeit reduziert wird («burned down»), während der Earned Value die bereits geleistete Arbeit abbildet.

Da am Ende jeder Iteration funktionierende Software geliefert werden muss, zeichnet sich die Fortschrittsmessung solcher Projekte durch eine höhere Aussagekraft und Robustheit gegenüber Fehleinschätzungen des Arbeitsfortschritts aus. Werden Abweichungen vom geplanten Fortschritt je Iteration («Velocity») erkannt, bleibt auch solchen Projekten nicht erspart, darauf mit den üblichen Maßnahmen zu reagieren, die da sind:

• Projektabwicklung optimieren
• Features streichen/zurückstellen
• Kapazität erhöhen
• Zusätzliche Iterationen und Verschiebung des Endtermins.

Als Auftraggeber von Projekten mit agilen Elementen ebenso wie als Projektmanager muss man darauf achten, die spezifischen Herausforderungen der mit agiler Methodik abgewickelten Projektteile zu erkennen und darauf adäquat zu reagieren. Wird in Projektaufträgen bzw. in Verträgen eine Philosophie der Projektsteuerung festgeschrieben, die das nicht richtig adressiert, gerät man entweder in einen vertragsfreien Raum oder man kollidiert ständig mit Vertragsbestimmungen, die nicht zum tatsächlichen Vorgehen passen.

Generell muss man feststellen, dass agile Softwareentwicklung im Kern auf einer Aufwandsverrechnung beruht, da ein fixer Werklohn mangels detaillierter Ergebnisbeschreibung nicht definiert werden kann. Wie oben schon ausgeführt, steuert das österreichische Justizministerium dem insofern etwas entgegen, als sehr wohl eine umfassende Spezifikationen zu Beginn erarbeitet wird. Da diese allerdings als offen für Veränderungen während der Umsetzung gesehen werden, resultiert daraus trotzdem eine gewisse Unschärfe. Diese wird allerdings nach den Erfahrungen des Autors von Entscheidungsträgern, die agilen Methoden skeptisch gegenüber stehen bzw. damit keine Erfahrung haben, stark überschätzt: Jeder weiß aus eigener Erfahrung, dass Fixpreise trotz detaillierten Lasten und Pflichtenheften durch Change Requests regelmäßig ausgehebelt werden. Daher erscheint eine Aufwandschätzung mit eingestandener Bandbreite sowie einer darauf aufsetzenden Projektsteuerung durch Burn-Down-Charts als die ehrlichere und de facto auch wirksamere Methode. Man muss allerdings der hier sichtbar gemachten Unsicherheit ins Auge blicken können, wozu nicht alle Auftraggeber bereit und in der Lage sind; dass Dr. Schneider diesen Mut schon vor Jahren gehabt hat, zeichnet ihn aus und ist wohl eines seiner Erfolgsgeheimnisse.

Eine zentrale Herausforderung ist also: professionelle Projektsteuerung ersetzt detaillierte Ergebnisdefinition. Abweichungen werden früh erkannt, können aber nicht an einem vertraglich fixierten detaillierten Pflichtenheft gemessen werden. Daher müssen geeignete Prozesse (auch vertraglich) definiert und gelebt werden.

Sachlich gesehen ist das Vertrauen in die Angemessenheit der Aufwände des Realisierungspartners ein entscheidender Erfolgsfaktor. Das Aushandeln des Verzichts auf Features, um das Budget und den Endtermin zu halten, funktioniert nur, wenn die vom Auftragnehmer geschätzten Realisierungsaufwände vom Auftraggeber als angemessen und nachvollziehbar gesehen werden. Regelmäßig als überhöht empfundene Aufwandschätzungen können durchaus auf Architekturmängel zurückzuführen und daher in Wirklichkeit korrekt sein, sie sind also einer unzureichenden Projektvorbereitung geschuldet. Damit bleibt aber das Problem gleich, nur die Ursache liegt in der Vergangenheit.

Dass die Umsetzung der IT-Projekte des Bundesministeriums für Justiz durch die im Eigentum des Bundes stehende BRZ GmbH erfolgt, mag auf den ersten Blick die Entscheidung für agile Vorgehensmodelle erleichtert haben. Wer allerdings die Details kennt, weiß, dass die BRZ GmbH gegenüber seinen Auftraggebern genauso zu agieren hat wie jedes andere Softwareunternehmen und durch mangelhafte Projektplanung und Projektsteuerung resultierende Mehraufwände genauso beim Auftraggeber zu Buche schlagen (müssen).

Agile Projekte können daher nur gelingen, wenn es aktive und sachkundige Mitwirkungsleistungen des Kunden gibt, wobei dies im Falle einer externen Beauftragung nicht nur für die Anwenderbereiche («Business») gilt, sondern auch für die IT-Abteilung des Auftraggebers. Dies erscheint gegenüber einem Wasserfallmodell als Mehraufwand. Der Autor dieses Beitrages wagt die Behauptung, dass der tatsächliche Gesamtaufwand gut gemanagter agiler Projekte eher geringer, aber anders verteilt ist als bei Projekten nach einem Wasserfallmodell.

Ebenso gilt: Agiles Vorgehen erfordert eine vertrauensvolle Zusammenarbeit. Dafür müssen Bereitschaft und Fähigkeit zu interdisziplinärer Arbeit und Social skills bei allen Beteiligten verfügbar sein.

Der Einsatz agiler Vorgehensmodelle in der österreichischen Justizverwaltung hat mittlerweile einen hohen Reifegrad erreicht und kann daher als Best Practice Modell für andere Verwaltungsorganisationen herangezogen werden. Die Entscheidung für diesen Paradigmenwechsel erforderte Mut, die erfolgreiche Umsetzung Professionalität. Beides war durch Dr. Martin Schneider gegeben und hat zu beachtlichen Erfolgen geführt; sich auf Erreichtem auszuruhen ist allerdings nicht sein Stil und so kann man gespannt sein, mit welchen Innovationen er uns in den nächsten Jahren überraschen und erfreuen wird.

---

 

Gerhard Friedrich, Beirat der act Management Consulting GmbH und geschäftsführender Gesellschafter der 360PM Dr. Friedrich & Partner KG, Parkring 10, 1010 Wien, Österreich, gfr@360pm.eu; http://www.360pm.eu.