Trendscout
What’s your beef #2: Warum agiles Projektmanagement auch nach Ihrem Geschmack sein könnte
Das Dumme beim Thema Agiles Projektmanagement (APM): Es ist nicht immer augenscheinlich, warum überhaupt agil gearbeitet werden sollte, da der Nutzen von APM in der Zukunft liegt und nicht kurzfristig nachgewiesen werden kann.
Außerdem ist es immer einfacher und bequemer, auf Bewährtes zu setzen, anstatt alles in Frage zu stellen und neu zu denken. Bei aller Euphorie ist festzustellen, dass, auf den Healthcare-Marketing-Bereich bezogen, noch keine wirklichen positiven Auswirkungen von APM zu spüren sind, weil es einfach noch nicht genügend Projekte gibt, die auf diese Art durchgeführt werden oder wurden. Was noch fehlt, ist der klare Vergleich von herkömmlich und neuartig durchgeführten Projekten.
Mit anderen Worten: Das Bauchgefühl sagt, dass gerade etwas ganz Großes entsteht. Man weiß aber nicht so richtig, warum. Die harten Fakten liegen noch nicht auf dem Tisch. Ich habe vor kurzem den Test gemacht: Ich habe in meinem Netzwerk auf LinkedIn die Frage gepostet, ob jemand etwas zu agilen Projekten sagen könne, ob Erfahrungswerte existieren und ob Projekte besser oder schlechter laufen. Fazit dieses Postings: ca. 500 Personen haben sich ihn angesehen, aber ich habe keinen Kommentar erhalten. Ein User hat mir lediglich einen Berater für agile Projekte empfohlen.
Um dieses diffuse Bauchgefühl zu beseitigen und APM ein Stück weit zu „entzaubern“, und zwar im positiven Sinne, habe ich die folgenden Feststellungen, Beobachtungen und Meinungen zusammengetragen:
Ja, es ist Software!
Durch die laufenden Agilitätsdiskussionen erfolgt eine Richtigstellung, die seit Jahren überfällig ist: Web-Projekte wie Websites oder andere interaktive Anwendungen überhaupt als Software zu bezeichnen und ihnen dadurch eine andere Wertigkeit zu verleihen. Dass Apps ein Stück Software sind, ist jedem klar, wahrscheinlich, weil es einen Installationsprozess gibt. Websites wurden als solche nie wirklich angesehen, weil sie eben nicht installiert werden müssen, sondern einfach über den Browser abrufbar sind. Sie wurden ganz gerne als „minderwertige Programmierung“, Publishing-Tools oder einfach als Anhängsel von Werbung abgetan. Durch Einsatz von Methoden aus der Software-Entwicklung und der Übertragung dieser auf Web-Projekte, werden sie nun auch als „Software“ begriffen. Was gut ist, denn es handelt sich de facto um Software.
So unterschiedlich wie Geschmäcker – Agile Projekte
Ein großer Vorteil von agilen Projekten ist sicherlich, dass diese mit „flexibel“, „proaktiv“ und „initiativ“ charakterisiert werden können. Alles Eigenschaften, die, wenn sie auch beherzigt werden, üblicherweise zu Begeisterung bei Auftraggebern oder Kunden führen. Veränderungen und neue Funktionen werden noch sehr spät in die Entwicklung mit aufgenommen, um ein möglichst immer besseres Endprodukt zu erschaffen. Ein Produkt wird inkrementell innerhalb relativ kurzer Entwicklungszyklen immer weiter entwickelt. Funktionierende Teile werden nach und nach ausgeliefert, Änderungen und Neuanforderungen sukzessive eingearbeitet („Sprints und Backlogs“). Alles ist im Fluss – und zwar jederzeit.
Damit muss man umgehen können. Diese Arbeitsweise tut nicht allen Projekten gut – und kann für die ein oder andere schlaflose Nacht beim Auftraggeber sorgen. Bei linear verlaufenden Projekten nach dem Wasserfall-Modell verläuft im Vergleich alles in „geordneten Bahnen“ ab. Auf ein fest vorgegebenes Ziel wird hin-, einmal definierte Anforderungen werden abgearbeitet.
Andererseits gibt es in quasi jedem Projekt Änderungen, während das Projekt läuft – und dann ist APM mit seiner Schnelligkeit und Flexibilität im Vorteil.
Die Frage ist, wie signifikant die Änderungen sind: Ob es sich um einen grundlegende Änderung, ein „auf links drehen“ oder lediglich um ein paar kosmetische Korrekturen handelt, macht den Unterschied.
Synchronizing the world of…
Der Versanddienstleister UPS hat den Satz geprägt „Synchronizing the world of Commerce“. Ich fand den Satz schon immer irgendwie gut, führt er doch anschaulich vor Augen, was UPS eigentlich macht: eben nicht einfach nur „Pakete durch die Weltgeschichte senden“. APM synchronisiert auch, und zwar die Arbeitsweisen, Prozesse und Kulturen komplett unterschiedlicher Unternehmen. Das wird aus meiner Sicht einen großen Effizienzgewinn für Marketing-Projekte bedeuten. Man stelle sich folgendes vor: Gerade bei Erstprojekten vergeht eine Menge Zeit damit, sich kennenzulernen, Prozesse zu definieren, Prozesse aufzusetzen, die kulturellen Eigenheiten zu vermitteln, sich also im Großen und Ganzen „zusammenzuraufen“. Durch die Einigung auf eine einheitliche Methode der Zusammenarbeit ist man auf jeden Fall schneller bei der Sache und kann schneller starten. Wenn in den Sprints und Backlogs neue Ideen festgehalten und eingearbeitet werden, also gut kollaboriert wird, ist die Wahrscheinlichkeit groß, ein besseres Endergebnis entstehen zu lassen.
Diese Synchronisations- und Kollaborationskraft ist für mich zur Zeit DER Big Point von agilen Projekten.
Viele Köche verderben den Burger?! Von wegen!
Die Verbesserung der Zusammenarbeit von Auftragnehmer und Auftraggeber ist das Eine. Weiteres Plus auf der Habenseite ist die deutlich bessere Kundenorientierung bzw. Nutzerzentrierung – und damit meine ich die Kunden des Auftraggebers. Mithilfe agiler Methoden ist es möglich, die Kunden ständig mit einzubeziehen und auch mit ihnen zu kollaborieren. Prototypen und Beta-Versionen sind schnell ausgeliefert, so dass Feedback in die Backlogs mit aufgenommen werden kann. Wenn das Endprodukt bzw. Endergebnis gemeinsam mit dem Kunden entwickelt wurde und von ihm deshalb besser akzeptiert wird, ist das mehr wert als die zusätzlichen Kommunikationsströme, die nötig werden.
Ich habe kürzlich von einem Pharmaunternehmen gehört, dass Co-Creation-Labs mit Ärzten und Patienten durchgeführt werden, um die User Experience mit dem Unternehmen und dessen Medikamenten und Services zu verbessern bzw. um besser verstehen zu können, was diese Stakeholder eigentlich wollen.
Wenn die Ergebnisse dieser Labs in laufende Prozesse integriert und berücksichtigt werden, ist das agil „at its best“.
Probieren, um auf den Geschmack zu kommen
Ein Prinzip des APM hatte ich eingangs kurz beschrieben: Schnell Ergebnisse produzieren und modifizieren anstatt lange an der einen, geplanten richtigen Lösung zu werkeln. Genau das könnte man sich für den Einstieg in das APM vornehmen. Mit einem kleinen Projekt beginnen, ein kleines Projektteam bilden, die Personen darauf einschwören und einfach mal machen. Die Risiken sind überschaubar und wahrscheinlich nicht größer als bei jeder anderen Projektherangehensweise auch. Wenn alle Beteiligten und die Stakeholder „committed“ sind, möchten alle das Projekt zum Erfolg führen. Von daher wäre ich zuversichtlich, dass auch genau das eintritt – bei vielleicht geringer Zeitverzögerung zu Beginn. Die herkömmliche „Change-Methode“ würde bedeuten, möglichst große Teile einer Organisation auf APM „umzustellen“, zu schulen, Infoveranstaltungen im größeren Rahmen zu veranstalten, alle abzuholen und mitzunehmen. Das kann dauern. Ein Best Practice zu schaffen, welches genau zur Organisation passt und von allen Beteiligten (inkl. Agentur) während des Projektes erarbeitet wurde, hat operative und strategische Vorteile. Wir bei antwerpes arbeiten seit Jahren intern ohnehin mit agilen Methoden, so dass wir diese Expertise auch in einzelne Projekte einfließen lassen können.
Muss es immer Fast Food sein?
Oder immer alles agil? Nein, denn es gibt Projekte, und ich vermute, die wird es noch eine Zeit lang geben, die keine agile Arbeitsweise benötigen. Auch wenn wir intern ohnehin so arbeiten, muss man nicht aus jedem Projekt ein agiles in der Zusammenarbeit mit externen Parteien machen. Man kann den zu Beginn des Artikels erwähnten „Idealismus“ auch mal beiseite lassen. Es würde außerdem der Agilität widersprechen, immer starr an diesem Prinzip festzuhalten. Ist eine langjährige Basis der Zusammenarbeit vorhanden, lassen sich Projekte zielgerichtet und zum Festpreis umsetzen, ohne dass man agil zusammenarbeitet. Voraussetzung dafür ist, dass die Zielsetzung und der gewünschte Output klar umrissen sind, zum Beispiel in einer konkreten Leistungsbeschreibung.
Dieser Beitrag ist der zweite Bissen des dreiteiligen Artikels „What’s your beef? Warum Agiles Projektmanagement auch nach Ihrem Geschmack sein könnte“. Appetit auf den dritten Bissen?
Thilo Kölzer ist Vorstandsmitglied und Verantwortlicher für Digital & Mobile, Performance Marketing und Internet-of-Things bei der antwerpes ag.