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.
Ich möchte Ihnen heute von zwei Beispielen erzählen, die zeigen, warum Earned Value Management sich hierzulande nicht der ihr zustehenden Beliebtheit erfreut, und wie man in diesen Fällen die Vorbehalte überwunden und die Nutzung erfolgreich betrieben hat. Ich möchte vorausschicken, dass ich ein „Fan“ der Methode bin, gerade weil sie sich so universell und unkompliziert einsetzen lässt und mit ein paar einfachen Formeln valide Statusbestimmungen und Prognosen für das Projektmanagement ermöglicht.
in dieser Zeit etwas Neues (Produkt oder Service) entwickeln müssen. Das wäre mit der Entwicklung der neuen Baureihe erledigt. Die Serienproduktion fiele nicht unter den Begriff „Projekt“. Es hält aber auch die Zulieferer nicht davon ab, der Sichtweise ihrer OEMs in der Entwicklung und laufenden Produktion ihrer Komponenten zu folgen.
sind neben technischen auch kreative Tätigkeiten gefordert. Der Faktor Unsicherheit und Risiko ist also unvergleichbar höher, Ideenaustausch, Kommunikation und Zusammenarbeit im Team sind kritische Erfolgsfaktoren.
Vier Hauptursachen
keinen wirklichen Draht hatte. Die „menschliche“ Folge: Er investierte den Großteil seiner Zeit und Aufmerksamkeit in das Produkt, während die Planung und Koordination des Projekts hinten runter fiel. Als das Projekt zum Krisenprojekt wurde, fokussierte er sich auf das, was er am besten konnte – und wieder litt das Projektmanagement.
Wenn man ein Projekt erfolgreich leiten will, braucht man dafür wie in anderen Berufen auch eine methodische Ausbildung, die das Erkennen der Erfordernisse in der jeweiligen Projektsituation und den situativ sinnvollen, virtuosen Umgang mit den einschlägigen Werkzeugen einschließt. Das ist gewissermaßen wie bei einem Handwerk, und so gibt es auch im Projektmanagement Lehrlinge, Gesellen und Meister.
Einem guten Projektmanager wären daher die Fehler in unserem Beispiel nicht unterlaufen, denn er hätte sich in seinem und im Projektinteresse von Anfang an um eine klare Ziel- und Aufgabendefinition gekümmert und die Unterstützung seiner Vorgesetzten konsequent eingefordert. Seine Planung hätte auf realistischen Annahmen gefußt, und er hätte Risiken und Abweichungen frühzeitig erkannt, eskaliert und gegengesteuert.
Damit er das auch tun kann, braucht er noch einen weiteren Skill: Führungsqualitäten. Er ist der Manager seines Projekts, er verantwortet das Ergebnis und muss sein Team und auch seine Chefs so steuern, dass jeder seinen Teil zum Ganzen einbringt. Keine leichte Aufgabe, besonders wenn das Unternehmen nicht projekt-affin tickt. Und nicht jeder ist der Mensch für eine Führungsrolle, fühlt sich darin wohl. Wenn er aber seinen Job ernst nimmt, wird er Projektmanagement inklusive Führung konsequent anwenden. Andernfalls wird er bald zum Sündenbock, wenn das Projekt schiefgeht. Keine sehr motivierende Perspektive, oder was für opportunistische PM-Nomaden, die sich so manchmal Projektleiter nennen…
Ein weiterer, häufiger Faktor als Ursache für Projekte in Schieflagen ist die Zeit. Damit meine ich weniger die Dauer, die dem Projekt zur Ausführung gegeben wird. Die sollte eigentlich immer realistisch bemessen sein, nicht durch Wunschdenken oder willkürlich festgelegt. Das heißt, sie muss auf realistischen Schätzungen der ausführenden Mitarbeiter unter Berücksichtigung der Abhängigkeiten und Rahmenbedingungen basieren. Damit fällt „Dauer“ für mich unter die Rubrik „Mensch“, also ob der Projektleiter einen kompetenten Job macht.
Tatsächlich zeigen einige Statistiken, z.B. die auf 
Der überwiegende Teil der Projektprobleme entsteht also aus einer mangelhaften Unterstützung durch die ausführende Organisation, was wiederum in der Projektkultur, dem Mindset des Managements und der etablierten Organisationsstruktur begründet ist.
Kommunikation im Team, zwischen Team und Organisation und zwischen den Abteilungs-Silos untereinander – weil ungewohnt – nicht funktioniert, oder wenn die Kompetenzen des Projektmanagers nicht seiner Verantwortung entsprechen.
Genau darin lag die Krux. Das Unternehmen war produktorientiert in einer funktionalen Linienorganisation gewachsen. Dem sich internationalisierenden Markt folgend war vor einigen Jahren eine Matrix mit einer nach Regionen aufgestellten Vertriebsorganisation eingeführt worden. Jetzt war es Zeit, sich kundenorientiert dem projekt-getriebenen Geschäft anzupassen, denn hier verlor man oft und viel von der in der funktionalen Matrix erarbeiteten Rendite. Die Kundenprojekte mussten letztlich rentabler werden, damit das Unternehmen insgesamt rentabel arbeitete.
Begleitet werden muss dies vom Aufbau interner Projektmanagement-Kompetenz und eines eigenen Karrierepfades innerhalb der neuen Dimension. Da Projektmanagement „Managen unter erschwerten Bedingungen“ bedeutet, eignet sich dieser nebenbei auch hervorragend zur Führungskräfte-Entwicklung im Unternehmen. Es werden dabei universelle Management-Skills gefördert wie Stress-Resistenz und Risiko-Sensibilität, Methoden-Knowhow, strukturiertes Vorgehen, soziale Kompetenz und Führungsqualitäten. Somit dürfte die Dritte Dimension für motivierte Mitarbeiter auch attraktiv genug sein, mit unternehmensspezifischem Fachwissen den Schoß der Fachabteilung in Richtung Projektmanagement zu verlassen, und rasch an Akzeptanz im Unternehmen gewinnen.
Typischerweise haben in Deutschland die meisten Unternehmen eine gewachsene, funktionale Organisationsstruktur mit Fach- und Zentralabteilungen. Besonders in unseren traditionell starken Branchen wie dem Maschinen- und Anlagenbau ist das so, v.a. im Mittelstand, aber auch bei Beratungs- und IT-Unternehmen, Ingenieur- und Entwicklungsbüros usw. Oft finde ich in solchen Betrieben ein ausgeprägtes Eigenleben der Abteilungen und Produktionsstandorte, Silo-Denken und mangelhafte Kommunikation und Zusammenarbeit vor, ganz zu schweigen von der abteilungsübergreifenden Arbeit in Projekten.
Projektmanagement als Kernkompetenz und starke Abteilung. Schluss mit Fachspezialisten, die nebenher die Projekte leiten. Projektmanagement braucht volle Aufmerksamkeit auf Planung, Koordination und Führung – wie Unternehmensmanagement ja auch. Zeit und Zielkonflikte zweier Herzen in der Brust des Projektleiters sind Gift für die Konzentration auf’s Wesentliche. Auch seine „Denke“ muss projekt-getrieben und nicht mehr produkt-verliebt sein. Jeder bringt seine Kernkompetenz ein, der Ingenieur sein Fachwissen und der Projektmanager seine PM-Skills, zum gemeinsamen Gelingen des Ganzen. Vorgehensstandards machen es replizierbar und kalkulierbar.
Fach- und Zentralabteilungen als Dienstleister für die Projekte. Dabei hilft Ihnen der zuvor durchlebte Change in der Projektkultur Ihres Unternehmens. Die Zuarbeit der Ingenieure dient nicht mehr nur dem perfekten Produkt, sondern der vertragsgemäßen Auslieferung des Gewerks. Der Einkauf hat nicht nur die Konditionen sondern auch die Liefertreue (vielleicht auch mal mit zielführenden Zugeständnissen) im Blick. Legal verprobt partnerschaftliche Zusammenarbeit, QM prüft in den Projekten die Produktqualität und treibt die Prozessqualität voran (Continuous Improvement). HR sucht nach Skills statt nach Positionen, schult für kommende Projektbedarfe, kümmert sich um Corporate Identity unter den Mitarbeitern, usw.
Nach der „reinen Lehre“ musste mein Programmmanagement einen Mehrwert stiften, der durch das Management der einzelnen Komponenten nicht erreichbar gewesen wäre. Meine Aufgaben lagen also insbesondere in der Koordination der Komponenten, dem Betrachten der Schnittstellen untereinander und mit der Kunden-Organisation, und darin, dass ich den Nutzen des Programms für den Kunden sicherstellte. Diese strategische Nutzensicht für den Kunden unterscheidet im Programmmanagement fundamental von der primär von der operativen Lieferung geprägten Sicht eines Projektmanagers (PM).