Scrum - Hoe budgettering en financiële forecast?

[joostvanpoppel]

Hi,

In mijn zoektocht naar scrum vragen en antwoorden kwam ik op "Programming" uit. Wellicht zijn hier scrummasters die antwoord hebben op mijn vraag; hoe vind project budgettering en financiële forecasting plaats? Hoe vindt dat bij jullie in de praktijk plaats? En hoe zou het volgens het framework moeten werken?

Fixed funding? Of met enige regelmaat het budget herzien tov de geleverde waarde?

thanks,
Joost

[Sircuri]

Als eerste moet ik opmerken dat er niks MOET volgens het framework. Het is een best practice en je haalt er uit wat je denkt nodig te hebben,

Hoe zie de financiering er nu uit? Is het een fixed budget of moet eerst het hele project geanalyseerd worden om tot een guestimation te komen voor de totale inspanning?
De echte Scrum manier is fiat krijgen voor een bepaalde hoeveelheid sprints waarin het development team zich committeerd aan een X aantal features. Na elke sprint een retro houden en kijken hoe ver je bent en je PM laten beslissen of het haalbaar is om op deze koers door te gaan. Ben je door je budget heen, maar ziet men er nog steeds waarde in, dan zal er nieuw budget kunnen komen voor nog eens een aantal sprints.

De focus ligt op added value.
Als alles van te voren helemaal duidelijk moet zijn, weet ik niet of Scrum echt de juiste manier van werken is.

[Woy]

Sircuri schreef op maandag 4 maart 2019 @ 22:03:
De focus ligt op added value.
Als alles van te voren helemaal duidelijk moet zijn, weet ik niet of Scrum echt de juiste manier van werken is.

Ook daar kan het prima, want het gaat vooral om de complexiteit te managen. Ook een fixed price project kan prima op een scrum manier uitgevoerd worden, alleen als er toch meer tijd nodig is dan kun je dat niet door factureren. Het is juist wel een goede manier om op tijd inzichtelijk te krijgen als er toch andere wensen zijn die buiten de initiële offerte vallen, en dan te overleggen of er ook extra budget is, of dat er andere functionaliteit moet sneuvelen.

Het grote probleem met fixed price is vooral het tot stand komen van de prijs. Dat kan je prima op de conventionele manier doen, dan heb je vast een duidelijk gedefinieerd backlog. Wat je als eerste oppakt kan dan gewoon aan de hand van wat het meeste toegevoegde waarde heeft. Grote kans dat je dan tijdens de uitvoering van het project tot de conclusie komt dat de klant toch nog andere wensen heeft, dat is dan ook het punt om opnieuw te overleggen over de prijs, of welke andere functionaliteit wordt gedropt.

@joostvanpoppel op zich is dit een prima plek om deze vraag te stellen, maar we verwachten eigenlijk wel dat je ook iets meer zelf aangeeft wat je al bedacht hebt, en welke problemen je voorziet.

[ Voor 7% gewijzigd door Woy op 05-03-2019 15:55 ]

[Standeman]

Het Scrum framework zelf zeg uiteraard helemaal niets over budgettering en geeft ook geen handvatten om voorspellingen te doen over de hoeveelheid uren of euro's besteed gaan worden om het project af te ronden. Vaak is het ook ontzettend moeilijk vast te leggen wat nou exact het eindresultaat moet zijn, zelfs als de wereld om je heen statisch zou zijn.

Met een ervaren team kan je wel een inschatting maken hoeveel je sprints je ongeveer denk dat je misschien nodig hebt om een project tot een redelijk resultaat te brengen. De risico's zitten vooral in de wispelturigheid van de klant, wet -en regelgeving, voortschrijdende inzichten en hoe veranderlijk de business is.

Mijn inziens komt het neer op het definieren van een backlog, inschatten hoeveel sprints je daar mogelijk voor nodig hebt en elke sprint de toegevoegde waarde goed in de gaten houden en met de klant bespreken hoe het ervoor staat.

Verder houden scrummasters (als het goed is) bijzonder weinig bezig met budgettering. Die houden het Scrum proces in de gaten, verhelpen dependencies en draagt het uit naar de rest van de organisatie.
Ik denk dat Product Owners meer te maken hebben met budgettering.

Sircuri schreef op maandag 4 maart 2019 @ 22:03:
Als eerste moet ik opmerken dat er niks MOET volgens het framework. Het is een best practice en je haalt er uit wat je denkt nodig te hebben,

Daar ben ik het mee oneens. Ja, je hebt binnen scrum de vrijheid om heel veel zaken toe te voegen (poker sesssies, refinements) en hoe je de events inricht moet je zelf weten.

Maar wanneer je zegt, "We gooien de sprintplanning er uit" werkt Scrum voor geen meter meer. Net zoals bij het overslaan van de Review, teams van 20 man of geen Definition of Done hanteren.
In vrijwel alle organisaties die halfbakken het scrumproces implementeren heb ik het ook episch zien falen. De Scrum guide is echt het minimale. Als je daar niet aan voldoet kan je het beter gewoon helemaal achterwege laten.

[ Voor 39% gewijzigd door Standeman op 05-03-2019 16:26 ]

[Kwistnix]

Mijn ervaring met financiële sturing in een Scrum proces, is dat het er bijna zonder uitzondering op neer komt dat stories in uren worden geschat, gestimuleerd door degene die de voortgangsrapportages moet opstellen. Daarin wil men namelijk wel graag uurtjes kunnen zien en omrekenen naar eurootjes. Vaak wordt er dan gerekend met 1 punt == x uren, waardoor het schatten in punten totaal zinloos is. En helemaal leuk wordt het, wanneer het onvermijdelijk moment aanbreekt waarop een of andere bijgoochem de velocities van de verschillende scrum teams gaat vergelijken. Als de scrum master(s) niet voor dit soort praktijken gaat liggen, degenereert het scrum proces op een of andere manier altijd naar iets als dit. Al te vaak meegemaakt.

[Standeman]

Kwistnix schreef op dinsdag 5 maart 2019 @ 16:57:
Mijn ervaring met financiële sturing in een Scrum proces, is dat het er bijna zonder uitzondering op neer komt dat stories in uren worden geschat, gestimuleerd door degene die de voortgangsrapportages moet opstellen. Daarin wil men namelijk wel graag uurtjes kunnen zien en omrekenen naar eurootjes. Vaak wordt er dan gerekend met 1 punt == x uren, waardoor het schatten in punten totaal zinloos is. En helemaal leuk wordt het, wanneer het onvermijdelijk moment aanbreekt waarop een of andere bijgoochem de velocities van de verschillende scrum teams gaat vergelijken. Als de scrum master(s) niet voor dit soort praktijken gaat liggen, degenereert het scrum proces op een of andere manier altijd naar iets als dit. Al te vaak meegemaakt.

Klopt 100%. Story punten hebben niets met uren te maken, maar met effort en een Scrummaster moet er echt voor vechten om dit soort zinloze praktijken tegen te gaan. En velocities van verschillende teams vergelijken is echt
Ik heb genoeg projectmanagers meegemaakt en ze met de handen in het haar zien staan omdat ze niet meer wisten wat hun rol was of hoe ze nou verder moesten

Welk grappig is dat story points en velocity eigenlijk niks met Scrum te maken hebben en maar heel weinig mensen dat realiseren.

[ Voor 6% gewijzigd door Standeman op 05-03-2019 17:07 ]

[rvankruistum]

Standeman schreef op dinsdag 5 maart 2019 @ 17:05:
[...]
Welk grappig is dat story points en velocity eigenlijk niks met Scrum te maken hebben en maar heel weinig mensen dat realiseren.

Jawel hoor. Scrum is zo'n bord met van die post-its, en dat je geen documentatie meer hebt en burndown charts en zo

Mijn antwoord op de oorspronkelijke vraag zou zijn: Forecasting, budgettering op de lange termijn etc. is in mijn ogen altijd een ruwe gok. Het hele idee van agile werken is dat je van tevoren niet weet wat je niet weet en dus ook niet precies kan inschatten hoeveel het gaat kosten. Vraag aan het team hoeveel sprints ze ongeveer nodig hebben voor een feature, verdubbel dat aantal voor de zekerheid en reken uit wat de kosten zijn. Elk uur dat aan dit soort zaken wordt besteed is een uur dat niet gebruikt wordt om iets waardevols op te leveren, en in de praktijk is er geen betrouwbare manier om op een nauwkeurige inschatting uit te komen.

[ACM]

Standeman schreef op dinsdag 5 maart 2019 @ 17:05:
Story punten hebben niets met uren te maken, maar met effort

Het zou wel heel bijzonder zijn als er geen relatie tussen uren en effort zit... In werkelijkheid zit er natuurlijk een hele sterke correlatie tussen het aantal punten en uren. En dat druk je effectief uit in de velocity.

Door die twee via de vecolity te ontkoppelen kan je bij gelijke schattingen toch meer of minder verwachte tijd nodig hebben. Dat kan komen doordat e.e.a. soepeler gaat - men raakt op elkaar ingespeeld, leert het product beter kennen, enz. Of juist door nadelige aspecten; de werksfeer raakt ergens door verpest, een teamlid gaat op vakantie of naar een andere baan, er komt een of andere onverwachte verandering of tegenslag, enz. En natuurlijk ook doordat de "ene 3" niet de "andere 3" is.

Het lastige is natuurlijk wel dat het de bedoeling is dat story points vooral uitdrukken dat story A ruwweg evenveel of juist meer/minder werk is dan story B. Maar dat dat dan niet zegt dat als A 5 punten is en B 13 punten, dat het ook daadwerkelijk 2.6x zoveel tijd zal kosten (of zoveel werk/effort is). Er zitten daar ook domweg veel meer onzekerheden in.

Overigens is het in mijn ervaring niet ongebruikelijk dat schattingen toch ook weer deels voortkomen uit een gok hoeveel tijd je ergens mee bezig bent. Bijvoorbeeld "zeker wel een hele dag"; "veel" en "weinig" werk hebben tenslotte toch ook weer een sterke correlatie met tijd

Er zijn verder vast puristen die vinden dat je voor een sprint begint helemaal niet naar de velocity moet kijken om te bepalen hoeveel werk het team aankan. Maar ik vind het zelf in ieder geval wel handig om een indicatie te hebben wat er zou moeten kunnen, gegeven de velocity van de afgelopen sprints in combinatie met de beschikbare manuren.

Gelukkig klopt dat in onze praktijk ook vaak best goed zodra de teams een tijdje op gang zijn met een project.

[Hydra]

SCRUM / Agile hebben echt niks met projectbudgetten e.d. te maken. Het idee van agile werken is dat alles vooruit plannen meestal niet werkt, en dat je om met veranderingen om te kunnen gaan in korte iteraties moet werken. Je deelt je project dus op in mini projectjes van bijvoorbeeld 2 weken. Da's eigenlijk het hele eieren eten.

Kwa budgetten van projecten is het over het algemeen nog steeds fixed price (met een flink premium daarbovenop) of uurtje-factuurtje.

Standeman schreef op dinsdag 5 maart 2019 @ 17:05:
Ik heb genoeg projectmanagers meegemaakt en ze met de handen in het haar zien staan omdat ze niet meer wisten wat hun rol was of hoe ze nou verder moesten

Dat komt ook omdat er in zelf-studeren agile teams helemaal geen rol weggelegd is voor een 'projectmanager'.

[ Voor 29% gewijzigd door Hydra op 06-03-2019 08:48 ]

[Standeman]

ACM schreef op woensdag 6 maart 2019 @ 08:46:
[...]

Het zou wel heel bijzonder zijn als er geen relatie tussen uren en effort zit... In werkelijkheid zit er natuurlijk een hele sterke correlatie tussen het aantal punten en uren. En dat druk je effectief uit in de velocity.

Ja, maar met een flinke disclaimer: Het team moet 3 a 4 sprints ongewijzigd en gefocust kunnen werken aan het project met een duidelijke backlog, pas dan kan je voor dat team een bruikbare correlatie tussen storypoints en uren zien.
Zodra je de teamsamenstelling wijzigt, individuen andere taken geeft of aan een ander project laat werken is die correlatie het eerste dat je direct uit het raam kan gooien.

Door die twee via de vecolity te ontkoppelen kan je bij gelijke schattingen toch meer of minder verwachte tijd nodig hebben. Dat kan komen doordat e.e.a. soepeler gaat - men raakt op elkaar ingespeeld, leert het product beter kennen, enz. Of juist door nadelige aspecten; de werksfeer raakt ergens door verpest, een teamlid gaat op vakantie of naar een andere baan, er komt een of andere onverwachte verandering of tegenslag, enz. En natuurlijk ook doordat de "ene 3" niet de "andere 3" is.

En er zit nog ook nog een stuk risico gecalculeerd in de story. Sommige zijn no-brainers, maar andere hebben meer onbekende factoren of zijn afhankelijk van bijv. stakeholders. Dan kan zeker de ene 3 niet overeenkomt met de andere 3. Zeker niet qua doorlooptijd.

Het lastige is natuurlijk wel dat het de bedoeling is dat story points vooral uitdrukken dat story A ruwweg evenveel of juist meer/minder werk is dan story B. Maar dat dat dan niet zegt dat als A 5 punten is en B 13 punten, dat het ook daadwerkelijk 2.6x zoveel tijd zal kosten (of zoveel werk/effort is). Er zitten daar ook domweg veel meer onzekerheden in.

Overigens is het in mijn ervaring niet ongebruikelijk dat schattingen toch ook weer deels voortkomen uit een gok hoeveel tijd je ergens mee bezig bent. Bijvoorbeeld "zeker wel een hele dag"; "veel" en "weinig" werk hebben tenslotte toch ook weer een sterke correlatie met tijd

Er zijn verder vast puristen die vinden dat je voor een sprint begint helemaal niet naar de velocity moet kijken om te bepalen hoeveel werk het team aankan. Maar ik vind het zelf in ieder geval wel handig om een indicatie te hebben wat er zou moeten kunnen, gegeven de velocity van de afgelopen sprints in combinatie met de beschikbare manuren.

Gelukkig klopt dat in onze praktijk ook vaak best goed zodra de teams een tijdje op gang zijn met een project.

Je kan de velocity aardig gebruiken als graadmeter voor de volgende sprint, maar je kan er geen harde uitspraken over doen. Sprint bugs, ziekte, vakantie en allerlei externe factoren kunnen een rol spelen in het afwijken. Mijn nekharen gaan overeind staan wanneer een team elke sprint exact 50 storypoints opleveren. Dan gaat er iets ontzettend mis.

[Woy]

Standeman schreef op woensdag 6 maart 2019 @ 09:05:
Mijn nekharen gaan overeind staan wanneer een team elke sprint exact 50 storypoints opleveren. Dan gaat er iets ontzettend mis.

Dat komt tevens omdat er te vaak binnen bedrijven "Commitment" van het team gevraagd wordt om de sprint te "Halen". Als dan niet alles wat in de planning geselecteerd is af komt dan is het meteen weer paniek. Gevolg is dat teams weer gewoon veilig gaan schatten, of dingen als done markeren die helemaal nog niet af zijn. Het doel is niet om de sprint vooraf helemaal in detail te plannen. Het doel is om een duidelijk doel voor een x periode te hebben, en aan de hand van dat doel ook binnen de sprint te kunnen sturen.

[ Voor 4% gewijzigd door Woy op 06-03-2019 10:29 ]

[Hydra]

Standeman schreef op woensdag 6 maart 2019 @ 09:05:
Mijn nekharen gaan overeind staan wanneer een team elke sprint exact 50 storypoints opleveren. Dan gaat er iets ontzettend mis.

Vanuit het standpunt van de devs niet. Ze doen precies wat van ze gevraagd wordt; consistente aantal 'punten' opleveren.

Dat een punt steeds minder waard wordt, dat weet 'het management' dan niet.

Ik ben zelf een groot voorstander van punten helemaal afschaffen. Ze zijn in mijn ervaring alleen ietwat nuttig als je in een constante omgeving vrijwel constant dezelfde dingen doet. En dat is als software engineer vrijwel nooit het geval. In een vorige klus bijvoorbeeld heb ik veel API integraties gedaan. De PO vond het moeilijk te begrijpen dat de ene me een paar dagen kostte, en de andere 2 weken. "Maar het is toch dezelfde story"? Tja, die eerste had een simpele Oauth implementatie met goeie documentatie en die tweede zat rare shit te doen met RSA, had geen documentatie en ze reageren niet op e-mail.

Waar het systeem voorbij aan gaat zijn de 'unknown unknowns'. Je hebt bij de inschatting de 'knowns' (waar je ervaring mee hebt), de known unknowns (de dingen die je nog niet uitgevogeld hebt maar weet dat er aan gaan komen) en de unknown unknowns (de verassingen die je niet aan ziet komen. 80% van m'n werk is over het algemeen 'unknowns', en door ervaring zijn het relatief vele 'known unknowns'. Maar je blijft je kop stoten aan shit die je niet verwacht. En dat is software-engineering eigen.

Als je bij een projectbureau werkt die eigenlijk iedere keer dezelfde webshop voor een andere MKB klant neerzet dan kun je een redelijk consistente velocity houden. Als je werkt aan een enkele complexe applicatie gaat, door de groeiende complexiteit, je velocity omlaag. Als het bedrijf groeit, gaat door de groeiende complexiteit in de communicatie, je velocity omlaag. Als je als manager daar dan over gaat klagen is het enige dat je bewerkstelligt punten-inflatie. Je wordt dan dus blind voor die vertraging.

En als je dus niet stuurt op velocity, wat de enige optie wat mij betreft is, heeft het ook bijzonder weinig zin om dergelijke punten te gaan toekennen. Ik zie ook veel projecten waar ze maar met T-shirt sizes gaan werken; werkt beter omdat je ze niet op kunt tellen en er geen grafiekjes van kan maken. Prima. Er is niks schadelijker dan demo sessies met burndown charts.

[Standeman]

Woy schreef op woensdag 6 maart 2019 @ 10:28:
[...]

Dat komt tevens omdat er te vaak binnen bedrijven "Commitment" van het team gevraagd wordt om de sprint te "Halen". Als dan niet alles wat in de planning geselecteerd is af komt dan is het meteen weer paniek. Gevolg is dat teams weer gewoon veilig gaan schatten, of dingen als done markeren die helemaal nog niet af zijn. Het doel is niet om de sprint vooraf helemaal in detail te plannen. Het doel is om een duidelijk doel voor een x periode te hebben, en aan de hand van dat doel ook binnen de sprint te kunnen sturen.

Ligt er een beetje aan wat je bedoelt met commitment. Het team (niemand anders!) geeft wel commitment af op de sprintplanning en er moeten aanwijsbare redenen zijn indien die planning niet gehaald wordt. De velocity wordt gebruikt om in te schatten hoeveel werk er in een sprint gedaan kan worden.
Druk van buiten af kan er inderdaad voor de effecten zorgen die beschrijft en zijn in veel organisaties echt een probleem.

@Hydra Sturen op storypoints en velocity is inderdaad een no-go. Imho dienen ze ook maar twee functies en dat is 1) een leidraad in hoeveel werk je de komende sprint kan verzetten en 2) status van de huidige sprint. Daar zit wel de harde eis aan vast dat je een goed uitgewerkte backlog moet hebben.

En als van het management de velocity omhoog moet, dan is dat zo geregeld Zorgt er wel voor dat je er geen ene moer meer aan hebt.

[Woy]

Standeman schreef op woensdag 6 maart 2019 @ 11:57:
[...]
Ligt er een beetje aan wat je bedoelt met commitment. Het team (niemand anders!) geeft wel commitment af op de sprintplanning en er moeten aanwijsbare redenen zijn indien die planning niet gehaald wordt.

Dat is dus een beetje de misvatting, natuurlijk moet het team zich committen, maar dat betekend niet dat er een fixed scope op een fixed moment opgeleverd dient te worden. Hier wordt het ook mooi uitgelegd: https://www.scrum.org/res...alues-commitment-part-4-5

Sowieso wordt die misvatting ook nog eens versterkt door bedrijven die van alles extra verwachten, zonder dat dat invloed op het behaalde resultaat mag hebben, want "Het team heeft zich hier aan gecommit", dat er dan ook aan externe voorwaarden voldaan moet worden wordt daar meestal maar bij vergeten.

[Croga]

Standeman schreef op woensdag 6 maart 2019 @ 11:57:
Ligt er een beetje aan wat je bedoelt met commitment. Het team (niemand anders!) geeft wel commitment af op de sprintplanning en er moeten aanwijsbare redenen zijn indien die planning niet gehaald wordt.

Dit is exact de misvatting die er voor gezorgd heeft dat het concept "Commitment" helemaal niet meer bestaat.

Commitment betekend zoveel als "We denken dat dit realistisch is en zullen er alles aan doen om dit te halen". Op geen enkele manier is het een belofte van levering, het is een belofte van inzet.

Maar omdat mensen dachten dat het een belofte van levering was, is het woord nu vervangen door "Forecast". Ofwel: Het kan zijn dat we dit leveren. Het kan ook zijn dat we dit niet leveren.

Daarnaast wordt er een commitment gegeven op goal, niet op content. De commitment is op "Aan het eind van deze sprint kan de gebruiker inloggen", niet op de product backlog items die die login volledig functioneel maken.

Standeman schreef op woensdag 6 maart 2019 @ 09:05:
Je kan de velocity aardig gebruiken als graadmeter voor de volgende sprint, maar je kan er geen harde uitspraken over doen. Sprint bugs, ziekte, vakantie en allerlei externe factoren kunnen een rol spelen in het afwijken. Mijn nekharen gaan overeind staan wanneer een team elke sprint exact 50 storypoints opleveren. Dan gaat er iets ontzettend mis.

Het grappige is dat er hier een aantal zijn die "Velocity" willen gebruiken om een team op af te rekenen. En zoals sommigen al stellen; dan verliest de inschatting én de velocity alle waarde.

Velocity is dan ook niet "Wat we vorige sprint gedaan hebben" maar "Wat we verwachten te kunnen doen op basis van wat we in het verleden gedaan hebben".

Als je iedere sprint genoeg werk plant om exact aan je velocity te komen dan zul je 50% van de tijd al dat werk af krijgen. Zo werken gemiddeldes namelijk. En je hebt gelijk; iedere sprint exact dezelfde velocity is een red flag voor de Scrum Master; dan wordt er ergens gelogen, heb je dus geen transparantie....

Velocity is een planning tool voor het team. Het is een sanity check of je het werk wat je komende sprint wilt gaan doen, op basis van het werk wat je in het verleden verzet hebt, in redelijkheid af kunt krijgen of niet. Het is dus náást je eigen common sense inschatting en heeeeeel mischien kan de PO het gebruiken om een idee te krijgen van wat we in de nabije toekomst gaan realiseren.

[ Voor 42% gewijzigd door Croga op 06-03-2019 14:55 ]

[Hydra]

Croga schreef op woensdag 6 maart 2019 @ 14:50:
Velocity is een planning tool voor het team.

Belangrijkste kernpunt wat mij betreft. Zo gauw je het naar buiten gaat communiceren (in demo's of op een dashboard ofzo) ontstaat er druk en door die druk gaan mensen de boel flessen. En dan is meteen je hele waarde weg. En omdat dit in eigenlijk elk project tot nu toe wel gebeurd is, ben ik zelf dus een voorstander van er helemaal niet meer aan doen. Liever geen cijfers dan cijfers die liegen.

[Croga]

Hydra schreef op woensdag 6 maart 2019 @ 15:22:
Belangrijkste kernpunt wat mij betreft. Zo gauw je het naar buiten gaat communiceren (in demo's of op een dashboard ofzo) ontstaat er druk en door die druk gaan mensen de boel flessen. En dan is meteen je hele waarde weg. En omdat dit in eigenlijk elk project tot nu toe wel gebeurd is, ben ik zelf dus een voorstander van er helemaal niet meer aan doen. Liever geen cijfers dan cijfers die liegen.

Je zou kunnen gaan voor de #NoEstimates evolutie; de enige "velocity" is aantal stories, de enige inschatting is "Zijn ze allemaal ongeveer even groot".

Naar mijn mening (en die van Jeff en Ken) is het de verantwoordelijkheid van de Scrum Master om te zorgen dat er geen externe druk ontstaat. Niet op basis van de velocity, noch op basis van willekeurig welke andere zaak. De Scrum Master moet zorgen dat de organisatie begrijpt hoe het team werkt en waarom. En tot nu toe is me dat nog altijd redelijk gelukt.

[Standeman]

Croga schreef op woensdag 6 maart 2019 @ 15:35:
[...]
...

Naar mijn mening (en die van Jeff en Ken) is het de verantwoordelijkheid van de Scrum Master om te zorgen dat er geen externe druk ontstaat. Niet op basis van de velocity, noch op basis van willekeurig welke andere zaak. De Scrum Master moet zorgen dat de organisatie begrijpt hoe het team werkt en waarom. En tot nu toe is me dat nog altijd redelijk gelukt.

Dat klopt als een zwerende vinger. De grootste uitdaging zit vaak niet in het team, maar in de organisatie er om heen. Nee zeggen en het ook nog kunnen verkopen.