Alles - Henning Zeumer Projektmanagement

Portfolio ohne Management ergibt unbefriedigende Ergebnisse

„Aber wir haben doch ein Portfolio Management!“ sagte neulich ein CIO, der sich nicht erklären konnte, warum seine Projekte ständig Ressourcenprobleme hatten. Klar: Projekt Portfolio Management (PPM) dient dazu, knappe Ressourcen – und das ist wohl der Normalfall – möglichst nutzenbringend einzusetzen. Nutzen bemisst sich am Beitrag zur (strategischen) Zielerreichung. PPM ist kein aber Tool, sondern ein transparenter und konsistenter Prozess, mit dem man das Portfolio managt (was von einem Tool unterstützt werden kann). Und den muss man konsequent leben, wenn er helfen soll !

Ich möchte drei verfehlte Voraussetzungen als Gründe aufzeigen, warum in meinem Beispiel hier das Projekt Portfolio Management versagen musste:

Wer Ziele erreichen möchte, muss welche haben ! Und die müssen harmonisch aufeinander abgestimmt sein, etwa mithilfe einer Balanced Scorecard oder nach langfristigen (z.B. Wachstum, Marktstellung etc.) und kurzfristigen Zielen (z.B. Innovation, Markteintritt usw.) und Nachhaltigkeit (z.B. das Haus in Ordnung halten). Wenn strategische Ziele konkurrieren oder gar im Widerspruch zueinander stehen, ist das Portfolio nicht effizient und wird die Ziele auch wenig effektiv erreichen.
Setze Prioritäten – und bleibe dabei ! Nach den Prioritäten werden die Ressourcen auf die Projekte verteilt, nicht nach Opportunität oder weil gerade jemand besonders laut schreit. Das heißt nicht, dass man Prioritäten bei besserer Erkenntnis nicht anpassen könnte, aber häufiger Richtungswechsel trägt erwiesenermaßen nicht zur Zielerreichung bei.
Mache nie mehr als Du kannst ! Wer in der Jahresplanung die mit den geplanten Kapazitäten möglichen Projekte in der priorisierten Reihenfolge plant, ist gut beraten. Wenn man dann aber findet, dass ja X, Y und Z auch noch dringend (on Top) gemacht werden müssen und unterm Jahr noch weitere Initiativen draufsattelt, überfordert man die Leistungs- und Leidensfähigkeit seiner Organisation. Und muss sich nicht wundern, wenn nicht mehr sondern weniger als geplant fertig wird…

Ich wünsche mir, dass mehr Manager in der Unternehmensführung ihre „Flexibilität“ und „Entscheidungsfreiheit“ zugunsten nachvollziehbarer Entscheidungsprozesse und realistischer Erwartungsdisziplin einschränken und mit einem strukturierten Projekt Portfolio Management ihre Unternehmensergebnisse effektiv und effizient steigern. Nebenbei werden sie so auch die Motivation der Mitarbeiter stärken und die Projektergebnisse (Termine, Kosten, Qualität, Geschäftsnutzen) deutlich verbessern.

Erfahren Sie mehr zur richtigen Einführung von Projekt Portfolio Management…

Projekt-Organisation – Die Dritte Dimension der Matrix

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

Matrix Vertrieb - Organisation, Transformation, Projektmanagement 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.

Matrix 3dim - Organisation, Transformation, Projektmanagement 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.

Wie Projektmanagement und Agilität zusammen mehr Nutzen bringen

Es begab sich zu einer Zeit vor Beginn des Jahrtausends, als die Wörter Scrum und agil noch nicht erfunden und das Agile Manifest noch nicht geschrieben war… Vielleicht ist bei meiner heutigen Praxis-Rückschau dann das „neulich“ nicht ganz richtig, aber ich habe in den seither vergangenen Jahren immer wieder Projektsituationen erlebt, für die das Beispiel für hybrides Projektmanagement hier exemplarisch stehen soll.

Nah am Standard und doch ganz individuell – geht das?

Es ging darum, ein Pilotprojekt für ein ERP-Template durchzuführen, das in der Folge dann seinen Roll-out in alle Niederlassungen des weltweit operierenden Kundenunternehmens erfahren sollte. Das Template sollte zur Kostenminimierung nahe am Standard bleiben und dennoch möglichst gut die Markt-Besonderheiten und gesetzlichen Anforderungen in den Niederlassungen adaptieren. Eine Quadratur des Kreises?

Es kam wie es kommen musste. Das Lastenheft erfuhr immer wieder Change Requests für neue oder geänderte Anforderungen aus den Niederlassungen, die Abteilungen im Hauptsitz des Unternehmens sahen das als Einladung, auch ihre Sonderwünsche freizügig einzukippen, die prognostizierten Kosten schossen über alle Budgetgrenzen hinaus. Nun machte das Projekt, was Piloten immer tun, wenn sie keine Landeerlaubnis bekommen: es drehte Schleifen.

Agiles und „klassisches“ Projektmanagement gehen eine Symbiose ein

Damit es sich nun auch von der Anforderungs- und Planungsphase einmal in Richtung Umsetzung bewegte, entschlossen wir uns, aufbauend auf den Kernfunktionalitäten des Standards iterativ vorzugehen. Als Strategie wurde vereinbart, nach jeweils einer festgelegten Zeitspanne ein funktionsfähiges Template fertig gestellt und getestet zu haben, das in folgenden Iterationen um priorisierte Inkremente ergänzt werden sollte, bis entweder der Zeit- bzw. Budgetrahmen erschöpft wäre oder das Template den Ansprüchen des Kunden hinreichend genügte.

Entsprechend wurden in der „klassischen“ Projektplanung abgegrenzte Zeit- und Kostenblöcke eingesetzt, aus denen die Geschäftsleitung jederzeit belastbare Vorschauen erhalten konnte. Das gab dem Management Kalkulations- und Planungssicherheit. Wir konnten so außerdem anhand der Prioritäten recht genau vorhersagen, wann wir den Fachbereichen welche Funktionalitäten zum Testen und zur Bewertung bzw. Abnahme würden liefern können, was uns in der Entwicklung Stabilität und Sicherheit brachte und dem Projekt wohlgesonnene Stakeholder.

Der Erfolg: Quick Wins, Flexibilität und Sicherheit

Auf diese Weise erreichten wir zweierlei: Erstens konnten wir mit der Entwicklung ohne weitere Verzögerungen beginnen, also ohne auf umfängliche Detailplanungen warten zu müssen, denn der Standard und die unstrittigen Grundfunktionalitäten für die ersten Entwicklungsphasen (Sprints) standen ja schon fest. Innerhalb von fünf Monaten hatten wir ein Deployment-fertiges Grundrelease, das ca. 70% der Prozesse unterstützte und für das die Mappings für die Datenmigration von den Altsystemen entworfen werden konnten.

Zweitens zogen wir so den „Anforderungsstreit“ aus dem Team heraus. Der fand fortan unter den (heute würde man sagen) Product Ownern aus den Niederlassungen und Fachabteilungen statt, die sich auf eine priorisierte Anforderungsliste (Stories) einigen und ein minimales Lastenheft (Product Backlog) definieren mussten. Später stellten wir in den Release-Planungen fest, dass wir um einen gemeinsamen Kern (das Template Backlog) durchaus individuelle, länderspezifische Erweiterungen in „Country Backlogs“ entwickeln konnten, deren inkrementelle Freigabe von ihrer sauberen Integration mit dem Kern abhängig gemacht wurde.

Top-effizient: auf Entwicklungsebene agil, im Projektmanagement „klassisch“

Während der gesamten Entwicklungszeit waren die Entwicklerteams nur gebunden an das, was sie für die jeweils 4- bis 6-wöchigen Release-Zyklen vom priorisierten Backlog-Stapel von oben herab geschätzt und Deployment-fertig zu liefern zugesagt hatten. Das ging in 90% der Fälle auf. Die Entwicklung war in der Masterplanung des Projekts als Control Account zeit -und budgetmäßig eingearbeitet, Risiko- und Issue Management arbeiteten eng mit den Teamleitern (Scrum Masters) zusammen, die Projektleiter und Qualitätssicherer (Product Owner) intensiv mit den verschiedenen Stakeholdern.

Insgesamt konnte nach 18 Monaten Projektlaufzeit etwa zwei Monate Entwicklung eingespart werden. Die haben wir lieber in ein gut vorbereitetes Change Management gesteckt, zulasten von ca. 25% des ursprünglichen Lastenheftes, die sich als Nice-to-haves herausstellten und eher neuen, als wichtiger eingestuften Anforderungen Platz machen mussten.

Und noch etwas: Wir waren mit dem 14. Release des Templates um Monate früher live als mit dem ursprünglichen Endprodukt geplant. Viele der Niederlassungen hatten ihre Varianten schon im operativen Betrieb als der anfangs geplante Roll-out hätte erst beginnen sollen. Alles zusammen haben wir auf der Kostenseite nicht so viel gespart, aber auf der Produktivitäts- und Business-Seite viel gewonnen.

Ein Beispiel für Best Practice

Warum ich über dieses Projekt hier gern erzähle? Weil wir damals noch nicht wussten, dass viele unserer Vorgehensweisen heutigen agilen Entwicklungsmethoden entsprachen. Und weil ich in vielen Projekten seither immer wieder feststellen konnte, dass sich diese mit dem „klassischen“ Projektmanagement nicht beißen, sondern, richtig und versiert miteinander verknüpft, hohe Produktivitäts- und Effizienz-Potenziale in sich tragen, die so manchem Projekt und Business Case gut täten.

Lesen Sie ein weiters Beispiel aus meiner Praxis mit einem hybriden Sanierungs-Ansatz…

Turnaround für Unternehmen mit einem projekt-getriebenen Business

Aein letzter Beitrag befasste sich mit dem Weg, aus einem Krisenprojekt wieder ein erfolgreiches Unterfangen zu machen oder zumindest noch einen brauchbaren Nutzen daraus zu erzielen. Er endete mit dem Aufruf an die projekt- und unternehmensverantwortlichen Manager, jetzt bloß nicht aufzuhören, sondern die aus dem Fehlschlag gewonnenen Erkenntnisse für ein sinnvolles Abstellen der eigentlichen Ursachen für immer wiederkehrende Probleme in Projekten zu nutzen, einen nachhaltigen Turnaround zu schaffen.

Diese Ursachen sind spätestens nach meinen vielen vorhergehenden Artikeln (https://eobz.de/category/news/), aber auch nach einem Blick in eine der unzähligen Studien hierüber, hinreichend bekannt. Zusammengefasst: Es liegt meist am Stellenwert, den Projekte im Allgemeinen und gutes Projektmanagement im Besonderen in einer Firma haben.

Unternehmen mit projekt-getriebenem Geschäftsmodell sind besonders betroffen

Bei diesem Geschäftsmodell erfolgt das vorherrschende Geschäft in Projekten, z.B. in Kundenprojekten. Aber auch Unternehmen mit einem Business, das sehr stark von Änderungen beeinflusst wird, die eine hohe Anzahl oder Frequenz an Investitionen und Anpassungen in Ihrem Geschäft erfordern (etwa wegen Regulatorik), sind projekt-getrieben.

Linienorganisation - Turnaround, Organisation, Projektmanagement, projekt-getriebenes Geschäftsmodell 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.

Zu dumm, wenn aber das Unternehmen gerade vom profitablen Abliefern von Projekten, also der reibungslosen Zusammenarbeit lebt, und eben nicht vom Blühen und Gedeihen der einzelnen Organisationseinheiten. Meist ist diese Diskrepanz bei traditionell aufgestellten, aber projekt-getriebenen Betrieben auch in den Büchern zu spüren: mit Rückgängen bei den Umsätzen, Gewinnen und Marktanteilen. Denn dort hat sich der Markt in den letzten Jahren dramatisch verändert. Diese Firmen brauchen dringend einen Turnaround nicht nur in einzelnen Krisenprojekten, sondern für das gesamte Unternehmen.

Mit dem Umbau der Kultur muss es anfangen

Nichts ist schwerer zu ändern als alte, lieb gewonnene Gewohnheiten. Viele Unternehmer und Executives sind schon daran gescheitert, überkommene Strukturen und Abgrenzungsdenken aufzubrechen, Abteilungsfürsten „umzudrehen“ und ihre Unternehmen für den Turnaround einer zukunftssichernden Rosskur zu unterziehen. Dazu muss sich zunächst einmal die Unternehmenskultur hinsichtlich seiner Projekte authentisch ändern. Und das fängt ganz oben im Top Management an.

Ein intensiver Change Management Prozess, der nicht von heute auf morgen geschieht, beginnt. Darauf kommt es an:

Begreifen, mit was Geld verdient wird. Das ist eben nicht mehr genug, ein gutes Produkt zu haben. Es muss auch zuverlässig geliefert, montiert und in Betrieb genommen werden, zum vereinbarten Preis. Das Geschäft ist also nicht mehr produkt- sondern projekt-getrieben. Und dabei muss Ihr Unternehmen (trotzdem) gut verdienen. Ergo
Übergreifende statt lokale Optimierung. Das heißt, dass Gewinn nicht in den einzelnen Produktionslinien und Fachabteilungen entsteht, sondern in den Projekten, die das Ganze als Paket liefern. Effiziente Zusammenarbeit über die Abteilungsgrenzen hinweg macht schöne Unternehmensmargen statt guter Einzelergebnisse der Funktionen. Dazu gehört auch das konsequente
Einbeziehen der Vorstufen und Lieferanten. Auch die müssen projekt-getrieben sein, zumindest in der Zusammenarbeit mit Ihnen. Denn wenn die nicht nach Plan zuliefern, wird die eigene, stringente Projektplanung schnell zur Makulatur. Also genau prüfen, wer zum neuen Konzept von der Leistung und seinem Organisationsgrad her passt, Verträge mit den neuen Kriterien neu verhandeln, Kontrollmechanismen, Expediting und Claim Management dafür schärfen und ausrichten.

Nur wenn alle verstanden haben, worum es im projekt-getriebenen Business geht, und wenn das Management authentisch dahinter steht, wird der Turnaround gelingen. Und auch nur dann werden Sie den nun folgenden Umbau erfolgreich und ohne verlustreiche Widerstände schaffen.

Der Umbau der Organisation ist logische Konsequenz und Fundament

Wenn Sie den wirtschaftlichen Erfolg Ihrer Projekte in den Fokus stellen, muss Ihre Unternehmensorganisation dazu passen und es widerspiegeln. Ein profitables, projekt-getriebenes Unternehmen braucht ein gutes und professionelles Management. Ergo braucht Ihr Unternehmen zukünftig ein starkes

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.

Flankierend gezielter Ressourcen-Einsatz und Zuarbeit

Leider haben Unternehmen meist von beiden Fachleuten zu wenige für all die wichtigen Projekte. Daher brauchen Sie ein strukturiertes und betriebswirtschaftlich effektives

Portfoliomanagement, um Ihre Projekte objektiv priorisieren und Ihre Ressourcen für einen optimalen Business-Nutzen einsetzen zu können. Nicht Bauchgefühl und Vorlieben und schon gar nicht wer am lautesten schreit dürfen entscheiden, welche Projekte für das Unternehmen wichtig sind. Dabei ist zu beachten, dass es auch bei einem projekt-getriebenen Geschäftsmodell weiterhin wichtige interne Projekte geben wird, die mit dem Umsatz nur indirekt zu tun haben. Die Kriterien für alle Projekte müssen Unternehmensziele, -Strategie, Risiko, Gewinn, Ausgewogenheit der Initiativen und Belastbarkeit der Organisation sein. Als Mittel bieten sich Nutzwertanalyse, (vielleicht) Balanced Scorecard und messbare KPIs an. Die Steuerung erfolgt nach Fakten und zeitnah konsequent. Das macht die Diskussion und Entscheidungen transparent und sicher.

Soweit die „neuen Besen“. Aber für ein Gelingen der Transition für den Turnaround braucht es noch einen Umbau im Zuschnitt und Selbstverständnis der

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.

Das ist kein „Kehraus“, aber schon ein tiefgreifender Umbau der Organisation, nicht nur in ihrer Struktur, denn Sie müssen flankierend

Auch den Umbau der Belohnungssysteme vollziehen

Alle strukturellen und Mindset-Änderungen werden wieder zurück in den alten Trott fallen und der Turnaround stecken bleiben, wenn die Mitarbeiter weiter für die alten statt für die neuen Verhaltensweisen und eben nicht auch projekt-getrieben belohnt werden. Abteilungsleiter dürfen nicht mehr am Erfolg oder der Größe ihrer Abteilung gemessen werden, Mitarbeiter nicht mehr primär an der Produktionsmenge oder Produktqualität. Wichtig ist der Beitrag zum Ganzen, die Performanz in den Projekten, Teamfähigkeit, Zuverlässigkeit, Eigenverantwortung, Verbesserung der Prozesse, persönliches Wachstum und Erweiterung von Skills, Einsatzfähigkeit und -Flexibilität. Das sind die Erfolgsfaktoren für den Turnaround und die Zukunftsfähigkeit des Unternehmens.

Sales wird z.B. nicht für viele verkaufte Projekte provisioniert, sondern für gute mit guten Margen und realistischen Liefervereinbarungen. Der Einkauf hat nicht mehr nur möglichst hohe Rabatte zum Ziel, sondern günstige Konditionen, die den Lieferanten realistische Ansätze und Kalkulationen erlauben und noch einen Anreiz für priorisierte, zuverlässige Lieferung sind. Eine Messzahl für seinen Erfolg könnte z.B. termingerechte Zulieferung oder geringe Ausfälle sein.

Bei HR ist das analog richtig besetzte Projekte oder weniger Ressourcen-Engpässe bei gleichzeitig guter Auslastung. QM erhält Boni für Prozessverbesserungen, die die Effizienz und Effektivität in Abläufen und Zusammenarbeit weiter steigern. Ihnen fallen jetzt bestimmt noch eine Menge weiterer Beispiele ein, oder? In allen Fällen ist jedenfalls eine enge Zusammenarbeit untereinander und gute Abstimmung mit dem Projekt- und Portfoliomanagement die Grundlage für Incentives, denn darin liegt die Basis für den Turnaround.

Ihre Belohnung

Wenn Ihr Unternehmen dann schließlich den Turnaround geschafft hat und ganz projekt-getrieben „tickt“, werden Sie keinen Vergleich mit den anderen Betrieben Ihrer Branche scheuen müssen. Vielleicht schon verlorene Marktanteile werden Sie zurück erobern und mehr dazu gewinnen. Vor allem aber werden Ihre Margen und Gewinne wieder Freude machen, ganz zu schweigen vom gemeinsamen Erfolg, den alle Mitarbeiter spüren und zu schätzen wissen werden. Erfolg macht sexy – das gilt auch für Unternehmen !

Ich hoffe, ich habe Ihnen mit diesen Zeilen ein paar nützliche Anregungen gegeben. Glauben Sie mir: der Gedanke lässt sich unendlich weiterführen. Ich finde daran viel Gefallen und Freude, gerne auch zusammen mit Ihnen für Ihren ganz individuellen Turnaround.

Lesen Sie mehr zum Thema Organisation und projekt-getriebenes Geschäftsmodell…

Programmmanager brauchen Bodenkontakt

Programmmanager sollten nahen Kontakt zu ihren Projektmanagern pflegen, selbst zu den Teams. Konzentrieren Sie sich nicht nur auf die Kommunikation nach oben! Ihr Marketing nach innen und außen ist besser, wenn Sie Geschichten aus dem Programm erzählen können. Wenn Sie selbst nicht tief drin im Programm stecken, verlieren Sie schnell den Überblick, werden misstrauisch oder unsicher bezüglich des Status, beginnen vielleicht, Mitarbeiter grundlos zu „schlagen“, und Sie verlieren so auch schnell das Vertrauen bei Ihren Vorgesetzten.

Lesen Sie mehr Lessons Learned…

Warum nicht auch mal Kurzarbeit im Projekt?!

Sparschwein - Lessons Learned: Kurzarbeit

Wenn unvorhergesehene Budgetkürzungen ein Projekt zum Anhalten zwingen würden, ist es manchmal überlegenswert, ob nicht eine Fortführung mit reduziertem Scope oder Tempo einen besseren Spareffekt bringt anstatt ein gutes, eingespieltes Team aufzulösen. Weitermachen mit Teilzeit-Ressourcen (Kurzarbeit) ist oft einem kompletten Freeze und späterem Wiederbeginnen mit ganz neu einzuarbeitenden Ressourcen vorzuziehen.

Lesen Sie mehr Lessons Learned…

Wenn Projektmanagement nicht ausreicht – Programmmanagement

Häufig werde ich in letzter Zeit gefragt, wo denn der Unterschied zwischen Programmmanagement und Projektmanagement liege. In der Tat sind die Grenzen in der Praxis oft fließend, werden die Strukturen, Rollen und Aufgaben nicht immer trennscharf definiert und gelebt. Und genau da liegen die Fallstricke für einen Programm-Manager, die Erwartungen der Stakeholder zu erfüllen, weshalb ich heute einmal ein Beispiel zur Veranschaulichung vorstellen möchte.

Zu komplex für Projektmanagement-Methoden

Im vorliegenden Fall wurde ich zu einer großen, komplexen Initiative gerufen, die in mehreren „Teilprojekten“ einzelne Module eines neuen IT-Systems erstellen, anpassen und einführen sollte, dazu eine großangelegte Datenerfassung und ‑Migration umfasste, dieses in mehreren Schritten einzuführende System betreiben und auch nach Abschluss der Implementierung weiter supporten sollte.

Ganz klar: das war ein Programm, denn die einzelnen Komponenten bauten aufeinander auf und ergaben nur zusammen den letztendlich gewünschten Nutzen für den Kunden. Außerdem ging es schon von der Dimension und Dauer her über ein normales Projekt hinaus. Das musste schiefgehen, auch wenn man es mit gutem Projektmanagement leiten wollte.

Nicht nur abliefern, sondern Nutzen maximieren

Projekt, Programm, Portfolio - Programmmanagement und Projektmanagement - Beispiel 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).

In der Realität erwiesen sich die Rahmenbedingungen allerdings für dieses Rollenbild nicht als ideal: den Kundenkontakt beanspruchte der Key Account Manager für sich, Änderungen am Vertrag sollten vermieden werden, und der Fokus des Programms sollte aus Lieferantensicht in der Sicherung der Meilensteine und der Marge liegen. Also nicht PgM, sondern Multi- oder Super-PM?!

Mit normalem Projektmanagement geraten Programme in die Krise

Bei meinem Boarding war das Programm bereits in Schieflage: erster Meilenstein geplatzt, der Kunde verweigerte die Teilabnahme trotz Lieferung aller Features, weil ihm die Usability und Performance nicht genügte. Im Vertrag stand dazu nichts. Überdies gab es mittlerweile ein paar neue Features, die der Kunde auch gern haben, der Lieferant aber erst nach Abschluss des ersten Vertrags angehen wollte. Verfahrene Situation, Hektik im Key Account und bei den Vertragsanwälten, mein Vorgänger verließ das Programm…

Krise oder Chance - Programmmanagement und Projektmanagement - Beispiel

Nun bekommt man nicht die Verantwortung für solch eine Riesen-Initiative, wenn man nicht als PM schon richtig gute Leistungen gezeigt hat. Aber das allein genügt für ein Programm meist nicht, wenn nicht zusätzliche PgM-Methodik und –Handeln hinzukommen.

Ich musste also meinen Auftraggeber überzeugen, aus dem Großprojekt ein richtiges Programm zu machen, mit dem Kunden vornehmlich über dessen Nutzen und Business Case zu reden, und nutzenstiftende Änderungen als zielführend zu antizipieren. Der Kunde wiederum musste sich auf kostenpflichtige Change Requests einlassen, auch wenn er vertragsmäßig gerade am längeren Hebel saß.

Programmmanagement funktioniert nur gemeinsam

Nur gemeinsam und mit Blick auf den Nutzen, den die Investition für den Kunden bringen soll, macht eine solche Sinn – schon bei Projekten, und noch viel mehr bei Programmen. Das ist im harten Business-Alltag sicher manchmal ein Spagat, denn auch für den Auftragnehmer muss es sich ja rentieren. Also musste ich die verfahrenen Positionen (und auch die bereits festgezurrten Claims) zwischen den Parteien auflösen und zurück auf die gemeinsamen Interessen an der Initiative führen.

Das Eingehen meines Auftraggebers auf die Kundenwünsche zur Änderung und Erweiterung des Umfangs nach dem aktuellen Stand der Geschäftsbedürfnisse einerseits und der Neuentwicklung verfügbarer Features und Module andererseits sowie die Bereitschaft des Kunden, dafür auch einen angemessenen Obolus zu entrichten, die benötigte Zeit einzuräumen und Ressourcen bereitzustellen, schlugen schließlich den Knoten entzwei. Hatte man sich vorher über Vertragsinhalte gestritten und sich gegenseitig „belauert“, zog man nun wieder gemeinsam an einem Strang und auch in die gleiche Richtung.

Auch ein als Projekt verfahrenes Programm kann gerettet werden

Nach der Sanierung fand die Geschichte jedoch ihr „Happy End“: Das Programm erlebte einen nicht ganz schmerzlosen Umbau, konnte aber für alle Beteiligten erfolgreich abgeschlossen werden.

Es hat etwas länger als ursprünglich geplant gedauert, die Marge des Auftragnehmers ist etwas schmaler ausgefallen. Dafür ist der Kunde mit dem Gelieferten mit mehr Qualität und Features glücklich, und die Investition hat sich für beide Seiten gelohnt.

Sicher aber wäre der Erfolg für den Lieferanten größer geworden, wenn die Initiative von Beginn an als Programm gemanagt worden wäre, ohne die etwas holprige Zwischenphase mit ungleichen Kräfteverhältnissen, und damit durchgängig mehr als Partner denn als Vertragsgegner.

Man muss es eben verstehen, was ein Programm ausmacht – und wie man ein solches richtig managt…

Mehr zum Thema Programmmanagement: Lesen Sie auch…

Projektmanagement im Unternehmen effizienter machen – Projekt Management Office einführen

Haben Sie sich auch schon mal gefragt, was Ihre „teuren“ Projektmanager (PMs) den ganzen Tag so machen? In einem meiner anderen Artikel können Sie zu diesem Thema einen Survey über den „Missbrauch“ von Projektmanagern für „artfremde“ Tätigkeiten lesen. Dazu kommt häufig auch, dass Projektmanager ihren Job nur „nebenbei“ zusätzlich zu hands-on Arbeiten im Projekt machen können. Heute möchte ich mich mit einer dritten Spielart des Zeitmissbrauchs von Projektmanagern beschäftigen, den Jobs, die ihnen andere viel billiger und effizienter abnehmen könnten – im Projekt Management Office.

Projektmanager leisten wertvolle Arbeit

Nochmal zurück: Gut ausgebildete Projektmanager werden auch gut bezahlt (bzw. sollten es werden). Dafür schultern sie eine Menge Verantwortung, behalten den Überblick für ihr ganzes Team, und sorgen dafür, dass im Projekt nichts Wichtiges vergessen und es ein Erfolg wird. Das ist schon für sich gesehen ein sehr anspruchsvoller Vollzeit-Job.

In der Firma, von der ich hier erzählen will, gab es mehrere Projektmanager von dieser Sorte, viele Projekte und damit sehr viel Arbeit. Schon in einer früheren Initiative hatten wir erfolgreich gemeinsame Standards für ein strukturiertes Vorgehen in Projekten festgelegt und zugehörige Vorlagen und Tools zusammengestellt. Die Basis für Operational Excellence in der täglichen Projektarbeit war gelegt und zeigte auch die gewünschten Resultate. Allein die Belastung der Projektmanager war nicht gesunken, und während die Projekte spürbar runder durchliefen, hatte der Projektmanager-Arbeitstag weiter 10 und mehr Stunden.

Die Analyse ergab wie nicht anders erwartet, dass methodisches Vorgehen eben auch einige Routinen mit sich bringt, die es „ohne“ nicht gäbe. Viele davon waren zyklisch, die meisten waren auch in jedem der Projekte anzuwenden. Zwar gehörten alle zum Projektmanagement dazu, aber eigentlich war die Zeit der Projektmanager dafür viel zu schade bzw. diese wäre an anderer Stelle sinnvoller eingesetzt gewesen.

Entlastung von Routinen steigert die Effizienz der Projektmanager

Also erhielt ich den Auftrag, für das Unternehmen ein Projektbüro einzurichten, das zentral die allfälligen Routinearbeiten zusammenfassen und zuarbeitend für die Projektmanager erledigen sollte. Hierzu gehörten u.a. die Organisation von Reisen und Unterkünften für Projektmitarbeiter, Buchen von Räumen oder Telefonkonferenzen, das Einsammeln und Aufbereiten der Zeit- und Arbeitsberichte sowie das aktualisierende Fortschreiben der Planungs- und Controlling-Unterlagen.

Hierfür wurden junge Projektmitarbeiter rekrutiert, die hier ihren Karriereweg im Projektmanagement begannen, und von mir mit Kursen in den Basics des Projektmanagements und den im Unternehmen standardmäßig angewendeten Tools unterwiesen wurden. Einige von ihnen haben später auch über die CAPM oder IPMA Level D Zertifizierung diesen Weg weiter beschritten.

Die Projektmanager wurden dadurch spürbar entlastet, hatten mehr Zeit für planerische und analytische Tätigkeiten, so dass die Projektqualität und -Effizienz durchweg noch einmal einen Schub bekam.

Wohl gemerkt: Um ein funktionierendes Projektbüro oder Projekt Management Office aufzubauen, braucht man einen sehr erfahrenen Projektmanager, der weiß, worauf es ankommt. Das ist sicher keine Aufgabe für einen jungen Projektmanager, um sich seine Sporen zu verdienen !

Das Projekt Management Office (PMO) übernimmt Management-Aufgaben

Mit der Einführung des neuen Karrierewegs war aber auch eine neue Organisationseinheit entstanden, eine Stabstelle außerhalb der traditionellen, funktionalen Linie, die sich primär mit Projektmanagement beschäftigte. Eine logische Konsequenz wäre die disziplinarische Zuordnung auch der Projektmanager hierher gewesen, um Ausbildung und Förderung in diesem Karrierepfad zusammenzufassen, und der neuen Abteilung auch disziplinarische Kompetenzen zu geben. Soweit wollte man aber bei meinem Kunden (noch) nicht gehen.

block2 - Projekt Management Office (PMO)

Immerhin bekam sie aber im zweiten Schritt meines Auftrags auch noch „höhere“ Aufgaben zugewiesen: Die Pflege und Qualitätssicherung der Projektmanagement-Standards, Übernahme des Change Control Managements und des Controllings in den Projekten sowie das Verfolgen und Aufbereiten des Risiko und Contingency Managements.

Das Projektbüro mauserte sich schrittweise zum Projekt Management Office (PMO), das das Projektmanagement-Wissen ausfallsicher auf mehrere Schultern verteilte und dem sich die Projektmanager effizienzsteigernd als Shared Services bedienen konnten. Dies sollte sich als sehr hilfreich herausstellen, als das Unternehmen zwei größere Programme zu stemmen hatte und die dafür notwendige Infrastruktur im Projekt Management Office bereits verfügbar war.

Projektmanagement im Unternehmen kontinuierlich weiter entwickeln

Wie es hier nun weitergehen wird? Nun, mein Beitrag hat schon so viel Knowhow im Unternehmen und Projekt Management Office hinterlassen, dass die Organisation mittlerweile notwendige Anpassungen oder Weiterentwicklungen selbst erkennen und initiieren kann. Ich werde nur noch punktuell für Audits oder Schulungen hinzugezogen.

Das ist auch gut so, denn Operational Excellence und interne Projektmanagement-Kompetenz war das Ziel, und das wurde erreicht. Nun können die „teuren“ Projektmanagement-Ressourcen sehr effizient und effektiv ihren hochwertigen Aufgaben nachgehen, und das Unternehmen profitiert davon am meisten…