Jolyon Hallows fasst Project Office Functions in drei Funktionsgruppen zusammen: Development, Support und Control. Ähnlich sollen hier im Folgenden vier Dimensionen unterschieden werden, anhand derer die in den weiteren Beiträgen beschriebenen Varianten eines Projektbüros (oder wie auch immer der Name ausfallen sollte) unterschieden und abgegrenzt werden können:

• Entwickeln
  Weder Projektmanager noch PM-Standards fallen vom Himmel, sondern müssen rekrutiert oder entwickelt werden.
   
• Regulieren
  Dies beinhaltet die Genehmigung, Überwachung und Freigabe von Projekten.
   
• Agieren/Führen
  Die konkrete Umsetzung des PM und evtl. auch die fachliche Mitarbeit im Projekt. Das „Kümmern“ um das Erreichen des Projektziels. Dies kann neben klassischen PM-Aufgaben u.a. Moderation, Konfliktmanagement und Problemlösung beinhalten.
    
• Administrieren
  Angefangen von Sekretariatsfunktionen bis in zur Verwaltung von Infrastruktur und Mitarbeitern.
   

Anhand dieser Dimensionen werden in den weiteren Beiträgen die folgenden vier prototypischen Varianten unterschieden:

• „Backoffice“
• „Portfoliomanagement“
• „Verlängerter Arm“
• „Programmmanagement“

Jede dieser Ausprägungen weist andere Schwerpunkte und Zielsetzungen auf und hat andere Zielgruppen im Visier. Aufgrund ihrer unterschiedlichen Ausrichtung ist es durchaus möglich, das mehrere dieser Stellen parallel bestehen, was meist die Namensvielfalt und -verwirrung beflügelt. Darüber hinaus finden sich in der Praxis natürlich auch Mischformen und beliebige Abwandlungen.

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.

Jürgen Beckers und Gerry Wallner haben für die Computerwoche eine 3-teilige Serie zum Thema IT-Einkauf verfasst:

Teil 1 – Softwareeinkauf ohne Reue
Teil 2 – Wie Sie den passenden Anbieter finden
Teil 3 – Gute Planung rechnet sich

Im ersten Teil werden die Abstimmung der Ziele, die Erstellung des Lastenhefts und die Einbindung der Stakeholder beschrieben. In Teil 2 geht es im Prozess dann weiter über die auf dem Lastenheft basierende Ausschreibung, die erforderlichen Vorgaben zum Angebot, der Auswahl, bis hin zur Vertragsgestaltung. In Teil 3 geht es dann um die Durchführung, angefangen bei der Planung über die Umsetzung, Testing bis hin zur Betriebsübergabe. Es werden die dafür erforderliche Organisation und das Projektmanagement angesprochen (inkl. des Änderungmanagements, dem Controlling, Detailfragen zur Abnahme und dem leidigen Thema Dokumentation).

Natürlich sind solche Listen, wie hier von Gartner zusammengetragen und im CIO-Magazin veröffentlicht, Humbug, aber irgendwie sind sie doch auch „inspirierend“ und daher lesenswert. Genannt werden:

• Teure Fachkräfte
• Produktfriedhof (aus historisch gewachsenen Systemlandschaften)
• Dürftige Flexibilität (mit der Folge, dass das Kerngeschäft die Fähigkeit verliert sich zu verändern)
• Eskalierende Kosten (im laufenden Betrieb)
• Veraltete Technik
• Schwieriger Datenzugriff (moderne Unternehmen hängen extrem von aktuellen Daten ab)
• Kapazitätsengpässe (aufgrund des stetig steigenden Transaktionsvolumens un der steigenden Zahl an Schnittstellen)
• Compliance-Risiken (Gesetzliche Bestimmungen gewinnen an Bedeutung)
• Steigende Kosten und schwindende Agilität
• Green IT (Wo der Applikationsbetrieb unter grünen Zielen leidet, ist Gefahr im Verzug)

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

Klar fallen solche Projektberichte wie die Case Study im CIO-Magazin zur IT-Bebauung bei E.ON immer als Success Story aus (siehe auch unsere Diskussion über 10projects), aber der Artikel beschreibt ganz gut allgemein die Vorgehensweise bei der IT-Bebauung, nur den rosa Filter muss man beim Lesen noch entfernen…

In einem Interview in Air&Space spricht Chesley Sullenberger über seine spektakuläre Airbus-Landung im Hudson River. Bemerkenswert vor allem gegen Ende der Passus über die Verwendung von Notfall-Checklisten (soviel zum Thema Grenzen der Planung):

Air & Space: Does the Airbus operator’s manual have a procedure for ditching?

Sullenberger: Yes.

Air & Space: So your first officer would have found that procedure and had a checklist to go through for the ditching procedure?

Sullenberger: Not in this case. Time would not allow it. The higher priority procedure to follow was for the loss of both engines. The ditching would have been far secondary to that. Not only did we not have time to go through a ditching checklist, we didn’t have time to even finish the checklist for loss of thrust in both engines. That was a three-page checklist, and we didn’t even have time to finish the first page. That’s how time-compressed this was.

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.