I verkligheten är krav inte sällan föränderliga. Kundens förståelse för vad han eller hon vill ha ökar, marknaden förändras, etc. Projektarbetets krav kan komma att ändras under kursens gång. Exempel på kravförändringar från tidigare år är t.ex. ökade kvalitetskrav (koden skall följa en viss standard och kontrolleras med ett visst program), utökad funktionalitet (kalenderfunktion och synkroniserade kalendrar mellan olika klienter), etc. Vissa år har vi inte ändrat kraven. Det handlar om att planera för möjliga förändringar.
Om man inte har dokumenterat varför man löst ett visst problem på ett visst sätt, hur kan man då veta om man kan ändra den om kraven förändras? Om man inte har designat med tanke på underhåll eller framtida utökningar -- hur mycket arbete måste man kasta?
Ibland gör vi också ledningsmässiga eller projektorganisatoriska förändringar för att illustrera dessa poänger. Vad händer om vi skiftar alla beställare ett steg, från en grupp till en annan, (beställarna har olika hjärtebarn och olika syn på hur saker skall göras)? Hur vet den nya beställaren vad som har kommits överens om tidigare? Vad händer om vi flyttar runt alla programmerare mellan projektgrupperna? Kan de nya programmerarna läsa er dokumentation?
Alltså: planera för förändringar i krav och organisation. Se till att ni vet vad ni gör, skall göra och att ni har god kontroll över exakt vad ni har gjort.