Tool-Evaluierung – von der Kunst, die richtige PM-Software zu finden

PM Toolfinder

Kaum jemand mag darüber sprechen und doch geschieht es immer mal wieder: PM-Implementierungsprojekte werden nach einem schwungvollen Start still und leise eingestellt oder – schlimmer – die Software ist nach dem Rollout zwar auf den Rechnersystemen vorhanden, aber kaum jemand verwendet sie. Thomas Brunschede, Le Bihan Consulting, öffnet den Vorhang für einen Blick hinter die Kulissen: Was sind neben den bekannten Kriterien die ungeschriebenen Regeln für eine gelingende Softwareeinführung?

Tool-Evaluierung – von der Kunst, die richtige PM-Software zu finden

PM Toolfinder

Kaum jemand mag darüber sprechen und doch geschieht es immer mal wieder: PM-Implementierungsprojekte werden nach einem schwungvollen Start still und leise eingestellt oder – schlimmer – die Software ist nach dem Rollout zwar auf den Rechnersystemen vorhanden, aber kaum jemand verwendet sie. Thomas Brunschede, Le Bihan Consulting, öffnet den Vorhang für einen Blick hinter die Kulissen: Was sind neben den bekannten Kriterien die ungeschriebenen Regeln für eine gelingende Softwareeinführung?

Herr Brunschede, welches Vorgehen empfehlen Sie Unternehmen, die eine PM-Software einführen wollen?

Unsere erste Empfehlung: Beginnen Sie nicht mit der Anforderungsanalyse! Auch wenn das eine sehr weit verbreitete Vorgehensweise ist. Viel wichtiger ist es, von Anfang an ein professionelles Stakeholder-Management zu etablieren. Denn Sie werden mit Widerstand rechnen müssen, und der kann zu einem regelrechten "Showstopper" anwachsen. Es kristallisieren sich immer wieder zwei Hauptmotive für Widerstand heraus: Das eine ist die Angst vor negativen Effekten wie z.B. unerwünschter Transparenz. Und das andere ist fehlende Partizipation: Wer das Gefühl hat, nicht gefragt worden zu sein, wird eher blockieren als unterstützen. Das ist alles ja gar nicht so neu und unbekannt. Aber unsere Erfahrung zeigt, dass Stakeholder-Management in der Praxis deutlich zu oberflächlich betrieben wird.

Wenn gleich von Anfang an große Widerstände erkennbar sind, muss man da manchmal nicht erst einmal die Unternehmenskultur ändern?

Das klingt gut, aber unsere Gegenfrage auf solche Ansätze lautet: Was machen Sie in der Zwischenzeit? Eine Kultur kann man ja nicht innerhalb von drei, vier Monaten ändern, das dauert erfahrungsgemäß sehr viel länger.

Also besser parallel fahren?

Ja, richtig. Vor allem dann, wenn die Unternehmenskultur defizitär ist, ist es wichtig, mit Widerständen adäquat umgehen zu können. Wir haben – teilweise in Zusammenarbeit mit Hochschulen und Wissenschaftlern – bestehende Methoden auf den Prüfstand gestellt, verändert und ergänzt sowie neue Methoden entwickelt. Das Ergebnis ist ein Toolset mit meist sehr pragmatischen Ansätzen, um ein Stakeholder-Management betreiben zu können, das diesen Namen auch verdient.

Was folgt als nächster Schritt? Sind wir nun bei der Anforderungsanalyse?

Nein, noch immer nicht. Wenn ein Unternehmen sein Projektmanagement verbessern will, dann geht es ja nicht nur um die Software und die Anforderungen, die daran gestellt werden. Es geht darum, Organisation, Methoden, Prozesse, Menschen – und natürlich auch Software – miteinander in Einklang zu bringen. Vor allem die Prozesse sind ein zentrales Thema. In den meisten Unternehmen existieren Prozessbeschreibungen, aber nicht selten haben diese beinahe schon den Charakter eines abstrakten Gemäldes: Sie sind unscharf gezeichnet, hängen an der Wand, werden nicht gelebt und haben eher eine künstlerische Qualität, als dass man mit ihnen arbeiten könnte. Andererseits: Es kommt nicht darauf an, formvollendete Prozesslandkarten zu entwickeln. Wichtig ist aber, dass den Akteuren bekannt ist, wie wirklich gearbeitet wird.

Warum empfehlen Sie, eine Prozessanalyse der Anforderungsanalyse voranzustellen?

Der Prozess übernimmt der Anforderung gegenüber eine Art Masterfunktion. Die Anforderung wird quasi an ein Prozesselement "geheftet". Zum einen wird dadurch deutlich, wie die konkrete Abbildung eines Prozesses durch Software aussieht. Andererseits kann eine Anforderung so auf Plausibilität überprüft werden: Ordnet man jede Anforderung konsequent einem Prozesselement zu, wird bei Auftauchen einer neuen Anforderung, deutlich, ob eine Überschneidung mit bereits bestehenden Anforderungen oder eine andere Plausibilitätsstörung vorliegt.

Wenn Prozess und Anforderungen niedergelegt sind, wie findet man nun die Software, die diese am besten erfüllt?

Der klassische Ansatz geht ja davon aus, dass zunächst einmal Prozess und Anforderungen betrachtet werden. Erst dann kommt die Dimension "Software" ins Spiel. In der Praxis sind diese Ebenen aber miteinander verwoben, und wir empfehlen, bereits bei der Analyse der Prozesse und Anforderungen die spätere Umsetzung in Software angemessen zu berücksichtigen. Das bedeutet konkret, entsprechende Kompetenzträger von Anfang an mit ins Boot zu nehmen. Das hat vor allem zwei positive Effekte: Man kann den Prozess so gestalten, dass er nah an Software-Standards implementiert werden kann. Das wirkt sich enorm kostensparend aus – nicht nur bei der initialen Investition, sondern auch im Nachhinein, allein wenn Sie an das Thema Wartung und Migration denken. Der zweite Aspekt ist der Prototyp-Effekt: Kaum jemand kann sich "auf der grünen Wiese" ein komplettes PM-System vorstellen oder es gar beschreiben. Wenn wir einen Kunden beraten, dann zeigen wir von Anfang an spätere Umsetzungsmöglichkeiten direkt in der Software auf. Dadurch kommt eine völlig andere Qualität in die Diskussion. Außerdem sind die in der Software abgebildeten Standardprozesse ja oft Best Practice: Man muss das Rad nicht immer neu erfinden. Die passende Software finden wir dann über eine eigens hierfür entwickelte Plattform, den PM Toolfinder. Wir arbeiten dort mit einem Partner zusammen, der marktführend in Deutschland ist und europaweit eine der größten Evaluierungsplattformen betreibt. Dort sind die Merkmale der verschiedenen Softwareprodukte hinterlegt, und wir können auf dieser Basis mit einem Höchstmaß an Objektivität die passenden Hersteller herausfiltern.

Was sind nach Ihrer Erfahrung die größten Fehler, die in der Tool-Evaluierung gemacht werden?

Kunden erleben häufig, dass in der Präsentation alles funktioniert und toll aussieht, doch später stellt sich heraus, dass die Realisierung bei weitem nicht so einfach ist, wie es in der Präsentation vermittelt wurde. Einer der Hauptgründe liegt unserer Erfahrung nach darin, dass Hersteller in Präsentationen nicht immer durchgängige Konzepte verwenden.

Haben Sie dazu ein Beispiel?

Nehmen Sie das Ressourcenmanagement. Der Hersteller demonstriert vielleicht, wie bereits in der Ideenphase die zur Verfügung stehende Kapazität im Falle einer späteren Realisierung berücksichtigt werden kann. Eine solche, meist generische Ressourcenplanung ist aber nicht immer sauber mit dem späteren operativen Ressourcenmanagement verknüpft. Das bedeutet: Wenn es zum Projekt kommt, muss der Benutzer mit der Ressourcenplanung wieder von vorne beginnen. Er kann nicht auf der bestehenden Planung aufbauen. Der Grund für diese fehlende Durchgängigkeit liegt oft in der Programmierweise: Software-Hersteller haben ein Kernsystem, an das sie später dann weitere Funktionalitäten "anflanschen". Das Software-Gebäude wird dabei nicht immer sauber vergrößert, sondern lediglich um entsprechende "Balkone" ergänzt. Das spart Entwicklungskosten, kann aber gerade bei einer Vielzahl von Balkonen zu großen Problemen führen. Die Durchgängigkeit der von den Herstellern verwendeten Konzepte zu prüfen, ist eine der schwierigsten Aufgaben bei einer Evaluierung, aber auch eine enorm wichtige.

Welche anderen Dinge kann das Unternehmen tun, um die richtige Entscheidung zu treffen?

Es ist hilfreich, wenn die späteren Benutzer im Rahmen von Hands-on-Workshops selbst mit der Software arbeiten, anstatt nur jemandem zuzuschauen, der alle Tricks und Fallen kennt. Und bei Unklarheiten ist es wichtig, auch einmal ein wenig hartnäckiger nachzuhaken und nicht zu früh zufrieden zu sein. Ein gesundes Misstrauen ist empfehlenswert! Bei der späteren Umsetzung raten wir zu einer Politik der kleinen Schritte. Der "Big Bang" ist meist nicht wirklich gut realisierbar. Bei kleinen Schritten kann deutlich besser nachjustiert werden.

Apropos Entscheider: Wer gehört mit ins Team?

Wichtig ist, dass sowohl Entscheider und Management mit dabei sind als auch die wirklichen Anwender, die Power User aus der Praxis. Da kann es durchaus unterschiedliche Interessen geben. Möglicherweise punktet bei den Anwendern eine Software am meisten, die funktional gar nicht am besten abgeschnitten hat. Usability kann wichtiger sein als die Nähe zum Prozess. Manche Hersteller bieten zudem bewusst das an, was
die Entscheider im Management gerne sehen, also z.B. ein schickes Dashboard. Das kommt dann vielleicht auf dieser Ebene gut an, aber nicht zwangsläufig bei denen, die es befüllen sollen. Diese unterschiedlichen Anforderungen müssen gut aufeinander abgestimmt werden, denn hier werden die Weichen für die spätere Akzeptanz der Lösung gestellt.

Wenn ein Unternehmen stark zwischen zwei Anbietern schwankt, wie viel prototypische Umsetzungen sollte und kann es von den Herstellern erwarten?

Sich anzusehen, wie Hersteller relevante Anforderungen konkret umsetzen, kann natürlich sehr hilfreich sein. Die Frage der Bezahlung ist dabei oft etwas heikel: Manche Unternehmen setzen die Hersteller unter Druck und erwarten viele individuelle Leistungen, ohne dafür zahlen zu wollen. Wir haben die Erfahrung gemacht, dass die erfolgreichen Einführungen diejenigen waren, bei denen es ein faires Miteinander zwischen Kunde und Hersteller bzw. Implementierungspartner gab. Nur dann kleben nicht beide Seiten an schriftlich fixierten Spezifikationen und Vertragsbestandteilen, sondern sind an einer echten Lösung interessiert.

 

Herr Brunschede, vielen Dank für das Gespräch!

 

Das Interview führte Elisabeth Wagner

Bewertungen und Kommentare

(nur angemeldete Benutzer)

Diese Funktion steht nur eingeloggten Nutzern zur Verfügung. Jetzt einloggen
Gesamt
Bewertungen 1
Alle anzeigen