Smart Hacks für IT Projektmanager

Sidekick Network

Since 12/2024 11 Episoden

Wenn der Scope plötzlich wächst – Hacks gegen Scope Creep

Die unsichtbare Gefahr für IT-Projekte meistern

13.08.2025 15 min

Zusammenfassung & Show Notes

In dieser Folge von Smart Hacks für IT Projektmanager spricht Anita mit dem erfahrenen IT- und ERP-Projektmanager Frank Nungesser über ein Thema, das viele Projektleiter nur zu gut kennen: Scope Creep. Frank teilt ein anschauliches Beispiel aus einem Pharma-Projekt, in dem kurz vor dem Go-Live plötzlich kritische Anforderungen auftauchten. Er erklärt, wie ein radikaler Workshop-Ansatz das Projekt rettete. Gemeinsam diskutieren Anita und Frank, wie Scope Creep bereits in der Assessment-Phase vermieden werden kann, warum ein klarer Scope und feste Leitplanken essenziell sind und weshalb konsequentes Nein-Sagen so wichtig ist. Zum Schluss fasst Anita drei praxisnahe Hacks zusammen, mit denen sich IT-Projekte effektiv vor unkontrollierten Änderungen schützen lassen.

📢 Episode: Scope Creep verhindern – Die unsichtbare Gefahr für IT-Projekte meistern
🎙 Gast: Frank Nungesser – IT- & ERP-Projektexperte mit über 20 Jahren Erfahrung
🎯 Thema: Wie du Scope Creep frühzeitig erkennst, effektiv stoppst und Projekte sicher ins Ziel führst.

🔍 In dieser Episode erfährst Du:

✅ Was Scope Creep genau ist und warum er so gefährlich für Projekte werden kann.
✅ Welche radikalen Maßnahmen Frank im Ernstfall erfolgreich eingesetzt hat.
✅ Warum ein klar definierter Scope und feste Leitplanken von Anfang an essenziell sind.
✅ Wie du durch cleveres Fragenstellen in der Assessmentphase Überraschungen vermeidest.

📌 Highlights:

⏳ [00:02] – Begrüßung & Einführung ins Thema
💥 [02:38] – Scope Creep: Was steckt dahinter?
⚠️ [03:33] – Praxisbeispiel: Pharma-Projekt kurz vor dem Go-Live
🛡 [06:25] – Die Rettung: Entscheider-Workshop als Gamechanger
🗺 [07:12] – Scope von Beginn an richtig definieren
🤝 [09:31] – Assessmentphase: Richtig zuhören & die richtigen Fragen stellen
🔄 [12:45] – Standardisierung vs. lokale Bedürfnisse
✅ [15:37] – Zusammenfassung: Die drei Top-Hacks gegen Scope Creep
🎯 [16:57] – Abschluss & Takeaways

🎧 Jetzt anhören & wertvolle Impulse für dein Projekt mitnehmen!
👉 LINK

🔔 Folge uns, um keine Episode zu verpassen! 🚀

Mehr Infos zu Frank Nungesser: https://www.linkedin.com/in/frank-nungesser/
Mehr Infos zu Sidekick Network: https://www.linkedin.com/company/sidekick-network/

Transkript

One, two, three, four. Hallo und herzlich willkommen bei Smart Hacks für IT Projektmanager, präsentiert von Sidekick Network basiert unser Podcast auf der Erfahrung von über 20.000 IT Projekten. Bist du bereit? Direkt zum Punkt zu kommen? Dann lass uns starten. Herzlich willkommen zu einer neuen Folge von Smart Hacks Flight Projektmanager. Ich bin Anita. Und heute sprechen wir über ein Thema, das jedem Projektmanager schon mal passiert ist. Obwohl es natürlich keiner will. Scope Creep Das Projekt ist idealerweise gut geplant. Der Scope ist definiert nach der Assessmentphase, das Budget steht, Zeitplan passt soweit und dann kommt doch noch eine Anforderung. Erstmal okay, jedoch dann werden es immer mehr Features, weniger Zeit, höhere Kosten. Wir kennen das alles. Aber wie kann man das frühzeitig erkennen und wie kann man es wirksam stoppen? Dazu habe ich heute einen Gast eingeladen, der weiß, wovon er spricht. Frank Nungesser. Frank bringt über 20 Jahre Erfahrung aus IT und ERP Projekten mit in unterschiedlichsten Branchen. Hi Frank, schön, dass du da bist. Ja, Hallo, Anita. Herzlichen Dank für die Einladung. Du kennst das Thema und die ist es sicherlich schon öfter über den Weg gelaufen. Daher erzähl mal, was immer passiert ist. Kannst du uns ein gutes Beispiel nennen? Ja, mir ist da direkt ein Projekt eingefallen bei einem Pharmaunternehmen in der Schweiz. Da hatten wir eine Lieferantenplattform entwickelt und das ganze Projekt lief tiptop. Alles war okay, bis hin zur Testphase. Wir hatten dann die wichtigsten User eingeladen und um die Funktionalitäten zu testen. Und dann stellte sich plötzlich heraus Oh, viele Business Cases fehlten ja. Im Prinzip waren nur 80 % der benötigten Funktionalität abgedeckt und viele Spezialprozesse und kritische Prozesse waren scheinbar gar nicht erkannt. Frühzeitig, wurden aber erwartet und im Prinzip war das so kritisch, dass der ganze Chor live in Gefahr geriet. Klingt nach einer kniffligen Situation, vor allem so kurz vor dem Go Live. Was habt ihr unternommen, um das Projekt wieder auf Kurs zu bringen? Ja, das war natürlich ein kritischer Moment. Wenn der Go Live in Gefahr ist, dann ist er auch entsprechend Druck in der Organisation und eine Erwartungshaltung. Und da mussten wir sagen Okay, jetzt oder nie, wir müssen eine radikale Entscheidung treffen. Wir haben alle involvierten Personen rausgenommen, rausgezogen aus dem Tagesgeschäft und einen eintägigen Workshop gemacht mit den ganzen Usern Matter Experts, Product Owner IT. Alle Wichtigen, die irgendwie eine etwas dazu beitragen konnten und Entscheidungen treffen konnten, haben wir in einen Raum gesteckt, sozusagen weg vom Tagesgeschäft und haben im Prinzip die Situation analysiert. Also da ist die Vorbereitung für diesen Workshop natürlich wichtig. Und wenn man dann kommt und sagt, das sind jetzt noch die ganzen Anforderungen, die vielleicht übersehen wurden, die irgendwie sowieso im Backlog drin sind. Was ist davon kritisch? Da muss man wirklich dann den Experten und den Usern zuhören und schauen okay, was ist machbar, was ist wirklich kritisch, Was ist ein Should have could have? Was ist einfach nur ein Sonderwunsch? Und dann die ganzen Themen priorisieren und dann natürlich schauen, okay, wie komplex sind diese Themen, Was haben wir noch? Nicht nur im Budget, aber was ist auch zeitlich möglich? Natürlich bis zum Go live und das entsprechend dann mit vereinten Kräften, sozusagen. Dadurch, dass alle da sind, sind alle mit an Bord, haben zugehört und haben zugestimmt. Das sind vielleicht die zwei, drei Sachen, die absolut kritisch sind, die fehlen. An denen müssen wir arbeiten, bis zum Go live und alles andere kommt dann später. Klingt aufwendig. Klingt aber auch nach einem guten Plan. Jetzt sind sicherlich schon alle Zuhörer gespannt. Hat es denn geklappt? Tatsächlich? Ja. Also es hat erfreulicherweise geklappt. Das Wichtigste da war wirklich, dass man alle aus dem Tagesgeschäft herausgezogen hat, dass sie mit dem Kopf sozusagen frei waren oder total fokussiert auf dieses Projekt zumindest. Dass wir die Entscheider vor Ort hatten und alle eingebunden waren. Dieser eine Tag Workshop hat uns so viel gebracht wie mehrere Wochen. Irgendwelche Meetings, die man da virtuell macht und dann fehlt einer oder die sind abgelenkt oder man weiß nicht mehr, was man vor einer Woche beschlossen hat. Das war jetzt wirklich kompakt, fokussiert. Und das war im Prinzip das Entscheidende, dass wir den riesen Meilenstein vorwärts gingen und tatsächlich diese kritischen Funktionalitäten noch einbinden konnten. Zum Gurley Finn. Das ist schon ein super Hack für uns alle. davon. Da kann ich auch aus Erfahrung sprechen. Das ist natürlich eine eine Maßnahme, die wir ergreifen können, wenn wir schon mitten im Projekt sind. Natürlich wollen wir nicht, dass das passiert. Hast du noch ein paar Tipps oder aus deiner Erfahrung, was man machen kann oder welche Hebel man ziehen kann, damit es möglichst im Laufe des Projekts nicht zum Scope kommt? Ja, natürlich. Also gerade zu Beginn eines Projektes muss der Scope klar definiert sein. Wenn man scope creep vermeiden möchte, dann muss für jeden klar sein Das sind die Anforderungen des Projektes und das sind die Leitplanken dazu. Das heißt, was wollen wir erfüllen und was gehört eben nicht dazu? Was sind die Tools, mit denen wir arbeiten und welche lassen wir sein? Dazu benötigen wir natürlich die Key User. Die muss man frühzeitig einbinden, um damit jeder versteht okay, das ist das Ziel. Ist das machbar? Was sind die kritischen Anforderungen, die wir liefern müssen? Und auch technisch und organisatorisch müssen wir die Grenzen festlegen. Also wie wollen wir zusammenarbeiten? Mit welchen Tools arbeiten wir? Was nutzen wir? Wer darf auch entscheiden und was ist in scope und out of scope? Das muss von Anfang an klar sein. Und wenn dann eben Diskussionen im Laufe eines Projektes kommen, dann fällt es einem auch leichter, Nein zu sagen. Man muss dann wirklich glasklar sagen Wir haben am Anfang des Projektes so entschieden, das ist die Aufgabe, die wir als Projektteam haben. Und alles andere ist eben vielleicht in einem zweiten Schritt erst möglich. Und wenn man am Anfang eben weiß, was, was die Anforderungen sind, dann kann man auch die Testszenarien, die Testkriterien sauber festlegen. Nicht, dass uns dann wie bei dem erwähnten Beispiel das gegen Ende beim Testen feststellen. Da fehlt ja vielleicht ein großer Teil die kritischsten Sachen, dass wenn man die Leitplanken, die Leitplanken am Anfang festgelegt hat, dann weiß man auch, dass in die Testszenarien Szenarien und das sind die Erfolgskriterien des Projektes und alles andere wird erst mal beiseite geschoben für den nach dem Go Live, für die Product Enhancements. Kontinuierliche Verbesserungen und solche Sachen. Ja, das hilft uns natürlich auch im Projekt so auf der Straße zu bleiben und da nicht so oft abzuweichen. Und wenn ich da von allen Beteiligten, wie du erwähnt hast, da so ein Sign off habe, dann erspart mir das natürlich einige Diskussionsrunden. Hoffentlich. Aber das ist sicherlich ein super Anfang. Du hast erwähnt und frühzeitig die richtigen Leute einzubinden, dass da kommt mir natürlich gleich in den Sinn, dass es sich in der Praxis oft wiederholen wird und ich das immer wieder höre. Ja, die User haben uns nicht alle Anforderungen geliefert, die sind nicht vollständig. Die in der Assessmentphase haben sie nicht. Haben Sie nicht genug darüber nachgedacht, was auch immer Und jedoch ist das Problem natürlich oft. Auch beim Projektteam würde ich behaupten, dass man nämlich auch die richtigen Fragen stellt. Und ein Assessmentphase hängt natürlich ein Erfolg einer Assessmentphase nicht nur von den Usern ab, sondern auch vom zentralen Team. Welche Tipps kannst du uns da geben, wie man das Team einbinden soll und wie man am besten die Assessmentphase gestaltet oder die Fragen gestaltet, damit man sicherstellt, auch als zentrales Team, damit man ein vollständiges Bild hat und somit den vollständigen Scope rahmen. Hast du da ein paar Tipps, die du uns mitgeben kannst? Ja, gerade zu Beginn eines Projektes ist es wichtig zuzuhören. Fragen stellen und noch mehr Fragen und Fragen. Fragen sozusagen, dass man wirklich die User erstmal befragt und dann erfährt man häufig die Standardprozesse, weil dann natürlich auch die, die ja die User selber gar nicht wissen, wie soll die Plattform zum Beispiel am Ende aussehen? Was wird von dem Projekt erwartet, wenn man sie sprechen lässt, dann erzählen sie meistens erst einmal vom Standardgeschäft, vom Tagesgeschäft, vergessen vielleicht irgendwelche Spezialfälle oder sagen Das ist vielleicht gar nicht wichtig. Jetzt zu Beginn zu wissen aber das sind ja dann doch gerade die kritischen Punkte, die dann im Laufe des Projektes zum Tragen kommen. Deswegen ist es immer wichtig, nachfragen, notieren und auch häufig sagen Kannst du mir das mal zeigen, dass man dann sieht okay, es ist nicht irgendwie das Prozesshandbuch nachgeplappert, sondern wenn man sieht, wie dann gearbeitet wird, dann fällt einem auf Moment mal, das ist ja irgendein Workaround oder hier ist noch ein Zusatzschritt, der war gar nicht dokumentiert, oder Ja, irgendwelche Spezialfälle, die dann plötzlich auftreten, die vielleicht sonst nicht direkt angesprochen worden wären. Ja, und wenn man das ein paar Mal gemacht hat, dann wird der Fragenkatalog immer größer. Ich habe da so einen Fragebogen und dann hat man die Standardfragen drauf. Und später fällt mir auf den Bereich, der ist vielleicht auch wichtig oder den sollte ich mit meinen nächsten Interviewpartnern vielleicht auch abklären, ob die das gleiche Problem haben. Und so wird dann der Fragebogen vielleicht immer etwas länger, aber man klärt auch mehr ab und nicht nur das Offensichtliche. Das ist für mich mit das Wichtigste, dass man am Anfang eben die Mitarbeiter erst mal aussprechen lässt und ruhig noch ein bisschen mehr hinterfragt. Selbst wenn es auf den ersten Blick gar nicht relevant zu sein scheint. Ja, du hast mir im Vorgespräch auch berichtet, dass es zum Thema kommt Standardisierung. Das Themen aufkommen wie lokale Entwicklungen, dann kleine maßgeschneiderte Entwicklungssysteme, die sie lokal haben. Und das ist natürlich auch ein Thema, das reinkommt in ein Assessmentphase. Man möchte ja aus dem zentralen Team oft Es geht. Es geht oft um Standardisierung und somit will man natürlich abweichen von nice to have. man. Dementsprechend ist aber auch wichtig, dass die User die Prozesse und das System verstehen. Sonst ist es natürlich umsonst. Sonst ist es schwierig, auch für die eben die Use Cases zu identifizieren. Und wenn sie das System nicht verstehen, dann auch vollständig die Anforderungen mitzugeben. Das hast du mir im Vorfeld auch noch mal gesagt, dass da das Prozesssicht versus Beispiele, dass es dort auch dort auch sehr relevant ist, wie man da vorgeht. Absolut. Also gerade am Anfang ist es einfach wichtig, Themen aufzunehmen, die Leute aussprechen lassen und einfach mal ohne Bewertung aufnehmen, wie der jetzige Istzustand ist. Und dann kann man sagen ja, mit dieser neuen Plattform zum Beispiel möchten wir Prozesse standardisieren und das, was du jetzt machst, wird es so auch nicht mehr geben. Vielleicht. Das kann man dann natürlich in einem End to End mit verschiedenen Teilnehmern anschauen. Warum gibt es diesen Workaround? Der passt gar nicht in die Standardprozesse rein. Ist er wirklich nötig oder können wir das irgendwie anders abdecken? Aber erst einmal aufnehmen. Nicht, dass dann am Ende in der Testphase oder vielleicht beim Go Live Erwartungen nicht erfüllt werden, dass es dann heißt Ja, ich dachte, das funktioniert so, oder Ich dachte, das wird ja Und das ist dann wichtig, dass man frühzeitig sozusagen, um scope creep zu vermeiden, auch klar macht. Vielen Dank. Wir haben jetzt alles gesehen, hoffe ich. Ja, 95 98 % sollte irgendwo mal thematisiert worden sein. Und dann auch zu sagen, wir setzen nicht alles um. Ja, das sind erstmal die kritischen Prozesse, die braucht es. Und diesen Workaround, den wir später vielleicht entweder gar nicht mehr geben oder den machen wir in einer Phase zwei. Wichtig ist einfach, dass man die Business Prozesse generell abwickeln möchte und alles andere, sagen wir 20 %, ist dann individuelle Prozesse und Regularien, lokale Gesetze und so etwas gibt es immer. Man kann nicht sagen, wir machen alles standardmäßig für alle gleich, aber man muss dann, wenn man etwas spezialisiert, muss es auch einen richtigen Grund dazu geben. Einen Business Case eben. Legal. Lokale Anforderungen. Und dann probiert man, größere Bomben zu vermeiden. Genau. Danke dir, Frank. Ich bin mir sicher, viele von unseren Zuhörern und Zuhörer überlegen jetzt schon Ach, was könnte ich vielleicht aktuell ändern? Oder zukünftig oder gleich am Anfang gegebenenfalls Maßnahmen einleiten. Daher fasse ich noch mal die Hacks zusammen und das unseren Zuhörerinnen und Zuhörern mitzugeben in einer kompakten Form. Hack eins Wenn Scope zuschlägt und der Go Live in Gefahr ist, so im laufenden Projekt, dann zieh die Entscheider für einen Tag raus aus dem Tagesgeschäft und bring sie alle an den Tisch live und entscheidet gemeinsam sofort. Dann Hack zwei. Denk an den Projektstart schon an klare Leitplanken. Somit kannst du den Scope Creep während des Projekts minimieren. Hack drei Sei konsequent. Ein klares Nein ist oft wichtig bei zusätzlichen Anforderungen und daher frag dich Und die User sollten sich auch immer fragen wie oft wird diese Funktion wirklich gebraucht und wie notwendig ist sie? Frank Ganz herzlichen Dank! Das waren wertvolle Einblicke, ehrliche Worte und ich bin mir sicher, dass wir alle neue Impulse mitnehmen können heute. Ich freue mich, dass du mein Gast warst. Super. Auch dir. Vielen Dank, Anita. Vielen Dank für die Einladung. Mir hat es ebenfalls viel Spaß gemacht. Das war's für heute. Ich freue mich auf die nächste Folge. Bis zum nächsten Mal, Eure Anita. If you know.