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.