Andreas Heilwagen hat einen Post von Glen Alleman, wie man sich als professioneller Projektmanager verhalten sollte, dankenswerterweise ins Deutsche übertragen. Ich teile Glen´s Sichtweise allerdings nicht, denn die Empfehlungen sind leider überzogen und blauäugig:

• Natürlich ist es gut alle Fakten bei der Hand zu haben. Der allwissende PM ist mir allerdings noch nie begegnet…
• Nur über einforderbare Ergebnisse und in aussagekräftigen Einheiten (Zeit & Geld) zu sprechen, reduziert den PM auf eine technisch-bürokratische Rolle. Ergebnisorientierung und der Transfer der Auswirkungen im magischen Dreieck sind zwar wesentliche Bestandteile der PM-Arbeit, aber warum zum Teufel sprechen wir immer wieder von Projektkultur und Kommunikation?? Bitte die Menschen in Projekten nicht vergessen! Glen´s Anspruch „speak only in actionable outcomes“ schießt hier über das Ziel hinaus. Gute PM´s beherrschen die Kunst auch „zwischen den Zeilen zu lesen“.
• Und zu guter letzt Glen´s Vorliebe für die Messung des Projektfortschritts und die Earned Value Methode: Die Messung des Projektfortschritts ist gut und schön, wird aber allzuleicht überschätzt und hat auch methodische Grenzen. Z.B. Schelle (Amazon) weist darauf hin, dass der sinnvolle Einsatz  der Earned Value Analyse an zwei Voraussetzungen gekoppelt ist, nämlich die Proportionalität von Leistungen und Kosten, sowie eine relative Planstabilität. In komplexen oder politischen Umfeldern (wie es Projekte nun mal sind), ist dies allzu häufig nicht gegeben. Da führt die Fortschrittsmessung zu Scheingenauigkeiten oder wird zur Selbstbeschäftigung. Ich spreche hier gar nicht gegen eine Fortschrittsmessung, aber auch sie muss angemessen sein und nicht überzogen.

Dass sich unter dem Titel PMO nicht immer das Gleiche verbirgt, darauf habe ich vor einer Weile in einer kleinen Serie (Hier: Teil1) hingewiesen. Jerry Manas spricht auf PMThink! ein weiteres Problem an: Getreu dem Motto „Der Ton macht die Musik“, weist er auf mögliche Akzeptanzprobleme und falsches Anspruchsdenken hin. Er zeigt eine Entwicklungslinie auf vom PMO als „supporting organization“ (1), die durch ihre Arbeit Einfluss gewinnt (2), um in der höchsten Stufe auch den Führungsanspruch zu verkörpern(3). Wer gleich mit den höchsten Ansprüchen anfängt, ohne sich die entsprechende „credibility“ zu erwerben wird auf die Schnauze fliegen.

Ich kann seine Einschätzung leider nur bestätigen allzuoft wird ein zentrales PMO installiert, das nur mehr führen will und die eigentliche Projektarbeit nicht mehr unterstützt. Andererseits geniessen PM´s, die die Ärmel hochkrempeln und im Projekt unterstützen, wo sie nur können, die höchste Wertschätzung im Projektteam.

Passend zum voranstehenden Beitrag über das Scheitern von Projekten und passend zu der kleinen BI-Serie, die wir jüngst hier hatten, berichtet die Computerwoche über gescheiterte BI-Projekte. Und man staune: es scheitert zuerst an den Menschen und dann an den Daten…

Und hier noch einmal die Links zu den einzelnen Beiträgen der BI-Serie:

In Teil 1 der Reihe finden sie eine Definition von BI und grundlegende Anforderungen von Kennzahlsystemen.
In Teil 2 wurde das Anforderungsdilemma in BI-Projekten beschrieben.
In Teil 3 rückt das Augenmerk auf die Unternehmensleitung und deren Umgang mit BI.
Teil 4 beschäftigt sich mit den elementaren Themen Datenqualität und Datenbereitstellung.
In Teil 5 wird resümiert, was ein erfolgreiches BI-Projekt ausmacht.

Wird ein Projekt eingestellt, abgebrochen, vorzeitig beendet, etc. so hat dies weit mehr Auswirkungen, als es im ersten Augenschein anmutet.  Robert K. Hurley und Joseph T. Jimmerson fassen auf PMHut einige Auswirkungen zusammen und sprechen sogar vom Projektabbruch als traumatischem Erlebnis. Zweifelsohne gibt es auch solche Auswirkungen auf Ebene des einzelnen Projektmitarbeiters. Daneben gibt es aber auch noch Auswirkungen auf die Organisation, zum Einen auf Projektkultur und Motivation, zum Anderen auf Erfahrung und Wissen.

Der Abbruch von Projekten ist immer wieder an der Tagesordnung und weiter verbreitet als man denkt. Die beiden führen hierzu eine akutelle PMI-Umfrage, sowie Erfahrungen der NASA an und weisen darauf hin, dass ein vernünfitger Abschluss in gescheiterten Projekten mitunter noch wichtiger ist, als in erfolgreichen Projekten.

Weitere Beiträge zum Scheitern von Projekten aus schlossBlog:

#201 CHAOS-Report und mehr…
#172 Scheitern von Projekten
#163 Scheitern
#141 Erfolg und Scheitern von Projekten
#80 Projekterfolg
#70 Umgang mit dem Scheitern
#44 warum Großprojekte scheitern

Das CIO-Magazin berichtet über Mediatoren in IT-Projekten. Angeführt werden insbeondere Konflikte zwischen IT und Fachabteilung (Hatten wir das nicht erst?), in denen Mediation sinnvoll eingesetzt werden kann Eigentlich wäre das doch der Job eines IT-Management, des Anforderungsmanagement oder des Claim Management,… Auch als PM war ich schon oft entsprechend gefordert. Also wieder die Geschichte vom alten Wein in neuen Schläuchen? Oder nur Marketing für eine weitere Ausbildung/Zertifizierung? Auch dieser Geschäftszweig will leben und braucht neue Märkte.

Ein Fehler in der Mediationsmetpaher in diesem Zusammenhang ist, dass IT und Business als eigenständig gesehen werden. Das mag in der Unternehmensrealität vielleicht auch der Fall sein, aber hier liegt der Hund begraben: IT ist kein Selbstzweck! Die IT gewinnt ihre Existenzberechtigung erst aus dem Business. Kundenorientierung und Prozessorientierung wären die geeigneten Direktiven. Sind die beiden gegeben und gibt es ein funktionierendes Anforderungsmanagement, so wird der der im Artikel beschriebene Mediationsbedarf sich wieder weitgehend auflösen.

Im Interim Management kommt ein erfahrener Manager von außen und wird in das operative Geschäft eines Unternehmens eingebunden, d.h. er wird in die Aufgaben- und Verantwortungshierarchie integriert und erhält auch entsprechende Weisungsbefugnisse. Interim Management beseitigt Engpasssituationen, sichert die Handlungsfähigkeit und leitet langfristige Lösungen ein. Interim Management kann in verschiedenen Szenarien zum Einsatz kommen:

• Projektmanagement
• Krisenmanagement
• Change Management
• Expertenmanagement
• Überbrückungsmanagement

Projektmanagement ist also ein mögliches Einsatzszenario für den Interim Manager. Der Einsatz des Interim Manager kann dabei sowohl in der zentralen Koordination/Projektmanagement als auch in fachlichen Arbeitspaketen als Experte erfolgen.

Die GPM hat jüngst das Management-Summary einer Studie über den Einsatz von KPIs im Projektmanagement veröffentlicht. Die Studie entstand im Rahmen eines Praxisprojektes an der Hochschule für Angewandte Wissenschaften in St. Gallen (FHS).

KPIs oder Key Performace Indicators sind Kennzahlen, natürlich nur die ganz besonders wichtigen, die in der Studie nach den Rollen Geschäftsleitung, Progammführung, Portfolioführung und Projektleitung zusammengefasst werden.

Der Studie liegt ein einseitiges Projektverständis zugrunde: Die Auswahl der KPIs lässt vermuten, dass überwiegend Vertriebsprojekte erfasst wurden (was wohl mit dem Stichwort Project Driven Enterprises gemeint war.) Man könnte also auch von CRM-KPIs sprechen… Nein, das war jetzt etwas gemein, aber ein KPI Angebotserfolgsrate kommt wohl nur in solchen Projekten vor.

Inhaltliche Themen, Projektfortschritt und Status spielen anscheinend keine große Rolle, aber die lassen sich auch nicht so einfach quantifizieren, was meine Vorurteile gegenüber zu stark quantitativen Denkens  bestätigt.

Zumindest im Management-Summary gibt es auch keine Erläuterungen zu den einzelnen KPIs. Die Praxis unzähliger BI-Projekte zeigt leider, dass auch die vermeinlich eindeutigsten KPIs sehr kreativ unterschiedlich definiert werden können.

Christian Henner-Fehr hat auf seinem Kulturmanagement-Blog mal wieder einen PM-Beitrag in dem er kurz und prägnant das Thema Projektstrukturplan (PSP) oder Work Breakdown Structure (WBS) zusammenfasst.

“Haben Sie das nicht auch als Powerpoint-Folie?” – mit dieser Frage endete der vorangehende Beitrag. Nachdem mir diese Frage schon viel zu oft über den Weg lief, habe ich mir selbst eine kleine Hilfe mittels VBA-Makro gestrickt, die auf schlossblog zum Download bereit steht. Diese Hilfe ist für Powerpoint 2007 ausgelegt und verwendet ein kleines Makro. Speichern Sie die Hilfe als .pptm-Datei.

Hier eine kurze Anleitung zum Einsatz der Datei:
(1) Datei öffnen
(2) Eine neue Folie erstellen
(3) Erstellen Sie ein einfaches Rechteck an der Stelle und Größe, wo das GANTT-Diagramm auf der Folie erscheinen soll.

(4) Lassen Sie das Rechteck markiert und rufen über den Ribbon Entwicklertools>>Makros im Dialog das Makro GANTTinRectangle auf:

(5) In den nächsten beiden Dialogfenstern, werden die Zahl der Perioden und die Zahl der Vorgänge abgefragt.
(6) Anschließend erstellt das Makro automatisch eine Vorlage für das GATT-Chart:

(7) Die Anpassung der Beschriftung und der Balken können nun manuell vorgenommen werden.

Bei Projektplänen denken viele gleich an GANTT-Charts (Balkendiagramme), wie sie PM-Software wie z.B. MS Project automatisch generiert.

GANTT-Diagramm

Bereits vor dem Start unserer VisualPM-Reihe gab es auf schlossblog Beiträge zum Thema GANNT:

#217 GANTT mit Excel?
#218 GANTT mit Excel 2007 (inkl. einem Excel-Template)

So schön die grafische Darstellung von Vorgängen als Balken auf einer Zeitachse auch sein mag, sie wird gerne überschätzt, denn in einem komplexen Projektplan geraten auch die GANTT-Diagramme immer komplexer und je häufiger es zu Planänderungen kommt, umso mehr verlieren all diejenigen, die den Plan nicht aus dem FF im Kopf haben schnell die Übersicht. Wer den Plan aber derart intus hat, benötigt die grafische Aufbereitung weit weniger als zusätzliche Informationen. Wenn ich an MS Project Dateien sitze, sind die schicken Balken meist ausgeblendet und dafür weitere inhaltliche Spalten eingeblendet. Und die großen gedruckten Wandtapeten, wie wir sie in Projekten mitunter finden, sind meist nicht aktuell gepflegt und geben irgendeinen alten Stand wieder.

Hilfreich sind GANTT-Darstellungen für Roadmaps, als Übersichtsdarstellungen in der Kommunikation, beispielsweise um den Teammitgliedern oder Stakeholdern die geplanten Projektphasen zu vermitteln. Allerdings sind solche Übersichten nicht sehr komplex, beschränken sich auf eine handvoll Vorgänge/Phasen und im Projektmarketing sind dann die Screenshots aus MS Project verpöhnt, weil zu wenig schick und dann kommt auch schon gleich die Frage: „Haben Sie das nicht auch als Powerpoint-Folie?“