Hallo,

es gibt Projektstarts, die sehen auf den ersten Blick ziemlich ordentlich aus.

Es gibt einen Auftrag, vielleicht einen Termin, ein paar Stakeholder, eine grobe Idee vom Ergebnis und natürlich die freundliche Hoffnung, dass diesmal alle wissen, was sie tun.

Und dann sitzt man im ersten Gespräch und merkt: Alle benutzen dieselben Wörter – aber sie meinen nicht dasselbe.

Der eine denkt an eine schnelle technische Lösung. Die andere an einen Kulturwandel. Der Sponsor will Sichtbarkeit. Der Fachbereich will Entlastung. Die IT will bitte nicht noch ein System pflegen. Und der Projektmanager sitzt da und denkt: Aha. Wir haben also kein Projekt. Wir haben ein Wimmelbild mit Budget.

Genau deshalb halte ich die ersten Stakeholder-Gespräche für einen der wichtigsten Momente im Projekt. Und zwar idealerweise vor dem Kick-off.

Denn der Kick-off ist nicht der Moment, in dem du zum ersten Mal herausfinden solltest, was alle Beteiligten wirklich erwarten, befürchten oder unbedingt vermeiden wollen. Im Kick-off holst du alle ab. Du erklärst das Projekt-Setup, machst Rollen, Ziele, Vorgehen und nächste Schritte sichtbar und sorgst dafür, dass Team, Kunde und alle weiteren Stakeholder mit einem gemeinsamen Bild starten.

Aber dieses gemeinsame Bild entsteht nicht magisch auf Folie 7. Es entsteht vorher. In guten Gesprächen. Mit guten Fragen.

Viele Projektmanager starten dabei zu schnell mit Aufgaben, Terminen, Lieferobjekten und Statuslogik: Was sollen wir liefern? Bis wann brauchen Sie es? Wer ist beteiligt? Wie oft wollen wir uns abstimmen?

Alles wichtige Fragen. Keine Frage. Aber wenn du nur auf dieser Ebene bleibst, bekommst du oft ein scheinbar klares Projekt, das auf dem Papier sauber aussieht und darunter schon die ersten kleinen Risse trägt.

Weil noch nicht klar ist, was Erfolg eigentlich bedeutet. Weil niemand ausgesprochen hat, welche Sorgen es gibt. Weil die Vorgeschichte fehlt. Weil Entscheidungswege diffus sind. Weil alle eine andere Vorstellung davon haben, wie die Zusammenarbeit funktionieren soll.

Und dann kommt später dieser wunderschöne Satz: „So hatten wir uns das aber nicht vorgestellt.“ Einer dieser Sätze, bei denen man als Projektmanager kurz innerlich altert. Um ungefähr drei Projektjahre.

Dabei hätte man vieles früher sehen können. Nicht alles. Projekte bleiben Projekte und sind keine Kristallkugel mit Gantt-Ansicht. Aber vieles kann man sehr früh sehen.

Der Schlüssel sind bessere Fragen. Nicht mehr Fragen. Nicht kompliziertere Fragen. Sondern Fragen, die unter die Oberfläche kommen.

Gute Fragen sind kein Smalltalk. Gute Fragen sind Frühwarnsysteme. Sie zeigen dir, welches Projekt wirklich vor dir liegt. Nicht nur das Projekt aus dem Auftrag. Sondern das Projekt mit Erwartungen, Ängsten, Interessen, alten Erfahrungen, informellen Machtverhältnissen und ganz praktischen Stolperfallen.

Für mich gehören deshalb fünf Kategorien in die ersten Stakeholder-Gespräche: Erfolg – Woran messen wir Wirkung? Sorge – Was könnte schiefgehen? Geschichte – Was ist vorher passiert? Entscheidung – Wer muss wann rein? Zusammenarbeit – Wie bleiben wir sauber im Austausch?

5 Kategorien mit guten Fragen für deine Stakeholder-Erstgespräche

1. 1

   Erfolg: Frage nach Wirkung, nicht nur nach Lieferung. Viele Projektstarts drehen sich zu schnell um Aufgaben, Termine und Lieferobjekte. Das ist wichtig, aber es reicht nicht. Denn ein Projekt kann formal liefern und trotzdem am eigentlichen Nutzen vorbeilaufen. Frag deshalb: Woran würden Sie in sechs Monaten sagen, das Projekt war ein Erfolg? Was muss danach besser, schneller, einfacher oder verlässlicher funktionieren? Was wäre zwar geliefert, aber trotzdem enttäuschend? Diese Fragen helfen dir, nicht nur den Scope zu verstehen, sondern die Wirkung dahinter.

2. 2

   Sorge: Frage nach dem, was noch keiner offiziell Risiko nennt. Viele Risiken stehen am Anfang noch nicht sauber im Risikoregister. Sie hängen eher als Bauchgefühl im Raum herum. Frag deshalb: Was macht Ihnen bei diesem Projekt am meisten Sorgen? Wo haben ähnliche Vorhaben früher geklemmt? Gibt es etwas, das offiziell nicht kritisch klingt, intern aber schon alle nervös macht? Diese Fragen bringen dich schneller an die echten Stolperstellen.

3. 3

   Geschichte: Frage nach dem Gepäck, das schon im Raum steht. Kaum ein Projekt startet wirklich bei null. Frag deshalb: Gab es schon frühere Versuche oder ähnliche Projekte? Was hat damals funktioniert – und was nicht? Welche alten Enttäuschungen, Konflikte oder Erwartungen sollte ich kennen? Das ist Kontextarbeit. Wer die Geschichte nicht kennt, interpretiert Zurückhaltung schnell als Desinteresse.

4. 4

   Entscheidung: Frage nach echten Entscheidungswegen. Entscheidungswege sehen auf dem Papier oft klarer aus als in der Realität. Frag deshalb: Wer entscheidet in diesem Projekt wirklich? Wer muss vor wichtigen Entscheidungen gehört werden? Wer kann das Projekt blockieren, auch wenn er oder sie offiziell nicht entscheidet? Diese Fragen sind Gold, weil du damit nicht erst spät herausfindest, wie dein Entscheidungsweg wirklich verläuft.

5. 5

   Zusammenarbeit: Frage, wie der weitere Austausch wirklich ablaufen soll. Gute Zusammenarbeit entsteht nicht automatisch, nur weil alle im Kick-off freundlich nicken. Frag deshalb: Wie möchten Sie im Projekt informiert werden? Wie früh möchten Sie Risiken oder schlechte Nachrichten sehen? Was wäre für Sie in der Zusammenarbeit richtig nervig oder sogar kontraproduktiv? Gerade die letzte Frage bringt oft sehr klare Erwartungen auf den Tisch.

Herzliche Grüße
Saskia

Hallo,

es gibt diesen einen Satz, bei dem ich in Projekten sofort hellhörig werde: „Können Sie noch kurz …?“

Noch kurz etwas prüfen, noch kurz etwas anpassen, noch kurz mit jemandem telefonieren, noch kurz eine Einschätzung geben, noch kurz einen Sonderfall berücksichtigen.

Klingt harmlos. Ist es manchmal auch.

Ich bin sehr dafür, im Projekt die Kirche im Dorf zu lassen. Nicht jede Mini-Anpassung braucht einen Change Request mit Fanfaren, Freigaberunde und Projektordner in dreifacher Ausfertigung.

Aber genau hier wird es spannend. Denn im Projektalltag muss man unterscheiden können zwischen wirklich klein und klingt nur klein, ist aber eigentlich schon Arbeit.

Ich hatte dafür über die Jahre meine persönliche 5-Minuten-Regel. Alles, was wirklich in fünf Minuten erledigt war, habe ich nicht extra gebucht. Aber alles, was darüber hinausging, wurde gebucht. Auch Telefonate. Denn Telefonate sind in Projekten selten „nur Telefonate“. Oft sind sie Beratung, Klärung, Entscheidungsvorbereitung, Risikoreduktion und manchmal auch ein kleines Stück Projekttherapie mit Headset.

Ein Kunde fragte mich einmal: „Buchen Sie wirklich jede Minute?“ Meine Antwort war sinngemäß: „Ja. Wenn Sie von mir gute Leistung möchten – und davon gehe ich aus – dann buche ich das natürlich. Eine Ausnahme sind wirkliche Kleinigkeiten. Und das sind bei mir Dinge, die fünf Minuten oder weniger dauern.“

Das klingt vielleicht streng, ist aber eigentlich ziemlich fair. Gute Projektarbeit besteht eben nicht nur aus sichtbaren Ergebnissen wie Tickets, Plänen, Konzepten oder Statusberichten. Sie besteht auch aus Denken, Einordnen, Nachfragen, Übersetzen zwischen Fachbereich, Technik, Kunde und Management – und aus dem Verhindern von Problemen, die später viel teurer wären.

Wenn wir diese Arbeit ständig als „ach, das machen wir noch kurz“ behandeln, verschwindet sie aus der Planung. Aber nicht aus der Realität. Und genau so entsteht Scope Creep. Nicht immer durch den großen Änderungswunsch mit offizieller Ansage, sondern durch viele kleine Zusatzschleifen, die niemand richtig zählt.

Der Punkt ist: Kleine Dinge sind nicht gefährlich, weil sie klein sind. Sie sind gefährlich, weil sie oft nicht bewusst entschieden werden.

5 Tipps gegen den „nur kurz“-Scope Creep

1. 1

   Definiere, was für dich wirklich klein ist. Für mich war die Grenze klar: fünf Minuten oder weniger. Alles darüber war keine Kleinigkeit mehr, sondern echter Aufwand. Diese Regel nimmt enorm viel Druck raus – man muss nicht jedes Mal neu grübeln, ob man nett oder professionell sein soll.

2. 2

   Übersetze „nur kurz“ in konkrete Arbeit. Wenn jemand sagt: „Können Sie noch kurz prüfen, ob das geht?“, steckt dahinter oft ein kleiner Analyseauftrag mit hübscher Verpackung. Eine gute Rückfrage: „Gerne. Damit ich es sauber einschätzen kann: Geht es um eine kurze Auskunft oder sollen wir die Auswirkung auf Aufwand, Termin und Umsetzung prüfen?“

3. 3

   Frage: Was soll dafür rausfallen? Wenn eine neue Anforderung ins Projekt soll, gibt es nur ein paar Möglichkeiten: mehr Zeit, mehr Budget, weniger anderer Scope, mehr Risiko oder schlechtere Qualität. Magisch verschwindet Aufwand nicht. Der wichtigste Satz: „Wenn das zusätzlich hineinkommt: Was soll dafür rausfallen, später kommen oder zusätzlich budgetiert werden?“

4. 4

   Mache kleine Änderungen sichtbar. Scope Creep lebt davon, dass er unsichtbar bleibt. Eine einfache Liste reicht oft: Was wurde gewünscht? Von wem? Mit welchem Aufwand? Welche Auswirkung auf Termin, Budget, Qualität oder Risiko? Wer entscheidet? Das ist keine Bürokratie, das ist Projekthygiene.

5. 5

   Schütze dein Team vor falsch verstandener Hilfsbereitschaft. Viele Scope-Creep-Probleme entstehen, weil alle nett sind – bis niemand mehr nett ist, weil alle erschöpft sind. Als Projektmanager ist es nicht deine Aufgabe, jede Bitte möglich zu machen. Deine Aufgabe ist es, sichtbar zu machen, was eine Bitte kostet.

Herzliche Grüße
Saskia

Hallo,

diese Woche hatte ich die Generalprobe für einen meiner Konferenzvorträge. Und ich habe wieder gemerkt, wie wertvoll es ist, wichtige Dinge nicht nur im Kopf durchzugehen, sondern wirklich einmal unter möglichst realistischen Bedingungen zu testen.

Nicht nur einzelne Folien anschauen. Nicht nur überlegen, ob der rote Faden ungefähr passt. Sondern den vollen Vortrag tatsächlich halten. Mit anderer Technik in einem großen Meetingraum, Anmoderation, Einstieg, Übergängen, Beispielen, Interaktionen, Timing, Publikum und anschließendem Feedback.

Genau das macht für mich den Unterschied zwischen „ich habe mal draufgeschaut“ und einer echten Generalprobe aus.

Viele denken bei einer Generalprobe vor allem an Verbesserungsvorschläge. Was muss noch anders werden? Welche Folie funktioniert nicht? Das gehört natürlich dazu.

Aber für mich war mindestens genauso wertvoll zu sehen, was bereits funktioniert. Welche Stellen tragen. Welche Geschichten beim Publikum ankommen. Welche Botschaften schon klar genug sind. Denn wenn man lange an etwas arbeitet, verliert man irgendwann den Abstand.

Eine gute Generalprobe holt einen zurück in die Realität. Und genau das brauchen Projekte auch.

Gerade vor wichtigen Meilensteinen oder einem Go-Live reicht es nicht, einzelne Funktionen isoliert zu testen und anschließend zu hoffen, dass sich im Zusammenspiel schon alles freundlich die Hand gibt. Eine echte Projekt-Generalprobe muss möglichst nah am späteren Ablauf sein: mit den richtigen Rollen, den vorgesehenen Zugriffsrechten, den relevanten Komponenten, den Schnittstellen, der geplanten Reihenfolge, den Übergaben – mit allem, was im echten Betrieb gleichzeitig passiert.

Und genau deshalb muss vorher sauber vorbereitet werden, was eigentlich getestet werden soll: Welche Features sind kritisch? Welche Komponenten müssen zusammenspielen? Welche Zugriffe braucht wer? Welche Reihenfolge ist entscheidend? Und woran erkennen wir am Ende, ob der Ablauf wirklich tragfähig ist?

Das klingt erstmal aufwendig. Ist es auch. Aber deutlich weniger aufwendig, als beim Go-Live festzustellen, dass zwar jede einzelne Funktion irgendwie funktioniert, aber der Gesamtprozess trotzdem elegant gegen die Wand fährt.

Natürlich ist bei solchen Tests selten alles perfekt vorbereitet. Dann ist die Versuchung groß zu sagen: „Dann können wir noch nicht testen.“ Ich sehe das anders! Dann testet man mit dem, was vorhanden ist. Denn auch ein unvollständiger Test zeigt, wo man steht.

Wichtig ist dabei: Dieser Test muss rechtzeitig stattfinden. Nicht drei Tage vor dem Go-Live, wenn jede Erkenntnis nur noch ein dekorativer Panikzettel ist. Sondern so früh, dass das Team danach noch realistisch nacharbeiten kann.

Dafür braucht es auch eine gute Dokumentation. Jemand muss festhalten, was funktioniert hat, was nicht funktioniert hat, was unklar war und was konkret nachgearbeitet werden muss. Bitte nicht nur die Fehler dokumentieren – auch das, was bereits gut läuft, gehört auf die Liste.

Drei Gedanken für deine nächste Projekt-Generalprobe

1. 1

   Simuliere den echten Ablauf, nicht nur einzelne Funktionen. Teste möglichst so, wie der Go-Live oder der spätere Betrieb wirklich ablaufen wird. Mit Rollen, Reihenfolge, Übergaben, Zugriffen, Daten, Schnittstellen und allem, was im echten Ablauf zusammenspielt.

2. 2

   Bereite genau vor, was geprüft werden soll. Eine Generalprobe ist kein spontanes Herumklicken. Lege vorher fest, welche Komponenten, Features, Zugriffe, Schnittstellen, Prozessschritte und kritischen Situationen getestet werden sollen. Bereite auch vor, wie du und das Team den Ablauf bewertet und dokumentiert.

3. 3

   Lass dich nicht abwimmeln. Bei fast jeder Generalprobe wird es gute Gründe geben, warum etwas noch nicht getestet werden kann. Häufig wartet das Team, dass alles perfekt fertig ist. Meine Reaktion darauf: „Wir testen mit dem Stand, den wir heute haben. Genau dafür machen wir die Generalprobe.“

Herzliche Grüße
Saskia