Al weer 10 jaar werk ik als projectmanager in een Engineer to Order omgeving. Al die tijd dacht ik dat ik een goede projectmanager was. En met goed bedoelde ik dat ik mijn projecten vaak op tijd en volgens specificaties afleverde. In ieder geval vaker dan die van mijn collega’s.
Natuurlijk ging dit zelden tot nooit zonder spanningen. Zo waren er vrijwel altijd problemen met klanten, engineering en productie. Ook overwerk was geen uitzondering, Zeker niet tegen het einde. En dan was er natuurlijk het constante herplannen van de projecten om ze op het juiste spoor te houden. Maar is dat niet wat projectmanagement tot projectmanagement maakt?
Tenminste, dat dacht ik, totdat ik een masterclass bijwoonde over productiebeheersing in Engineer to Order omgevingen.
We zijn begonnen met het spelen van een eenvoudige multi-project simulatie met behulp van schalen, borden, kralen en lepels. Daarbij werden we verdeeld in teams en getraind op onze individuele taken.
De “projecten” leken eenvoudig genoeg. Met behulp van lepels verplaatsten we de kralen uit de schaal naar borden, om ze eerst een paar keer om te draaien en vervolgens terug te lepelen in de oorspronkelijke schaal. We hadden twee schalen (of projecten) uit te voeren in vijf minuten. Het tweede project zou worden gestart 30 seconden na de start van de eerste. Daarbij werd het belangrijk geacht om voortgang op beide projecten te laten zien.
Mijn team gebruikte een eenvoudige regel om dat te realiseren: als één persoon meerdere taken had moest hij of zij elke derde actie omschakelen naar een volgende taak. Zo moest ik, als verantwoordelijke voor het draaien van kralen, na elke derde kraal van een project te hebben omgedraaid, overschakelen naar kralen van het andere project. Op deze manier kon ik voortgang op beide projecten tonen.
We leverden laat, veel te laat: twee minuten en vijfenveertig seconden na de toegezegde termijn. En we waren niet de enigen. Alle andere teams leverden te laat. Wat was er gebeurd?
We kwamen met allerlei ideeën voor verbetering met inbegrip van:
Deze observaties kwamen ons bekend voor. Hoeveel van ons waren niet actief betrokken bij het verhogen van de ramingen en het toevoegen van meer mensen? De sessieleiders hadden onze aandacht.
Ze vroegen ons om het spel opnieuw uit te voeren met slechts twee wijzigingen.
Enigszins sceptisch speelden we het spel opnieuw. De resultaten waren echter opzienbarend. Ons team eindigde beide projecten in drie minuten en vijfendertig seconden. Ruim voor de toegezegde leverdatum.
De meest bijzondere gewaarwording was de verandering in de workflow van het hele team. Er was een dramatische afvlakking. Natuurlijk, een paar mensen waren nog steeds erg druk, maar degenen die in de eerste run voor langere tijd zonder werk zaten hadden in de tweede run een regelmatig werkaanbod. Het gevoel continue te worden opgejaagd was verdwenen en we waren opgetogen de toegezegde levertijd te hebben verslagen.
Maar hoe kunnen twee eenvoudige veranderingen zo’n impact hebben?
De sleutel ligt in hoe weinig we begrijpen van de effecten van multi-tasking. Allereerst geldt dat, vanuit het gezichtspunt van het project, multi-tasking de tijd om de taak te voltooien vermenigvuldigt. Dit effect kan worden aangetoond met een eenvoudige schets (zie figuur). Met multi-tasking wordt oplevering van project rood uitgesteld zonder winst voor project blauw … niemand wint!
Daarnaast denk ik dat we de vertraging die multi-tasking veroorzaakt in ons werk vaak niet herkennen. In tegenstelling tot productie, zien we in engineering en inkoop niet het fysieke bewijs van hoe lang het iemand kost om volledig over te schakelen van de ene taak naar de andere. Hoe ingewikkelder de taak, hoe langer het duurt om weer volledig om te schakelen. Toch wordt de tijd die nodig is om volledig om te schakelen taken zelden gezien als een tijdverkwister.
De derde les die ik van het kralenspel heb geleerd is dat het gedoseerd starten van werk kan helpen bij het minimaliseren van task switching. Alleen maar omdat een project is klaar om te beginnen betekent nog niet dat het zou moeten.
Aan het einde van de sessie was één ding helder: ik veroorzaak de problemen vooral zelf. Om een goede manager te zijn zorgde ik ervoor dat al mijn mensen hun handen vol hadden. Op deze manier konden ze zichzelf organiseren en zouden ze niet zonder werk komen te zitten. Wekelijks hadden we status updates en als dingen niet verliepen zoals gepland en er waren vragen over de prioriteiten, stelde ik voor om hun tijd te verdelen over de verschillende prioriteiten. Om iedereen bezig te houden startte ik vast nieuwe projecten op.
Ik was zelf dus de hoofdoorzaak van multi-tasking door mijn team!
De oplossing is niet zo makkelijk omdat het vereist een nieuwe waarheid te accepteren. Hier zijn de belangrijkste stappen die ik zelf moest doormaken.
Dat allemaal dankzij een eenvoudig kralenspel.