Das Reifegradmodell für Projektmanagementsysteme: Whitepaper

Dieses Whitepaper ist Teil unserer Sammlung "Aus der Praxis". Es beschreibt, wie Organisationen während ihres Reifungsprozesses bei der Verwendung ihrer Projektmanagementsysteme effektiver werden können. Es beschreibt ferner, wie es in Unternehmen effektiver sein kann, sich nur für die Nutzung bestimmter Aspekte eines neuen Projektmanagementsystems bis zu dem Grad, zu entscheiden, bei dem man sich wohlfühlt, auch wenn man versucht ist, alle Features, die verfügbar sind, auch zu nutzen. Während sich das Unternehmen weiterentwickelt und reift, kann die Verwendung der erforderlichen Features durchaus komplexer werden.

Eine Word-Version dieses Whitepapers können Sie unter Das Reifegradmodell für Projektmanagementsysteme: Whitepaper herunterladen.

Weitere Whitepapers finden Sie unter "Aus der Praxis" – Whitepapers.

Das Reifegradmodell für Projektmanagementsysteme

Das Modell des Projektmanagementreifegrads (Project Management Maturity, PMM) ist im Moment ein ziemlich angesagtes Thema. Es gibt ganze Scharen von Beratern, die gut davon leben können, Organisationen bei der Bewertung des "Projektreifegrads" zu helfen, der praktisch immer hierarchisch illustriert wird, wobei reifer immer als besser dargestellt wird gegenüber weniger reif. Befürworter des Konzepts sagen, dass das PMM-Modell die Fähigkeiten einer Organisation zum Management von Projekten aufzeigt. Man könnte tagelang darüber reden, wie Organisationen effektiver werden können, und ich bin mir nicht sicher, ob es notwendigerweise dafür ausreicht, alleine im PMM-Modell eine höhere Kompetenzstufe zu erreichen. Aber dieses Thema wollen wir an einem anderen Tag behandeln. Ob Sie nun Verfechter des PMM-Modells sind oder nicht, es gibt eine andere Art von Reifegradmodell, das ich bei Organisationen gesehen habe, die Projektmanagementsysteme verwenden.

Wenn wir mit Organisationen arbeiten, die ein Projektmanagementsystem bereitstellen, findet man häufig, dass es der Wunsch der Organisation ist, die Vorteile jedes einzelnen Elements des neuen Systems ausnutzen zu wollen, das ihnen gerade vom Verkäufer demonstriert wurde. Der Kunde sieht Berichte und Bildschirme, Workflows und Funktionen, von denen er immer geträumt hat, und er malt sich sofort aus, wie alle diese Funktionen genauso naht- und problemlos in seiner Organisation funktionieren, wie es soeben bei der Verkaufsdemonstration der Fall war. Normalerweise ist dem Kunden nicht klar, das die vorgeführten Demodaten und die Demokonfiguration sorgfältig für die Demonstrationszwecke eines maximalen Funktionsumfangs des Produkts entwickelt wurden Im Falle von Microsoft Project und Project Server kann dies weit über das einzelne Produkt hinausgehen und die gesamte Technologiesparte umfassen.

Der Kunde sieht Bildschirme, die aus Windows SharePoint Services oder aus Microsoft Office SharePoint Server-Formularen stammen. Er sieht Funktionen, die mit Active Directory oder SQL Server Reporting Services zu tun haben. Möglicherweise sieht er auch Workflows aus BizTalk Server oder Windows Workflow Foundation sowie Anzeigen aus PerformancePoint. Der Datenfluss folgt möglicherweise einem Drehbuch oder einem Anwendungsfallszenario, das das Verständnis der möglichen Vorteile erleichtert, das Verständnis der zugrunde liegenden Technologien aber erschwert.

Wenn wir dann an dem Punkt sind, wo wir tatsächlich die Funktionen bereitstellen sollen, an denen der Kunde interessiert ist, müssen wir seine Wünsche, sofort alles bereitzustellen, erst einmal etwas zügeln, indem wir ihm die Augen über die Realität öffnen. Der Kunde muss entscheiden, wie er seine Geschäfte führen möchte, bevor wir überhaupt daran denken können, solche Funktionen zu konfigurieren, und entscheiden können, ob diese Funktionen mit vorgefertigten Lösungen oder mit Konfigurations- oder Anpassungsaufwand erzielt werden können. Es gibt einige Kunden, die darauf bestehen, alle Funktionen, die sie gesehen haben, in vollem Umfang bereitzustellen, und darauf vorbereitet sind, sich zu engagieren und den Aufwand für Design, Schulung, Einarbeitung und Entwicklung für diese Lösung zu investieren sowie die zeitlichen als auch finanziellen Mittel für die Bereitstellung der Lösung zur Verfügung zu stellen – aber diese Organisationen sind die Ausnahme.

Viel verbreiteter ist jedoch, dass der Kunde sich entschließt, die Teile seines neuen Projektmanagementsystems in dem Umfang bereitzustellen, mit dem er bereits vertraut ist. Je mehr die Kenntnisse der Organisation über das System und die zugrunde liegenden Geschäftsprozesse wachsen, desto mehr wird die Organisation dem System auch abverlangen und so im Rahmen dieser Fortschritte "reifer werden". Dies ist eine natürliche Entwicklung.

In gleichem Maße, wie sich das Verständnis der Organisation für einen automatisierbaren Projektmanagementprozess herausbildet, wird sich auch ihr Bedarf für diese Automatisierungslösung entwickeln. Diese natürliche Entwicklung entspricht vollkommen den Projektmanagement- oder Fähigkeitsreifegrad-Modellen ("Capability Maturity"). Durch unsere Kenntnis, dass sich Organisationen höchstwahrscheinlich entlang dieser Pfade entwickeln, wissen wir heutzutage äußerst effektiv, an welcher Stelle wir Aufwand investieren müssen, um eine Organisation effektiver zu machen. Wir tendieren dazu, den Schwerpunkt auf die Bereiche des Projektsystems zu legen, von denen wir wissen, dass sie eine höhere Chance für Akzeptanz haben und eine Investitionsrendite liefern können, auf Grundlage des Reifegrads des Projektsystems der Organisation. Natürlich sind keine zwei Organisationen gleich, weshalb es keine gute Idee ist, diese Kenntnisse in Stein zu meißeln. Es handelt sich lediglich um die wahrscheinlichste Entwicklung auf Grundlage unserer Erfahrung mit zahlreichen Unternehmen.

Nach unserer Erfahrung erfolgt die natürliche Evolution der Nutzung eines Projektmanagementsystems in fünf grundlegenden Bereichen, obgleich sich deren Reihenfolge in den letzten Jahren, größtenteils aufgrund der Technologie, verschoben hat. Lassen Sie uns damit beginnen, dass wir über diese fünf Bereiche reden, und am Ende dieses Artikels werde ich dann einige der neueren Verschiebungen behandeln, die sich in den letzten Jahren ereignet haben.

5 Hauptbereiche eines Projektmanagementsystems

1 – Planung   . Fast immer sehen wir die Planung als ersten Schritt. Manche Organisationen kommen nie über diese Phase hinaus. Sie erstellen einen grundlegenden Zeitplan, gießen das GANTT-Diagramm in Bronze und hängen es im Büro des Projektteams an die Wand. Ab und zu sehen sich die Leute die Bronzetafel mit einem Hauch von Nostalgie noch einmal an, während Sie sich an den tollen Status ihres Zeitplans vor Projektbeginn erinnern.

Wenn ich auch ein bisschen grausam gegenüber denjenigen bin, die ihre kostspielige Projektmanagementsoftware nur verwenden, um ein Balkendiagramm zu erstellen, kann man hieraus doch durchaus auch Nutzen ziehen. Das Erstellen eines organisierten Zeitplans veranlasst die Projektteilnehmer eher dazu, darüber nachzudenken, wie die Arbeit organisiert werden sollte, und es ist wesentlich effektiver, als nur eine tabellarische Liste aufzustellen.

2 – Überwachung   . Als Nächstes kommt nach unserer Erfahrung die Überwachung. Eine Organisation, die schon ein wenig "reifer" bei der Verwendung ihres Projektmanagementsystems ist, wird nicht nur planen, sondern ihre Pläne auch überwachen und nachverfolgen und regelmäßig mit den Fortschritten bis zum aktuellen Datum aktualisieren und fortschreiben und sogar mit Prognoseplänen einen Blick in die Zukunft werfen, während die Pläne fortschreiten. Für viele Organisationen ist es effektiv, hier aufzuhören. Sie führen die Planung im Projektmanagementsystem durch und arbeiten den Plan dann ab, indem sie ihn regelmäßig aktualisieren und sogar nützliche Berichte für das Management erstellen.

3 – Ressourcenmanagement   . Nachdem Planung und Überwachung versorgt sind, wenden sich Organisationen tendenziell dem Problem des Ressourcenmanagements zu und wie dieses mithilfe des Projektmanagementsystems gelöst werden kann. Ressourcen können, wie ich an dieser Stelle bereits diskutiert habe, zahlreiche Aspekte besitzen, doch auf der einfachsten Stufe stellt die Ressourcenzuordnung (das Zuweisen der Arbeit zu Ressourcen) einen großen Schritt dar, auf den eine wie auch immer geartete Ressourcenanalyse folgt.

4 – Kostenmanagement   . Das Kostenmanagement ist der vierte typische Bereich, zu dem viele Organisationen nie gelangen. Auf einer grundlegenden Stufe ist das Vorhandensein der Aufschlüsselung einer Kostenabschätzung nach Phasen, oder noch besser nach Aufgaben im Projekt ein guter Ausgangspunkt für eine Kostenkalkulation. Die nächste Stufe ist dann die Kontrolle der tatsächlichen Kosten, entweder nach Stunden oder nach Euros.

5 – Fortgeschritten   . Ich habe hier einen fünften Bereich für "fortgeschrittene" Aspekte erstellt, bei denen es sich um eine breite Palette von Themen handeln kann, die in den anderen vier Kategorien noch nicht abgedeckt sind. Nicht, dass sie nicht wichtig wären, aber wenn Sie erst einmal als Organisation zum fünften Bereich vorgestoßen sind, kann sich dieser in viele verschiedene Richtungen entwickeln Somit werden hier Risikoanalyse, Dokumentenmanagement und automatisierte Workflows erfasst. Es gibt außerdem in jedem der vier anderen Bereiche, die ich bereits angesprochen habe, ebenfalls fortgeschrittene Bereiche.

Jedes der Elemente, die ich bisher besprochen habe, könnte noch erweitert werden und wird es auch häufig tatsächlich, wenn der Projektreifegrad der Organisation und ihr Verständnis der automatisierten Aspekte der eigenen Projektmanagementumgebung wachsen.

Die Planung kann sich zu integrierten Plänen mit mehreren Projekten hin entwickeln mit Verknüpfungen zwischen Projekten oder Programmmanagement mit Unterprojekten.

Bei der Überwachung entwickelt sich die Organisation in der Regel vom Fortschritt der einfachen prozentualen Fertigstellung, was normalerweise die niedrigste Qualität für die Datenüberwachung darstellt, hin zur Restdauer. Die Überwachung kann sich auch auf Arbeitszeittabellen ausdehnen, um einen exakten Wert der geleisteten Ist-Stunden gegenüber dem ursprünglichen Soll-Wert pro Person zu ermitteln.

Im Bereich der Ressourcen finden wir Entwicklungen von der reinen Zuordnung von Aufgaben zu Ressourcen hin zur Erfassung des Ressourcenfortschritts, in der Regel mit Arbeitszeittabellen, bis hin zum am stärksten vom EPM nachgefragten Aspekt, der Ressourcenkapazitätsplanung. Bei einigen Organisationen gehört in diesen Bereich auch die Critical Chain, wobei dann die Ressourcen- und Zeitplaninformationen in einem komplexeren Algorithmus zusammengeführt werden.

Hinsichtlich des Kostenbereichs geht die Entwicklung normalerweise von einer grundlegenden Budgetierung über die Erfassung von Ist-Kosten und Ist-Stunden, um die tatsächliche Abweichung zwischen Budget (Soll) und Ist-Werten zu erhalten, hin zur Erfassung des Leistungswerts (Earned Value), wie sie in den Sparten Verteidigung und Luft- und Raumfahrt üblich ist.

Selbst im fortgeschrittenen Bereich gibt es noch stärker fortgeschrittene Themen. Das beliebteste hierunter ist die Monte-Carlo-Risikoanalyse und die Integration von Projektmanagementmethoden (insbesondere im IT-Sektor).

Grundlegende und komplexere Bereiche eines Projektmanagementsystems

Die meisten Organisationen entwickeln sich in allen fünf grundlegenden Elementen von links in der oben dargestellten Grafik in der Reihenfolge, die ich gerade beschrieben habe, bevor sie sich einem der fortgeschrittenen Bereiche zuwenden. Manche sind der Meinung, dass ihr besonderer Projektmanagementanspruch fordert, dass sie sich noch vor dem einen Element auf ein anderes konzentrieren. Was aber äußerst schwer und selten erfolgreich ist, ist der Versuch, reifer zu sein, als man wirklich ist.

Sehr häufig taucht in Organisationen der Wunsch nach Ressourcenkapazitätsplanung auf, doch wenn Sie sich die Kompetenz und Erfahrung der Organisation ansehen, stellen Sie fest, dass die Bausteine zum Erstellen eines Systems für die Ressourcenkapazitätsplanung fehlen. Ich verwende häufig die Kapazitätsplanung als Beispiel dafür, warum die Kenntnis, wo man im PMM-Modell steht, so wichtig ist. Nach meiner Erfahrung ist dies zwar der am häufigsten nachgefragte Einzelvorteil von EPM-Systemen, doch ist es auch gleichzeitig der Vorteil, zu dem ich praktisch erst zuletzt verhelfen kann. Dies liegt daran, dass eine Ressourcenkapazitätsplanung erfordert, dass so viele andere Voraussetzungen zuerst funktionieren müssen. Um projektierte Ressourcenanforderungen gegenüber den verfügbaren Ressourcen bereitstellen zu können, benötigen wir zuerst:

  • zuverlässige Projektpläne

  • Projekte mit exakt erfasstem Fortschritt/Status

  • die Zuordnung aller Aufgaben zu Ressourcen

  • vollständige und exakte Ressourcenverfügbarkeit

  • Quantifizierung und Erfassung aller nicht projektbezogenen Arbeiten

  • vollständige Konformität seitens der Projektmanager und Abteilungsmanager hinsichtlich erledigter Arbeiten, projektierter Arbeiten und Veränderungen bei Ressourcen

Wow! Das ist keine kleine Liste, und die Unternehmenskultur, die für die Einhaltung einer solchen Umgebung erforderlich ist, erfordert wiederum häufig ein Change Management im großen Maßstab. Somit wenden wir uns wieder unserem Reifegradmodell für Projektmanagementsysteme zu, und der Kunde kann eine Roadmap seiner zu erreichenden Ziele entwerfen.

Dies ist natürlich keine erschöpfende Liste. Wir können bequem noch eine dritte Spalte, dann eine vierte usw. aufmachen, aber ich habe hier Abstand davon genommen, weil ab diesem Punkt der gängigste Fortschritt weniger klar wird. Die Projektmanagementanforderungen jeder Organisation diktieren deren Interesse an der Fortentwicklung in einem bestimmten Bereich.

Ich habe weiter oben in diesem Artikel versprochen, eine Veränderung zu diskutieren, die sich in den letzten Jahren vollzogen hat. Das Modell, das ich oben beschrieben habe, hatte für eine ganze Weile Gültigkeit, aber in den letzten Jahren hat sich in der IT-Branche einiges signifikant in eine andere Richtung verschoben, und das hat alles mit Zusammenarbeit zu tun.

Zu einem bestimmten Zeitpunkt war die Projektmanagementsoftware-Branche sehr algorithmuszentriert ausgerichtet. Wir glaubten, dass alles auf den kritischen Pfad des Zeitplans zurückzuführen sei. In den letzten Jahren haben sich dennoch ein paar Sachen geändert. Zunächst einmal hat es die Verfügbarkeit von Personen durch das allgegenwärtige Internet bzw. die Telefonietechnologie sogar noch einfacher gemacht, Ihr Projektteam zusammenzustellen und mit ihm zu kommunizieren. Dies hat Änderungen bewirkt, wer zu einem Projektmanagementteam gehört. Während wir uns früher unter Mitgliedern eines Projektteams Leute vorgestellt haben, die sich tief in der Organisation befinden und in einem kleinen, fensterlosen Raum an Schreibtischen arbeiten, die einen großen Plotter umgeben, denken wir heute bei Projektteammitgliedern an Personen, die über die gesamte Organisation verstreut sind.

Teammitglieder umfassen natürlich diejenigen, die die Arbeit erledigen, können aber auch den Projektleiter (Executive Sponsor), die Ressourcen-Manager der Abteilungen, die Benutzer und die Marketingabteilung einschließen. Es ist heutzutage gar nicht ungewöhnlich, dass sich ein Projektteam nicht nur über die Gebäudegrenzen hinaus, sondern auch bis weit über die Organisation hinaus erstreckt, um so Subunternehmer, Generalunternehmer und sogar den Kunden zu umfassen. Subunternehmer befinden sich möglicherweise nicht in derselben Zeitzone oder noch nicht einmal im selben Land. Durch all diese Umstände ist die Kommunikation in zahlreichen, unterschiedlichen Branchen zum Schlüsselfaktor für den Erfolg von Projekten geworden.

Dies hat einige Organisationen in Branchen wie der Forschung und Entwicklung (R&D) oder IT veranlasst, ein Reifegradmodell für Projektmanagementsysteme zu betrachten, dass sich anders entwickelt:

Neu angeordnete Elemente eines Projektmanagementsystems

Das erste Element in diesen Organisationen ist das Erstellen eines Kommunikationsplans, der praktisch immer auf einer Zusammenarbeitstechnologie wie SharePoint Server basiert. Diese Organisationen sind aus einer zentralisierten Perspektive der Meinung, dass sie größere Vorteile erzielen können, indem sie ihr ausgedehntes Projektmanagementteam zur Zusammenarbeit und Kommunikation bewegen können, als durch jegliche zentralisierte Planung. Der kometenhafte Aufstieg von SharePoint Server auf der Beliebtheitsskala ist ein Zeugnis dafür, wie groß das aufgestaute Bedürfnis ist, Menschen zur Zusammenarbeit zu bewegen.

Die Entwicklung geht dann häufig von einem einfachen Kommunikationsplan weiter zum Dokumentenmanagement – wobei ein Dokument davon sehr gut ein Projektzeitplan sein kann. Hierbei wird der klassische Projektmanagementfortschritt in Unternehmen auf den Kopf gestellt, aber Sie können erkennen, wie attraktiv dies für manche Organisationen sein muss. Wenn Sie einmal die Verträge, Dokumente, E-Mails, Besprechungen und anderen Kommunikationsformen im Griff haben, steigt die Effizienz sehr schnell. Bekommen Sie die Kommunikation nicht in den Griff, kann der Effizienzverlust gravierend sein.

Vom Dokumentenmanagement ist es nur noch ein kleiner Schritt zum Problemmanagement und zur Durchführung eines Change Managements – das für IT und R&D bedeutet, einen der potenziell schädlichsten Aspekte eines Projekts zu managen.

Überraschenderweise kommen als Nächstes die Arbeitszeittabellen. Tatsächlich werden Arbeitszeittabellen sogar schon früher eingeführt. Als unsere Organisation mit unserem TimeControl-Produkt in das Arbeitszeittabellengeschäft eingestiegen ist, waren wir ziemlich sicher, dass Organisationen, die eine Arbeitszeittabelle wie unsere benötigen, diejenigen sind, die bereits über ausreichend reife Planungs- und Überwachungsprozesse verfügen, um in der Lage zu sein, daraus Nutzen zu ziehen. Sie können sich unsere Überraschung vorstellen, als wir herausfanden, dass zahlreiche Organisationen eine Arbeitszeittabelle im Unternehmen bereitstellen möchten, bevor sie ein Projektmanagementsystem im Unternehmen einrichten. Wenn Sie sich die Herausforderungen des Change Managements beider Alternativen ansehen, wird schnell klar warum. Die meisten Benutzer werden eine Arbeitszeittabelle widerstrebend aber schnell akzeptieren. Eine Organisation mit 1000 Personen dazu zu bringen, ein zentralisiertes Arbeitszeittabellen-System zu akzeptieren, dauert Wochen. Dieselben 1000 Benutzer dazu zu bewegen, ein zentralisiertes Projektmanagementsystem zu akzeptieren, kann zwischen Monaten und einigen Jahren dauern. Somit kann die Organisation, selbst wenn die zentralisierte Planung noch nicht etabliert ist, dennoch umfangreichen Nutzen aus zentralisierten Arbeitszeittabellen-Daten ziehen.

Schließlich wenden diese Organisationen dann ihre Aufmerksamkeit der "Hauptübung" der Projektplanung zu. Dies soll nicht heißen, dass nicht schon Projektzeitplanung betrieben wurde, aber sie war dann noch nicht allzu zentralisiert.

Wie bei dem ersten Reifegradmodell für Projektmanagementsysteme kann jedes dieser Elemente ebenfalls fortgeschrittene Aspekte beinhalten.

Kommunikationspläne entwickeln sich häufig zu stärker integrierten Kommunikationssystemen, einschließlich Instant Messaging/Chat, E-Mail-Integration und mehr.

Das Dokumentenmanagement entwickelt sich häufig zu Workflowmanagement und Formularintegration.

Das Problemmanagement entwickelt sich normalerweise zum Management von Listen aller Arten und einem integrierten Change Management-Prozess.

Arbeitszeittabellen beginnen als einfache Aufgabenzeittabellen, werden dann mit Buchhaltung, Lohnbuchhaltung und Personalwesen verknüpft, und letztendlich erfolgt eine Rückverknüpfung zum Projektmanagementsystem des Unternehmens, um die auditfähige Überwachung von Daten zu ermöglichen.

Planung und Ressourcenmanagement entwickeln sich eher analog zu meinem klassischen Reifegradmodell für Projektmanagementsysteme.

Es gibt weder eine "richtige" Art, sich bei der Verwendung Ihres Projektmanagementsystems fortzuentwickeln, noch einen "falschen" Weg. Wie ich bereits in früheren Kolumnen gesagt habe, ist das Wichtigste, dass Sie sich zuerst ansehen, was Sie erreichen müssen, um als Organisation effektiver zu werden, um von dieser Basis aus dann die Lösung für diese Herausforderung zu entwerfen. Wichtig hierbei ist das Wissen, dass Sie die Bausteine aus den grundlegenden Elementen besitzen, bevor Sie damit beginnen, eine fortgeschrittenere Lösung zu entwickeln. Sie werden mich häufig sagen hören, dass wir zuerst Projektmanagementgrundlagen benötigen, bevor wir zu Projektmanagement-Doktoren werden.

Denken Sie daran, dass der Einsatz eines Projektmanagementsystems nur ein Aspekt einer möglichen Lösung ist, und dass es ganz bei Ihnen liegt, zu entscheiden, wie "reif" und in welchen Bereichen Sie dies sein sollten, um das Management Ihrer Projekte effektiver zu gestalten.

Informationen zum Autor

Chris Vandersluis ist der Präsident und Gründer von HMS Software, einem im kanadischen Montreal ansässigen Microsoft Certified Partner. Er hat einen Abschluss in Wirtschaftswissenschaften von der McGill University und mehr als 30 Jahre Erfahrung in der Automatisierung von Projektsteuerungssystemen. Er ist ein langjähriges Mitglied des PMI (Project Management Institute) und hat geholfen, die Ortsverbände der Microsoft Project-Benutzergruppen (MPUG) in Montreal, Toronto und Quebec zu gründen. Vandersluis hat Beiträge in Fortune, Heavy Construction News, im Magazin "Computing Canada" und im PMNetwork von PMI veröffentlicht. Darüber hinaus verfasst er regelmäßig die Leitartikel für Project Times. Er unterrichtet Projektmanagement für Fortgeschrittene an der McGill University und hält häufig Vorträge auf Veranstaltungen der Project Management Association in Nordamerika und weltweit. HMS Software ist der Herausgeber von TimeControl, einem projektorientierten Zeiterfassungssystem, und seit 1995 ein Microsoft Project Solution Partner.

Sie können Chris Vandersluis per E-Mail kontaktieren: chris.vandersluis@hms.ca

Wenn Sie weitere EPM-bezogene Artikel von Chris Vandersluis lesen möchten, besuchen Sie die EPM Guidance-Website von HMS (http://www.epmguidance.com/?page_id=39).

Teilen Facebook Facebook Twitter Twitter E-Mail E-Mail

War diese Information hilfreich?

Sehr gut. Noch anderes Feedback?

Was können wir verbessern?

Vielen Dank für Ihr Feedback!

×