Wer Projekte organisieren und unterstützen will, muss wissen, wovon er redet

Wieviel Projektunterstützung darf es sein?

Marcus Konitzny

© Shutterstock.com/alphaspirit

„Unser Projekt braucht Unterstützung“, so beginnt häufig die Unterhaltung, bevor externe Consultants eingekauft werden sollen. Was dann folgt, ist in den meisten Fällen ein Sammelsurium an Hilferufen, in denen häufig die wichtigen Informationen fehlen und in der Folge alle bekannten Begrifflichkeiten durcheinander geworfen werden. Die grundlegende Frage, was gemacht werden soll, wird schnell beantwortet und dem Ganzen ein Name gegeben: Wir suchen ein PMO, dass dem Projektmanager bei der Folienerstellung hilft, Räume für Besprechungen reserviert, ihm die Protokolle schreibt und die Projekt- und Budgetpläne aktualisiert.

„Einige Projekte im Portfolio sind ernsthaft gefährdet, Sie brauchen ein Projekt Management Office“, waren die Worte des Beraters und die Antwort kam wie aus der Pistole geschossen: „Das haben wir schon, das macht bei uns Frau Meyer für das Projekt Alpha und Frau Schmitt für die anderen Projekte“. So oder ähnlich verlaufen häufig die Gespräche, wenn es um die Unterstützung im Projektmanagement geht. Doch was verbirgt sich tatsächlich hinter den Abkürzungen wie PA, PO oder PMO, die zwar jeder verwendet, aber für die jeder eine andere Definition hat? Und was sind die Aufgaben der unterschiedlichen Unterstützungsformen, wann brauche ich welche und was bringen sie in der Realität? Nach dem Lesen dieses Artikels besitzen Sie einen Überblick über die verschiedenen Formen der Unterstützung, und Sie haben Klarheit im Begriffswirrwarr.

Drei sind mehr als eins

Grundsätzlich kann man in der Projektunterstützung zwischen drei Möglichkeiten unterscheiden:

• Project Assistant
• Project Office
• Project Management Office

Die hierarchische Anordnung der Optionen bedeutet keineswegs eine Bewertung der Arbeit an sich. Jede Unterstützung hat bestimmte Charakteristika, Vor- und Nachteile, Möglichkeiten und Grenzen, wie beispielsweise Skalierungsmöglichkeiten, Aufgabengebiete und Ähnliches, die ich im Folgenden aufzeige. Die Optionen überlappen sich teilweise in den Aufgaben und alle ergänzen sich zu einem stimmigen Gesamtbild, wie sie am Ende sehen werden. Eines ist allen Unterstützungsformen gemein: Keine entbindet den Projektmanager von seinen Aufgaben oder davon, die Informationen aus einem bestimmten Bereich auf dem Radar zu behalten. Sie können als Projektmanager das Budget-Tracking an einen Personal Assistant oder an ein Project Office auslagern, doch wenn Sie die Zahlen nicht kennen und ihre Entscheidungen diese Zahlen nicht berücksichtigen, ist der Nutzen jeglicher Unterstützung dahin. Es sind Unterstützungsleistungen, die den Fokus des Projektmanagers weg von administrativen und zurück zu den Kernaufgaben des Projektmanagements leiten. Was sind diese Kernaufgaben?

1. Projektmarketing: Sorge dafür, dass jeder Stakeholder um die Wichtigkeit und den Vorteil des Projekts weiß und wenn möglich das Projekt aktiv unterstützt!
2. Beseitigung von Hindernissen: Sorge dafür, dass dein Projektteam frei von Hindernissen arbeiten kann!

Project oder Personal Assistant – individuell und schnell?

Während im Internet verschiedene Definitionen für die Arbeit eines Personal Assistants zu finden sind, gibt Google bei der Suche nach dem Project Assistant ein sehr spärliches Feedback. Ein Blick auf die Jobbeschreibungen offenbart das identische Aufgabenspektrum wie beispielsweise Zeitmanagement, Planung von Meetings, Protokollerstellung, Überarbeitung und Erstellung von Folien und Korrespondenz bis hin zur Übernahme von einzelnen Aufgaben wie Controlling oder Aktualisierung des Projektplans. Der Schwerpunkt liegt bei beiden in der individuellen Betreuung einer Person. Hier darf beachtet werden, dass die Bezeichnung Project Assistant sich auf die Arbeit zur Unterstützung des Projektmanagers bezieht. Es ist also per Definition nicht die Unterstützung des gesamten Projekts. In der Realität wird diese Grenze auch nur in Details aufgeweicht. Beispielsweise wird es häufiger vorkommen, dass ein Project Assistant auch andere Regeltermine aufsetzt und plant, an denen der Projektleiter nicht teilnimmt. Es wird auch gelegentlich vorkommen, dass in einem solchen Meeting das Protokoll vom Project Assistant geschrieben wird. Die Zeit, die ein Assistant in einem Meeting ohne den Projektleiter verbringt, steht er diesem allerdings nicht zur Verfügung. Entsprechend wird das Eigeninteresse dafür sorgen, dass diese Abwesenheiten wohl dosiert sind. Andere Aufgaben, wie das Zeitmanagement kann ein Assistant schlichtweg nicht für das Projekt übernehmen. Die Unterstützung bei der Erstellung von Folien ist eines der Themen, die in Projekten häufiger an Assistants übergeben werden, und auch hier gilt der gleiche Grundsatz wie bei der Protokollerstellung. Ein Projektmanager wird seinen Folien eine höhere Priorität geben und somit sicherstellen, dass hierauf der Fokus gelegt wird. Recht häufig hingegen werden Budget- oder Zeitplanung als Pflegeprozesse an einen Project Assistant abgegeben. Projektleiter, die ihren Assistants keine sinnvollen oder nicht ausreichend Aufgaben übergeben, sorgen in der Regel dafür, dass innerhalb kurzer Zeit die Person zu einem weiteren Projektmitarbeiter wird und die individuelle Unterstützung schwindet.

Wann setze ich einen Project Assistant ein?

Mit dem Wissen um das Aufgabenspektrum ist der Einsatz eines Project Assistants immer dann sinnvoll, wenn es um die individuelle Unterstützung eines Projektmanagers geht. Hierbei spielt in erster Linie das Projekt an sich bzw. dessen Komplexität keine große Rolle, sondern die Tatsache, dass der Projektmanager neben seinen Aufgaben zur Steuerung des Projekts nicht mehr in der Lage ist, auch noch andere Aufgaben zu erfüllen. Ich möchte kurz ein Szenario aufzeigen, in dem klar wird, dass diese Unterstützung keineswegs die Leistung von schlechten Projektmanagern kompensieren soll, sondern eine Entlastung zugunsten des Projekts ist. Stellen Sie sich ein beliebiges IT-Projekt vor, bei dem ein neues Backend-System in eine bestehende IT-Landschaft eingeführt werden soll. Dieses System hat fünfzig Schnittstellen zu anderen Systemen, von denen zehn intern (gleiches Unternehmen) und vierzig extern (Drittunternehmen verantwortlich für Hosting, Wartung und Weiterentwicklung) sind. Sie haben also einen Projektmanager mit einem erhöhten Abstimmungsbedarf mit vierzig externen Schnittstellen, den dazugehörigen Unternehmen und etwaigen Projekten in den Unternehmen, die auch gerade diese Schnittstelle bearbeiten. Hier ist die Sternstunde für eine Project-Assistant-Unterstützung, welche die Koordination von Terminen, das Erstellen von Diskussionsvorlagen und Protokollerstellung auf hohem Niveau übernimmt.

Bedingt durch die personelle Stärke – eine Person – ist die Grenze für diese Art der Unterstützung, die Kapazität der handelnden Personen. In unserem obigen Beispiel könnte der Project Assistant mit der Terminkoordination, Vorbereitung und Protokollierung der Meetings bereits zeitlich so stark eingebunden sein, dass beispielsweise die Pflege des Budgets oder des Projektplans nicht mehr möglich wäre. An die Übernahme des Risiko-, Qualitäts-, Kommunikationsmanagements oder anderer administrativer Aufgaben ist dann nicht mehr zu denken. Die Rolle des Project Assistants ist nicht skalierbar, denn jede Aufstockung um eine weitere Person und damit auch die Übernahme von mehr Projektaufgaben macht aus dem Project Assistant ein Project Office.

Project Assistant
Individuelle Betreuung des Projektmanagers
Aufgaben: Zeit- und Meetingmanagement, Protokoll- und Folienerstellung bis hin zur Übernahme einzelner Pflegeprozesse für Budget oder Zeit
Vorteile: Schnelle Einarbeitung durch stringente Führungsmöglichkeit, individuelle Unterstützung
Nachteile: Keine Skalierbarkeit zur Übernahme weiterer Funktionen
Skalierbarkeit: Keine

Project Office – das Projektbüro

Das Project Office (PO) ist eine Unterstützungsform, bei der eine oder mehrere Personen den Projektmanager durch die Übernahme von administrativen Projektmanagementaufgaben entlasten. Gerade bei der Besetzung durch nur eine Person wird häufig fälschlicherweise angenommen, die Aufgaben seien analog zu denen des Project Assistants. Das Leistungsspektrum eines Project Office liegt allerdings nicht in der persönlichen Unterstützung, sondern in der Projektunterstützung und beinhaltet somit alle administrativen Aspekte folgender Bereiche (beispielhafte und nicht vollständige Liste):

• Projektplanung
• Budgetplanung/Controlling
• Ressourcenplanung
• Risikomanagement
• Management der Lieferleistungen
• Kommunikationsmanagement
• Qualitätsmanagement
• Management des Projektumfangs
• Management der beteiligten Personen und Erwartungen
• Meldewesen/Statusberichte

In jedem dieser Bereiche gibt es unterschiedliche so genannte Artefakte, wie Dokumente, Pläne und Lieferleistungen, die aufgesetzt und nachgehalten werden müssen. Denken Sie an Ihre letzten Projekte und erinnern Sie sich daran, wann der Projektplan aufgesetzt und in welchen Frequenzen er aktualisiert wurde bzw. ob er im letzten Drittel des Projekts noch die Realität widerspiegelte. Oder erinnern Sie sich zurück, wie im vergangenen Projekt die Risiken aufgenommen, bewertet, Gegenmaßnahmen entschieden und nachgehalten wurden. In wie vielen Projekten werden überhaupt alle vier Reaktionsmöglichkeiten zu einem Risiko – Akzeptieren, Mitigieren, Transferieren und Umgehen – in Betracht gezogen? Fragen Sie sich einmal, in welchen Projekten eine Requirements-Traceability-Matrix erstellt und gepflegt wurde – ein Dokument, in dem die Businessanforderungen mit den technischen Merkmalen der Lösung verbunden werden und somit die Testerstellung und Abnahme maßgeblich unterstützen und entspannter machen.

Der Projektmanager wird also durch ein Project Office von vielen administrativen Aufgaben entlastet und kann sich darauf konzentrieren, Entscheidungen zu treffen. Das Project Office kann beispielsweise im Risikomanagement ein Risiko vorqualifizieren und aufbereiten, die Entscheidung, wie mit diesem Risiko umgegangen wird, obliegt allerdings immer dem Projektmanager.  Dies hat nicht nur den Hintergrund der klaren Aufgabentrennung zwischen den beiden Parteien, sondern ist häufig auch eine notwendige Maßnahme in den aufkommenden Diskussionen über Fremdarbeitskräfte und Arbeitnehmerüberlassung. In der Praxis bekomme ich häufig zwei Hauptargumente zu hören. Das Project Office übernimmt nur Administration, ohne die das Projekt sowieso viel besser laufen würde, und man sollte daher doch lieber die Bürokratie herunterschrauben. Das zweite Argument, das sich meist nahtlos an das erste anknüpft, liegt in der vermeintlich reaktiven Natur der Aufgaben – ein Project Office sei demzufolge nur eine reagierende Unterstützung gegen die aufkeimende unnötige Bürokratie.

Lassen Sie uns kurz – weil ich es im ersten Absatz zum PO bereits angerissen habe – auf diese beiden Argumente schauen. Beide Punkte zeigen im Übrigen, dass die Definitionen durcheinandergeworfen werden, unterschiedliche Verständnisse aufeinanderprallen oder wenige echte Project Offices existieren.

Bürokratie

Um es vorweg zu nehmen: Ja, in einigen Unternehmen wird das Projektmanagement mit diversen auch unnötigen bürokratischen Hürden konfrontiert, was Mehraufwand bedeutet. Und ja, ein PO kann auch Teile dieser Arbeit übernehmen. Jetzt kommt das Nein, denn ein Großteil der so genannten Bürokratie sind die Kernaufgaben und die Kernartefakte des Projektmanagers, und deren Fehlen ist nach meiner Meinung auch häufig ein Grund für das Scheitern oder etwaige Schwierigkeiten im Projekt. Nehmen wir Zeit- und Ressourcenplanung als Beispiele, dann wird jeder Leser folgendes Phänomen mindestens bei der Zeitplanung kennen: Das Erstellungsdatum des Projektplans ist meist identisch mit dem Datum der letzten Aktualisierung. Bei Nachfragen kommen dann häufig Aussagen wie: „… wir waren unter Zeitdruck und haben erst mal X und Y fertigstellen müssen …“ oder „… ich habe den Plan im Kopf …“ oder ‒ mein Favorit ‒ „… wir sind jetzt im operativen Modus, jeder weiß, dass es kritisch ist und da ist keine Zeit für die Aktualisierung …“. Dramatischer ist es nach meiner Erfahrung mit der Ressourcenplanung, da sie meist überhaupt nicht vorhanden ist. Ich habe Pläne gesehen, in denen Ressourcen zu über 3 000 Prozent überbucht waren, und keinen hat dieses Detail interessiert. Gewundert haben sich die Verantwortlichen nur, dass das Projekt sehr schleppend voranschritt und sehr viele Verzögerungen auftauchten. Um das Ganze mit einem etwas bildhafteren Beispiel zu erklären: Wenn Sie einen Ozean mit einem Schiff überqueren wollen, werden Sie nicht auf die Idee kommen, die Karte zu Hause zu lassen oder die zeitliche Planung nicht mit den an Bord befindlichen Lebensmitteln abzugleichen. Natürlich gibt es Segler auf dieser Welt, die eine solche Aktion ohne Karte machen könnten und die Lebensmittel nach Intuition einkaufen. Während wir normalerweise aber nie auf die Idee kommen, wir könnten mal eben einfach so in See stechen, denken wir als Projektmanager genau umgekehrt: „Ich bin der eine von hundert Projektmanagern, der auch ohne Planung auskommt.“ Warum gehen wir, teils bewusst, dieses Risiko ein und gönnen uns nicht das kleine bisschen (Planungs-)Bürokratie?

Aktion statt Reaktion

Bei all diesen, vermeintlich reaktiven und administrativen, Aufgaben liegt der Schwerpunkt des Project Office in der proaktiven Informationsgewinnung. Ein echtes Project Office wird aktiv auf die Stakeholder zugehen und Risiken aufnehmen, zeitliche Abweichungen bei Lieferleistungen in den Projektplan integrieren, melden und vieles mehr. Der Sinn und Zweck eines Project Office ist gerade, dass es dem Projektmanager die Informationen beschafft, die er für die Entscheidungen benötigt. Diese Art der Arbeit ist also per Definition schon aktiv und nicht reaktiv. Der Eindruck einer reaktiven Arbeitsweise entsteht meiner Meinung nach dann, wenn ein PO nicht richtig dimensioniert ist und somit in Arbeit ertrinkt bzw. richtig dimensioniert ist und in Nicht-PO-Aufgaben ertrinkt. Nach meiner Erfahrung werden häufig Project-Assistant-Aufgaben an das PO gegeben, und hier gilt das gleiche Prinzip: Wenn ein PO bestehend aus zwei Kollegen damit beschäftig wird, in Meetings zu sitzen und Protokolle zu schreiben, bleibt keine Zeit mehr für die eigentlichen wertschöpfenden, proaktiven Project-Office-Tätigkeiten.

Project Office
Betreuung des Projekts/Programms
Aufgaben: administrative Unterstützung in den Kerngebieten des Projektmanagements
• Projektplanung
• Budgetplanung/Controlling
• Ressourcenplanung
• Risikomanagement
• Management der Lieferleistungen
• Kommunikationsmanagement
• Qualitätsmanagement
• Management des Projektumfangs
• Management der beteiligten Personen und Erwartungen • Meldewesen/Statusberichte
Vorteile:
• schnelle Einarbeitung durch stringente Führungsmöglichkeit
• individuelle Unterstützung
• kein Know-how-Transfer am Projektende notwendig (das Wissen bleibt im Unternehmen)
• hohe Skalierbarkeit
Fehlerquellen:
• häufiger Missbrauch durch Übertragung weiterer Aufgaben, die nicht zum eigenen Leistungsspektrum zählen
• Selbstorganisation – je komplexer das Projekt/Programm, desto besser muss ein PO organisiert sein
Skalierbarkeit:
• je nach Projekt- bzw. Programmgröße und Komplexität kann ein PO aus einer oder mehreren Personen bestehen; die Herausforderungen in sehr großen Programmen ist vielmehr die Aufgabenteilung innerhalb des PO, damit eine koordinierte Unterstützung gewährleistet werden kann

Besonderheit: Shared Service Center

Das Project Office ist die einzige der drei Unterstützungsoptionen, bei der man den Service auch zentral mehreren Projekten oder Programmen zur Verfügung stellen kann. Wenn beispielsweise das Projektportfolio vornehmlich aus kleineren Projekten besteht, bei denen eine Person im PO nicht Vollzeit beschäftigt wäre, kann ein so genanntes Shared Service Center (SSC) in der Organisation aufgebaut werden. In diesem SSC befinden sich dann meist mehrere PO-Kollegen, die ihre Services den kleinen Projekten zur Verfügung stellen. Hier können die Kosten gesenkt und die Qualität verbessert werden. Zudem haben die Projekte weiterhin einen gleichbleibenden Ansprechpartner für die Arbeiten. Innerhalb des SSC bietet sich dann noch die Möglichkeit, die anfallenden Tätigkeiten durch einen Experten durchführen zu lassen (bspw. Risikomanagement, Projektzeitplanung oder Budgetplanung).

Project Management Office – der kleine, aber feine Unterschied

Das kleine Wort „Management“ macht den großen Unterschied, denn beim Project Management Office (PMO) handelt es sich um eine Stabsfunktion im Unternehmen. Idealtypisch werden hier die Vorgaben für das gesamte Unternehmen in puncto Projektmanagement gemacht und deren Einhaltung überwacht. Ein PMO hat zwei Hauptaufgaben. Es ist die Schnittstelle zwischen den Projekten und der Geschäftsleitung und liefert Antworten auf die Frage, wo das Unternehmen bezogen auf seine Projekte steht. Es versetzt somit die Geschäftsführung in die Lage, Entscheidungen zur Unternehmenszukunft bzw. für das Daily Business zu treffen. Die zweite Aufgabe ist die Schaffung und Erhaltung einer Projektmanagementkultur, in der Projekterfolg wiederholbar gemacht wird und gemachte Fehler künftig vermieden werden. Für die Projekte bietet es Antworten auf die Fragen, welche Key Performance Indicators sollen in welchem Rhythmus gemeldet werden, welche Projektmanagementvorgehensweise wird verwendet, woran sind vorherige Projekte womöglich gescheitert oder wo hatten sie erhebliche Schwierigkeiten und so weiter.

Das Aufgabenspektrum des Project Management Office ist ähnlich eines Maturity Levels gestaltbar. So gibt es PMOs auf einer ersten Stufe, die ausschließlich Vorgaben in puncto KPIs, Templates und Reporting-Zyklen für die Projekte machen, bis hin zu PMOs, bei denen die Ausbildung der Projektmanager integriert ist, die Ressourcen (Räume, elektronische Medien etc.) vergeben sowie zentrale Risikomatrizen, Qualitätsstandards oder ein zentrales Wissensmanagement zur Verfügung stellen. In einer älteren Umfrage von PMI aus dem Jahr 2005 (die 2010 gleicher Form wiederholt wurde) wurde herausgefunden, dass viele Unternehmen ihre PMOs nach kurzer Zeit aus verschiedenen Gründen wieder schließen. Nach einem Jahr waren 25 Prozent der PMOs, nach zwei Jahren 50 Prozent und nach drei Jahren ganze 75 Prozent der ursprünglich vorhandenen PMOs wieder eingestampft. Warum passiert so etwas? Meine Beobachtungen decken sich da mit neueren Studien zur Wirksamkeit von PMOs und auch den Erfahrungen des Autors Mark Price Perry und lassen sich in vier Kategorien aufteilen:

• Zusammenlegung von PO und PMO
• Personelle Besetzung des PMO
• Mandat der Geschäftsleitung
• Verlust des Fokus

Strikte Trennung

Unternehmen kombinieren POs und PMOs zu einer Organisationseinheit, wodurch die Aufgaben vermischt werden und es zur Überlastung kommt bzw. zu einem Governance-Problem, da die gleiche Einheit die Vorgaben macht, gleichzeitig versucht, diese einzuhalten und auch noch diesen Zustand zu überwachen. Die wichtige Funktion, Projekterfolg wiederholbar zu machen, geht verloren.

Ausbildungsstätte PMO?

Die zweite Fehlerquelle ist häufig die Besetzung des PMOs mit Junioren, mit dem Gedanken, diese auf der PMO-Position in das Projektmanagement einzulernen. Das PMO ist keine Einheit, in der die Kollegen das Handwerk lernen. Es ist die Stelle, an der alle wissen müssen, wie das Handwerk in seinen Details funktioniert. Hier müssen gestandene Projektmanager mit mehreren Jahren Erfahrung sitzen. Kurz: Kollegen, die wissen, wie man den Projekten den wahren Status entlocken kann, um der Geschäftsleitung ein echtes Bild zeigen zu können.

Mandat oder Lippenbekenntnis

Ein weiterer häufiger Fehler ist das fehlende klare Mandat der Geschäftsleitung, wodurch der Auftrag zu einem Lippenbekenntnis abgewertet wird. Wenn das PMO kein Mandat hat und die Projekte auch ohne die Vorgaben weiterarbeiten können, herrscht genau die unter Project Office angesprochene sinnlose Bürokratie.

Fokus, Fokus, Fokus

Je länger ein PMO im Amt ist, desto größer ist die Gefahr, dass es den Fokus verliert. Den Nährboden für diesen Verlust bilden die drei erstgenannten Fehler. Sie haben es bestimmt auch schon erlebt, dass ein PMO im Unternehmen mehrheitlich die Templates pflegt und sich aufregt, wenn diese Templates wahlweise nicht genutzt oder von den Projekten ständig nahezu vollständig geändert werden. Oder wenn regelmäßige Publikationen wie Statusberichte und Ähnliches vom PMO aufs Sorgfältigste geprüft werden und beinahe ein Gütesiegel bekommen müssen. In all diesen Fällen ist das PMO zu einer Templatepolizei oder zu einem Auditor – was im Übrigen die Aufgabe einer Compliance wäre – mutiert und hat seine beiden wahren Aufgaben aus den Augen verloren: Die Schnittstellenfunktion (die Aufbereitung der Projektdaten für die Unternehmensführung) und die Unterstützungsfunktion (den Projekten zum Projekterfolg verhelfen).

Es geht auch anders

Wie eine Studie von PM Solutions aus dem Jahr 2010 zeigt, kann ein PMO durchaus einen erheblichen Mehrwert liefern. So konnte gezeigt werden, dass bei einem gut funktionierenden PMO

• weniger Projekte aufgegeben werden.
• Projekte sogar unter dem Budget bleiben können.
• Projekte „in time“ fertiggestellt werden können.
• Ressourcen besser genutzt werden können.
• Kosten gespart werden können (in der Studie bis zu 567 000 US-Dollar).

Project Management Office
Schaffen und Erhalten einer Projektmanagementkultur
Aufgaben:
• Variabel und somit unternehmensabhängig mindestens jedoch
o Rahmen schaffen und Vorgaben definieren für Projekte
o Aufbereiten der Lessons Learned aus den Projekten
• Darüber hinaus ggf.
o Ausbildung der Projektmanager
o Ressourcenverteilung
o zentrale Templateverwaltung und -aktualisierung
o und weitere
Vorteile:
Standardisierung des Projektmanagements und somit Erfolg wiederholbar machen und künftig Fehler vermeiden
Fehlerquellen:
• Fehlende Struktur durch Kombination von PMO und PO in einer Organisationseinheit
• Falsche Besetzung – Junioren statt erfahrene Projektmanager
• Fehlendes klares Mandat der Geschäftsführung – das Wort bzw. die Vorgaben des PMO haben kein Gewicht oder werden ohne Konsequenzen umgangen
Skalierbarkeit:
• Je nach Anzahl der Projekte/Programme bzw. Größe des Projektportfolios kann ein PMO aus einer oder mehreren Personen bestehen; die Skalierbarkeit ist gegeben, aber nur in gewissem Maße sinnvoll aufgrund der Aufgaben

Zusammenfassung – Das Big Picture

Wenn Sie jetzt einen Blick auf das Gesamtbild werfen und die drei Unterstützungsarten betrachten, werden Sie mir zustimmen, dass die begriffliche Trennung sinnvoll ist und alle drei Optionen sich ergänzen. Entsprechend können kleinere Projekte mit Project Assistants oder einem Project Office Shared Service Center unterstützt werden, wohingegen größere Projekte und Programme ein eigenes Project Office haben sollten. Um als Unternehmen Projektmanagement zu kultivieren, Projekterfolge wiederholbar zu machen und das Projektmanagement kontinuierlich zu verbessern, sollte das PMO als Unternehmensinstanz eingesetzt werden. Dann gewinnen alle Beteiligten. Es werden nicht mehr die gleichen Fehler wiederholt und das Projektportfolio für ein noch klareres Bild der Geschäftsleitung aufbereitet. Wie sieht es in Ihrem Projekt aus, welche Verbesserungen könnte Ihr Unternehmen vertragen? Rufen Sie sich bei Ihrem nächsten Projekt diesen Artikel in Erinnerung und lassen Sie sich unterstützen. Schreiben Sie mir Ihre Erfahrungen!

Aufmacherbild: Team of businesspeople build a new company von Shutterstock / Urheberrecht: alphaspirit

Verwandte Themen:

Geschrieben von
Marcus Konitzny
Marcus Konitzny ist Teammanager Project Office Services bei dem unabhängigen Management-, Fach- und IT-Beratungsunternehmen EXXETA AG. Er verfügt über mehr als zehn Jahre Projekterfahrung als Projektleiter sowie in der Projektunterstützung und -auditierung in unterschiedlichen IT-Projekten unterschiedlicher Branchen.Mail: Marcus.Konitzny@EXXETA.com
Kommentare

Hinterlasse einen Kommentar

avatar
4000
  Subscribe  
Benachrichtige mich zu: