Het zijn de grenzen die ons verbinden in plaats van dat zij ons van elkaar scheiden

Wat is een van de kernprincipes van lean? Flow, een continue stroom van waarde toevoegende activiteiten die uiteindelijk bij de klant uitkomen. Het liefst met zo weinig mogelijk overdrachtsmomenten. Als we agile gaan werken dan splitsen we het werk op in waardestromen, daarbinnen in epics en tot slot users-stories. Deze opsplitsing is belangrijk omdat je anders toch weer snel in het water valt ;-). Dit vraagt een grote verandering waarvan het nog maar de vraag is of het management voldoende bereid is om hier aan mee te werken. We horen nu al weer verhalen van organisaties waar men agile aan het terugdraaien is, omdat het niet direct de gewenste besparingen opleverde. Alsof besparingen ooit in het agile manifesto hebben gestaan, maar goed, dat is een ander onderwerp. Terug naar de agile transformatie.

Wat nu, als deze stap van verticale decompositie van de macht naar horizontale opsplitsing over klantenfunctionaliteit een te grote stap is. Wat doe je dan om een kleinere stap te maken? 

Laten we teruggaan naar een van de problemen die we bij grotere organisaties hebben. De verzuiling rondom bepaalde disciplines. We hebben marketing en sales, de HR afdeling, de bouwers, de beheerders, facility management, en ga zo maar door. Boven aan elke divisie, afdeling of team zit een manager en naarmate deze machtiger is, hebben te maken met koninkrijken en scherpe grenscontroles. De strijd om de macht is in volle gang en suboptimalisatie is de norm. Dat terwijl de hele organisatie het eigenlijk niet zo goed doet. Herkenbaar? Een ieder die ooit in een grote organisatie heeft gewerkt, zal dit herkennen. De grenzen van ons team scheiden ons.

Ook in projecten zien we iets dergelijks. Het begint al met een goede scope afbakening met de omgeving. Een van de grootste zondes van het projectmanagement is scope-creep. Het langzaam uitbreiden van de leveringen waardoor alles veel langer en veel duurder is. Begrenzen is goed. De boekjes die projectmanagement weer leuk moeten maken – was dat het dan niet – vertellen dat je juist kleine projecten moet doen. Kleine teams, niet te veel interfaces en ga zo maar door. De projectplannen staan vol met RACI tabellen om heel duidelijk de verantwoordelijkheden en bevoegdheden vast te leggen. Door de grenzen die we trekken, scheiden we de mensen van elkaar. We trekken ook hier een grens tussen management en uitvoering!

Althans, dat is de heersende metafoor. Grenzen brengen scheiding aan!

Maar, zo besefte ik me onlangs, kan je er ook op een andere manier naar kijken en dat levert een ander beeld op. Dit gezichtspunt is misschien wel een goede tussenstap om meer agility te bereiken. In plaats van dat grenzen ons scheiden, verbinden zij ons juist. Als ik deze zomer naar Frankrijk ga, moet ik meerdere keren de grens over. Van Nederland naar BelgiĆ«, als we de grens passeren dan worden we vrolijker, als we van BelgiĆ« aan Luxemburg gaan opnieuw en van Luxemburg naar Frankrijk helemaal, nu zijn we er bijna. Grenzen verbinden ons. Op de grenzen zijn conflicten die we moeten oplossen om meer klantwaarde te leveren. De gewenste toestand in elke organisatie is die van het verbinden van de grenzen. We gaan de managers belonen voor het verbinden.

Hoe werkt dat? Een ding schiet me direct te binnen. Escaleren doen we in het nieuwe paradigma niet meer. Wanneer een managers dat wel doet, dan is het de taak van de hoger liggende echelons de beide ‘strijdene’ partijen bij elkaar te zetten met de opdracht VERBIND! Als we dat nu eens een vol jaar doen, dat naast alle andere doelstellingen die we hebben: VERBIND! Misschien hoef je dan straks niet eens een megakanteling te maken. Want of je nu van boven naar beneden, of van links naar rechts klantwaarde levert, het is maar net hoe je het organisatieschema draait. VERBINDEN dat is waar het uiteindelijk om draait!

Help #agile werkt niet, wat nu?

Wanneer je agile benadert vanuit het best-practice paradigma dan is de constatering dat agile niet werkt een zeer verontrustende. Immers je hebt net veel geinvesteerd in de opleiding van je mensen. De projectmanagers ontslagen of een andere functie gegeven. Lijnmanagers gedwongen om te dienen, ga zo maar door. Als je dan tot de conclusie komt dat de IT projecten nog steeds niet de problemen oplossen, dan moet dat een frustrerende gedachte zijn. In het verleden heb je al kapitalen geinvesteerd aan andere methoden en nu had men je toch gegarandeerd dat agile dit nu wel een zou oplossen. Wat een telleurstelling!

Ik heb al eens eerder geschreven dat er zonder mindset geen transformatie kan zijn. Een van de onderdelen van die mindset is dat je niet meer denkt in best-practices, maar in learning-practices. Je hebt besloten in de organisatie om agile te gaan! Agile is geen methode maar een gewenste toestand. Het is een streven om de organisatie wendbaar te maken, zodat zij doorlopend meebeweegt met wat er in haar omgeving gebeurd, met als doel het blijvend leveren van klantwaarde. Het is een streven, niet een middel. Stel je besluit om dit al scrummend te doen, scrum is ook geen methode maar een raamwerk een kader waarin je zelf aan het experimenteren slaat om die toestand van agility te bereiken.

Help #agile werkt niet, wat nu? Is daarom niet de juiste vraag, het is er een die je niet kunt stellen. Beter zou zijn: “Zoals we nu doen, worden we niet agile, wat verhindert ons in de huidige werkwijze om dat wel te worden?” Kijk dan kom je nog ergens. De agile mindset is er een van snel falen waardoor je eerder leert. Als iets niet werkt dan hebben we geleerd, en kijken we welke obstakels in de weg liggen om bij ons streven uit te komen. Die verwijderen en dan proberen we opnieuw. Dat is agility zoals het bedoeld was. Al die mensen die tegenwoordig schrijven dat agile ook niet werkt, bewijzen de agilisten een grote dienst omdat we nu weten dat we nieuwe dingen moeten proberen om verder te komen.

Voor ons agilisten is een mislukking meer een hypothese die gefalsifieerd is dan dat het een persoonlijk falen is. Het geeft ons informatie en aanknopingspunten voor een volgende stap. We zeggen dan: Hoi het werkt niet! We hebben geleerd! Wat gaan we nu doen?

Het grote probleem met #risicomanagement in #projectmanagement

Wanneer je aan de gemiddelde projectmanager vraagt welke zaken belangrijk zijn bij het succesvol managen van een project dan is risicomanagement zeker een onderdeel van het antwoord. Een goede projectmanager identificeert, analyseert en beheerst de risico’s. Op die manier is de kans het grootst om de gestelde doelen te realiseren. Dat is de algemene veronderstelling. Een aantal observaties, ik laat even in het midden welke, triggerden mij om deze te onderzoeken. Ik kwam tot een onthutsende conclusie. Het traditionele aanleren van risico’s heeft desastreuze gevolgen voor de mentaliteit van de projectmanagers en daarmee ook voor de cultuur die er binnen de projectmanagementgemeenschap heerst.

We gaan uit van de veronderstelling dat risico’s te beheersen dan wel te voorkomen zijn. Daar is op zich niets mis mee. We kunnen oorzaken wegnemen, noodmaatregelen treffen, voor het geval dat. Allemaal dingen die je zeker moet doen. Een helm op de brommer, geen alcohol in het verkeer, niet appen in de auto, zeer nuttige risicomaatregelen. Het laatste wat ik wil is dat je stopt met voorzichtig te zijn. Echter de eenzijdige focus op het voorkomen van risico’s kan uiteindelijk leiden tot een wantrouwend beeld naar de toekomst. Omdat het zo belangrijk is binnen de projectmanagemengemeenschap en omdat ze er zoveel nadruk op leggen, lopen projectmanagers de kans dat zij daardoor een wantrouwende persoonlijkheidsstructuur ontwikkelen.

Kijk maar eens naar de reacties van projectmanagers op posts in je timeline op twitter of linkedin. Heel veel negativiteit. Heel veel statements hoe het beter moet! Ik ben veel projectmanagers tegengekomen die in een doorlopend gevecht met de omgeving zijn. Met de opdrachtgever, met resourcemanagers, met stakeholders, met het lijnmanagement en ga zo maar door. Is het je opgevallen dat de laatste tijd veel leden uit de projectmanagementgemeenschap met negatieve en ontkennende berichten komen over agile projecten? Waarom negatief, wat heb je te verliezen, vraag ik me dan af.

Ik heb in veel overleggen gezeten met projectmanagers en vaak is het een strijd van ‘wie het het beste weet, of waarom een bepaald iets niet werkt’. Het zijn toch vooral de projectmanagers zelf die een negatief beeld over hun collega’s hebben verspreid. Als ik bij een klant kom om een training voor projectmanagers te ontwerpen gaat het altijd over dat er iets ontbreekt en dat dat gefixt moet worden. Ook daar is het negatieve mensbeeld doorgedrongen. Terug naar risicomanagement, de grootte focus op het managen van risico’s activeert de ‘wantrouwende’ delen van ons brein overmatig, met als gevolg projectmanagers die in elke hoek een of meerdere risico’s zien. Dit is fout zowel voor onze projecten als dat het wreed is naar de mensen toe. Hoe lossen we dit op? Een eerste aanzet!

We omarmen onzekerheid en richten ons daar op in. We doen geen risicoanalyse meer, maar een van de onzekerheid die we hebben. Onzekerheid is het ontbreken van informatie, informatie krijg je door snel te testen of bepaalde aannames kloppen. Als je faalt doe het dan snel. Niet een mega-analyse met een nog grotere set aan maatrgelen. Neen, onzekerheid is als zwaartekracht, het is er altijd. De focus is niet op risico’s voorkomen, maar op informatie inwinnen en daarop reageren. Niet op inspelen, reageer snel op de kennis van het nu. De grootte zwakte van risicoanalyses is dat ze bol staan met aannames en dat wij mensen nu eenmaal de neiging hebben om foutieve aannames niet te corrigeren. Kom snel achter je ongelijk, het zijn niet de risico’s die je moet vrezen maar je eigen aannames over de toekomst.

Dit heeft uiteindelijk een positieve ontwikkeling op de persoonlijkheidstructuur van de mensen die in project samenwerken, een lerende persoonlijkheid in plaats van een wantrouwende!