Das Kind hat viele Namen: Projektbüro, Project Office, Project Management Office (PMO), Program Management Office (ebenfalls PMO), Program Office, Project Support Office, …

Was man darunter versteht ist auch wiederum uneinheitlich. In den Standardwerken, wie dem PMBOK, führt das PMO ein Schattendasein (in der 3rd edition des PMBOK ganze 2 Seiten). Klar hat es irgendetwas mit Projektmanagement zu tun, aber was, das fällt in der großen weiten Welt mitunter sehr unterschiedlich aus.

In einer kleinen Serie sollen daher kurz der Gestaltungsspielraum für ein PMO (Teil 2) aufgezeigt und dessen Ausprägungen anhand von 4 prototypischen Varianten (Teil 3-6) aufgezeigt werden.

Es gibt kein Patentrezept für ein PMO, denn die Anforderungen sind von Projekt zu Projekt, von Organisation zu Organisation sehr unterschiedlich. Kontext- und situationsspezifisch ist der richtige Ansatz zu wählen. Es macht einen gravierenden Unterschied, ob der Projektleiter ein reiner Fachexperte oder ein erfahrener Projektmanager ist. Nicht weniger unterschiedlich fallen die Anforderungen aus, wenn ein Unternehmen ein erstes Projekt startet oder bereits eine ausgeprägte Projektkultur vorhanden ist. Als dritter wesentlich Punkt ist auch die vorhandene Infrastruktur anzusehen: Kann ein Projekt auf eine bestehende Infrastruktur, angefangen von Räumen, Systemen bis hin zu Standards zurückgreifen oder startet ein Projekt auf der grünen Wiese.

Die weiteren Beiträge in dieser Reihe folgen in den nächsten Tagen.

Patrick Fritz hat auf Jahooda eine Auswahl von Methoden-Tipps für das Projektmanagement aus den einschlägigen Blogs zusammengestellt.

Im Editorial der aktuellen Ausgabe von Projektmanagement aktuell, nimmt Heinz Schelle in bemerkenswerterweise Stellung zur projektbezogenen Einsatzmittelplanung:

„… Wie auf dem Gebiet der projektbezogenen Einsatzmittelplanung, wo man sich leider wieder auf  ‚dumme‘ Algorithmen besinnt, statt einzusehen, dass die auf Vorgängen und Arbeitspaketen basierende Planung ein Irrweg war, feiert Operations Research, meiner Meinung nach im Projektmanagement längst glorreich gescheitert, fröhliche Auferstehung. Geboten wird nicht, was das Projektmanagement braucht (Nachfrageorientierung), sondern was die Mathematik hergibt (Angebotsorientierung).“

Andreas Heilwagen greift die Diskussion von Meilensteinen und Stage Gates von Glen Alleman auf, der stattdessen für die Verwendung von klar definierten Metriken für die Fertigstellung plädiert. Unter Hinweis auf den häufig vertraglichen Charakter von Meilensteinen und Stage Gates plädiert Andreas Heilwagen für die Nutzung solcher Metriken im Rahmen von Meilenstein- und Stage Gate-Konzepten.

Theoretisch kann ich dem voll und ganz zustimmen. Praktisch sieht es aber leider etwas anders aus, denn eigentlich erfordert das Reissen eines Meilensteins oder das Verpassen eines Stage Gates klare Konsequenzen, die im Projektalltag so häufig gar nicht gewünscht sind – von allen Beteiligten!! Wenn eine Testphase nur zu 80% abgeschlossen ist, der gewünschte GoLive-Termin aber verschoben werden müsste, werden sich i.d.R. Auftraggeber und Projektteam tief in die Augen schauen und eine Risikoabwägung vornehmen, die so in keinem Projektplan vorgesehen war. Es ist illusorisch anzunehmen, dass alle Unabwägbarkeiten eines Projekts in den vertraglichen Beziehungen eindeutig vorab geklärt werden können. Voraussetzung, dass solche AdHoc-Anpassungen nicht ein reines Hasardeurspiel werden, ist ein höchstes Mass an Transparenz und Vertrauen zwischen den Beteiligten. Vertragliche Regelungen und theoretische Konzepte können wieder einmal keine Projektkultur ersetzen, sondern setzen diese voraus.

Felix Rüssel von armerkater.de fasst einen Beitrag auf PMhut (Teil1, Teil2) über das Scheitern von Projekten zusammen, der 11 Symptome für das Scheitern von Projekten aufzählt.

Ja, selbstverständlich sind die üblichen Verdächtigen darunter und Felix schreibt:

Es ist für mich immer wieder erstaunlich wie sich bekannte Probleme immer wieder wiederholen.

So richtig solche Aufzählungen sein mögen, ich mag sie trotzdem nicht, weil die Symptome von den grundlegenden Krankeiten fehlende Projektkultur und mangelhafte Kommunikation ablenken. Zum Beispiel an einem Risikomanagement kann ich beliebig rumdoktern und mir ein Risikoinventar und Risk Assessments um die Ohren schlagen, wenn die Einstellung dahinter nicht stimmt, bleibt die Veranstaltung relativ sinnlos, dann geht es nur mehr um reine Absicherung und Schuldzuweisung, was noch kein Projekt zum Erfolg geführt hat.

Übersetzungsprobleme sind zugegebenermaßen ein Lieblingsthema von mir. Aktuell wieder zu finden in einem Interview im CIO-Magazin mit Klaus Rausch (Ex-HypoVereinsbank-CIO, heute CTO beim Schweizer Dienstleister Avaloq) mit dem passenden Titel:

Wenn Anwender der IT das Programmieren erklären

Siehe auch:
#144 Übersetzungsprobleme: IT und Business
#131 IT versteht Business nicht

Persönlich stehe ich mit Zertifizierungen (nicht nur im PM) auf dem Kriegsfuss. Die meisten Zertifizierungen driften ins formale ab und vernachläsigen die Praxis. Darüber hinaus hat man das Gefühl, dass weniger das hehre Wissen als das Geschäft mit der Zertifizierung und dann das Folgegeschäft mit der Rezertifizierung, usw. im Vordergrund steht. Ich bin durchaus ein Freund des lebenslangen Lernens, aber das hat mit Zertifizierungen wenig zu tun (zumindest habe ich ein solches Zertifikat noch nicht gefunden).

Bernd Oestereich zusammen mit Prof. Dr. Michael Gessler (GPM/IPMA) und Oliver F. Lehmann (PMI) setzen sich aktuell in einem Beitrag für ObjektSpektrum mit den PM-Zertifikaten auseinander. Die Kollegen sehen durchaus auch die Vorbehalte gegen die Zertifizierungen und führen sie in ihrem Artikel auch mit auf. Schwerpunktmäßig setzen sie sich mit den Zertifizierungen nach PMI und GPM/IPMA auseinander. Weitere Zertifizierungen und Standards werden zumindest kurz erwähnt. Beispielsweise PRINCE2 (dem britischen Standard), der vor allem daher im Kommen ist, da die OGC als Herausgeber auch den ITIL-Standard für das IT-Servicemanagement entwickelt hat und man vermehrt im IT-Umfeld deshalb immer wieder über PRINCE2 stolpert.

Wie sich die Inhalte der Standards, die sich hinter den Zertifizierungen verbergen, unterscheiden, hat bereits vor einer Weile Andreas Heilwagen zusammengefasst. Von ihm gibt es ganz aktuell auch Tipps für eine erfolgreiche PMP-Zertifizierung (PMI) als Podcast.

Nachtrag 22.05.2009: Und nochmal Andreas Heilwagen, der auf PMHut eine Lernhilfe für die PMP-Zertifizierung ausgegraben hat.

Passend zum Thema Kommunikation in Projekten hat auch Stefan Hagen einen interessanten Artikel von Ulrike Wikner auf perspektive-mittelstand.de ausgegraben. Sie befasst sich mit der Moderation und Vorbereitung von Meetings im Projekt. Kommunikation ist selbstverständlich noch viel mehr als das, was in Projektmeetings passiert, aber ein bisschen Disziplin hilft hier schon ein gutes Stück weiter und über die Bedeutung von Kommunikation habe ich mich bereits im letzten Beitrag ausgelassen.

Przemysław Bielicki berichtet auf AgilSoftwareDevelopment.com über den Einsatz agiler Methoden in einer vom Wasserfallmodell geprägten Umgebung und insbesondere wie direkte Kommunikation zum Rettungsanker für ein bereits halb-totes Projekt wurde (Englisch).

Agil hin oder her – unabhängig von der Diskussion über agile Vorgehensweisen unterstreicht das Beispiel vor allem eines: Die Bedeutung von Kommunikation in der Projektarbeit.

Meine These: Stimmt die Kommunikation in einem Projekt, dann ist die Vorgehensweise „fast schon egal“…

Nachtrag (22.05.09): Hier die Fortsetzung des Kollegen Bielicki.

Andreas Heilwagen hat in einem Post 9 Denkschulen des Projektmangements nach Rodney Turner, Cristophe Bredillet und Frank Anbari ausgegraben, nämlich:

1. Optimierung: Das Projekt als Maschine
2. Modellierung: Das Projekt als Spiegel
3. Governance: Das Projekt als Rechtssubjekt
4. Verhalten: Das Projekt als soziales System
5. Erfolg: Das Projekt als Geschäftsziel
6. Entscheidung: Das Projekt als Computer
7. Prozesse: Das Projekt als Algorithmus
8. Umstände: Das Projekt als Chamäleon
9. Marketing: Das Projekt als Plakatwand