3.9    Risiken der Implementierung von Microsoft Project Server oder Microsoft Project Online

Die AIRBI GmbH hat sich im Rahmen der Strategieentwicklung für die Einführung eines Microsoft-Projektmanagement-Systems entschieden und auch bereits festgelegt, wie die Einführung des Werkzeugs konkret ablaufen soll. Na dann sollte ab hier alles reibungslos verlaufen, oder nicht?

In diesem Abschnitt lernen Sie nun die Risiken kennen, die typischerweise die Einführung von Projektmanagement-Werkzeugen begleiten. Diese liegen weniger am Produkt selbst als vielmehr in der Natur von Projekten. So polarisiert Microsoft Project sehr stark. Möglicherweise beginnen die Mitarbeiter anfänglich Erfolg versprechende Pläne zu erstellen, wechseln dann aber in der Bearbeitung z.B. immer wieder zu Microsoft Excel. Das folgende Erfahrungsmodell wird Ihnen als Microsoft-Project-Anwender möglicherweise nicht ganz fremd sein:

• Phase 1 – enorme Begeisterung
  Einfache Installation des Programms/sieht aus wie Microsoft Office.
• Phase 2 – allmähliche Ernüchterung
  Die Software ist ja doch recht komplex.
• Phase 3 – Panik
  Irgendwie stimmen die Termine nicht mehr.
• Phase 4 – Flucht in Nebensächlichkeiten
  Balkenpläne lassen sich schön malen.
• Phase 5 – Bestrafung Unschuldiger
  Praktikanten helfen bei der Pflege der Pläne.
• Phase 6 – Verwerfen der Microsoft-Project-Pläne
  Der Plan wird in Microsoft Excel neu erstellt.

Tritt genau dieser Verlauf ein, das heißt, verweigern die Anwender den Einsatz von Microsoft Project, können Sie die Einführung des Projektmanagement-Werkzeugs als gescheitert betrachten.

Welche Risiken im Detail können zu solch einem Verlauf führen?

• Prozesse sind nicht klar und verbindlich definiert.
  Dieses Risiko besteht, wenn bei Ihnen keine Projektmanagement-Standards und verbindlichen Vorgaben vorhanden sind, mit anderen Worten, wenn jeder nach seiner eigenen Fasson arbeitet. Begrifflichkeiten und Standards sind dann nicht vereinbart. Um das zu verhindern, hat Heinrich Schmidt innerhalb der ersten Iteration die parallele Entwicklung von Projektmanagement-Prozessen und entsprechende Trainings vorgesehen.
• Die Verantwortlichen und Ansprechpartner sind nicht benannt.
  Niemand ist für das System wirklich verantwortlich. Es gibt niemanden, der Standards und die Verbindlichkeit des Einsatzes überwacht und steuernd eingreift. Sie können hier gegensteuern, indem Sie parallel den Aufbau von organisatorischen Strukturen und die klare Definition von Rollen vornehmen. Auch dieser Punkt ist deshalb zusätzlich zur Systemeinführung in der Roadmap vorgesehen.
• Das System wird nicht akzeptiert.
  Dieses Risiko kann zum Problem werden, wenn Sie nur wenige Beteiligte vor der Einführung an der Konzeption des Systems beteiligen und die Gründe für die Einführung des Systems nicht ausreichend kommunizieren. In diesem Fall wird den Mitarbeitern der mögliche Mehraufwand zur Erarbeitung und Aktualisierung von Projektplänen sehr wohl auffallen, jedoch nicht der Nutzen.
  Mit der Nutzung eines bewährten Vorgehensmodells können Sie die betroffenen Mitarbeiter in die Anforderungsdefinition (Define) sowie in die Entwicklung des Prototyps (Design) einbinden. Die Pilotgruppe stellt zudem mit ihrem Feedback sicher, dass der Roll Out auf die gesamte Organisation ein Erfolg werden kann. Außerdem beinhaltet die Roadmap den Aufbau von Bereitstellungs- und Unterstützungsprozessen durch ein Projektmanagement-Office (PMO), um den Benutzern die nötige Sicherheit und einen zentralen Anlaufpunkt bei Fragen zu geben.

Diese drei Risiken seien hier exemplarisch erwähnt. Sie sehen, dass die Entwicklung einer Roadmap und damit einer Einführungsstrategie sowie die Anwendung eines strukturierten Vorgehensmodells bei der eigentlichen Werkzeugeinführung diese Risiken erheblich eindämmen können.