Hoe vaak hoor je niet dat bij IT-projecten de plank volledig wordt misgeslagen? Een projectvoorstel en een Functioneel Ontwerp (FO) worden opgesteld op basis van een pakket aan vastomlijnde eisen en globale wensen. Maar in plaats van door te vragen naar wat de opdrachtgever nou echt bedoelt met die globale wensen, slaan de IT-ers die betrokken zijn bij het project er maar een slag naar. Ze doen allerlei interpretaties, gaan uit van vooronderstellingen en brengen eigen ideeën in. En dat is vreemd, want in plaats van met scherp op de roos te schieten, schieten ze nu met hagel; lekker breed in de hoop dat ze wat raken.
Dat het bij IT-projecten zo vaak misgaat, is echter niet alleen maar op het conto te schrijven van de IT-ers. Voor een deel is het ook te wijten aan de manier waarop projectvoorstellen en FO’s worden opgesteld. Er wordt veel gespecificeerd hoe, weinig wat en al helemaal niet waarom. En juist dat laatste zou veel meer moeten gebeuren, omdat je dan bij de kern komt. Vanuit het waarom, kom je vanzelf bij het wat en tenslotte het hoe.
Of de eisen nou tot in detail zijn vastgelegd in een functioneel ontwerp zoals de traditionele ontwikkelmethodes voorschrijven of zoals bij Agile het geval is, de eisen tijdens de ontwikkeling nog verder worden ingekleurd: IT-ers vragen niet naar de achterliggende businessdoelstellingen. En daarmee niet naar het waarom. Als je het mij vraagt, is dit de belangrijkste oorzaak dat de business en IT elkaar niet begrijpen. Dat er nauwelijks gevraagd wordt naar het waarom der dingen kan deels voortkomen uit gemakzucht of vooringenomenheid bij de IT-er.
Ik denk zelf echter, dat het vooral zo is dat IT-ers op basis van hun ervaringen en kennis wel een idee hebben waar de behoefte van de business ligt. Van daaruit maken ze vervolgens te snel de sprong naar oplossingen. Ik mag dan geen psycholoog zijn, ik heb al wel heel wat projecten van dichtbij meegemaakt. Dat er over het algemeen niet wordt gevraagd naar het waarom, heeft volgens mij ten eerste te maken met de tijdsdruk waar veel projecten toch mee te kampen hebben. Het is nou eenmaal sneller om maar gewoon te doen wat er gezegd wordt, in plaats van naar het achterliggende waarom te vragen. Ten tweede is het zo dat het doorvragen niet in de natuur van de gemiddelde IT-er zit. Ze bouwen braaf wat de klant vraagt en gaan daarmee voorbij aan wat de klant echt bedoelt.
En toch zou het vragen naar het waarom eigenlijk wel veel meer moeten. Simpelweg omdat je er betere oplossingen door krijgt. Beter in de zin dat fouten en verkeerde aannames in een vroeger stadium aan het licht komen, dat de oplossingen aan het eind van de rit zijn zoals de opdrachtgever ze bedoeld heeft en dat deze aansluiten bij de behoefte van de gebruikers. Apple is een bedrijf waar het vragen naar het waarom duidelijk wel gebeurt. Aan hun producten kun je zien dat ze niet zonder meer voortborduren op de tot dan toe bekende producten. Ze doen niet dingen zomaar omdat het altijd zo is geweest. De oplossingen van Apple zijn duidelijk anders en vernieuwend, ze hebben een andere look & feel en sluiten perfect aan bij de (soms nog niet bewuste) wensen van gebruikers.
Ik zou daarom elke IT-er willen oproepen om weer op zoek te gaan naar het kind in zichzelf. Kinderen zijn als een onbeschreven blad; zij hebben in hun jonge leventje nog niet de ervaring en kennis opgedaan die aannames mogelijk maken en vooringenomenheid in de hand werken. Zij treden de wereld onbevangen en met een ongekende nieuwsgierigheid tegemoet. Voor hen is niets vanzelfsprekend en ze vragen dan ook te pas en te onpas “Waarom?”. Maar we doen er beter aan de vraag serieus te nemen en een betekenisvol antwoord te geven. Want ze stellen de vraag niet voor niets. En zo zou het ook in de wereld van de IT moeten zijn. Daarom, waarde IT-er, ontdek het kind in jezelf opnieuw en stel die waarom-vraag! Het zal leiden tot begrip en verbetering.
Wijze woorden, het blijft een mooie moeilijke klus om te realiseren wat nuttig en onderhoudbaar is, in plaats van wat er gevraagd wordt.
Mijn mooiste projecten heb ik gedraaid waar goede mensen in de gebruikersorganisatie een jaartje werden vrijgesteld om voltijds met de informatici mee te werken, zonder zorgen over hun ‘echte’ werk; met een uutje in de week vergaderen krijg je geen nuttige communicatie op gang die aan het ‘waarom?’ toe komt. Ook het ‘waarom niet’ van de ITers kon in de discussie meegenomen worden voordat er systeemeisen officiëel geformuleerd en in steen gebeiteld werden. Het is zo gemakkelijk als je de mensen met de juiste competenties echt met elkaar samen kunt laten werken, in plaats van sequentieel hun zegjes te doen die dan netjes maar zonder begrip worden verzameld en zonder begrip worden gerealiseerd.