Dr. Huber vom projekt (B)log hat die Toolfrage hinsichtlich Kommunikation auf den Punkt gebracht. Ein gutes Web 2.0 Tool ist irrelevant, wenn die Nutzer nicht bereit sind ihr Wissen zu teilen. Er weist darauf hin, dass man sich für den Status eine Wissensteilenden in vielen Unternehmen nichts kaufen kann. In einem eher konservativen deutschen Großunternehmen habe ich eine gegenteilige Erfahrung gemacht. Die Auskunftsfreudigkeit und das Teilen von Wissen sind wichtige Aspekte der Kultur und sind damit Voraussetzung für den Erfolg.

In diesem Sinne viel Spaß bei der Lektüre seines Postings.

Nachdem die meisten Publikationen die Suche nach erfahrenen Projektmanagern und deren Mangel am Markt hervorheben, liest man nun bei heise online Informationen vom Bitkom:

Gesucht werden auch Projektmanager: In den Anwenderbranchen geben das 47 Prozent der Firmen mit unbesetzten Stellen an. Zwei Drittel der Unternehmen suchen dabei ausschließlich nach Hochschulabsolventen..

Wie passt das zusammen? Ist der neue Trend in der Wirtschaftskrise, Absolventen und Projektmanager günstig einzustellen und heranzuziehen? Wer meint mehr zu wissen?

Ist es nun eine Marketing-Glanzleistung oder die Einladung zum erweiterten Dialog? In der Novemberausgabe von PMWorldToday lädt die IPMA-Präsidentin Brigitte Schaden alle PMI®-Chapter ein, Mitglieder in der IPMA zu werden. Weiterhin sieht sie die IPMA in der Rolle der Vereinten Nationen für das Projektmanagement in zwei Jahren.

Oliver Lehmann, u.a. Vice President Members des PMI München Chapters sieht es so:

„PMI Chapter sollen der IPMA beitreten? Interessanter Gedanke.

Man muss Frau Schaden aber für den interessanten Denkansatz und für das Aufstoßen von eher verschlossenen Türen großes Lob aussprechen.“

Ich für meinen Teil freue mich ebenfalls, dass die IPMA in einen derartigen Dialog einsteigen will, nachdem die Reibereien zwischen den PM-Fachverbänden eine lange Historie haben. Schauen wir uns das Ganze jetzt mal praktisch und mit teilweise nicht ganz ernster Miene an, gefolgt von einem konkreten Vorschlag:

1. Das PMI hat mehr als fünfmal soviele Chapter wie die IPMA Länderorganisationen. Da fühlt man sich an den fehlgeschlagenen Versuch von Studenten die FDP zu übernehmen erinnert. Die Organisationen sind eben doch ziemlich unterschiedlich.
2. Die IPMA nimmt nur eine nationale Organisation pro Land auf, und Corporate Membership ist nur für den Fall vorgesehen, dass es keinen nationalen Verband als Mitglied der IPMA gibt. Wo passen da Chapter ins Bild?
3. Die UN steht für Weltfrieden, Völkerrecht und Menschenrechte, die IPMA für Promotion von Projektmanagement, Bereitstellung von Standards auf Basis der ICB und „das weltweit führenden 4-Level-Zertifizierungssystem“. Dieser Führungsanspruch passt nicht zu einer Zusammenarbeit mit PMI Chaptern.

Also erstmal zurück auf den harten Boden der Realität! In Deutschland wird die GPM für eine hypothetische PMI-Chapter-Dachorganisation nicht aus der IPMA austreten und die Chapter auch nicht in einer entscheidenden Rolle neben sich dulden können und soll sie auch nicht da nicht zielführend.

Für einen gemeinsamen Weg der Fachverbände bedarf es einer Vision. Dafür sollten aus meiner Sicht eine relevante Anzahl weltweiter Fachverbände ein „PM Manifest“ analog dem Agilen Manifest entwickeln. Dieses gibt die Ziele und die Leitplanken des gemeinsamen Handelns vor und erlaubt Schritt für Schritt echten Mehrwert für Projektmanager und Organisationen zu schaffen, ohne dass die Differenzen der Verbände im Vordergrund stehen. Auf diesem Weg kommen die Fachverbände allerdings auch nicht umhin, ihre Agenda auf den Prüfstand zu stellen.

Sehr geehrte Frau Schaden, ich lade Sie ein, gemeinsam mit der Community der Projektmanager, so verteilt sie im Netz auch ist, die Diskussion über einen gemeinsamen Weg der Fachverbände anzustoßen. Denn letztlich sollten sich die Fachverbände auf einem gemeinsamen Weg am Bedarf der Projektmanager ausrichten, ergänzt um strategische Ziele zur Verbreitung von Projektmanagement als Schlüsselkompetenz für erfolgreiche Organisationen. Bitte nehmen Sie den Ball mit einem Kommentar zu diesem Posting auf.

Über Brigitte Schaden
Im letzten Jahr wurde Brigitte Schaden zur Präsidentin der IPMA (International Project Management Association gewählt. Aufgewachsen in Österreich, ist sie heute selbständig (Homepage im Moment nicht erreichbar) und u.a. Mitglied im pma-Vorstand sowie in diversen weiteren Rollen in der IPMA aktiv.

Hinweis: Dieses Posting ist kein offizielles Statement des PMI® oder eines seiner Chapter, sondern die Meinung der genannten Einzelpersonen und des Autors.

Ralf Friedrich hat auf XING eine gute Präsentation mit einem Vergleich der beiden führenden PM-Fachverbände PMI® und IPMA hochgeladen. Die Unterlage wurde von Rüdiger Geist vom PMI Switzerland Chapter und Dr. Daniel Baumann von der SPM erstellt. Die Übersicht adelt die Tatsache, dass sie von namhaften Vertretern beider Fachverbänder erstellt wurde. Diesem Punkt geschuldet ist zwangsläufig auch wieder, dass einige wirkliche Konfliktpunkte nicht berücksichtigt wurden. Ich fand die folgenden Punkte besonders relevant:

Hier eine Übersicht über die Entwicklung der Zertifikantenzahlen von PMI und IPMA:

Die gute Nachricht ist, dass ich damit mein Versprechen einlösen konnte, die Zertifikantenzahlen mit Historie einander gegenüberstellen. Auf der anderen Seite ist es mir leider nicht gelungen, der GPM selbst Zahlen zu entlocken.

Bei der Entscheidung für eines der beiden Zertifizierungssysteme sollte man sich im Wesentlichen von der Frage leiten lassen, ob man ein Prozess-Framework (PMI) oder ein Kompetenz-Framework (IPMA) nutzen möchte. Die Frage, wie die einzelnen Zertifizierungen einander gegenübergestellt werden können, wurde in der Präsentation nicht geklärt und wird seitens der GPM offiziell relativ einseitig gesehen (IPMA Level D = PMP®) und seitens des PMI aus meiner Sicht nach beiden Prüfungen inoffiziell relativ ausgewogen (IPMA Level B oder C = PMP®).

Diese vor allem politische Frage ließe sich nur mit einem gemeinsamen System von Metriken beantworten. Allerdings muss man sich nach der Investition in den Aufwand und Erhalt des Ergebnisses fragen, ob dies eine Frage war, die man beantworten wollte. Denn die wirkliche Erfahrung eines Projektmanagers ist schwer messbar und spielt immer mit der Lebenserfahrung und der Erfahrung im Fachgebiet zusammen.

Ja, man kann über Wasser gehen…aber man muss nicht. Ich für meinen Teil war die Woche mit einem kurzfristigen Projekt beschäftigt und bin darüber leider nicht zum Bloggen gekommen.

Aber wie kam das Segel nun ins Wasser?

Der Super-Trimaran von BMW Oracle, der den nächsten America’s Cup gewinnen soll, hat seinen Mast verloren. Auch darauf hat mich netterweise Sailing Anarchy gebracht.

In diesem Sinne: Auch in Projekten kann vieles ermöglicht werden…man muss vor allem kreativ sein und die entscheidenden Person dafür ins Boot holen…und sei es dass man über Wasser gehen möchte…aber nicht dass es kostenlos wäre…

Am 28.10.2009 wurde die neue Fachgruppe „Transportation PM“ der GPM aus der Taufe gehoben. Eine Übersicht der aktuellen Fachgruppen gibt es auf der Homepage der GPM.

Auf TechFAQ habe ich eben einen kostenlosen Test mit 200 Fragen zur Vorbereitung der PMP®-Zertifizierung gefunden. Das Ganze hat natürlich auch einen kommerziellen Hintergrund, denn es wird auch ein kostenpflichtiger Offline-Test mit ca. 1600 Fragen angeboten. Wie gut oder schlecht der Test ist, habe ich nicht getestet, gehe aber davon aus dass der eine gute Ergänzung für die Prüfungsvorbereitung ist.

Sie kennen sicher diverse Projekte, die für Günstlinge erstellt wurden oder einfach nur fixe Ideen einzelner Personen sind. Die Personen haben erhebliche Macht und der Business Case für das Projekt ist eine Katastrophe. Privat mag das noch angehen, im Berufsleben sollte der business value von Projekten in Bezug auf die Kosten einfach stimmen.

Um meinen Ruf am Wochenende off-topic-Bilder zu posten zu untermauern, hier ein wirklich kreatives Pet Project:

Selbst dem Laien fällt auf, dass dieses Ruder geringfügig von der Norm abweicht und selbst Foils wirken dagegen antiquiert. Und die Auflösung ist:

Der Mann ist ein Fan von E-Gitarren und hat deshalb dieses total schräge und eigentlich unpraktische Ruder eingebaut. Das Originalposting dazu kommt wieder einmal von Sailing Anarchy.

Das Thema Microblogging in Projekten kreist gerade wieder in den PM-Blogosphäre auf Basis eines Postings von Claudio Sprenger. Wenn ich das Posting bewusst aus meiner Brille betrachte, fasst das folgende Statement das Ergebnis für mich passend zusammen:

Microblogging soll die altbewährten Projektkommunikationstools wie E-Mail, Ordnerstrukturen und -ablagen nicht ersetzen. Es soll eher als Ergänzung der kollaborativen Informations- und Kommunikationsumgebung dienen.

Es gibt diverse Tools wie Chat, Telefon- und Videokonferenzen etc., die für Projekte effektive Kommunikationsformen darstellen. Gerade in meinem derzeitigen Projekt sehe ich jedoch einen wesentlichen Unterschied zwischen nachhaltigen und ergänzenden Kommunikationsformen.

Chats, Telefon-/Videokonferenzen und Twitter sind aus meiner Sicht gute Mittel, um die Projektkommunikation je nach Anlass effektiv zu realisieren. Allerdings gilt für mich am Beispiel dieser vier Wege: Man kann sie als Weg zu einer Entscheidung oder zur Verteilung von Informationen nutzen, allerdings sind sie nach Projektende nur begrenzt nachvollziehbar. Eine E-Mail mit einer Entscheidung oder ein Meetingprotokoll kann geeignet archiviert werden, um nach einem Projekt nachvollziehen zu können, was warum geschehen ist. Wie mache ich dies mit einem Microblog?

Wenn das Projektteam gerne Microblogging verwenden möchte, finde ich es als Motivationsaspekt positiv. Es sollte allerdings gewährleistet sein, dass das „Tool“ nicht über seine Fähigkeiten hinaus verwendet wird.

Konkreter Anlass meines Postings? Die Kluft zwischen Hype und harter Realität. Die harte Realität bedeutet für mich gerade: Aufarbeitung von Kundenanforderungen nach einer kurzen Übergabe, deren Anforderungsstatus nicht immer sauber dokumentiert wurde. D.h. ich führe immer wieder Gespräche über Themen, die scheinbar aktuell sind, andererseits aber von einigen Personen ohne Dokumentation längst beerdigt wurden. In vielen Fällen flossen Ergebnisse mündlicher Abstimmungen nicht in die Dokumentation ein. Bei Microblogging sehe ich eine ähnliche Gefahr: wer sorgt dafür, dass darüber erreichte Ergebnisse dann durch eine andere geeignete Kommunikationsform festgehalten werden? A fool with a tool is still a fool! Also, Microblogging kann eine gute Ergänzung der Projektkommunikation sein, aber seien Sie sich über die Grenzen im Klaren. Ich für meinen Teil würde selbst nicht die Initiative starten, Microblogging für Projekte einzuführen aufgrund der bekannten Schwächen. Es als in einer Gruppe etablierte Kommunikationsform dem Projektteam zu „verbieten“ ist allerdings genauso kontraproduktiv. In diesem Sinn bin ich gespannt, wie es mit dem Thema weitergeht.

Einige andere Postings hierzu waren:

• Microblogging (Twitter) und Enterprise 2.0
• Microblogging – Zwischen Schätzmaschine und Projekttool
• Microblogging – (Un)Sinn in Projekten

Es ist schön, wenn Gartner die eigene Meinung bestätigt…ich habe die alten Reports von Gartner zum Thema Enterprise Wikis nie gelesen, versprochen! Für mich spannend: Confluence von Atlassian gehört zu den Challengern und hat den kleinen Nachteil der kleinen Firma. Microsoft Sharepoint auf der anderen Seite ist zwar im Quadranten der Leader gut aufgehoben, allerdings auf der Wiki-Seite schwach besetzt.

Auch hier grüßt wieder ein Posting der T-Systems MMS, welches den Gartnerreport sehr gut zusammenfasst…lesenswert wenn Sie Enterprise Wikis ernst nehmen.

Das PMI® hat die Glossare seiner verschiedenen Standards und Guides zusammengefasst und als Combined Standards Glossary Fourth Edition auf Papier veröffentlicht. Zumindest als PMI-Mitglied kommt man an den gesamten Inhalt über die elektronischen Versionen der einzelnen Standards auch kostenlos heran. Das gleiche Werk gab es auch schon für die letzte Edition der PMI-Standards.

Zumindest hat man so die konsolidierte Sicht der PMI-Welt. Für mich ist es viel spannender, ausgewählte Begriffe im Rahmen meines pm-woerterbuch.de hinsichtlich der verschiedenen Definitionen in Standards und Normen zu vergleichen und sinnvolle standardübergreifende Definitionen vorzuschlagen. Meine Quellen sind hier:

• Projekt Magazin
• Der Projektmanager (GPM)
• ICB 3.0/NCB 3.0
• DIN 69900:2009
• DIN 69901:2009
• PMBOK^® Guide 3rd edition
• PMBOK^® Guide 4th edition
• PRINCE2
• Weitere Standards des OGC
• Max Widemans PM Glossary
• Wiktionary und Wikipedia
• Das Blog projektmanagement-definitionen.de
• project-management-knowledge.com

und zukünftig natürlich auch die erste internationale PM-Norm ISO 21500.

In vielen Projekten sind Risikoregister noch keine Selbstverständlichkeit, auch wenn sie es längst sein sollten. Zum methodisch fundierten und strukturierten Umgang mit Chancen und Risiken gehören neben einem Risikoregister auch Risikomanagementpläne. Schwerwiegende Risiken und große Chancen können häufig nur gemeinsam mit vielen Stakeholdern angegangen werden. Es sind z.B. Wege aufzuzeigen, die Risiken bewältigen und Chancen verstärken. Diese sind mit den Stakeholdern abzustimmen, Entscheidungen zu treffen und es ist sicherzustellen, dass die Entscheidungen berücksichtigt werden, wenn es Zeit ist die definierten Maßnahmen hinsichtlich der Risiken und Chancen umzusetzen.

Kurz gesagt: „kleine“ Risiken und Chancen können ausreichend auf Basis eines Risikoregisters gesteuert werden, sobald die Komplexität hoch ist und viele Stakeholder einbezogen werden müssen, sollte man jeweils einen Risikomanagementplan aufstellen:

Der Rahmen für die Erstellung eines Risikomanagementplans ist

1. Beschreibung des Risikos bzw. der Chance
2. Analyse der Symptome und Ursachen, Rückführung auf root causes
3. Aufzeigen der Aspekte, die das Risiko bzw. die Chance beeinflussen sowie der Auswirkungen
4. Qualitative und quantitative Bewertung
5. Beschreibung der Strategien zur Bewältigung des Risikos oder Verstärkung der Chance
6. Definition der möglichen Pläne und Analyse der Restrisiken

Danach geht es in die finalen Abstimmungsrunden mit den Stakeholdern, die Beschaffung des Budgets für die definierten Maßnahmen etc.

Nutzungshinweise

Ziel	Strukturierte Analyse von Risiken und Chancen sowie Definition von Bewältigungs- und Verstärkungsplänen
Technik	Hinweise zum Ausfüllen sind in der deutschen Version enthalten.

Den aktuellen Download-Link für das Template finden Sie unter pm-templates.de bzw. pm-vorlagen.de.

Als Betroffener einer Sharepoint-Einführung merke ich gerade, wie sehr mit ein Enterprise Wiki im aktuellen Umfeld fehlt. Es zwar schön, dass Sharepoint eine Datenbank-Anbindung hat und gut mit Office integriert ist, aber letztlich erscheint mir das Leben damit reichlich kompliziert. Deshalb hat mich der Bericht der T-Systems MMS über ein Jahr Confluence besonders gefreut. Hier die wichtigsten Punkte:

• Einfacher Zugriff
  Der Zugriff auf Informationen wurde erheblich vereinfacht da sie zentral durchsuchbar sind anstatt auf Fileservern und in E-Mail-Postfächern abseits gelagert zu werden.
• Niedrige Einstiegshürrde
  Die Einstiegshürde für die aktive Teilnahme wurde erheblich gesenkt gegenüber der alten Lösung.
• Hohe Öffentlichkeit
  Informationen sind einem größeren Teilnehmerkreis verfügbar und führen zu einer stärkeren Einbindung von mehr Mitarbeitern.
• Social Medie üben
  Der Enterprise Wiki ermöglicht den Mitarbeitern Social Media auszuprobieren und schafft das Vertrauen, diese auch in der „Öffentlichkeit“ außerhalb des Konzerns zu nutzen.
• Gute Strukturierung
  Eine gute Struktur unterstützt das Wachstum des Wikis und vereinfacht die Navigation.
• Gute Einstiegsseite
  Eine geeignete Einstiegsseite ist wichtig, hier entwickelt die T-Systems MMS gerade eine neue Lösung.
  
• Übergreifende Suchmaschine
  Eine Suchmaschine über die Grenzen des Wikis hinaus ist entscheidend. In einem Intranet, welches ich aktuell nutze, ist der Wert der Suchergebnisse quasi Null, denn die Ergebnisse haben meist keine wirkliche Relevanz, auch wenn sie technisch korrekt sind.

Spannend finde ich, dass nun Confluence 3.x das Vignette-CMD und Sharepoint ersetzen soll. Die Datenbank-Anbindung von Confluence fand ich bisher eher schwach und das WebDAV-Modul völlig unbrauchbar. Abzuwarten bleibt aus meiner Sicht, ob Microsoft Sharepoint einen ordentlichen Wiki spendieren wird und wie sich die DB-Unterstützung von Confluence weiterentwickelt.

Normalerweise habe ich am Wochenende hier und da etwas über Multihulls parat, heute ist mir bei Sailing Anarchy ein Spitzenbild einer Monohull-Regatta in die Hände gefallen:

Wenn sich Projekte nach so einem Bad doch auch einfach wieder aufrichten und normal weiterlaufen würden…

Während der closing session des PMI® North America Congress 2009 prophezeite Harold Kerzner das baldige Ende des Earned Value Managements. Er sieht die Zukunft in Value Management-Methodiken, die den Wert bzw. Nutzen eines Projekts für die Businessseite (business value) erfassen. Damit fordert er insbesondere von Projektmanagern ein tieferes Verständnis des Business ein. Kurz gesagt geht er davon aus, dass die bisherige Fokussierung auf Zeit und Kosten als Randbedingungen für Projekte in Zukunft der Frage nach dem Wert bzw. Nutzen eines Projekts untergeordnet wird.

Soweit, so gut. Aber wie kommen wir von der Earned Value Analyse und dem Triple Constraint (Scope, Time, Cost) zu neuen Value Management Frameworks? Hier einige erste Ideen auf dem Weg. Fangen wir an mit dem Triple Constraint:

An sich ein (ver)alt(et)er Hut, allerdings auf der gleichen Linie wie das Earned Value Management:

In beiden Fällen versucht man das Projekt über Scope, Zeit und Kosten zu steuern. Beim Earned Value Management gehen Scope, Budget und Ressourcen in die Berechnung des bisher erreichten „Values“ des Projekts ein. Allerdings steht „Value“ an dieser Stelle nur für die Kennzahl, die angibt, wie weit man auf dem geplanten Weg gekommen ist. Für agile Projekte macht Earned Value Management herzlich wenig Sinn, da man ein „moving target“ unter dem Gesichtspunkt der Maximierung von Metriken wie Kundenzufriedenheit verfolgt und bei ständig wechselnder Planung der Earned Value zu verschiedenen Zeitpunkten nicht miteinander vergleichbar ist.

Triple Constraint und EVA greifen auch aus meiner Sicht zu kurz, da sie weder Qualität noch Kundenzufriedenheit berücksichtigen. Deshalb nutze ich folgendes Modell:

Wo soll nun der Business Value berücksichtigt werden? In meinem oben gezeigten Modell habe ich ihn für mich unter Kundenzufriedenheit subsummiert und bin damit für die Zukunft gerüstet.

Wie kann man aus Sicht des PMI® den Weg vom Earned Value Management zum Business Value Management gehen?

Michel Thiry (PMI Fellow) definiert den Wert bzw. Nutzen eines Projekts über Scope und Qualität auf der einen Seite und Ressourcen, bestehend aus Kosten und Zeit, auf der anderen Seite einer Wage. Um die Argumentation zu unterstützen, habe ich folgende Darstellung gewählt:

Im Wesentlichen arbeitet er damit noch mit den Themen des Earned Value Managements. Spannend wird es nun, wenn man sein Modell um die neuen Projektrandbedingungen aus dem PMBOK^® Guide 4th edition ergänzt und Business Value hinzufügt:

D.h. der Wert eines Projekts könnte sich entsprechend dem Denkmodell des PMI aus den PMI-Projektrandbedingungen Scope, Quality, Budget, Ressources, Time und Risks ergeben, ergänzt um Business Value (bzw. Customer satisfaction aus meiner Sicht). Damit hätte man eine erste Diskussionsgrundlage, um die zukünftige Bewertung von Projekten durchzuführen und z.B. zu entscheiden, wann man ein Projekt stoppt.

Die besonderen Herausforderungen dieses Modells sind, geeignete Metriken für Qualität und Business Value bzw. Kundenzufriedenheit zu definieren bzw. eine Kennzahl festzulegen, die den letztlichen Nutzen bzw. Wert des Projekts beschreibt. Es ist auch zu prüfen, inwiefern die Menge der Kennzahlen reduziert wird, da deren hohe Anzahl nicht notwendigerweise zu besseren Aussagen führt.