Wie wäre es hierbei mit ein wenig EPM? – Whitepaper

Dieses Whitepaper ist Teil unserer Sammlung "Aus der Praxis". Es erörtert die Entwicklungsgeschichte von Projektmanagementsystemen, die Nutzung von EPM (Enterprise Project Management) und zeigt, wie wichtig es ist zu verstehen, welche Projektmanagementlösung für Sie am besten geeignet ist.

Die Word-Version dieses Whitepapers finden Sie unter Whitepaper: Wie wäre es hierbei mit ein wenig EPM?.

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

Wie wäre es hierbei mit ein wenig EPM?

Kürzlich sprach mich im Büro einer meiner erfahrendsten Mitarbeiter an und stellt mir eine merkwürdige Frage.

"Wie kann man wissen, ob es sich bei einer Software um ein Projektmanagementsystem handelt?"

Ich wollte gerade schon eine Antwort geben, schluckte diese dann aber herunter und hielt inne ... und zwar für längere Zeit. Gute Frage, und die Antwort ist nicht offensichtlich.

Anfang der 1980er Jahre kamen die ersten Pakete zur Planung des kritischen Wegs für PCs auf den Markt. Tatsächlich finde ich es interessant, dass historisch gesehen Software für die Planung des kritischen Wegs zu den ersten kommerziellen Anwendungen gehörte, die in jeder neuen Welle der Computernutzung beginnend mit den ersten kommerziell verfügbaren Mainframes in den 1960er Jahren auf den Markt kamen. Meine Karriere in der Projektmanagementsoftware-Branche begann jedoch in den frühen 80er Jahren, und seinerzeit haben wir die Begriffe "Projektmanagementsoftware" und "Planungssoftware für den kritischen Weg" synonym verwendet.

Wenn mir 1983 jemand etwas anderes als ein Planungssystem für den kritischen Weg gezeigt und mich gefragt hätte, ob es sich hierbei um ein Projektmanagementsystem handelt, hätte ich wahrscheinlich den Kopf geschüttelt und nein gesagt.

Microsoft Project ist im Kern ein Planungssystem für den kritischen Weg, und wir verwenden immer noch den Begriff Projektmanagementsoftware, um die Anwendung zu beschreiben. Wenn mich also jemand fragt, ob Microsoft Project eine Projektmanagementsoftware ist, habe ich keine Probleme damit, dies zu bestätigen.

Aber was ist mit Buchhaltungssoftware? Es gibt diverse Dynamics-Produkte, mit denen Projektbudgets erstellt und die Kosten nachverfolgt werden. Ist das Projektmanagement? Auch das muss ich bejahen.

Mit SharePoint-Produkten können Sie Dokumente und Dokumentenworkflows verwalten und Listen mit offenen Problemen erstellen. Ist das eine Projektmanagementsoftware? Sieht ganz so aus!

Microsoft Dynamics CRM ermöglicht Ihnen, Aktivitäten und Ressourcen mit Kundeninitiativen zu verbinden. Ist das Projektmanagement? Könnte man sicherlich so sehen.

Und wie sieht es mit Software für die Vertragsverwaltung, die Arbeitszeittabellen-Verwaltung, die Personaleinsatzplanung, den Materialverbrauch, die Arbeitsmittelverwaltung und die Verfolgung des Produktionswerts aus? Kann diese Software auch als Projektmanagementsoftware bezeichnet werden? Ja, jede dieser Anwendungen könnte man als Projektmanagementsoftware bezeichnen.

Vor Jahren habe ich mit einem Experten für das Projektmanagement im Bauwesen zusammengearbeitet, dessen wichtigstes Tool eine Software war, mit der er das Arbeitstempo mehrerer Gewerke gleichzeitig verwalten konnte. Mit einem einzigen grafischen Bericht verfolgte er Zimmerleute und Klempner, Elektriker und diverse andere Gewerke. Dieses sehr abgeklärte Projektmanagement hat mir gezeigt, dass mit der einfachen Verwaltung des Tempos der einzelnen Teams verhindert werden konnte, dass die Elektriker anrücken, bevor die Trockenbauwand errichtet war, und dass die Klempner den Elektrikern auf den Füßen standen. Dieser einfache Bericht für diesen speziellen Projekttyp hat es dem Projektmanager ermöglicht, erstaunlich effektiv zu arbeiten. War das ein Projektmanagementsystem? Darauf können Sie wetten.

Um die Angelegenheit noch komplexer zu machen, gibt es sowohl Projektmanagementtools, die die Effektivität der einzelnen Projektmanager steigern, und weitere Tools, die sich eher an die Organisation als solche wenden. Willkommen im magischen Garten der "Enterprise Project Management-Software". Um fair zu sein, das Konzept ist nicht wirklich neu. Die ersten Projektmanagementsysteme in den 60er- und 70er-Jahren waren alle Enterprise-Tools, obwohl der Zugriff auf Computersysteme seinerzeit im Allgemeinen weit mehr Einschränkungen unterlag als sie für heutige Organisationen gelten.

Wie alles, was Hand und Fuß hat, lässt sich auch das Enterprise Project Management auf eine aus drei Buchstaben bestehende Abkürzung reduzieren: EPM. Wenn ich allerdings im Internet nach EPM suche, finde ich vielleicht Enterprise Project Management. Möglicherweise finde ich aber auch Enterprise Performance Management, Enlisted Personnel Management, Electric Propulsion Motor, Exchange Permission Manager oder eine beliebige andere der etwa 40 weiteren Definitionen. Vergewissern Sie sich, dass Sie nach dem richtigen Schlagwort suchen, denn ein Antriebsmotor (Electric Propulsion Motor) ist bei der Projektplanung wahrscheinlich nicht sehr hilfreich.

Wenn es schon Schwierigkeiten bei der Definition gibt, was ein Projektmanagementsystem ist, dann ist es wahrscheinlich noch viel schwieriger zu definieren, was aus einem Projektmanagementsystem ein "Enterprise Project Management System" macht.

Aber ist das unter dem Strich wirklich wichtig?

Ich war zeitweilig dafür berüchtigt, dass ich es vorziehe, immer erst das Problem zu definieren, bevor ich nach einer Lösung Ausschau halte. Bei uns gehen häufig Anrufe ein, in denen um Hilfe bei der Bereitstellung eines "Enterprise Project Management Systems" gebeten wird, und ich muss dann zwangsläufig immer wieder dieselben Fragen stellen, nämlich was ist mit "Enterprise" gemeint, und welche Erwartung verbirgt sich hinter "Projektmanagement". Es dauert dann in der Regel ein paar Minuten, in denen der Anrufer sein Anliegen erläutern muss. Schließlich verfüge ich über ein profundes Hintergrundwissen im Bereich des Projektmanagements, und die Anrufer wissen sicher, dass ich weiß, was diese Begriffe bedeuten.

Manchmal stellt sich heraus, dass hinter "Enterprise" nur eine Handvoll Leute stehen. Daran ist erst einmal nichts auszusetzen. Ich führe selbst ein kleines Unternehmen, und "zu klein" gibt es nicht. Aber wenn ich nicht nachgefragt hätte, hätte ich möglicherweise eine Software empfohlen, die für eine Firma mit 1.000 Mitarbeitern ausgelegt ist. Das hätte zwar sicher ganz putzig ausgesehen, hätte aber auch ein absolutes Missverhältnis zwischen Tools und Bedarf bedeutet. Darüber hinaus wäre auch die Kapitalrendite einer solchen Implementierung wahrscheinlich schauderhaft, da es schwierig ist, eine so unverhältnismäßige Investition mit der Effizienz eines kleinen Teams wieder hereinzuholen.

Wenn Sie jemanden bei der Toolauswahl beraten möchten, ist es nicht nur wichtig, die richtige Größenordnung zu wählen, Sie müssen auch unbedingt in Erfahrung bringen, worin die geschäftlichen Herausforderungen bestehen.

Vor einigen Jahren besuchte ich einen sehr großen Energieversorger, bei dem wir uns bereits einen guten Ruf mit der Unterstützung bei der Einführung einer Projektmanagementsoftware geschaffen hatten. Während des Besuchs traf ich den Leiter einer neuen Abteilung, der eine "Enterprise-Projektmanagementsoftware" einführen wollte. Ich setzte mich mit ihm zusammen, und wir gingen gemeinsam die Anforderungen durch.

"Wie viele Projekte verwalten Sie?", fragte ich ihn.

"Zehn bis zwölf gleichzeitig", antwortete er.

"Und wie viele Vorgänge gibt es in diesen Projekten?", fragte ich weiter.

"Oh, das ist immer gleich. Sechs Vorgänge", antwortete er.

"Sechs", wiederholte ich. "Wir sprechen also von 60 bis 70 Vorgängen, die parallel verwaltet werden müssen?"

"Ja, das ist richtig. Es ist sehr komplex", sagte er.

"Ich verstehe", sagte ich. "Und wie viele Benutzer sind mit der Verwaltung dieser Vorgänge befasst ?", fragte ich.

"Nur ich", antwortete er.

Ich bin sicher, Sie haben das kommen sehen. Es gab keinen kritischen Weg, und es war keine Problemverwaltung, keine Dokumentverwaltung, kein Kapazitätsabgleich, kein Risikomanagement und keine Kostenverwaltung erforderlich. Alles, was er benötigte, war eine visuelle Übersicht über die ausstehenden Vorgängen für sich selbst, damit er nicht versehentlich irgendetwas aus den Augen verlieren konnte. Der monetäre Wert dieser Projekte war wirklich hoch, es ging tatsächlich um einige Millionen Dollar, allerdings ließ der einzigartige Typ des Projekts den Schluss zu, dass es relativ einfach zu verwalten sein sollte.

"Warum bilden wir die Projekte nicht einfach auf einem Whiteboard hier in Ihrem Büro ab?", schlug ich vor. "Sie könnten mit selbstklebendem Markierungsband Zeilen für, sagen wir 15 Projekte erstellen, und dann mit farbigen Markierstiften die Planung aktualisieren und hätten die Projekte immer vor Augen. Sie könnten beispielsweise einen roten Markierstift verwenden, um wichtige Meilensteine zu kennzeichnen, und einen grünen Markierstift für Vorgänge mit einer langen Vorlaufzeit."

Er schien ziemlich verwirrt und gleichzeitig aufgebracht zu sein, dass ich ihm für die Verwaltung seiner Projekte nun keine Software auf Unternehmensniveau empfehlen konnte. Er hatte von Kollegen aus der Firma gehört, dass es leistungsfähige Enterprise-Projektmanagementpakete auf dem Markt gibt, und er war sicher gewesen, dass ich ihm empfehlen würde, eines dieser Paket zu implementieren.

Die Besprechung war kurz danach zu Ende, und ich war mir sicher, mit meinem Rat einen enttäuschten neuen Kontakt hinterlassen zu haben. Zu meiner Überraschung rief er mich jedoch eine halbe Stunde später auf meinem Handy an, als ich schon auf dem Nachhauseweg war.

"Ich möchte mich noch einmal ausdrücklich für unser Treffen bedanken", begann er. "Ich habe mir bereits aus dem Materiallager unserer Firma ein Whiteboard kommen lassen, aber hätten Sie vielleicht noch eine Minute für mich, um mir noch einmal zu erklären, welche Farbe ich für welche Vorgangstypen verwenden sollte?"

Fünfzehn Minuten später hatte er sich eine Menge Notizen gemacht und war mit meinem Vorschlag sehr zufrieden.

Für mich war das ebenfalls eine wichtige Lektion, die ich später bei vielen weiteren Beratungsgesprächen immer wieder eingebracht habe. Ich versuche, mir am Anfang eines Beratungsgesprächs immer eine stille Minute zu nehmen, um mir klarzumachen, was mit Begriffen gemeint ist, die trügerischerweise wie ein universeller Standard klingen.

Projektmanagementsoftware kann in zahlreiche Kategorien eingeordnet werden. Auch wenn wir nur mit den Projektmanagementbereichen des Project Management Institutes beginnen, finden wir:

  • Integrationsmanagement

  • Kostenmanagement

  • Kommunikationsmanagement

  • Bereichsverwaltung

  • Qualitätsmanagement

  • Risikomanagement

  • Zeitmanagement

  • Personalwesen

  • Beschaffungsmanagement

Es ist einfach, sich die Vielzahl der Tools, Pakete und Techniken für die Verwaltung all dieser Bereiche vorzustellen, und, je nach der jeweiligen Situation, könnten jede dieser Lösungen für erhebliche Verbesserungen im Projektmanagement oder im unternehmensübergreifenden Projektmanagement sorgen.

Nehmen wir beispielsweise einmal an, eine Organisation hat Probleme mit der Projektkommunikation, weil sich die Ressourcen möglicherweise in einer Reihe unterschiedlicher Zeitzonen und Länder oder gar Unternehmen befinden. In diesem Fall wäre es einfach zu zeigen, wie mit der Implementierung von Lync und SharePoint gewaltige Verbesserungen bei der Kommunikation erzielt werden können.

Wenn eine Organisation jedoch mit vielen Untervertragsnehmern an einem Projekt arbeitet oder wenn im Projekt umfangreiche Einkäufe getätigt werden müssen, könnten mit einem leistungsstarken Beschaffungsmanagement und einer Dynamics ERP und SharePoint gute Erfolge erzielt werden.

Wenn eine Organisation komplex aufgebaut oder etwas größer ist und die Herausforderung im Projekt in der Priorisierung und der Planung der Ressourcenkapazitäten liegt, ist Project Server möglicherweise der schnellste Weg zur Kapitalrendite.

Können Sie sich noch an meinen Mitarbeiter erinnern, der gefragt hat, ob es sich bei einem bestimmten Paket um Projektmanagementsoftware handelt? Meine Antwort lautete: "Ist es eine Software? Ist sie für das Management von Projekten geeignet? Dann ist es eine Projektmanagementsoftware. Und jetzt sollten Sie sich aufmachen und herausfinden, worin die geschäftliche Herausforderung Ihres Kunden beim Projektmanagement besteht."

Es führt immer zu besseren Ergebnissen, wenn Sie erst das Problem kennen, die das Projekt darstellt, bevor Sie Ihre Projektlösung implementieren.

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!

×