Jährliche Archiv: 2018

Es hat sich schon viel gebessert. Noch bis vor nicht allzu langer Zeit standen die Agilen Jünger dem klassischen Projektmanagement und seinen Projektmanagern unversöhnlich gegenüber: Agil als einzige, neue Wahrheit in der Durchführung von Projekten war hip und der durchgeplante Wasserfall sowas von gestern. Folglich proklamierten auch eine große Anzahl von Unternehmen den Hype „Wir sind jetzt agil“ – und fielen mehrheitlich böse auf die Nase. Dies möchte ich heute einmal etwas analysieren und für einen Mittelweg werben.

Agil ist man nicht auf Ansage, es ist eine Geisteshaltung, ein Mindset, der sich so sehr vom bisher gewohnten Unternehmens-Paradigma der Hierarchien, Planung und Kontrolle unterscheidet, dass sie zunächst einmal für solche „gewachsenen“ Unternehmen zumindest schwer verdaulich ist. Bedenkt man all die liebgewordenen Fürstentümer und Vorschriften-Komfortzonen: Es braucht eine lange, behutsame Transformation, angefangen beim Top- und Mittelmanagement bis in die Projekte hinein, um den Kulturwandel zu partizipativem, kollektivem und selbstorganisiertem Handeln zu vollziehen.

Fallbeispiel Sanierung eines “klassischen” Projekts

In meinem heutigen Beispiel tauchen wir ein in ein typisches deutsches Unternehmen, das seine Kernprozesse von der Akquise über die Auftragsbearbeitung und ‑ausführung bis zur Fakturierung und dem Mahnwesen beschreiben, standardisieren und mit IT-Unterstützung digitalisieren wollte. Dabei hatte man – wie immer – der starken internen IT-Abteilung den Auftrag zur Umsetzung erteilt und sich hernach in den Fachabteilungen wieder auf das Tagesgeschäft konzentriert. Nach einem halben Jahr traditionellem Projektmanagement in der IT wurde der Pilot stolz in der ersten Niederlassung vorgestellt. Business wie IT waren enttäuscht von der Reaktion der jeweils anderen Seite. Über ein Jahr der schmerzvollen Nachbesserungen folgte, bis das Produkt halbwegs gebrauchsfähig war, Kosten und erhoffter Time-to-Market liefen davon. Die Geschäftsleitung zog die Notbremse.

Aktive Beteiligung des Business

Mein erster Vorschlag zur Sanierung war, die Fachseite aktiv am Projekt zu beteiligen, sie in den Driver Seat zu setzen. Das ist in vielen „IT-Projekten“ ungewöhnlich (!?!), denn erstens hat das Business für „sowas“ ja keine Zeit und zweitens meist keinerlei Erfahrung, wie man das macht. So auch in diesem Fall: Fehlanzeige bei Anforderungs- und Projektmanagement. Also: Grundlagen einführen und dedizierte Projektmitglieder aus den Fachbereichen einfordern. Die IT-Leitung lehnte sich zurück und erwartete unsere Bauchlandung. Dennoch hatten wir in relativ kurzer Zeit eine kleine, sehr engagierte Truppe zusammen, die sich erstmals eingehende Gedanken über die Prozesse machte, die da von der IT abgebildet werden sollten.

Gleichzeitig schaute ich mich im Unternehmen etwas um und fand ein paar weitere Projekte anderer Fachseiten, die sich just mit den gleichen Themen beschäftigten und bei der IT dafür Ressourcen angefordert hatten. Die Geschäftsleitung erkannte die Sparpotenziale und Synergien sofort. In den „Fürstentümern“ regte sich zunächst Widerstand gegen die nun folgenden Konsolidierungen. Ich gab meinen Team-Mitgliedern eine kleine Einführung ins Veränderungsmanagement und holte Leute aus den anderen Abteilungen mit in unser Boot.

Was hat das bisher mit Agil zu tun? Nun, eine Grundvoraussetzung für alle agilen Vorgehensweisen ist eine intensive, aktive Beteiligung der Fachseite, die ja die Product Owner stellen muss. Und die müssen wissen, wie das Ergebnis aussehen soll, also was die Definition of Done in Reviews und Tests sein soll. „Klassisches“ Anforderungsmanagement wie bei unserer Prozessdefinition mag zwar nicht genau ins agile Bild passen, aber wir haben immerhin bereits hier mit allen Beteiligten sehr iterativ gearbeitet, und in vielen Teilen haben wir auch Elemente aus dem Design Thinking genutzt.

Das zeigt aber auch, dass in Unternehmen, die noch nicht gesamtheitlich agil „ticken“, ein hybrider Ansatz zielführender sein kann als einer „by the books“. Das kompetent und der Situation angemessen beurteilen zu können und zu entscheiden ist letztlich die Aufgabe und der Skill eines guten Projektmanagers, den es ja so in der agilen Welt auch nicht gibt.

Anforderungen: „klassische“ Ermittlung der Features und User Stories

Mithilfe einer kleinen Unternehmensberatung, die uns bei der Anforderungs- und Prozessbeschreibung unterstützte, kamen wir in allen Bereichen gut voran. Und siehe da: Viele der Abteilungs-Prozesse überschnitten sich oder waren sogar weitgehend gleich ! Aus diesen ca. 80% ließ sich mit etwas Abstraktion und Konzentration auf das Wesentliche am Ende ein einziger, gemeinsamer End-to-End-Ablauf mit nur ganz wenigen aufgabenindividuellen Schleifen machen. Eine signifikante Einsparung für den kommenden Entwicklungsaufwand und ein riesiges Synergievolumen für das Unternehmen aus der Prozessoptimierung und –standardisierung !

Grobschätzung statt definitiver Budgets spart Zeit

Ein zweiter, häufiger Hinderungsgrund, Projekte tatsächlich agil durchzuführen, liegt in der Beharrlichkeit der Auftraggeber auf Managementebene auf „klassischem“ Reporting aus dem Projektmanagement: Wann liefern wir was zu welchen Kosten, wie ist der aktuelle Status gemessen an der Abarbeitung der Planung usw.? In unserem Fall wurde das noch verschärft durch meinen zweiten Vorschlag: Wir wollen von der IT keine definitive Kostenschätzung, sondern auf Basis der Prozessbeschreibungen und der damit involvierten Systemkomponenten eine in der Genauigkeit „Rough Order of Magnitude“. Achtung, jetzt wird’s wieder agil: Damit wollten wir uns eine langwierige, detaillierte Anforderungsdokumentation sparen und schnell an die Umsetzung kommen, die Prioritäten der Backlogs abgestimmt in den Fachteams und auf der technischen Seite mit der IT.

Der Aufschrei war zunächst groß. Die Geschäftsleitung wurde unruhig angesichts großer Zahlen in einem Kostenkorridor von +/- 50%, lies sich aber auf einen mittels Drei-Punkte-Schätzung angenommen Kostenumfang mit Obergrenzen schließlich ein. Viel größer war das Ringen mit der IT-Leitung, sich auf eine solche Kostenschätzung einzulassen, ganz ohne Lasten- und Pflichtenhefte und genaue Kalkulation (die dann wohl doch nicht eingetroffen wäre).

Wir haben viel Zeit verloren, bis wir endlich auf nachdrückliche Anweisung des Vorstands unseren ROoM-Kostenvoranschlag zur Genehmigung des Budgets erhielten. Vielleicht hat etwas geholfen, dass wir im Kompromiss die Konfiguration des ERP-Systems als Basiskomponente der Gesamt-Topologie auf „klassische“ Projektmanagement-Weise akzeptiert haben. Am Ende ist dieses Teilprojekt aber eben doch nicht mit der geplanten Zeit ausgekommen und hat sogar den oberen Korridor, den wir trotz „genauem“ Kostenvoranschlag zuließen, noch knapp gerissen…

Gemeinsame Entwicklung: gemeinsame Probleme und Akzeptanz

Die übrigen Nicht-ERP-Komponenten sind wir iterativ-inkrementell angegangen. Aber auch hier hat es Wochen der Überzeugungsarbeit gebraucht, um die IT davon abzubringen, zuerst genaue Anforderungsdokumentationen erstellen zu wollen. Wir hatten Features und User-Stories, die sich an den Prozessschritten entlang hangelten. Wie die genau aussehen sollten, das wollten wir, Fachseite mit der IT, gemeinsam erarbeiten und eine nach der anderen iterativ und lauffähig umsetzen. Für die Fachseite war das sowieso alles neu, aber man konnte sich jetzt richtig einbringen und „sein Baby“ bauen – die Akzeptanz war hoch, auch auf Auftraggeberseite im Management.

Auch die Entwickler in der IT fanden den Ansatz gut, hatten sie doch bei Fragen und Abstimmungen immer einen direkten Ansprechpartner auf der Businessseite. Und die Dokumentation sollte erst erstellt werden, wenn man fertig war und feststand, wie es schlussendlich gemacht worden war. Nur die IT-Leitung tat sich zunächst mit der Aufgabe der Projektmanagement-Kontrolle insbesondere in der Ressourcenplanung und der Transparenz in Fortschritt und auch Problemen schwer.

An die Fachseite stellte die Vorgehensweise die schwierige Anforderung, immer genügend eingearbeitete und miteinander abgestimmte Ansprechpartner vorzuhalten, die möglichst auch aus dem prallen Leben der Praxis kamen, aber dennoch das Abstraktionsvermögen hatten, nach den definierten Prozessen und nicht nach der eigenen Gewohnheit zu urteilen.

Erfolg schafft Vertrauen und Motivation

Die Geschäftsleitung wurde schon langsam mangels sichtbarer Fortschritte ungeduldig. Aber hinter den Kulissen haben wir mit jedem Meeting von Business- und IT-Leuten Vertrauen untereinander aufgebaut, den Sand aus dem Getriebe bekommen, sind ein gemeinsames Entwicklungsteam geworden und haben durch offene und ehrliche Kommunikation schließlich auch die IT-Leitung in unser Boot bekommen.

Und es begann, Spaß zu machen, gemeinsam etwas zu erschaffen, Probleme zu überwinden, Erfolge zu sehen und auch schließlich dem Lenkungskreis zeigen zu können. Die übergreifende Koordination der verschiedenen Entwicklungs-Streams habe ich „klassisch“ geplant, mit der Earned Value Methode verfolgt und berichtet, ebenso die inkrementellen Rollouts an das Business und in die Niederlassungen. Das war das „Nervenfutter“ für die Geschäftsleitung…

Fazit: Agil ist Veränderung und braucht Zeit

Der hybride Projektansatz hat in den agilen Teilen etwas länger gebraucht, bis er „zum Fliegen“ kam. Das ist zum größten Teil den Widerständen gegen gefühlten Kontrollverlust ohne eine „ordentliche“ Planung und der Angst vor zu viel Transparenz geschuldet, aber auch der anfänglichen „Unbedarftheit“ der Fachseite in der Projektarbeit und den “Notwendigkeiten” im Projektmanagement (insbesondere Anforderungs- und Changemanagement) und –Führung.

Unsere agilen Vorgehensweisen haben sich als mindestens so effektiv wie das „klassisch“ durchgeführte ERP-Teilprojekt erwiesen, jedoch als wesentlich effizienter, wenn auch sicher noch entwicklungsfähig. Mit der Übung werden wir immer besser, der sichtbare und schnelle Erfolg wirkt als Motivator und überzeugt mehr und mehr Stakeholder im Unternehmen bis hinauf in den Vorstand. Aber es bleibt dennoch ein langer Weg, bis alle agil arbeiten und auch der Lenkungskreis das „Agile“ vollständig versteht.

Agil ist kein Allheilmittel, und aus meiner Praxis kann ich überdies bestätigen, dass Agil nicht für jedes Unternehmen und jedes Projekt vollständig oder ausschließlich geeignet ist. Es hilft aber zumindest in hybriden Projekten an den passenden Stellen eingesetzt, effizienter und flexibler zu sein, und klassisches Projektmanagement hat weiter seine Existenzberechtigung – in den Händen von Projektleitern, die ihr Handwerk verstehen. Vielleicht ist dann auch der Titel „der lange Weg zu mehr Agilität“ an dieser Stelle zutreffender.

Lesen Sie einen weiteren Artikel über hybrides Projektmanagement…