Vom Tool zur Lösung – von der Kunst, die richtige PM-Software zu finden

Haifisch StrasseKaum jemand mag darüber sprechen und doch geschieht es immer mal wieder: Projektmanagement-Software-Projekte 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. Mitarbeiter, die für die Einführung einer Software verantwortlich sind, leben potentiell gefährlich. Vor allem, wenn es sich um Projektmanagement-Software handelt.

Das Webinar von Thomas Brunschede, Geschäftsführender Gesellschafter der Le Bihan Consulting GmbH, ermöglicht Ihnen einen Blick hinter die Kulissen. Was hat sich bewährt, und welches sind die ungeschriebenen Regeln für eine erfolgreiche Softwareeinführung?

Anzeige

Die Einführung einer Projektmanagement-Software ist in aller Regel mit hohen Investitionssummen verbunden. Allein schon deshalb stehen die Verantwortlichen unter einem enormen Erfolgsdruck. Eine besondere Herausforderung dabei: Die Erfahrung, die Sie nach Abschluss einer solchen Einführung haben werden, benötigten Sie eigentlich bereits zu Beginn des Projekts. Aus diesem Grund werden gerne Berater mit an Bord geholt, die das Einführungsprojekt begleiten sollen. Allerdings endet deren Unterstützung meist mit dem Ende der Softwareevaluierung. Hier wird häufig unterschätzt, dass die anschließende technische Implementierung für Unternehmen besonders erfolgskritisch ist. Doch selbst wenn es zum Rollout kommt, ist das noch lange keine Garantie für eine halbwegs angemessene Lebensdauer der neuen Software.

Worin liegen die Ursachen für ein derart beständig wiederkehrendes Scheitern? 

Die meisten Einführungsprojekte laufen sequentiell ab: Erst das Konzept, dann die Umsetzung. Irgendein Softwarehersteller wird sich schon finden, der die in der Konzeptphase entwickelten Prozesse implementieren kann. Bei einem solchen Vorgehen bleibt jedoch wichtiges Know-how unberücksichtigt: Ohne das Wissen um gängige Standards von PM-Softwarelösungen ist die Gefahr groß, Prozesse auf der „grünen Wiese“ zu definieren – oftmals sehr weit entfernt von ebendiesen Standards. Welcher Softwareanbieter wird während einer Präsentation schon freudestrahlend verkünden, dass er sich mit einem solchen Prozess überfordert sieht? Tut sich zwischen dem Sollprozess und seiner Realisierung ein Graben auf, wird dieser meist erst während der technischen Implementierung entdeckt.

Das ließe sich vermeiden, würde die Umsetzung von Anfang an in den Fokus genommen. Konkret bedeutet das, entsprechende Kompetenzträger mit ins Boot zu holen. Dies hat vor allem zwei positive Effekte: Man kann den Prozess so gestalten, dass er nah an Software-Standards implementiert werden kann. Das wirkt sich in der Regel enorm kostensparend aus – nicht nur bei der initialen Investition, sondern auch in Bezug auf Folgekosten durch Wartung und Migration. 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. Werden in der Konzeptphase hingegen die späteren Umsetzungsmöglichkeiten direkt in der Software aufgezeigt, kommt eine völlig neue Qualität in die Diskussion. Außerdem sind die in der Software abgebildeten Standardprozesse fast immer Best Practice: Es gibt keinen Grund, das Rad immer wieder neu zu erfinden.

Prozesse und Anforderungen

Prozesse sind in der Konzeptphase eines Einführungsprojekts ein zentrales Thema. In den meisten Unternehmen existieren Prozessbeschreibungen, manchmal auch Prozesslandkarten genannt, und nicht selten haben sie den Charakter eines abstrakten Gemäldes. Es kommt nicht darauf an, formvollendete Prozesslandkarten zu entwickeln. Wichtig ist, dass den Akteuren bekannt ist, wie wirklich gearbeitet wird.
Der Prozess sollte der Anforderung gegenüber eine Art Masterfunktion übernehmen. Die Anforderung wird quasi an ein Prozesselement “geheftet”. Zum einen wird dadurch deutlich, wie die konkrete Abbildung eines Prozesses 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.

Fallstricke bei der Tool-Evaluierung

Nachdem Prozesse und Anforderungen – gespiegelt an den Realisierungsmöglichkeiten gängiger Softwarestandards – definiert sind, betreten die Toolanbieter die Bühne. Ihr größtes Anliegen ist es, eine größtmögliche Übereinstimmung zwischen den Kundenanforderungen und der eigenen Software zu suggerieren. Doch nicht jede auf den ersten Blick beeindruckende Übereinstimmung überdauert den Moment ihrer Präsentation: Kunden erleben häufig, dass in der Präsentation alles funktioniert und gut aussieht, erst später stellt sich dann heraus, dass die Realisierung bei weitem nicht so einfach ist, wie es in der Präsentation vermittelt wurde. 

Die Realiserungsphase

Bei der späteren Umsetzung hat sich eine Politik der kleinen Schritte bewährt. Der “Big Bang” ist kaum praxisnah. Bei kleinen Schritten dagegen kann deutlich besser nachjustiert werden – idealerweise auf der Basis einer guten Zusammenarbeit zwischen Kunde und Softwarelieferant. Die erfolgreichsten Einführungen sind erfahrungsgemäß diejenigen, bei denen es ein faires Miteinander zwischen Kunde und Hersteller bzw. Implementierungspartner gibt. Nur dann kleben nicht beide Seiten an schriftlich fixierten Spezifikationen und Vertragsbestandteilen, sondern sind an einer echten Lösung interessiert. 

Hier geht es zur Anmeldung für das kostenlose Webinar: “Vom Tool zu Lösung – Die Kunst, die richtige Projektmanagement-Software zu finden”. 
 

 

Anzeige

Weitere Artikel

Newsletter
Newsletter Box

Mit Klick auf den Button "Jetzt Anmelden" stimme ich der Datenschutzerklärung zu.