ORDINA BLOGT

Van multitasking naar high performance - effectiever werken in projecten (1)

Veel organisaties worstelen met projecten. Er komt simpelweg te weinig uit. Projecten lopen uit.

  • Anko Tijman
  • 29 maart 2013

Mensen worden op meerdere projecten gezet  - die vervolgens nog meer uitlopen. Projectleiders moeten vechten om resources en werken met halve projectteams. Er is een paradigmaverandering voor nodig om dit probleem op te lossen: we moeten stoppen met het multitasken van onze mensen. Het gedachtegoed van de Theory of Constraints1 helpt ons daarbij. Lees hier de ervaringen van Kees en Jan… (gastblog door Pepijn van de Vorst)

Dependant-team

“Dat kunnen ze niet maken, wéér een project erbij!”. Kees briest verontwaardigd. “Maar joh, zo gaat het altijd bij projecten, waar maak je je druk om?” Johan is een ervaren projectmanager en kent het klappen van de zweep. “Nou, als ze me een burnout in willen jagen, moeten ze vooral zo doorgaan! Ik wou dat ik mezelf kon klonen. Ze kunnen toch niet van me verwachten dat ik drie projecten mijn volle aandacht kan geven. Dit is vrágen om problemen”

Voor veel werknemers is dit herkenbaar. Softwareontwikkeling vindt vrijwel altijd plaats in projecten. En er zijn maar weinig organisaties die slechts één project tegelijkertijd uitvoeren. Veel projecten tegelijkertijd is eerder regel dan uitzondering. En omdat ICT’ers dure arbeidskrachten zijn, zou het zonde zijn als ze even niets te doen hebben. Toch? Dus zetten we veel mensen in op meerdere projecten zodat iedere resource optimaal benut wordt. Logisch toch?!

“Kijk, ik zal eens even laten zien dat het geen enkele zin heeft om meerdere projecten tegelijkertijd met dezelfde mensen te doen”, zegt Kees vastberaden. Hij pakt een servet en een pen en maakt een tekening.

“Als je afwisselend aan taak A en taak B werkt, is taak A veel later klaar, en taak B niét eerder. En als je rekening houdt met het effect dat je steeds als je van taak wisselt er weer even ‘in’ moet komen, wordt het nog veel erger.”

 “Hmmmm…..” Johan heeft een diepe frons in zijn voorhoofd. Zijn goedlachse gezicht is opeens één en al concentratie. “Ik begrijp dat dat heen en weer gejojo irritant is voor de mensen die het uitvoerende werk doen. Voor mij als projectmanager is het ook lastig. Ik ga continu met andere projecten de strijd om de resources aan, omdat ik anders mijn deadline niet haal. Dat is frustrerend.”
 
“En wat dacht je van de kans op fouten die toeneemt doordat je met meerdere dingen tegelijkertijd bezig bent?” vult Kees aan. “Wat ook nog eens een heleboel energie kost en stress oplevert. Ik ben er van overtuigd dat het werken aan meerdere projecten tegelijkertijd alle projecten schade toebrengt”. “Maar ja”, zegt Johan uit het veld geslagen, “het gaat niet voor niets op de manier zoals het nu gaat. Er zullen de nodige pogingen zijn gedaan om het anders aan te pakken, maar dat is  allemaal op niets uitgelopen”.

 
Multitasking is gebruikelijk bij softwareontwikkeling. Maar het leidt tot ongewenste effecten:

  • Projecten worden later afgerond dan wanneer ze één voor één worden uitgevoerd omdat task switching veel tijd kost en niet bijdraagt aan eerder afronden van de  projecten2
  • Het vergt extra energie en levert stress op
  • Projectleiders moeten continu vechten om resources, wat leidt tot onderlinge spanningen
  • Met meerdere dingen tegelijkertijd bezig zijn, betekent een groter risico op fouten
  • Als je even niet verder kunt met taak A, is de verleiding groot verder te gaan met taak B, waardoor het probleem waardoor je niet verder kunt met taak A blijft liggen.
  • Als werk voor project A moeizaam verloopt, is de verleiding groot te gaan werken aan project B. We hebben als mens nu eenmaal de neiging dingen af te willen maken.

De enige oplossing om de ongewenste effecten van multitasken tegen te gaan, is niét te multitasken.

  • Pak één taak op en rond deze af voordat je aan een volgende taak begint.Als je niet verder kunt, zorg je dat datgene dat je blokkeert, wordt opgelost
  • Maak met een bepaalde groep resources één project af, voordat je een volgende project start.

 
Maar dat is gemakkelijker gezegd dan gedaan!
 
 “Ik weet het niet”, zegt Johan. “We werken al jaren zo, waarom zouden we dat nu ineens gaan veranderen? Waarom zou dat nu ineens werken? Het klinkt te mooi om waar te zijn. Als het zo eenvoudig was, zou iedereen al lang op die manier werken.”
 
 “Ik ken ze wel, hoor”. Bij Kees is opeens een lichtje gaan branden. “Het zijn vaak de niet zo populaire medewerkers, die door anderen en vooral door projectmanagers als lastig worden gezien. Ze staan erop de taak waaraan ze werken af te maken en gaan daarná pas met een volgende taak aan de slag. En warempel, die lui zijn vaak akelig productief.”
 
 “Nou je het zegt!” Johan bedenkt zich dat hij twee projectmanagers kent, die alleen een klus aannemen als ze van tevoren de garantie krijgen dat de mensen dedicated op hún project worden ingezet. Ze bewegen hemel en aarde om dat voor elkaar te krijgen en gaan door het vuur voor hun mensen. En ze boeken vaak spectaculaire resultaten.”
 
Maar hoe creëer je een (project)omgeving waarin “bad multitasking” wordt uitgebannen? Daarover meer in de volgende blog.

 
1)  voor meer uitleg over TOC en CCPM, zie onder andere http://nl.wikipedia.org/wiki/Theory_of_constraints en
http://www.ikdoeprojecten.nl/group/criticalchainprojectmanagement 

2) voor meer informatie over de effecten van multitasken en task switching, zie onder andere http://psyweb.psy.ox.ac.uk/acc/papers/YeungMonsell_2003b.pdf en http://www.apa.org/research/action/multitask.aspx 

Pepijn van de Vorst is testconsultant bij Ordina en enthousiast aanhanger van het concept Theory of Constraints, waarmee hij veel voorkomende testproblemen analyseert en oplost.

Over de auteur:

Anko Tijman

Anko Tijman is Thought Leader Agile bij Ordina. Vanuit die rol neemt hij het voortouw in inhoudelijke discussies over Agile, DevOps en Lean werken. Hij is sinds 2004 in dienst van Ordina. Hij is onder meer betrokken bij AgileOverheid, is Computable Expert en is trainer van de Agile-managementtraining Management3.0.