EPM: zentralisiert oder dezentralisiert?

Dieser Artikel ist Teil unserer Sammlung "From the Trenches". Es wird beschrieben, wie Organisationen die Probleme verstehen müssen, die sie lösen möchten, wenn sie sich für die Implementierung eines Projektmanagementsystems entscheiden. Manchmal ist die Bereitstellung eines zentrales Projektmanagementsystems nicht unbedingt die beste Lösung.

Informationen zum Herunterladen der Word-Version dieses Artikels finden Sie unter EPM-Zentral oder Dezentralisiert?.

Weitere Artikel finden Sie in den Whitepapers "Aus den Gräben".

EPM - Zentral oder Dezentralisiert?

Ich bin ein Verfechter des Enterprise-Projektmanagements, seit ich anfang der 1980er Jahre in die Projektmanagementbranche eingetreten bin. Sie würden also denken, dass ich immer auf der Seite des zentralisierten Projektmanagements abstimmen würde, aber das ist nicht immer der Fall. Lassen Sie uns kurz besprechen, was wir unter Enterprise Project Management verstehen.

EPM kann für verschiedene Menschen viele verschiedene Dinge bedeuten. Ich habe bereits in anderen Artikeln in dieser Spalte erläutert, wie der Schwerpunkt einer EPM-Bereitstellung möglicherweise die Dokumentverwaltung für eine Organisation und integrierte Zeitpläne für die nächste sein kann. Im Mittelpunkt des Enterprise-Projektmanagements steht jedoch die Vorstellung, dass Personen in der Projektmanagementübung miteinander interagieren müssen. Das bedeutet, dass der Projektmanager und/oder das Projektmanagementteam nicht völlig unabhängig arbeiten. Aber bedeutet das, dass die einzige Möglichkeit, diese "Interaktion" zu erreichen, ein zentralisiertes Projektplanungssystem ist? Nicht unbedingt. Für einige Organisationen ist die Projektmanagement-Herausforderung möglicherweise nicht in der Möglichkeit, zusammenfassende, unternehmensweite Projektmanagementberichte zu erstellen, da alle Projekte auf Ad-hoc-Basis verwaltet werden. In diesem Fall kann EPM nur durch Projektstandards erreicht werden, die von allen Projektmanagementmitarbeitern gemeinsam genutzt werden. Dies lässt sich am besten mit einem zentralen Pool von Vorlagen, Schulungsmaterialien, Dokumenten und Berichtsstandards erreichen, die jeder verwenden kann. Vielleicht würde eine einfache SharePoint-Website ausreichen.

Für einige Organisationen kann die Projektmanagement-Herausforderung ineffektive persönliche Zeitpläne sein, da die Kommunikation zwischen den Ressourcen darüber fehlt, worum sie arbeiten und was ihr nächster Fokus ist. In diesem Fall kann EPM durch verbesserung der Team- und Teamkommunikation erreicht werden. Die Tools können so einfach sein wie ein freigegebener Kalender, Instant Messaging oder ein freigegebenes Portal, in dem Benutzer ihre Prioritäten auflisten können.

In einigen Organisationen besteht die Projektmanagement-Herausforderung nur darin, Fortschritte bei den Programmierentwicklungsprojekten zu erzielen. Wenn dies der Fall ist, können die Tools, die bereits in einem Produkt wie Visual Studio Team Services vorhanden sind, ausreichen. In Programmierprojekten kommt es häufig vor, dass viele Aufgaben in fast jeder Reihenfolge abgeschlossen werden können, sodass die Strenge der Planung kritischer Pfade je nach Art der durchgeführten Entwicklung möglicherweise nicht einmal angemessen ist.

Ich kann mich an eine Reihe von Jahren erinnern, als ich mit der Wartungsabteilung einer Fluggesellschaft gearbeitet habe. Die Mitarbeiter durften zu Beginn jedes Monats ihre eigenen Zeitpläne auswählen, und wenn dies nicht koordiniert wurde (wie es oft der Fall war), war es möglich, eine Schicht zu verwalten, nur um herauszufinden, dass niemand arbeitet. Ihre Projektmanagementherausforderung lautete nicht "Wann wird die Arbeit abgeschlossen?", sie lautete": "Kommt jemand zur Arbeit?" In diesem Fall wurde EPM durch die Implementierung eines Schichtplanungstools erreicht.

Selbst wenn wir die EPM-Herausforderung auf Projektpläne konzentrieren, ist es nicht sofort offensichtlich, dass die Bereitstellung eines zentralisierten Projektmanagementsystems die einzige oder beste Antwort ist. Es lohnt sich zu fragen, welche Interaktion die Projektmanagementmitarbeiter untereinander haben müssen. Wenn sie regelmäßig zusammenarbeiten müssen, um Ressourcenkonflikte zu lösen, um zu sehen, welche anderen Prioritäten in der Organisation anstehen, oder um zu sehen, wie sich der Fortschritt eines Projekts auf ein anderes auswirken wird, dann ist ein Blick auf ein Tool wie Project Server absolut sinnvoll, aber oft interagiere ich mit Organisationen, die diese Frage nicht einmal von sich selbst gestellt haben.

In einigen Organisationen finden wir eine kleine Anzahl von Schedulern und eine große Anzahl von Ressourcen. Selbst in einer gut dimensionierten Organisation kann dies die Struktur sein, abhängig von der Branche und der Art der durchgeführten Projekte. Vor nicht allzu langer Zeit traf ich eine Organisation, die sicher war, dass sie die richtige Lösung für ihre EPM-Herausforderung ausgewählt hatte. Sie baten mich, die Lösung zu artikulieren, aber wie üblich bat ich sie, zuerst ihr Projektmanagementproblem zu artikulieren.

Als sie fertig waren, ihre Umgebung auf einem Whiteboard zu beschreiben, war es sogar für sie offensichtlich, dass die von ihnen gewählte Lösung ihr Problem nicht lösen würde.

In diesem Fall war das Problem ein mangelnder Projektfortschritt, der von einem großen Pool von Unterauftragnehmern gemeldet wurde. Der Kunde hat festgestellt, dass er wirklich eine Zeit- und Abrechnungsart von Arbeitszeittabellen für seine Subunternehmer auferlegen würde. Der Programmdirektor wurde entmutigt. "Wir werden nie in der Lage sein, das in die Subunternehmerverträge zu bekommen", sagten sie. Glücklicherweise war ein Mitglied der Finanzabteilung anwesend. "Sie wissen", antwortete diese Person, "eine Klausel, die verlangt, dass sie die Arbeitszeittabelle unserer Wahl ausfüllen muss, ist bereits im Subunternehmervertrag enthalten." Problem gelöst.

Die Idee, das Problem zu durchlaufen, bevor ich zur Lösung komme, ist eine, über die ich hier oft spreche, aber es ist eine schwierige Einführung. Logisches Denken würde vorschreiben, dass die Reihenfolge der Bestimmung einer automatisierten Lösung wie folgt wäre:

1. Identifizieren des Problems

2. Definieren der Lösung

3. Bestimmen, ob die Lösung automatisiert werden soll (und wenn ja, wie)

Automatisierte Lösungsdemonstrationen auf Websites, Videos und anderswo lassen uns das vergessen. Wir suchen natürlich keine Lösung, es sei denn, wir haben ein Problem, aber die automatisierten Lösungen sehen so überzeugend aus und klingen so, dass wir dies letztendlich tun:

1. Auswählen der automatisierten Lösung

2. Erstellen des Problems beim Bereitstellen der Lösung

3. Beheben Sie dieses Problem, indem Sie definieren, wie das automatisierte Tool auf die Lösung angewendet werden kann.

4. Versuchen Sie, sich daran zu erinnern, was das ursprüngliche Problem war

Das neue Problem stellt die Lösung für eine ganze Zeit bereit und dann Wochen, Monate oder sogar ein paar Jahre auf dem Weg, wenn jemand aus dem oberen Management fragt, wann das ursprüngliche Problem gelöst wird, und alle sehen sich ziemlich überrascht an. Es war leicht zu vergessen.

Im Laufe der Jahre habe ich alle möglichen automatisierten Lösungen empfohlen. Natürlich war Project Server eine der Optionen, aber ich habe auch eine Kombination aus Microsoft Project Pro und SharePoint Server empfohlen. Ich habe empfohlen, eine Kombination aus Excel und Outlook zu verwenden. Ich habe empfohlen, Arbeitszeittabellen von Drittanbietern mit Project zu verwenden.

Ich habe sogar einmal empfohlen, ein großes Whiteboard zu verwenden. Ehrlich. Die Organisation war eine, mit der ich jahrelang Geschäfte gemacht hatte. Die betreffende Person war in einer Immobilienrolle und musste langfristige Mietverträge in Immobilien erneuern. Als ich fragte, was das Problem sei, war es eindeutig ein Zeitplanungsproblem. Die Person hatte einige wichtige Termine versäumt und war sicher, dass ein Enterprise-Projektmanagementtool das Problem beheben würde. Die Organisation hatte bereits darum gebeten, Berichte an mehrere Führungskräfte zu verteilen, damit zukünftige Fristen nicht versäumt werden. "Wie viele Benutzer würde es geben?" Fragte ich. "Nur ich", antwortete er. "Wie viele dieser Projekte gibt es gleichzeitig?" Ich fragte "Sieben oder acht", antwortete er. "Und wie viele dieser Deadline-Meilensteine verwalten Sie für jedes Projekt "Es ist sehr kompliziert. Es gibt etwa ein halbes Dutzend Fristen für jeden", sagte er mir.

Es war mir schon klar, dass wir kein großes zentrales EPM-System für diesen armen Kerl installieren sollten.

"Warum stellen Sie nicht einfach ein großes Whiteboard in Ihre Kabine und verwenden Sie ein paar farbige Marker für die verschiedenen Meilensteine?" Fragte ich. "Sie könnten blau für die erste, grün für die zweite, rot für die letzte usw."

Er nahm reichlich Notizen, fasziniert von dem Konzept. Ich verließ die Firma mit dem Wissen, dass ich an diesem Tag keine Dienstleistungen oder Produkte verkauft hatte, aber dass ich die Person enttäuscht verlassen hatte, dass er das System, das er beabsichtigt hatte, nicht bereitstellen konnte. Auf dem Weg nach Hause klingelte mein Handy im Auto. Er war es. "Könnten Sie die verschiedenen Farben für das Whiteboard erklären?", fragte er.

Herauszufinden, welche Probleme Sie lösen möchten, bevor Sie die Lösung entwerfen und bevor Sie sich entscheiden, wie sie automatisiert werden soll, spart nicht nur Geld. Es kann eine enorme Menge an Zeit sparen, die mit der Arbeit an Elementen der Organisation verbracht wurde, die kein Problem hatten, das überhaupt gelöst werden musste.

Wenn die Probleme, die Sie zu lösen versuchen, am besten mit zentralisierter Enterprise-Projektmanagementsoftware gelöst werden können, wird nichts anderes wirklich tun, aber der Fokus, den Sie durch die Artikulation des Problems gewonnen haben, wird auch dort helfen. Ihr Bereitstellungsteam kann Erfolgsmetriken erstellen, mit denen das Projekt als erfolgreich deklariert werden kann, wenn die Probleme behoben wurden. Zentralisieren oder dezentralisieren? Enterprise-Projektmanagement kann mit beidem erreicht werden.

Informationen zum Autor

Chris Vandersluis ist Präsident und Gründer von HMS Software aus Montreal, Kanada, einem zertifizierten Partner von Microsoft. Er verfügt über einen Abschluss der Wirtschaftswissenschaften der McGill University und über 30 Jahre Erfahrung in der Automatisierung von Projektleitsystemen. Er ist langjähriges Mitglied des Project Management Institute (PMI) und hat die Kapitel Montreal, Toronto und Quebec der Microsoft Project Users Group (MPUG) gegründet. Zu den Publikationen, für die Chris geschrieben hat, gehören Fortune, Heavy Construction News, Computing Canada Magazine und PMI's PMNetwork, und er ist ein regelmäßiger Kolumnist für Project Times. Er unterrichtet Advanced Project Management an der McGill University und spricht häufig in Projektmanagement-Verbandsfunktionen in Nordamerika und auf der ganzen Welt. HMS Software ist Herausgeber des projektorientierten Timekeeping-Systems TimeControl und seit 1995 Microsoft Project Solution Partner.

Chris Vandersluis ist per E-Mail erreichbar unter: chris.vandersluis@hms.ca

Weitere EPM-bezogene Artikel von Chris Vandersluis finden Sie auf der HMS EPM Guidance Site (https://www.epmguidance.com/?page_id=39).