Gratis Agentur-Pitch: My 2 cents!

Als Agentur freuen wir uns, wenn sich die Qualität unserer Arbeit herumspricht und wir zu Projektausschreibungen eingeladen werden. Natürlich erfordert jede Angebotslegung eine intensive Beschäftigung mit dem Kunden, dem Produkt, den Leistungen und dem Auftraggeber im Allgemeinen. Wir setzen uns professionell und intensiv mit Anfragen auseinander und erwarten eben diese Ernsthaftigkeit auch von unseren Partnern und potenziellen Kunden.

Nicht selten gehen Anfragen aber weit darüber hinaus und es sind umfangreiche Kreativ- und Konzeptionsleistungen in Rahmen eines mehrstufigen und oft monatelangen Prozesses gefragt. Gerne greifen Auftraggeber deshalb auf einen Pitch zurück, d.h. es werden mehrere Agenturen eingeladen, Konzepte, Designideen und Strategien zu präsentieren. So weit, so üblich und legitim.

Wer allerdings mehr vergleichen möchte, umfangreiche und detaillierte Entwürfe einfordert, muss auch mit entsprechendem Aufwand seitens der Auftragnehmer rechnen und Abschlagshonorare einkalkulieren.

Genau das hat sich aber anscheinend noch nicht überall herumgesprochen. Eine aktuelle Studie besagt, dass 2014 zwei Drittel der Auftraggeber nicht andenken, ein Pitch-Honorar zu bezahlen. Wohlgemerkt bei steigenden Qualitätsansprüchen an die abgelieferte (kostenlose) Arbeit. Gerne greifen manche Unternehmen deshalb immer noch auf den vermeintlich verlockenden Gratis-Pitch zurück.

Doch was bekommt man als Auftraggeber eigentlich, wenn man Leistung ohne Gegenleistung verlangt, wer bezahlt schlussendlich und warum wir, die Agenturen und Kreativen, an dieser Unsitte eigentlich selber schuld sind. Ein Erklärungsversuch.

No free pitch

Wie viel kostet ein Pitch?

Gehen wir von einem klassischen Webprojekt mittlerer Größenordnung aus. Überliefert werden Briefings mit Anforderungen, Zielsetzungen, Zielgruppenanalyse, Personas und / oder User stories. Im Idealfall. Die Liste lässt sich endlos fortsetzen. Gewünscht wird eine Kalkulation, Designvorschläge, eine Strategie sowie ein Navigationskonzept und die Informationsarchitektur.

Das bedeutet, dass Konzepter, Controller, Designer und Developer gemeinsam an der Erstellung und Umsetzung arbeiten. Es wird recherchiert, analysiert, konzipiert und im Anschluss die Ergebnisse in Meetings besprochen, bevor die Unterlagen aufbereitet und Entwürfe vorbereitet werden.

Bei einem durchschnittlichen Agenturstundensatz zwischen EUR 80 und EUR 120 und umgerechnet 50 – 100 Arbeitsstunden (je nach Komplexitätsgrad) entspricht dies (theoretisch) einem monetären Aufwand von EUR 4.000 bis EUR 12.000. Eine nicht unbeträchtliche Summe.

Am Ende bezahlt ein Kunde

Jeder Agentur-Pitch schlägt sich also in der Kalkulation nieder. Ja, so isses. Nimmt eine Agentur im Jahr also an fünf bis zehn Gratis-Pitches teil, belaufen sich die Aufwände schnell im höheren fünfstelligen Bereich. Auch wenn ein gewisser Prozentsatz dafür einkalkuliert wurde, können sich dies nur wenige Dienstleister auf lange Sicht erlauben. Und die traurige Wahrheit lautet: Wird der Aufwand nicht vergütet, bezahlen mittelfristig laufende Kunden. Diese Vorgehensweise ist unfair für bestehende Kunden und schadet dem partnerschaftlichen Vertrauensverhältnis zwischen Agentur und Auftraggeber an sich.

Reputationsstärkung und Lob

Doch was sind die Beweggründe dahinter, warum lassen sich Kreative auf dieses Spiel ein? Hand aufs Herz: Wer hat nicht zumindest bereits einmal kostenlos seine Leistungen angeboten, weil die Hoffnung auf Folgeprojekte, die Stärkung der Reputation oder das unternehmerische Ego auf Höhenflug unterwegs waren? Das kennt jeder! Und das wissen auch Auftraggeber zu nutzen.

Gewunken wird so ziemlich allem Manchmal mit einer Art “Preisgeld”, wenn man es unter die Top 3 schafft. Oder es werden Sachpreise angeboten. Süßigkeiten, Knabbereien oder Jahresvorräte an Getränken, alles schon erlebt. Aus betriebswirtschaftlicher Sicht ein interessantes Angebot. Not.

Den Gipfel der Absurditäten bildet dann noch der Reputations-Schmäh. Das klingt in etwa so: “Es ist eine tolle Gelegenheit für Sie und Ihr Unternehmen sich einem breiten Publikum vorzustellen”. Verlockend. Aus Kundensicht sollte man sich die dann aber schon die Frage stellen, ob man sich ernsthaft Experten an Bord holen möchte, die ihre Leistungen kostenlos anbieten und den Wert ihrer Arbeit selbst nicht erkennen?

Die Milchmädchenrechnung – Der nächste große Auftrag winkt schon

Und dann gibt es dann ja noch die versprochenen Folgeprojekte. Aber der Gedanke ist so simpel wie falsch und lockt vor allem kleine Agenturen immer wieder in die Falle: „Wenn wir nur (kostenlos) zeigen, wie gut wir sind, wird sich das auch herumsprechen und wir können mit größeren Aufträge und lukrativeren Etats rechnen.“ Die Realität ist allerdings ernüchternd: Gratis-Arbeit spricht sich nämlich tatsächlich herum und ruft vor allem Kunden auf den Plan, die oftmals ohnehin nicht bereit sind, reale Aufwände zu begleichen.

Schuld sind nicht (nur) die Auftraggeber

Schuld an der Misere sind nicht die Auftraggeber, hier ist branchenintere Selbstreflexion gefragt. Betrachten wir es einmal quer über die gesamte Dienstleistungsbranche hinweg. Kaum eine Branche erlaubt es kostenlose Leistungen zu beziehen, die eventuell – sofern das Ergebnis gefällt – zu einem späteren Zeitpunkt bezahlt werden.

Wer in der Kreativbranche arbeitet, weiß, wieviel Aufwand die Gestaltung eines Logos, einer Kampagne, eines Slogans oder einer Website darstellt. Aber wir können nicht verlangen, dass sich darüber auch Auftraggeber im Klaren sind. Es liegt in unserer Verantwortung transparent zu arbeiten und somit aufzuzeigen, dass sich ein Claim nicht in fünf Minuten entwickelt, Visitenkarten nicht in der Mittagspause erstellt werden, das Interaktionsdesign für eine Website nicht nur einen Nachmittag lang dauert und ein Webshop nicht in ein paar Stunden umgesetzt wird.

Wir lieben unsere Arbeit, setzen unsere Projekte mit Leidenschaft um und verzichten auf Lösungen von der Stange. Dahinter stehen Kreativprozesse, die sich über Monate erstrecken und die interdisziplinär entstehen. Der Aufwand setzt sich nicht nur nach Stunden zusammen, sondern hängt auch von der Erfahrung und dem Know-How des Dienstleisters ab.

Um mit den Worten der Designerin Paula Scher abzuschließen: ! It took me a few seconds to draw it, but it took me 34 years to learn how to draw it in a few seconds.

User stories oder Persona-based design?

Bei der Gestaltung von Webseiten, Apps oder Webservices im Allgemeinen steht das User Centered Design klar im Vordergrund. Technik, Design und Marketing definieren die jeweiligen Anforderungen gemeinsam in der Konzeptionsphase. Die Herausforderung liegt darin, alle Projektziele miteinander zu erarbeiten.

Denn ist das Design noch so schön, der User findet sich aber nicht zurecht oder braucht zu lange, um sein Ziel zu erreichen, dauert es nicht lange und er ist futsch. Wir suchen daher bereits in der Konzeptionsphase nach Workflows, die die Absichten der User erkennen und festlegen lassen. Dabei haben wir sowohl mit User stories als auch mit Personas gearbeitet.

Effizienter Prozess durch User stories

Haben wir vor einigen Jahren noch Personas präferiert, so arbeiten wir heute hauptsächlich mit User stories. Eine Unser storie beschreibt das Verhalten des Benutzers, also was muss die Anwendung können, wenn der Benutzer eine Aktion ausführen möchte. Dabei werden mögliche Szenarien durchgespielt und das Handeln des Benutzers analysiert. Ganz wesentlich dabei ist, dass dies frei von technischen Spielerein gehalten wird. Die Benutzerfreundlichkeit steht beim Erstellen von User stories klar im Vordergrund, weil mit Hilfe der User stories ein schnelles und einfaches Benutzen auf der Website erzielt werden kann.

Arbeiten mit User stories ermöglicht auch eine höhere Effizienz im Designprozess, denn wenn alle nötigen Funktionen im Vorfeld abgeklärt wurden, passiert es kaum, dass eine wesentliche Funktion vergessen wird und somit das Design neu oder umgestaltet werden muss.

Der erheblichste Vorteil ist wohl eine gute Kommunikation zwischen Designer und Entwickler, es erfolgt ein intensiver Austausch über die Anforderungen und begünstigt einen Wissenstransfer in beide Richtungen. Durch die Anwendung von User stories können Anforderungen flexibler gestaltet werden und beispielsweise den aktuellen Marktgegebenheiten angepasst werden.

Inhomogene Zielgruppen sprechen gegen Personas

Anders ist der Prozess beim Arbeiten mit Personas. Als Persona wird ein typisches Nutzerprofil verstanden, das sich durch Befragungen von realen Nutzern oder durch die Abbildung von statistischen Häufungen ergibt. In der Regel werden mehrere Personas entwickelt, die eine typische Zielgruppe darstellen sollen. Bei diesem Prozess wird nicht davon ausgegangen, was der Benutzer für Ziele hat, sondern soll primär sicher gestellt werden, dass die grundlegenden Anforderungen der Hauptnutzergruppe erfüllt werden.

Das System des Persona-based-Designs stammt eigentlich aus dem Marketing bzw. aus der Marktforschung, wo mit Hilfe von Befragungen versucht wird eine Zielgruppe festzulegen. Bei diesem System wird weniger auf die Benutzerfreundlichkeit geachtet und mehr auf die jeweilige Zielgruppe eingegangen, was meines Erachtens bei manchen Webprojekten funktionieren kann, aber schon lange überholt und veraltert ist. In erster Linie soll eine Webseite benutzerfreundlich und klar strukturiert sein, jeder der sie benutzt soll sich wohlfühlen, egal, ob er einer definierten Zielgruppe angehört oder nicht. Jeder Kunde zählt.

Wir haben unseren Workflow auf das Arbeiten mit User stories eingestellt und nutzen die Vorteile bei allen Projekten. Dabei kann es schon sein, dass drei, vier Leute einen oder zwei Tage zusammen sitzen und vor dem Whiteboard alle möglichen Szenarien durchspielen. Aber die Vorteile dieses Systems haben uns überzeugt und es gibt keine unvorbereiteten Überraschungen mehr nach der Konzeptionsphase.

Agiler Workflow statt Kommunikationschaos

Der folgende Beitrag gibt eine Übersicht zu dem von uns verwendeten agilen Projekt-Workflow, den wir mit Hilfe des Issue- und Bugtracking- Systems Youtrack umsetzen. Das Ganze aus der Perspektive eines Entwicklers.

Ein Rückblick

Wer kennt es nicht, Änderungswünsche von Kunden kommen idR. per Mail oder in ganz dringenden Fällen per Telefon. Empfänger sind meist die Projektmanager oder Entwickler aber auch gerne mal die Chefin. Jetzt kommt der Knackpunkt: Diese Änderungswunsche wurden dann agenturintern gleich per Mail an die zuständigen Designer, Entwickler oder Projektmanager weitergeleitet – was bei mehreren gleichzeitigen Projekten in der Pipeline unweigerlich im Chaos endete. In scheinbar ganz dringenden oder ganz einfachen Fällen geht aber auch noch direkter – nach dem Prinzip der kürzesten Wege gleich per Zuruf: „Kannst du bitte mal schnell… .“

Gerade Entwicklern kosten solche kleinen Unterbrechungen Studienergebnissen zufolge 15 oder gar 30 Minuten Zeit, um wieder ganz in die ursprüngliche Problemstellung hinein zu finden. Abgesehen davon ist die gesamte Kommunkation zu Änderungswünschen in E-Mails, auf Notizblöcken und vor allem in den Köpfen des Teams gespeichert. Das führt dazu, dass es für alle Beteiligten schwer wird den Überblick zu behalten und konzentriert zu arbeiten. Eine Lösung musste also her, aber klassische Bugtracker sind zu sehr an Entwicklern ausgerichtet und für Projektmanager, Designer und Kunden eher ungeeignet. Nach langem Suchen sind wir aber seit letztem Jahr fündig geworden und möchten euch einen Einblick in unsere Erfahrungen geben.

Die Qual der Wahl

Nach gründlicher Recherche und Tests von vielen Bug-, Issue-Tracking und Projektmanagement-Systemen wie Jira, Redmine, Trac, Erpal, etc. haben wir uns unter anderem aus folgenden Gründen für Youtrack entschieden:

  • Individuell an unseren Workflow anpassbar
  • Zusammenfassung von Projektmanagement, Bug-Tracking und Zeiterfassung
  • Zentrale Dokumentation aller Änderungen und Kommunikation
  • Integration mit unserem Continuous Integration System (wird in einem späteren Beitrag erörtert)
  • Möglichkeit zu schnelleren Strukturierung von Kundenanfragen (Erstellung von Angeboten, wird ebenfalls später gebloggt)
  • Ausgefeiltes Rollensystem, um Kunden Zugriff auf Projektbereiche zu geben

Effizienter und agiler Workflow

Da wir bereits bei der Angebotserstellung die Projekte strukturieren, beschreiben und in kleinere Tasks bzw. Tickets aufteilen, können wir bei Projektstart schneller in die Umsetzung gehen. Es sind bereits alle Features und User stories definiert und werden gegebenenfalls in kleinere Subtickets aufgeteilt.

Kommunikation und Dokumentation von Änderungen Alle Änderungen, zusätzliche Informationen oder Fragen werden zu den jeweiligen Tickets gespeichert. Etwaige Rückfragen an den Kunden werden sofern möglich auch über das System abgewickelt. Kunden können aber auch via E-Mail neue Tickets eröffnen. So ist sichergestellt, dass alle Beteiligten, jederzeit, auf dem gleichen Wissenstand sind.

Priorisierung der Tickets Um abschätzen zu können, wie wichtig die Bearbeitung der Tickets ist werden folgende Prioritäten vergeben:

  • Minor
  • Normal
  • Major
  • Critical
  • Show-Stopper

Als „Critical“ und „Show-Stopper“ markierte Tickets sind meist Grundbausteine und für den Projekterfolg äußerst wichtig. Diese werden dementsprechend prioritär behandelt und zuerst umgesetzt. Auch Bugs fallen in diese Kategorie.

Wöchentliche Sprints Meist 2-4 Wochen im Voraus wird durch die Projektmanager aus den laufenden Projekten und etlichen Tickets ein wöchentlicher Sprint zusammengestellt und gleich einzelnen Personen zugeordnet. Im so genannten Agile Board haben nun alle Projektbeteiligten einen Überblick über die anstehenden Aufgaben, kategorisiert nach Priorität. Die Tickets sind entweder wie erwähnt bereits zugeordnet oder aber „Unassigned“. So können am Projekt beteiligte Teammitglieder die Tickets selbst untereinander aufteilen.

Tägliche Bearbeitung der Tickets Auf Basis der für die Woche definierten Sprints wird je nach Priorität mit den wichtigsten Tickets begonnen. Der Status des Tickets wird dabei auf „In Progress“ gesetzt und auch im oben genannten Agile Board abgebildet. So bekommt jeder einen Überblick, woran gearbeitet wird. Dadurch entfallen täglich mehrmalige Nachfragen, woran gerade gearbeitet wird und was bereits gefixt wurde.

Gibt es Rückfragen oder Unklarheiten wird direkt das entsprechende Ticket kommentiert und einfach dem gewünschten Teammitglied zugeordnet. Dieses erhält eine Benachrichtigung und kann darauf direkt per Mail (wird im Ticket gespeichert) oder über die UI reagieren. So bleibt die gesamte Kommunikation an zentraler Stelle und ist nicht in Mails, auf Zetteln oder in den Köpfen verstreut.

Nach Umsetzung des Tickets wird der Status auf „Fixed“ gesetzt um zu signalisieren, dass vorerst alles fertig ist. Youtrack informiert automatisch die Projektverantwortlichen bzw. den/die ErstellerIn des Tickets und weist es zu. Ist die Umsetzung überprüft und vollständig wird das Ticket endgültig geschlossen. Sollte es noch etwas zu tun geben kann demenstprechend der Status wieder auf „Open“ gesetzt werden.

Durch die Integration von Youtrack mit unserem Continuous Integration System können Tickets auch mit einer entsprechenden Commit-Message geschlossen und auf „Fixed“ gesetzt werden. Dazu wird mein Kollege Sebastian in Kürze einen Beitrag schreiben.

Stolpersteine und Verbesserungspotenzial

Nur ein „bisschen“ Issue-Tracking, Projektmanagement und Continuous Integration funktioniert nicht wirklich. Wir haben festgestellt, dass es äußerst wichtig ist wirklich alles im System abzubilden und einzutragen – nur so ist sichergestellt dass die Flut von Informationen und Änderungswünschen im Zaum gehalten wird und der Überblick nicht verloren geht. Kundenanfragen via Mail oder Telefon sollten direkt eingetragen und damit dokumentiert werden.

Bei „nur kurz“ oder „geht das“ Nachfragen tendieren wir im Team teilweise noch dazu das System zu umgehen. Ist eine Frage oder Änderungswunsch trivial erscheint es uns manchmal keinen Sinn zu machen diese als Ticket einzutragen. Dass man mit einer scheinbar kurzen Nachfrage die Kollegen unter Umständen unterbricht und aus der Konzentration bringt (kostet wie oben bereits beschrieben bis zu 30 Minuten Arbeitszeit) ist einem in der Situation nicht klar. Da müssen wir uns noch strikter an den Workflow halten.

Für Tätigkeiten, die nicht direkt einem Ticket zuordenbar sind oder mehrere Tickets umfassen, fällt es oft schwer den tatsächlichen Aufwand zu erfassen bzw. ist einem nicht sofort klar, dass ein eigenes Ticket erstellt werden sollte. Zum Beispiel beim Testen des gesamten Projekts vor Live-Schaltung.

Fazit

Keine Frage, das System ist bereits jetzt eine enorme Effizienzsteigerung für unseren internen Workflow. Wir wollen es alle nicht mehr missen. Aufgrund der Flexibilität von Youtrack ist sichergestellt, dass wir nach und nach mit den richtigen Stellschrauben unseren Workflow weiter ausbauen und optimieren.