Umgang mit Scope Creep (mit Suze Haworth)

Lesen Sie das Transkript:

Wir testen das Transkribieren unseres Podcasts mit einem Software-Programm. Bitte entschuldigen Sie eventuelle Tippfehler, da der Bot nicht zu 100% korrekt ist.

Ben Aston:

Willkommen beim DPM-Podcast, in dem wir über die Theorie hinausgehen, um Expertenrat für ein besseres Management digitaler Projekte zu geben. Danke fürs Einschalten. Ich bin Ben Aston, Gründer des Digital Project Manager. Wenn es eine Sache gibt, die fast jedes Projekt entgleisen lässt, dann ist es Scope Creep. Wir alle wissen, dass es problematisch ist. Wir alle wollen es vermeiden. Aber wie erkennt man es in all seinen Erscheinungsformen? Was sind die Ursachen? Wer ist schuld daran? Und vor allem: Wie geht man eigentlich damit um? All das werden wir im heutigen Podcast klären, in dem wir darüber sprechen, wie man mit Projekten umgeht, bei denen sich der Umfang schleichend erweitert.

Dieser Podcast wird Ihnen präsentiert von Clarizen, dem Marktführer für Projekt- und Projektmanagementsoftware für Unternehmen.

Mehr erfahren auf clarizen.com

Ich spreche heute mit Suze Haworth. Suze ist eine unserer DPM-Expertinnen bei The Digital Project Manager, und sie arbeitet als freiberufliche Senior Digital Project Managerin in London, Großbritannien. Sie hat mehr als 10 Jahre Erfahrung in Agenturen und schon viele Scope-Creeps erlebt – daher ist sie die perfekte Gesprächspartnerin. Willkommen, Suze.

Suze Haworth:

Hallo Ben.

Ben Aston:

Suze, wir haben uns ja vor der Aufnahme schon ein bisschen unterhalten. Kannst du uns kurz erzählen, an welchen Projekten du momentan arbeitest und welche Herausforderungen du dabei hast?

Suze Haworth:

Ja, ich arbeite zurzeit freiberuflich für eine Agentur in London und bin zwischen der Rolle als Senior Project Manager und Projektleiterin aufgeteilt – für zwei Kunden. Einer davon ist IKEA, im Bereich Einzelhandel und E-Commerce. Für sie entwickeln wir ein Designsystem – eine Art Prototyp dieses Systems. Und dann arbeite ich noch für einen weiteren großen E-Commerce-Händler im Vereinigten Königreich. Im Moment drehen sich viele meiner Projekte um den Einzelhandel. Die Herausforderungen – tja, es ist immer schwierig, über Herausforderungen zu sprechen, wenn man gerade mitten drin steckt.

Ben Aston:

Ist es vielleicht der schwierige Kunde?

Suze Haworth:

(lacht) Nein, tatsächlich nicht. Die Kunden sind im Moment wirklich toll, das muss ich sagen.

Ben Aston:

Das musst du auch!

Suze Haworth:

Es stimmt aber wirklich! Ich arbeite gerade mit sehr guten Kunden. Das Schöne und Schwierige an Projekten und an der Rolle als Projektmanagerin ist ja, mit verschiedensten Menschen zusammenzuarbeiten – mit all ihren Eigenheiten. Das macht Spaß, aber manchmal ist es auch frustrierend, wenn man auf Ergebnisse warten muss oder Leute nicht motiviert bekommt. Das habe ich kürzlich wieder erlebt.

Ben Aston:

Spaß und Spiele also. Dann erzähl mal vom Projekt Designsystem, denn ich finde das sehr spannend. Früher wollten viele jedes Projekt individuell behandeln, die Kreativen unbedingt kreativ sein. Erzähl uns: Was ist ein Designsystem? Woran arbeitet ihr genau? Und wie rollt ihr das aus?

Suze Haworth:

Ja, das ist wirklich spannend, weil Designsysteme in der digitalen Welt immer wichtiger werden. Sie sind so etwas wie ein Style-Guide oder eine Bibliothek für das digitale Design eines Unternehmens oder einer Marke. Es werden Standard-Komponenten, Module und Templates definiert, die jede:r Designer:in oder Entwickler:in für diese Marke nutzen kann. Dadurch wird ein einheitlicher Standard gesetzt, der Effizienz und Konsistenz fördert: wiederverwendbarer Code und ein einheitliches Design im Unternehmen.

Gerade bei großen Marken wie IKEA mit vielen Agenturen und Organisationen sorgt ein solches System dafür, dass zum Beispiel ein Call-to-Action-Button überall gleich aussieht – auf allen Plattformen, Geräten und Apps.

Ben Aston:

Erzähl uns doch bitte etwas zum Ablauf und Management solcher Projekte – die sind ja manchmal schwer abzugrenzen. Wie beginnt ihr? Wie läuft die Iteration? Wo ist die Grenze?

Suze Haworth:

Bei IKEA ist interessant, dass sie dieses Projekt nicht intern machen, sondern sich externe Hilfe holen – wir also mitgestalten dürfen. Das ist ein cleverer Ansatz, weil wir als Externe objektiv draufschauen können. Wir starteten konzeptionell: haben Grundprinzipien, digitale Leitlinien und die Designphilosophie von IKEA analysiert. Also zunächst ein strategischer, konzeptioneller Blick auf das Erlebnis und den Markenkern. Danach haben wir den Basis-Design-Stand anhand vorhandener Elemente (Farben, Typografie, Rastersystem etc.) gesetzt und weiterentwickelt.

Anschließend folgte User-Testing dieses Designs auf ein paar ausgesuchten IKEA-Plattformen. Daraufhin haben wir konkrete Komponenten entworfen und auf einer internen Designsystem-Website bereitgestellt. Zunächst geht es um einen vielseitigen Prototyp. Im Anschluss wird dieser zu einer vollumfänglichen Lösung weiterentwickelt.

Ben Aston:

Was bedeutet diese „Voll-Lösung“? Ist das ein lebendiger Styleguide, aus dem man Snippets oder Templates direkt entnehmen kann?

Suze Haworth:

Ja, genau das sollte ein Designsystem sein: ein kontinuierlich wachsendes und gepflegtes Werkzeug. Es gibt kein definiertes Ende. Wir stehen noch am Anfang: Grundprinzipien, Basiselemente, Komponenten. Von da werden sie gruppiert, zu Modulen und später zu Templates, und man überlegt, wie man die Leute dazu bringt, es wirklich anzuwenden. Gerade bei so vielen Beteiligten ist das ein riesiges Projekt. Wir sind also fast noch beim Start – obwohl wir schon seit fast einem Jahr daran arbeiten.

Ben Aston:

Klingt nach Spaß! Gibt es Tools, die dir aktuell das Leben erleichtern oder neue Erkenntnisse, die du teilen möchtest?

Suze Haworth:

Ehrlich gesagt nutze ich aktuell keine neuen Tools, bleibe lieber beim Bewährten. Ironischerweise höre ich aber inzwischen vermehrt Podcasts (ausgerechnet, wo wir in einem Podcast sind!). Auf meinem Arbeitsweg höre ich statt Musik nun mehr Podcasts – um die Zeit sinnvoll zu nutzen und nebenbei Neues zu lernen.

Ben Aston:

Gab es konkrete Podcasts, die du besonders hilfreich findest?

Suze Haworth:

Natürlich höre ich als erstes den Digital Project Manager Podcast. Letztens war ich im Drunken ... Podcast, nach meinem DPM Summit Vortrag, und habe über mein Thema gesprochen. Bei der Bureau of Digitalist Community gibt es auch spannende Sendungen, z.B. „Sprints and Milestones“ von Brett, basierend auf seinem Buch zu Digital Project Management – eine tolle Ressource.

Ben Aston:

Empfehlenswert! Was ich neu entdeckt habe: Blinkist. Kennst du das? Ich höre zwar kaum andere Podcasts als meine eigenen – aber manchmal denke ich, ich sollte mehr lesen ... Dann kaufe ich Bücher und lese sie doch nie zu Ende. Blinkist fasst Sachbücher in 15 Minuten zusammen – per Audio oder Text.

Suze Haworth:

Ja, davon habe ich gehört!

Ben Aston:

Man kann sie sogar schneller abspielen – also quasi ein Buch in sieben Minuten durchgehen.

Suze Haworth:

Super, das muss ich ausprobieren. Ich nehme mir sowieso vor, mehr zu lesen!

Ben Aston:

Das ist mein Buch-Tipp für euch alle. Cool. Aber eigentlich wollten wir heute ja über Scope Creep sprechen. Für alle, denen der Begriff nichts sagt – was ist das und warum ist das relevant?

Suze Haworth:

Im Grunde ist Scope Creep, wenn der Umfang eines Projekts, also die Anforderungen oder Liefergegenstände, über das ursprünglich Vereinbarte hinauswächst – ohne, dass Mehraufwände für Zeit oder Budget eingeplant wurden. Das kann in ganz verschiedener Form passieren. Es schleichen sich Aufgaben ein, die Projektlaufzeit verlängert sich und das Projekt wird größer als gedacht.

Ben Aston:

Genau: Zusatzarbeit, die wir nicht vorgesehen haben. Sie wirkt sich auf Budget, Zeitplan und Umfang aus. Das hat viele Ursachen. Im Artikel dazu stehen sie sehr ausführlich, daher gehen wir nicht auf alle ein. Welche sind für dich die typischsten – und die „hinterhältigsten“?

Suze Haworth:

Die häufigste Ursache ist Unklarheit über den Projektumfang zu Beginn. Wenn die Anforderungen oder das Statement of Work zu vage formuliert sind, kann jeder – ob Kunde oder intern – sie unterschiedlich interpretieren. Dadurch wächst der Projektumfang schnell. Daher ist es enorm wichtig, die Anforderungen und Erwartungen an die Lieferergebnisse klar zu definieren und auch klar zu kommunizieren.

Oft werden solche „Leistungsbeschreibungen“ zwar von Kunden unterschrieben, aber nicht immer verstanden. Deshalb sollte man die wichtigsten Punkte im persönlichen Gespräch explizit erläutern – nicht nur hoffen, dass Kunden die Dokumente lesen und wirklich verinnerlichen.

Hier passieren erfahrungsgemäß viele Missverständnisse: Das Statement of Work wird zwar akzeptiert, aber später sagen Beteiligte, dass sie etwas anderes erwartet hatten, selbst wenn es klar und deutlich dort steht.

Ben Aston:

Ja – also Unklarheit zu Beginn, oder das Problem der Kommunikation. Häufig fehlt die Definition, was z.B. eine Page-Template wirklich beinhaltet. Oder man ist nicht klar genug, was der Kunde erwarten darf.

Suze Haworth:

Exakt. Es sind zwei Ebenen: Zum einen die exakte Definition der Ergebnisse, zum anderen das Sicherstellen, dass der Kunde sie auch versteht. Sonst gibt es Fehlannahmen über den tatsächlichen Umfang.

Ben Aston:

Also: Unklarheit und Missverständnisse zu Projektbeginn sind die allerhäufigsten Ursachen. Aber was ist mit den „hinterhältigen“ Fällen – wo Scope Creep unbemerkt passiert? Was hast du da erlebt?

Suze Haworth:

Viele denken, Scope Creep entsteht nur durch Kunden, die immer mehr wollen. Tatsächlich kommt er oft auch aus dem eigenen Team. Wenn die Teammitglieder nicht genau wissen, was zu tun ist, arbeiten sie manchmal eigenmächtig und weiten Versäumnisse oder Features aus – häufig unbeabsichtigt. Beispielsweise kann ein:e Designer:in Elemente entwickeln, die später in der Entwicklung viel mehr Aufwand bedeuten. Oder interne Stakeholder bringen zusätzliche Business-Anforderungen mit ein oder bestätigen dem Kunden etwas, was gar nicht vorgesehen war.

Das überrascht oft, weil man davon ausgeht, intern sind alle auf derselben Linie – das ist aber nicht immer so! Manchmal werden (ohne Absicht) Zusatzfunktionen entworfen, weil jemand ein persönliches Interesse daran hat oder etwas besonders „herausragend“ gestalten möchte.

Ben Aston:

Ich kann das bestätigen: Häufigster Auslöser ist „Gold Plating“ – wenn interne Teams Dinge über das ursprünglich Vereinbarte hinaus verschönern wollen, um das eigene Ego oder Portfolio aufzubessern. Das passiert oft im Design, UX, bei der Entwicklung. Wer zahlt für diesen extra Aufwand?

Suze Haworth:

Genau.

Ben Aston:

Wer übernimmt die Verantwortung? Unkoordinierte Einzelaktionen führen zu Unklarheiten. Ein wichtiger Punkt ist auch das Thema QA. Oft fehlen am Anfang die genauen Akzeptanzkriterien und dann testet jemand auf exotischen Geräten wie Blackberry oder Browsern wie IE9, die nie vorgesehen waren, und plötzlich stecken Entwickler in endlosen Bugfixes für Dinge, die irrelevant sind. Kennst du das?

Suze Haworth:

Absolut! Vor allem im QA-Bereich kann der Aufwand explodieren, wenn nicht vorab Browser-/Gerätematrix, Bug-Priorität und Akzeptanzkriterien klar festgelegt werden. Je weniger Vorgaben es gibt, desto größer wird der Testaufwand und die Zahl der Korrekturen. Daher: Bugs priorisieren, device matrix festlegen und genau regeln, welche Fehler kritisch sind. Die Kommunikation mit den Stakeholdern muss offen und frühzeitig über diese Themen laufen. Auch Alternativen aufzeigen, wenn ein Aufwand z.B. für einen bestimmten Browser zu hoch wird.

Wichtig ist: Scope Creep möglichst direkt und ehrlich adressieren – und immer Lösungsvorschläge präsentieren, wenn neue Anforderungen ungeplant dazu kommen.

Ben Aston:

Ja, das ist hilfreich. Also: Unklare Anforderungen, internes „Gold Plating“, QA – drei Hauptquellen für Scope Creep. Aber wessen Schuld ist das – und wie gehen wir damit um?

Suze Haworth:

Es geht nicht um Schuld, sondern um ein gutes Risikomanagement. Wenn man weiß, von welchen Seiten Scope Creep kommen kann, kann man auch besser vorbeugen. Wir PMs neigen selbst dazu, Probleme lieber „unter den Tisch zu kehren“ als sie offen zu kommunizieren – aus Angst vor negativen Reaktionen. Ich habe das selbst gemacht.

Es ist aber besser, ehrlich zu sein, Probleme frühzeitig zu markieren und direkt mit Lösungsvorschlägen auf den Kunden zuzugehen. Vor allem nicht versuchen, Anforderungen heimlich „einzuschlucken“ – sondern zusammen mit dem Kunden entscheiden, wie der Mehraufwand priorisiert oder abgebaut werden kann.

Ben Aston:

Da sind wir schon beim Umgang mit Scope Creep ...

Suze Haworth:

Sorry.

Ben Aston:

Kein Problem. Wichtig ist: Je klarer die Scope-Definition, desto weniger Risiken. Hole dir Feedback aus dem Team oder QA, Business Analysten, die Schwachstellen in SOWs aufdecken. Gerade am Anfang hilft es enorm, alles im Gespräch zu klären, statt einfach auf die Unterschrift zu hoffen.

Gleichzeitig ist frühe Transparenz im Projektverlauf essenziell: Viele PMs haben Angst vor unangenehmen Kundengesprächen und hoffen, dass Scope Creep von allein verschwindet. Das ist selten der Fall. Proaktives Informieren und Priorisieren hilft, aus Scope Creep ein lösbares Problem zu machen.

Wir haben bisher viel von „klassischen“ Projekten gesprochen – wie sieht Scope Creep bei agilen Projekten aus?

Suze Haworth:

Das war mir in meinem Artikel wichtig: Scope Creep gilt vor allem bei Wasserfall-Projekten als Problem, aber auch agile Projekte sind davon betroffen. Agile Methoden fordern geradezu, auf Veränderungen einzugehen – das ist ausdrücklich erwünscht, Stichwort: „embracing change“. Dennoch muss bei Scrum z.B. jedes Sprint-Backlog gegen Zusatzanforderungen, die der Kunde im Lauf des Sprints einbringt, abgewogen und ggf. umgeplant werden. Es darf nicht passieren, dass einfach immer neue Items dazu kommen. Stattdessen muss sauber re-priorisiert – ggf. anderes abgewählt werden. In kleinen Zeitfenstern lassen sich Änderungen besser auffangen, aber sie müssen trotzdem gesteuert werden.

Ben Aston:

Das ist ein guter Punkt: Scope Creep muss kein Drama sein – im agilen Kontext kann er sogar zur besseren Lösung beitragen, solange Änderungswünsche transparent gemacht und als gemeinsames Ziel betrachtet werden.

Wenn das Projekt dann dennoch aus dem Ruder läuft – Overbudget, verspätet, Scope explodiert – was ist dein wichtigster Tipp, um wieder Kontrolle zu gewinnen?

Suze Haworth:

Wenn du ein neues Projekt übernimmst, ist die beste Prävention eine solide Schätzung gemeinsam mit dem Team – also kollegiale Planung und realistische Aussage über Aufwand und Ressourcen. Wird ein laufendes Projekt übernommen, verschaffe dir einen Überblick und prüfe, wie viel noch ansteht. Dann: Ehrliche, offene Kommunikation mit dem Kunden – damit gemeinsam priorisiert und Lösungen gefunden werden können.

Ben Aston:

Super, Suze – vielen Dank für das Gespräch! Als DPM-Expertin bist du übrigens bald in unserem neuen Kurs dabei: Mastering Digital Project Management. Ein siebenteiliges Intensiv-Training mit Video-Lektionen, Aufgaben, Webinaren, Gruppendiskussionen und Coaching. Schau auf DPMschool.com vorbei und melde dich an, bevor die Plätze weg sind! Und wenn du deine Meinung zum Thema Scope Creep teilen möchtest – kommentiere gern und besuche unsere Ressourcenseite oder tritt unserem Slack-Team bei. Bis zum nächsten Mal – danke fürs Zuhören.