Projektmanagement bei der CRM-Einführung
Scrum oder Wasserfall - eine Gegenüberstellung
Längst setzen nicht nur Startups, sondern auch Großunternehmen auf Scrum, Kanban und Co. Wo bei der Einführung von CRM-Software agile Methoden auftrumpfen und wo klassisches Projektmanagement schlägt, zeigt diese Gegenüberstellung.
Klassisches Projektmanagement steht gegenüber agilen Methoden zuweilen im Ruf, starr und behäbig zu sein und in längere Projekte zu münden. Bei der Einführung von Software folgen beide Methoden einer unterschiedlichen Logik und haben ihre Vor- und Nachteile. Folgender Check bietet eine praxisorientierte Entscheidungshilfe, welche Methode für welches Projekt geeignet ist.
Kosten klassischer Projekte
Bei der klassischen Einführungsmethode wird eine Software konzipiert, entwickelt und ausgeliefert und später durch kleinere Releases angepasst. Dieses sogenannte Wasserfall-Modell bietet auf den ersten Blick Kostensicherheit: Aufgrund der detaillierten Softwarespezifikation schätzt der CRM-Integrator ab, wie viele Manntage zur Entwicklung nötig sind. Daraus ergeben sich die Kosten für die Einführung. Doch bei umfangreichen CRM-Projekten kommt es in der Praxis laufend zu Änderungen. Müssen Prozesse vielleicht doch anders gestaltet werden? Passt das CRM auch noch zum Unternehmen, wenn sich in der Zukunft die Strukturen ändern? Kommen solche Fragen im Projekt auf, sollten sie ernstgenommen werden. Um jeden Preis an der ursprünglichen Spezifikation festzuhalten, kann sich negativ auf die Anwenderakzeptanz auswirken. Muss die Spezifikation angepasst werden, ändert sich der Aufwand und die Kostensicherheit ist dahin, wenn keine ausreichenden Puffer eingeplant wurden. Deshalb gilt im klassischen Projekt: Die Kosten sind kalkulierbar, sofern Veränderungen während der Umsetzung den eingeplanten Rahmen nicht übersteigen. Gerade bei großen Projekten ist das jedoch häufig der Fall.
Kosten agiler Projekte
Definierte Festpreise sind nichts für das agile Projekt. Starre Vorgaben widersprechen ganz klar dem Wesen der Agilität. Ein Entwicklerteam des Software-anbieters passt die Software schrittweise an individuelle Anforderungen unterschiedlicher Abteilungen an. Den Arbeitsaufwand für die jeweiligen Bereiche ermittelt das Projektteam im Grobkonzept. In der Praxis werden Entwicklungsschritte in überblickbare Zeiträume gegliedert, etwa mit 20 Manntagen pro Schritt. So strukturierte Bereiche können preislich besser kontrolliert werden. Das bietet zwar keine garantierte Kostensicherheit, Projektverantwortliche können den Aufwand dennoch einschätzen, weil die aktuellen Anforderungen gemeinsam erarbeitet und angepasst werden. Das beugt dem Risiko teurer Fehlentwicklungen vor. Die Gefahr beim agilen Projekt besteht jedoch an ganz anderer Stelle, denn oft kommt der Appetit beim Essen: Dann werden erste Bereiche sehr gut angepasst, es werden viele Funktionen umgesetzt, die 'nice to have' sind, aber eigentlich nicht vorgesehen waren. Das Problem besteht dann darin, dass die weiteren Bereiche aus Kostengründen nicht entsprechend der eigentlichen Planung umgesetzt werden können - oder nur mit einem höheren Kostenaufwand.
Der Faktor Zeit
Aufgrund ihrer Logiken folgen klassische und agile Projektmanagement-Methoden unterschiedlichen Zeitplänen. Ist der zeitliche Rahmen vorgegeben, etwa weil die neue Lösung für ein Kundenprojekt benötigt wird, wird der Zeitplan oft zum wichtigsten Entscheidungskriterium.
Bei klassischen Projekten
Die Software konzipieren, entwickeln, ausliefern und kleinere Anpassungen vornehmen: So sieht der Ablauf bei der traditionellen Einführungsmethode aus. Für das Projektteam bedeutet das eine starke zeitliche Belastung zu Beginn des Projekts. Schließlich definieren die Beteiligten hier die Anforderungen, die Prozesse, das Lastenheft und die Spezifikation. Während der Umsetzung des Projekts ist der Aufwand für das Projektteam dann eher gering, bevor es vor Ende des Projekts wieder in eine heiße Phase geht: Das Testen der Lösung, eventuelle Änderungen und Schulungen stehen dann an und nehmen einiges an Zeit in Anspruch. Der Aufwand für das Unternehmen ist bei klassischem Vorgehen also punktuell bei der Konzeption und Auslieferung hoch, dazwischen geringer.
Bei agilen Projekten
Die agile Methode geht iterativ vor. Auf Basis von Workshops wird in kurzer Zeit ein Prototyp entwickelt. Dieser deckt die Grundanforderungen weitgehend ab. Weitere Anforderungen werden Schritt für Schritt in Workshops definiert und anschließend umgesetzt. Die Mitarbeiter sind so von Beginn an aktiv und dauerhaft eingebunden. Dadurch ist die agile Methode zeitintensiv und verlangt die stetige Mitarbeit des Teams. Das muss allen Beteiligten im Vorfeld klar sein. Die Geschäftsleitung muss den Teammitgliedern die entsprechende Zeit zur Verfügung stellen. Der Vorteil: Weil Mitarbeiter die neue Lösung schrittweise testen und nutzen, ist die Akzeptanz der Software besonders hoch. So kann eine agile Methode für komplexe Projekte mit engem Zeitrahmen besser geeignet sein. Vom Projektteam ist wegen der häufigen kurzen Abstimmungsphasen - im Gegensatz zum klassischen Weg - eine stetige Mitarbeit erforderlich.
Lastenheft vorhanden
Existiert bereits ein detailliertes Lastenheft in dem die Zielprozesse definiert sind, stehen grundsätzliche beide Projektmanagement-Methoden offen. Tendenziell geht es mit der klassischen Variante dann aber schneller ans Ziel.
Grobe Anforderungsdefinition
Anders sieht es aus, wenn es erst ein grobes Lastenheft gibt, noch nicht alle Anforderungen definiert werden konnten oder Prozesse noch nicht klar sind. Ist der Zeitplan eng, dürfte dies häufig die Ausgangslage sein. Hier kann der Vorteil beim agilen Vorgehen liegen: Detailanforderungen werden iterativ gemeinsam in Workshops erarbeitet. Die Teilnehmer profitieren dabei vom Vorwissen aus dem Projekt. Die so gemeinsam erarbeitete Lösung wird für die Projektteilnehmer greifbarer.
An die Anwender denken
Bleiben diejenigen, die am Ende mit der Lösung arbeiten, bei der Entscheidung außen vor, kann das gravierende Folgen haben. In punkto Anwenderakzeptanz liegt der Vorteil beim agilen Projekt, denn die Anwender kommen Stück für Stück in Berührung mit der neuen Software, lernen diese kennen und sind stärker eingebunden. Beim klassischen Projektmanagement kommen die Anwender erst bei der Auslieferung mit der neuen Software in Kontakt - gerade in eher traditionell geprägten Unternehmen stößt die Lösung dann oft auf Ablehnung. Im Nachgang für Akzeptanz zu sorgen, kostet unter Umständen dann mehr Zeit und Geld, als vorher eingespart werden konnte.
Längst setzen nicht nur Startups, sondern auch Großunternehmen auf Scrum, Kanban und Co. Wo bei der Einführung von CRM-Software agile Methoden auftrumpfen und wo klassisches Projektmanagement schlägt, zeigt diese Gegenüberstellung.
Klassisches Projektmanagement steht gegenüber agilen Methoden zuweilen im Ruf, starr und behäbig zu sein und in längere Projekte zu münden. Bei der Einführung von Software folgen beide Methoden einer unterschiedlichen Logik und haben ihre Vor- und Nachteile. Folgender Check bietet eine praxisorientierte Entscheidungshilfe, welche Methode für welches Projekt geeignet ist.
Kosten klassischer Projekte
Bei der klassischen Einführungsmethode wird eine Software konzipiert, entwickelt und ausgeliefert und später durch kleinere Releases angepasst. Dieses sogenannte Wasserfall-Modell bietet auf den ersten Blick Kostensicherheit: Aufgrund der detaillierten Softwarespezifikation schätzt der CRM-Integrator ab, wie viele Manntage zur Entwicklung nötig sind. Daraus ergeben sich die Kosten für die Einführung. Doch bei umfangreichen CRM-Projekten kommt es in der Praxis laufend zu Änderungen. Müssen Prozesse vielleicht doch anders gestaltet werden? Passt das CRM auch noch zum Unternehmen, wenn sich in der Zukunft die Strukturen ändern? Kommen solche Fragen im Projekt auf, sollten sie ernstgenommen werden. Um jeden Preis an der ursprünglichen Spezifikation festzuhalten, kann sich negativ auf die Anwenderakzeptanz auswirken. Muss die Spezifikation angepasst werden, ändert sich der Aufwand und die Kostensicherheit ist dahin, wenn keine ausreichenden Puffer eingeplant wurden. Deshalb gilt im klassischen Projekt: Die Kosten sind kalkulierbar, sofern Veränderungen während der Umsetzung den eingeplanten Rahmen nicht übersteigen. Gerade bei großen Projekten ist das jedoch häufig der Fall.
Adito Software GmbH
Dieser Artikel erschien in IT&Production Juli+August 2019 - 18.07.19.Für weitere Artikel besuchen Sie www.it-production.com