Wie funktionieren agile Marketingprojekte? Und kann SCRUM Flexibilität und Sicherheit wirklich verbinden? Wir klären in unserem Blog auf!
Über ein Drittel aller Projekte werden nicht in der geplanten Zeit, dem vorgegebenen Budget oder mit dem erwarteten Ergebnis abgeschlossen. Von diesen Projekten wiederum wird ein weiteres Drittel als gescheitert angesehen und das Budget komplett abgeschrieben – Das sind die traurigen Ergebnisse einer Umfrage des Global Project Management Survey von PIM.
Warum scheitern so viele Projekte? Drei Erkenntnisse vorweg: Die Projektpläne sind oft zu starr, das Umfeld und die Anforderungen hingegen sind häufig zu volatil und die Projektmanagementmethode passt nicht zu den vorhandenen Gegebenheiten.
Kein Wunder also, dass in den letzten Jahren unterschiedliche agile Projektmanagement-Verfahren entwickelt wurden, denn diese versprechen eine erfolgreiche Kombination aus maximaler Flexibilität und einem erfolgreichen Projektabschluss. Dass hier ein Bedürfnis gestillt wurde, zeigt auch das nachfolgende Schaubild zum wachsenden Trend von SCRUM Modellen.
Bei jeder Projektumsetzung (egal ob klassisch oder agil) spielen die drei Faktoren des magischen Dreiecks eine wesentliche Rolle:
Hinzu kommt das Erwartungsmanagement der Stakeholder, die den Auftrag für das Projekt vergeben und das gewünschte Zielbild definieren.
Doch wo liegt der Unterschied der beiden Ansätze, wenn sie die gleichen originären Rahmenbedingungen haben bzw. die gleichen Faktoren zusammenspielen? Die Antwort: In den variablen und fixen Projektfaktoren!
Zudem unterscheiden sich agile und klassische Methoden sowohl in der Vorgehensweise während des Projekts als auch im Ergebnis.
Bei der Betrachtung des Wasserfall-Modells – eines der bekanntesten klassischen Ansätze – wird ersichtlich, wie starr die Projektumsetzung ist. Hier muss zuerst jede Phase vollständig durchlaufen werden, bevor sie erfolgreich abgeschlossen werden kann. Streng genommen führen Anforderungsänderungen im Umfeld immer zurück zum Neustart der Konzeptionsphase, also zur Überarbeitung des Lastenhefts und der Neuauflage des Pflichtenhefts. Die im Lastenheft aufgeführten Anforderungen sind in der Regel nach dem MusCoW-Prinzip priorisiert. Die sogenannten Must-Kriterien sind unbedingt zu erfüllen, um das Produkt oder Projekt abnehmen zu können. Could- und erst recht Would-Kriterien fallen insbesondere bei Zeit- und Budgetmangel hinten unter.
Diese Fokussierung und Versteifung auf bestimmte Kriterien ist wichtig, wenn Standards oder Regularien zu erfüllen sind. Für ein Produkt, dessen endgültige Gestalt noch nicht feststeht oder dessen Rahmenbedingungen sich fortlaufend ändern, ist diese Gliederung hingegen hinderlich. Zudem verlängert es den Zeitraum, bis zu dem das Produkt als solches genügend vollständig und begreifbar ist, sodass der Auftraggeber Feedback geben kann.
Die SCRUM Methode verzichtet natürlich nicht auf ein geregeltes Anforderungsmanagement, rückt aber die eigentliche Produkt-Funktion in den Mittelpunkt und lässt den Weg dorthin offen. Diesen Weg soll das Projektteam selbstständig mit den ihm zur Verfügung stehenden Ressourcen finden und dabei größtmögliche Freiheiten in der Ausgestaltung haben, um Kapazitäten effizient zu nutzen. Gefördert wird dieser Ansatz durch das sogenannte Minimum Valuable Product (MVP). Dieses erlaubt in der ersten Release-Stufe ein Produkt, das bereits wesentliche Funktionen beinhaltet, aber noch keine Marktreife erreicht haben muss. Diese unvollständigen oder nicht abschließend bereitgestellten Funktionen werden ausdrücklich nicht als Mängel, sondern Entwicklungsschritte zum fertigen Produkt betrachtet. So kann der Stakeholder sicher sein, im MVP garantiert nicht das Produkt zu erhalten, welches alle Basis-Anforderungen erfüllt. Erst im sogenannten Minimum Marketable Product (MMP) kann ein Produkt abgenommen werden, das – im besten Fall –die initial gestellten Erwartungen übertrifft, denn in der Entwicklung wurden fortlaufend konkretisierte oder geänderte Anforderungen der Stakeholder berücksichtigt.
Wie wird bei der SCRUM Methode auf geänderte Prioritäten reagiert, ohne die Anforderungen des Endproduktes aus den Augen zu verlieren?
Geänderte Prioritäten
Wäre es nicht ein Einfaches den agilen Projekten das klassische MusCoW-Prinzip überzustülpen und im Minimum Valuable Product (MVP) auf die Erfüllung aller Must-Kriterien bzw. Prio-1 Use Cases zu pochen? Nein – Ganz im Gegenteil! Dieser hybride Ansatz führt nicht zum Erfolg, denn dem Projekt wird die gewonnene Flexibilität genommen und die Projektlaufzeit im Zweifel verlängert! Und das bei denselben Herausforderungen wie im klassischen Ansatz ergänzt um die Unsicherheiten der Agilität. Hier ist also Stress vorprogrammiert.
Unklare Anforderungen
Hier lohnt der Blick auf die Erfahrungen aus dem klassischen Ansatz: Anforderungen müssen Zielen zugeordnet werden, die wiederum einer Strategie und einer Produktvision untergeordnet sind. Vor Entwicklungsstart müssen jene Anforderungen (Requirements) dementsprechend geordnet und priorisiert werden. Hilfreich sind hierbei Balanced Scorecard oder ähnliche Modelle. Wird sich lediglich auf den Strom der Anforderungen konzentriert, besteht die Gefahr, dass jene höher priorisiert oder schnell in den Projektverlauf geschoben werden, die von einem Stakeholder mit hoher Position in der Unternehmenshierarchie gestellt werden. Diese Anforderungen müssen nicht grundlegend falsch sein, sind aber unter Umständen weniger präzise ausformuliert oder einer anderen Ebene in der Prioritätenliste zuzuschreiben.
Werden stattdessen Projektziele gemeinsam mit den Stakeholdern gewichtet und die Anforderungen konsequent an diese Ziele angelehnt, kann jeweils ein Business Value (BV) für das Projekt errechnet werden. Zudem wird durch die Beziehungen der Projektziele klar, welche Voraussetzungen und Basis-Arbeiten zu übergeordneten Zielen führen.
Die Gewichtung sollte also anhand der verfügbaren Ressourcen, Fähigkeiten und der Projektlaufzeit getroffen werden, um unrealistische Ziele rechtzeitig zu erkennen. Ziele, die leichter erreichbar sind, sollten demnach höher gewichtet werden. Der so errechnete Business Value unterstützt in der Argumentation und Entscheidung, in welcher Reihenfolge Anforderungen spezifiziert und priorisierte Use Cases bearbeitet werden sollten, um den größtmöglichen Erfolg im Projekt zu erreichen.
Ja, SCRUM kann Flexibilität und Sicherheit verbinden. Agile Projektmanagementmethoden in CRM- und Marketing-Projekten sind Modelle, die besonders auf Flexibilität und Geschwindigkeit angewiesen sind, aber gleichzeitig Mitarbeiter:innen einen größtmöglichen Freiraum in der Ausgestaltung einräumen. Um den Erfolg agiler Projekte zu gewährleisten, gibt es dennoch Regeln, an die es sich zu halten gilt:
Haben Sie weitere Fragen zum Thema agile Marketingprojekte bzw. SCRUM? Unser Expertenteam steht Ihnen gerne zur Verfügung – Kontaktieren Sie uns jetzt!