Vanguard methode

Onlangs wees iemand mij op de Vanguard methode, afkomstig uit Engeland. Het gaat in deze manier om een andere manier van organiseren in dienstverlenende organisaties, minder vanuit de functionele hiërarchie en meer vanuit de klant gedacht. In een van de mij toegestuurde artikelen ('Klaar voor de toekomst') zet John Seddon, managing director van Vanguard consulting UK, dit uiteen in zes stappen.

De eerste stap is bereid zijn om anders te denken, door meer naar de werkvloer te kijken en vanuit de klant te denken. Niet denken dat je er met standaarden en normen bent. Het gaat er om de organisatie als een systeem te zien en niet als een top-down hiërarchie. De tweede stap is van buiten naar binnen denken en er vervolgens voor zorgen dat de mensen in de organisatie beter samenwerken om de klant te helpen. De volgende stappen betreffen de daadwerkelijke interacties met de klant, de doorstroom in de organisatie, de samenwerking binnen de organisatie en de rol van de manager in dit alles.

Deze manier van systeemdenken, geïnspireerd door de Lean methode in de Japanse maakindustrie, is buitengewoon waardevol. In het traditionele functionele en hiërarchische denken zitten absoluut valkuilen. Aan de andere kant heb ik het idee dat dit soort organisatieadviezen vanuit het systeemdenken hoge verwachtingen hebben van de inzet en het verantwoordelijkheidsbesef van medewerkers en van de rationaliteit van klanten. Volgens mij is het niet: het moet totaal anders, maar hoe kun je beide benaderingen combineren (en-en dus)? Tot slot met instemming een citaat uit een artikel van John Seddon: "Management's roles have to change from adversarial roles (controlling the worker) to complementary roles (solving problems beyond the control of the workers)".

PS. Dit is mijn 300e blog item

Loop alleen als het groen is

Dit is de titel van een boekje over business cases, dat ik onlangs toegestuurd kreeg van Bisnez Management. Er worden "veel projecten gestart zonder dat we duidelijkheid hebben over de kleur van het stoplicht". Twee aspecten springen er voor mij uit als het gaat om business cases: a) het expliciteren van de inschatting van de haalbaarheid van een project en b) het verbreden van het draagvlak voor een project. De grote vraag is natuurlijk waarom we toch oversteken, ook als het licht (nog) niet groen is. Rechtvaardigt de aanleiding/noodzaak of doelstelling van het project kortzichtigheid? Of is het gewoon niet eenvoudig om te bepalen of alle seinen op groen staan? En is het ook niet zo dat in een noodsituatie verkeerslichten niet aan de orde zijn (rennen voor je leven)?

Hoe dan ook, een business case kan zeker inzicht bieden in de slaagkans van een project, maar van elke business case geldt dat deze gebaseerd is op "subjectieve oordeelsvorming en onzekere projecties". In het werk moeten risico's genomen worden, omdat je nu eenmaal niet alles kunt voorspellen. In een business case zouden met het oog op de inschatting van de haalbaarheid alle risico's (én de impact) benoemd moeten worden, zeg maar als advocaat van de duivel. Niet alleen de risico's van het project, maar ook de 'gevolgschade' voor de organisatie zou in kaart gebracht moeten worden.

Maar moet dat allemaal zo uitgebreid? Gelukkig geeft het genoemde boekje daarover een paar relativerende opmerkingen. Een business case bij de grotere projecten is echter geen overbodige luxe, zeker niet als je meemaakt dat zulke projecten vaak de mist in gaan. Maar er geldt ook een ander statement dat ik onlangs aantrof op een brief van hetzelfde bedrijf: "het is nooit het model, altijd de mens". Je kunt nog zoveel aan analyse vooraf doen, maar als je de juiste mensen niet hebt voor de uitvoering, dan kun je maar beter stoppen.

De kloof

In het maandblad Informatie van deze maand las ik een artikel over goed opdrachtgeverschap, een thema dat me blijft boeien. "Een van de redenen waarom projecten niet succesvol zijn is de kloof tussen opdrachtgever en opdrachtnemer. Om die kloof te dichten worden er vooral aan de opdrachtnemende kant maatregelen genomen. Maar welke kennis heeft een opdrachtgever eigenlijk nodig en wat kan hij zelf doen om de kloof te dichten?" In feite speelt opdrachtgeverschap niet alleen rondom projecten. Iedere manager, bestuurder, toezichthouder is opdrachtgever.

Blijkens het artikel hoeft een opdrachtgever niet te beschikken over specialistische kennis (bijvoorbeeld over ICT of projectmethodieken), maar gaat het vooral om een houding van betrokkenheid in het gehele investeringstraject waarvan het project een onderdeel is. Bepaalde verantwoordelijkheden, zoals het betrekken van stakeholders, kunnen niet uitbesteed worden aan een projectmanager. De opdrachtgever van een project moet het overzicht houden en er voor zorgen dat in de organisatie de gewenste/noodzakelijke veranderingen in gang gezet worden.

De opdrachtgever zal de business case van een project moeten kunnen beoordelen. "Inhoudelijke kennis over het bereiken van het resultaat is niet primair nodig. Maar kennis over de mate waarin het project professioneel wordt georganiseerd wel. Wat zijn de mijlpalen? Welke risico's zijn er en wat wordt gedaan om deze te voorkomen? Op welke aannames is het plan gebaseerd? Hoe zijn de schattingen onderbouwd?" Uiteraard is het goed om enerzijds specialisten en anderzijds vertegenwoordigers van gebruikers in het traject te betrekken en daarin de nodige checks and balances in te bouwen. De opdrachtgever moet in ieder geval het proces bewaken en de randvoorwaarden stellen. Ten slotte, bedenk ook dat een opdrachtgever de enige is die in een project kan ingrijpen.

Job crafting

De Intermediair valt wekelijks bij mij op de mat, ik blader er meestal snel door heen. Dit weekend staat er wel een aardig artikel in: 'Boetseer je baan', over hoe je lol houdt in je werk zonder van baan te veranderen. Het valt me op dat vooral medewerkers die langer bij een organisatie werken, kunnen verzuren (of zeuren). Het centrale begrip in het artikel is job crafting, uitgelegd als:

• Zelf of samen met collega's mooier maken van je eigen werk door concrete aanpassingen in taken, relaties, cognities of context;
• Je werk beter laten aansluiten op je persoonlijke interesses, capaciteiten, behoeften en sterke kanten;
• Voor zover de organisatiedoelstellingen het toestaan en collega's en klanten er niet door worden benadeeld.

Het gaat er om dat je jezelf blijft ontwikkelen, dat heb ik altijd al belangrijk gevonden. Een mooi citaat: "Wie bevlogen is, blijft zich ontwikkelen en wie zich ontwikkelt, blijft bevlogen." Een droombaan is een karikatuur, bij iedere baan hoort corvee, maar je kunt je eigen baan wel een beetje leuker maken. Je kunt iets toevoegen aan je werk, contacten bijvoorbeeld of taken. Je kunt met een collega afspreken om taken te ruilen. Je kunt je zwakkere kanten ontwikkelen tot een acceptabel niveau. En je kunt eventueel vervelende taken afstoten. Alles in overleg uiteraard. Maar het allerbelangrijkste is om te snappen dat de mogelijkheid om te veranderen begint met eigen initiatief. Niet zeuren, maar aanpakken.