Starte Deine Projekte Richtig (mit Suze Haworth)

Das Transkript lesen:

Wir probieren aus, unsere Podcasts per Software-Programm zu transkribieren. Bitte entschuldigt eventuelle Tippfehler, da der Bot nicht immer 100% korrekt arbeitet.

Ben Aston:

Willkommen beim DPM-Podcast, bei dem wir über Theorie hinausgehen, um Expertenratschläge zum Führen besserer digitaler Projekte zu geben. Danke, dass ihr zuhört. Ich bin Ben Aston, Gründer des Digital Project Manager.

Wir wissen alle, dass der Beginn eines Projekts wirklich entscheidend für dessen Erfolg ist, aber es kann eine ziemlich knifflige Zeit sein. Es gibt viel Unklarheit, viel Verwirrung, viele Meinungsverschiedenheiten und jede Menge Unsicherheit. Als PM ist es unsere Aufgabe, das Projekt in Bewegung zu bringen und am Laufen zu halten – und Extrapunkte gibt es, wenn wir es auch noch in die richtige Richtung leiten. Aber was können wir tatsächlich tun, um sicherzustellen, dass wir den richtigen Kurs einschlagen? Dass wir Dinge richtig anstoßen? Genau darum geht es im heutigen Podcast. Höre also weiter zu, um herauszufinden, wie du deine Projekte richtig ins Rollen bringst.

Heute ist Suze Haworth bei mir. Hallo Suze.

Suze Haworth:

Hallo.

Ben Aston:

Suze ist eine unserer DPM-Expertinnen beim Digital Project Manager. Sie arbeitet als freiberufliche Senior Digital Project Managerin in London. Suze, warum erzählst du uns nicht ein wenig über einige Projekte, an denen du kürzlich gearbeitet hast?

Suze Haworth:

Ja. Also ich bin tatsächlich freiberufliche PM. Ich habe vor ein paar Wochen einen Vertrag abgeschlossen, der ziemlich langfristig bei einer Agentur war. Aber ich hatte dort zwei Hauptrollen. Eine war eher als Programmleiterin für ein Kundenkonto. Das war für Specsavers, einer sehr großen Einzelhandels-Brillemarke im Vereinigten Königreich, die auch in den Nordics und Australien tätig ist. Und da habe ich eine(n) Senior-PM im kreativen und UX-Bereich gemanagt, den digitalen Specsavers. Das war also ein ziemlich großes Arbeitsprogramm. Und dann habe ich noch an einem Projekt für Ikea gearbeitet. Das war ein Projekt zur Konzeption und Entwicklung eines Prototyps für ein Designsystem der Marke.

Ben Aston:

Cool. Also Specsavers, das klingt mehr nach einem E-Commerce- und Conversion-Optimierungsprojekt?

Suze Haworth:

Ja. Es kam sehr auf den Markt an, aber sie verkaufen tatsächlich nicht online, wegen bestimmter Vorschriften. Vieles zielt daher darauf ab, die Leute dazu zu bringen, Termine zu buchen und in die Filialen zu gehen. Aber ja, es geht sehr viel um Conversion-Optimierung, wie du sagst.

Ben Aston:

Ja. Was war an diesen Projekten schwierig? Welche Herausforderungen hast du mit dem Projekt, den Kunden oder dem Team erlebt? Ich glaube, es ist für viele interessant zu hören, dass auch andere mit ähnlichen Problemen kämpfen. Was war schwer?

Suze Haworth:

Ja. Beim Specsavers-Arbeitsprogramm war es wirklich eine interessante Zeit, als ich eingestiegen bin, denn das war im März, also zu Beginn des neuen Jahres, und wir sind auf eine völlig neue Arbeitsweise umgestiegen. Bis dahin hatten wir als Designagentur gemeinsam mit deren Entwicklungsagentur gearbeitet und saßen in deren Scrum-Teams, also ein Zweierteam aus Designer:in und UX in jedem Scrum-Team ihrer Arbeitsströme. Dann haben wir beschlossen, alle unsere Designer:innen und UX‘ler:innen aus den Scrum-Teams rauszunehmen und als ein Team auf unserer Seite zu bündeln. Gleichzeitig sind wir auf einen Dual-Track-Prozess umgestiegen: Wir betrieben einen Entdeckungspfad, der quasi über dem Auslieferungspfad lag – letzterer war das Scrum-basierte Entwicklerteam.

So konnten wir mehr Raum für Nutzer-Testing, Exploration, Hypothesen aufstellen und Annahmen testen, also viel mehr Forschung und Daten einfließen lassen. Das hat uns mehr Handlungsspielraum verschafft, tatsächlich Dinge zu liefern, die die Nutzer:innen auch wirklich brauchen. Es war spannend, diese neue Arbeitsweise einzuführen und zum Laufen zu bringen. Das war eine Herausforderung, aber auch sehr aufregend.

Ben Aston:

War deine Rolle dann die … Wessen Rolle war das? Die des Product Owners? Es gibt also diese zwei parallelen Arbeitsstränge – einer für Strategie, UX und Design; ich vermute, dort findet das Nutzer-Testing statt, die Nutzerbedürfnisse werden identifiziert und priorisiert, manche davon gehen dann an UX und Design, wo sie für die Entwicklung vorbereitet werden. Lief das so?

Suze Haworth:

Genau. Wir haben festgestellt, dass das Zusammensitzen von Design- und UX-Duo im Scrum in den zweiwöchigen Sprints ziemlich bremsend war, und oft mit technischen Details belegt wurde. Da saßen sie in langen Sprint-Planungs-Meetings, beteiligten sich aber nur in kleineren Teilen, oder in Stand-Ups, in denen es oft um Bugs ging, statt um Nutzerbedürfnisse – das Ganze wurde technisch dominiert. Die Entscheidung war, sie aus den Sprints zu nehmen und darüber einen eigenen „Entdeckungsstrang“ laufen zu lassen, so dass wir gezielt Zeit für Research, vorhandene Daten und das Identifizieren von Annahmen und Hypothesen hatten, um Nutzerprobleme zu lösen.

Anschließend konnten wir schnell testen, ob neue UX-Designs, Prototypen oder andere Maßnahmen zum Bedarf passen und bereits vor der eigentlichen Auslieferung Nutzerfeedback einholen. Ziel war, nicht am Nutzer vorbei zu entwickeln. Wir haben weiter Technikleute im Discovery-Track eingebunden, aber erst, wenn es darum ging, ob eine entwickelte Funktion auch technisch umsetzbar ist. Es ging uns darum, den Prozess zu straffen und kundenorientierter zu machen, statt sich an technischen Machbarkeiten zu orientieren. Weißt du, was ich meine?

Ben Aston:

Ich glaube, das ist für viele Agenturen eine Herausforderung, die Scrum anwenden möchten. Scrum ist ganz sicher nicht die einzige Möglichkeit, ein agiles Projekt zu führen, aber es ist die gängigste. Was dabei oft problematisch ist: Was machen UX und Design eigentlich im Sprint? Entweder sie sind zwei Sprints voraus – aber dann ist nichts zum Ausliefern fertig. Eigentlich sollte das Sprintende ja ein auslieferbares Ergebnis bereitstellen, das Akzeptanzkriterien erfüllt, und das ist in zwei Wochen extrem schwer zu erreichen, wenn noch Strategie, UX und Design im selben Zeitraum passieren sollen.

Deshalb gefällt mir dieser Ansatz: Die Streams werden parallel geführt, und erst wenn Features validiert sind, übernimmt der Product Owner sie ins Entwicklung-Backlog. Es gibt also quasi zwei Backlogs: einen für Strategie („Ist das überhaupt richtig, was wir machen?“) und einen fürs Umsetzen („Okay, das wollen die Nutzer, jetzt bauen wir es.“). Das löst tatsächlich einige typische Probleme.

Suze Haworth:

Genau. Das Entscheidende ist, dass wir wirklich validierte Features bauen, die Nutzer:innen wollen – viel weniger Verschwendung, effizienter und einfach besser, finde ich.

Ben Aston:

Super. Sprechen wir mal über Projektinitiierung und den eigentlichen Projektstart. Mich würde interessieren, bei Ikea oder Specsavers: Warst du jeweils schon von Anfang an dabei?

Suze Haworth:

Bei Specsavers – das war ein Jahr lang mit klar festgelegtem Team – kam ich hinzu, als die Arbeitsweise schon lose definiert und das Scope geschrieben war. Das ist eine Herausforderung, die ich in meinem Artikel beschreibe: Wenn man ein Projekt übernimmt, das jemand anderes bereits gestartet oder umrissen hat. Ich kam ziemlich zeitnah nach der Scope-Definierung dazu, aber bei den Workflows gab es definitiv Anpassungsbedarf, und manches hat sich im Lauf der Zeit ebenfalls verändert.

Bei Ikea war ich in Stufe zwei dabei, Stufe eins hatte bereits begonnen, als ich dazukam.

Ben Aston:

Und das ist ja oft so, dass wir als PMs Projekte nicht ganz vom Anfang an übernehmen. Man übernimmt etwas, das bereits vorbereitet oder vom BD- oder Sales-Team übergeben wurde, und oftmals sind Dinge nur grob geplant. Genau darüber sprechen wir heute: Projektinitiierung, egal ob vom allerersten Moment oder mittendrin.

Lass uns über die Stichworte aus deinem Artikel reden: Du schreibst, dass es beim Starten der Projekte darum geht, die Menschen, den Prozess und das Produkt unter einen Hut zu bringen – also das Wer, das Wie und das Was. Fangen wir mit dem Wer an: Was tust du, wenn du neue Projekte anstößt oder in laufende einsteigst, aus Perspektive der beteiligten Personen?

Suze Haworth:

Wie gesagt, es gibt ein paar Kernfragen bezüglich der Menschen im Projekt. Zunächst geht es ums Team: Wer arbeitet daran? In der Initiierungsphase stellt man das Team zusammen, versucht Leute zu buchen und zu bestimmen, wer wirklich am Projekt teilnehmen soll. Dabei zählt nicht nur, wer verfügbar ist, sondern auch, wer wirklich geeignet ist – von Fähigkeiten über Arbeitsweisen bis zum Projekttyp und zum Kundentyp.

Kennt man sein Team bereits, hilft es natürlich, die ideale Besetzung herauszufiltern – oft ist das Luxus, aber schon ein Bewusstsein über die Arbeitsweise einzelner kann später helfen, eventuelle Probleme zu vermeiden.

Dazu gehört auch, dass alle Teammitglieder möglichst früh eingebunden werden. Was die meisten, wenn nicht alle, Designer, Entwickler oder QAs an Projekten hassen: Wenn man sie erst dazu holt, wenn alles schon definiert und entschieden wurde und sie dann nur noch irgendetwas bauen oder gestalten sollen. Das nimmt ihnen jede Eigenverantwortung und erzeugt Frust.

Wenn es Zeit und Budget erlauben, ist es daher wirklich hilfreich, sie frühzeitig (wenigstens ein bisschen) einzubinden. Also nach dem ersten internen Kick-off-Meeting offen reden: Was halten sie vom Projekt? Was sind die Erwartungen? So sind alle von Anfang an dabei.

Ben Aston:

Absolut, und das betrifft auch das Thema Team-Resourcing: Je früher man das Team zusammenbringt und einbindet, desto besser ist das Buy-in. Wenn Menschen einfach etwas übernehmen sollen, ohne eingebunden gewesen zu sein, sind die Resultate meist schwach. Eigentum und Identifikation mit dem Projekt führen zu viel besseren Ergebnissen.

Suze Haworth:

Ganz genau.

Ben Aston:

Kommen wir zum Prozess, der damit verknüpft ist: Wir haben jetzt unser Team. Wie nutzen wir es optimal, um das Projekt zu liefern? Du hast bei Specsavers die anfänglichen Unstimmigkeiten angesprochen – oft gibt es Uneinigkeit über geplante Prozesse, Methoden oder Tools. Wie gelingt es dir, hier gemeinsam mit dem Team einen Weg zu finden?

Suze Haworth:

Man wird wahrscheinlich nie einen Prozess finden, der für alle gleichermaßen perfekt passt – Konflikte gibt es immer. Manchmal wird ein Prozess von der Agentur oder vom Kunden vorgegeben. Wenn man selbst entscheiden kann – umso besser, dann kann man es noch besser auf Team und Kunde abstimmen. Gibt es einen vorgegebenen Prozess, hilft es, beim internen Kickoff-Meeting zu erklären und zu begründen, warum diese Methode gewählt wurde, um möglichst frühzeitig Akzeptanz zu schaffen.

Ebenso wichtig ist es, Prozesse unterwegs zu adaptieren. Klammern an etwas, das nicht funktioniert, bringt niemanden weiter. Das Team sollte wissen, dass Kritik an Tools oder Kommunikationswegen offen geäußert werden kann, damit man gemeinsam Anpassungen vornehmen kann.

Ben Aston:

Flexibilität ist da tatsächlich entscheidend. Oft kleben Leute dogmatisch an Methoden („So geht Scrum“, „Das ist nicht agil“, „Das ist zu Wasserfall-mäßig“), aber was zählt ist: Was funktioniert für dieses Team, dieses Projekt und diesen Kunden am besten? Nicht eine Methode stur anwenden, sondern mit allen Beteiligten den besten Weg finden.

Jedes Projekt ist verschieden, auch wenn Standardprozesse für Routinejobs sinnvoll sind. Aber bei Neukunden und neuen Projekten ist Flexibilität Pflicht.

Damit kommen wir zum Was: Zu Projektbeginn ist das oft am schwierigsten, weil man meist nur ein grobes Scope von Sales bekommt. Wie gehst du dabei vor, um aus dieser Unklarheit herauszukommen?

Suze Haworth:

Das hängt sehr vom Projekttyp ab. Ich finde es sinnvoll, Scopes so zu halten, dass Änderungen möglich sind. Aber es gibt natürlich auch sehr starre Projekte. Wichtig ist, mit dem Kunden die Anforderungen zu klären – Nutzer- und Unternehmensbedürfnisse abfragen und das Projektkontext verstehen.

Diese Anforderungen müssen dann möglichst früh mit dem Team besprochen werden. Schon vor dem finalen Projektteam sollte man ein bis zwei Disziplinleiter:innen oder Hauptteammitglieder einbinden, um gemeinsam zu klären, was möglich ist und wie es zu gestalten wäre.

Ben Aston:

Mir hilft es, solche offenen Fragen mit dem Team in einem halbtägigen Workshop – mit Whiteboard und Post-its – anzugehen, einfach auf grober Ebene das Lösungskonzept zu erarbeiten. Dadurch schaffen wir ein gemeinsames Verständnis davon, was eigentlich gemeint ist, identifizieren unterschiedliche Erwartungen und können später gezielt Rückfragen an den Kunden stellen. So kommt Struktur rein.

Das große Bild auf dem Whiteboard dient dem Team als Referenz – darauf wird später immer wieder Bezug genommen. Es hilft enorm, gleich zu Beginn alles zu visualisieren.

Suze Haworth:

Definitiv. Solche Workshops – intern und später mit dem Kunden – bringen extrem viel, um sich gegenseitig abzugleichen.

Ben Aston:

Also: Wer, wie, was – Team, Prozess und Lösungsidee; plus Budget, Timing, Erfolgskriterien. Alles am Anfang auf das große Whiteboard – selbst wenn es noch viele Änderungen geben wird.

Oft ist Projektinitiierung aber auch schon vor der offiziellen Freigabe gefragt. Wo ist da die Grenze? Wie gehst du mit dem Spannungsfeld zwischen „vorausschauend vorbereiten“ und „nicht zu viel vorwegnehmen, falls doch alles anders kommt“ um?

Suze Haworth:

Ich bin da eher vorsichtig und gehe offen mit dem Kunden um: Wenn sie bei der Freigabe trödeln, kläre ich die Auswirkungen auf Zeit und Projektverlauf. Risiken der Unklarheit offenlegen, dennoch alles Nötige für den späteren Kick-off vorbereiten.

Trotz Vorsicht: Es ist gut, erste Schritte zu machen und das Momentum oben zu halten. Wenn das Team frühzeitig mit Vorüberlegungen dabei ist, bleibt die Motivation hoch und das Projekt präsent – sonst besteht die Gefahr, dass alle sich anderen Aufgaben zuwenden.

Ben Aston:

Was tust du, wenn durch Verzögerungen der Schwung verloren geht und der Projektstart ins Stocken gerät?

Suze Haworth:

Schwierig – vor allem, wenn das Team schon gebucht ist, aber noch nicht offiziell anfangen kann. Falls ein wenig Zeitbudget da ist, ist es sinnvoll, das Team mit etwas Recherche- oder Konkurrentenanalyse zu beschäftigen, um gedanklich am Ball zu bleiben, auch wenn sie noch nicht voll einsteigen können.

Ben Aston:

Oft hilft schon ein kurzes Team-Meeting, um alle auf Stand zu halten und das Projekt nicht ganz aus dem Blick zu verlieren.

Suze Haworth:

Es gibt nichts Schlimmeres, als plötzlich nach Wochen wieder ein Projekt hochzuholen. Kontinuierliche Kommunikation, transparente Gründe für Verzögerungen und klare Information über den Stand sind wichtig.

Ben Aston:

Kommen wir zum Thema, das viele Projektmanager:innen betrifft: Das Übernehmen eines laufenden Projekts, bei dem du die Pläne zu Team, Prozess und Produkt von jemand anderem erbierst. Hast du Tipps, wie man in diesem „Durcheinander“ schnell klarkommt?

Suze Haworth:

Das ist eine echte Herausforderung – weil du meist nicht bei der Konzeption oder bei der Akquise dabei bist, sondern übernimmst. Die Kosten sind oft vorgegeben, das Scope unscharf, also muss man schauen, was im Rahmen möglich ist, und gegebenenfalls Scopereduzierung, Zeitplanung o.ä. klären, um realistisch zu bleiben.

Wenn du ein Projekt von einer anderen PM übernimmst, sind zwei Dinge wichtig: Möglichst viel über das bisherige Projekt erfahren und einen Mini-Kickoff machen, mit dem Team und auch mit dem Kunden – quasi ein Neustart. Das hilft, auf gemeinsame Linie zu kommen und offene Fragen oder Problemfelder transparent zu machen. Das muss gar nicht lange dauern.

Ben Aston:

Dieser Neustart – Mut zum Reset – ist wertvoll. „Dumme“ Fragen als Neue:r zu stellen, eröffnet oft auch für andere Themen, die bisher nur angenommen, aber nie explizit benannt wurden. So kann man verborgene Probleme rechtzeitig aufdecken.

Suze Haworth:

Scheue dich nicht zu fragen! Das sage ich auch neuen PMs: Lieber einmal zu viel fragen als zu wenig – offene Fragen vermeiden böse Überraschungen später.

Ben Aston:

Das ist wirklich der Schlüssel: Kommunikation, auch unbequeme oder schwierige Themen ansprechen und klar herausfinden, was eigentlich gemeint ist. Nur so lassen sich Missverständnisse und unnötige Arbeit vermeiden. Suze, danke dir vielmals fürs Mitmachen!

Suze Haworth:

Danke, es war super.

Ben Aston:

Als eine unserer DPM-Expert:innen wird Suze auch in unserem neuen Kurs auftreten, der im Februar startet: Mastering Digital Project Management – ein siebentägiger Intensivkurs mit interaktiven Video-Lektionen, Podiumsdiskussionen und optionalen Coachingsessions. Wenn du Projektstarts noch besser machen möchtest, schau auf DPMSchool.com vorbei und melde dich schnell an, bevor die Plätze weg sind. Willst du dich zum Thema Projektstart austauschen, diskutiere hier im Beitrag mit oder gehe im Ressourcenbereich von DigitalProjectManager.com in unser Slack-Team – dort wird intensiv über Projektinitiierung und Projektmanagement diskutiert. Bis zum nächsten Mal, danke fürs Zuhören.