Marcus stellt die Situation dar:
Situation Agentur, Launch Webseite markiert Stichtag Ende des Projekt
- Zwei Effekte
- Team ist foh, das System live ist
- Pulsanstieg beim Kunden
- Start des Servicevertrags in der Regel mit Zeitbudget.
Fragestellung der Session:
Wie kann die Zeit des Übergangs gestaltet werden? (manchmal geht es gut, manchmal knirscht es)!
Wie äußert sich das Knirschen (Nachfrage aus der Runde)?
- Kunde erwartet immer noch Bugfixing wie in der heißen Projekt-Schlussphase
- Ärger über Reaktionszeiten
- Ansprechpartner wechselt ggf.,
- manchmal entstehen neue Anforderungen sehr schnell nach dem Launch, das fertige System wird z.B. vom Management erst nach dem Going Live bemerkt (überraschte Wahrnehmung).
Die gewünschten Features können dann nicht mehr im Projektmodus bearbeitet werden. - Ggf. hat das Team keine Lust mehr zu Nacharbeiten.
Ideen für Verringerung des Knirschens:
- Übergang bewusst deutlich nach Going Live setzen, Arbeitsstil kann so noch eine Weile aufrechterhalten werden, Ansprechpartner bleibt gefühlt länger erhalten.
- Gestaltung des Übergangs in parallel laufenden Phasen
- Bewusstmachung der vertraglichen Änderung zum Kunden hin ist wichtig, dass alle wissen was auf die zukommt.
- Durch Übergangsphase werden auch technische Schulden vermindert.
- Viel Zeit für Gestaltung der Übergangsphasen einplanen,
- Je transparenter die Übergangsphase gestaltet wird desto besser.
- Vorbereitung des Übergangs solle bei Bedarf bereits zum Projektstart begonnen werden.
- Die Gestaltung und das Erleben der Übergangsphase ist auch wichtig für die Wahrnehmung des Projekterfolgs.
- Gemeinsamer Test mit dem Kunden, vermindert den Effekt der (überraschte Wahrnehmung, siehe oben)
- Sammeln von Änderungen in neuen Releases ermöglich die bessere Planung der Arbeiten.
- Frühe Lieferung und Protoypen sind hilfreich für die Vorbereitung des Kunden auf den Übergang.
Ergänzende Bemerkungen / Beobachtungen
- Teilweise ist es auch eine Kulturfrage wie der Übergang rezipiert wird, wird eher der Fortschritt oder eher der Fehler gesehen.
- Das Thema hat zwei grundsätzliche Aspekte, interne Organisation auf Seite des Dienstleisters einerseits und ein Kommunikationsthema andererseits.
- Die konkrete Gestaltung hängt vom Projekt (und dessen Größe) ab.
- Es gibt auch keine goldene Regel wer die Kommunikation machen muss, sie/er sollte auf jeden Fall von allen verstanden werden.
- Auf Dienstleisterseite muss das Geschäftsmodell klar sein, wird im Projekt oder in der Service Phase verdient.
Wird eher kurzfristig oder eher langfristig gedacht? - Falls langsamer Übergang nicht möglich ist sollte Entwicklungprozess und Servieprozess ähnlich gestaltet sein.
