Stop met elkaar de schuld te geven—gebruik een RACI-schema (met Suze Haworth)

Lees het transcript:

We proberen onze podcasts uit te schrijven met behulp van een softwareprogramma. Vergeef ons eventuele typefouten, want de bot heeft niet altijd 100% gelijk.

Ben Aston:

Een van de lastigste dingen aan het managen van projecten is misschien wel dat we moeten samenwerken met … mensen. En mensen zijn ongelooflijk wisselvallig. We zijn inconsistent, egoïstisch, onbetrouwbaar en ongelooflijk wispelturig — en ik heb het alleen over mezelf. Dus ik vraag me af of jouw projecten lijken op die van mij. Wanneer het misgaat — en dat gebeurt natuurlijk op enig moment — kan het snel veranderen in een verschrikkelijk vingerwijsspel, waarbij iedereen lijkt te beschuldigen dat alle anderen hun werk niet goed doen. Dus hoe kunnen we in hemelsnaam een project managen wanneer we daar allemaal rekening mee moeten houden? Dat ontdek je vandaag.

Bedankt dat je luistert. Ik ben Ben Aston en dit is de podcast van The Digital Project Manager. Deze podcast wordt mogelijk gemaakt door Clarizen, de leider op het gebied van software voor bedrijfsbreed project- en portfoliomanagement. Ga naar Clarizen.com voor meer informatie. Vandaag praat ik met Suze Haworth, een van onze vaste DPM-experts bij The Digital Project Manager. Suze, ontzettend bedankt dat je bij de show bent.

Suze Haworth:

Bedankt, Ben. Bedankt dat ik hier mag zijn.

Ben Aston:

Laat me Suze goed introduceren, want ze is nieuw. Dit is volgens mij onze allereerste gezamenlijke podcast.

Suze Haworth:

Ja.

Ben Aston:

Suze is een freelance digital project director in Londen en heeft enorm veel ervaring. Ze werkt al meer dan dertien jaar in de branche, begon net als ik in accountmanagement en stapte daarna over naar projectmanagement. Maar in plaats van alleen je biografie voor te lezen, Suze: kun je ons wat vertellen over het soort projecten waar je momenteel aan werkt?

Suze Haworth:

Op dit moment? Vorig jaar ben ik eigenlijk net als freelancer begonnen. Zoals je zei, heb ik een aantal jaren bij verschillende bureaus gewerkt, maar vorig jaar ben ik zelfstandig geworden. Momenteel werk ik bij een bureau in Londen en doe ik twee grote projecten: een ontwerpsysteem voor een vrij groot retailmerk en een programma van werkzaamheden voor een ander retailmerk. Het is allemaal behoorlijk interessant werk.

Ben Aston:

Is retail dus jouw specialiteit?

Suze Haworth:

Het is eigenlijk heel uiteenlopend. Ik doe veel retail, maar ook een omroep, een goed doel en allerlei andere dingen. Op dit moment ligt de nadruk bij de accounts die ik noemde wel sterk op retail, dus dat zou je kunnen zeggen.

Ben Aston:

Leuk. Wat vind je in je rol als freelancer moeilijker? Met welke grotere uitdagingen heb je momenteel te maken?

Suze Haworth:

Ik denk dat de grootste uitdaging — en dat is volgens mij altijd zo voor projectmanagers, als ik uit ervaring spreek — is dat je zo veel verschillende dingen moet managen en uitvoeren waarvoor je verantwoordelijk bent. Je probeert niet alleen een project succesvol op te leveren, maar managet ook planningen, budgetten, teamresultaten, de teamleden zelf en allerlei teamproblemen. En natuurlijk heb je ook contact met de klant. Het is dus erg moeilijk om binnen de beschikbare tijd met zo veel dingen tegelijk om te gaan. Vaak voelt het alsof het een voortdurende strijd is om alles in één dag te passen.

Ben Aston:

Ja. Vind je dat moeilijker omdat je eerst in vaste dienst was en nu in een soort contractrol werkt? Ervaar je dat anders?

Suze Haworth:

Ja, ik denk het wel. Als freelancer ben je in zekere zin meer verantwoordelijk voor je eigen tijd, bijvoorbeeld voor de uren die je aan het bureau in rekening brengt. Je moet voorkomen dat je het gevoel krijgt dat je geen nee kunt zeggen. Ik heb geleerd dat beter te doen: als er te veel op je bord ligt, kun je maar een beperkte hoeveelheid werk doen en je moet dat goed doen. Het is dus beter om je grenzen te kennen en nee te kunnen zeggen dan overal ja op te zeggen.

Ben Aston:

Toen ik contractant was, vond ik dat ook. Er is iets prettigs aan contractwerk, omdat je niet echt bezig bent met promotie. Natuurlijk wil je je contract behouden en met hen blijven werken, maar je probeert mensen niet op dezelfde manier te imponeren als wanneer je een vaste medewerker bent en denkt: “Ik kan maar beter ja zeggen, anders ziet dit er slecht uit.”

Suze Haworth:

Ja, precies. Je wilt natuurlijk nog steeds een goede indruk maken. De branche is klein, dus iedereen kent elkaar. Maar het is fijn dat je aan het einde van de dag wat meer afstand kunt nemen en kunt zeggen: “Oké, mijn uren zitten erop.” Soms net iets meer dan wanneer je in vaste dienst bent.

Ben Aston:

Bij hoeveel verschillende organisaties heb je gewerkt sinds je contracten doet?

Suze Haworth:

Tot nu toe maar een paar, omdat ik het nog niet zo lang doe. Dat is eigenlijk goed geweest, want ik heb inmiddels wat tijd opgebouwd bij het bureau waar ik nu werk. Ik ken de mensen goed en begrijp de klanten beter, omdat je wat langer aan projecten en accounts werkt.

Ben Aston:

Werk je op locatie of voornamelijk op afstand?

Suze Haworth:

Op locatie. Ik vertel iedereen die ik erover spreek eigenlijk graag over de voordelen van werken op afstand, omdat ik denk dat het belangrijk is en voor veel mensen productiever kan zijn. Maar veel bureaus — vooral in Londen, waar ik veel heb gewerkt — werken voornamelijk op locatie.

Ben Aston:

Interessant. Naast je freelance- en contractwerk schrijf je ook. Je hebt artikelen geschreven voor DPM en je bent later dit jaar ook aanwezig op de DPM Summit. Kun je daar iets over vertellen?

Suze Haworth:

Ja. Daar kijk ik echt naar uit. Vorig jaar sprak ik op de DPM Summit in Las Vegas en dit jaar geef ik een workshop. Het onderwerp is interessant, omdat wij als projectmanagers volgens mij allemaal nogal geobsedeerd zijn door methodologieën, vooral Agile-methodologieën. In de workshop praat ik daarom over het combineren van benaderingen, specifiek over iets wat ik momenteel implementeer in een programma van werkzaamheden: de Dual-Track-benadering. Daarbij gebruik je bepaalde aspecten van Agile, maar combineer je die op een andere manier. Ik bespreek Kanban, Lean en hoe je verschillende benaderingen voor je projecten kunt combineren — dus niet noodzakelijk puur Agile of één enkele methodologie, maar hoe je bestaande methodologieën kunt aanpassen.

Ben Aston:

Dat is goed. Suze is een van onze DPM-experts en verschijnt ook in onze cursus Digitaal Projectmanagement beheersen. Als je niet weet wat ik bedoel—

Suze Haworth:

Jawel, dat weet ik.

Ben Aston:

Die vindt deze vrijdag plaats en het is Suzеs eerste optreden. Een van de dingen die we in de cursus bespreken, is dat je niet te veel moet blijven hangen in de naam van de methodologie of in de vraag—

Suze Haworth:

Ja, precies.

Ben Aston:

Het gaat uiteindelijk om het opleveren van werk en het vinden van betere manieren om dat te doen op een manier die werkt voor het team, het project en de klant. Je moet pragmatisch zijn in plaats van dogmatisch: “Dit is geen Scrum, dus we moeten het op deze Scrum-manier doen.” Dat doet er eerlijk gezegd niet echt toe. We moeten het project gewoon opleveren.

Suze Haworth:

Precies. Ik heb altijd gemerkt dat mensen zo gefocust kunnen zijn op het proces en op het volgen van een bepaald proces, terwijl je eigenlijk naar je projecten of het product dat je maakt moet kijken en moet denken: “Wat werkt hiervoor?” Dat verschilt enorm per project, dus je moet aanpassen of combineren.

Ben Aston:

Helemaal. Sommige mensen kunnen nogal neerbuigend doen over het afzwakken van de zuiverheid van methodologieën, maar ik heb nooit gemerkt dat die in hun pure vorm goed werken.

Suze Haworth:

Nee, precies. Er bestaat veel snobisme rond favoriete benaderingen, maar ik sta open voor het gebruik ervan. Vooral in de bureaumanagementwereld moet je volgens mij meestal een gecombineerd proces gebruiken in plaats van iets zuivers, simpelweg vanwege de situaties waarin je werkt.

Ben Aston:

Zeker. Afgezien van je conferentietour, het schrijven van artikelen en je werk: heb je jezelf dit jaar nog doelen gesteld waaraan je werkt of waarin je beter probeert te worden?

Suze Haworth:

Dat is een moeilijke vraag. Ik ben momenteel zo gericht op het heden — op wat ik op en buiten mijn werk doe — dat het soms lastig is om aan de lange termijn te denken. Een belangrijk punt waar ik het eerder over had, is leren nee zeggen. Ik probeer veel beter te worden in delegeren en in het loslaten van verantwoordelijkheid. Dat vind ik altijd lastig. Als projectmanager word je een beetje een controlefreak, dus dat is zeker een doel voor de lange termijn.

Ben Aston:

Delegeren is moeilijk. Vooral wanneer je contractant bent en niet zeker weet of degene aan wie je delegeert je serieus zal nemen omdat je slechts contractant bent. Bovendien heb je nog geen geschiedenis met die persoon, dus weet je niet of diegene daadwerkelijk kan doen wat je probeert te delegeren.

Suze Haworth:

Precies.

Ben Aston:

Laten we het even over hulpmiddelen hebben. Omdat je op verschillende plekken hebt gewerkt, kom je natuurlijk met verschillende hulpmiddelen in aanraking. Heb je onlangs iets gevonden dat je leven gemakkelijker maakt of waarvan je denkt: “Iedereen moet dit kennen”?

Suze Haworth:

Eerlijk gezegd krijg je als freelancer en door de jaren heen bij allerlei bureaus met zo veel verschillende hulpmiddelen te maken dat je meestal gewoon moet gebruiken wat het bedrijf gebruikt. Ik zou dus nooit zeggen dat ik het ideale hulpmiddel heb gevonden dat alles doet wat ik wil en geen problemen heeft waar je mee moet omgaan. Ik gebruik hulpmiddelen voor capaciteitsplanning, urenregistratie en allerlei andere zaken, en bij elk hulpmiddel zijn er goede en slechte kanten. Het enige hulpmiddel — als je het zo kunt noemen — waar ik echt van houd, zijn Google-spreadsheets. Je kunt ze volgens mij voor alles of in elk geval voor heel veel verschillende dingen gebruiken.

Ben Aston:

Heb je Monday.com geprobeerd?

Suze Haworth:

Nee, eigenlijk niet.

Ben Aston:

Voor iemand die graag dingen met spreadsheets beheert, denk ik dat Monday misschien precies iets voor jou is—

Suze Haworth:

Wat ben je toch een nerd.

Ben Aston:

Het mooie van spreadsheets is dat ze gratis zijn — of in elk geval Google Spreadsheets — en ongelooflijk flexibel kunnen zijn. Monday voegt volgens mij een extra automatiseringslaag toe, plus meer mogelijkheden voor filteren en beheren. Je zou het moeten bekijken. Het zijn eigenlijk spreadsheets met steroïden.

Suze Haworth:

Dan ga ik zeker kijken. Dat klinkt echt als iets voor mij.

Ben Aston:

Laten we het hebben over je artikel. Het is alweer een tijdje geleden dat je het schreef, maar aansluitend bij waar we begonnen: hoe gaan we om met mensen die een project lijken te willen overnemen of juist helemaal geen verantwoordelijkheid lijken te willen nemen? Je artikel gaat over hoe we daarvoor een RACI-schema gebruiken. Voor wie het artikel nog niet heeft gelezen: vertel eens over RACI-schema’s. Waar staat “RACI” voor?

Suze Haworth:

RACI staat voor verantwoordelijk, eindverantwoordelijk, geraadpleegd en geïnformeerd. Het is in feite een eenvoudig schema waarin je taken of op te leveren resultaten van een project afzet tegen de belanghebbenden of interne teamleden van je project. Vervolgens wijs je aan elke rol en taak een van de vier letters toe. Iemand is verantwoordelijk, iemand is eindverantwoordelijk, iemand wordt geraadpleegd en iemand wordt geïnformeerd. Het is een goede manier om verantwoordelijkheid voor elke taak of elk op te leveren resultaat toe te wijzen, ervoor te zorgen dat niet te veel mensen bij elke beslissing betrokken zijn en duidelijk te maken wie gedurende het project aan wat werkt.

Ben Aston:

Een van de grootste bronnen van verwarring lijkt niet te gaan over wie geïnformeerd of geraadpleegd moet worden. Dat is meestal vrij duidelijk. De verwarring zit vooral in het verschil tussen verantwoordelijk en eindverantwoordelijk. Hoe pak je dat aan? En hoe ga je om met mensen die wel verantwoordelijk willen zijn maar niet eindverantwoordelijk?

Suze Haworth:

Dat is volgens mij inderdaad het lastigste onderdeel van RACI, en ik heb daar zelf in het verleden vaak mee geworsteld. Daarom kan een RACI-schema zo’n ingewikkeld geheel worden: je besteedt veel tijd aan de vraag wat iets precies betekent en wat het betekent voor de persoon aan wie je die rol toewijst. Heel eenvoudig gezegd is de verantwoordelijke de persoon die de taak daadwerkelijk uitvoert, bijvoorbeeld een resultaat creëert of het proces begeleidt. De eindverantwoordelijke is degene die verantwoordelijk is voor het goedkeuren van de taak en er toezicht op houdt, maar de taak niet zelf uitvoert.
Een ander probleem is dat je de neiging kunt hebben om de eindverantwoordelijkheid bij de projectmanager of product owner te leggen, omdat die het project leidt en centraal staat. Je moet de projectmanager echter los zien van verantwoordelijkheid voor alles en nadenken over wie binnen die taak of dat resultaat daadwerkelijk hoger in de hiërarchie staat. Als het om ontwerp gaat, is dat dan de creatief directeur aan jouw kant of aan de kant van de klant? Probeer dus te voorkomen dat je de rol van eindverantwoordelijke steeds bij de projectmanager of product owner neerlegt.

Ben Aston:

Dat is belangrijk. De fout die we gemakkelijk maken, is iedereen verantwoordelijk en eindverantwoordelijk maken. Niet alleen de projectmanager, maar iedereen: iedereen moet hiervoor verantwoordelijk zijn. We hebben collectieve verantwoordelijkheid nodig.

Suze Haworth:

Ja, precies. Het is moeilijk, want je denkt: de teamleden gaan dit ook doen, dus misschien zijn er vijf mensen die dezelfde taak uitvoeren en zijn ze allemaal verantwoordelijk. Maar je moet het stroomlijnen en beperken. Als je rollen over iedereen verspreidt, bereik je nooit wat RACI juist zo goed doet: duidelijk vastleggen wie het aanspreekpunt is en wie goedkeuring geeft. Daarvoor gebruik je RACI.

Ben Aston:

Wie het werk daadwerkelijk uitvoert, is meestal niet zo ingewikkeld. Het verschil tussen geraadpleegd en geïnformeerd kan ook lastig zijn. Volgens mij verwarren mensen vooral eindverantwoordelijkheid en geraadpleegd worden. We willen eigenlijk één persoon die eindverantwoordelijk is en het laatste woord heeft over de vraag of iets aan de norm voldoet. Dat is bijna kwaliteitscontrole. We kunnen meer mensen raadplegen en nog meer mensen informeren. Zij krijgen alleen een bericht met: “Dit is wat we hebben gemaakt.”
De geraadpleegden kunnen het project echter ontsporen, omdat ze een stem hebben. Ze zijn niet noodzakelijk verantwoordelijk voor tijdige of correcte oplevering, maar ze hebben wel inspraak. De gevoeligheid zit dus vooral tussen eindverantwoordelijkheid en raadpleging, en in het machtsspel tussen mensen die hun positie, autoriteit of mening willen laten gelden maar niet eindverantwoordelijk zijn voor een goede oplevering.

Suze Haworth:

De geraadpleegden willen inderdaad inspraak omdat je hun vertelt dat ze geraadpleegd worden. Daarom is de rol van eindverantwoordelijke zo belangrijk. Die persoon moet eigenaar zijn van het resultaat of de taak en ervoor zorgen dat de geraadpleegden input leveren zonder het hele project te laten ontsporen met eindeloze feedback.

Ben Aston:

Wees eerlijk: gebruik je een RACI-schema voor elk project? En hoe houd je het licht? Als je heel gedetailleerd wordt, kan het enorm lang duren om het te maken. Hoe voorkom je dat het een nieuwe werkverdelingsstructuur wordt met namen ernaast?

Suze Haworth:

Ik wil absoluut niet te veel documentatie maken alleen omwille van de documentatie. Als je een RACI maakt, moet je het nuttig maken en ook echt gebruiken. Je maakt het dus niet aan het begin van een project en laat het vervolgens ergens op een server verstoffen. Je moet ernaar verwijzen en het gebruiken wanneer je je op te leveren resultaten doorneemt. Aan het einde van het project bekijk je tijdens de evaluatie hoe je het hebt gebruikt: was het succesvol en klopte wat je aanvankelijk had vastgelegd? Alleen door het document te gebruiken, wordt het nuttig.

Ben Aston:

Kun je een situatie beschrijven waarin je de RACI erbij pakt? Gebruik je het tijdens statusvergaderingen, wanneer je zegt dat we de komende week dit en dat doen, en verwijzen we dan naar het schema om te bepalen wie eindverantwoordelijk en wie verantwoordelijk is en wie we onderweg raadplegen en informeren?

Suze Haworth:

Ik gebruik het niet per se tijdens statusvergaderingen. Het laat natuurlijk zien naar wie je moet gaan, wie je moet betrekken, met wie je resultaten moet delen en aan wie je taken moet toewijzen. Maar voor mij is het vooral een intern naslagpunt. Je kunt controleren wie betrokken is bij een resultaat, naar wie je het voor feedback moet sturen en wie er na oplevering over geïnformeerd moet worden. Het is dus vooral een intern hulpmiddel. Als zaken anders lopen, moet je dat natuurlijk benoemen.
Als je bijvoorbeeld de rol van geraadpleegde aan iemand hebt toegewezen en opeens iedereen aan klantzijde of alle belanghebbenden betrokken willen raken, kun je naar je directe klantcontact gaan en zeggen: “Dit hebben we aan het begin samen opgesteld. We moeten dit volgen, omdat het bedoeld is om efficiëntie te creëren, de communicatie te stroomlijnen en geen extra lagen en tijd aan het project toe te voegen.”

Ben Aston:

Begrijp ik goed dat jouw RACI’s een gecombineerd schema zijn voor bureau en klant, of gebruik je twee aparte schema’s?

Suze Haworth:

Ik heb verschillende benaderingen gebruikt. Het hangt echt van het project af. Als je twee grote teams hebt — jouw team en het klantteam — kan het beter zijn om twee schema’s te maken. Recent heb ik vooral een schema voor de klantzijde gemaakt wanneer daar veel belanghebbenden betrokken waren. Dan weet je wie je aan hun kant en wanneer moet betrekken. Ons bureau had een wat kleiner, gestroomlijnder team, dus dat heb ik als één geheel opgenomen. Voor bepaalde taken namen wij de verantwoordelijkheid, terwijl veel verantwoordelijkheid ook aan hun kant lag. Ik maakte daarom een groter schema voor de klantzijde. Het hangt dus van het project af.
Het belangrijkste is dat je de RACI maakt om iets nuttigs te bieden. Een project heeft er misschien geen nodig. Bij een klein, slank project met enkele teamleden en één klant is het waarschijnlijk zinloos. Beoordeel dus de behoefte en wat je ermee probeert te bereiken. Als er veel belanghebbenden zijn en je duidelijke verwachtingen wilt scheppen over wie betrokken is, maak je er een.

Ben Aston:

RACI helpt voorkomen dat zaken tussen wal en schip vallen. Aan het einde van een project kan iemand dan niet zeggen: “Waarom kreeg ik geen kans om hier feedback op te geven?” Of: “Ik dacht dat de ontwerpers de wireframes zouden annoteren.”
In mijn ervaring hoeven we de klant niet altijd volledig inzicht te geven in alles wat intern gebeurt, wie wat doet, wie verantwoordelijk of eindverantwoordelijk is en wie wordt geraadpleegd. Dat is meestal niet nodig en kan verwarring veroorzaken. Aan klantzijde is het wel nuttig, vooral bij een groot team of een politieke organisatie die moeite heeft met beslissingen. Zoek degene die eindverantwoordelijk is en vraag: “We hadden aan het begin afgesproken dat jij hiervoor eindverantwoordelijk was. Geldt dat nog? Zo niet, dan moeten we ons proces aanpassen, de planning verlengen of waarschijnlijk het budget verhogen.”

Suze Haworth:

Daarom is het zo belangrijk om klanten of interne teamleden te betrekken bij het maken van het schema, vooral de mensen aan wie je verantwoordelijkheid, eindverantwoordelijkheid of de rol van geraadpleegde toewijst. Je kunt het niet zomaar alleen maken en ter goedkeuring opsturen. Mensen denken er dan misschien niet goed over na en zeggen alleen: “Ja, prima, laten we doorgaan.” Als je hen vanaf het begin bij die beslissingen betrekt, leg je de afspraken vast en weet iedereen wie wat doet.

Ben Aston:

Wanneer werkt RACI niet meer? Wanneer valt het uit elkaar? Je hebt aan het begin documentatie gemaakt en geprobeerd alles af te spreken. Wanneer begint het in jouw ervaring mis te gaan? Waar moeten mensen op letten?

Suze Haworth:

Drie dingen die ik al heb genoemd zijn belangrijk. Ten eerste moet je vooraf overeenstemming krijgen. Als je het schema alleen maakt, verantwoordelijkheid aan iemand toewijst zonder dat die persoon daarvan weet of ermee instemt, of aannames doet over de klant, werkt het niet. Je hebt ieders steun nodig, vooral van de mensen die eindverantwoordelijk of verantwoordelijk worden.
Daarnaast moet je het gebruiken. Verwijs er tijdens het project naar, controleer of alles op schema ligt en of de juiste mensen betrokken zijn. Als je het laat liggen, is het een verspilling van tijd en slechts een vakje dat je aan het begin hebt aangevinkt. Evalueer het na het project: was het nuttig, klopte het en waren de rollen goed in kaart gebracht? Dat helpt bij toekomstige RACI’s.

Ben Aston:

Wat doe je wanneer het toch uit elkaar valt? Er ontstaat vingerwijzen, zaken vallen tussen de kieren en mensen raken overstuur. Hoe trek je de zaken weer strak?

Suze Haworth:

Je kunt het schema misschien voor iemands neus houden en zeggen: “Dit heb je aan het begin afgesproken,” maar zo moet je het niet gebruiken. Zeg liever: “Hierover waren we het eens. Zo probeerden we vooraf efficiëntie te creëren en verwachtingen vast te leggen. Sommige mensen houden zich er nu niet aan, waardoor extra tijd en moeite aan het project wordt toegevoegd.” Bespreek de gevolgen met de mensen die het project laten ontsporen of met degenen die hen aansturen. Leg uit waarom je het schema hebt gemaakt, waarom bepaalde mensen betrokken of verantwoordelijk zijn en wat er gebeurt als je op deze manier doorgaat.

Ben Aston:

Mensen herinneren aan de reden waarom zaken aan het begin zo zijn vastgesteld, helpt hen soms weer binnen hun rol te komen. Er is een reden waarom ik niet eindverantwoordelijk ben: ik heb misschien niet de expertise om er iets zinnigs over te zeggen.

Suze Haworth:

Dat brengt ons terug bij het maken van een echt nuttig document. Je hebt er een reden voor: je wilt efficiëntie creëren binnen een beperkte tijd of een beperkt budget. Zonder duidelijke reden is het document vrijwel waardeloos. Zorg er dus voor dat je duidelijke voordelen ziet en daadwerkelijk efficiëntie creëert.

Ben Aston:

Als je een RACI-sjabloon wilt downloaden, heeft Suze er een voor ons gemaakt. Ze heeft ook een nuttig voorbeeld gemaakt met “The Lord of the Rings” om te laten zien hoe dit op een project kan worden toegepast. Toen we een e-mail verstuurden met de mededeling dat Suze dit artikel had geschreven en dat er een voorbeeld gebaseerd op “The Lord of the Rings” bij zat, stuurde iemand mij een bericht: “Ik kan niet geloven dat jullie ieders tijd hiermee verspillen.” Een dag later schreef die persoon: “Ik heb het artikel toch gelezen en het was geweldig. Ik houd gewoon niet van ‘The Lord of the Rings’.”

Suze Haworth:

Ik weet het. Het is nogal specifiek. Toen ik die matrix voor “The Lord of the Rings” maakte, dacht ik: “Ik weet zeker dat ik sommige dingen verkeerd heb.” In zekere zin deed ik dus precies wat ik zeg dat je niet moet doen. Maar het helpt om het op een herkenbare manier tot leven te brengen.

Ben Aston:

Het goede eraan was dat sommige mensen een beeld hebben van de opdracht om de Ring te bemachtigen. Het is natuurlijk een beetje polariserend, maar ik vind het geweldig. Suze, ontzettend bedankt dat je bij ons was.

Suze Haworth:

Dank je.

Ben Aston:

Als je aan het gesprek wilt bijdragen, laat dan een reactie achter bij het artikel of ga naar het gedeelte Bronnen van TheDigitalProjectManager.com om lid te worden van ons Slack-team. Daar vind je allerlei interessante gesprekken. Als je meer van Suze wilt horen, ga dan naar het gedeelte Training van TheDigitalProjectManager.com en schrijf je in voor de volgende cursus Digitaal Projectmanagement beheersen, waarin Suze te zien zal zijn. Tot de volgende keer: bedankt voor het luisteren.