GPS-Unterstützung bei der Erstellung einer Roadmap für eine EPM-Bereitstellung
Dieser Artikel ist Teil unserer Sammlung "From the Trenches". Es wird beschrieben, wie Sie eine Enterprise Project Management-Bereitstellung als "Roadmap" festlegen, wenn Sie EPM implementieren möchten. Es werden darin auf spezielle Art Faktoren beschrieben, die bei der Planung des Bereitstellungspfads berücksichtigt werden müssen.
Weitere Artikel finden Sie in den Whitepapers "Aus den Gräben".
G.P.S. Unterstützung beim Roadmapping einer EPM-Bereitstellung
In meiner letzten Spalte habe ich über die Verwendung eines stufenweisen Ansatzes zum Erstellen Ihrer Pläne für eine Bereitstellung der Enterprise Project Management-Lösung (EPM) von Microsoft gesprochen. Heute befassen wir uns mit der Erstellung einer EPM-Bereitstellungsroadmap als Teil Ihres Projektplans.
Wenn Sie bei Microsoft Live Maps waren, wissen Sie, dass wegbeschreibungen zwei Dinge erfordern: ein Ziel und einen Ursprungspunkt. Wenn wir diese Analogie auf eine EPM-Bereitstellung anwenden, müssen wir ähnlich denken:
In Technologie, Prozess und Personal definierter Ursprungsort
Ziel, das in geschäftlichen Begriffen definiert und priorisiert ist
Wir können auch einige "Wegstationen" oder Zwischenstationen definieren, wo Sie sich neu gruppieren, Fotos machen, die Landschaft für eine Weile genießen und Ihre Vorräte für die nächste Etappe der Reise auffüllen können.
Wenn Sie eine Roadmap oder Richtungen erstellen, ist es üblich, zwei Skalierungen zu haben. Wir halten die nächste Etappe der Reise sehr detailliert, bis hin zu einer Turn-by-Turn-Route. Wir können jedoch auch eine Karte der gesamten Reise auf höherer Ebene in weniger Details führen, um unsere aktuelle Etappe im Kontext der gesamten Reise zu halten. Im Projektmanagement nennen wir diese "Rollwellenplanung".
"Wegbeschreibungen"
Bei der Erstellung einer EPM-Bereitstellungsroadmap beginnen wir immer mit der Vision oder Absicht, wohin das Unternehmen in Bezug auf seine EPM-Bemühungen geht. Dies gibt uns das Ziel, das wir benötigen, um Wegbeschreibungen zu erstellen, genau wie Microsoft Live Maps.
Wenn wir nur fragen würden: "Was willst du?" kommt die Antwort fast ausnahmslos in Form einer Lösung. Personen sagen wahrscheinlich "Ich benötige einen Bericht, der so aussieht" oder "Unser Unternehmen benötigt eine Portfolioanalyse".
Für diejenigen von uns im Lösungsgeschäft wissen wir, dass diese Art von Entwurfsnotizen mit Risiken verbunden ist. Wir schulen unsere Berater, um Kunden zuzuhören, die ihr Problem als Lösung beschreiben. "Das ist eine Lösung für ein Problem", werden wir sagen, "nicht das Problem. Definieren wir das Problem."
Daher neigen wir dazu, nicht zu fragen: "Was wollen Sie?" Stattdessen können fragen, die während einer Einführung nützlich sein können:
"Welche geschäftliche Entscheidung können Sie jetzt nicht treffen oder können sie nur mit großen Schwierigkeiten treffen, deren Entscheidung durch diese EPM-Bereitstellung erleichtert würde?"
oder -
"Welcher Aspekt der Organisation könnte Ihrer Meinung nach effizienter gemacht werden, entweder durch eine Erhöhung des Durchsatzes oder eine Verringerung des Aufwands durch diese EPM-Bereitstellung?"
Wem sollten wir nun diese Fragen stellen? Warum, die Menschen, die diese Entscheidungen treffen, natürlich! Wenn Sie jemals einen Minivan voller Kinder hatten und sie gefragt haben, wohin Sie als Ziel gehen sollten, wissen Sie, dass Sie 50 Antworten erhalten werden.
Ebenso müssen wir sicherstellen, dass die Entscheidungsträger der Organisation ein wichtiger Teil dieses Prozesses sind, oder wir laufen Gefahr, eine Richtung zu wählen, zu der der "Fahrer" nicht bereit ist. Es gibt einen zusätzlichen Vorteil, wenn die Geschäftsleitung derzeit in den EPM-Roadmapping-Prozess eingebunden wird. Abgesehen davon, dass sie ein wichtiger Teilnehmer bei der Wahl der Richtung sind, in die die EPM-Bereitstellung gehen sollte, können sie auch ein Gefühl für das Ausmaß des Projekts bekommen. Eine der häufigsten und schwierigsten Herausforderungen für eine erfolgreiche EPM-Bereitstellung ist die langfristige Verwaltungsunterstützung. Einige Führungskräfte haben nicht berücksichtigt, wie sehr dies bestehende Praktiken und Verfahren verändern könnte und wie störend dies, auch vorübergehend, sein könnte. Sie schätzen möglicherweise auch nicht, wie viel Aufwand ein Kulturänderungsprojekt wie EPM sein kann.
Während unserer Arbeit mit der Geschäftsleitung, dem Projektmanagement und vielleicht dem Line-Personal versuchen wir, Geschäftsentscheidungen oder Geschäftseffizienz mit Prozess und Technologie zu verbinden. Gibt es einen Prozess, der erstellt werden muss, um diese Anforderung zu erfüllen? Was müsste sie erreichen? Gibt es eine Systemfunktion, die entweder vorhanden ist oder erstellt werden muss, um dieser Geschäftsentscheidung zu dienen? Was muss er liefern?
Grundlegende Systemanalyse ist in dieser Phase der Schlüssel. Wir beginnen mit der "Ausgabe" der Geschäftsentscheidung und arbeiten uns zurück zu den Datenelementen, die für diese Entscheidungen erforderlich sind. In einigen Fällen stellen wir fest, dass die grundlegenden Daten einfach nicht vorhanden sind, und dies führt dazu, dass dieses Element der Roadmap als "hohes Risiko" gekennzeichnet wird. Schließlich müssen wir nun das Sammeln von Daten in einem neuen Format oder einer neuen Struktur einschließen, um diese neuen Datenelemente zu erfassen, bevor wir uns vorstellen können, den besseren Geschäftsprozess bereitzustellen, und das kann in einigen Fällen eine hohe Reihenfolge sein.
Bevor wir den Zielprozess beenden, müssen wir noch eine weitere Sache tun, nämlich die verschiedenen Elemente der endgültigen Vision zu priorisieren. Es ist sehr üblich, zu Beginn des Roadmapping-Prozesses zu denken, dass die Prioritäten einen Weg gehen werden, aber stellen Sie fest, dass sie sehr unterschiedlich verlaufen, wenn Sie gehen, um sie tatsächlich zu erfassen. Interessanterweise besteht zu dem Zeitpunkt, an dem alle sich darauf geeinigt haben, welche Ziele in unserem Ziel enthalten sind, ein bemerkenswerter Konsens darüber, was die wichtigsten Prioritäten sein sollten.
Das nächste, was wir für wegbeschreibungen benötigen, ist ein Ursprungspunkt, und wir verwalten dies durch eine Bestandsaufnahme der Position, an der sich die Organisation jetzt in Bezug auf die von uns gewählten Ziele befindet.
Wir betrachten vorhandenes Personal. Sind sie im Projektmanagement für ihre jeweiligen Rollen ausgebildet? Verfügen wir über ausreichend Personal mit ausreichend Erfahrung, um die gesetzten Ziele zu erreichen? Denken Sie daran, dass wir hier mehrere Measures betrachten müssen, da unterschiedliche Personen eine unterschiedliche Rolle im letztendlichen Enterprise-Projektmanagementprozess haben werden. Es macht keinen Sinn, jeden Mitarbeiter zu einem Projektplaner zu schulen, wenn er niemals für die Erstellung von Zeitplänen verantwortlich ist. Standardmäßig denken wir an vier Rollen: Administrator, Projektmanager, Einzelne Ressource und Führungskraft. Wenn Arbeitszeittabellen beteiligt sind, betrachten wir auch die Vorgesetzten als fünfte Rolle. Je nachdem, welches Ziel wir in unserem ursprünglichen Erstellungsprozess definiert haben, können die Rollen natürlich ganz unterschiedlich sein. Dies verändert den Prozess der Qualifikationsinventur grundlegend, weshalb wir immer damit beginnen, das Ziel zu definieren, bevor wir über den Ursprungsort nachdenken.
Wir betrachten auch den bestehenden Prozess. Gibt es einen festgelegten oder dokumentierten Projektmanagementprozess? Wie wird es gewartet? Wer ist dafür verantwortlich? Wenn bereits ein Projektmanagement-Büro eingerichtet ist, ist ein Großteil dieser Bemühungen dort konzentriert. Schließlich macht es keinen Sinn, neue Prozeduren zu erstellen, wenn vorhandene Prozeduren und Prozesse vorhanden sind, die bereits wirksam sind. Wir können vorhandene Prozesse inventarisieren, die sich sowohl innerhalb des aktuellen Projektmanagementprozesses als auch außerhalb befinden, je nachdem, was die letztendlichen Ziele der EPM-Umgebung sein werden.
Beispielsweise könnten wir entschieden haben, dass das Vertragsmanagement ein wichtiger Bestandteil unserer neuen EPM-Umgebung sein wird und dass dies noch nie Teil der Projektmanagementprozesse innerhalb dieser Organisation war. Wenn wir jedoch etwas weiter suchen, stellen wir möglicherweise fest, dass die Organisation über einen starken Satz von Steuerelementen zum Verwalten von Dokumenten und vorhandenen Workflows verfügt, die bereits Dokumente verschieben, z. B. in SharePoint. Dies wäre ein idealer Prozess für uns, um diesen Aspekt der neuen Enterprise-Projektmanagementumgebung zu übernehmen und gegebenenfalls anzupassen. Dies hat einen dreifachen Vorteil. Erstens müssen wir den Aufwand zum Erstellen eines neuen Prozesses nicht aufwenden. Zweitens wissen wir, dass das Personal bereits über die Fähigkeiten und Gewohnheiten verfügt, um den Prozess auf diese Weise zu nutzen, was keinen Schulungsaufwand oder Aufwand bedeutet, um das Personal zur Einhaltung zu bringen. Schließlich haben wir nicht die schwierige Situation, einen separaten Prozess zu erstellen, der möglicherweise im Widerspruch zu einem vorhandenen Prozess für die Verwaltung von Dokumenten steht, z. B. Verträge.
Wir wissen, dass eine unserer größten Herausforderungen die Compliance sein wird. Nicht das System zu erstellen, sondern alle dazu zu bringen, es zu verwenden und es konsistent zu verwenden. Je mehr wir bestehende Gewohnheiten, Praktiken und Verfahren übernehmen können, die in der Organisation eingebettet sind, desto einfacher wird die Compliance.
Schließlich benötigen Sie einen Bestand der Technologieplattform. Da die Microsoft EPM-Lösung auf einer Technologieplattform basiert, ist es wahrscheinlich, dass einige dieser Technologien bereits vorhanden sind, aber es ist auch möglich, dass die Organisation einen Teil ihrer Plattform aktualisieren muss, damit die von Ihnen entworfene Lösung funktioniert. SharePoint und SQL Server sind offensichtliche Elemente der Bereitstellung von Microsoft Office Project Server, aber Sie müssen möglicherweise auch die Browserkompatibilität (verwendet jeder die neueste Version von Internet Explorer?), den Sicherheitsstatus (ist das System nach außen ausgerichtet?), welche Version von SQL Server bereitgestellt wird (ist OLAP-Dienste oder SQL Server Reporting Services wird bereits verwendet?). Möglicherweise müssen Sie auch andere Systeme in Betracht ziehen, mit denen Sie eine Schnittstelle herstellen oder integrieren müssen. Wie erhalten Sie Zugriff auf diese Systeme in der Produktion?
Die Größe des geplanten Systems erfordert möglicherweise auch die Betrachtung von Hardware, Netzwerk und anderen Infrastrukturelementen, um sicherzustellen, dass das System die erforderliche Struktur hat, wenn es eintrifft.
Wie bei jedem Unternehmenssystem sollten Sie sowohl einen Produktions- als auch einen Stagingbereich planen, sodass Updates und Verbesserungen im Laufe der Zeit im Lab und nicht im Livesystem erstellt werden können. Möglicherweise müssen Sie auch Pläne für eine Pilot- oder Proof of Concept-Phase erstellen. etwas, über das ich in meiner nächsten Spalte mehr sprechen werde.
"Route neu berechnen"
Als die G.P.S.-Einheit in meinem Auto feststellt, dass ich eine Abzweigung verpasst habe, sagt eine sehr nette Damenstimme "Neu berechnende Route". Augenblicke später ändert sich die Linie durch meine Karte und ich habe neue Richtungen. In einer EPM-Bereitstellung müssen wir für einen Umweg oder eine Kurve bereit sein, die für Reparaturen blockiert ist. Vielleicht haben wir diese Autobahnausfahrt verpasst. Wie gehen wir mit der Neuplanung um? Es gibt zwei Dinge zu fragen, wenn Sie aus dem Kurs gehen: Erstens, gehen Sie immer noch an den gleichen Ort? Zweitens, wie kommen wir von hier dorthin? Eines meiner Lieblings-Projektmanagement-Zitate zu diesem Thema stammt von Napoleon Bonaparte, der einmal sagte: "Ein Kampfplan dauert bis zum Kontakt mit dem Feind."
Wie wenden wir dieses Prinzip in einer EPM-Bereitstellung an? Zunächst benötigen Sie ein Measure, um festzustellen, ob Sie nicht mehr auf Kurs sind. Wenn ein Teammitglied morgen einen Notfallzahnarzttermin hat und vier Stunden im Büro abwesend ist, sollten wir dann zulassen, dass diese Diskrepanz alle nachgeschalteten Aufgaben ändert, alle von morgen mittags bis zum Ende des Projekts neu planen und dann allen mit ihren neuen Aufgabenzeiten eine E-Mail senden?
Natürlich nicht.
Eine Diskrepanz von vier Stunden für eine Ressource über die sechsmonatige Lebensdauer eines Projekts, an dem Dutzende von Personen beteiligt sind, reicht nicht aus, um eine Änderung unseres Pfads zu rechtfertigen. Wir müssen beim Starten jeder Art von Enterprise-Projekt Schwellenwerte für akzeptablen Fortschritt festlegen. Die Luft- und Raumfahrt- und Verteidigungswelt findet in letzter Zeit einen neuen Begriff für diese , "Tripwires", die sehr beschreibend ist. Wir können festlegen, welche Kriterien uns zeigen würden, dass unsere Route neu berechnet werden muss. Es sind mehrere typische Metriken oder Measures zu berücksichtigen. Wenn die geplanten Fertigstellungskosten um mehr als X Prozent vom ursprünglichen Budget variieren, kann dies eine Projektplanüberprüfung darstellen. Sie können die Kosten in Arbeitsstunden oder Geld messen. Beides ist wirksam. Wenn der prognostizierte Endtermin um mehr als X Tage vom ursprünglich geplanten Endtermin ab weicht, kann dies eine Projektplanüberprüfung darstellen.
Sie können auch entscheiden, dass das Verpassen bestimmter wichtiger Meilensteine um mehr als eine bestimmte Anzahl von Tagen ein Tripwire ist, oder Sie erkennen bestimmte Risiken als Tripwire, oder Sie können feststellen, dass eine Änderung bestimmter wichtiger Teammitglieder, z. B. der leitende Sponsor, ein Tripwire ist. Es ist wichtiger, einige Kriterien festzulegen, als die Kriterien genau richtig zu erhalten. Denken Sie auch daran, dass Sie während der gesamten Lebensdauer des Projekts mit diesen Kriterien messen müssen. Wenn Sie also 50 oder 100 verschiedene Metriken auswählen, können Sie am Ende mehr Zeit damit verbringen, das Projekt zu messen, als das Projekt zu erledigen!
Sobald Sie festgestellt haben, dass Sie nicht mehr auf kursfähig sind, können Sie am besten eine Projektplanüberprüfung durchführen. Es wird empfohlen, die Vertretung sowohl der ursprünglichen Gruppe der Geschäftsleitung, die bei der Gründung unseres Ziels geholfen hat, als auch der Gruppe innerhalb des Projektmanagementteams, die bei der Erstellung des ursprünglichen Inventars geholfen hat, aufzunehmen. Projektplanüberprüfungen können sich daran verdingen, die Schuld dafür zuzuweisen, warum das Projekt nicht in der Spur ist und warum ein bestimmter Tripwire ausgelöst wurde. Ein solcher Aufwand kann enorm kontraproduktiv sein. Es wird empfohlen, sich auf die folgenden Fragen zu konzentrieren:
Was ist geschehen?
Wo sind wir gelandet? Was ist unser aktueller Ausgangspunkt?
Sind wir immer noch auf unser ursprüngliches Ziel festgelegt, oder gibt es einen zwingenden Grund, diesen Prozess zu überprüfen oder sogar den Prozess der Bereitstellung zu wiederholen?
Müssen wir zwischengeschaltete Meilensteine oder Phasen zurücksetzen?
Müssen wir unser Projektteam ändern?
Müssen wir unsere Tripwire-Metriken zurücksetzen?
Zu den Fragen, die wir als weniger produktiv befunden haben, gehören:
Wessen Fehler ist es, dass wir hier sind? Wer ist verantwortlich? Wer ist schuld?
Wie kommen wir wieder auf Kurs? 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 für Phase 3 konzipiert wurden, in Phase 2 angefordert. Dies ist in der Regel ein Zeichen für eine fehlerfreie Dynamik innerhalb der Organisation und das Ergebnis, dass die Leute beginnen, ernsthaft über die Auswirkungen der Bereitstellung des EPM-Systems nachzudenken.
Schlechtes Wetter
Bevor Sie eine lange Fahrt unternehmen, überprüfen Sie wahrscheinlich den Wetterkanal (oder weather.msn.com), um sicherzustellen, dass sich kein schlechtes Wetter auf Ihre Reise auswirkt. Risiken gehören zum Leben. Denken Sie daran, wenn es keine Risiken gäbe, gäbe es keine Notwendigkeit für Projektmanager! Die Planung für die eklatantesten Risiken ist kein komplizierter Prozess. Beginnen Sie am Anfang des Planungsprozesses, und fragen Sie die Gruppe, welche Hindernisse für das Erreichen dieses Ziels sie sich vorstellen können. In einigen Fällen sind die Risiken erheblich. Es ist nicht ungewöhnlich, dass eine Organisation ein bestimmtes Ergebnis wünscht, nur um festzustellen, dass die rohen Daten, die für die Übermittlung dieses Ergebnisses erforderlich sind, nie gesammelt wurden und dass es möglicherweise erheblichen Widerstand gegen die Sammlung dieser Daten gibt.
In einem Beispiel haben wir eine Organisation gefunden, die die Ressourcenkapazitätsplanung wollte. Dies erforderte eine vollständige Abrechnung aller Ressourcenverfügbarkeiten aller Projektmitarbeiter und eine vollständige Abrechnung aller möglichen Workloads, die auf diese Mitarbeiter angewendet werden konnten. Als wir gefragt haben, ob beide verfügbar sind, wurde uns gesagt, dass sie sicher verfügbar sind, aber nur für zwei Fünftel der Organisation. Als wir dann feststellten, dass die drei Fünftel der Organisation, für die die Daten nicht verfügbar waren, nicht einmal bei der envisioning Meeting vertreten waren, sagten wir: "Lassen Sie uns raten. Die Probleme, die Sie mit der Ressourcenkapazitätsplanung haben, liegen in diesen drei Bereichen." Natürlich waren sie das, und wir mussten die Einschreibung der Abteilungsleiter dieser Bereiche als separate Phase des Projekts und sehr hohes Risiko identifizieren.
Wenn Sie mit dem Projektmanagement und dem Line-Personal im Inventarprozess zusammenarbeiten, fragen Sie während der Vorstellungsgespräche nach Risiken, die diese Mitarbeiter möglicherweise identifizieren können.
Nachdem die Risiken identifiziert wurden, ist es wichtig, sie zu organisieren. Wenn Sie dies noch nicht getan haben, sind die grundlegendsten Informationen die wertvollsten. Enthalten:
Eine kurze Beschreibung des Risikos
Der Bereich oder die Phase des Projekts, auf die es sich auswirken kann
Der Schweregrad des Risikos, wenn die Kriterien erfüllt sind
Schließlich ist eine der wichtigsten Dinge, die Sie tun können, einige Details zur Risikominderung hinzuzufügen. Nur über ein Risiko nachzudenken, ist ein großer Minderungsfaktor, aber während die EPM-Bereitstellung noch in den Kinderschuhen steckt, kann es von unschätzbarem Wert sein, einige Hinweise dazu zu geben, wie Sie während des Projekts mit einem bestimmten Risiko umgehen können. Es ist üblich, dass Entscheidungen in Eakt in einem emotionalen Kontext getroffen werden, wenn Risiken realisiert werden. Einige Notizen zu haben, die durchdacht wurden, während kühlere Köpfe vorherrschen, kann nützlich sein.
Lassen Sie uns das Auto fahren, das wir bauen
Hier ist ein Tipp, wie Sie Ihre Roadmap erstellen, die sich möglicherweise auszahlt: Verwenden Sie Project Server und die Microsoft EPM-Lösung, um Ihren Roadmap-Plan zu erstellen und zu verwalten. Es scheint vielleicht offensichtlich, aber es ist selten genug für Organisationen, das zu tun, wir erwähnen es hier.
Ich hatte einmal einen leitenden Manager, der mir sagte, dass seine Projektmitarbeiter ihn gefragt hatten, ob er dachte, dass die Verwendung der Microsoft EPM-Lösung zum Bereitstellen der Microsoft EPM-Lösung nicht übertrieben wäre. "Wenn wir Jet-Flugzeuge für einen Lebensunterhalt bauen würden, würden wir sie nicht zur Arbeit fliegen", sagten sie. "Scherzen Sie?", antwortete er. "Wenn ich ein Düsenflugzeug zur Arbeit fliegen könnte, würde ich es jeden Tag tun!"
Tatsächlich ist die Verwendung der Microsoft EPM-Lösung für das EPM-Bereitstellungsteam eine gute Idee.
Die Installation von Project Server und den anderen Elementen der Microsoft EPM-Lösung ist keine große technische Herausforderung, und mit dem absoluten Minimum an Konfiguration können Sie innerhalb weniger Tage mit einem kleinen Bereitstellungsteam als Benutzer ausgeführt werden. Dies ist eine hervorragende Möglichkeit für benutzer, die zu Ihren Bereitstellungsexperten werden, sich mit der Verwendung und den Vorteilen des Systems vertraut zu machen, bevor es an den Schreibtischen des Großteils der Mitarbeiter eintrifft.
Diese Bereitstellung sollte nicht Ihre Produktionsumgebung sein. Sie werden dies mit ziemlicher Sicherheit konfigurieren und anpassen, um die Vision des ursprünglichen Ziels zu erfüllen. Sie werden in Ihrer EPM-Bereitstellungsiteration von Project Server mit hoher Wahrscheinlichkeit nicht an Dingen wie der Planung mehrerer Projekte oder der Ressourcenkapazität oder der Portfoliooptimierung arbeiten, aber Sie werden in der Lage sein, ein System bereitzustellen, das große Vorteile bieten kann. Wir empfehlen Folgendes:
Führen Sie einen Zeitplan für eine rollierende Welle als veröffentlichtes Projekt durch.
Ein Zeitplan für eine rollierende Welle hebt die aktuelle Phase ausführlich und die zukünftigen Phasen als Zusammenfassung hervor. Dadurch erfahren die Teammitglieder, worüber sie jetzt arbeiten müssen, und können das Projekt dennoch in einem größeren Kontext sehen.
Verwalten Sie das Vision-Dokument 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 platzieren Sie nicht alle Ihre Projektdokumente für das EPM-Bereitstellungsprojekt hier, und erstellen Sie die Versionskontrolle von SharePoint, damit Sie immer zur ursprünglichen Version zurückkehren können?
Platzieren Sie Ihre Meilensteinabzeichen und "Gates" in den Projektarbeitsbereichs-Lieferumfang.
Dies ist eine einfache Aufgabenliste, die Sie mit Vorgängen in Project Server verknüpfen können. Es gibt eine sehr hochwertige Ansicht des Projekts und ist ein einfaches Tool, das für die Schwellenwertverwaltung verwendet werden kann, um zu bestimmen, wann Sie "aus dem Kurs" gehen.
Fügen Sie die Änderungsverwaltung als Probleme in den Projektarbeitsbereich ein.
Change Management ist eine der großen Herausforderungen von Technologieprojekten. Wenn neue Vorschläge für Änderungen am Projekt auftreten, bringen Sie sie in den Issue-Bereich, um eine potenzielle Änderung zu verwalten. Wenn Sie diesem Bereich einige Felder hinzufügen, können Sie jederzeit eine Liste mit Elementen mit hoher Priorität und deren Verantwortung abrufen.
Fügen Sie die Projektrisiken in den Projektarbeitsbereich ein.
Abgesehen von Dokumenten und Problemen ist der Risikobereich des Arbeitsbereichs der ideale Ort, um Ihre Risiken und Risikominderungspläne hinzuzufügen. Tatsächlich sind auf dem Standardbildschirm alle Felder zur Verwendung bereit.
Sind wir schon da?
"Fast. Wir werden bald da sein."
Eine EPM-Bereitstellung kann eine Organisation an so viele verschiedene Orte bringen, dass es keine Möglichkeit gibt, einfach den Standardzeitplan für alle zu veröffentlichen. Aber ein paar Minuten beim Durchsuchen des Internets können Ihnen viele mögliche Beispiele für verschiedene Teile des Projekts liefern. Wenn ich die obige Roadmap-Übung zusammenfasse, werden Sie wahrscheinlich mit einem Projekt enden, das einige offensichtliche Phasen aufweist:
Roadmap-Übung
Envisioning (Wählen Sie das Ziel aus)
Bestand vorhandener Prozesse (Identifizieren des Ursprungspunkts)
Bestand des vorhandenen Personals (Identifizieren des Ursprungsorts)
Inventar der Technologie (Identifizieren des Ursprungsorts)
Bereitstellung der EPM-Lösung für das EPM-Team
Phase 1
Design
Konfiguration, Anpassung, Dokumentation
Pilotprojekt
Schulungen
Rollout
Überprüfung von Phase 1 und Anpassen von Phase 2 nach Bedarf
Phase 2
Phase 3
Phase 4
Projektumbruch
Das Anwenden einer Roadmap-Übung auf Ihre EPM-Bereitstellung kann die Erfahrung sehr schnell von chaotisch in verwaltbar ändern. Denken Sie daran, zuerst Ihr Ziel zu wählen, als Nächstes Ihren Ausgangspunkt zu ermitteln und den Pfad zwischen ihnen zu zeichnen.
Viel Spaß beim Reisen!
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).