Projekt-Management-Tools: Warum PM-Projekte scheitern

Selten sind es äußerliche Faktoren wie schlechte Beratung, die die Einführung eines Projekt-Management-Tools zum Scheitern verurteilen. [...]

Dass die Einführung eines Projekt-Management-Werkzeugs ein Projekt für sich ist, gilt mittlerweile als Binsenweisheit. Dass sie keineswegs scheitern darf, leuchtet ein, denn von ihr hängt die gesamte Projektkultur des Unternehmens ab. Trotzdem machen die Unternehmen hier häufig gravierende Fehler. Welches sind die Stolperfallen auf dem Weg zu einem gern und intensiv eingesetzten PM-Tool? Und wie lassen sie sich umgehen? Diese Fragen werden anhand der acht häufigsten Fehler beantwortet. werden.
TOOL ERSETZT METHODE
Es ist eine Binsenweisheit, dass erfolgreiches Projekt-Management weit mehr ist als nur die Einführung eines PM-Tools. Doch obwohl zu erwarten wäre, dass dies hinlänglich bekannt ist, denken viele Verantwortliche noch immer, mit der Implementierung eines modernen Werkzeugs hätten ihre Projektleiter alles zur Hand, was sie für ihre Arbeit brauchen. Schließlich beherrschen die Projektleiter ihr Geschäft, und moderne Tools unterstützen sowieso die meisten bekannten PM-Methoden.
So ein Tool berechnet zum Beispiel auf Knopfdruck verschiedene Terminszenarien oder sucht per Mausklick zur Verfügung stehende Mitarbeiter zusammen. Doch die Entscheidung für das am besten geeignete Phasenmodell es nicht treffen. Es weiß auch nicht, in welcher Art und Weise Projektmitarbeiter vom Abteilungsleiter zugesichert werden sollen. Solche Fragen der unternehmensweiten Projekt-Management-Prozesse und -methoden können von den Werkzeugen allenfalls unterstützt werden.
Tools können also auswerten, aufbereiten, anschaulich machen. Aber es sollte darum gehen, sie stufenweise und im Einklang mit Prozessen, Methoden und Organisationsanpassungen einzuführen. Ziel ist es doch, das Unternehmen auf dem Weg zu einem höheren Reifegrad zu begleiten.
METHODE UND KEIN ENDE
Auch der umgekehrte Fall lässt sich beobachten: Es gibt viel Methode, aber noch kein adäquates Werkzeug. Offenbar herrscht bei einigen Beratungsansätzen die Philosophie vor, dass zuallererst sämtliche Prozesse und Methoden gründlich erarbeitet werden müssen. Erst wenn diese stehen, kann das dazu passende Tool ausgewählt werden.
Im Rahmen dieser Einführung von Prozessen und Methoden wird viel (durchaus sinnvoll aufgewendete) Zeit in die Erstellung von Prozess-Charts, Workflows und Vorlagen investiert. Parallel entstehen massenweise Folien, mit deren Hilfe Festlegungen und Ergebnisse präsentiert werden, was bei Projekt-Managern schon mal zu abfälligen Begriffen („Powerpoint-Projekt-Management“) führt.
Sicher ist der Schritt der Methodeneinführung notwendig. Aber wenn er zu lange dauert, kann es passieren, dass sich die Projektverantwortlichen unter dem gegebenen Zeitdruck eigene Lösungswege suchen. Die heißen dann häufig Excel oder Microsoft Project, und manchmal handelt es sich auch um ein proprietäres Web-basierendes System. Und haben sich die Projektleiter erst einmal ihre eigene Minilösung zurechtgebastelt, wird es schwierig, ein unternehmensweites Tool einzuführen, welches die neuen Prozesse und Methoden unterstützt. Denn die eigene Lösung funktioniert, und man hat schließlich viel Zeit dafür investiert.
Methoden und Prozesse sind wichtig. Aber das ist eben nur der erste Schritt zum erfolgreichen Projekt-Management. Der möglichst zeitgleichen Tool-Einführung ist dabei eine ähnliche hohe Bedeutung beizumessen. Sie sorgt nicht nur für ein Werkzeug in der Hand der Projektbeteiligten, sondern auch dafür, dass Methoden und Prozesse im Rahmen ihrer Einführung erprobt und verbessert werden können.
Viele Unternehmen verbringen viel Zeit mit Definition und Design von Workflows im Vorfeld einer Tool-Einführung, die dann in das Werkzeug eingebaut werden müssen. Im Nachhinein stellt man dann bisweilen fest, dass einige Workflows zu komplex, überflüssig oder nicht ausreichend sind.
EIN AUFGEZWUNGENES TOOL
Neben der Frage, wann ein Tool ins Spiel kommt, sollte auch betrachtet werden, wer eigentlich über ein neues System entscheidet. Projekt-Management-Werkzeuge betreffen mehrere Rollen im Unternehmen, die Entscheidung darüber wird somit auf Management-Ebene getroffen – meist von der IT-Leitung. Eine recht häufig anzutreffende Tendenz ist die, das ERP-System einfach um Projekt-Management-Module zu erweitern. Das erscheint auf dem ersten Blick als eine recht praktikable Lösung, vor allem für das Projekt-Controlling; für die beteiligten Fachbereiche jedoch ist so ein ERP-Tool selten praxistauglich.
In der Folge akzeptieren die Projektbeteiligten das System nicht; die Projektleiter führen ihre „Schattenbuchhaltung“ in anderen Tools (auch hier stehen Excel oder Microsoft Project Client ganz oben auf der Liste) und pflegen nur das absolut Nötigste im ERP-System. Es sind sogar Fälle bekannt, in denen Projektteams aus den Fachbereichen die Implementierung eines ihnen aufgezwungenen ERP-basierenden Systems bewusst gegen die Wand fahren ließen, um ihrerseits ein anderes System zu erzwingen. Solche Auswüchse politischer Art kommen die Unternehmen teuer zu stehen.
Die Einführung eines Projekt-Management-Systems sollte daher unbedingt mit den Anforderungen aller betroffenen Rollen abgestimmt werden. Das Resultat muss nicht unbedingt ein System für alle sein. In der Praxis haben sich oft integrierte Systeme als gut geeignet erwiesen – etwa ein PM-System für den Fachbereich im Zusammenspiel mit dem ERP-System für das Controlling.
ZUVIEL CONTROLLING
Wieviel Controlling benötigt die Projekt-Management-Welt wirklich? Beziehungsweise wieviel kann sie verkraften? Es steht außer Frage, dass im Rahmen der Planung von Projekten auch die Kosten kalkuliert und das Budget festgelegt werden müssen. Im Laufe der Durchführung sollen das Budget überwacht und die Projektkosten laufend neu geschätzt werden. Aus Unternehmenssicht sind dabei vor allem projektübergreifende Kosten- und Budgetinformationen von Interesse. Eine enge Zusammenarbeit zwischen den Kaufleuten und dem Projektleiter ist damit unabdingbar.
Je nach Stellenwert des Controllings im Unternehmen ist aber oft zu beobachten, dass zu viele kaufmännische Anforderungen in die Welt des Projekt-Managements einfließen. Im günstigsten Fall beschränken sich diese auf bestimmte Aspekte, etwa den Zwang, Projekte kostenbezogen zu strukturieren, was allerdings den Planungsprozess verkompliziert.
Darüber hinaus sind auch Extrembeispiele aus der Praxis bekannt. Dazu zählt folgendes Szenario: Es wurde verlangt, dass die Projektleiter sämtliche Details aus ihrem Projektmanagement-System auch im ERP-System vorhalten müssen. Den Regeln der kostenorientierten Strukturplanung und Projektkostenrechnung sei seitens der Projektleiter Folge zu leisten, so die Begründung, und es müsse jederzeit möglich sein, Projekte nach Belieben im ERP-System weiterzuführen.
Aus technischer Sicht ließ sich das mit entsprechendem Aufwand realisieren; für die tägliche Arbeit wurde das Tool allerdings extrem schwerfällig und kompliziert, bedingt durch den Import zahlreicher Regeln und Restriktionen des ERP-Systems. Die Reaktion ließ nicht lange auf sich warten: Die Projektleiter boykottierten die neue Vorschrift, das Projekt-Management-System wurde in dieser Form nicht mehr verwendet.
Ein Projektleiter ist kein Kaufmann und sollte daher nicht gezwungen sein, wie ein Controller zu planen. Systemtechnisch ist es heutzutage möglich, Lösungen bereitzustellen, die beide Seiten gleichermaßen adressieren. Daten, die Kaufleute und Projektleiter voneinander benötigen, können adäquat aufbereitet und dem jeweils anderen in der richtigen „Sprache“ zur Verfügung gestellt werden.
INTEGRATION UND KOMMUNIKATION
Keine Integration in die Systemlandschaft
Nicht nur im Zusammenhang mit ERP-Systemen wird deutlich, dass sich PM-Werkzeuge mit anderen Unternehmenslösungen verbinden lassen müssen. Projektarbeit besteht nicht nur aus Planungsmethoden im engeren Sinn. Sie betrifft unterschiedliche Rollen im Unternehmen und umfasst auch Themen wie Projektdokumentation, Kommunikation im Team oder Erstellen von Projektangeboten.
Bei der Wahl eines PM-Systems ist somit die Integration in die Systemlandschaft zu beachten. Dazu gehören insbesondere das CRM und das Dokumenten-Management-System sowie die genutzte Portallösung, die „Collaboration“-Plattform und das ERP-System. Proprietäre Lösungsansätze scheitern häufig genau daran: So gut sie funktional auch sein mögen, passen sie nicht in die spezifische Landschaft eines Unternehmens. Aus IT-Management-Sicht bedeutet dies, PM-Werkzeuge als Teil einer umfassenden Softwarestrategie im Unternehmen zu betrachten.
Mangelnde Kommunikation und fehlendes Verständnis
Was haben Projektmitarbeiter beziehungsweise das Unternehmen davon, wenn die geleisteten Stunden im Tool zurückgemeldet werden? Lohnt sich dieser „Extra-Aufwand“ überhaupt? Weshalb muss ein Projektleiter monatliche Statusberichte erstellen? Liest die überhaupt jemand? Allen Benutzern eines neuen Projekt-Management-Tools sollte bei dessen Einführung bewusst sein, welche Vorteile sie selbst und das Unternehmen vom Einsatz des Systems haben. Sobald die Pflege des Tools als unnötig, lästig oder arbeitsverhindernd wahrgenommen wird, sind die Chancen für einen erfolgreichen Einsatz extrem niedrig.
Der Nutzen ist aber nicht immer direkt erkennbar, und manche Tätigkeiten müssen eben einfach sein, etwa die erwähnte Zeitrückmeldung. Umso mehr ist dafür zu sorgen, dass alle beteiligten Rollen das System als Entlastung, Arbeitsverbesserung oder zumindest als sinnvollen Beitrag zum Unternehmenserfolg verstehen.
Am Beispiel der Zeiterfassung lässt sich der Nutzen etwa so begründen, dass Mitarbeiter ihre Zeiten endlich nur in einem Tool und genau einmal erfassen können. Außerdem buchen sie direkt auf die ihnen bekannten Projektaktivitäten. Zudem leisten sie mit ihrer Rückmeldung einen Beitrag zur korrekten Projektabrechnung, was letztendlich der eigenen Abteilung und auch dem Unternehmen zugute kommt. Die Akzeptanz des Systems seitens der Benutzer sichert den Erfolg des Systems nicht nur nach dessen Einführung, sondern auch mittel- und langfristig.
UNTERSTÜTZUNG UND VERANTWORTUNG
Zu wenig Unterstützung vom Management
Dieselben Manager, die sich zuvor für das besagte Werkzeug entschieden hatten, können dieses verkümmern lassen. Wie das passieren kann? Man arbeitet mit den alten Gewohnheiten, liest die Berichte nicht, ignoriert Eskalationen aus dem System und trifft die Entscheidungen wie gewohnt und nicht auf Basis der Tool-Informationen. Den Daten im System wird nicht vertraut, und statt eine solide Informationsbasis einzufordern, werden alte Arbeitsweisen weitergelebt.
Dabei besteht einer der größten Vorteile unternehmensweiter Projekt-Management-Tools in den übergreifenden Projektberichten und der Unterstützung von Management-‚Entscheidungen, etwa für Budgets oder Projektportfolios. Seitens des Managements muss das System genutzt werden. Zudem ist dessen permanente Pflege, auch mit Sanktionen, einzufordern.
Ungeklärte Verantwortung für das Tool
Geneigte Nutzer, Unterstützung des Managements, Berücksichtigung der Belange aller Beteiligten sowie ein sinnvolles Zusammenspiel mit dem Controlling – das sind die besten Voraussetzungen für eine erfolgreiche Systemeinführung. Doch wer zeichnet verantwortlich für die Pflege des Tools? Wer sorgt sich zum Beispiel um die ständiger Veränderung unterliegenden Stammdaten. Wer erstellt neue Vorlagen? Wer ändert die Workflows gemäß den angepassten Prozessen und aktualisiert die Berichte? Wer organisiert das Einspielen von Software-Updates?
Ähnlich einem ERP-System ist ein Projekt-Management-Tool ein zentrales Werkzeug, das der permanenten Pflege und Anpassung bedarf. In der Praxis wird das gern mal übersehen. Die Pflege landet dabei oft in der IT, wodurch die technischen Aspekte abgedeckt werden, aber nicht die methodischen.
Besteht im Unternehmen ein Projekt-Management-Office, kurz PMO, so ist das genau die richtige Adresse für die Pflege des Systems. Es zeichnet nicht nur verantwortlich für die Entwicklung und Implementierung von Methoden und Prozessen, sondern auch für das entsprechende Projekt-Management-Werkzeug. Wie ein PMO konkret aufgebaut und in die Organisation eingebunden wird, ist vom Unternehmen abhängig. In jedem Fall trägt es aber die Verantwortung für PM-Werkzeuge und deren Schnittstellen – und damit ist es eine der wesentlichen Voraussetzungen für den erfolgreichen Einsatz der Projekt-Management-Systeme.
* Stavros Georgantzis ist Gründer, Geschäftsfüher und Partner von The Project Group in München. Der Artikel stammt von der deutschen Computerwoche.