Das unterschätzte Risiko – Warum viele Einführungsprojekte von Projektmanagement Software scheitern

Martin RudolphProjektmanager kennen das magische Dreieck aus Kosten, Dauer und inhaltlichem Projektziel (Qualität). Ein Projekt innerhalb des vorgegebenen Budgets, im Rahmen der vereinbarten Zeitplanung und mit den erwarteten Ergebnissen abzuschließen, ist eine anspruchsvolle Herausforderung - zumal diese drei traditionellen Komponenten heutzutage durch die drei weiteren Faktoren Risiko, Nutzen und Stakeholder-Zufriedenheit ergänzt werden. Das Gleiche gilt für Software-Einführungsprojekte. Wer sich in der Industrie umhört, stellt schnell fest, dass viele Software-Einführungsprojekte nicht erfolgreich verlaufen. Was sind die Gründe? Wo liegen die spezifischen Risiken bei der Einführung einer neuen Projektmanagement-Software? Und wie kann diesen Risiken in der Praxis entgegen gewirkt werden?

Die Anschaffung einer neuen PM-Software ist langfristig ausgelegt. Unternehmen erwarten, dass ein einmal in Betrieb genommenes System zumindest über die nächsten fünf bis eher zehn Jahre im Einsatz ist, bevor es ggf. abgelöst wird. Hieraus ergeben sich die Herausforderungen der Erstmaligkeit und der Skalierbarkeit. Da frühere Einführungsprojekte vielleicht schon lange zurückliegen, ist das notwendige Know-How unternehmensintern nicht mehr vorhanden. Diejenigen, die seinerzeit für die Auswahl der alten PM-Software verantwortlich waren, haben das Unternehmen vielleicht bereits verlassen oder die technologischen, organisatorischen und prozessualen Rahmenbedingungen haben sich grundsätzlich geändert.

Die Gründe, warum die Einführung von PM-Software scheitern kann, lassen sich in zwei Risikogruppen einordnen:

  • Einmal in das Risiko, dass ein Einführungsprojekt noch vor der Produktivsetzung nicht erfolgreich verläuft.
  • Zum anderen in das Risiko, dass ein System nach der Einführung nicht in der gewünschten Art und Weise genutzt wird.

Die zugrundeliegenden Treiber beider Risikotypen, und wie diesen in der Praxis entgegen gewirkt werden kann, sollen im Folgenden skizziert werden.

Risiken vor der Produktivsetzung

Die Auswahl und Einführung einer neuen PM-Software ist kein reines Beschaffungsprojekt, sondern ein erkenntnisgetriebener Prozess. Wer dies nicht beachtet, setzt sich bei der Software-Einführung fünf potenziellen Gefahren aus.

Erstens können sich überzogene Erwartungen an das einzuführende System im Laufe des Einführungsprojektes als nicht realisierbar herausstellen. Gesucht ist die in freier Wildbahn leider eher selten anzutreffende eierlegende Wollmilchsau, also eine PM-Software, die die im Vorfeld formulierten Anforderungen vollumfänglich abdecken kann. Ernüchterung und Unzufriedenheit stellt sich dann ein, wenn sich die Erkenntnis durchsetzt, dass keines der am Markt verfügbaren Systeme dem avisierten Idealzustand als „Out-of-the-Box“-Lösung entspricht oder umfangreiches Customizing zur Realisierung dieser Anforderungen notwendig ist.

Zweitens bestehen vielfach zunächst nur vage und amorphe Anforderungen an das einzuführende System. Eine generische Anforderung an ein neues System könnte beispielsweise dahin gehend lauten, dass eine Ressourcenzuordnung im Projekt möglich sein soll. Die Anforderungen an ein neues System müssen jedoch wesentlich spezifischer benannt werden. So sollte im genannten Beispiel konkretisiert werden, ob und wie im Rahmen der Ressourcenplanung eine rollenbasierte Grob- und Feinressourcenplanung notwendig ist oder nicht. Etliche weitere Beispiele für generisch formulierte Anforderungen sind in der Praxis häufig anzutreffen. Neben funktonalen Anforderungen spielen zudem nicht-funktionale Anforderungen wie Benutzerfreundlichkeit, Wartungsfragen und IT spezifische Themen eine nicht unwesentliche Rolle. Hierbei sollten Anforderungen noch nicht zu sehr lösungsorientiert spezifiziert werden, da dies potenzielle Lösung zu sehr vordefiniert und einen möglichen Lösungsraum frühzeitig verengt.

Drittens empfiehlt sich die Definition von prozessualen Anwendungsfällen anstelle eines reinen Checklisten-Ansatzes. Bei Checklisten sollen Projektleiter oft anhand von technischer Funktionen festlegen, ob sie diese in ihrem täglichen Alltag für notwendig halten. Dieser Ansatz greift jedoch oft zu kurz, da Projektleitern die technische Expertise fehlt, um die funktionalen Anforderungen an ein System zu benennen. Sinnvoller ist es, wenn die Projektleiter Erwartungen in ihren eigenen Worten beschreiben, um dann durch den Fachmann eine Ausformulierung der funktionalen Anforderungen vornehmen zu lassen. Auch ist dies dann eher anwendungs- als lösungsorientiert. Zudem erfüllt manch ein System einzelne funktionale Anforderungen, aber im rollenbasierten Prozess zeigt sich u.U. eine nicht akzeptierbare Benutzerunfreundlichkeit oder das Berechtigungskonzept macht einen Strich durch die Rechnung.

Viertens scheitern Software-Einführungsprojekte bereits vor der Produktivsetzung aufgrund eines vernachlässigten Kommunikationsmanagements und durch mangelnde Koordination der beteiligten Stakeholder. Anforderungen werden zum Beispiel aufgrund fehlender Zuständigkeiten nicht systematisch aufgenommen. Eine weitere Risikoquelle ist auf interne Konflikte zurückzuführen, wenn es darum geht Anforderungen zu priorisieren und in eine im Rahmen des vorgegebenen Budgets akzeptable Lösung zu gießen.

Fünftens sollte die Nahstelle zwischen Fach- und IT-Seite mit einer entsprechend qualifizierten Person besetzt sein. Häufig werden auf der Fachseite Anforderungen erhoben und „über den Zaun“ zur IT sowie zum SW Anbieter gegeben, die dies in einer Systemumgebung (technisch) umsetzen sollen. Hier ist jedoch ein partnerschaftlicher Dialog notwendig. Ein Auswahl- und Einführungsprojekte benötigt eine Rolle, die sowohl die Anforderungen und Prozesse auf der fachlichen Seite versteht und interpretiert als auch über ausreichende Kenntnisse der IT-technischen Zusammenhänge verfügt.

Risiken nach der Produktivsetzung

Auch nach der Produktivsetzung existieren Risiken, die zum Scheitern von Software-Einführungsprojekten führen können. Hier ist zum einen der Faktor Software und zum anderen der Faktor Mensch zu sehen.

So besteht die Gefahr, dass fachliche Funktionen in Gänze fehlen oder fehlerhaft bzw. benutzerunfreundlich umgesetzt werden. Diese Gefahr besteht insbesondere dann, wenn die technische Implementierung ohne ausreichenden fachlichen Input durchgeführt wurde. Eine rein technikgetriebene Implementierung führt häufig dazu, dass niemand mit der notwendigen Einsatzbereitschaft mit dem System arbeitet und sich eine qualitativ mangelhafte Datenbasis entwickelt. Ein Teufelskreis, der zu einer Software-Ruine führen kann. Deswegen ist es wichtig, die Rolle des Projektleiters mit einem internen oder externen Mitarbeiter zu besetzen, der einerseits die fachlichen Anforderungen versteht, andererseits aber auch über grundlegende Systemkenntnisse verfügt. Hinzu kommen möglicherweise technische Mängel, sowie mangelnde Performanz bei hohen Nutzerzahlen bzw. Datenmengen denen die Software nicht gewachsen ist. Diese Risiken existieren insbesondere dann, wenn im Vorfeld der Einführung zusammen mit dem Hersteller kein Proof of Concept durchgeführt wurde oder keine Verifikation von Herstellerangaben erfolgt ist.

Neben den technischen Details, betrifft ein weiterer wichtiger Aspekt den Faktor Mensch. Ein zentrales – aber oft unterschätztes Risiko – besteht darin, dass ein neu eingeführtes System von den Anwendern nicht angenommen wird. Die Einführung einer neuen Toolunterstützung im Projektmanagement ist ein nicht zu unterschätzender Change in der Organisation. Das Change Management ist zwar dann ein nicht unwesentlicher Kostentreiber, aber es ist die bestimmende Voraussetzung, um den angestrebten verbesserten qualitativen Nutzen durch das neue System zu gewährleisten. Der Roll-Out eines Systems ist folglich technischer, fachlicher und kultureller Natur und sollte entsprechend gemonitort werden. Von Seiten des höheren Managements kann zwar versucht werden über Vorgaben die Nutzer zur Annahme eines neuen Systems zu bewegen, der Erfolg eines von oben verordneten Change-Managements stellt sich jedoch oft als illusorisch heraus.

Einführungsprojekte professionell managen

Zusammenfassend ist also ein umfassendes Anforderungs-, Risiko-, Qualitäts-, Kommunikations- und Change-Management notwendig, um ein Software-Einführungsprojekt erfolgreich abzuschließen. Zudem ist die zielgerichtete Besetzung der Nahtstelle von Fach- zur IT-Seite ein Schlüsselfaktor zum Erfolg. Je nach Größe und Umfang des Projektes, bietet es sich an, neben dem Projektleiter für jeden der genannten Bereiche eine übergreifende Funktion zu schaffen, die sicherstellt, dass die potenziellen Risiken bei der Einführung kontinuierlich minimiert werden. Um Zielkonflikten zwischen den intern beteiligten Stakeholdern vorzubeugen, kann auch die Beauftragung eines externen Dienstleisters, wie beispielsweise der Tiba Technologieberatung GmbH, sinnvoll sein, da diese über signifikante Erfahrung im Management von Software-Einführungsprojekten verfügen.

Der Autor dieses Gastartikels Martin Rudolph ist seit 25 Jahren als Berater, Trainer sowie in der Konzeption und Implementierung von Lösungen für das toolgestützte Projektmanagement tätig. Der seit 1997 geschäftsführende Gesellschafter der Tiba Technologieberatung GmbH hat erfolgreich zahlreiche Einführungsprojekte von unternehmensweiten und plattform-übergreifenden Projektmanagement-Standardsystemen geleitet.

 

Machen Sie jetzt unseren Projektmanagement Test

Wo steht Ihr Unternehmen bei der Planung und Steuerung von Projekten? Haben Sie eine Übersicht über Ihre eingesetzten Ressourcen und freie Kapazitäten? Wo und wie verwalten Sie diese Informationen? Wie weit ist Ihr Unternehmen im Bereich Multi-Projekt­management? Machen Sie jetzt unseren Test!

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert