Mit Projektscope-Statements Deinen Speck retten (mit Robyn Birkedal)

Lies das Transkript:

Wir probieren es aus, unsere Podcasts mit einem Software-Programm zu transkribieren. Bitte entschuldige etwaige Tippfehler, die KI ist nicht immer 100 % korrekt.

Ben Aston:

Du bist nervös und hältst das Telefon mit schwitzigen Händen. Der Kunde ist sauer. Er droht am Telefon, das Projekt abzubrechen und nicht zu bezahlen. Dabei lief bisher alles so gut. Sie waren völlig entspannt – genauso wie du. Sie wollten ihre Website neu gestalten. Klang einfach. Und du hast eigentlich gar nichts aufgeschrieben, weil… Nun, es fühlte sich einfach so an, als ob alle Bescheid wissen. Alle waren entspannt – jetzt nicht mehr. Was sie tatsächlich erwartet haben, war ein komplettes Rebranding oben drauf auf der neuen Website. Jetzt hast du ein flaues Gefühl im Bauch, weil du weißt, dass du es vermasselt hast. Nichts wurde festgehalten. Nun steht Aussage gegen Aussage. Schon das Erzählen stresst mich. Wenn du also künftig weniger Stress willst: Hör diesen Podcast und erfahre, warum Scope Statements so wichtig sind, wie man sie schreibt und in deinem Projekt nutzt.

Danke, dass du reinhörst. Ich bin Ben Aston, Gründer von The Digital Project Manager. Willkommen beim DPM Podcast. Unsere Mission: Projektmanager:innen zum Erfolg verhelfen, Menschen zu unterstützen, die Projekte besser umsetzen wollen. Wir helfen dir, dein Projekt-Game aufs nächste Level zu bringen. Schau auf thedigitalprojectmanager.com vorbei und entdecke unsere Trainings und Ressourcen für Mitglieder. Dieser Podcast wird präsentiert von Clarizen, dem führenden Anbieter von Software für Enterprise-Projekt- und Portfolio-Management. Besuche Clarizen.com für mehr Infos.

Heute ist Robyn bei mir. Robyn ist eine unserer DPM-Expertinnen. Und sie wohnt praktischerweise gleich um die Ecke. Sie liebt Emojis, Listen-Schreiben und Hunde. Robyn ist eine gelernte Köchin, die zum Projektmanagement wechselte – mit über 10 Jahren Erfahrung in Agenturen und Startups. Und bald hat sie wieder mehr Kapazitäten für freiberufliche Projekte. Wenn ihr also eine Projektmanagerin sucht: Auf LinkedIn findet ihr sie. Danke, dass du heute dabei bist, Robyn.

Robyn Birkedal:

Hi Ben. Immer schön, mit dir zu plaudern.

Ben Aston:

Ich will gleich mit einer deiner Listen und Hunden starten. Hast du heute eine Liste gemacht?

Robyn Birkedal:

Habe ich. Ich bin da ein Nerd. Ich habe eine Liste mit den heutigen Zielen, eine weitere im Planer und dann noch meinen Google Kalender. Offenbar brauche ich zu jeder Zeit drei verschiedene Listen. Hinter mir befindet sich übrigens eine Wand voller Post-its – mein Krimi-Board.

Ben Aston:

Sozusagen dein Listen-Archiv.

Robyn Birkedal:

Das sind verschiedene Kategorien, an denen ich privat und beruflich arbeite oder auch Ideen für Inhalte.

Ben Aston:

Hast du auch einen Hund bei dir?

Robyn Birkedal:

Ich habe meinen achtjährigen Hund hier, aber ich liebe Hunde eh deutlich mehr als Katzen – da kann jeder sagen, was er will. Emojis benutze ich inzwischen weniger begeistert. Das war wohl eine Phase.

Ben Aston:

Letztes Jahr war das noch anders.

Robyn Birkedal:

Stimmt.

Ben Aston:

Listen sind dir also wichtig. Wodurch lässt du dich inspirieren? Was liest oder konsumierst du aktuell, um dich zu motivieren?

Robyn Birkedal:

Oh, gute Frage. Darüber könnte ich lange reden. Die DPM-Community inspiriert mich immer. Ich war kurz nicht so aktiv im Slack, jetzt bin ich zurück – ich hab viele Freund:innen dort vermisst, das tut gut. Auch Freundeskreis und Community vor Ort geben mir viel. Ich möchte besonders die Gruppe PDXWIT (Portland Women in Technology) hervorheben. Eine tolle Community, die Veranstaltungen, Mentoring und Zugang zu Jobs bietet. Sie haben mir viel in Sachen Diversität und Inklusion beigebracht. Ich kann allen empfehlen, sich etwas ähnliches aufzubauen oder pdxwit.org zu besuchen.

Ben Aston:

Was willst du gerade besser können? In letzter Zeit haben wir ja alle etwas mehr Zeit nebenbei. Thema Masterclasses und Co.: Gibt’s etwas, was du dir gerade Neues vornimmst? Ein Hobby, eine Programmiersprache, oder tauchst du tiefer in etwas ein?

Robyn Birkedal:

Ich habe länger nicht mit Drupal gearbeitet – da hole ich gerade auf. Ansonsten ist das große Thema, Ben, das weißt du: Ich denke tatsächlich über neue Zertifizierungen nach, z.B. einen PMP oder ähnliche Standards. Ich muss noch herausfinden, was wirklich sinnvoll ist – mehr Fokus auf verschiedene Methoden zu bekommen als immer nur im eigenen Trott zu bleiben.

Ben Aston:

Viel Erfolg dabei! Gibt es sonst was, das dir aktuell kleine Glücksmomente im Alltag bringt?

Robyn Birkedal:

Das ist fast peinlich! Aber ich genieße Homeoffice wirklich. Im Hintergrund lasse ich oft einen gewissen Surf-TV-Sender auf YouTube TV laufen. Ich bin kein Surfer – der Strand ist 1,5 Stunden entfernt – aber diese Ambient Surf TV Championships laufen fast durchgehend. Ich bin inzwischen ein Fangirl vieler Surfer – Andy Irons, Kelly Slater und ihre Geschichten. Es ist das Merkwürdigste, was mein Leben grade „awesome“ macht.

Ben Aston:

Wer ist dein Lieblingssurfer?

Robyn Birkedal:

Definitiv Kelly Slater.

Ben Aston:

Den hab ich sogar mal in Hawaii beim Surfen getroffen ...

Robyn Birkedal:

Moment, das zählt so aber nicht.

Ben Aston:

Doch! Wir gingen gerade raus, da kam er mit seiner Freundin rein – wir haben uns gegrüßt. Also kann ich sagen: Ich war surfen mit Kelly Slater, oder?

Robyn Birkedal:

Also auf jeden Fall im selben Wasser.

Ben Aston:

Genau!

Robyn Birkedal:

Aber nicht auf den großen Wellen zusammen, oder ...

Ben Aston:

Klar. So, genug vom Strand, zurück zu Scope Statements! Warum sind Scope Statements so spannend? Hast du eigene Horror-Stories aus Projekten ohne Scope Statement?

Robyn Birkedal:

Oh ja! Schon bei deiner Einleitung hab ich alle Traumata wieder vor Augen. Scope Statements sind enorm wichtig, weil sie dafür sorgen, dass alle – Team und Kunde – das große Ganze verstehen. Sie definieren, wie Misserfolg aussieht und verhindern Konflikte – intern und mit dem Kunden. Sie sorgen für Ausrichtung und helfen, rechtliche Streitigkeiten zu vermeiden.

Ben Aston:

Wir wollen also für Klarheit und ein gemeinsames Verständnis sorgen. Scope Statements machen die Vereinbarungen konkret. Gerade bei guten Beziehungen denkt jeder, der andere hat verstanden, worum es geht. Doch Worte wie „update“ oder „refresh“ sind schwammig. Scope Statements reduzieren diesen Graubereich.

Robyn Birkedal:

Absolut. Und Begriffe ändern sich dauernd. Scope Statements zu schreiben ist zwar trocken & unbeliebt – aber lebenswichtig für einen effizienten Projektverlauf. Es kostet zu Beginn Zeit, spart aber hinterher viel Ärger.

Ben Aston:

Ganz genau. Was ist ein Scope Statement für dich?

Robyn Birkedal:

Es gibt viele verschiedene Begriffe – wie „refresh“ oder „redesign“. Im Kern beschreibt das Scope Statement das vereinbarte Arbeitspaket: Was wird geliefert? Was nicht? Welche Bedingungen und Annahmen gelten?

Ben Aston:

Scope Statements beschreiben und definieren die Aufgabenstellung. Manchmal ist das Ergebnis nicht klar – dann definiert man zumindest den Prozess. Oft reicht es schon, das Ziel und den Weg dahin zu definieren anstatt fertige Lieferobjekte zu beschreiben.

Robyn Birkedal:

Richtig. Es gibt aber keine Universallösung oder -vorlage für Scope Statements. Jedes Unternehmen, jedes Projekt tickt anders. Ziel ist Konsistenz, um dich und das Unternehmen abzusichern – oder wie ich sage: Deinen Speck zu schützen.

Ben Aston:

Hast du mal erlebt, dass du Scope Statements nicht detailliert genug definiert hast? Was ist passiert?

Robyn Birkedal:

Definitiv. In manchen Rollen wurde mir geraten, bewusst wenig Details aufzunehmen, um keinen juristischen Angriffspunkt zu bieten. Rückblickend hat es trotzdem meist geholfen, möglichst viel zu definieren – egal ob Wasserfall oder agil. Perfekt wird das nie. Es passieren immer mal Missverständnisse. Aber Erfahrung hilft.

Ben Aston:

Meine Horrorstory: Ein Großkunde wollte eigens angefertigte Animationen. Wir haben die Rechte für fünf Jahre gekauft – der Kunde bestand dann später aber auf „in alle Ewigkeit“. Die Agentur stieg uns aufs Dach, am Ende platzte die Kundenbeziehung, nur wegen eines schlecht definierten Scope Statements. Gerade so kleine Details können das ganze Projekt gefährden!

Von der Theorie zur Praxis: Wie gehst du das Schreiben von Scope Statements an? Versucht man, alles abzudecken oder möglichst offen zu bleiben?

Robyn Birkedal:

Zunächst mal: Ich bin keine Juristin, gebe hier nur persönliche Erfahrungen weiter. Zweitens – nochmal: kein Rechtsbeistand. Und drittens: Scope Statements können viele Namen haben: Kostenschätzung, Projektumfang, Vertrag, Angebot ... Aber nicht alles – wie NDA oder SLA – gehört dazu. Scope Statements sind nur ein Bestandteil.

Ben Aston:

Klar.

Robyn Birkedal:

Wie gehe ich vor? Ich nutze interne Vorlagen, halte eigene Versionen vergangener Scope Statements bereit, etwa für Branding-Projekte vs. Digitalprojekte. The Digital Project Manager ist eine tolle Quelle: Dort gibt es beispielsweise einen Artikel von dir, Ben, mit einer Vorlage fürs Statement of Work.

Ben Aston:

Super! Es lohnt sich also, eine eigene „Bank“ mit Scope Statements anzulegen, die man anpassen und wiederverwenden kann. Viele Elemente wiederholen sich bei ähnlichen Projekten. Thedigitalprojectmanager.com hält dazu gute Beispiele bereit. Manche kann man fast 1:1 übernehmen, andere brauchen mehr Anpassung.

So ein Scope Statement sollte klären: Wer zahlt für Bildrechte? Wie viel Feedback gibt es? Wie schnell muss der Kunde reagieren? Usw.

Lass uns über gute und schlechte Scope Statements reden. Es gibt das lockere und das sehr detaillierte Scope Statement. Was macht für dich ein gutes Scope Statement aus?

Robyn Birkedal:

Große Frage! Mein Tipp: Tauscht euch mit Kolleg:innen aus, nutzt die Community – fangt nicht immer bei null an! Ich kann dir fünf Punkte verraten, mit denen du deinen Speck rettest, Ben – magst du sie hören?

Ben Aston:

Ja, unbedingt!

Robyn Birkedal:

1. Definiere das „Warum“ – meist als Übersicht/Projektbeschreibung. Halte das prägnant, aber erkläre den Zweck, das Ziel und den Mehrwert des Projekts. Hole dazu am besten auch die Accountmanager ins Boot.

Ben Aston:

Das „Warum“ ist enorm wichtig, weil es als Rückversicherung dient. Wenn man nachweist, dass das Projektziel erreicht wurde, ist die Basis geschaffen. Zum Beispiel: Mehr Abos generieren – dann zählt das Resultat, selbst wenn dem Kunden die Ausführung nicht gefällt.

Robyn Birkedal:

Ganz genau. Hilft in jedem Ansatz, egal ob agil oder klassisch. Gut auch, das „Warum“ in Teamdokus (z.B. im Slack-Channel) zu verankern und herumzuschicken. 2. Definiere den Abnahmeprozess: Wie gibt der Kunde Feedback? Wer ist beteiligt? In welcher Form? Das wirkt banal, wird aber oft zum Problem. Lieber erst grob im Statement, später detaillieren – und immer parallel auch mündlich klären.

Ben Aston:

Absolut. Super Hinweis.

Robyn Birkedal:

3. Definiere, was du lieferst – meist der umfangreichste Teil. Egal ob Wasserfall („alles im Detail auflisten“) oder agil („Prozesse statt fester Ergebnisse“): Beschreibe möglichst konkret, was, wann und wie geliefert wird. Besonders wichtig: Anzahl Feedbackschleifen, Vertrags-Einstieg, Migration, Hosting, Konfig, QA, Bildrechte, Deployment.

Ben Aston:

Ich bin ebenfalls ein Fan davon, so viel wie möglich zu definieren. Und wenn du unsicher bist, lieber das sogenannte „Sandbagging“: Das Minimum festschreiben (z.B. zwei Konzepte), sodass am Ende keine Übererwartungen entstehen – lieber mehr liefern als versprochen, statt umgekehrt.

Robyn Birkedal:

Das habe ich auch schon erlebt. Es hilft auch nach innen, z.B. darin, dass Design oder Strategie sich auf bestimmte Workloads einstellen können. 4. Definieren, was enthalten ist – und vor allem, was nicht! Dafür ein eigenes Kapitel machen. Ich nenne das gern „Grenzen“. Dort schreibst du Annahmen, Abhängigkeiten (z.B. schriftliches Feedback nur von einer Seite), aber auch: Was passiert bei zweiten Deployments, Verschiebungen etc.? Bei Änderungen gibt’s Change Requests, alles Weitere steht dann in deinem Exclusions- oder Out-of-Scope-Abschnitt: Dinge, die der Kunde evtl. erwartet, du aber explizit NICHT lieferst (z.B. Hosting, Doku, Bildrechte auf Lebenszeit, Styleguides etc.).

Ben Aston:

Das sind sogenannte „Negative Scope Statements“. Es lohnt sich hier, alle Eventualitäten aus bisherigen Gesprächen aufzulisten, um spätere Missverständnisse zu vermeiden.

Robyn Birkedal:

Absolut. Es gibt kein Patentrezept, aber lieber zu viel als zu wenig absichern. Manchmal wirke ich da wie eine Katastrophen-Prophetin – aber es schützt das Projekt.

5. Ich liebe es, eine Scope-Statement-Matrix zu erstellen – auch wenn das kontrovers ist. Ich habe schon ewig lang alte Dateien durchsucht und so viel Zeit vergeudet. Eine Matrix (intern oder auch für den Kunden) hält immer fest, welcher Stand gerade gilt und was tatsächlich geliefert wird. So kann ich bei Streitigkeiten sofort alles belegen, statt lange zu suchen.

Ben Aston:

Eine Matrix macht Aussagen zum Scope Statement während des gesamten Projekts nachvollziehbar. So bleibt das Doku-Tool am Leben und dient als kontinuierlicher Referenzpunkt für Kunde & Team.

Robyn Birkedal:

Genau. Nicht immer teile ich die direkt mit dem Kunden, oft reicht es, sie intern vorzuhalten.

Ben Aston:

Klingt alles wunderbar, aber wo liegen die größten Stolpersteine bei Scope Statements?

Robyn Birkedal:

Man darf kein Schema F anlegen – jede:r Kunde und jedes Projekt sind anders. Flexibilität ist genauso wichtig wie Klarheit bei den festgelegten Liefergegenständen.

Ben Aston:

Die größte Gefahr ist, sich zu weit aus dem Fenster zu lehnen, wenn man noch gar nicht genau weiß, was später wirklich gebraucht wird. Lieber Scope Statements für einzelne Projektphasen (z.B. Discovery) schreiben – und erst danach das nächste definieren. Das verhindert Überversprechen.

Robyn Birkedal:

Ein weiteres Risiko ist fehlender Konsens: Wenn der Kunde zwar unterzeichnet, aber nicht alle Stakeholder abgeholt sind. Daher immer nochmal mit allen durchsprechen.

Ben Aston:

Unbedingt! Mündliche Walk-Throughs sind enorm wichtig: Scope Statements sind keine juristische Waffe, sondern ein Tool zur Erwartungsabstimmung. Es geht nicht ums Tricksen, sondern ums Level-Setting – damit alle am Ende zufrieden sind. Sonst verlieren alle, vor allem auch den Kunden.

Robyn Birkedal:

Ja, und es gibt nichts Schöneres, als wenn du ein Scope Statement fast 1:1 in einen Vertrag übernehmen kannst – und alle sind aligned!

Ben Aston:

Genau. Danke, Robyn! Es war großartig, dass du heute dabei warst.

Robyn Birkedal:

Danke für die Einladung.

Ben Aston:

Und an euch, die zuhören: Was sind eure Tipps und Tricks zu Scope Statements? Wie nutzt ihr sie? Was läuft gut, was nicht? Schreibt uns eure Erfahrungen in die Kommentare! Und wenn ihr mehr lernen und euch weiterentwickeln wollt: Kommt in unsere DPM-Community! Mehr Infos und Vorteile (Slack, Mentoring, Templates usw.) unter thedigitaprojectmanager.com/membership. Wenn dir der Podcast gefallen hat: abonnieren nicht vergessen und bleibt auf thedigitalprojectmanager.com auf dem Laufenden. Bis zum nächsten Mal – danke fürs Zuhören!