Nach Abgabe der Iteration kommt der Wunsch beim Auftraggeber auf, dass Feature XYZ sich anders verhalten soll. Ihr seid Euch über die budgetären Auswirkungen recht schnell einig. Aber wie wir die Umsetzung des Change Requests in den Projektplan integriert?
Für den Auftraggeber ist - ohne viel Worte - klar, dass der Change Request (CR) umgehend umgesetzt und ausgeliefert wird. Dieser häufig vorkommenden, impliziten Annahme ist eine transparente Projektplanung entgegenzusetzen.
Selbst in der Summe aufwandsneutrale Change Requests können zu veränderten Timings führen. Die Einplanung des Change Requests hat Konsequenzen:
- Kann der CR vom bisherigen Team ausgeführt werden?
- Oder braucht Ihr jetzt andere Kompetenzen im Team?
- Muss daher die Teamaufstellung geändert werden?
- Welche Auswirkungen aufs Timing hat das veränderte Vorgehen?
Diese Fragen stellen sich bei Mehr- und Minderaufwand genauso wie bei aufwandsneutralen Change Requests. Alle Fälle sind zu prüfen. Und der Auftraggeber ist über die Auswirkungen zu informieren.
Falls sich das Timing durch den CR verändert wird, kann ggf. durch Umpriorisierungen im Sinne des Projektziels mit einer veränderten Featureliste (Reduktion anderer Features) das Timing gehalten werden.
Dieser Blog-Post ist ein privater Beitrag von Judith Andresen.
- Nächster Artikel: Technischer Relaunch mit einer Prise Überraschung
- Vorheriger Artikel: Ankündigung IPC Night-Session | Kursänderung? Ja, bitte!
- Kategorie: Projekt
Kommentar schreiben