Softwareprojecten kunnen snel ontsporen. En de redenen hiervoor zijn divers. We overlopen negen signalen die je kunnen doen vermoeden dat je softwareproject de mist ingaat. ‘Als ik in het begin die woorden hoor, dan weet ik dat er ruzie van komt.’
IDC-analist Stephen Elliot schat dat dertig tot 35 procent van de it-projecten mislukt. Al zijn er ook studies, zoals van The Standish Group, die dat faalpercentage hoger inschatten: richting vijftig procent of meer. De problemen klinken bekend: de software doet niet (echt) wat gevraagd wordt en/of het budget en timing werd overschreden. Nochtans hadden ze het kunnen weten als ze deze signalen hadden opgemerkt.
1. Wijzigingen in managementsupport
Vaak zijn softwareprojecten het resultaat van de visie of voorkeur van één iemand uit het management. Zo iemand is noodzakelijk, maar als hij wegvalt, of van mening verandert dan is dat nefast voor het betreffende softwareproject.
Dikwijls komt voor it- of softwareprojecten één zogenaamde ‘executive sponsor’ naar voren. Maar voor de slaagkansen van zo’n project is het beter dat er binnen het hogere kader een echt sponsorverbond wordt gevormd. Ook al vraagt het misschien tijd en energie om meerdere kaderleden te coachen om hun rol als projectsponsor goed op te nemen.
2. Onduidelijke businessverwachtingen
Hoe duidelijk (of vaag) zijn de verwachtingen? Volgens Christiane Vandepitte, die als business-analist al dertig jaar maatsoftware ontwerpt voor grote organisaties, zit daar vaak het probleem. ‘Wanneer een bedrijf een opdracht geeft aan een it-bedrijf om een nieuwe softwaretoepassing op maat te ontwikkelen, dan wordt dikwijls gewerkt met een fixed price-contract’, vertelt ze.
Maar met een dergelijke regeling komen er later ook vaak problemen. ‘De prijs voor analyse en ontwikkeling wordt dan bepaald op basis van een oppervlakkige analyse van de wensen van de opdrachtgever. Dikwijls schiet die analyse tekort. Maar dat wordt pas vastgesteld als het contract al getekend is, en de analist aan de opdracht begint.’
3. Veranderende marktomstandigheden
Het is niet alleen management-steun die stabiel moet zijn, ook om je heen kan de wereld veranderen. Meer dan ooit. Hiervoor is de kans natuurlijk groter als je project zich richt op een snel evoluerende markt.
Al zijn de marktomstandigheden vandaag sowieso dynamischer dan pakweg twintig of dertig jaar geleden. Terwijl software-projecten maanden of langer blijven aanslepen, kunnen marktomstandigheden in dagen of weken veranderen.
4. Gebrek aan snelheid en flexibiliteit
Cruciaal voor het succes van een softwareproject is ook hoe snel je kan reageren op plotse aanpassingen. ‘Ontwikkelaars hebben er wat van weg om zelf de eenvoudigste wijzigingen te ingewikkeld te maken. Soms zijn de slimste ontwikkelaars hierin zelf het ergst’, merkt auteur Peter Wayner op op Cio.com. ‘Maar als het team problemen heeft met de meeste kleine veranderingen, wijst dit op een fundamenteel probleem’, vindt hij.
5. Slechte fundamentele keuzes
Om snel en flexibel te werken zijn agile methodologieën zo populair geworden. Al helpen die natuurlijk ook niet bij fundamentele wijzigingen van de scope van een project, zoals het compleet veranderen van een databaseschema als het project al vergevorderd is. Slechte keuzes op vlak van architectuur vallen bijvoorbeeld maar moeilijk recht te trekken. Hetzelfde geldt bijvoorbeeld als je kiest voor de laatste tools of frameworks die hun degelijkheid nog niet volop hebben bewezen.
6. Complexiteit niet onder controle
Wat vroeger al het geval was, en vandaag nog meer: software kan behoorlijk complex zijn. En niet iedereen kan die complexiteit goed inschatten.
‘Wanneer een bedrijf een opdracht geeft aan een it-bedrijf om een nieuwe softwaretoepassing op maat te ontwikkelen, dan wordt dat bedrijf op de vergadering vertegenwoordigd door een manager. Managers hebben dikwijls maar een vaag idee van de gegevensverwerking die hun afdeling uitvoert. Ze stellen de zaak te eenvoudig voor’, weet Vandepitte. ‘Pas later komt aan het licht hoe complex de oude, te vervangen softwaretoepassing eigenlijk is, hoeveel interfaces er zijn met andere toepassingen van het bedrijf of hoeveel werk de nachtelijke batchjobs verzetten.’
7. Complexiteit niet onder controle (bis)
Complexiteit is niet enkel een technische kwestie. ‘Indien de projectmanager iemand is met diepgaande technische kennis, dan is de kans groot dat hij de functionele complexiteit onderschat’, stelt Vandepitte. ‘Indien ik zo iemand de analyse hoor aanduiden als ‘het voortraject’, dan weet ik al hoe laat het is. Indien het project een naam draagt als ‘data migration’, terwijl het eigenlijk gaat om een fusie of overname gaat, dan weet ik dat het probleem onderschat wordt, en dat er later ruzie van komt.’
Het probleem van het beheersen van complexiteit doet zich, volgens haar, ook voor als men de ontwikkeling toevertrouwt aan een intern team. ‘Wanneer dan iemand van het team de projectmanager verwittigt dat het project de verkeerde kant opgaat, verwijt men hem vaak een negatieve houding, en wordt het probleem onder de mat geschoven. De informatici mogen hier niet over spreken met buitenstaanders, want zij tekenden een geheimhoudingsovereenkomst of non-disclosure agreement’, klinkt het.
8. Het team loopt leeg
Net als bij startups mag je de rol van het team, in dit geval het team van ontwikkelaars, niet onderschatten. Teams mogen om te beginnen al niet te groot of te klein zijn. Of niet afhangen van één iemand die alles weet, maar niets deelt.
En dan is er natuurlijk nog zoiets als personeelsverloop. Mensen wisselen voortdurend van baan en goede ontwikkelaars krijgen regelmatig werkaanbiedingen, maar als het team constant mensen verliest, is er een fundamenteel probleem.
9. Niet luisteren naar testers
Heel vaak onderschat, is het testen van de software. Heel wat programmeurs houden er van om nieuwe code te produceren. Maar testen is net zo goed een noodzaak.
‘Testers werken met test-scenario’s. Daarin beschrijven ze de gevallen die ze gaan testen, en het verwachte resultaat. Dat doen ze op basis van de analyse’, vertelt Vandepitte, die dit al talloze keren heeft zien foutlopen. ‘Indien de analyse niet goed, duidelijk of stabiel is, dan loopt dit fout. De testers trekken dan aan de alarmbel, maar niemand luistert naar hen.’
