Två av tre IT-projekt misslyckas
Så var det dags igen: en ny undersökning som slår fast att bara vart tredje IT-projekt lyckas och att det sett likadant ut i 40 år. I dagens artikel i CS lägger KTH-professorn Torsten Cegrell en stor del av skulden på beställarsidan och alltför omfattande specifikationer med dålig koppling till verksamhetsnyttan som eftersträvas.
Det är svårt att inte hålla med om den kritik som kommer fram och det gör lika ont varje gång som de typiska nybörjarmisstagen görs om. Jag tycker ändå det finns skäl att notera att moderna IT-projekt inte nödvändigtvis bör drivas som beställningar via ett kontrakt där specifikationen är klar vid upphandlingstillfället.
Många projekt, oavsett hur väl verksamhetsnyttan/effektmålen är specificerade, stupar just därför att man trott att det varit möjligt att i detalj kravställa nödvändig funktionalitet i början av projektet. Vissa projekt kräver helt enkelt ett annorlunda angreppssätt och systemutvecklingsmetodiker som RUP (med iterativ detaljering av specifikationen) och olika agila metoder som t ex Scrum har vuxit fram för att möta behoven i den typen av projekt.
Är lösningen då att alltid välja Scrum, eller nästa metodikbuzzword som dyker upp? Absolut inte! Däremot är mycket vunnet om åtminstone en person i styrgruppen, och definitivt projektledaren, har förståelse för styrkan och svagheten i en vattenfallsmodell, styrkan och svagheten i RUP, styrkan och svagheten i agila metoder osv och sedan funderar lite över organisationens mognadsgrad, projektets mål och syfte och anpassar metodiken baserat på lång erfarenhet och med fingertoppskänsla.
Lyckas man med det – och dessutom har en beställare som vet vad han eller hon vill – då går det absolut att förändra de tråkiga siffrorna med två av tre IT-projekt som misslyckas.
