Tag Archives: PM Excellence

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…

Er hätte mich nie um Rat gefragt, denn ich kenne mich ja nur mit Projektmanagement aus. Während eines Mittagessens „unter guten Bekannten“ erzählte er mir von seinem Geschäft, dass alle Werke dank guten Controllings solide schwarze Zahlen schrieben, der Vertrieb gute Aufträge akquiriere, aber das EBIT trotzdem nicht richtig zum Fliegen käme. Im Verlauf unseres Gesprächs entwickelte er die Erkenntnis, dass seine Firma ihren Gewinn eigentlich nicht mit ihren Produkten verdiente, sondern mit der Auslieferung derselben an ihre Kunden – in Projekten.

Das Unternehmen passt nicht mehr zum Markt

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.

Die Betriebswirtschaft denkt zu egozentrisch

Um sich dem Problem zu nähern, müssen wir etwas in die Vergangenheit der Betriebswirtschaftslehre (BWL) zurückblicken. Linie und Matrix entstammen einer produktorientierten, egozentrischen Sicht auf den Markt. Bis in die 1990er Jahre hinein nahm der Markt dankbar das Angebot an Produkten und Dienstleistungen an. Es konnten sich über technologische Führerschaft teilweise monopol- oder oligopolistische Angebotsstrukturen entwickeln, in denen die Kunden sich mangels Alternativen nicht selten in einem Abhängigkeitsverhältnis von ihren Lieferanten befanden. Die BWL befasste sich daher dem ökonomischen Prinzip folgend mit der Beschreibung, Analyse und Optimierung der Produktion und der Organisation des laufenden Betriebs und entwickelte entsprechende Managementmodelle.

Mit zunehmender Globalisierung sind spätestens seit der Jahrtausendwende viele traditionelle Marktführerschaften infrage gestellt worden. Internationale Konkurrenz, preisgünstigere und/oder einfachere, aber ausreichende Alternativprodukte aus Schwellenländern mit niedrigeren Herstellungskosten, Transparenz von Preisen und Leistungen über moderne Kommunikationsmittel usw. haben die Dominanz der hiesigen Industrie in vielen Branchen stark angekratzt. Hinzu kommt eine Emanzipation der Kunden, gefördert durch die neue Konkurrenzsituation auf der Anbieterseite. Der Wandel vom Anbietermarkt zum Kundenmarkt fordert mehr Flexibilität von den Produzenten, aber auch das Einhalten von Verkaufsversprechen, da sonst Claims d.h. Abzüge, Nachbesserungen, Margenverluste usw. drohen.

Etablierte Managementansätze und –systeme sind nicht ausreichend

Diesen Wandel haben viele Unternehmen (wie das meines Bekannten), aber auch die moderne BWL noch nicht ausreichend nachvollzogen. Die etablierten Managementansätze und -systeme, die auf wiederkehrende Abläufe und bekannte Einflussfaktoren ausgelegt sind, sind für das Management von (Kunden-)Projekten in sich je Auftrag ändernden oder gar unbekannten Rahmenbedingungen nicht ausgelegt und ungeeignet. Oft ist sogar nicht einmal das Bewusstsein für diese Verschiedenheit der Charakteristika und Imperative von laufendem und Projektgeschäft vorhanden. Projekte aus der Linie sinnvoll zu führen scheitert daher mehrheitlich an den Zeit- und Zielkonflikten bei den Linienmanagern sowie an daraus resultierenden Ressourcenkonflikten zwischen Linie und Projekten.

Vorhandene Strukturen sind überfordert

Ein projekt-getriebenes Geschäftsmodell (zur Definition vgl. meinen Beitrag „Passt Ihre Organisationsstruktur noch zu Ihrem Business ?„) verlangt nach einer Organisationsstruktur und -kultur, bei der dem die Unternehmensrendite-erwirtschaftenden Projekt die gleiche Priorität eingeräumt wird wie dem mit dem Projekt zu erstellenden und auszuliefernden Produkt. Lokale Optimierung der KPIs von Werken oder Abteilungen, deren Erfolge in unprofessionellen Projekten wieder zunichte gemacht werden, darf nicht mehr allein im Fokus des Managements stehen, sondern die Gesamtoptimierung. Sinnvollerweise legt man daher die P&L-Verantwortung mit entsprechenden, weitreichenden Kompetenzen in die Hände der die Klammer von Auftrag bis Abnahme bildenden Projekte.

Die vorhandene Linie bzw. Matrix schafft meist die abteilungsübergreifende Querschnittsfunktion nicht wegen Zuständigkeits- oder Kompetenzkonflikten. Projekte brauchen aber eine Führung über Abteilungsgrenzen hinweg, nicht nur auf Unternehmens- sondern bereits auf Auftrags- bzw. Projektebene. Außerdem ist bis heute auf der Führungsebene der Abteilungen eher eine funktionale und „klassisch“-betriebswirtschaftliche Kompetenz anzutreffen als ausgeprägte Projektmanagement-Skills.

Das Unternehmen dem Geschäftsmodell anpassen

Abhilfe kann nur eine Transformation der Organisation und Unternehmenskultur hinsichtlich bestehender Hierarchien, Zuständigkeiten, Vergütungen, Denkweisen und Prioritäten usw. zu einer auf das Projektgeschäft ausgerichteten Organisation schaffen. In einer reinen Linienorganisation bedeutet dies den Wechsel zu einer Matrix Funktion-Projekt, bei bereits Matrix-organisierten Unternehmen die Einführung einer dritten Dimension auf Augenhöhe mit den bestehenden Levels. Was hierzu notwendig und zu beachten ist habe ich in meinem Beitrag „Turnaround für Unternehmen mit einem projekt-getriebenen Business“ beschrieben.

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.

Es sollte nicht verkannt werden, dass diese Transformation einigen, mittel- bis langfristig angelegten Aufwand bedeuten und auf viele Ängste und Widerstände in der etablierten Organisation treffen wird. Siemens-Chef Peter Löscher hat dies 2010 in seinem Vergleich mit einer „Lehmschicht“ sehr illustrativ beschrieben: Die Mitarbeiter in den Projekten brauchen sie dringend für die Qualität und den Erfolg ihrer Arbeit, das Top-Management will sie als überlebensnotwendig erkannt durchsetzen, und das mittlere Management muss mitziehen – oder gehen. Das war es auch, was ich schlussendlich meinem Bekannten für sein Unternehmen geraten habe.