Van de week zat ik aan tafel met een aantal projectmanagers. We wilden het hebben over het slagen dan wel mislukken van ict-projecten. Is het met de slaagkans echt zo erg als veel onderzoekers zeggen? Waarom falen projecten eigenlijk, en wat kunnen we eraan doen om mislukken te voorkomen?
De discussie kwam al snel op dreef toen we het probeerden eens te worden over wat falen nu precies is. De loop van de discussie deed me sterk denken aan de tijd dat mijn kinderen nog op school zaten. Een 5,5 rond je af naar een 6, een 6 is ‘voldoende’ en dus is een 5,5 een prima resultaat! Toen was ik het hier niet mee eens, en nu nog steeds niet. Als wij als beroepsgroep respect willen verdienen, moeten wij ervoor zorgen dat it-projecten een duidelijk succes zijn en niet in discussie gaan over wel of geen ‘voldoende’.
Interessant genoeg kwam de invoering van de basisverzekering ter sprake. Heel belangrijk voor de zorgverzekeraars. Bijna allemaal hebben zij hun offertes op tijd de deur uit kunnen doen. Afgesproken is dat reeds geïncasseerde premies van mensen die zijn overgestapt binnen vier weken terugbetaald zullen worden. Dat zal waarschijnlijk ook lukken – dus blijkbaar kunnen wij het wel. De millenniumwissel in 2000 is evenmin uitgelopen op een ramp, zoals heel veel mensen verwacht hadden. Dat hebben wij ook heel goed gedaan. Een beetje aan de dure kant misschien, maar toch.
Wat zijn dan de verschillen tussen deze enorme operaties en de talrijke crm-, business intelligence en datawarehousing-projecten waar niemand tevreden over is? Het antwoord: duidelijkheid. Als iedereen weet wat het doel is, Y2K overleven, of offertes op tijd de deur uit krijgen, dan doen wij het heel goed. Moeilijk of niet, maar als wij praten over ‘integratie’ en ‘beslissingsondersteunende systemen’ heeft iedereen een eigen idee van wat er wel of niet mee bedoeld wordt. Helaas hebben de meeste projecten niet zo’n voor iedereen herkenbaar doel.
Dat is dan ook de oorzaak dat projecten falen. De gebruiker weet alleen dat hij meer informatie wil: beter, sneller, vaak beperkt tot een klein aantal dingen die hem echt interesseren, informatie die hij echt begrijpt. It heeft de neiging om over architectuur en infrastructuur te praten. Als het kan willen zij de grote piramide van Giza opnieuw bouwen – op zich een prestatie, maar dat kostte 25 jaar en had uiteindelijk maar één gebruiker. Niet helemaal wat wij willen met business intelligence…
Wat kunnen wij hiervan leren? Als wij bezig zijn met systemen voor gebruikers die niet precies weten wat zij hebben willen – en dat zijn de meesten – dan moeten wij heel flexibel zijn. Met het ontwerp van het datawarehouse, met de ETL-procedures, met de rapportage en de tools eromheen. Als je niet in staat bent om een overzicht binnen een uur volledig aan te passen, dan heeft het weinig zin het overzicht te maken. Je gebruiker gaat terug naar zijn spreadsheet, omdat hij die zelf kan aanpassen, met alle problemen van dien.
Norman Manley
