Projecten veranderen voor de juiste oplossing

IT-projecten gaan fout, dat weten we allemaal. We kunnen dit vaak niet voorkomen, maar je kunt je wel voorbereiden op fouten. Feedback vragen helpt je om je zelf te verbeteren. Je kunt niet alle vereisten van tevoren weten. Voor een team van specialisten om dan een oplossing te ontwerpen en in te schatten en dat foutloos te doen, is gekkenwerk.

De vereisten en oplossing ontwerpen ontwikkelen zich als je meer kennis krijgt over het project en deze gaat ontwikkelen. De oplossing die wordt opgeleverd aan het einde is nooit de oplossing die van te voren is gespecificeerd. Het plan wat je aan het begin van het project maakt is nooit correct, het ontwikkelt en veranderd samen met de oplossing.

Vereisten zijn nooit compleet, worden gemist, worden toegevoegd, zijn niet goed of ze veranderen tijdens de ontwikkeling van het project.

Inschattingen zijn geen toezeggingen, maar een inschatting van de benodigde tijd gebaseerd op de informatie op dat moment. Deze inschattingen kunnen veranderen naarmate er meer informatie beschikbaar komt, en daardoor dus veranderen.

Plannen worden vaak gemaakt met de aanname dat er niks fout gaat, niks veranderd en er niks fout gaat. Maar plannen veranderen altijd, door juist dit te verwachten is een voordeel.

Verandering is een natuurlijk verschijnsel en juist goed. Verandering levert een project op wat nodig is, niet een project dat is ingeschat met minimale informatie en dat dus niet voldoet aan de verwachtingen.

Het is daarbij belangrijk dat iedereen er bewust van is dat plannen veranderen en lever het project op in kleine delen (sprints), en zorg ervoor dat je feedback in je proces verwerkt. Het doel van een project is het opleveren van een oplossing die de business nodig heeft, niet een oplossing op basis van de specificaties die gemaakt zijn met minder informatie.