GPS-Unterstützung beim Planen einer EPM-Bereitstellung: Whitepaper

Dieses Whitepaper ist Teil unserer Sammlung "Aus der Praxis". Es beschreibt das Erstellen eines Leitplans für die Bereitstellung von Enterprise Project Management, wenn Sie sich für die Implementierung von EPM entschieden haben. Es beschreibt in eindeutiger Weise die beim Planen des Bereitstellungspfads zu berücksichtigenden Faktoren.

Die Word-Version dieses Whitepapers finden Sie unter GPS- Unterstützung beim Planen einer EPM-Bereitstellung.

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

GPS- Unterstützung beim Planen einer EPM-Bereitstellung

In meiner letzten Kolumne habe ich über die Verwendung eines phasenweisen Ansatzes beim Planen der Bereitstellung der Microsoft EPM-Lösung (Enterprise Project Management) gesprochen. Heute werden wir uns damit befassen, im Rahmen Ihres Projektplans einen Leitplan für die EPM-Bereitstellung zu erstellen.

Wenn Sie sich einmal Microsoft Live Maps angesehen haben, wissen Sie, dass man für eine Richtung zwei Informationen benötigt: Ein Ziel und einen Ausgangspunkt. Wenn wir diese Analogie auf eine EPM-Bereitstellung anwenden, müssen wir in ähnlichen Begriffen denken:

  1. Der Ausgangspunkt muss in Form von Technologie, Prozess und Mitarbeitern definiert werden

  2. Das Ziel muss in Form von Geschäftsbedingungen definiert und priorisiert werden

Es kann auch sinnvoll sein, ein paar "Stationen am Wege" oder "Haltepunkte" zu definieren, an denen Sie sich neu aufstellen, Fotos schießen, einen Moment lang die Landschaft genießen und Ihre Reserven für das nächste Wegstück auffüllen können.

Beim Erstellen eines Leitplans wie auch beim Beschreiben von Wegen ist es recht gebräuchlich, mit zwei verschiedenen Maßstäben zu arbeiten. Wir halten den nächsten Wegabschnitt im Detail bereit, bis zur Darstellung der einzelnen Kurven. Wir können uns aber außerdem eine Karte des gesamten Wegs in weniger detaillierter Darstellung zulegen, um unseren aktuellen Wegabschnitt im Kontext der ganzen Reise sehen zu können. In Begriffen des Projektmanagements nennt man das "rollierende Planung".

"Wegbeschreibung"

Beim Erstellen eines Leitplans für eine EPM-Bereitstellung beginnen wir immer mit der Vision oder Intention des Ziels des Unternehmens im Hinblick auf seine EPM-Aktivitäten. Dadurch können wir das Ziel bestimmen, das wir benötigen, um die Richtung anzugeben, genau so, wie das auch in Microsoft Live Maps passieren würde.

Karte mit angezeigter Route von Seattle nach Montreal

Wenn wir nur fragen würden "Was wünschen Sie sich?" käme die Antwort fast immer in den Begriffen einer Lösung. Die Mitarbeiter sagen dann "Ich brauche einen Bericht, der etwa so aussieht" oder "Unsere Firma benötigt Portfolioanalyse".

Für diejenigen hier, die in der Lösungsbranche arbeiten – wir wissen, dass diese Art von Entwurfsnotizen Risiken birgt. Wir schulen unsere Berater, auf Kunden zu achten, die ihr Problem in Form einer Lösung beschreiben. "Das ist die Lösung eines Problems", sagen wir dann, "nicht das Problem". Lassen wir uns das Problem definieren".

Also neigen wir dazu, nicht zu fragen: "Was wünschen Sie sich?" Stattdessen können etwa folgende Fragen für die Zielfindung nützlich sein:

“Welche Geschäftsentscheidungen können Sie jetzt nicht oder nur unter großen Schwierigkeiten treffen, die als Ergebnis der EPM-Bereitstellung leichter zu treffen sind?"

Oder:

"Welcher Aspekt der Organisation könnte Ihrer Meinung nach durch diese EPM-Bereitstellung effizienter werden – entweder durch gesteigerten Durchsatz oder verringerten Aufwand?"

Und wem sollten wir diese Fragen stellen? Also, naturgemäß doch den Personen, die diese Entscheidungen treffen! Wenn Sie schon Mal einen Minivan voller Kinder gefahren und sich dann umgedreht haben, um zu fragen, wohin die Reise gehen soll, wissen Sie, dass sie 50 verschiedene Antworten erhalten.

Aufgrund der gleichen Überlegung müssen wir sicherstellen, dass die Entscheidungsträger des Unternehmens eine Schlüsselrolle in diesem Prozess tragen, andernfalls laufen wir Gefahr, eine Richtung einzuschlagen, in die der "Fahrer" partout nicht will. Die Einbeziehung der Geschäftsleitung in die Erstellung des EPM-Leitfadens zu diesem Zeitpunkt hat einen weiteren Vorteil. Abgesehen davon, dass sie einen kritischen Teilnehmer beim Festlegen der Richtung der EPM-Bereitstellung darstellt, kann sie auf diese Weise auch eine Vorstellung von der Dimension des Projekts erlangen. Eine der häufigsten und schwierigsten Herausforderungen für eine erfolgreiche EPM-Bereitstellung ist die Langzeitunterstützung durch die Geschäftsleitung. Einige Mitglieder der Führungsebene haben möglicherweise nicht bedacht, wie stark sich dieser Vorgang auf etablierte Verfahren und Vorgehensweise auswirken kann und wie störend – wenn auch nur vorübergehend – das sein kann. Sie können möglicherweise auch nicht einschätzen, wie viel Mühe ein stark in die Unternehmenskultur eingreifendes Projekt wie EPM machen kann.

Während unserer Arbeit mit der Geschäftsleitung sowie dem Projektmanagement und möglicherweise auch Mitarbeitern aus der Fertigung versuchen wir, Geschäftsentscheidungen oder Unternehmenseffizienz mit Prozessen und Technologie zu verbinden. Gibt es einen Prozess der erst noch erstellt werden muss, um diese Anforderung zu erfüllen? Was wäre zu seiner Realisierung erforderlich? Gibt es eine Systemfunktion, die entweder vorhanden ist oder erstellt werden muss, um diese Geschäftsentscheidung zu befördern? Was müsste sie leisten?

Grundlegende Systemanalyse ist der Schlüsselfaktor in dieser Phase. Wir beginnen bei der Geschäftsentscheidung als "Ausgabe" und arbeiten uns den Weg zurück zu den Datenelementen, die zum Treffen solcher Entscheidungen erforderlich sind. In manchen Fällen stellt sich heraus, dass die Basisdaten einfach nicht vorhanden sind, und das hat zur Folge, dass dieses Element des Leitplans als mit hohem Risiko behaftet gekennzeichnet werden muss. Schließlich müssen wir jetzt das Sammeln von Daten in einem neuen Format oder einer neuen Struktur mit in die Planung einbeziehen, um diese neuen Datenelemente zu erfassen, bevor wir auch nur daran denken können, den besseren Geschäftsprozess zu etablieren, und das kann in manchen Fällen eine erhebliche Dimension annehmen.

Wir haben noch etwas zu erledigen, bevor wir den Zielfindungsprozess abschließen, nämlich die verschiedenen Elemente der endgültigen Vision zu priorisieren. Es kommt häufig vor, dass man zu Anfang der Leitplanerstellung denkt, dass die Prioritäten in eine bestimmte Richtung gehen werden, aber wenn man sie dann wirklich festhält, stellt sich heraus, dass sie sich anders verteilen als gedacht. Interessanterweise gibt es zu dem Zeitpunkt, da alle den in das Ziel aufzunehmenden Einzelpunkte zugestimmt haben, einen bemerkenswerten Konsens hinsichtlich der obersten Prioritäten.

Das nächste, was wir für die Richtungsbestimmung brauchen, ist ein Ausgangspunkt, und den bestimmen wir durch eine Bestandsaufnahme dessen, wo sich die Organisation im Verhältnis zu dem gewählten Ziel befindet.

Karte mit angezeigter Route von Seattle nach Montreal

Wir sehen uns die vorhandenen Mitarbeiter an. Sind sie in Projektmanagement für ihre jeweiligen Rollen geschult? Haben wir genügend Mitarbeiter mit ausreichend Erfahrung, um die festgelegten Ziele zu erreichen? Bedenken Sie, dass wir hier mehrere Maßstäbe betrachten müssen, da verschiedene Personen im sich gegebenenfalls ergebenden Enterprise-Projektmanagementprozess eine andere Rolle spielen werden. Es ist völlig sinnlos, jeden Mitarbeiter in Projektplanung zu schulen, wenn er nie für die Erstellung von Projektplänen zuständig sein wird. Standardmäßig haben wir vier Rollen im Blick: Administrator, Projektmanager, Einzelressource und leitender Angestellter. Wenn Arbeitszeittabellen eine Rolle spielen, kommen noch Supervisor als fünfte Rolle hinzu. Natürliche kann die Ausgestaltung der Rollen eine ziemliche Bandbreite aufweisen, je nachdem, was wir in unserem ursprünglichen Zielfindungsprozess definiert haben. Das bedeutet eine tiefgreifende Änderung für die Bestandsaufnahme der Qualifikationen, und das ist der Grund, warum wir von der Definition des Ziels ausgehen, bevor wir uns Gedanken über den Ausgangspunkt machen.

Wir betrachten außerdem die bereits vorhandenen Prozesse. Gibt es einen festgelegten oder dokumentierten Projektmanagementprozess? Wie wird er gewartet? Wer ist dafür verantwortlich? Wenn bereits ein Projektmanagementbüro vorhanden ist, dann konzentrieren sich viele unserer Bemühungen darauf. Schließlich gibt es keinen Grund, neue Verfahren zu definieren, wenn bereits Verfahren und Prozesse vorhanden und in Kraft sind. Wir können vorhandene Prozesse, sowohl innerhalb des aktuellen Projektmanagementprozesses als auch außerhalb, in den Bestand aufnehmen, je nachdem, ob sie sich in die Endziele der EPM-Umgebung einfügen.

Wir können beispielsweise entschieden haben, dass Kontraktmanagement einen wichtigen Bestandteil unserer neuen EPM-Umgebung bilden wird, und dass dieses noch nie Teil des Projektmanagementprozesses innerhalb der Organisation gewesen ist. Wenn wir uns jedoch in einem etwas größeren Bereich umsehen, stellen wir vielleicht fest, dass die Organisation eine starke Sammlung von Mechanismen für die Dokumentenverwaltung und bereits einen definierten Workflow für die Verarbeitung von Dokumenten besitzt, etwa in SharePoint. Das wäre ein idealer Prozess für die Übernahme, der ggf. angepasst werden kann, um sicherzustellen, dass er diesen Aspekt der neuen Umgebung für Enterprise Project Management antreibt. Dieses Vorgehen wäre in dreierlei Hinsicht nützlich. Erstens brauchen wir nicht die Anstrengung aufzuwenden, einen neuen Prozess zu erstellen. Zweitens wissen wir, dass die beteiligten Mitarbeiter bereits über die Qualifikation und Gewohnheiten verfügen, um den Prozess in dieser Weise zu verwenden, sodass kein Schulungsaufwand und keine psychologische Einstimmung der Mitarbeiter anfallen. Schließlich haben wir nicht die schwierige Situation, einen separaten Prozess erstellen zu versuchen, der möglicherweise im Widerspruch zu einem bereits vorhandenen Prozess für die Verwaltung von Dokumenten, wie Verträgen, steht.

Wir wissen, dass eine unserer größten Herausforderungen die Compliance sein wird. Nicht, das System zu erstellen, sondern jeden dazu zu bewegen, es zu verwenden und zwar durchgängig. Je mehr bereits vorhandene Gewohnheiten, Praktiken und Verfahren, die einen festen Platz im Unternehmen haben, wird dazu übernehmen können, desto leichter lässt sich Compliance erreichen.

Abschließend benötigen wir eine Bestandsaufnahme der Technologieplattform. Da die Microsoft-EPM-Lösung auf einer Technologieplattform aufbaut, ist es wahrscheinlich, einen Teil dieser Technologie bereits vorzufinden, es ist aber auch möglich, dass die Organisationen für einen Teil ihrer Plattform ein Upgrade ausführen muss, damit die Lösung, die Sie entwerfen, funktioniert. SharePoint und SQL Server sind offensichtliche Elemente einer Bereitstellung von Microsoft Office Project Server, aber es kann auch nötig sein, die Browserkompatibilität (verwendet jeder die aktuelle Version von Internet Explorer?), den Sicherheitsstatus (hat das System Verbindungen nach außen?), die bereitgestellte Version von SQL Server (werden die OLAP-Dienste oder die SQL Server Reporting Services bereits verwendet?) zu überprüfen. Sie müssen darüber hinaus möglicherweise auch andere Systeme, zu denen Schnittstellen bestehen oder die integriert werden müssen, in Erwägung ziehen. Wie erhalten Sie Zugriff auf diese Systeme in der Produktion?

Die Größe des geplanten Systems kann es auch erforderlich machen, Hardware, Netzwerk und andere Infrastrukturelemente zu betrachten, um sicherzustellen, dass das System bei Inbetriebstellung die erforderliche Struktur vorfindet.

Wie bei jedem Unternehmenssystem ist es sinnvoll, sowohl einen Produktionsbereich als auch einen Stagingbereich zu planen, damit Updates und Verbesserungen im Lauf der Zeit erst im Labor erstellt und erprobt werden können, statt am Produktionssystem. Möglicherweise müssen Sie ferner Pläne für eine Pilotphase oder einen Machbarkeitsnachweis machen; über dieses Thema werde ich in meiner nächsten Kolumne mehr sagen.

"Die Route wird neu berechnet"

Wenn das GPS-System in meinem Auto feststellt, dass ich eine Abzweigung verpasst habe, sagt die sehr nette Stimme einer Frau "Die Route wird neu berechnet". Ein paar Augenblicke später ändert sich die Linie auf meiner Karte, und ich habe eine neue Wegbeschreibung. In einer EPM-Umgebung müssen wir ebenfalls auf eine Umleitung oder eine wegen Reparaturarbeiten gesperrte Abzweigung vorbereitet sein. Vielleicht haben wir die Autobahnausfahrt verpasst. Wie gehen wir mit Neuplanungen um? Wenn wir vom Weg abkommen, müssen wir uns zwei Fragen stellen: Erstens, wollen wir immer noch an das gleiche Ziel gelangen? Zweitens, wie kommen wir von hier aus da hin? Eins meiner liebsten Zitate zum Projektmanagement zu diesem Thema stammt von Helmuth von Moltke, der einmal sagte "Kein Plan überlebt die erste Feindberührung".

Karte mit angezeigter Route von Seattle nach Redmond

Wie wenden wir diese Erkenntnis nun in einer EPM-Bereitstellung an? Zunächst mal benötigen wir ein Kriterium, um zu bestimmen, ob wir nicht mehr auf Kurs sind. Wenn ein Teammitglied morgen einen zahnärztlichen Notfalltermin hat und vier Stunden nicht im Büro sein wird, sollten wir dann aufgrund dieses Engpasses alle nachfolgenden Schritte von morgen Mittag bis zum Projektende umplanen und dann allen Mitarbeitern per E-Mail die neuen Einsatzzeiten mitteilen?

Natürlich nicht.

Eine Abweichung von vier Stunden für eine Ressource über die gesamte Projektlebensdauer einer Projekts von sechs Monaten, an dem Dutzende Mitarbeiter beteiligt sind, ist keine ausreichende Störung, um eine Änderung des Wegs zu rechtfertigen. Was wir zu Beginn jeder Art von Unternehmensprojekt tun müssen, ist, Schwellenwerte für den akzeptablen Fortschritt festzulegen. Die Luftfahrt- und Verteidigungsbranche verwendet dafür in letzter Zeit einen neuen Ausdruck, "Stolperdrähte", der sehr bildhaft ist. Wir können festlegen, welche Kriterien uns anzeigen, dass eine Neuberechnung der Route erforderlich ist. Es gibt eine Reihe typischer Metriken oder Kennzahlen, die wir dazu berücksichtigen können. Erstens, wenn die prognostizierten Fertigstellungskosten um mehr als X Prozent vom ursprünglichen Budget abweichen, kann das einen Fall für eine Überprüfung des Projektplans darstellen. Sie können die Kosten in Arbeitsstunden oder in Geld messen. Beides funktioniert. Beispielsweise, wenn das vorhergesagte Abschlussdatum eines Projekts um mehr als X Tage vom ursprünglich geplanten Fertigstellungstermin abweicht, kann das Anlass zu einer Überprüfung des Projektplans sein.

Sie können auch entscheiden, dass das Versäumen bestimmter Meilensteine um eine festgelegte Anzahl Tage einen Stolperdraht darstellt, bestimmte Risiken als Stolperdraht implementieren oder auch festlegen, dass der Wechsel bestimmter Mitglieder des Projektteams, wie etwa des Hauptsponsors, als Stolperdraht anzusehen ist. Es ist wichtiger, bestimmte Kriterien festzulegen, als die Kriterien haargenau abzustimmen. Bedenken Sie auch, dass Sie das Projekt für seine ganze Lebensdauer an diesen Kriterien messen müssen, wenn Sie also 50 oder 100 verschiedene Metriken festlegen, verbringen Sie unter Umständen mehr Zeit mit dem Vermessen des Projekts als mit der Arbeit daran!

Sobald Sie festgestellt haben, dass Sie vom Kurs abgekommen sind, besteht die beste Möglichkeit, wieder in die Spur zu kommen, in der Durchführung einer Projektplanüberprüfung. Wir empfehlen, die Vertretung sowohl der ursprünglichen Geschäftsleitung, die an der anfänglichen Definition des Ziels beteiligt war, als auch der Gruppe im Projektmanagementteam, die an der ursprünglichen Bestandsaufnahme beteiligt war, einzubeziehen. Projektplanüberprüfungen stehen in der Gefahr, zur Schuldzuweisung zu verkommen, warum das Projekt nicht mehr in der Spur ist und warum eine bestimmter Stolperdraht ausgelöst wurde. Solche Bestrebungen können extrem kontraproduktiv sein. Wir empfehlen, den Schwerpunkt auf die folgenden Fragen zu legen:

  1. Was ist geschehen?

  2. Wo sind wir gelandet? Was ist unser aktueller Ausgangspunkt?

  3. Sind wir noch unserem ursprünglichen Ziel verpflichtet, oder gibt es einen überzeugenden Grund, diesen Prozess zu überprüfen oder sogar neu in die Zielfindung einzusteigen?

  4. Müssen wir die Zwischenmeilensteine oder Phasen zurücksetzen?

  5. Müssen Änderungen am Projektteam vorgenommen werden?

  6. Müssen wir Teile unserer Stolperdrahtmetrik zurücksetzen?

Fragen, die sich für uns als wenig ergiebig herausgestellt haben, sind unter anderen:

  • Wessen Fehler ist es, dass wir an diesem Punkt stehen? Wer ist verantwortlich? Wer ist Schuld?

  • Wie kommen wir wieder in die Spur zurück, zurück zum alten Plan?

Der häufigste Grund für eine Projektplanüberprüfung ist, dass sich die Prioritäten der Organisation verschieben. Beispielsweise werden Elemente, die in Phase 3 entwickelt werden sollten, plötzlich in Phase 2 benötigt. Dies ist normalerweise ein Anzeichen einer gesunden Dynamik in der Organisation und das Ergebnis ernsthafter Diskussionen unter den Mitarbeitern über die Implikationen der Bereitstellung des EPM-Systems.

Schlechtes Wetter

Bevor Sie sich auf eine lange Fahrt machen, besorgen Sie sich vermutlich einen Wetterbericht (z. B. auf weather.msn.com), um sicherzugehen, dass kein raues Wetter Ihre Reise trübt. Risiken sind ein Teil des Lebens. Bedenken Sie, wenn es keine Risiken gäbe, brauchte man auch keine Projektmanager! Das Berücksichtigen der offensichtlichsten Risiken in der Planung ist kein komplizierter Prozess. Beginnen Sie am Anfang des Zielfindungsprozesses und fragen Sie beim Betrachten der Elemente des Ziels, das Sie entwerfen, die Gruppe, welche Barrieren vor dem Erreichen dieses Ziels sie sich vorstellen können. In manchen Fällen werden die Risiken erheblich sein. Es ist nicht ungewöhnlich, dass eine Organisation sich ein bestimmtes Ergebnis wünscht, nur um dann festzustellen, dass die Rohdaten, die zum Erzielen dieses Ergebnisses benötigt werden, nie erfasst wurden und es erhebliche Widerstände gegen die Erfassung dieser Daten gibt.

MSN-Seite mit Wettervorhersage für Montreal

In einem Beispiel haben wir eine Organisation gefunden, die Ressourcenkapazitätsplanung wünschte. Das würde eine vollständige Erfassung der gesamten Ressourcenverfügbarkeit für das gesamte Projektpersonal sowie eine vollständige Erfassung sämtlicher möglicher Arbeitslasten, die diesen Mitarbeitern zugeordnet werden könnten, erfordern. Als wir nachfragten, ob diese Daten verfügbar wären, bekamen wir zur Antwort, ja sicher, die wären verfügbar, aber nur für zwei Fünftel der Organisation. Als wir entdeckten, dass die drei Fünftel der Organisation, für die keine Daten verfügbar waren, nicht einmal bei der Zielfindungsbesprechung anwesend waren, sagten wir "Lassen Sie uns raten. Die Probleme, die Sie mit der Ressourcenkapazitätsplanung haben, treten in diesen drei Abteilungen auf". Naturgemäß war das so, und wir mussten die Einbeziehung der Abteilungsleiter der betreffenden Abteilungen als separate Projektphase mit sehr hohem Risiko identifizieren.

Während der Arbeit an der Bestandsaufnahme mit dem Projektmanagement und den Mitarbeitern aus der Produktion fragen Sie während der Gespräche, ob diese Mitarbeiter Risiken benennen können.

Sobald die Risiken identifiziert wurden, müssen sie strukturiert werden. Wenn Sie diese Tätigkeit zuvor noch nicht ausgeführt haben: die einfachsten Informationen sind die wertvollsten. Schließen Sie ein:

  1. Eine kurze Beschreibung des Risikos

  2. Den Bereich oder die Phase des Projekts, auf den bzw. die es sich auswirken kann

  3. Die Schwere des Risikos, wenn das Kriterium erfüllt wird

Schließlich ist eine der wichtigsten Sachen, die Sie tun können, einige Details zur Verringerung der Risiken hinzuzufügen. Ein Risiko einfach nur identifiziert zu haben, ist schon ein riesiger Schritt zu seiner Verminderung, aber während die EPM-Bereitstellung noch in den Kinderschuhen steckt, kann das Eingeben von Notizen, wie ein bestimmtes Risiko während des Projekts vielleicht behandelt werden kann, einen unschätzbaren Vorteil darstellen. Es kommt häufig vor, dass Entscheidungen hastig und in emotionaler Erregung getroffen werden, wenn Risiken eintreten. In der Situation ein paar Notizen zur Hand zu haben, die bedacht wurden, als kühlere Köpfe in der Mehrzahl waren, kann nützlich sein.

Fahren wir das Auto, das wir bauen

Hier ein Tipp zum Erstellen Ihres Leitplans, der möglicherweise eine hohe Dividende abwirft: Verwenden Sie Project Server und die Microsoft EPM-Lösung, um Ihren Leitplan zu erstellen und zu verwalten. Das mag offensichtlich erscheinen, aber Organisationen machen es immerhin so selten, dass wir es hier eigens erwähnen.

SharePoint-Website mit einer Liste von Projektlieferumfängen

Ein Mitglied der Geschäftsführung erzählte mir einmal, dass sein Projektteam ihn fragte, ob er nicht meinte, die Verwendung der Microsoft EPM-Lösung zum Bereitstellen der Microsoft EPM-Lösung wäre zu viel des guten. "Wenn wir unser Geld mit dem Bau von Düsenjets verdienten, würden wir ja nicht damit zur Arbeit fliegen", sagten sie. "Macht Ihr Witze?" antwortete er. "Wenn ich einen Düsenjet zur Arbeit fliegen könnte, täte ich das jeden Tag!"

Die Microsoft EPM-Lösung für die EPM-Bereitstellung zu verwenden, ist eine großartige Idee.

Project Server und die anderen Elemente der Microsoft EPM-Lösung zu installieren, ist keine große technische Herausforderung, und mit dem erforderlichen Minimum an Konfiguration können Sie mit einem kleinen Bereitstellungsteam als Benutzer in zwei Tagen betriebsbereit sein. Das ist eine großartige Möglichkeit für die Benutzer, aus denen die tragenden Säulen Ihres Bereitstellungsteams werden sollen, sich mit der Verwendung und den Vorzügen des Systems vertraut zu machen, bevor es die Schreibtische des Hauptteils der Mitarbeiter erreicht.

Diese Bereitstellung sollte nicht zu Ihrer Produktionsumgebung werden. Sie werden das mit an Sicherheit grenzender Wahrscheinlichkeit konfigurieren und es so anpassen, dass es die Vision der ursprünglichen Zielsetzung erfüllt. Sie werden mit fast an Sicherheit grenzender Wahrscheinlichkeit in Ihrer EPM-Bereitstellungsiteration von Projekt Server nicht an Dingen wie der Planung für mehrere Projekte oder Ressourcenkapazitätsplanung oder Portfoliooptimierung arbeiten, aber Sie werden imstande sein, ein System abzuliefern, das große Vorteile bietet. Wir empfehlen Ihnen dazu:

  1. Sehen Sie einen rollierenden Projektplan als veröffentlichtes Projekt vor.

    Ein rollierender Projektplan hebt die aktuelle Phase detailliert hervor und lässt zukünftige Phasen als Zusammenfassung sichtbar werden. Dadurch wissen die Teammitglieder, woran sie jetzt arbeiten müssen, und trotzdem können sie das Projekt im größeren Kontext sehen.

  2. Verwalten Sie das Zielfindungsdokument im Projektarbeitsbereich.

    Der Projektarbeitsbereich ist eine SharePoint-Website, die an das Projekt gebunden ist und standardmäßig einen Bereich für Probleme, Risiken und Dokumente enthält. Warum fügen Sie nicht alle Ihre Projektdokumente für das EPM-Bereitstellungsprojekt hier ein und aktivieren die Versionskontrolle von SharePoint, sodass Sie jederzeit wieder zur ursprünglichen Version zurück gelangen können?

  3. Setzen Sie die abgezeichneten Meilensteine und passierten "Tore" im Projektarbeitsbereich in die Lieferumfänge ein.

    Das ist eine einfache Vorgangsliste, die Sie in Project Server mit Aufgaben verknüpfen können. Das ergibt einen Blick auf das Projekt von einer sehr hohen Warte aus und stellt ein einfaches Mittel dar, Schwellenwerte zu verwalten, um zu bestimmen, wann Sie vom Kurs abkommen.

  4. Speichern Sie die Änderungsverwaltung im Projektarbeitsbereich unter "Probleme".

    Änderungsverwaltung ist eine der großen Herausforderungen bei Technologieprojekten. Wenn neue Vorschläge für Änderungen am Projekt aufkommen, setzen Sie sie in den Bereich "Probleme" als potenziell zu verwaltende Änderung ein. Indem Sie diesem Bereich einige Felder hinzufügen, können Sie eine Liste von Elementen mit hoher Priorität und die für sie zu den verschiedenen Zeiten jeweils Zuständigen erstellen.

  5. Fügen Sie die Projektrisiken in den Projektarbeitsbereich ein.

    Jenseits von Dokumenten und Problemen ist der Risikobereich des Arbeitsbereichs der ideale Ort, um Ihre Risiken und die Pläne zur Abmilderung hinzuzufügen. Tatsächlich weist der Standardbildschirm alle Felder zu Ihrem direkten Gebrauch auf.

Haben wir's schon geschafft?

"Naja, fast. Wir sind bald da".

Eine EPM-Bereitstellung kann eine Organisation an so viele Orte bringen, dass sich die Möglichkeit, einfach den Standardprojektplan für alle öffentlich verfügbar zu machen, von selbst verbietet. Ein paar Minuten Suche im Internet geben Ihnen aber wahrscheinlich viele mögliche Beispiele für verschiedene Teile des Projekts an die Hand. Wenn ich die Leitplanübung oben zusammenfasse, enden Sie wahrscheinlich bei einem Projekt, das vier deutlich unterscheidbare Phasen aufweist:

  1. Leitplanübung

    1. Zielfindung (Auswahl des Ziels)

    2. Bestandsaufnahme der vorhandenen Prozesse (Identifizieren des Ausgangspunkts)

    3. Bestandsaufnahme des vorhandenen Personals (Identifizieren des Ausgangspunkts)

    4. Bestandsaufnahme der Technologie (Identifizieren des Ausgangspunkts)

  2. Bereitstellen der EPM-Lösung für das EPM-Team

  3. Phase 1

    1. Entwurf

    2. Konfiguration, Anpassung, Dokumentation

    3. Pilot

    4. Schulung

    5. Rollout

    6. Überprüfung von Phase 1 und Anpassung von Phase 2 nach Bedarf

  4. Phase 2

  5. Phase 3

  6. Phase 4

  7. Abschließende Projektzusammenfassung

Das Anwenden einer Leitplanübung auf Ihre EPM-Bereitstellung kann die Erfahrung sehr schnell von chaotisch zu handhabbar ändern. Vergessen Sie nur nicht, zuerst das Ziel auszuwählen, dann Ihren Ausgangspunkt herauszufinden und den Pfad dazwischen zu zeichnen.

Glückliche Reise!

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!

×