Sluipende scope-uitbreiding beheersen (met Suze Haworth)

Lees het transcript:

We proberen onze podcasts te transcriberen met behulp van een softwareprogramma. Vergeef ons eventuele typefouten, want de bot is niet altijd 100% accuraat.

Ben Aston:

Welkom bij de DPM-podcast, waarin we verder gaan dan theorie en deskundig advies geven voor het leiden van betere digitale projecten. Bedankt dat je luistert. Ik ben Ben Aston, oprichter van The Digital Project Manager. Als er één ding is dat bijna elk project ontspoort, dan is het sluipende scope-uitbreiding. We weten allemaal dat het slecht is. We weten allemaal dat we het willen voorkomen. Maar hoe herken je het in al zijn verschillende vormen? Waardoor ontstaat het? Wiens schuld is het? En het allerbelangrijkste: hoe ga je er daadwerkelijk mee om? Dat wordt allemaal duidelijk in de podcast van vandaag, waarin we praten over het beheersen van sluipende uitbreidingen van de projectscope.

Deze podcast wordt mogelijk gemaakt door Clarizen, de leider op het gebied van software voor bedrijfsprojecten en projectmanagement.

Lees meer op clarizen.com

Vandaag ben ik samen met Suze Hayworth. Suze is een van onze vaste DPM-experts bij The Digital Project Manager. Ze werkt als zelfstandig senior digital projectmanager in Londen, in het Verenigd Koninkrijk. Ze heeft meer dan 10 jaar ervaring bij bureaus en heeft veel ervaring met sluipende scope-uitbreiding. Ze is dus een uitstekend persoon om hier vandaag over te spreken. Suze, welkom.

Suze Hayworth:

Hoi Ben.

Ben Aston:

Suze, we waren voor de opname al even aan het praten. Kun je ons iets vertellen over het soort projecten waaraan je momenteel werkt en over enkele uitdagingen waar je mee te maken hebt?

Suze Hayworth:

Ja. Ik werk momenteel als freelancer bij een bureau in Londen. Ik ben verdeeld over een rol als senior projectmanager en projectdirecteur voor twee accounts. Voor een daarvan werk ik voor IKEA, een groot retail- en e-commercebedrijf. We ontwikkelen daar een ontwerpsysteem voor, een soort prototype van een ontwerpsysteem. Daarnaast werk ik voor een andere e-commercewinkel in het Verenigd Koninkrijk. Op dit moment zijn het dus vooral retailprojecten. Wat de uitdagingen betreft: het is altijd lastig om daarover te praten, vooral wanneer ze nog actueel zijn. Maar ik denk—

Ben Aston:

Is het die lastige klant?

Suze Hayworth:

Ja. Nee, eigenlijk niet. Ze zijn echt geweldig — dat moet ik natuurlijk wel zeggen.

Ben Aston:

Dat moet je inderdaad.

Suze Hayworth:

Dat is waar. Het zijn momenteel heel goede klanten. Ik denk dat het goede én slechte aan projecten, en aan projectmanager zijn in het algemeen, het werken met mensen is. Het is geweldig. Ik werk graag met mensen, met verschillende karakters en eigenaardigheden. Maar soms bereik je ook een punt waarop je gefrustreerd raakt omdat je probeert dingen gedaan te krijgen van mensen die iets niet willen doen. Daar heb ik de laatste tijd wel wat mee te maken gehad, denk ik.

Ben Aston:

Plezier en spelletjes. Vertel ons eens over het project voor het ontwikkelen van een ontwerpsysteem. Ik vind dat een interessant project en het is ook een soort project dat we steeds vaker zien. Vroeger behandelde iedereen elk project misschien graag als een uniek sneeuwvlokje en wilden de creatieven creatief zijn. Vertel ons dus: wat is een ontwerpsysteem? Aan welk project werk je precies? En hoe rollen jullie het uit?

Suze Hayworth:

Het is inderdaad een heel spannend project, want zoals je zegt krijgen ontwerpsystemen steeds meer een rol in de digitale wereld. In feite zijn ze een soort stijlbibliotheek voor het digitale ontwerp van bedrijven en merken. Ze vormen een basis van ontworpen componenten, modules en sjablonen die ontwerpers of ontwikkelaars die met het merk werken kunnen gebruiken om hun eigen ontwerpen en code te ontwikkelen. Het is dus een basis die efficiëntie bevordert: herbruikbare code en ontwerpen, en ook efficiëntie en consistentie binnen het bedrijf.

Een merk als IKEA is enorm groot en heeft veel verschillende bureaus, mensen en organisaties die ervoor werken. Zo’n ontwerpsysteem kan een standaard bieden waarmee ontwerpers en ontwikkelaars kunnen werken. Zo kan bijvoorbeeld de knop op een pagina, een oproep tot actie, consistent zijn op meerdere platformen, apparaten, enzovoort, en in apps — welke digitale eigendommen ze ook gebruiken.

Ben Aston:

Kun je me meenemen in het proces van het managen van zo’n project? Het kan een project zijn waarbij je je afvraagt hoe lang een stuk touw is. Hoe pak je het aan? Waar ben je mee begonnen? Waarop itereren jullie? Waar eindigt het product?

Suze Hayworth:

Voor IKEA doen veel merken dit als intern project. IKEA heeft echter extern ondersteuning en hulp gezocht en ons bij het ontwerp betrokken. Dat is een slimme zet, omdat we als buitenstaanders dingen kunnen beoordelen zonder de meer ingebakken benadering die je binnen een bedrijf soms hebt. We begonnen conceptueel met het beoordelen van de principes: de belangrijkste digitale principes, het concept achter ons ontwerp en de ontwerpprincipes van het merk IKEA. Dat vormde de basis. Het was een meer strategische blik op de volledige ervaring en de ontwerpprincipes erachter. Daarna werden we concreter met ontwerpen en stelden we een basisontwerp op aan de hand van bestaande basiselementen, zoals kleur, typografie en rasters. Vervolgens ontwikkelden we dat verder.

Daarna hebben we gebruikerstests uitgevoerd met dat ontwerp op enkele platformen die we uit het aanbod van digitale eigendommen van IKEA hadden gekozen. Vervolgens gingen we verder met het ontwerpen en bouwen van specifieke componenten en plaatsten we die op een website voor het ontwerpsysteem, die momenteel alleen intern wordt gebruikt. We werken nu aan een veelzijdig prototype om dit eerst op gang te brengen. Daarna wordt het, zodra we deze fase hebben afgerond, ontwikkeld tot een volledige oplossing.

Ben Aston:

Mooi. Hoe ziet die volledige oplossing eruit? Is het een soort levende stijlgids met stukjes code die mensen kunnen pakken? Of sjablonen die ze kunnen gebruiken? Is dat de richting waarin het gaat?

Suze Hayworth:

Ik denk dat elk ontwerpsysteem een doorlopend, levend project moet zijn. Het heeft dus geen definitief eindpunt. Het is geen product waar je gewoon mee stopt en dat daarna klaar is. Het moet verder worden ontwikkeld. We zijn nog maar net begonnen en hebben alleen het oppervlak geraakt wat betreft de eerste principes, fundamenten en componenten. Daarna gaat het om het groeperen van die componenten, het ontwikkelen van modules en vervolgens ook sjablonen. Daarna moet je kijken hoe je mensen dit laat gebruiken en verspreiden, en hoe je mensen ermee vertrouwd maakt. Het is een enorm project, zeker gezien het aantal verschillende partijen binnen het bedrijf. We zijn dus eigenlijk nog maar net begonnen, ook al zijn we inmiddels bijna een jaar bezig.

Ben Aston:

Klinkt als een leuk project. Ik vraag mensen altijd graag of ze recent interessante hulpmiddelen hebben ontdekt, of wat hun leven momenteel beter maakt. Is er iets dat je hebt ontdekt, gelezen of geleerd waarvan andere mensen zouden moeten weten?

Suze Hayworth:

Ik gebruik eerlijk gezegd niet echt andere hulpmiddelen. Ik blijf bij wat ik ken. Maar dit is behoorlijk ironisch, aangezien ik in een podcast zit: ik luister de laatste tijd wel naar meer podcasts. Normaal luister ik onderweg naar mijn werk, tijdens mijn uur durende reis, naar muziek. Maar onlangs ben ik die tijd nuttiger gaan gebruiken en luister ik naar allerlei podcasts. Dat is erg goed, want het is een andere manier om te leren en de tijd te benutten terwijl ik in de trein sta — ik wilde zeggen zit, maar ik krijg nooit een zitplaats — op weg naar mijn werk.

Ben Aston:

Zijn er podcasts die je bijzonder nuttig of interessant vindt?

Suze Hayworth:

De podcast van The Digital Project Manager natuurlijk. Dat spreekt voor zich. Daarnaast heb ik onlangs een podcast gedaan voor, was het The Drunken ...? Na mijn sessie op de DPM Summit sprak ik met hem over het onderwerp van mijn sessie. En The Bureau of Digitalists tijdens de DPM Summit. Zij maken goede podcasts. Brett, die de top organiseert, heeft er onlangs een uitgebracht met de naam Sprints and Milestones, gebaseerd op zijn boek over digitaal projectmanagement. Dat is een nuttige bron.

Ben Aston:

Goed bezig. Luister dus naar je podcasts. Iets wat ik zelf erg interessant vind, weet ik niet of je ervan hebt gehoord, heet Blinkist. Ik moet eerlijk zeggen dat ik weinig tot geen podcasts luister, behalve mijn eigen podcasts waarin ik praat. Maar ik denk vaak: dat boek zou ik echt moeten lezen. Vervolgens koop ik het boek en kom ik er nooit aan toe, of ik koop het helemaal niet. Blinkist biedt in feite zeer beknopte samenvattingen van boeken. Het is een soort—

Suze Hayworth:

Volgens mij heb ik daar inderdaad van gehoord.

Ben Aston:

Het duurt ongeveer 15 minuten om zo’n samenvatting te lezen, of je kunt hem laten voorlezen. Iemand leest dan de samenvatting en de belangrijkste punten van het boek voor. Het lijkt een beetje op een podcast. Het mooie is dat je de snelheid kunt verhogen. Je kunt het op normale snelheid afspelen, maar ook op dubbele snelheid. Dan duurt het zevenenhalve minuut om een boek te lezen of te beluisteren.

Suze Hayworth:

Dat is geweldig. Dat moet ik proberen, want ik probeer de laatste tijd ook meer te lezen. Meer boeken inpassen zou goed zijn.

Ben Aston:

Dat is mijn boeksnelkoppeling voor jullie allemaal: Blinkist. Goed, we zouden het vandaag hebben over sluipende scope-uitbreiding. Laten we het daarover hebben. Voor wie dit begrip niet kent: wat is het en waarom zouden we ons er druk om maken?

Suze Hayworth:

Het betekent in feite dat je scope — dus je op te leveren resultaten, alles wat je hebt afgesproken en de functies in een project — groter wordt dan wat je oorspronkelijk had afgesproken, zonder dat je rekening houdt met de extra tijd en middelen die daarvoor nodig zijn. Een project kan hierdoor worden beïnvloed omdat het in allerlei vormen kan voorkomen. Het gaat erom dat dingen ongemerkt binnensluipen, zich uitbreiden en ervoor zorgen dat binnen je project tijd verloren gaat.

Ben Aston:

Het is dus extra werk waar we geen rekening mee hadden gehouden, met gevolgen voor ons budget, onze planning en uiteraard de scope, oftewel de hoeveelheid werk die we uitvoeren.

Er zijn veel redenen waarom dit gebeurt. We zijn heel goed in het creëren van werk voor onszelf. In het artikel dat je hebt geschreven zullen we niet alle oorzaken bespreken, want er zijn er ontzettend veel.

Suze Hayworth:

Dat zijn er inderdaad veel.

Ben Aston:

Wat zijn volgens jou de meest voorkomende oorzaken? En laten we daarna de meest geniepige bespreken.

Suze Hayworth:

Een van de meest voorkomende oorzaken is dat de scope in het begin niet duidelijk is. Wanneer je de op te leveren resultaten vastlegt en aan het begin van een project een opdrachtomschrijving schrijft, kan een vage beschrijving of een onvoldoende strakke definitie van wat je precies oplevert later problemen veroorzaken. Een klant of iemand binnen de organisatie kan dezelfde beschrijving anders interpreteren. Vervolgens begint het project te groeien op basis van een vage vastlegging van de op te leveren resultaten.

Het is dus belangrijk om de scope vooraf duidelijk te maken en ervoor te zorgen dat degene die de scope goedkeurt precies begrijpt wat hij krijgt. Een opdrachtomschrijving is nuttig om alle op te leveren resultaten en werkzaamheden vast te leggen, maar het zijn vaak lange documenten. Je geeft ze aan een klant en verwacht dat die alles leest, verwerkt en begrijpt. Daarom moet je de belangrijkste punten, planning en het budget duidelijk uitlichten en expliciet uitleggen. Zelfs als je denkt dat de klant het document heeft gelezen, is het belangrijk om de eerste scope samen in een vergadering door te nemen en zeker te weten dat de klant begrijpt wat hij krijgt.

Veel problemen ontstaan wanneer een opdrachtomschrijving is goedgekeurd en mensen later zeggen: ‘Maar ik dacht dat ik dit zou krijgen’, ook al stond het misschien ergens explicieter beschreven.

Ben Aston:

We zijn dus aan het begin niet duidelijk. We zeggen bijvoorbeeld: ‘Ja, klant, we maken een paginasjabloon voor je’, maar definiëren niet volledig wat er eigenlijk in dat sjabloon komt. Vaak is het ook een communicatieprobleem: we hebben de klant niet duidelijk gemaakt wat we met ‘sjabloon’ bedoelen.

Suze Hayworth:

Precies. Het gaat om twee dingen: de op te leveren resultaten vooraf duidelijk vastleggen en ervoor zorgen dat degene die de scope goedkeurt echt begrijpt wat je hebt beschreven. Zelfs als je heel expliciet bent, kan de klant nog steeds een ander beeld hebben van wat hij krijgt, terwijl dat niet in de scope staat.

Ben Aston:

Dat zijn dus de meest voorkomende situaties: wij zijn niet duidelijk en de klant begrijpt het niet.

Maar hoe zit het met de geniepigere kant? Wat is de meest ongebruikelijke of moeilijk te herkennen vorm van scope-uitbreiding die je hebt meegemaakt?

Suze Hayworth:

Projectmanagers denken vaak dat scope-uitbreiding van de klant komt: de klant vraagt voortdurend om iets extra’s, wil iets uitbreiden of wil meer. Maar het kan ook afkomstig zijn van interne teams en belanghebbenden. Als teamleden niet goed begrijpen wat ze moeten doen, gaan ze soms onbewust een andere richting op, waardoor hun werkzaamheden langer duren of de functionaliteit groter wordt. Een ontwerper kan bijvoorbeeld iets ontwerpen zonder te beseffen welke gevolgen dat heeft voor de ontwikkelingsscope. Dat kan volledig onbedoeld gebeuren. Of iemand heeft bijna een eigen agenda en wil iets bouwen of ontwerpen omdat hij dat interessant vindt.

Het is misschien verrassender wanneer het intern ontstaat, omdat je wilt dat iedereen dezelfde richting op werkt. Ook andere interne belanghebbenden kunnen zakelijke behoeften in het project verwerken. Ze willen misschien meer opleveren vanuit relatieperspectief of spreken dingen af zonder dat jij daarvan op de hoogte bent. Dat is ook een klassieker.

Ben Aston:

Een van de meest geniepige oorzaken is inderdaad intern werk, zoals het toevoegen van extra kwaliteit. Interne teams proberen soms een ontwerp, strategie of ontwikkeling mooier te maken dan afgesproken. Iemand wil geweldig werk leveren of denkt dat iets een pronkstuk kan worden dat we kunnen inzenden voor prijzen. Maar niemand heeft besproken wie voor dat extra werk betaalt of wie ervoor verantwoordelijk is.

Suze Hayworth:

Precies.

Ben Aston:

Een andere oorzaak is kwaliteitsborging. In de kwaliteitsborgingsfase hebben we misschien niet duidelijk vastgelegd wat de acceptatiecriteria zijn. Of we hebben niet gezegd dat een bepaalde oude browser niet getest hoeft te worden. Het kwaliteitsteam kan dan besluiten die browser toch te testen en ontwikkelaars kunnen problemen proberen op te lossen die helemaal niet opgelost hoeven te worden.

Suze Hayworth:

Volledig. Kwaliteitsborging is een van de grootste gebieden waarop projecten kunnen uitlopen. Aan het begin kun je op basis van de ontwikkelperiode een ruwe inschatting maken, maar het is moeilijk te voorspellen hoeveel extra werk nodig is voor nieuwe tests en hertests. Dat kan steeds verder toenemen, zeker wanneer je vooraf geen grenzen vastlegt. Definieer dus de acceptatiecriteria, bepaal de browser- en apparaatmatrix en stel prioriteiten voor bugs en problemen. Welke problemen moeten worden opgelost voordat je kunt publiceren? Welke hebben een lagere prioriteit en kunnen na de lancering worden opgelost?

Ook hier gaat het om het zo duidelijk mogelijk definiëren van de kernscope en het verminderen van onzekerheid. Daarnaast is voortdurende communicatie essentieel. Als tijdens de kwaliteitsborging blijkt dat één browser veel extra tijd kost, moet je dat snel en open met de klant of belanghebbende bespreken. Leg uit wat de oorzaak is, geef alternatieven en stel prioriteiten vast. Zo maak je scope-uitbreiding zo snel mogelijk zichtbaar en bied je tegelijkertijd oplossingen.

Ben Aston:

We hebben besproken dat onduidelijke scope, ongecontroleerd intern werk en kwaliteitsborging scope-uitbreiding kunnen veroorzaken. Wiens schuld is het? Niet om met vingers te wijzen, maar om te bepalen hoe we ermee omgaan.

We hebben de klant, interne belanghebbenden en teams genoemd. In jouw artikel noem je ook derden, gebruikers en ons als projectmanagers. In hoeverre is dit ons probleem en onze schuld?

Suze Hayworth:

Het gaat niet om schuld, maar om het vaststellen van risico’s. Kijk welke mensen binnen je project scope-uitbreiding kunnen veroorzaken en wat ze zouden kunnen doen. Dat helpt om vooraf risico’s te herkennen.

Als projectmanager kijken we vaak naar buiten: wat kan het team doen, wat kan de klant doen? Maar persoonlijk kunnen we ook bijdragen door problemen niet te signaleren wanneer ze ontstaan. Ik geef toe dat ik dit vroeger ook heb gedaan. Als er een probleem is, wil je het oplossen en soms verbergen in plaats van het steeds aan de klant te melden. Je wilt het project draaiende houden, tegen de planning vechten en resultaten opleveren. Daardoor zeg je misschien dat je het probleem hier of daar wel kunt opvangen, zonder de klant er op dat moment over te informeren.

Dat is een gebied waarin we beter kunnen worden. Een gesprek is veel gemakkelijker wanneer je eerlijk en open bent en een probleem snel aankaart. Presenteer niet alleen het probleem, maar ook mogelijke oplossingen. Stel vast wat er misgaat, bepaal wat het probleem veroorzaakt en ga vervolgens met een aantal alternatieven naar de klant.

Als de scope-uitbreiding intern is ontstaan, kijk dan hoe je die kunt terugbrengen, maar laat de klant wel weten dat het is gebeurd. Als een klant iets vraagt dat buiten de afspraak valt, slik het dan niet zomaar in. Onderzoek de impact, werk verschillende opties uit en bespreek vervolgens met de klant wat bijvoorbeeld een lagere prioriteit kan krijgen.

Ben Aston:

We zijn al vooruitgelopen op hoe we ermee omgaan. Als projectmanagers kunnen we ook proberen onze scope duidelijker te maken. Vraag een andere projectmanager om mee te kijken. Vraag kwaliteitsborging of een bedrijfsanalist om de scope kritisch te beoordelen. Zij vinden vaak hiaten en stellen vragen waarop je zelf niet was gekomen.

Ook communicatie is belangrijk. Gooi niet simpelweg een opdrachtomschrijving over de schutting in de hoop dat de klant tekent. Bespreek het document daadwerkelijk met de klant. Dat helpt om problemen vanaf het begin te voorkomen.

Je zei ook dat we scope-uitbreiding niet onder het tapijt moeten vegen. Als projectmanager die met klanten werkt, is het verleidelijk om niets te zeggen omdat je de relatie goed wilt houden. Maar als je niet transparant bent, wordt het probleem uiteindelijk te groot. Proactief zijn, transparant communiceren, prioriteiten stellen en de impact analyseren zijn daarom erg belangrijk.

Scope-uitbreiding wordt vaak geassocieerd met watervalprojecten, waarbij vooraf veel wordt gepland en vervolgens fase voor fase wordt uitgevoerd. Is het ook een probleem bij agile projecten? Waar moeten mensen in een meer iteratief en flexibel project op letten?

Suze Hayworth:

Dat wilde ik in mijn artikel benadrukken. Scope-uitbreiding wordt vaak als iets negatiefs gezien omdat we ons aan een vaste afgesproken scope proberen te houden. Het mooie van agile werken en agile methoden is juist dat verandering wordt omarmd. Dat is een kernprincipe van agile: verandering kan uiteindelijk een beter product of een betere dienst opleveren.

Verandering is dus niet de vijand. Het is vaak iets goeds. Je moet vooral weten hoe je ermee omgaat.

In een agile project, bijvoorbeeld een Scrum-project, spreek je nog steeds af wat je binnen een bepaalde tijdsperiode, de sprint, gaat doen. Je bepaalt wat er in de backlog komt. Een product owner of klant kan tijdens een sprint iets aan de backlog willen toevoegen terwijl alles al gepland en afgesproken is. Dat kan invloed hebben op wat je oplevert en op de release.

Let erop dat wat wordt toegevoegd niet simpelweg bovenop al het andere komt. Herprioriteer en zorg dat de inspanning voor de nieuwe verhalen of epics wordt gecompenseerd door iets anders een lagere prioriteit te geven. Scope-uitbreiding komt dus ook in agile projecten voor, maar de kortere tijdsperiodes en regelmatige releases maken het vaak gemakkelijker om veranderingen te verwerken.

Ben Aston:

Ik vind het goed om het gesprek te veranderen en verandering te omarmen. Scope-uitbreiding kan een negatief gesprek worden omdat het meestal meer kosten betekent. We moeten de klant dan vertellen dat iets extra tijd en extra budget kost.

Maar met een transparante, doorlopende dialoog over de realiteit en beperkingen van het budget kunnen we samen prioriteiten stellen. Misschien krijgt de klant niet de functionaliteit die hij oorspronkelijk wilde, maar ontdekken we tijdens het project iets dat belangrijker is. Dat is goede verandering voor de gebruiker, de klant, het project en het team.

Suze Hayworth:

Helemaal. Het is belangrijk om voortdurend te praten over wat je oplevert en wat uiteindelijk het meeste voordeel biedt aan de gebruikers van het product of de dienst. Als de klant iets nieuws vraagt, denk dan niet meteen: ‘Dat kan niet, tenzij je meer betaalt.’ Onderzoek wat het voordeel voor gebruikers is, waarom de vraag nu ontstaat en of er een nieuwe behoefte wordt aangepakt. Als de nieuwe functionaliteit waardevoller is, vergelijk die dan met andere op te leveren resultaten en geef iets anders een lagere prioriteit.

Houd de klant betrokken, analyseer nieuwe verzoeken en bepaal waarom ze worden gedaan en wat het uiteindelijke voordeel is.

Ben Aston:

Maak er een gesprek van en denk aan de gebruiker. Scope-uitbreiding hoeft niet negatief te zijn. Ze kan goed zijn voor gebruikers, de klant, het project en het team. We hoeven er dus niet bang voor te zijn; het is beter om ermee te leren omgaan.

Wat is je belangrijkste advies voor mensen van wie projecten steeds boven budget uitkomen, te laat zijn en grote problemen met scope-uitbreiding hebben?

Suze Hayworth:

Als je aan een nieuw project begint, richt je dan op de inschatting en de manier waarop je de scope bepaalt. Werk niet in een isolement: maak de inschatting samen met het team en zorg dat die zo goed mogelijk is, terwijl je beseft dat het om schattingen gaat. Zo voorkom je dat planning en budget tijdens de uitvoering plotseling uit de hand lopen.

Kom je nieuw binnen in een lopend project, maak dan eerst de balans op. Bepaal hoe ver het project is uitgelopen, zorg dat je een nauwkeurig beeld hebt van wat nog moet gebeuren en bespreek dit met de klant. Benoem de problemen openlijk en voer daarover een eerlijk gesprek.

Ben Aston:

Suze, bedankt dat je bij ons was. Het was geweldig om je erbij te hebben. Als een van onze DPM-experts verschijnt Suze ook in onze komende cursus, die in februari begint. De cursus heet Mastering Digital Project Management. Als je niet weet waar ik het over heb maar wel projectmanagementtraining nodig hebt, neem dan een kijkje. Het is een intensieve cursus van zeven weken met interactieve videolessen, opdrachten, webinars, groepsdiscussies en de mogelijkheid om ook coachingssessies te volgen. Ga naar DPMschool.com en schrijf je in voordat de cursus vol is. Wil je aan het gesprek over scope-uitbreiding bijdragen, reageer dan op het artikel en ga naar de bronnensectie van TheDigitalProjectManager.com om je bij ons Slack-team aan te sluiten. Tot de volgende keer, bedankt voor het luisteren.