Eine doofe Frage vorweg – was ist eigentlich “Scope”?

Wir sprechen hier vom Leistungsumfang oder auch den Inhalt eines Projektes. Aktivitäten, um den Scope im Projekt zu bearbeiten, bezeichnet man zwar selten aber treffend als “Scoping”. Diese Aktivitäten zielen darauf ab, sowohl alles umfänglich ausreichend zu betrachten, als auch eine sinnhafte Struktur herzustellen, die den Projektinhalt über mehrere Ebenen ordnet und bearbeitbar macht.

Zudem hat sich der Begriff “Scope Creep” in vielen Projektumfeldern bereits fest etabliert. Gemeint ist der schleichende Zuwachs von Scope ohne explizite Beauftragung. Nahezu unbemerkt und schwierig zu erklären wird ein Projekt dadurch aufwendiger als ursprünglich geplant. Im Pulse of the Profession Umfrage 2018 benennt auch das Project Management Institute (PMI) 52% der Projekte von Scope Creep betroffen. Verzug in Time & Budget und Unzufriedenheit bei allen Beteiligten sind damit also sehr häufig vorprogrammiert.

Symptome und Ursachen von schlechtem Scoping und Scope Creep

Um den wichtigsten Problemen auf die Schliche zu kommen, lohnt sich ein Blick auf die Symptome und Ursachen von schlechtem Scoping und Scope Creep in Projekten.

SYMPTOME

• Der Scope des Projektes ist für die Beteiligten teilweise unklar. Es besteht ein individuelles Selbstverständnis, das nur teilweise konkret ist und nicht mit den tatsächlich formulierten Anforderungen angeglichen wird. Gesprächsrunden enthalten viele Unklarheiten.
• Das Projekt verzeichnet nur einen langsamen Fortschritt, weil an einzelnen Anforderungen zu lange gearbeitet wird. Insbesondere Aufwände für Abstimmungen steigen enorm, bevor die technische Umsetzung beginnen kann.
• Anforderungen wachsen qualitativ, gefühlt aus sich selbst heraus. Das bedeutet, die Anforderung ist grundsätzlich die gleiche, die Ausgestaltung birgt nun aber Details, die vorher nicht besprochen worden waren.
• Explizite IT-Anforderungen und implizite Facherwartung weichen voneinander ab. Fachliche Verantwortliche sind zu wenig in den IT-Entwicklungsprozess, dessen Struktur und Ablauf, eingebunden.
• Zielstellungen sind nicht konkret genug formuliert und halten sich oft im Bereich von Einführung einer bestimmten Software. Die konkret zu verfolgenden IT-Ziel, aber auch das fachliche, zum Bsp. vertriebliche Ziel sind nicht ausreichend explizit benannt und können so nicht konsequent verfolgt werden.

URSACHEN

• Anforderungen sind häufig nicht ausreichend eindeutig und formal formuliert. Das bezieht sich auf die konzeptionelle Dokumentation wie auch die tatsächlichen IT-Umsetzungstickets , z. B. in Form von JIRA-Stories und -Tasks inkl. eindeutig formulierter Akzeptanzkriterien.
• Ideen von Fachseite werden als” Eierlegendewollmilchsäue” formuliert anstatt bei der einfachsten Lösung zu beginnen und diese dann mit weiteren Anforderungen zu erweitern. Hinzu kommen historisch angesammelte Vorstellungen, welche Probleme mit einem entsprechenden Projekt gelöst werden sollen, die aber mit der Beauftragung als solche u. U. nicht abgedeckt sind.
• Thema Abhängigkeiten – Technische Veränderungen können meist nicht so isoliert betrachtet werden, wie gerne angenommen wird. Komponenten haben einen Einfluss aufeinander. Erfahrungsgemäß sind die Abhängigkeiten entweder quantitativ zu wenig bekannt oder in ihrer Auswirkung unterschätzt.
• Die IT-Strukturen und -funktionsweise, sowie der Entwicklungsprozess sind bei Fachkolleg*innen zu wenig bekannt. Kleinere Wünsche und qualitative fachliche Änderungen führen so zu IT-Aufwänden, um dies technisch detailgetreu abzubilden. Die aufwandsseitigen Auswirkungen sind Fachbereichen häufig nicht ausreichend transparent.
• Möglichkeiten von digitalem Customer Relationship Management sind zu wenig in die Vertriebsprozesse eingebunden. Vertrieb z. B. ist an vielen Stellen immer noch “Handarbeit” und von persönlichen Beziehungen abhängig. Digitale bzw. IT-Prozesse werden zu wenig und zu losgelöst vom Vertriebsprozess verstanden.

Lösungsmöglichkeiten liegen in Struktur und Kommunikation

Wie so häufig führen klare Strukturen zu Ordnung und Qualität.

STRUKTUR

• Selbst wenn man nicht mit Jira & Co. arbeitet, bietet die hier verfügbare Struktur ein gutes Gerüst für die Strukturierung von Scope. Zudem bietet sich die strukturierung nach den S.P.I.D.R.-Kriterien* sehr an. So lässt sich jedes große Thema in Teilthemen untergliedern, die für einen agilen Arbeitsablauf geeignet sind.
• Jeder Teil einer Software ist Teil eines Prozesses. Prozessabläufe in Form von Flow-Charts schaffen Klarheit und Eindeutigkeit. Sie bilden Inhalte von Aktionen, sowie auch wichtige Chronologien und Entscheidungspunkte ab. Sie bieten zudem die Möglichkeit, notwendige Plausibilitäten konkret zu verorten.
• Interfaces sollten in Mock-ups bildlich dargestellt werden, um ein gemeinsames Bild unter den Beteiligten zu schaffen. Notwendige Details können dargestellt werden, während generelle Anforderungen, wie z. B. die Abbildung in einem Corporate Identity Design, hinten angestellt werden können.
• Verhältnismäßigkeiten und Ausprägungen sollten idealerweise in einer Tabelle abbildbar sein. Ist dies nicht möglich oder wird die Tabelle zu kompliziert, dann ist der entsprechende Inhalt zu komplex. Um diese Komplexität zu reduzieren und Inhalte in den IT-Prozess geben zu können, müssen diese kleinteiliger abgegrenzt werden.

KOMMUNIKATION

• Schon im Gespräch und der Moderation von Anforderungsworkshops ist es wichtig, strikt der Philosophie der einfachst-möglichen Lösung zu folgen. Es gilt, auch die Gedankenstruktur der Teilnehmer und Kommunikationspartner, an einfachen Prinzipien auszurichten. Dazu kann man z. B. einzelne S.P.I.D.R.*-Kriterien voranstellen.
• Noch mal Stichwort “Eierlegendewollmilchsau” – auch kommunikativ bringt sie Projektinitiativen regelmäßig zum Stillstand, schürt Frust und schlechte Laune. Anforderungen sollten auch im Gespräch unbedingt getrennt behandelt werden, um einen schlanken Prozess zu ermöglichen.
• Wichtig ist zudem, dass echte und klare Akzeptanzkriterien in den Anforderungen schriftlich niedergeschrieben stehen. Bei einer Erweiterung wächst zwar der Scope, aber dieser muss nicht Teil der gleichen Story sein. Neue Anforderungen sollten sogar unbedingt als solche und explizit aufgenommen werden. Sie sollten jedoch nicht in eine bereits in Bearbeitung befindliche Anforderung eingebaut werden.

Fazit und Empfehlungen

Was gilt es also zu tun?

FAZIT

Wer unklaren Scope und langsamen Fortschritt, unklare Erwartungen und Zielstellungen bemerkt, kann sich sicher sein, dass es an Struktur und Klarheit in der Sache und im Verständnis bei den Beteiligten fehlt. Es gilt, die Ursachen in den Fokus zu nehmen und somit Anforderungen, idealerweise in Form von Stories zu formulieren. Abhängigkeiten können dann transparent gemacht werden und gezielt gelöst, z. B. in Form eines User Story Mappings.

Kurz- aber auch mittelfristig lohnt sich ein Invest in das IT-Know-how von Fachkollegen. Hier geht es vor allem darum, den agilen IT-Entwicklungsprozess zu verstehen sowie die damit verbundene Notwendigkeit, Anforderungen entsprechend zu schneiden und Akzeptanzkriterien zu formulieren. Letztlich hilft dies auch ihnen, das Ergebnis nach ihren Wünschen entstehen zu lassen.

EMPFEHLUNGEN

Empfehlenswert sind zudem Strukturmerkmale, die Klarheit in den Scope des Projektes bringen. Dies sind vor allem die Abstraktionsebenen aber auch der Schnitt der Stories anhand der S.P.I.D.R.-Kriterien, die den Scope in gut verarbeitbare Häppchen teilt, die zu einem schnellen Ergebnis führen. Praktische Strukturen in der Analyse von Prozessen und Fachinhalten finden sich in Flowcharts aus dem Prozessmanagement, in Tabellen, die Komplexität reduzieren und auch in bildlichen Mock-ups, die ein einfaches Soll-Bild skizzieren.

Das Projekt, das es schafft, diese Merkmale herauszuarbeiten, wird in der Konsequenz auch ein Leichtes haben, mit Auftraggebern, den Fachkollegen und Stakeholdern einen konstruktiven Dialog zu führen. Unter dem Strich sind es also klare To-Do’s, die sowohl ein klares transparentes Scoping ermöglichen als auch Scope Creep verhindern. Also, wer geht sie an?