Het gebeurt nogal eens dat jonge projectleiders het slachtoffer worden van de bekende 'doorschuifspelletjes', waarbij de verantwoordelijkheid voor een fout als een puck bij ijshockey wordt doorgeschoven totdat een minder ervaren speler hem vanzelf in het eigen doel speelt. Hierbij speelt de neiging een rol om het iedereen naar de zin te willen maken.
Twaalf jaar geleden werkte de verkeersleiding van (toen nog) de spoorwegen aan de invoering van een automatiseringssysteem onder de naam VPT. Dit systeem was revolutionair. Het verving potloden en traditionele seinstelsels en had als doel planning en realisatie met elkaar te verbinden. Dat was nog niet zo gangbaar destijds en het was dan ook een pittige ambitie.
Opdrachtgever was een directeur, uitvoerder was de IT-club en de projectleider was een jonge baas van de verkeersleiding die gedelegeerde bevoegdheden had namens de directeur. Die verwachtte uiteraard van hem openhartige rapportage. Diezelfde directeur zette echter nogal wat druk op de zaak door te beweren ‘ dat met de deadline niet te marchanderen’ viel.
De IT-club beloofde een datum die niet gerealiseerd werd: 18 augustus. Toen het de directeur op 11 augustus bekend werd dat die datum niet gehaald werd, was hij woedend. Waarom had niemand hem op tijd ingelicht? De jonge projectleider werd verantwoordelijk gesteld. Hij werd van het project afgehaald.
De projectleider was sip. Kon hij er iets aan doen? Jawel, gaf hij toe, hij had de directeur op tijd moeten inlichten. Waarom had hij dat dan niet gedaan? Omdat de directeur zich star had opgesteld over de deadline. Hij had gedacht dat het geen enkele zin had om de vertraging te bespreken, en had gehoopt dat de boel uiteindelijk wel op zijn pootjes terecht zou komen. Hij vond dat hij domme pech had gehad.
IT ging vrijuit. Er was een bepaling opgenomen in het 117 pagina’s tellende boek met leveringsvoorwaarden, dat de deadline opgeschoven kon worden na overleg. Het gesprek waarin de jonge projectleider was medegedeeld dat de dealine niet werd gehaald, gold als formeel overleg. IT trof geen blaam!
Kom met uw praktijkervaringen op het terrein van managen en organiseren
Deel uw kennis, schrijf 3 columns of artikelen en ontvang een gratis pro-abonnement (twv €200)
Word een pro!
SCHRIJF MEE >>
Wat eens goed duidelijk moet worden bij IT-ers is dat ze te allen tijde leverancier / ondersteunde afdeling zijn. Zij maken dus per definitie nooit de keuze in iets en zijn altijd ondergeschikt aan de lijn / gebruikers. Mooi IT-woord trouwens “gebruikers???, heeft bij mij altijd de associatie met drugs en afstandelijkheid (wij en “de gebruikers???).
Voorbeeld: bij een eerste demo van een nieuw te ontwikkelen pakket heb ik 90 minuten geluisterd naar wat er allemaal al gedaan was aan het pakket (3 maanden bezig). Daarin werd aangegeven dat ze in staat waren om alle referentiegegevens in te lezen (klantgegevens, ordergegevens, afleverlocatiegegevens). Met andere woorden alles wat ik als lijn nu al weet staat in het nieuwe pakket! Wauw, wat zijn we trots. Als ik bij een autodealer een auto koop dan komt hij toch ook niet uitleggen dat ik er mee kan tanken en dat de deuren open kunnen. Ik snap ook wel dat veel tijd aan dit soort noodzakelijke zaken besteed moet worden. Maar vermoei mij als klant er niet mee, het is voor mij vanzelfsprekend dat dergelijke zaken het doen. Dat moet het voor een IT-er dus ook zijn anders mag hij/zij niet eens meespelen.
Ook een stuk zelfreflectie (als lijn) is nodig. Ik moet dus kennis hebben van IT om zaken te kunnen doen met IT. Daar schort het er dus aan, in dit geval (en vaker). Zowel bij de directeur als de opdrachtgever. De laatst heeft het via de harde school geleerd. De eerste zou het moeten weten. Je moet als lijn tijd steken in het opdoen van kennis over IT. Het is een van de belangrijkste ondersteunende middelen in huidige processen. Dus moet je er iets van weten. Zeker op managementniveau twijfel ik vaak of die kennis aanwezig is.
IT is nu vaak nog onbetrouwbaar, dat is ook logisch gezien de korte historie en snelle ontwikkelingen. Als lijn moet ik daar mee omgaan. Ik moet dus IT-chs leren praten.
Hetzelfde als ik een keuken of een auto ga kopen. Over het algemeen onbetrouwbare handel, zeker m.b.t. prijs. Wat ga ik dus doen: zeer heldere afspraken maken, alle regels en uitzonderingen goed doornemen, externe expertise inhuren (ANWB keuring), bij een bekend betrouwbaar adres kopen.
Is het terecht dat de ‘jonge’ projectleider de schuld krijgt? Ja! Hij heeft zich laten bedotten en dat mag je jezelf aanrekenen. Had hij steun moeten krijgen van de directeur? Ja! Want die had het kunnen weten en hij zit uiteindelijk met de gebakken peren.
Er zijn echter een paar zaken die mij opvallen, gevoed door mijn eerdere rollen als "linkin-pin" (implementatie-verantwoordelijke) tussen lijn en IT.
- je zult inderdaad de taal van "de bouwer" met enige basiskennis moeten spekken wil je tijdig gevoel hebben bij het voortgaan van een project
- escaleren doet (soms) wonderen. Het teruggeven van een (lijn)opdracht is stevig schudden aan de boom. Zeker bij harde einddatums zijn verantwoordelijken in mindere mate bereid of welwillend om naar negatieve berichten te luisteren of worden ze door de uitvoerenden lange tijd stil gehouden (herkenbaar?!). Als je dat tot een week voor oplevering zijn beloop laat, mag je zelf de vruchten plukken
- ik ben het volledig eens met de stelling van Rene, dat zowel de directeur alsmede junior blaam treffen. Had de junior niet in het beginstadium meer aan verwachtingenmanagement moeten doen en/of was het een bewuste keuze van de directeur om een niet/nauwelijks ervaren vent op dit project te zetten (refererend aan het artikel op de blog over afschuiven gesproken....)?
- hoe en of spreken bouwers en gebruikers (en ja, wat een stigma) elkaar aan? Omtrekkende bewegingen, ruis op de lijn, escapisme, gooien met modder (veelal verantwoordelijkheden). Natuurlijk is IT ondersteunend aan de lijn. Maar net als in mijn huidige functie kan ik geen goed product vermarkten als ik geen heldere verstandhouding heb met mijn productgevers. Het mes snijdt dus te allen tijde aan twee kanten, en daar zag ik het vaak fout gaan (zonder nu expliciet het waarom uit te leggen)
Als je ambitieus bent pak je alle ontwikkelkansen die op je pad komen. Dan weet je ook dat je risico neemt (zowel degene die de kans pakt alsmede degene die de kans biedt). Daar zul je dus heldere afspraken over moeten maken. Niets is zo makkelijk om iemand te laten sneuvelen; zoveel moeilijker om iemand tot grotere hoogte te brengen.
Er is dus sprake van een afgeleide ondernemersvraag: kun je het jezelf permitteren om iemand in zijn rol te laten groeien (low value/low risk) of moet er snel en effectief gescoord worden (meer ervaring veelal gewenst)? Die vraag had zowel de directeur als ook de projectleider zich op voorhand moeten stellen en op basis daarvan een betere afspraak tot stand moeten komen. En uiteindelijk zijn er nu alleen maar verliezers in dit spel....
Michel