Heb je je weleens afgevraagd hoeveel van de door jou opgestelde requirements gewijzigd zijn nadat ze door de business stakeholders goedgekeurd waren? Grote kans dat dat er veel meer zijn dan je had gedacht (en gehoopt).
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?
Een paar gedachten
– meer tijd in het tijdframe ervoor stoppen scheelt in wijzigingen daarna
– meer kennis stoppen in de migratie van wijziging naar verbetering en niet in de serie – nu ik dit weet wil k ook nog dat en dat en dat
– verander, verbetertrajecten vergen kennis en ervaring en is nog niet uit een boekje
te halen.
In deze zin spreekt me nog geen van je 4 keuzes me aan…….