OUT OF SCOPE

Was für den Projektstart wirklich wichtig ist

"Der Projektplan des Webprojekts steht. Die Meilensteine sind gesetzt und der Aufgaben-Wasserfall darf sich in die Tiefe stürzen.
Oder aber die Umsetzung erfolgt agil. Epics wurden im Planing Poker grob geschätzt und tolle erste Stories geschrieben, die nun der Umsetzung erzählt werden wollen. Die Vorbereitung war also lehrbuchartig.
Der 1. Meilenstein wird schnell erreicht – die ersten Sprints sind abgeschlossen und einige brauchbare Ergebnisse wurden erzielt. Das Projekt läuft, aber irgendwann stellt man fest, dass die einzelnen Aufgaben nicht fertig werden / doch nicht so klar sind wie in der Planung gedacht / insgesamt alles länger dauert als angenommen. Im schlimmsten Fall droht sogar der Aufgaben-Wasserfall einen mit sich zu reißen und der Projekterfolg wird gerade maximal agil selbst zur Geschichte.


Was ist passiert und war die Vorbereitung wirklich so lehrbuchartig?


Eine oft unterschätzte Quelle großer und kleiner Herausforderungen ist der Project Scope – und dass, nicht nur bei der Festlegung des Projektumfangs sondern auch während der Umsetzung.
Welche Methoden und Tools gibt es um einen sinnvollen Projektumfang festzulegen? Wie kann ein idealer Project Scope aussehen – egal ob Wasserfalls oder agile Umsetzung? Was ist eigentlich Project Creep und wie wird er verhindert? Schauen wir es uns gemeinsam an."

Bernhard Aster

Technischer Berater bei Arrabiata
LinkedIn-Profil

Lesezeit: 10-12 Minuten

[:SKƏƱP]

Was ist Scoping und wofür brauchen Sie dies?

Scoping leitet sich vom Begriff "scope" (engl. für Umfang) ab und beschreibt einen Planungsschritt, um den Rahmen eines Projektes konkreter zu definieren. Es ist damit ein Teil des Anforderungsmanagements, worin abgegrenzt wird, was das Projekt abdeckt und vor allem auch, was nicht.

Intention dieses Vorgehens ist, für alle jetzt und später Beteiligten ein klares Zielbild zu schaffen und das Risiko des Scheiterns eines Projektes zu verringern.

Scoping

Man kann nicht nicht scopen!

Implizit wird jede Aufgabe und jedes Projekt in irgendeiner Form abgesteckt. Je nach Komplexität des Projektes unterscheiden sich Vorgehen und Detailgrad. Scoping ist somit kein festgeschriebener Prozess sondern ein Methodenset. In unserem Alltag als Digitalagentur erleben wir Kundenanfragen mit teilweise schon sehr ausdifferenzierten Anforderungen aber auch recht grobe Projektideen, deren einzig klare Grundlage festgelegte Business-Ziele sind. Damit kann Scoping ein relativ knappes Festhalten von Eckpunkten bis zu einer mehrwöchigen Phase mit begleitenden Analysen von z.B. Systemlandschaften, Prozessen und Abhängigkeiten umfassen.

Was Scoping nicht ist

Ziel ist die Anforderungserfassung und keine Strategieberatung – diese würde vorgelagert erfolgen und damit das Fundament darstellen. Es werden Anforderungen und Einschränkungen beschrieben - also WAS ein System bzw. Kommunikationsprodukt können soll und nicht WIE es das machen wird.

Scoping ist nie lästiger Selbstzweck sondern eine wertvolle Leitlinie für Projektentscheidungen und ein unerlässlicher Baustein für einen reibungsarmen Projektstart.

Die größten Fallstricke und der gefürchtete Scope Creep

Es ist schon herausfordernd genug, den Umfang eines Projektes initial festzulegen. Ist dieser Schritt erfolgreich inkl. der Zustimmung aller Stakeholderinnen und Stakeholder erfolgt, sei man vor einer dauerhaften Gefahr gewarnt, dem sogenannten Scope Creep. Dieser meint die unvorhergesehene und unkontrollierte Ausweitung des ursprünglich festgesetzten Umfangs. Creep heißt übersetzt zwar "Einschleichen", es passt aber genauso der Begriff "Schleicher" – analog zum Schleicher bei einem Reifen beim Auto oder Fahrrad, aus dem unbemerkt Luft entweicht und somit Gefahr läuft, das Ziel nicht zu erreichen.

Gründe, die ein Projekt in Schwierigkeiten bringen kann, gibt es einige - die gängigsten hier mal zusammengetragen. Damit ist zugleich erklärt, weshalb Scoping viel Erfahrung und einen klaren womöglich sogar unbefangenen Blick erfordert.

Der inhaltliche Fokus weicht auf

Der wohl am häufigsten begangene Fehler ist jener, das Projekt an den ursprünglichen Zielen vorbei zu planen. Insbesondere je detaillierter man wird, desto eher weicht man ab.

Zum Beispiel soll ein leichtgewichtiger eShop entwickelt werden, der primär das interne Team in der Datenpflege entlasten soll. In der Diskussion mit verschiedenen Abteilungen landet man plötzlich schnell bei sehr individuellen Wünschen, was die Optik verschiedener Produktgruppen betrifft und nimmt eine Vielzahl an Features und Content Elementen auf. An dieser Stelle muss deutlich erkannt werden, welche Anforderungen zielführend sind.

Die Priorisierung fällt schwer

In der Realität ist mit den beiden Ressourcen Zeit und Budget zu kalkulieren. Aus diesem Grund ist entscheidend, die Anforderungen klar zu priorisieren, um nur die oberste Wichtigkeitsstufe ins Umsetzungsprojekt zu überführen. Das ist deutlich schwieriger als es klingt. Viele Abteilungen bringen meist viele Wünsche ein, wie und durch wen wird an dieser Stelle nach Relevanz bewertet?

Es wird falsch und durch die falschen Personen geschätzt

Immer wieder werden auch Aufwände unterschätzt. Das geht uns ehrlich gesagt manchmal ganz genauso. An dieser Stelle kommt ins Spiel, wer die Rolle der Scope-Managerin bzw. Managers übernimmt. Eine optimistische Person geht weniger auf Risikofaktoren ein und wird automatisch geringere Zeitkontingente schätzen, als effektiv benötigt werden. Ein zu vorsichtiger Charakter nimmt dem Vorhaben schnell die Vision und das Momentum. Führt das Scoping das Sales oder eine bestimmte Abteilung mit eigenen Interessen, agiert man unter Umständen auf den zügigen Abschluss dieser Phase hin und lässt wertvolle Aspekte links und rechts unberücksichtigt.

"Nur mal schnell..."

Diese Formulierung entlarvt im Vorfeld ein Scoping Creep, wenn dahinter eine vermeintlich kleine Ergänzung des Leistungsumfangs steckt. Auch wenn das gewünschte Feature verhältnismäßig klein wirkt, können die Tätigkeiten rundherum sowie evtl. Abhängigkeiten andere Features ausbremsen.

Stakeholderinnen und Stakeholder werden nicht abgeholt

Der Gau ist, sollten in der Anbahnung bereits wesentliche Stakeholderinnen und Stakeholder außen vor geblieben sein. Vertretende aus sämtlichen relevanten Tätigkeitsbereichen genauso wie sämtliche Personen mit Entscheidungsbefugnis und auch evtl. Querschlägerinnen und -schläger (positiv gemeint) sollten involviert sein, damit das Projekt Commitment erfährt.

Wie gehe ich ein erfolgreiches Scoping an?

Um die genannten Fehler bei der Definition des Projektumfangs vorzubeugen, sollte man sich über folgende Grundlagen Gedanken gemacht haben.

Welche Stakeholderinnen und Stakeholder werden beteiligt?

Für ein reibungsfreies Scoping, dessen Ergebnis ein hohes Maß an Akzeptanz auslöst und welches möglichst breit mitgetragen wird, sind zunächst die Teilnehmenden entscheidend. Welche Abteilungen haben ein Interesse am Projekt und wer stellt die Entscheiderin bzw. Entscheider. Wer bildet auch im späteren Projekt den Leitungskreis und muss Vision und Intention gut verstanden haben.

Und nicht zuletzt wer leitet die Scoping Phase? Vorteile, den Prozess intern zu stemmen, sind das tiefe Verständnis für das Business, Details zu den geplanten Anforderungen und evtl. Einschränkungen. Lässt man einen Scoping-Workshop extern moderieren, bringt dies eine neutrale Sicht, die abteilungsunbefangen agiert und durch faire Moderation auch politisch-herausfordernde Konstellationen auflösen kann. Erfahrung in Richtung Machbarkeit und Aufwandschätzungen kommt durch unsere Projekthistorie ins Spiel. Im Idealfall kristallisiert sich bereits an dieser Stelle der Dienstleister als vielseitiger Sparringspartner hervor.

MVP vs Big Bang Release

Um das optimale Maß an Projektumfang zu erreichen, ist eine weitere Vorüberlegung nötig: Wie soll das neue Produkt lanciert werden? Als schlankes MVP oder in Form eines Big Bang Releases.

Kurz zur Begriffsklärung, MVP steht für Minimum Viable Product und beschreibt die Schnittmenge aus dem kleinstmöglichen Produkt und den optimalen Produkteigenschaften. So soll mit einer kurzen Umsetzungsdauer ein Ergebnis am Markt platziert und getestet werden. Der MVP-Approach kommt aus der agilen Startup-Welt und ist darauf ausgelegt, möglichst schnell ursprüngliche Annahmen durch Nutzerfeedback zu validieren. Entsprechend der gemachten Learnings wird daran kontinuierlich weiterentwickelt. So kann es sinnvoll sein, in nicht nur einem MVP zu denken sondern sogar mehrere Ansätze parallel zu vertesten, um mit größter Geschwindigkeit ein am Markt akzeptiertes Produkt oder einen Service zu finden und dadurch das Gesamtrisiko zu mindern.

Das gegenteilige Vorgehen wäre ein Big Bang Release, welches ein Komplettprojekt geschlossen realisiert. Schließlich macht nicht in jedem Szenario ein MVP Sinn, man denke bsp. an den Flughafen BER oder die Elbphilharmonie. Nur eine Rollbahn und ein Mini-Terminal ohne ÖPNV-Zugang oder der reine Konzertsaal ohne gastronomische Verweilbereiche hätten wenig Nutzerbegeisterung zur Folge.

Auch wenn der Trend deutlich zu immer agileren Projekten geht, liegt die Wahrheit wie so oft zwischen diesen beiden Extremausprägungen und muss auf Basis der mittelfristigen Strategie entschieden werden.

Auf welchem Detailgrad findet Requirement Engineering statt?

Welches Ziel soll mit dem Scoping primär verfolgt werden? Geht es in einem ersten Schritt um eine High Level-Betrachtung, um bsp. das Gesamtvolumen etwas greifen zu können? Oder soll bereits eine Detailschätzung für die konkrete Planung oder Beauftragung durchgeführt werden?

Davon hängt im wesentlichen ab, wie granular das Requirement Engineering betrieben und in welcher Form die Ergebnisse dokumentiert werden sollen. Was wird der anschließende Schritt sein, sollen die Leistungsbeschreibungen in einer Ausschreibung münden? Oder werden die Anforderungen in einen Projektplan überführt bzw. soll eine Epic-Liste den Übergang in die Projektumsetzung bilden?

Und sind in dieser Phase weitere begleitende Voraussetzungen zu schaffen wie z.B. eine Systemwahl oder Prozessanalysen?

In welcher Form begleiten wir Ihr Scoping?

1 Tages-High Level Scoping

Format: Workshop (in präsenz oder remote) mit zwei Beraterinnen bzw. Beratern (Business- und Technik-Fokus)

Ziel: Überblick gewinnen, Volumen erste Einschätzung

Vorgehen: IST-Sammlung, Anforderungen identifizieren in Interviews + Doku, Priorisierung

Output: TL;DR Summary + Constraints + erste Hausnummer (Project Scope Statement)


SIE SIND AN SCOPING INTERESSIERT?

Ich möchte gerne...

Kontakt Newsletter Anmeldung