Is het je weleens opgevallen dat weinig projectmedewerkers zich echt in het te bouwen product verdiepen? Consultants, proces specialisten, managers en quality assurance experts verdringen zich om een punt van de taart, maar geen van allen lijkt echt oog te hebben voor het product.
Zolang er vergaderd kan worden over processen en risico’s, planning en organisatie, prioriteiten- en issuelijsten, ‘de grote lijn’ en de rolverdeling, maar vooral over de projectaanpak is er aan mankracht geen gebrek. De linkedin profielen varen er wel bij: Senior Principal Team Development Coach.
Chef gebakken lucht
In een eerder project had ik het genoegen samen te werken met een collega die zó graag vooruit wilde met het product dat hij tijdens vergaderingen op zijn handen ging zitten om zichzelf in bedwang te houden (zo leek het althans). Direct na de vergadering werkte hij in hoog tempo uit wat hij bedacht had tijdens het overleg. De volgende dag had hij het grootste deel van de oplossing vaak al af. Elke dag deed hij wat legio projectteamleden verzaken: echt naar het product kijken en met alles wat hij in zich had het product een stap verder brengen.
Helaas is de machinerie van het adviseren, managen, en in standaard processen gieten in sommige organisaties zo allesomvattend geworden dat vakmensen zich genoodzaakt voelen om onder de radar door in ieder geval iets gedaan te krijgen. Onder de radar door. Ongezien. Zorgen dat je uit de klauwen van het ‘geoptimaliseerde’ standaard proces blijft. ‘Dit is een prachtig idee, maar dat krijgen we nooit van de grond in deze organisatie. Laten we dit onder de radar door oppakken.’
Om een goed idee om te zetten in een goed product is ontzettend veel vakwerk en betrokkenheid nodig. Dat wordt nog weleens vergeten. De balans slaat vaak door naar bijzaken. Je echt verdiepen in de gebruikers en daar een onderhoudbaar product zo goed mogelijk op afstemmen vergt inlevingsvermogen en kennis van zaken om maar eens twee essentiële vaardigheden te noemen.
Betrokkenheid en vakmanschap
Betrokkenheid als absolute voorwaarde voor verbetering; de Beatles wezen ons al de weg: ‘Remember to let her into your heart, then you can start, to make it better (…) The minute you let her under your skin, then you begin, to make it better.’ Volgens Wikipedia heeft Paul McCartney ‘Hey Jude’ gecomponeerd in de auto op weg naar Julian Lennon om hem te steunen tijdens de scheiding van zijn ouders Cynthia en John. ‘I was truly surprised when, one afternoon, Paul arrived on his own. I was touched by his obvious concern for our welfare … On the journey down he composed ‘Hey Jude’ in the car. I will never forget Paul’s gesture of care and concern in coming to see us’, zei Cynthia Lennon.
Geen songwriting process managers, songtext consultants of arrangement coaches, maar betrokkenheid en vakmanschap. Dat zorgt voor mooie producten en tevreden gebruikers. Het wordt tijd om vakmanschap en echte betrokkenheid weer op de radar te zetten.
The Nail on the head!
Ik heb hier binnen Computable met regelmaat dezelfde discussie door te stellen dat IT/ICT 100% voorspelbare materie is doordat elke stap van elk proces, binnen elke IT discipline, 100% afhankelijk is van voorafgestelde vaste waarde.
Het probleem bij de consultants, de ‘gebakken lucht mensen’ is gewoon dat zij dit klaarblijkelijk niet weten, er zich dus niet naar conformeren, ergo er door die ‘andere dynamiek’, hoe je deze ook zou willen noemen, er verantwoordelijk voor zijn waarom het toch zo vaak schromelijk verkeerd kan gaan, ergo, zoveel meer kost dan werkelijk zou moeten.
Een volzin ik weet het maar toch.
Het grote verschil zit hem in de hier naar voren gebrachte professional die gewoon naar het proces/project/product kijkt en daarmee aan de slag gaat terwijl al die anderen bezig gaan met vaak van alles en nog wat behalve dat proces/project/product.
Het lastige is dat al die hele knappe koppen/professionals zo vaak vergeten hun ‘klanten’ uit te leggen hoe het werkt en hoe je daar nou het beste mee om gaat. Wat dan vervolgens weer de basale oorzaak is waarom ‘men’ dan zo vaak weer onder de radar duikt.
Zeer herkenbaar.
Mijn gok is dat de waarheid – zoals vaak in het midden ligt.
Ik ken ook hele bakken “nerds” (net zo kinderachtig als consultants allemaal afschilderen als “de gebakken lucht mensen”) die als een gek iets in elkaar flansen, totdat ze erachter komen dat het geproduceerde nergens kan landen, te complex is, en nauwelijks aansluit bij eindgebruikers dan wel enig business model.
Beiden zijn relevant. Inmiddels duidelijk dat agile in combinatie met DevOps geen haarlemmerolie is. Het zijn goed bedoelde initiatieven om een stap in de goede richting te zetten. Maar doen alsof er totaal geen “grote lijn” bestaat is de werkelijkheid ontkennen. Zowel de IT-industrie, de organisaties waar IT bedreven wordt als de eindgebruikers veranderen echt niet van de een op de andere minuut: dat is puur een menselijke eigenschap.
Kijk voor de lol eens naar het aspect veiligheid in al zijn dimensies bij een gemiddeld project. Iedereen zal het toch eens zijn dat dat nog steeds een onderschoven kindje is. Ja het is opgenomen in veel methodieken, ja het is opgenomen in de daarbij gebruikte tools. Maar…….toch nog steeds gatenkaas. Goh hoe zou dat nu komen. Ik weet: het is niet sexy, iets veilig te ontwikkelen (waarbij meer aspecten zijn betrokken dan puur software ontwikkeling).
ik pleit voor iets heel banaals: echt samenwerking, maar dan zal de gehele organisatie moeten veranderen qua cultuur.
Handshake Atilla ….
Bedankt voor deze bijdrage en het vragen van aandacht voor vakmanschap (mannen en vrouwen).
De successen die ik ken en die ik zelf mocht vieren met diverse teams, zijn gebaseerd op vakmanschap, grote nieuwsgierigheid en gretigheid om nog betere prestaties te leveren en uiteraard met oog voor de andere teamleden en grote inzet!
Vakmanschap op het gebied van kennis van de business vanuit de optiek van de organisatie en vanuit wat de markt vraagt/of op zit te wachten; vakmanschap op het gebied van ontwerpen.
Een andere sleutel voor de successen: testen, testen, testen, ..