#187 Umgang mit Fehlern

Es klingt fast nach Slapstick oder Comedy, was Sven Rimbach zu berichten weiss. Er hat uns einen Dialog  über abnahmerelevante Fehler gebloggt. Komik und Tragik liegen nahe beieinander. Leider kann ich mir nur zu gut vorstellen, dass dieser Dialog so auch stattgefunden hat. Da werden die Testergebnisse und ggf. auch die Abnahmekriterien und Fehlerklassen solange umgedeutet, bis das herauskommt, was man eh wollte. Süffisant möchte man da anmerken: Wozu noch testen…

#186 PMO: Zusammenfassung

Bereits im ersten Teil dieser kleinen Reihe wurde darauf hingewiesen, dass es kein Patentrezept für ein PMO gibt. In der Projektpraxis finden sich die unterschiedlichsten Ausprägungen, die unterschiedliche Aufgabenstellungen verfolgen.

In Teil 2 wurden zur besseren Abgrenzung dieser Varianten die Dimensionen Entwickeln, Regulieren, Führen/Agieren und Administrieren beschrieben.

Anschließend wurden beispielhafte Ausprägungen beschrieben und klassifiziert, ohne diese zu bewerten, nämlich:

Zusammenfassend hier die Klassifizierung in tabellarischer Form:

 Zusammenfassung PMO

Natürlich ist die Beschreibung dieser Beispiele immer verkürzend, aber in Summe wird das ganze Spektrum dessen, was sich unter dem Mantel „PMO“ verbergen kann veranschaulicht.

#185 PMO: „Programmmanagement“

Während die Projekte in einem Portfolio auch vollkommen losgelöst voneinander sein können, fasst ein Programm gemäß PMBOK „a group of related Projects managed in a coordinated way to obtain benefits and control not available from managing them individually“ zusammen.

Auftrag:

Das „Programmmanagement“-PMO bewegt sich zwischen einem Portfoliomanagement beschränkt auf die Projekte eines Programms und einem „verlängertem Arm“ für die Programmleitung.

Zielgruppe:

Zielgruppe ist die Programmleitung.

Organisation:

Stabsstelle der Programmtleitung

Ausrichtung:

E – Entwickeln          ***        (3)
R – Regulieren          ***        (3)
F – Führen                ****   (4)
A – Administrieren     **      (2)

Eine Beschreibung der Dimensionen findet sich in Teil 2 dieser Artikelserie.

#184 PMO: „Verlängerter Arm“

Was hier als „verlängerter Arm“ (der Projektleitung) bezeichnet wird bewegt sich auf der Führungsebene eines einzelnen Projekts (aber nicht auf Ebene des Projektportfolios). Der „verlängerte Arm“ kann zwar auch administrative Aufgaben übernehmen, wie das „Backoffice„, hat aber Führungs- und Mitwirkungsaufgaben im Projekt.

Auftrag:

Der „verlängerte Arm“ des Projektleiters setzt das Projektmanagement um und entlastet den Projektleiter in dem er selbstäbstig PM-Aufgaben übernimmt. Eine Untervariante dieses Typus ist das „Planungsbüro“, das sich auf Planungs- und Reportingaufgaben beschränkt.

Zielgruppe:

Zielgruppe des „verlängerten Arms“ ist die Projektleitung. Projektleiter und PMO arbeiten abgestimmt „Hand in Hand“. Ab einer gewissen Größe ist eine solche Rolle mitunter auch auf Ebene von Teilprojekten sinnvoll.

Organisation:

Stabsstelle der Projektleitung

Ausrichtung:

E – Entwickeln          **         (2)
R – Regulieren          **         (2)
F – Führen               *****  (5)
A – Administrieren    ***     (3)

Eine Beschreibung der Dimensionen findet sich in Teil 2 dieser Artikelserie.

Als letzte PMO Variante folgt das „Programmmanagement“.

#183 PMO: „Portfoliomanagement“

Während das zuvor beschriebene „Backoffice“ sich auf einer reinen Arbeitsebene bewegt, spielt das „Portfoliomanagement“ in einer anderen Liga. Statt operativer Ausrichtung steht hier die Gesamtstrategie (und nicht nur ein einzelnes Projekt) im Vordergrund.

Auftrag:

Das „Porfoliomanagement“ kümmert sich um das Programm- und Projektportfolio einer Organisation. Es verwaltet den Mix unterschiedlichster Projekte, sorgt projektübergreifend für Transparenz und macht hierfür die entsprechenden Vorgaben (z.B. für das Reporting). Auf dieser Ebene wird auch bei Interessenskonflikten zwischen Projekten abgewogen. Im Namen der Leitung gibt das Portfoliomanagement Projekte frei, nimmt sie ab oder stampft sie ggf. auch wieder ein.

Zielgruppe:

Zielgruppe des „Portfoliomanagement“ ist die Unternehmensleitung. Die Projekte sind zuliefernde Einheiten.

Organisation:

Das „Portfoliomanagement“ ist eine Stabsstelle der Unternehmensleitung, entsprechend ist es in der Linienorganisation angesiedelt.

Ausrichtung:

E – Entwickeln            *****  (5)
R – Regulieren            ****    (4)
F – Führen                  *          (1)
A – Administrieren            (0)

(Natürlich hat ein „Portfoliomanagement“ v.a. Führungsaufgaben, aber nicht auf Ebene des einzelnen Projekts, sondern für das Gesamtportfolio. Aus Projektsicht wirkt es daher regulierend und nicht führend.)

Eine Beschreibung der Dimensionen findet sich in Teil 2 dieser Artikelserie.

In den weiteren Beiträgen folgen noch „Verlängerter Arm“, und „Programmmanagement“.

#182 PMO: „Backoffice“

Als erste Variante des PMO wird hier ein  „Backoffice“ beschrieben. In den weiteren Beiträgen folgen „Portfoliomanagement“, „Verlängerter Arm“, und „Programmmanagement“.

Auftrag:

Das „Backoffice“ ist eine klassische Support-Funktion. Die Aufgaben reichen vom Sekretariat (Folienerstellung & Bürobedarf), über die Verwaltung, evtl. auch Beschaffung der Projektinfrastruktur bis hin zu einfachen PM-Aufgaben (z.B. der Verwaltung eine Projektkalenders, Zeiterfassung, einfache Auswertungen).

Zielgruppe:

Zielgruppe des „Backoffice“ ist primär die Projektleitung. Je nach Kapazität und Ausstattung können sich auch mehrere Projekte ein „Backoffice“ teilen und die Unterstützungsleistungen können auch auf Teilprojektleiter und Projektmitarbeiter ausgedehnt werden.

Organisation:

Das „Backoffice“ ist eine Stabsstelle der Projektkleitung, kann aber evtl. auch in der Linienorganisation verankert sein und von dort mehrere Projekte unterstützen.

Ausrichtung:

E – Entwickeln                     (0)
R – Regulieren                     (0)
F – Führen              *          (1)
A – Administrieren  *****  (5)

Eine Beschreibung der Dimensionen findet sich in Teil 2 dieser Artikelserie.

#181 PMO: Der Gestaltungsspielraum

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.

#180 PMO: Das Project Management Office

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.

#179 IT-Einkauf

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).

#178 Die 10 folgenschwersten IT-Fehler

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)


bernhardschloss.de