Kijkend naar een aantal artikelen die de afgelopen tijd de revue gepasseerd zijn op deze site valt het me op dat de ict'er nogal eens de schuld in de schoenen geschoven krijgt als er iets anders gaat dan verwacht. Een rode draad die ik bespeur is dat vermeende oorzaken van het falen eigenlijk weinig tot niets van doen hebben met ict.
Dit staat of valt uiteraard met welke definitie van ict je hanteert. Onder het kopje Informatietechnologie geeft Wikipedia mijns inziens aardig weer waar het in de kern om draait: ‘het ontwikkelen en beheren van systemen, netwerken, databanken en websites’. Zelf wil ik het nog wel eens zwart-witter stellen: het echte ict wordt gedaan door de mensen achter de knoppen en tekentafel.
Neem bijvoorbeeld de veelbesproken kwaliteit van de software die door onze vakbroeders en -zusters in India gemaakt wordt. Is het de keuze van de vaderlandse ict’er om software daar te laten ontwikkelen, of zijn dit keuzes gemaakt door managers die veelal een niet-ict achtergrond hebben en puur naar de directe kosten op korte termijn kijken? Uiteraard zitten er in India ook minder goede programmeurs, maar die hebben we in Nederland ook. Echter, gebrek aan domeinkennis en -ervaring, cultuurverschillen en matig tot slecht opdrachtgeverschap zijn geen ict-eigenschappen toch? Dit zijn (al dan niet) weloverwogen keuzes vanuit management, niet vanuit de ict’er.
Slecht bid-management
Als klap op de vuurpijl hebben we dan natuurlijk nog het fenomeen ‘communicatie’. Communicatie heeft als eigenschap dat het typisch tussen twee (of meer) partijen plaatsvindt. Wellicht een leuke vraag om beantwoord te zien in de reacties: onder hoeveel verschillende projectmanagers heb je, als ‘uitvoerend ict’er’ mogen werken de afgelopen vijf jaar? Zelf kom ik al snel op acht. Bij elk van deze projectmanagers is er een aanloop-periode waarin je even aan elkaar moet wennen, en waarin je de communicatie-stijlen op elkaar aan moet passen om te weten wat je aan elkaar hebt binnen het project. Echter, bij het zo snel wisselen van projectmanagers krijg je, tegen de tijd dat je aan elkaar gewend bent, alweer een volgende projectmanager voor je kiezen.
Op één lijn zitten
Een vergelijkbare situatie zie je in sommige organisaties met betrekking tot de relatie lijn-/competence-/functionele-manager (of alle andere fancy namen die hiervoor ooit bedacht zijn) tot de uitvoerend ict’er. Door interne reorganisaties, natuurlijk verloop, promoties et cetera. krijg je als uitvoerende regelmatig een nieuwe directe manager. Ook hier kost het weer tijd voordat je samen op één lijn zit, het eens bent over een mogelijk carrière pad en qua communicatie elkaar weer begrijpt. Is het dan nog realistisch te verwachten dat een icter zich alsmaar aan blijft passen aan al die managers die komen en gaan?
Maar wat nu het meest frappante is: daar waar de diverse typen managers over elkaar heen buitelen in verwoede pogingen het falen in andermans schoenen te schuiven, blijft de uitvoerende tak van ons mooie vakgebied zitten waar ze zit. Bij iedere nieuwe manager zuchten ze maar weer een keer, passen ze zich weer aan en gaan gelukkig vooral verder met het gene waar ze goed in zijn: ict-bedrijven in de puurste vorm, dus zonder management poespas, maar vooral gericht op het ontwikkelen, beheren van systemen, netwerken, databanken en websites. Het geeft te denken dat deze uitvoerende tak binnen de ict soms tien jaar (of langer!!!) blijft zitten, en daarmee een schat aan ervaring en domeinkennis herbergt. Er zijn maar weinig managers die dit weten te evenaren!
I rest my case, and for those knowing me well, they know it’s not a clear case
Uitstekend artikel Pa Va Ke!
@Guus
Met dit fragment:
“Wat mij persoonlijk steeds weer verbaasd is dat blijkbaar iedereen verstand van IT heeft. Zelf matig ik mij niet aan verstand te hebben van boekhouden. Toch kom ik in de praktijk menig accountant tegen die advies geeft over ICT zaken waar mijn tenen van gaan krommen.”
Raak je een heel gevoelige snaar.
Er zijn helaas nog (te) veel mensen die niet snappen dat als een buurjongen van 12 een PC kan installeren, dat het in het bedrijfsleven zoveel moeite kost om alles in de lucht te houden.
@ Pa Va Ke
Als je een manager vertelt dat hij er een puinhoop van maakt moet je dat natuurlijk wel in zijn manier van taalgebruik doen. Iedere beroepsgroep, ook de onze, heeft een eigen taalgebruik. Als je over communicatie spreekt dan weet je dat “communicatie-stijlen” te maken hebben met taalgebruik. Pak je de boodschap in in een taal die je manager begrijpt, dan is de kans groter dat de boodschap aankomt.
Ik moet echter toegeven dat ik weinig denk aan carrière-bevorderend of niet. Oostenrijkers hebben heel erg veel moeite met mijn directe manier, die willen liever aangeslijmd worden, dat kan en doe ik niet.
Desondanks komen klanten terug nadat ze geschrokken zijn van eentje die gewoon zegt waarop het staat.
@Jan:
Als een manager iets van je gedaan wil hebben zal hij dat doorgans in zijn eigen taalgebruik doen. Snap je dat als ICT-er niet heb jij het gedaan.
Vertel je betreffende manager vervolgens in jouw taalgebruik dat ‘ie er een zootje van heeft gemaakt, heb jij je als ICT-er niet aangepast aan zijn taalgebruik, en heb je het wederom gedaan …
Ze verwachten wel dat je al ICT-er de taal van managers leert spreken, maar andersom ….
Kortom, als ICT-er trek je altijd aan het kortste eind.
In het artikel heb ik e.e.a. (bewust) wat zwart-wit gesteld. Uiteraard snap ik ook wel dat je als ICT-er bepaalde communicatieve vaardigheden nodig hebt. Maar typisch is dat er altijd geroepen wordt dat de ICT-er zich aan moet leren passen, maar dat het over de andere kant van de communicatie-kanalen altijd verdacht stil blijft.
Daar waar mid jaren 90 een enorme push werd gegeven om vooral ICT-ers meer soft-skills aan te trekken, is de behoefte aan meer vakinhoudelijke kennis en hands-on ervaring weer van belang vandaag de dag.
Het leuke epistel van Paul mij aan het denken zetten.
Als beide kampen (managers en ICT-ers) elkaars werelden niet (willen of kunnen) begrijpen dan kan je wel proberen allerlei vaardigheidsgesprekken voeren, maar je zult toch eerst dat verschil van inzicht moeten wegnemen.
Waarbij Jan wel de spijker op de kop slaat. Als de gezagsverhouding (managers zijn nu eenmaal de baas van de ICT-ers) een effect hebt op de manier waarop je omgaat met die verschillen in belevingswerelden, dan zoeken we nog steeds naar een natuurlijke manier waarop je hiermee omgaat. De ICT-er is van zijn baan afhankelijk van de manager. De manager is afhankelijk van het resultaat die de ICT-ers aan hem opleveren.
Is het dan nog steeds zo dat organisaties (waarbij ik dit even omschrijf als het collectief van individuen met al hun belevingswerelden en doelen/ambities) geen (vrij) gedragen doel? Met name de vertaling van het ultieme bedrijfsdoel naar individuele doelen zou een welkome aanvulling zijn. Het zou zo maar kunnen zijn dat er op elk niveau in een organisatie werknemers zitten (managers en uitvoerders) waarbij hun individuele doelen voor 80% niet aansluiten op de bedrijfsdoelen.
Het zou een verademing zijn voor veel organisaties (en bevrijding van veel medewerkers) om vanuit correct gepostuleerde missie, visie en strategie, de bedrijfsdoelstellingen te vertalen naar ieders individuele doelen. Door dit spel eens per jaar (of misschien 2x per jaar) te spelen, zouden er wellicht heel wat belevingswerelden tot elkaar kunnen komen.
@Jan van Leeuwen. Je zult mij ongetwijfeld geloven als ik zeg dat ik ook vrij direct ben.
Ik heb mij eigenlijk nooit om mijn (overigens iha prima) carriere druk gemaakt, maar merk wel dat ik tegenwoordig echt pas op de plaats maak om mijn gezondheid te beschermen (ik gedraag me welliswaar als een puber, maar het gaat hier nu toch wel erg rap richting de vijftig).
Ik heb altijd het geluk gehad met weinig lagen te maken te hebben,
maar merk de laatste paar jaar wel dat in de meeste bedrijven hordes lui bezig zijn met het project waar je mee te maken heb.
hordes lui waarvan ik meestal mijn twijfels heb over de meerwaarde voor het project.
e.g.
Tegenwoordig heb je voor een bescheiden projectje meteen een Marketing manager, projectmanager, project engineer, systeem architekt, database specialist en systeembeheerder nodig.
Ohhh en ehh heb je ook nog iemand die de klus uiteindelijk gaat doen of is die ook (op vakantie, wegbezuinigd, op zoek naar een andere werkgever) ?
Ik (mijn colega’s) zijn gewend om zelf een ontwerp te maken, dat in te regelen, code te schrijven, te testen, te integreren en op te leveren.
En ik doe echt niet aleen maar projectjes voor het lokale buurtschooltje.
Ik heb dan weer geluk, krijg zelden de schuld ergens van, al probeer ik het wel als het even kan op te lossen.
Boeit me ook niet echt, aan het eind van de maand rinkelt de kassa en dat was in eerste instantie toch de reden waarom ik ’s morgens om kwart over zeven op sta.
PaVaKe, weer een heerlijk artikel om te lezen. Je weet altijd weer te prikkelen en zinvolle dingen te schrijven.
Wat ik overigens vaak zie is dat de it-ers erg behulpzaam kunnen zijn, maar dat dit ook tegen ze gebruikt wordt. Zoals Paul al aangeeft met zijn (overbekende) grapje. Op het moment dat je het als it-er aanraakt is het ineens jouw probleem.
Overigens ligt het niet alleen aan de PM’s of aan de IT-ers al krijgen deze laatste inderdaad wat vaker de schuld aangepraat. Twee gedachten in dat kader:
– Realistische berekeningen om iets gedaan te krijgen worden praktisch altijd als veel te duur gezien. In dat opzicht is een kind krijgen net een IT project. De investering is veel groter dan men had verwacht, maar achteraf is men meestal wel blij dat ie gedaan is.
– IT is een lastig vak en niet IT-ers vinden het veelal niet interessant and a lot of work. Niet IT-ers kunnen vaak geen goede IT specs schrijven. Ik ben er voorstander van om een goede domein beschrijving te maken (DDD), deze is verstoken van vaktaal en legt uit hoe het domein werkt en welke processen er zijn. Als je kunt valideren dat de IT-er het domein begrijpt dan zal hij wellicht bouwen waar werkelijk behoefte aan is. Ook kan elke opgeleverde functionaliteit getoetst worden aan dit domein en hoeft er geen misverstand te bestaan.
Na zo’n 20 jaar pure IT ervaring heb ik geleerd dat kennis nagenoeg niet gecodificeerd kan worden, ofwel schriftelijk kan worden vastgelegd. Documentatie -hoewel deels noodzakelijk- mag niet als primair overdrachtsmiddel gezien worden. Kennis overdragen moet persoonlijk gebeuren door samen doen, laten zien en demonstratie.
Wat betreft de schuld krijgen; als ervaren freelancer ben ik redelijk sterk in het indekken en gebruik email hiervoor als primair middel. Ik koppel afspraken altijd per e-mail terug en vraag om een bevestiging. Daarnaast geef ik nadrukkelijk aan dat iets een schatting is en koppel ik vooraf terug als de schatting overschreden gaat worden.
Overigens vind ik 8 PM-ers in 2 jaar wel vrij fors. Dit is een garantie dat er kennis verloren is gegaan en minimaal een deel wellicht gewoon zijn handen er vanaf heeft getrokken. Ik denk niet dat IT erg gewild is bij project managers, dit omdat IT vrij exact is en je er wel moet verdiepen om tot goede resultaten te komen 🙂 🙂 🙂
Nogmaals dank voor deze realistische weergave van de werkelijkheid!
De grote vraag is hoe ICT de business het best kan ondersteunen. Zolang daar verschil van mening en vooral verschil van inzicht over bestaat zal de status quo nog wel even gehandhaafd blijven. Managers die zich als verwende gebruikers blijven gedragen en tegelijkertijd roepen dat ICT goedkoper moet met minder mensen bevorderen de oplossing niet – niet voor ICT, maar zeker ook niet voor de business.
Anderzijds, ICT’ers die zich als eigenwijze betweters blijven gedragen en de hakken in het zand zetten als er gesleuteld wordt aan de effectiviteit en efficiency van “hun” beheer- en leveringsprocessen dragen ook niet echt bij aan de verhoging van de.
Bottom line is dat de meesten gewoon bang zijn voor hun hachje. Als je die angst weg kunt nemen en mensen aan beide kanten perspectief kunt (blijven) bieden, dan ben je de bom.
@Ruud Dat goede ingespeelde team samenstellen is nog een lastig probleem. Daar zijn geen regels voor ben ik bang. Waar ik dan zomaar wat aan denk: de mensen moeten bij elkaar passen, het team is niet te groot, het zijn mensen met de juiste kwaliteiten en niet onbelangrijk, er moet goede leiding zijn.
Zeker in de aan trends onderhevige ICT waarin zoveel rollen zijn bedacht, iedereen doet mee, lijkt het Poolse Landdag model nog het meest voorkomende in project teams.
Het gaat altijd over communicatie. In de ICT wordt voldoende gecommuniceerd ben ik van mening, ook door technische ICT-ers. Onderdeel van je werk. Er zijn zelfs rollen in de ICT waar mensen een dagtaak aan communiceren hebben. Maar begrijp je elkaar wel? Om uit ervaring te spreken, het is absoluut geen vanzelfsprekendheid dat technische ICT-er elkaar goed begrijpen. Soms klopt het, soms ook niet. Laat staan dat technische ICT-ers aan niet ICT-ers kunnen uitleggen wat de stand van zaken of het probleem is. Of omgekeerd, niet ICT-ers hun kant van het verhaal over kunnen brengen. Ja, dat is een soft skill maar ook een kwaliteit niet een die je zomaar leert. Dat is een moeilijkheid bij het niet eenvoudige vakgebied van de ICT.
Nu vind ik ook dat het vakgebied er alles aan doet om de vaagheid en de moeizame communicatie in de hand te werken. Als ik nu alle artikelen die ik hier en op internet lees over bijvoorbeeld agile, big data, cloud, scrum, devops om een aantal hippe begrippen van nu te noemen dan valt me altijd op dat er met een vanzelfsprekendheid over gesproken wordt zonder dat ik lezende het idee krijg, ja dat is het. De goede teksten niet te na gesproken. Dat helpt ook niet bij de communicatie, deze vaagheid. Kijk, een harde schijf dan weet je waar het over gaat, ongeveer.
@PaVaKe Het zou goed zijn als technisch uitvoerende ICT-ers een veel belangrijkere rol gaan spelen bij beslissingen op ICT gebied. In ieder geval dat er een beroep gedaan wordt op die kennis. Ik heb het zelf meegemaakt dat er volledig voorbijgegaan wordt aan die kennis, het is ook wat ik van de ICT-ers om me heen hoor die dezelfde ervaringen hebben. Niet gekend, niet gehoord om uiteindelijk geconfronteerd te worden met oliedomme beslissingen, technische gedrochten en geldverslindende projecten. Al kan dat laatste ook doel zijn, dat geldverslinden.
@Henri Blij met je aandacht voor goede domein/fucntionele Specs, een zeer belangrijk onderdeel waarvan ik ook denk dat die juist (!) door de ICT afdeling (analist/ontwerper/ontwikkelaar) opgesteld zou moeten worden, niets concreter dan op papier waar het wederzijdse begrip hard gemaakt kan worden. Dat lijkt me nu belangrijk voor de communicatie. En dan kan je ook meteen die rol van de in de weg lopende productowner (ik wil dit, en dan wil ik weer dat) opdoeken. Nee, dan zou ik kiezen de zich ontwikkelende (agile toch?) specs. Mooi dat in deze discussie het belang van documentatie benadrukt wordt. Ik lees het wel eens anders.