Projektorientierte Softwareeinführung: Anpassung nach Erfahrung

Die Wahl der passenden Strategie ist ein entscheidender Schritt auf dem Weg zur erfolgreichen Softwareeinführung. Die projektorientierte Softwareeinführung ist eine Variante der iterativen, also schrittweisen Softwareeinführung. Ein kleines Projektteam nutzt die neue Software zunächst in einem unternehmenstypischen Projekt. Im besten Fall war das Projektteam an der Softwareauswahl beteiligt und steht neuen Prozessen nicht nur offen gegenüber, sondern treibt diese als Tiger Team voran. Da das Projektteam eine überschaubare Größe hat, ist es flexibel und muss nicht viel Zeit in die Vorbereitung des Testprojekts investieren.

Möglichst noch während dem Projektverlauf wird die Software an die firmenspezifischen Prozesse angepasst und Richtlinien für den Einsatz in künftigen Projekten definiert. Hierbei wird auch entschieden, ob die Software und die angepasste Konfiguration noch in einem zweiten Testprojekt erprobt werden soll oder ob die Nutzung gleich auf alle Projekte und Abteilungen des Unternehmens ausgeweitet werden kann.

Sofern sich die Projekte des Unternehmens stark ähneln, beispielsweise wenn es sich immer um Softwareentwicklung im Kundenauftrag handelt, können nach dem erfolgreich abgeschlossenen Testprojekt alle zukünftigen Projekte mit der neuen Software beginnen. Es ist auch möglich, ein zweites Testprojekt zu starten, während das erste Projekt noch läuft, aber es ist wichtig sicherzustellen, dass genügend Zeit vergeht, damit die Lektionen aus den einzelnen Projektphasen für das zweite Testprojekt genutzt werden können.

Wenn die Projekte sehr unterschiedlich sind, sollte nach dem Start des ersten Testprojekts und den ersten Erfahrungen auf jeden Fall ein zweites Testprojekt gestartet werden. Softwareentwicklung im Kundenauftrag erfordert als externes Projekt schließlich gänzlich andere Projektstrukturen, -führung und -dokumentation als sie beispielsweise ein internes Marketingprojekt zur Mitarbeiterbindung benötigt. In diesem Fall ist auch ein gleichzeitiger Projektstart kein Problem. Für ein internes Testprojekt ist es beispielsweise nicht möglich, Verbesserungsvorschläge zu Themen wie Business Case, Risiken, Angeboten, Kundenkommunikation oder Abrechnung aus einem Testprojekt mit Kundenbezug umzusetzen.

Als Testprojekt für die projektorientierte Softwareeinführung bietet sich ein Projekt an, das unternehmenstypische Prozesse beinhaltet und dessen Scheitern im Ernstfall keine weitreichenden oder schwerwiegenden Folgen hätte. Die Abbruchkosten wären gering. Daher empfiehlt sich die projektorientierte Einführungsstrategie insbesondere bei einem unsicheren Projektumfeld.

Ist die Motivation der Mitarbeiter noch gering und stehen sie der neuen Software kritisch gegenüber, empfiehlt sich die projektorientierte Methode besonders. Hat das Tiger Team beim Testprojekt Erfolg, promoted es die Vorzüge der neuen Software intern und steigert so die Motivation der gesamten Belegschaft bottom-up. Da die erste Iteration diese Signalwirkung hat, ist es umso wichtiger, ein geeignetes Projekt und vor allem ein inital bereits motiviertes Tiger Team auszuwählen. Der Multiplikatoreneffekt kann sich nämlich auch gegensätzlich auswirken, falls das Tiger Team keine guten Erfahrungen machen konnte und damit die Motivation der übrigen Mitarbeiter noch weiter senkt.

Diese projektorientierte Strategie eignet sich nicht gut, wenn Projekte über das zentrale PMO geführt werden. In diesem Fall sind gegebenenfalls doppelte Aufwände für die Pflege der Projektdaten im alten System notwendig, damit das projektübergreifende Ressourcenmanagement und Projektcontrolling für das PMO möglich ist. Gegebenenfalls müssten sogar temporäre Schnittstellen zur alten Software erstellt werden, um ein lückenloses Projektcontrolling zu ermöglichen. Dies wäre unnötig zeit- und kostenintensiv.

Da die Einführungsdauer von der Dauer des Testprojektes abhängt, sollte dieser Ansatz nicht bei Projekten mit hoher Laufzeit, zum Beispiel konzernweiten ERP-Einführungen, genutzt werden. Da zu Beginn der Einführung noch nicht klar ist, ob ein zweites oder gegebenenfalls noch weitere Testprojekte notwendig sind, ist ein Einführungsprojekt nach der projektorientierten Softwareeinführung nicht exakt terminierbar. Ein sehr enger oder erzwungener Zeitplan fürs Einführungsprojekt machen die Anwendung der projektorientierten Einführung unmöglich und lässt nur noch die Option zur Einführung per Big-Bang-Methode offen.

Ihre Rahmenbedingungen sind nicht optimal für die Anwendung der projektorientierten Softwareeinführung? In diesem Fall bietet sich Ihnen eine Fülle weiterer Optionen:

Die projektorientierte Softwareeinführung ist ein praxisorientiertes Konzept, eine neue Software im Unternehmen einzuführen. Die Strategie eignet sich besonders gut für Unternehmen, bei denen die Projekte ähnlich strukturiert sind und die neue Software direkt anhand der Erfahrungen des Praxiseinsatzes angepasst werden soll. Bei sehr unterschiedlichen Projekten ist ein zweites Testprojekt empfehlenswert, um sicherzustellen, dass die Software an die spezifischen Anforderungen angepasst wird.

Bei großen, langfristigen Projekten, wie konzernweiten ERP-Einführungen, ist die projektorientierte Softwareeinführung nicht empfehlenswert. Zudem kann die projektorientierte Einführung sich als problematisch erweisen, wenn Projekte über das zentrale PMO geführt werden.