WEBVTT

00:02:16.000 --> 00:02:18.080
One, two, three, four.

00:02:18.440 --> 00:02:23.040
Hallo und herzlich willkommen bei Smart
Hacks für IT Projektmanager,

00:02:23.480 --> 00:02:27.735
präsentiert von Sidekick Network basiert
unser Podcast auf der Erfahrung

00:02:27.760 --> 00:02:31.320
von über 20.000 IT Projekten.
Bist du bereit?

00:02:31.360 --> 00:02:32.720
Direkt zum Punkt zu kommen?

00:02:32.760 --> 00:02:34.400
Dann lass uns starten.

00:02:38.600 --> 00:02:42.720
Herzlich willkommen zu einer neuen Folge
von Smart Hacks Flight Projektmanager.

00:02:42.800 --> 00:02:43.800
Ich bin Anita.

00:02:44.000 --> 00:02:47.640
Und heute sprechen wir über ein Thema, das
jedem Projektmanager

00:02:47.680 --> 00:02:48.800
schon mal passiert ist.

00:02:49.360 --> 00:02:51.175
Obwohl es natürlich keiner will.

00:02:51.200 --> 00:02:54.920
Scope Creep Das Projekt ist
idealerweise gut geplant.

00:02:54.960 --> 00:02:58.600
Der Scope ist definiert nach der
Assessmentphase, das Budget steht,

00:02:58.880 --> 00:03:02.360
Zeitplan passt soweit und dann
kommt doch noch eine Anforderung.

00:03:02.840 --> 00:03:07.015
Erstmal okay, jedoch dann werden es immer
mehr Features, weniger

00:03:07.040 --> 00:03:08.960
Zeit, höhere Kosten.

00:03:09.000 --> 00:03:10.120
Wir kennen das alles.

00:03:10.280 --> 00:03:14.920
Aber wie kann man das frühzeitig erkennen
und wie kann man es wirksam stoppen?

00:03:15.440 --> 00:03:19.040
Dazu habe ich heute einen Gast
eingeladen, der weiß, wovon er spricht.

00:03:19.080 --> 00:03:19.960
Frank Nungesser.

00:03:20.120 --> 00:03:24.975
Frank bringt über 20 Jahre Erfahrung aus
IT und ERP Projekten mit in

00:03:25.000 --> 00:03:26.440
unterschiedlichsten Branchen.

00:03:27.600 --> 00:03:30.080
Hi Frank, schön, dass du da bist.

00:03:30.520 --> 00:03:31.520
Ja, Hallo, Anita.

00:03:31.560 --> 00:03:32.960
Herzlichen Dank für die Einladung.

00:03:33.520 --> 00:03:37.455
Du kennst das Thema und die ist es
sicherlich schon öfter

00:03:37.480 --> 00:03:38.720
über den Weg gelaufen.

00:03:39.000 --> 00:03:41.175
Daher erzähl mal, was immer passiert ist.

00:03:41.200 --> 00:03:43.215
Kannst du uns ein gutes Beispiel nennen?

00:03:43.240 --> 00:03:46.575
Ja, mir ist da direkt ein Projekt
eingefallen bei einem

00:03:46.600 --> 00:03:48.280
Pharmaunternehmen in der Schweiz.

00:03:48.840 --> 00:03:52.215
Da hatten wir eine Lieferantenplattform
entwickelt und das ganze

00:03:52.240 --> 00:03:53.295
Projekt lief tiptop.

00:03:53.320 --> 00:03:56.480
Alles war okay, bis hin zur Testphase.

00:03:56.520 --> 00:04:00.600
Wir hatten dann die
wichtigsten User eingeladen und

00:04:00.760 --> 00:04:02.895
um die Funktionalitäten zu testen.

00:04:02.920 --> 00:04:07.440
Und dann stellte sich plötzlich heraus
Oh, viele Business Cases fehlten ja.

00:04:08.960 --> 00:04:13.360
Im Prinzip waren nur 80 % der benötigten
Funktionalität abgedeckt und viele

00:04:14.040 --> 00:04:21.160
Spezialprozesse und kritische Prozesse
waren scheinbar gar nicht erkannt.

00:04:21.200 --> 00:04:26.575
Frühzeitig, wurden aber erwartet und im
Prinzip war das so kritisch, dass

00:04:26.600 --> 00:04:28.320
der ganze Chor live in Gefahr geriet.

00:04:30.360 --> 00:04:34.815
Klingt nach einer kniffligen Situation,
vor allem so kurz vor dem Go Live.

00:04:34.840 --> 00:04:37.520
Was habt ihr unternommen, um das
Projekt wieder auf Kurs zu bringen?

00:04:38.240 --> 00:04:40.360
Ja, das war natürlich
ein kritischer Moment.

00:04:40.440 --> 00:04:44.175
Wenn der Go Live in Gefahr ist, dann ist
er auch entsprechend Druck in der

00:04:44.200 --> 00:04:46.240
Organisation und eine Erwartungshaltung.

00:04:46.280 --> 00:04:49.000
Und da mussten wir sagen Okay, jetzt oder
nie, wir müssen eine radikale

00:04:49.025 --> 00:04:50.160
Entscheidung treffen.

00:04:50.200 --> 00:04:54.320
Wir haben alle
involvierten Personen rausgenommen,

00:04:54.360 --> 00:04:58.935
rausgezogen aus dem Tagesgeschäft und
einen eintägigen Workshop gemacht mit den

00:04:58.960 --> 00:05:03.360
ganzen Usern Matter
Experts, Product Owner IT.

00:05:03.400 --> 00:05:07.935
Alle Wichtigen, die irgendwie eine etwas
dazu beitragen konnten und Entscheidungen

00:05:07.960 --> 00:05:11.760
treffen konnten, haben wir in einen Raum
gesteckt, sozusagen weg vom Tagesgeschäft

00:05:12.200 --> 00:05:15.855
und haben im Prinzip die
Situation analysiert.

00:05:15.880 --> 00:05:18.680
Also da ist die Vorbereitung für
diesen Workshop natürlich wichtig.

00:05:18.720 --> 00:05:23.040
Und wenn man dann kommt und sagt, das sind
jetzt noch die ganzen Anforderungen, die

00:05:23.080 --> 00:05:26.840
vielleicht übersehen wurden, die
irgendwie sowieso im Backlog drin sind.

00:05:28.200 --> 00:05:29.480
Was ist davon kritisch?

00:05:29.640 --> 00:05:35.600
Da muss man wirklich dann den Experten und
den Usern zuhören und schauen okay,

00:05:36.200 --> 00:05:39.495
was ist machbar, was ist wirklich
kritisch, Was ist ein

00:05:39.520 --> 00:05:40.735
Should have could have?

00:05:40.760 --> 00:05:42.480
Was ist einfach nur ein Sonderwunsch?

00:05:42.840 --> 00:05:47.735
Und dann die ganzen Themen priorisieren
und dann natürlich schauen, okay, wie

00:05:47.760 --> 00:05:49.640
komplex sind diese Themen,
Was haben wir noch?

00:05:50.120 --> 00:05:52.560
Nicht nur im Budget, aber was
ist auch zeitlich möglich?

00:05:52.600 --> 00:05:57.560
Natürlich bis zum Go live und das
entsprechend dann

00:05:58.640 --> 00:06:00.920
mit vereinten Kräften, sozusagen.

00:06:00.960 --> 00:06:03.760
Dadurch, dass alle da sind, sind alle mit
an Bord, haben zugehört

00:06:03.800 --> 00:06:05.135
und haben zugestimmt.

00:06:05.160 --> 00:06:08.960
Das sind vielleicht die zwei, drei Sachen,
die absolut kritisch sind, die fehlen.

00:06:09.000 --> 00:06:13.520
An denen müssen wir arbeiten, bis zum Go
live und alles andere kommt dann später.

00:06:14.480 --> 00:06:16.400
Klingt aufwendig.

00:06:16.520 --> 00:06:20.080
Klingt aber auch nach einem guten Plan.

00:06:20.120 --> 00:06:22.440
Jetzt sind sicherlich schon
alle Zuhörer gespannt.

00:06:22.840 --> 00:06:24.200
Hat es denn geklappt?

00:06:25.840 --> 00:06:26.720
Tatsächlich?
Ja.

00:06:26.760 --> 00:06:29.240
Also es hat erfreulicherweise geklappt.

00:06:29.320 --> 00:06:33.655
Das Wichtigste da war wirklich, dass man
alle aus dem Tagesgeschäft herausgezogen

00:06:33.680 --> 00:06:37.735
hat, dass sie mit dem Kopf sozusagen frei
waren oder total fokussiert

00:06:37.760 --> 00:06:39.360
auf dieses Projekt zumindest.

00:06:42.120 --> 00:06:46.840
Dass wir die Entscheider vor Ort
hatten und alle eingebunden waren.

00:06:47.640 --> 00:06:51.535
Dieser eine Tag Workshop hat uns so
viel gebracht wie mehrere Wochen.

00:06:51.560 --> 00:06:56.215
Irgendwelche Meetings, die man da virtuell
macht und dann fehlt einer oder die sind

00:06:56.240 --> 00:06:59.520
abgelenkt oder man weiß nicht mehr, was
man vor einer Woche beschlossen hat.

00:06:59.545 --> 00:07:01.615
Das war jetzt wirklich
kompakt, fokussiert.

00:07:01.640 --> 00:07:05.455
Und das war im Prinzip das Entscheidende,
dass wir den riesen Meilenstein vorwärts

00:07:05.480 --> 00:07:09.775
gingen und tatsächlich diese kritischen
Funktionalitäten noch einbinden konnten.

00:07:09.800 --> 00:07:10.880
Zum Gurley Finn.

00:07:12.360 --> 00:07:16.720
Das ist schon ein super Hack für uns alle.
davon.

00:07:16.760 --> 00:07:18.560
Da kann ich auch aus Erfahrung sprechen.

00:07:19.240 --> 00:07:23.855
Das ist natürlich eine
eine Maßnahme, die wir ergreifen können,

00:07:23.880 --> 00:07:25.520
wenn wir schon mitten im Projekt sind.

00:07:25.545 --> 00:07:27.720
Natürlich wollen wir
nicht, dass das passiert.

00:07:28.040 --> 00:07:33.975
Hast du noch ein paar Tipps oder aus
deiner Erfahrung, was man machen kann oder

00:07:34.000 --> 00:07:38.095
welche Hebel man
ziehen kann, damit es möglichst im Laufe

00:07:38.120 --> 00:07:40.440
des Projekts nicht zum Scope kommt?

00:07:41.840 --> 00:07:42.520
Ja, natürlich.

00:07:42.560 --> 00:07:46.495
Also gerade zu Beginn eines Projektes
muss der Scope klar definiert sein.

00:07:46.520 --> 00:07:50.960
Wenn man scope creep vermeiden möchte,
dann muss für jeden klar sein Das sind die

00:07:52.120 --> 00:07:56.335
Anforderungen des Projektes und
das sind die Leitplanken dazu.

00:07:56.360 --> 00:07:59.400
Das heißt, was wollen wir erfüllen
und was gehört eben nicht dazu?

00:07:59.440 --> 00:08:02.680
Was sind die Tools, mit denen wir
arbeiten und welche lassen wir sein?

00:08:02.880 --> 00:08:05.080
Dazu benötigen wir natürlich die Key User.

00:08:05.120 --> 00:08:09.040
Die muss man frühzeitig einbinden, um
damit jeder versteht

00:08:09.080 --> 00:08:10.440
okay, das ist das Ziel.

00:08:10.520 --> 00:08:11.760
Ist das machbar?

00:08:11.800 --> 00:08:15.720
Was sind die kritischen
Anforderungen, die wir liefern müssen?

00:08:16.240 --> 00:08:20.880
Und auch technisch und organisatorisch
müssen wir die Grenzen festlegen.

00:08:20.920 --> 00:08:22.440
Also wie wollen wir zusammenarbeiten?

00:08:22.465 --> 00:08:24.055
Mit welchen Tools arbeiten wir?

00:08:24.080 --> 00:08:25.055
Was nutzen wir?

00:08:25.080 --> 00:08:30.655
Wer darf auch entscheiden
und was ist in scope und out of scope?

00:08:30.680 --> 00:08:32.200
Das muss von Anfang an klar sein.

00:08:32.240 --> 00:08:35.975
Und wenn dann eben Diskussionen im Laufe
eines Projektes kommen, dann fällt es

00:08:36.000 --> 00:08:37.800
einem auch leichter, Nein zu sagen.

00:08:37.960 --> 00:08:41.720
Man muss dann wirklich glasklar sagen Wir
haben am Anfang des Projektes so

00:08:41.760 --> 00:08:45.240
entschieden, das ist die Aufgabe,
die wir als Projektteam haben.

00:08:45.280 --> 00:08:51.720
Und alles andere ist eben vielleicht
in einem zweiten Schritt erst möglich.

00:08:52.440 --> 00:08:56.935
Und wenn man am Anfang eben weiß, was,
was die Anforderungen sind, dann kann man

00:08:56.960 --> 00:09:00.640
auch die Testszenarien, die
Testkriterien sauber festlegen.

00:09:01.280 --> 00:09:04.695
Nicht, dass uns dann wie bei dem erwähnten
Beispiel das gegen Ende

00:09:04.720 --> 00:09:06.615
beim Testen feststellen.

00:09:06.640 --> 00:09:11.575
Da fehlt ja vielleicht ein großer Teil die
kritischsten Sachen, dass wenn man die

00:09:11.600 --> 00:09:15.295
Leitplanken, die Leitplanken am Anfang
festgelegt hat, dann weiß man auch, dass

00:09:15.320 --> 00:09:19.360
in die Testszenarien Szenarien und das
sind die Erfolgskriterien des Projektes

00:09:19.440 --> 00:09:24.815
und alles andere wird erst mal beiseite
geschoben für den nach dem Go

00:09:24.840 --> 00:09:27.280
Live, für die Product Enhancements.

00:09:27.480 --> 00:09:29.640
Kontinuierliche Verbesserungen
und solche Sachen.

00:09:31.560 --> 00:09:34.720
Ja, das hilft uns natürlich auch im
Projekt so auf der Straße zu bleiben

00:09:34.745 --> 00:09:36.560
und da nicht so oft abzuweichen.

00:09:36.600 --> 00:09:40.600
Und wenn ich da von allen Beteiligten, wie
du erwähnt hast, da so ein Sign off habe,

00:09:40.800 --> 00:09:44.255
dann erspart mir das natürlich
einige Diskussionsrunden.

00:09:44.280 --> 00:09:47.920
Hoffentlich.
Aber das ist sicherlich ein super Anfang.

00:09:48.480 --> 00:09:53.895
Du hast erwähnt und
frühzeitig die richtigen Leute

00:09:53.920 --> 00:09:58.560
einzubinden, dass
da kommt mir natürlich gleich

00:09:59.280 --> 00:10:03.335
in den Sinn, dass es sich in der Praxis
oft wiederholen wird und

00:10:03.360 --> 00:10:04.760
ich das immer wieder höre.

00:10:04.800 --> 00:10:07.935
Ja, die User haben uns nicht alle
Anforderungen geliefert,

00:10:07.960 --> 00:10:09.415
die sind nicht vollständig.

00:10:09.440 --> 00:10:12.560
Die in der Assessmentphase
haben sie nicht.

00:10:12.600 --> 00:10:17.880
Haben Sie nicht genug darüber nachgedacht,
was auch immer Und jedoch

00:10:18.760 --> 00:10:20.360
ist das Problem natürlich oft.

00:10:20.400 --> 00:10:23.815
Auch beim Projektteam würde ich behaupten,
dass man nämlich auch die

00:10:23.840 --> 00:10:24.935
richtigen Fragen stellt.

00:10:24.960 --> 00:10:29.775
Und ein Assessmentphase hängt natürlich
ein Erfolg einer Assessmentphase nicht nur

00:10:29.800 --> 00:10:32.560
von den Usern ab, sondern
auch vom zentralen Team.

00:10:33.240 --> 00:10:37.575
Welche Tipps kannst du uns da geben, wie
man das Team einbinden soll und wie man am

00:10:37.600 --> 00:10:42.280
besten die Assessmentphase gestaltet oder
die Fragen gestaltet, damit man

00:10:42.320 --> 00:10:46.255
sicherstellt, auch als zentrales Team,
damit man ein vollständiges Bild hat und

00:10:46.280 --> 00:10:47.840
somit den vollständigen Scope rahmen.

00:10:48.040 --> 00:10:50.540
Hast du da ein paar Tipps,
die du uns mitgeben kannst?

00:10:51.480 --> 00:10:55.175
Ja, gerade zu Beginn eines
Projektes ist es wichtig zuzuhören.

00:10:55.200 --> 00:10:57.735
Fragen stellen und noch
mehr Fragen und Fragen.

00:10:57.760 --> 00:11:01.760
Fragen sozusagen, dass man wirklich die
User

00:11:03.680 --> 00:11:07.360
erstmal befragt und dann erfährt man
häufig die Standardprozesse, weil dann

00:11:07.480 --> 00:11:12.775
natürlich auch die, die
ja die User selber gar nicht wissen, wie

00:11:12.800 --> 00:11:14.600
soll die Plattform zum
Beispiel am Ende aussehen?

00:11:14.625 --> 00:11:19.055
Was wird von dem Projekt erwartet,
wenn man sie sprechen lässt, dann erzählen

00:11:19.080 --> 00:11:21.720
sie meistens erst einmal vom
Standardgeschäft, vom Tagesgeschäft,

00:11:22.200 --> 00:11:25.055
vergessen vielleicht irgendwelche
Spezialfälle oder sagen Das ist

00:11:25.080 --> 00:11:26.180
vielleicht gar nicht wichtig.

00:11:26.205 --> 00:11:30.935
Jetzt zu Beginn zu wissen aber das sind ja
dann doch gerade die kritischen Punkte,

00:11:30.960 --> 00:11:34.680
die dann im Laufe des
Projektes zum Tragen kommen.

00:11:34.720 --> 00:11:40.135
Deswegen ist es immer wichtig, nachfragen,
notieren und auch häufig sagen Kannst du

00:11:40.160 --> 00:11:44.295
mir das mal zeigen, dass man dann sieht
okay, es ist nicht irgendwie das

00:11:44.320 --> 00:11:48.695
Prozesshandbuch nachgeplappert, sondern
wenn man sieht, wie dann gearbeitet wird,

00:11:48.720 --> 00:11:52.320
dann fällt einem auf Moment mal, das ist
ja irgendein Workaround oder hier ist noch

00:11:52.345 --> 00:11:56.400
ein Zusatzschritt, der war gar nicht
dokumentiert, oder Ja,

00:11:57.360 --> 00:12:01.375
irgendwelche Spezialfälle, die dann
plötzlich auftreten, die vielleicht sonst

00:12:01.400 --> 00:12:04.640
nicht direkt angesprochen worden wären.

00:12:04.680 --> 00:12:08.095
Ja, und wenn man das ein paar Mal gemacht
hat, dann wird der

00:12:08.120 --> 00:12:09.520
Fragenkatalog immer größer.

00:12:09.720 --> 00:12:13.335
Ich habe da so einen Fragebogen und
dann hat man die Standardfragen drauf.

00:12:13.360 --> 00:12:17.175
Und später fällt mir auf den Bereich, der
ist vielleicht auch wichtig oder den

00:12:17.200 --> 00:12:19.960
sollte ich mit meinen nächsten
Interviewpartnern vielleicht auch

00:12:19.985 --> 00:12:22.040
abklären, ob die das
gleiche Problem haben.

00:12:22.600 --> 00:12:27.840
Und so wird dann der Fragebogen vielleicht
immer etwas länger, aber man klärt auch

00:12:27.880 --> 00:12:29.800
mehr ab und nicht nur das Offensichtliche.

00:12:30.560 --> 00:12:33.640
Das ist für mich mit das Wichtigste, dass
man am Anfang eben die

00:12:35.440 --> 00:12:40.095
Mitarbeiter erst mal aussprechen lässt und
ruhig noch ein bisschen mehr hinterfragt.

00:12:40.120 --> 00:12:43.600
Selbst wenn es auf den ersten Blick
gar nicht relevant zu sein scheint.

00:12:45.360 --> 00:12:49.760
Ja, du hast mir im Vorgespräch auch
berichtet, dass

00:12:50.800 --> 00:12:52.880
es zum Thema kommt Standardisierung.

00:12:53.640 --> 00:12:59.775
Das Themen aufkommen wie lokale
Entwicklungen, dann kleine

00:12:59.800 --> 00:13:03.615
maßgeschneiderte Entwicklungssysteme,
die sie lokal haben.

00:13:03.640 --> 00:13:07.960
Und das ist natürlich auch ein Thema,
das reinkommt in ein Assessmentphase.

00:13:09.320 --> 00:13:11.800
Man möchte ja aus dem
zentralen Team oft Es geht.

00:13:11.920 --> 00:13:16.200
Es geht oft um Standardisierung
und somit will man natürlich

00:13:16.240 --> 00:13:17.680
abweichen von nice to have.

00:13:18.400 --> 00:13:19.040
man.

00:13:20.320 --> 00:13:25.935
Dementsprechend ist aber auch wichtig,
dass die User die Prozesse

00:13:25.960 --> 00:13:27.160
und das System verstehen.

00:13:28.080 --> 00:13:30.160
Sonst ist es natürlich umsonst.

00:13:30.200 --> 00:13:34.560
Sonst ist es schwierig, auch für die
eben die Use Cases zu identifizieren.

00:13:34.920 --> 00:13:38.255
Und wenn sie das System nicht verstehen,
dann auch vollständig die

00:13:38.280 --> 00:13:39.440
Anforderungen mitzugeben.

00:13:39.720 --> 00:13:44.695
Das hast du mir im Vorfeld auch noch mal
gesagt, dass da das Prozesssicht versus

00:13:44.720 --> 00:13:49.560
Beispiele, dass es dort auch dort auch
sehr relevant ist, wie man da vorgeht.

00:13:49.880 --> 00:13:50.520
Absolut.

00:13:50.560 --> 00:13:54.695
Also gerade am Anfang ist es einfach
wichtig, Themen aufzunehmen, die Leute

00:13:54.720 --> 00:13:59.055
aussprechen lassen und einfach mal ohne
Bewertung aufnehmen, wie

00:13:59.080 --> 00:14:00.415
der jetzige Istzustand ist.

00:14:00.440 --> 00:14:04.415
Und dann kann man sagen ja, mit dieser
neuen Plattform zum Beispiel möchten wir

00:14:04.440 --> 00:14:07.775
Prozesse standardisieren und das, was du
jetzt machst, wird es so

00:14:07.800 --> 00:14:09.600
auch nicht mehr geben.
Vielleicht.

00:14:09.720 --> 00:14:13.655
Das kann man dann natürlich in einem
End to End mit verschiedenen

00:14:13.680 --> 00:14:14.695
Teilnehmern anschauen.

00:14:14.720 --> 00:14:16.655
Warum gibt es diesen Workaround?

00:14:16.680 --> 00:14:18.760
Der passt gar nicht in
die Standardprozesse rein.

00:14:18.800 --> 00:14:21.840
Ist er wirklich nötig oder können
wir das irgendwie anders abdecken?

00:14:22.000 --> 00:14:23.615
Aber erst einmal aufnehmen.

00:14:23.640 --> 00:14:27.240
Nicht, dass dann am Ende in der Testphase
oder vielleicht beim Go Live

00:14:27.880 --> 00:14:31.120
Erwartungen nicht erfüllt werden, dass es
dann heißt Ja, ich dachte, das

00:14:31.145 --> 00:14:36.135
funktioniert so, oder Ich dachte, das wird
ja Und das ist dann wichtig, dass man

00:14:36.160 --> 00:14:40.280
frühzeitig sozusagen, um scope
creep zu vermeiden, auch klar macht.

00:14:40.320 --> 00:14:42.520
Vielen Dank.
Wir haben jetzt alles gesehen, hoffe ich.

00:14:42.560 --> 00:14:48.080
Ja, 95 98 % sollte irgendwo
mal thematisiert worden sein.

00:14:48.120 --> 00:14:50.160
Und dann auch zu sagen,
wir setzen nicht alles um.

00:14:50.400 --> 00:14:54.000
Ja, das sind erstmal die kritischen
Prozesse, die braucht es.

00:14:54.040 --> 00:14:57.735
Und diesen Workaround, den wir später
vielleicht entweder gar nicht mehr geben

00:14:57.760 --> 00:14:59.920
oder den machen wir in einer Phase zwei.

00:15:00.240 --> 00:15:04.175
Wichtig ist einfach, dass man die Business
Prozesse generell abwickeln möchte und

00:15:04.200 --> 00:15:08.800
alles andere,
sagen wir 20 %, ist dann individuelle

00:15:09.400 --> 00:15:16.600
Prozesse und Regularien, lokale
Gesetze und so etwas gibt es immer.

00:15:16.640 --> 00:15:20.600
Man kann nicht sagen, wir machen alles
standardmäßig für alle gleich,

00:15:21.040 --> 00:15:25.120
aber man muss dann, wenn man etwas
spezialisiert, muss es auch

00:15:25.160 --> 00:15:26.920
einen richtigen Grund dazu geben.

00:15:26.960 --> 00:15:29.135
Einen Business Case eben.
Legal.

00:15:29.160 --> 00:15:31.920
Lokale Anforderungen.

00:15:33.360 --> 00:15:36.080
Und dann probiert man,
größere Bomben zu vermeiden.

00:15:37.600 --> 00:15:39.175
Genau.
Danke dir, Frank.

00:15:39.200 --> 00:15:42.960
Ich bin mir sicher, viele von unseren
Zuhörern und Zuhörer überlegen jetzt schon

00:15:43.000 --> 00:15:46.080
Ach, was könnte ich
vielleicht aktuell ändern?

00:15:46.200 --> 00:15:52.560
Oder zukünftig oder gleich am Anfang
gegebenenfalls Maßnahmen einleiten.

00:15:52.800 --> 00:15:56.200
Daher fasse ich noch mal die Hacks
zusammen und das unseren Zuhörerinnen und

00:15:56.225 --> 00:15:58.600
Zuhörern mitzugeben in
einer kompakten Form.

00:15:58.640 --> 00:16:04.615
Hack eins Wenn Scope zuschlägt und der Go
Live in Gefahr ist, so im laufenden

00:16:04.640 --> 00:16:10.335
Projekt, dann zieh die Entscheider für
einen Tag raus aus dem Tagesgeschäft und

00:16:10.360 --> 00:16:15.360
bring sie alle an den Tisch live
und entscheidet gemeinsam sofort.

00:16:15.640 --> 00:16:16.880
Dann Hack zwei.

00:16:17.120 --> 00:16:20.320
Denk an den Projektstart
schon an klare Leitplanken.

00:16:20.560 --> 00:16:25.400
Somit kannst du den Scope Creep
während des Projekts minimieren.

00:16:27.080 --> 00:16:29.440
Hack drei Sei konsequent.

00:16:29.680 --> 00:16:34.855
Ein klares Nein ist oft wichtig bei
zusätzlichen Anforderungen und daher frag

00:16:34.880 --> 00:16:39.735
dich Und die User sollten sich auch immer
fragen wie oft wird diese Funktion

00:16:39.760 --> 00:16:42.160
wirklich gebraucht und
wie notwendig ist sie?

00:16:43.960 --> 00:16:46.055
Frank Ganz herzlichen Dank!

00:16:46.080 --> 00:16:51.855
Das waren wertvolle Einblicke,
ehrliche Worte und ich bin mir sicher,

00:16:51.880 --> 00:16:55.480
dass wir alle neue Impulse
mitnehmen können heute.

00:16:55.520 --> 00:16:58.000
Ich freue mich, dass du mein Gast warst.
Super.

00:16:58.040 --> 00:16:59.295
Auch dir.
Vielen Dank, Anita.

00:16:59.320 --> 00:17:00.495
Vielen Dank für die Einladung.

00:17:00.520 --> 00:17:02.200
Mir hat es ebenfalls viel Spaß gemacht.

00:17:02.560 --> 00:17:03.760
Das war's für heute.

00:17:04.560 --> 00:17:06.200
Ich freue mich auf die nächste Folge.

00:17:06.440 --> 00:17:08.160
Bis zum nächsten Mal, Eure Anita.

00:17:14.480 --> 00:17:15.160
If you know.