Het is alweer een tijdje geleden, maar ik herinner me het nog als de dag van gisteren. Het leek een interessante klus die we hadden aangenomen bij een grote overheidsdienst, maar vanaf dag één had ik er toch een slecht gevoel over. Dat had niets te maken met de opdrachtgever of met het werk dat moest worden gedaan, want dat was interessant genoeg. Nee, het had te maken met de manier waarop de opdracht was geformuleerd.
Het ging, zoals meestal, om een nieuw ict-systeem. Ik zal u niet vermoeien met de details, maar het vraagstuk had onder meer met geldstromen te maken en hoe die moesten worden ingericht. So far, so good. Er was echter één probleem: de oplossing van het vraagstuk stond al op voorhand vast. De richting van de geldstromen moest zus en de bijbehorende inrichting van het ict-systeem moest zo. Daar had de opdrachtgever lang over gepraat en lang over nagedacht, dus dat kon niet meer anders.
Ik ging er vanuit dat ik er niet genoeg van af wist om een andere mening te hebben, dus ondanks mijn voorgevoel ging ik met goede moed aan de slag. Het nieuwe systeem, dat inmiddels in de steigers stond, was niet rampzalig slecht, maar het was ook bepaald niet goed. Het was suboptimaal. Het had veel beter gekund als we er met z’n allen op een open manier naar hadden gekeken.
Het was na deze opdracht dat ik voor mezelf de regel opstelde: beter niet getimmerd dan dichtgetimmerd. Elke opdracht en elke opdrachtgever verschillen immers van de vorige. Maatwerk en denkwerk zijn altijd vereist. Als een opdrachtgever je aan het begin van de opdracht vraagt hoe je het gaat aanpakken, dan is er maar één eerlijk antwoord: ‘ik weet het niet’. Ik weet het althans niet precies. Ik moet nadenken, kijken en vooral heel veel praten. Praten met de mensen die de beslissingen nemen, met de mensen die het ‘echte’ werk doen en met iedereen daartussenin en daaromheen. Pas dan kun je een oplossing ontwikkelen die werkt.
Onlangs hadden we met een nieuwe opdrachtgever te maken waar dit probleem opnieuw de kop opstak. De afdeling inkoop stuurde op een resultaatsverplichting, en daarmee dus onbedoeld een vooraf geformuleerd gebrek aan oplossingsruimte. Het heeft even geduurd, er waren meerdere gesprekken voor nodig, maar uiteindelijk ging de afdeling inkoop overstag. Inmiddels zijn we alweer een tijdje bezig, en het proces verloopt goed. Heel anders dan bij de eerdere opdracht. Onlangs sprak ik een vroegere collega die daar nog steeds werkt. Inmiddels is het ict-systeem aan zijn vijfde versie toe. Nog steeds is niemand echt tevreden.
Paul de Kort, partner bij M&I/Partners
Dit artikel is eerder verschenen in Computable magazine jaargang 48, nummer 6, zomer 2015.
De valkuil van veel opdrachtgevers is dat ze in oplossingen denken in plaats van vraagstukken en doelen.
Men beschrijft bijvoorbeeld een workflow zoals deze in het vorig pakket geïmplementeerd was, of zoals men het ooit ergens gezien heeft, zonder goed na te denken waarom deze workflow is zoals deze is.
Zeker wanneer een nieuw pakket conceptueel anders werkt leidt dit tot menig discussie, zo is mijn ervaring.
Men zoekt naar bepaalde knoppen en functionaliteit die men gewend is, maar die is er niet meer. Dat het nieuwe pakket misschien wel efficiënter is wordt daardoor over het hoofd gezien helaas.
Zou dat dichttimmeren niet vooral veroorzaakt worden door (1) het voorkomen dat de afdelingen bij de opdrachtgever weer hun hobby’s gaan uitleven, waar (2) de leverancier weer graag aan tegemoet komt middels een extra uurtje-factuurtje?
Het is een glijdende schaal. Aan de ene kant een compleet dichtgetimmerde opdracht vanuit de opdrachtgever gezien. Aan de andere kant een opdrachtnemer die een probleem bij een opdrachtgever op de mauw spelt. En alles wat daar tussen zit.
Het is net zoiets als een keuken of badkamer plaatsen. Het is echt een illusie dat welke keuken of badkamerboer dan ook, alle keuken en badkamerinnovaties kent, kan bouwen en leveren. Die bestaat gewoon niet. Net zo goed als elke huisvader ook niet weet wat er in die wereld te koop is. Maar ook niet dat elke huisvader dat beter doet dan de keukenboer, maar er genoeg zijn die dat weer wel kunnen.
Kortom: zowel opdrachtgever als opdrachtnemer hebben beide een verantwoordelijkheid waar men op die glijdende schaal wil zitten. Wel eerlijk zijn naar elkaar, zeker qua realiteitszin en verwachting management. Als ik de keuken of badkamerboer een vrije opdracht geven om maar iets “moois” te bouwen, dan moet ik achteraf “niet zeuren” over het resultaat. Aan de andere kant, de keuken- en badkamerboer heeft ook verzuimd vragen te stellen omtrent de afbakening.
Als ik bij wijze van spreken een besteklijst inlever met de exacte lijst van onderdelen van mijn keuken, ook nog even aangeef waar hij ze mag inkopen en de installatie instructie op de vierkante centimeter, vraag ik mij af of er nog überhaupt nog een keuken- of badkamerboer is die met me in zee gaat.
Zo ook in de ICT. Vroeger dacht ik altijd dat de oplossing van dit probleem was, door op het bot alles uit te schrijven, zodat het duidelijk werd wat een ieder van elkaar verwacht. Uiteindelijk blijkt dat het onmogelijk is om daadwerkelijk elk aspect van je werk te beschrijven. Ook zou je dat willen.
Een ander aspect dat dwars door deze “contract onderhandelingen” door loopt, is het aspect van aansprakelijkheid. Veel organisaties worden intern gedwongen om eisen te stellen aan hun toeleveranciers, hoe vreemd dat ook overkomt. Natuurlijk kun je daar als opdrachtnemer tegen gaan verzetten en proberen dat te veranderen. Risico wat je daarmee loopt, is dat je de opdracht niet krijgt. Daar zit dan ook vaak de crux: neem ik de opdracht aan, ondanks de bezwaren die ik heb of niet.
Als ik dat zo lees, dan toch beter lijmen!
Leuk verhaal, en hoewel ik die ervaring niet zo heb kan ik het me goed voorstellen dat genoemde werkwijze de basis legt voor de grote mislukkingen waar we zo vaak van horen.
De belangrijkste valkuil van veel ICT projecten is de rol van de opdrachtgever die inderdaad vaak wil bepalen Hoe het systeem gaat werken en eruit ziet. Ik merk in de praktijk dat een opdracht al vaak een oplossing suggereert of zelfs voorschrijft, terwijl het natuurlijk in eerste instantie meer over het Wat zou moeten gaan. En wat betreft dan de te behalen doelen, de business case, etc. Herkenbaar verhaal.
@Willem
Is dat zo vreemd?
ik citeer je:
“de opdrachtgever . . . wil bepalen hoe het systeem gaat werken en er uit ziet”
Is dat niet de “business-case” van de opdrachtgever?
Wie anders als de opdrachtgever zou moeten/mogen bepalen hoe zijn systeem gaat werken en hoe het er uit ziet?