Mijn manager sprak me aan tijdens de lunchpauze en vertelde me dat hij een zeer ervaren projectleider had aangenomen. Hij had bedacht dat Ton, want zo heette hij,  bij mij op de kamer zou komen, zodat ik van hem zou kunnen leren vanuit de dagelijkse praktijk. Ton had veel ervaring opgedaan in de culturele sector met het organiseren van het jaarlijkse theater programma. Ik vroeg me af wat hij dan bij een IT-bedrijf kwam doen, want ik ben er altijd van overtuigd geweest dat een manager pas goed zijn rol kan vervullen als hij ook inhoudelijk verstand heeft van de branch waar hij in werkt. Volgens mijn manager moest ik me daar geen zorgen over maken en met een vette knipoog zei hij dat Ton toch culturele programma’s had samengesteld en wij programmeren hier ook, dus dat loopt wel los. En weg was hij weer.

Oude patronen

Ton heeft nooit bij mij op de kamer gezeten. Hij had de voorkeur voor een eigen kamer waar hij in zijn eentje kon werken en waar hij, met de deur dicht, “in alle rust gesprekken kon voeren met zijn resources en zijn stakeholders”, zoals hij het zelf uitdrukte. Ton was druk met het maken van planningen, het schrijven van rapportages en het ‘achter iedereen aanjagen’. Hij liep altijd rond met zijn Nokia aan zijn oor.

Ik heb niets van hem geleerd behalve de bevestiging hoe je dingen niet moet doen. Het was begin deze eeuw en je zou verwachten dat we ruim 20 jaar later wel beter weten. In die tijd kwam scrum alleen nog bij rugby voor, maakten we nog Gantt charts en kwam zelfsturing nog niet in ons kantoor jargon voor. Ton stuurde op tijd en geld, op deadlines en budgetten. We weten al 20 jaar en misschien zelfs wel langer dat dit een recept is voor gedoe, maar jammer genoeg kom ik 20 jaar later niet alleen nog te vaak een Ton tegen, maar zie ik ook nog de mechanismen terug die Ton bij de organisatie opriep.

Buffers plannen

Een tactiek die vaak gebruikt wordt om ervoor te zorgen dat je je werk op tijd af kunt krijgen is buffers inplannen. Hiervan bestaan meerdere varianten. Je kunt het aantal uren dat je verwacht aan een taak te besteden een stuk hoger inschatten met het argument dat je rekening moet houden met onverwachte gebeurtenissen of tegenvallers. Maar pas op, want Ton is niet dom. Hij weet dat je dit doet en zal jouw inschatting ter discussie stellen. Vaak begint zijn zin dan met zoiets als “het kan toch niet waar zijn, dat …” Verzin zoveel mogelijk rampspoed (Ton houdt erg van het woord risico’s) en negatieve ervaringen uit het verleden. Zorg voor wat onderhandelingsruimte en je komt op een getal uit dat haalbaar is. Zelfs als Ton tijdens de uitvoering bij je aanklopt om de druk wat op te voeren om de afgesproken deadline te halen.

Een buffer kan overigens ook heel handig zijn om andere dingen te doen die sowieso moeten gebeuren, maar waar Ton geen urencode voor heeft gegeven. Ze horen niet bij zijn project of horen volgens hem bij de ‘basis op orde’. Daar kun je het project niet mee belasten, dus dat moet je even regelen met je eigen manager of een andere projectleider, zal hij zeggen. Denk ook aan alle administratie die je moet doen. Je moet daar wel wat ruimte voor inbouwen, want Ton zal je vertellen dat dat wel in de losse momentjes kan. Je hebt vast nog wel ergens een paar minuutjes over, dus daar gaan we niet op plannen. Maar het lospeuteren van urencodes, het gedetailleerd verantwoorden van uren en het rapporteren over de voortgang kan je flink wat tijd gaan kosten. Creëer hier dus wat ruimte voor.

Wachttijden en overdracht

Een derde optie die je kunt toepassen is om wachttijden mee te plannen. Je bent immers afhankelijk van anderen. Je hebt tijd nodig om bij de ander de druk op te voeren, want die hebben vaak maar heel beperkt tijd. “Je weet hoe druk ze zijn bij beheer, Ton. Ik moet daar wel achteraan jagen en dat kost me, zeker bij die afdeling, altijd een hoop tijd.” Vergeet ook niet voldoende tijd te rekenen voor de overdracht zelf. Het moet goed gedocumenteerd zijn, want ook in de toekomst moeten we weten wat de verantwoordelijkheid van de andere partij was. Stel dat er in de toekomst iets fout gaat, dan moet je ze er wel op kunnen aanspreken.

Grondige analyse

Je moest in die tijd hoge eisen stellen aan de input die je kreeg voordat je aan een taak kan beginnen. Een grondige requirements analyse en het liefst een akkoord in de vorm van een handtekening. De scope dient ook nauwkeurig afgebakend te zijn. Dit doen we wel en dit doen we niet. Hiermee voorkom je dat er onverwachte werkzaamheden bij komen en je kunt jezelf later indekken tegen de toorn van Ton, want die zal zijn budgetten strikt gaan bewaken. Ton maakt zelf ook graag gebruik van deze tactiek, want hij heeft voor de klant een change procedure ingericht. Vaak is het zelfs een verdienmodel, want het zijn kosten op basis van nacalculatie en daar kan Ton flink aan verdienen voor zijn baas. Als de klant later nog iets erbij wil of het toch nog anders wil, dan zal hij zeggen dat dat nog niet zo eenvoudig is, dat alles opnieuw geanalyseerd moet worden, dat de consequenties van de wijziging op andere plekken in het systeem gevolgen kunnen hebben en dat alles uiteraard goed getest moet worden. Je kunt deze argumenten zelf ook gebruiken, want de werkelijke tijd die nodig is om al dit werk uit te voeren is moeilijk in te schatten en dus ook bijna niet te verifiëren

Ton was in control

Ton had voor ons gevoel altijd alles onder controle. Hij gaf ons in ieder geval die illusie en dat geeft op z’n minst een prettig gevoel. Als het anders liep, dan had hij er een goed verhaal bij. Hij deed aan de ene kant beloftes aan de klant en aan de andere kant was hij constant aan het sturen om dit waar te maken. Ton was in control. Althans, dat dachten we, want projecten liepen maar al te vaak uit en budgetten werden te vaak overschreden. Het was schijnveiligheid en iedereen speelde het spelletje mee.

Hoe het anders kan

Ik gaf je een paar voorbeelden uit de praktijk van toen. Kom je ze nu nog steeds tegen? Loopt Ton nog bij jullie rond? Één van de doelen van een transitie naar een wendbare organisatie was om de werkwijze van Ton en het gedrag dat hij oproept uit te bannen. Als dat bij jullie nog niet gelukt is, dan is jullie transitie nog niet volledig geslaagd en is er werk aan de winkel. Voor iedere organisatie kan de oplossing anders zijn, maar ik heb alvast een lijstje voor je met mogelijke aandachtspunten:

• Gaan jullie nog uit van een maakbare wereld? Wordt er nog gesproken over Ist en Soll en een plan om daar te komen? Dan wordt het tijd om te beseffen dat de wereld daarvoor veel te complex is.
• Hoe transparant maken jullie het werk? Blijft er nog veel onder de radar en houden mensen informatie bij zichzelf of is alles openbaar? Onderzoek met elkaar hoe dit anders kan.
• Maken jullie het werk zichtbaar? Kun je op ieder willekeurig moment aan de visualisaties zien hoe jullie er voor staan of moet je eerst flink zoeken en het aan anderen gaan vragen? In een ideale situatie zie je in één oogopslag waar je nu staat en waar jullie knelpunten zitten.
• Bepalen teams zelf wat ze op kunnen pakken of wordt dit door anderen bepaald? Is jullie product owner een Ton? Anders gezegd: is er sprake van een pull mechanisme of werken jullie nog volgens het push systeem?
• Leren jullie echt van jullie fouten en worden jullie daardoor voorspelbaarder en betrouwbaarder? Waar mensen samenwerken worden nu eenmaal fouten gemaakt. Als fouten maken niet mag en mensen zich er tegen moeten indekken om niet geslachtofferd te worden, dan zal er veel minder ruimte zijn om te leren.
• Werken jullie nog met urencodes per taak en uitgebreide uren verantwoording? Dit is een symptoom van het maakbare wereld idee. Software ontwikkeling is een creatief vak in een complexe omgeving en per definitie niet volledig voorspelbaar.  Wil je honderd procent voorspelbaar worden dan zul je flinke buffers moeten inbouwen. Daarmee wordt je dan wel weer heel erg duur.

De lijst is natuurlijk niet compleet, maar hij geeft je hopelijk voldoende ideeën om mee aan de slag te gaan. En als je jezelf herkent in Ton, besef dan dat jouw collega’s echt wel die deadline willen halen en het snappen dat budgetten niet oneindig zijn. Maak het transparant door duidelijk te zijn over doelen en kaders. Doe geen eenzijdige beloftes, maar maak alleen afspraken op basis van wederzijdse instemming. Ontwikkel gemeenschappelijk begrip door alle informatie op tafel te krijgen en creëer een omgeving waarin medewerkers het beste uit zichzelf kunnen halen en er ruimte is om te leren. Dan hoef je ze ook niet continu achter de broek te zitten, bij te sturen en te motiveren.