Voor zowat elk soort project zijn er enorm veel schakeringen tussen “bijna klaar” en “helemaal klaar”. Die regels die in alle projectmanagementboeken staan — van planningen en dat de laatste 20% van het werk 80% van de tijd innemen en dingen.
Ik was een tijd geleden aan het kijken naar een ding dat ontwikkeld werd en dat “bijna helemaal klaar” was.
En oh wat had ik flashbacks naar tien jaar geleden, toen we dingen moesten maken — zoals in, dingen van nul af aan maken, complexe dingen. Waar precies dat ook gebeurde. Werk dat “bijna helemaal klaar” was, waar de klant alsmaar kleine of grote opmerkingen had, en dat het eindeloos lang bleef aanslepen.
Het “ah ja maar ik dácht dat dit zó zou werken”-syndroom. Of nog, het “het is allemaal in orde hoor, alleen nog dit klein dingetje”-syndroom, waarbij dat klein dingetje inderdaad heel erg klein lijkt, maar eigenlijk iets verschrikkelijk lastig is.
Nu is er gratis open source-gerief, dat zaken doet waar tien jaar geleden geen enkel zelfs commercieel pakket voor kon gevonden worden. Het was anders dan het nu is, maar tegelijk is er niets veranderd. Een mens krijgt wel eens het verwijt om consultantees te spreken, maar hey: scope management en expectation management en dergelijke zijn vlaggen die echt wel ladingen dekken.
*
* *
Ik was ook een tijd geleden bij mensen aan het kijken naar een ding dat jaren geleden ontwikkeld werd en waar ze niet honderd procent tevreden van waren.
En oh wat had ik opnieuw flashbacks naar tien jaar geleden. Van die situaties waarbij er aan de ene kant mensen staan die niet weten wat ze willen, of beter, die het wel weten maar het niet gecommuniceerd kregen. En aan de andere kant mensen die denken begrepen te hebben wat de klant wil, en die denken duidelijk gemaakt te hebben wat de klant mag verwachten, maar het eigenlijk niet begrepen hebben, en het eigenlijk niet duidelijk gemaakt hebben.
Waar alle betrokken partijen wel snappen dat er iets niet klopt, maar er de vinger niet op willen of durven leggen, en hopen dat het allemaal nog min of meer goed af zal lopen, maar waar het natuurlijk niet goed afloopt.
*
* *
Wat een gemak soms, om zo als consultant binnen te kunnen komen, de situatie te overschouwen, uit een zak ervaring (en/of uit een doos boeken, naargelang) een oplossing tevoorschijn te toveren (of een begin van oplossing, of een voorstel van oplossing, of een poging tot begin van voorstel, naargelang), en dan weer naar huis te kunnen gaan.
Wat een gemak om alleen bij het begin van een project aanwezig te moeten zijn en niet van vóór het begin tot het bittere eind te moeten blijven. Of, naargelang: alleen op het einde van een project / alleen maar in één van de fasen van het project / alleen maar bij één aspect van het project.
Reacties
3 reacties op “With a motorbike made of jealousy (i)”
Dat gemak, is zeker geen gemak voor de mensen die daar nog zitten.
In vele gevallen -niet altijd, maar toch in de meeste- komt het er toch op neer dat hetgeen door de externe consultants achtergelaten is, toch een soep / brol is.
Frederik, daar geef ik je gelijk in. Jammer genoeg wordt er heel weinig klantgericht gedacht. Elk automatisatieproject moet zich aanpassen aan de ideale workflow, niet andersom. De gedrochten die ik al heb zien/moeten bouwen..
Ik heb absoluut geen zak ervaring met allerhande foutgelopen projecten en “lessons learned”. Toch merk ik steevast dat bij elk project waarin ik betrokken ben, blijkbaar niemand beter de gevaren en pitfalls kan detecteren dan ikzelf. Ik zie waar het fout kan lopen en ben erg sterk in probleemoplossend denken.
Wat ik heel graag doe is uitzonderingen bedenken nadat iemand een automatisatiescenario heeft bedacht. Ik heb ook altijd wel een oplossing voorhanden, meestal met een schatting van de extra kost. Grappig om te zien hoe de ‘experts’ het probleem zelf niet gezien hadden én er vervolgens geen oplossing voor vinden. Drama’s die ik zo al vermeden heb!
Terwijl de klant het doel schetst, heb ik blijkbaar een aangeboren neus om te zien wanneer de rest van de “analisten” de noden van de klant helemaal fout begrijpen of veel eenvoudiger zien dan ze in werkelijkheid zijn. Elke klant is uniek, maar daar merk ik niet veel van in zo’n besprekingen. Dat bandwerkgedrag is verschrikkelijk.
Momenteel ben ik echter meer een technieker, terwijl het analyseren en vertalen in projectomschrijving (met ins en outs) meer mijn ding lijkt te zijn. Ik bedenk graag goeie oplossingen en techieken, maar laat de realisatie liever over aan anderen…
Ik werk echter graag vanuit een passie, vanuit het gevoel de klant zoveel mogelijk oplossing te geven voor het gevraagde geld. Ik haat projecten waarin ik het gevoel heb dat de klant een geldmachine is, alleen belangrijk tijdens het betalen van de factuur. Ik haal geen waarde uit een implementatie die onvoldoende ‘proper’ werkt, of wanneer er niet eerlijk is gecommuniceerd dat met het beschikbare budget nooit een goede oplossing gemaakt kan worden. Voor de helft van de prijs heb je namelijk bijna altijd een half-werkend geheel, ipv de helft van de features… In de contacten die ik vanuit mijn huidige job in het verleden had met externe consultants kreeg ik altijd dat onaangename gevoel… Is dit overal, of bestaat mijn droomjob toch?
Tiens, ik had dat gevoel onlangs gelijk ook in dit verband: “weten wat ik wil, maar het niet gecommuniceerd krijgen.” 🙂 Maar dan heb je een goeie ziel nodig, die wel consultantees spreekt. Die pro bono eens wil langskomen. En die dan vraagt: “Heb jij dat wel écht nodig?” “Echt?”. En die dan het verschil uitlegt tussen toeters en bellen en de essentie van information management. En je op weg helpt. Zonder salespitch. Dat zijn de goeie.