Vier strategieën voor het omgaan met wijzigingen

C. Jones komt in zijn onderzoek tot de conclusie dat bij een eenjarig project de requirements met gemiddeld 27 procent toenemen, bij een project van anderhalf jaar met gemiddeld 43 procent en bij een tweejarig project met maar liefst 63 procent. De belangrijkste oorzaken van wijzigingen in de requirements zijn voortschrijdend inzicht, wijzigende behoeften van de business en onvolledige of onjuiste requirements.

Je begrijpt dat ieder software ontwikkelproject een manier moet vinden om met deze wijzigingen om te gaan. Zij kunnen hiertoe inzetten op het verkleinen van het aantal wijzigingen (of beter verzoeken tot wijziging) en/of het gecontroleerd doorvoeren van wijzigingen.

Vroeger werden wijzigen op goedgekeurde requirements niet toegestaan. Afspraak is afspraak gold toen. Inmiddels is men daarvan teruggekomen en accepteert men dat wijzigingen onvermijdelijk zijn.

In de praktijk kom ik de volgende vier strategieën tegen:
- Kleinere projecten definiëren of grote projecten opknippen in deelprojecten. Het definiëren van de requirements is dan onderdeel van het kleinere (deel)project of heeft in ieder geval het kleinere (deel) project als scope.
- De requirements aanpak professionaliseren zodat de kwaliteit van de requirements stijgt. Het aantal wijzigingen door onvolledige en onjuiste requirements daalt dan sterk en de samenwerking met en tevredenheid van de stakeholders neemt toe.
- Een goed change controle process inrichten zodat je de wijzigingen gecontroleerd kunt doorvoeren. Een impactanalyse en bewuste kosten/baten afweging zijn hierbij essentieel.
- Overgaan op een agile werkwijze zoals Scrum. Agile anticipeert op (en stimuleert) het voortdurend doorvoeren van wijzigingen / verbeteringen. De hele werkwijze is daarop ingericht.

Welke strategie spreekt jou het meeste aan?