• Home
  • |
  • Blog
  • |
  • Optimale Zusammenarbeit zwischen Marketingabteilung und Werbeagentur

5. Mai 2014

Optimale Zusammenarbeit zwischen Marketingabteilung und Werbeagentur

Die Zusammenarbeit zwischen Marketingabteilung und Werbeagentur verläuft oft etwas unrunder als von beiden Seiten erwünscht. In meinen bisherigen beruflichen Stationen hatte ich die Gelegenheit, beide Seiten kennen und verstehen zu lernen. Gegenseitiges Verständnis ist zwar die Basis, aber noch kein Garant für eine erfolgreiche Zusammenarbeit. Was in der Praxis oftmals fehlt, ist ein definierter Ansatz um die Schnittstelle zwischen beiden Welten dahingehend zu gestalten, dass nicht nur beide Seiten mit der Zusammenarbeit zufrieden sind, sondern auch die Qualität des Ergebnisses den Erwartungen entspricht. In diesem Artikel stelle ich “Scrum”, eine Vorgehensweise aus der Softwareentwicklung als möglichen Lösungsansatz vor.

Selbstverständlich gibt es viele Fälle von professioneller Zusammenarbeit zwischen Werbeagenturen und deren Kunden, doch im Mittelstand bin ich immer wieder den folgenden Themen begegnet (ohne Anspruch auf Vollständigkeit oder Allgemeingültigkeit):

 

Unklare Zielvorstellung

Weder Agentur noch Kunde sind sich zu Beginn des Projektes bewusst, was genau bei dem Projekt herauskommen soll. Das ist verständlich, reden wir doch hier von einer kreativen Schöpfung, die geleistet werden soll. Oft geht die Unsicherheit beim Kunden jedoch darüber hinaus, es ist auch nicht umfassend definiert, was das Projekt im Rahmen der Aussenkommunikation leisten soll.

 

Keine Anforderungen

Der Kunde beauftragt die Agentur oft nur auf Basis eines Angebotes. Ein umfangreiches Lastenheft, wie es bei der Vergabe von technischen Entwicklungen üblich ist, wird nicht erstellt. Mit Sicherheit ist es im technischen Bereich einfacher Funktionen zu beschreiben als die nichtfunktionalen Anforderungen bei einem Kreativ-Projekt. Aber Grund genug im Folgenden noch einmal darüber nachzudenken.

 

Das Geheimlabor

Nach einem gemeinsamen Workshop verschwinden die Kreativen in ihrem Kämmerlein, kommen nach einiger Zeit mit einem weit gereiften Prototypen wieder zum Vorschein und präsentieren diesen beim Kunden. Während der Kunde die Gestaltung oder den Text zum ersten mal sieht und über sein Bauchgefühl in Richtung”gut” oder “schlecht” urteilt, hat die Agentur eine durchgehende Argumentationslinie für jedes Gestaltungselement parat. Die Agentur hat viel mehr geleistet, als es dem Kunde bewusst ist, sie hat ein druchgehendes Konzept erstellt und nicht nur “etwas gemalt”. Im Präsentationsmeeting treffen nun die beiden Welten und sämtliche Erwartungshaltungen aufeinander. Immer wieder habe ich erlebt, dass der Kunde aus dem Bauch heraus den Entwurf ablehnt oder zumindest für überarbeitungswürdig hält, die Agentur aber dank der vorbereiteten Argumentation den Kunden erfolgreich von ihrem Konzept überzeugt. So ist man sich am Ende des Termins einig, auf dieser Basis das Projekt umzusetzen, jedoch bleibt durch die geleistete Überzeugungsarbeit beim Kunden ein fahler Nachgeschmack. Auch auf Seiten der Agentur verursacht ein solches Meeting trotz des vermeintlichen Sieges andere Emotionen als eine Präsentation mit “Standing Ovations”.

 

Der Preis von Änderungen

Während die Agentur davon ausgeht, dass der mit viel Herzblut erstellte Entwurf vom Kunden durchgewunken wird, geht der Kunde des öfteren davon aus, dass “unendlich viele” Änderungswünsche von der Agentur ohne gesonderte Berechnung eingearbeitet werden. Beide Extrempositionen sind qualitativ bzw. wirtschaftlich nicht sinnvoll, und so wird oft schon im Vorfeld die Anzahl der im Preis inbegriffenen Änderungen oder Korrekturschleifen festgehalten. Diese Vereinbarungen mildern zwar das Konfliktpotential in dem sie die genannten Exptrempositionen entschärfen, greifen aber nicht den Kern der Zusammenarbeit an, in dem die Lösung für eine bessere Zusammenarbeit liegen könnte.

 

Die Analogie zur Softwareentwicklung

All die oben gennanten Themen sind bekannte Herausforderungen in einem anderen Kontext: wenn ein Kunde eine individuelle Software-Lösung bei einem Dienstleister beauftragt. Der klassische Ansatz ist, alles bis ins Detail zu planen, alles zu definieren und auf vielen Seiten Papier zu fixieren. Wenn dann eine der beiden Parteien dann von dem so eng gesteckten Rahmenwerk abweicht, ist die “Schuldfrage” schnell geklärt, die Verträge regeln Nachbesserungspflichten, Konventionalstrafen und vieles mehr. Nur: Wem ist damit geholfen? Wenn z.B. der Kunde den Softwaranbieter verklagt, hat er dann seine neue Software, die ihn bei seinen Prozessen unterstützen soll? Nein. Aber er hat Recht bekommen. Das ist natürlich ein extremes Ende des Projekts.

Gehen wir einmal vom Idealfall nach der klassischen Lehre aus: Alles wurde im Vorfeld genau definiert, alles wurde genau geliefert. Hat der Kunde dann die Software bekommen, die ihn optimal bei seinen Aufgaben unterstützt? Meistens nein, obwohl alle Beteiligten alles richtig gemacht haben. Warum? Zum einen lernt der Kunde erst im Laufe des Projekts was mit der gewünschten Software möglich ist, daraus ergibt sich, dass er manche Funktionen zusätzlich möchte, andere dafür vielleicht nicht mehr. Zum anderen ändert sich das Umfeld des Kunden während des Projekts, er hat neue Ideen, benötigt andere Funktionalität. Aber dann ist es zu spät. Das Projekt läuft, alles ist spezifiziert und wird auch so geliefert. Und dann ist da noch ein Punkt, der wieder den Bogen zu der Zusammenarbeit zwischen Marketingabteilung und Werbeagentur schließt: Gestalterische Dinge, wie z.B. die Benutzungsoberfläche der Software, kann der Kunde im Vorfeld gar nicht exakt definieren. Er kann nur durch Begutachten und Gebrauch eines Zwischenstandes beurteilen welche Änderungen er haben möchte.

Für all diese Themen hat die Softwareentwicklung hat eine Antwort gefunden.

 

Agile Zusammenarbeit

In der Softwareentwicklung haben sich Ansätze entwickelt, welche die oben beschriebenen Herausforderungen adressieren. Der Begriff der sich dafür eingebürgert hat, ist die sogenannte “Agile Entwicklung”. Wie aus dieser Bezeichnung schon ersichtlich ist, ist vorgesehen, dass der Projektverlauf sich dynamisch entwickeln kann um besser mit Änderungswünschen und Unvorhergesehenem umzugehen. Agile Entwicklung wendet sich ab vom tayloristischen Ansatz, dass alles planbar ist und erkennt folgende Tatsachen an:

  • Softwareentwicklung ist nicht Produktion, sondern eine kreative Tätigkeit. Softwareentwicklung ist dadurch nicht planbar.
  • Der Kunde weiß bei Projektstart nicht was die ideale Lösung für sein Business ist, seine Vorstellungen können sich im Laufe des Projekts ändern.
  • Änderungen können zu jeder Zeit im Projekt auftreten. Sie sollen aber durch das Modell der Zusammenarbeit nicht wie bisher vermieden werden, sonder als Chance für ein besseres Ergbnis verstanden werden.
  • Die (enge) Zusammenarbeit zwischen Personen schafft ein besseres Produkt und eine höhere beidseitige Zufriedenheit, als das strikte Einhalten von Plänen und Verträgen.
  • Alle Seiten sind sich einig, dass durch technische Probleme oder Änderungen das ursprüngliche Ziel evtl. nicht in der vorgesehenen Zeit erreicht werden kann. Auf keinen Fall wird an der Qualität gespart, im Zweifelsfall wird Geld nachgeschossen oder Funktionen werden weggelassen. Besser ein kleines perfektes Produkt auf dem Markt als ein gegenseitig korrekt eingehaltener Vertrag bei schlechter Produktqualität.
  • Gegenseitiges Verständnis und Transparenz schafft Lösungen statt Konflikte.

Diese Auflistung klingt zunächst einmal nach nicht mehr als nach gesundem Menschenverstand, dennoch haben die Projektmamangement-Philosophien des letzten Jahrhunderts diese Punkte nicht anerkannt.

 

Scrum

Scrum ist der am weitesten verbreitete agile Ansatz in der Softwarentwicklung. Bitte auch weiterlesen, wenn Sie aus einer Marketingabteilung oder einer Werbeagentur kommen. Sie werden Ihre Themen darin wiedererkennen. :)

Ich will hier in kurzen Stichworten die Grundprinzipien von Scrum beschreiben:

  • Der kreative Prozess wird in viele kleine Phasen, sogenannte Sprints, aufgeteilt. Alle Sprints sind gleich lang, meist zwischen einer und vier Wochen.
  • Jeder Sprint muss ein vorzeigbares (idealerweise auch ein verwendbares) Ergebnis für den Kunden liefern.
  • Alle Aufgaben / Wünsche / Anforderungen / Funktionen, werden von einem (nur einem!) Kundenvertreter priorisiert und dem Team vorgelegt. Der Kundenvertreter (bei Scrum “Product Owner”) gibt damit die Abarbeitungsreihenfolge vor, aber nicht das Volumen pro Sprint. Diese priorisierte Liste nennt man “Backlog”
  • Die kreative Arbeit (Entwicklung) ist Aufgabe eines Teams, nicht von einzelnen Personen. Das Team legt gegenüber dem Kunden für jeden Sprint fest, welche Arbeitspakete es in diesem Sprint schafft, in dem es von der priorisierten Liste so viel in den Sprint nimmt, wie es sich zutraut. Das Team verpflichtet sich, diese Pakete auch abzuarbeiten, das Team steht als eine Einheit in der Verantwortung, nicht einzelne Personen.
  • Nach jedem Sprint begutachtet der Kunde (bzw. dessen Stellvertreter) das Ergebnis, akzeptiert es oder fordert Änderungen, welche dann auch wieder in die große priorisierte Liste kommen und in den folgenden Sprints abgearbeitet werden.
  • Der Kunde kann jederzeit Aufgaben / Wünsche / Anforderungen im Backlog ändern, hinzufügen oder wegnehmen, wenn diese noch nicht vom Team in den aktuell laufenden Sprint genommen wurden. Dadurch kann jederzeit auf Änderungen reagiert werden.

Ok, wer das zum ersten mal liest wird sich denken: Anarchie. Doch der Erfolg gibt dem Modell recht. Die Vorraussetzung für den Erfolg ist natürlich, dass sich beide Seiten auf diese Form der Zusammenarbeit einlassen können und die Unplanbarkeit akzeptieren. Der Erfolg von Scrum basiert auf der engen, offenen Zusammenarbeit, der Transparenz und auf der Akzeptanz des Unplanbaren. Auch wirklich große Entwicklungsorganisationen wie z.B. SAP stellen im großen Stil auf Scrum um.

Ich möchte daher an dieser Stelle nicht in die Diskussion einsteigen, ob Scrum funktioniert oder nicht. Scrum funktioniert. Weltweit. Punkt. :))

Das spannende ist für diesen Artikel ja die Frage, ob die Mechanismen von Scrum die eingangs beschriebenen Herausforderungen im Marketing lösen können.

 

User Stories

Wie bereits dargestellt, ist die Basis der agilen Ansätze eine enge Zusammenarbeit zwischen Kunde und Dienstleister. Ein Teil davon ist, dass der Dienstleister ein umfassendes Verständnins nicht nur für die Anforderungen des Dienstleisters, sondern auch für dessen Umfeld (Business Case) erlangt. Aus diesem Antrieb heraus hat sich eine neue Art entwickelt, Anforderungen zu beschreiben, in sogenannten User Stories. User Stories haben immer den Aufbau “Als [Rolle] möchte ich [Funktionalität] um [Nutzen]”. Dadurch werden neben der Funktionalität immer die Perspektive (Rolle) und die Motivation (Nutzen) ersichtlich.

Als vereinfachtes Beispiel nehme ich hier eine klassisch formulierte Anforderung aus einem Online-Shopsystem:

Es muss die Möglichkeit vorgesehen werden, ein Kundenkonto anzulegen.

Als User-Story dann in etwa so:

Als Kunde möchte ich ein Kundenkonto anlegen können um mir beim nächsten Einkauf die erneute Eingabe meiner Daten zu ersparen.

Diese Story vermittelt als griffiger Satz schon mehr Infos: Wer ist der Anwender und warum möchte er diese Funktionalität haben? Vielleicht lässt sich sein Wunsch ja auf andere Weise technisch einfacher erfüllen. Doch mit diesem Satz alleine können die Entwickler noch nichts anfangen. Die Anforderung wird durch Akzeptanzkriterien präzisiert, in unserem Beispiel in etwa so:

Akzeptanzkriterien:

  1. Für die Anmeldung sind Name, Vorname, Adress, PLZ, Ort und Emailadresse einzugeben
  2. Als eindeutigen Benutzername verwendet das System die angegebene Emailadresse
  3. Das System verschickt eine Bestätigungsemail.

Hier wird deutlich, dass die Akzeptanzkriterien teilweise auch wieder User-Stories sein könnten. Ziel ist es, die Stories in der richtigen Granularität festzulegen, so klein dass mehrere davon in einem Sprint zu erledigen sind, aber so groß dass sie nicht trivial werden oder nicht mehr als eigenständige Funktionalität gesehen werden können.

 

Optimale Zusammenarbeit zwischen Marketingabteilung und Werbeagentur

Wie ich dargelegt habe, haben die Themen im Bereich “Marketing und Agentur” eine hohe Überlappung zu denen in der Software. Die spannende Frage für eine Umsetzung ist: Wie gehen wir mit dem Thema “Anforderungen” um. Bei der Software sind es zumeist halbwegs greifbare Funktionen. Aber im Marketing? OK, alles was die Agentur leisten soll hat auch einen “Sponsor”, also jemanden der Erwartungen an die Ergebnisse hat, und dieser hat auch eine bestimmte Motivation für seine Wünsche.

Um die abstrakte Ebene zu verlassen, will ich jetzt mit einem vereinfachten Beispiel weitermachen, um die Grundmechanismen darzustellen. Als Marketingabteilung / Agenturkunde nehme ich einen erfunden mittelständischen Anlagenbauer, die” JP Automatisierungsgesellschaft mbH”, kurz JPA. Die JPA möchte mit der ebenfalls erfundenen Werbeagentur “Geist, Blitz und Partner”, kurz GBP eine neue Imagebroschüre entwickeln.

Die Anforderungen der JPA an die Imagebroschüre habe ich in einem Workshop ermittelt und in User-Stories formuliert. Dabei wurden aus der Vision die Stories dergestalt abgeleitet, dass die Agentur in den Strories konkrete Vorgaben für die Umsetzung der Broschüre findet. Dabei ist interessant, dass durch die User-Stories klar wurde, dass es verschiedene Rollen gibt, die Anforderungen an die Broschüre haben:

  • Der JPA Vertrieb
  • Die Entwicklung von JPA
  • Der Geschäftsführer der JPA
  • Die Kunden der JPA

Das Backlog in unserem Beispiel beginnt mit folgenden User-Stories:

  1. Als Vertrieb möchte ich die Leistung unserer Anlagen herausstellen um uns vom Wettbewerb abzugrenzen,
  2. Als Vertrieb möchte ich die Leistung unseres Kundendiensts herausstellen, um uns vom Wettbewerb abzugrenzen.
  3. Als Geschäftsführer möchte ich die Historie darstellen um zu zeigen, dass wir ein langfristiger Partner für den Kunden sind.
  4. Als Geschäftsführer möchte ich die Gesellschafterstruktur beschreiben um beim Kunden Vertrauen in eine langfristige Zusammenarbeit aufzubauen.
  5. Als Kunde möchte ich wissen welcher Lieferant die Steuerungen zuliefert.
  6. Als Entwicklungsleiter möchte ich eine schematische Zeichnung unserer patentierten Vorschubeinheit abgebildet haben, um den Kunden ein konkretes Bild zu liefern das er mit unseren Vorteilen assoziiert.
  7. Als Kunde möchte ich wissen wie ein Projekt mit JPA abläuft, damit ich weniger Unsicherheit verspüre.
  8. […]

Die zugehörigen Akzeptanzkriterien habe ich in dieser Aufzählung einmal weggelassen.

Das so aufgebautes Backlog ist die Basis für die Zusammenarbeit zwischen Marketingabteilung und Werbeagentur. Der Ablauf ist sehr nah an Scrum angelehnt. Als Sprintlänge haben sich beide Seiten auf 2 Wochen geeinigt. Jeden zweiten Dienstag wird der neue Sprint aufgeplant, d.h. die Agentur wählt im Backlog so viele Stories aus, wie sie in zwei Wochen umsetzen kann. Diese Stories dürfen während des Sprints vom Kunden nicht mehr verändert werden. Jeden Mittwoch gibt es ein weiteres Treffen, in dem der Kundenvertreter mit der Agentur das Backlog verfeinert, ggf umpriorisiert und grob die nächsten 3 Sprints vorplant. Am Ende des Sprints ist, immer am Montag vor dem Sprint-Start, findet das Sprint-Review-Meeting statt, in dem die Agentur die aktuellen Zwischenergebnisse präsentiert. Anschliessend beraten Kunde und Agentur über den Ablauf der letzten beiden Wochen und was daran verbessert werden kann (hier unterscheidet sich das Marketing-Scrum vom Software-Scrum).

Soviel mal als Überblick für unser Beispiel. Natürlich sind noch mehr Themen in Scrum enthalten, auf die ich hier nicht eingegangen bin, die aber ebenfalls in den neuen Kontext übertragen werden müssen: Die Rolle des Scrum Master, Burndown-Charts, das Dashboard, Definition of Done, …

Ziel dieses Beitrags ist jedoch nicht ein fertiges Kochrezept zu liefern (Kochrezepte bei Prozessen funktionieren ohnehin nur bei dem Unternehmen, welches das Rezept entwickelt hat), sondern einen Impuls zu lieferen, die bewährten Konzepte von Scrum auch in anderem Kontext einzusetzen.

OK, Sie werden jetzt sagen, das ist aber alles ganz schön kompliziert. Die Wirkung von Scrum wird erst offensichtlich wenn man es anwendet. Im meinen Augen die wichtigsten Verbesserungen durch Scrum:

  • ehrlicher Umgang miteinander, keine Wahrheitsoptimierungen bezüglich Projektfortschritt
  • Transparenz bezüglich Fortschritt und Problemen
  • Bessere Schätzgenauigkeit durch konstanten Takt (Sprint)
  • Weniger Reibung an der Schnittstelle, da nur ein Kundenvertreter an der Schnittstelle steht
  • Mehr Motivation im Team des Lieferanten durch mehr Selbstbestimmung, Achtung und Transparenz
  • Durch Summe der Effekte: Effizientere Abwicklung des Projekts bei besserer Qualität der Ergebnisse

So, das soll mal für heute genügen, die weiteren Schritte überlasse ich Ihnen.

Viel Erfolg beim Experimentieren mit Scrum im Marketing!

 

Mehr Lesefutter

Scrum bei Wikipedia

Die Spielregeln von Scrum: Der Scrum Guide von scrum.org

Agile Prinzipien und Werte: Das Agile Manifest

Ähnliche Beiträge

Fallstudie: Messgerät mit Scrum

Fallstudie: Messgerät mit Scrum

Fallstudie: Motorkomponente mit Scrum

Fallstudie: Motorkomponente mit Scrum

Agiles Buch: Erstes Print-Release

Agiles Buch: Erstes Print-Release

Agiles Buch: Responding to change over following a plan

Agiles Buch: Responding to change over following a plan