Van watervalmodel naar contracten op basis van duur en prijs (met Tucker Sauer-Pivonka van Crema)

Lees het transcript:

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

Ben Aston:

Welkom bij de DPM-podcast, waarin we verder gaan dan theorie en advies geven dat werkt om betere digitale projecten te leiden. Bedankt voor het luisteren. Ik ben Ben Aston, oprichter van The Digital Project Manager. Projecten verlopen zelden volgens plan en wanneer plannen veranderen, zorgt dat vaak voor veel stress. Er moeten beslissingen worden genomen, vergaderingen worden gepland, plannen worden bijgewerkt, ramingen worden herberekend en meestal worden wijzigingsverzoeken ingediend. Maar wat als er een andere manier was om veranderingen in je projecten te beheren? In deze podcast lichten we een andere aanpak toe voor het beheren van veranderingen met agile contracten. Blijf dus luisteren om te begrijpen hoe agile contracten voor jou kunnen werken en wat de voordelen en uitdagingen van deze aanpak zijn.

Vandaag praat ik met Tucker Sauer-Pivonka. Hij is directeur productmanagement bij een bureau en helpt productmanagers groeien en zich ontwikkelen. Daarnaast is hij verantwoordelijk voor het verder ontwikkelen van hun best practices. Hallo, Tucker.

Tucker Sauer-Pivonka:

Hallo Ben, fijn om vandaag van je te horen.

Ben Aston:

Ja, jij ook. Een van de dingen die ik je aan het begin wilde vragen: ik weet dat een deel van je rol bestaat uit de ontwikkeling van het team. Kun je iets vertellen over wat volgens jou echt heeft gewerkt om je team te helpen ontwikkelen en groeien? Misschien ook over de contracten waarmee je werkt of experimenteert. Hoe begeleid je het team en help je mensen groeien? Wat werkt voor jou?

Tucker Sauer-Pivonka:

Ik denk dat je al vroeg moet erkennen dat iedereen op een iets andere manier leert en verschillende vormen van coaching nodig heeft. Een van de eerste dingen die ik met teamleden doe, is daarom met hen gaan zitten en dat onderzoeken. Hoe leren ze? Hoe ontvangen ze graag feedback? Hoe ontvangen ze graag complimenten? Ik houd dat allemaal bij, zodat ik mijn aanpak kan afstemmen op wat voor ieder van hen het beste werkt. Ik besteed veel tijd aan onze individuele gesprekken en bespreek verschillende onderwerpen en ontwikkelgebieden. Eigenlijk coach ik hen bij alles waar ze op dat moment moeite mee hebben. Die zaken dienen zich vanzelf aan en dan pakken we ze op. Daarnaast hebben we momenteel bij Crema een boekenstudie rond een boek met de titel Multipliers.

Dat is een belangrijk onderdeel van de groei van ons team. En natuurlijk zijn er ook conferenties. We gaan volgens mij eind september naar een conferentie over productmanagement. We gaan daar als team naartoe, niet alleen voor teambuilding, maar ook om nieuwe onderwerpen te leren kennen.

Ben Aston:

Leuk. Weet je hoe die conferentie heet?

Tucker Sauer-Pivonka:

Industry: The Product Conference. Die wordt volgens mij gehouden in Cincinnati.

Ben Aston:

Een feestje in Cincinnati als je je bij Tucker en het team wilt aansluiten. Je zei dat jullie als team allerlei onderwerpen behandelen. Kun je misschien enkele onderwerpen of gebieden noemen waarmee je het team helpt? Met welke uitdagingen heeft het team te maken die jij helpt overwinnen?

Tucker Sauer-Pivonka:

Dat ziet er opnieuw voor iedereen anders uit, omdat de mensen in ons team verschillende vaardigheidsniveaus hebben. Een groot deel van wat we in groepsverband doen, draait om klantmanagement. Bijvoorbeeld: “Mijn klant zei dit, of mijn klant vraagt ons om dat te doen, maar we hebben het daar nog niet over gehad. Hoe moet ik hiermee omgaan?”

Klantmanagement is meestal het lastigste om iemand aan te leren. Het wordt daarom meer een gesprek over vragen als: “Dit voelde vreemd. Ik weet niet of dit de juiste manier was om ermee om te gaan. Was dit goed, of moet ik het de volgende keer anders aanpakken?” Zo verlopen onze gesprekken meestal.

Ben Aston:

Dat klopt helemaal. Er zijn zachte vaardigheden rond klantmanagement en teammanagement, toch? Er is nooit één juist antwoord; het hangt altijd van de situatie af. Maar we kunnen ons op die gebieden altijd blijven ontwikkelen. Je noemde dat jullie als team naar een conferentie gaan, wat geweldig lijkt. Ik ben benieuwd waar jij inspiratie opdoet en hoe je op de hoogte blijft van alles wat er gebeurt. Hoe blijf je bij en hoe raak je geïnspireerd?

Tucker Sauer-Pivonka:

Ik blijf geïnspireerd door allerlei verschillende dingen te gebruiken. Een daarvan zijn de boeken die ik lees. Ik lees veel artikelen. Medium is een plek waar ik vaak inspiratie zoek over productmanagement, het leiden van teams en hoe dat eruit zou moeten of kunnen zien. Ik moet mezelf er wel aan herinneren dat Medium een geweldige bron is, maar dat je informatie soms met een korreltje zout moet nemen, omdat iedereen er een artikel kan plaatsen. Dat iemand iets op internet kan publiceren, maakt die persoon nog geen expert. Maar als je die houding aanneemt, kan het je in elk geval context geven voor het omgaan met bepaalde situaties.

Daarnaast lees ik graag Wired. Ik lees meestal de meeste artikelen in elke uitgave. Dat helpt me op de hoogte te blijven van trends buiten de wereld van projectmanagement, vooral van wat er in de technologie als geheel gebeurt.

Ben Aston:

Geweldig. Ben jij iemand die op technologisch gebied vooroploopt? Wat is het nieuwste speeltje dat je hebt gekocht?

Tucker Sauer-Pivonka:

Dat is een goede vraag. Ik wou dat ik je iets heel spannends kon vertellen. Ik zou niet zeggen dat ik helemaal vooroploop. Ik beschouw mezelf als iemand die nieuwe technologie vroeg adopteert, maar niet als een echte pionier. Ik probeer meestal nieuwe producten te kopen wanneer ze uitkomen, als dat kan. Op dit moment kijk ik verlangend naar een nieuwe iPad. Ik heb een iPad Pro, die prima werkt, maar ik wil de nieuwe versie en ik kan dat gewoon niet rechtvaardigen. Dat is het mooie aan Apple-producten: ze werken nog steeds prima, dus ik hoef ze niet echt te vervangen.

De nieuwste versie van iOS en iPadOS en alles wat tijdens WWDC werd aangekondigd, vond ik erg interessant. Ik denk daarom veel na over de impact die dit op de sector als geheel kan hebben, en misschien zelfs op sommige producten die ik maak. Dat is momenteel het belangrijkste waar ik naar kijk. Daarnaast ben ik een beetje een Zelda-nerd en is het vervolg op Breath of the Wild aangekondigd, dus daar ben ik ook enthousiast over.

Ben Aston:

Leuk. Ik kijk momenteel naar de DJI Rover. Ik weet niet eens zeker of het een Rover heet, maar het is dat kleine cameraatje op een soort tank die je zelf bouwt. Het ziet er geweldig uit. Dat staat op mijn boodschappenlijstje als volgende aankoop.

Tucker Sauer-Pivonka:

Dat klinkt leuk.

Ben Aston:

Ja, het is weer zoiets: heb ik dit echt nodig? Waarschijnlijk niet. Maar de kinderen zullen het leuk vinden. Je zei dat je dol bent op je iPad Pro. Is er op het gebied van hardware of software nog iets dat je onlangs hebt ontdekt en dat je leven beter maakt, waar iedereen van zou moeten weten?

Tucker Sauer-Pivonka:

Ik heb door de jaren heen moeite gehad om een balans te vinden tussen handgeschreven notities, getypte notities en het bijhouden van taken. Er is veel informatie die zegt dat je iets anders verwerkt wanneer je het opschrijft dan wanneer je het typt, en dat vind ik interessant. Een tijdlang maakte ik notities op mijn iPad met de Apple Pencil. Dat werkte redelijk goed, maar onlangs ben ik naar iets in het midden verschoven.

Ik draag nu ook een klein notitieboekje bij me waarin ik mijn dagelijkse notities maak en taken opschrijf zodra ze opkomen. Aan het einde van de dag zet ik die zaken over in Todoist om mijn taken bij te houden. Ook verwerk ik mijn notities dan verder.

Dat is de grootste verandering in mijn werkproces geweest en het helpt echt. Ik merk dat ik beter begrijp waarmee ik bezig ben. Tegelijkertijd kan ik mijn taken beter bijhouden, zodat ik er niet onmiddellijk inspring. Ook vanuit het oogpunt van tijdmanagement helpt het enorm.

Ben Aston:

Interessant. Je gebruikt dus een fysiek notitieboek om notities te maken. Daar ben je voor notities en herinneringen weer naar analoog teruggegaan?

Tucker Sauer-Pivonka:

Ja, maar uiteindelijk komt alles in een digitale omgeving terecht. Voor mij kan niets op tegen het openen van een notitieboek, het klikken van je pen en gewoon beginnen met schrijven. Mijn grootste probleem met notities maken op een iPad met een Apple Pencil is dat er tijd zit in het openen van de juiste app, het zoeken van het juiste notitieboek en controleren of je Apple Pencil is opgeladen. Dat lijken kleine dingen, maar ze vormen uiteindelijk barrières om gewoon een notitie te schrijven.

Ik merkte dat ik mijn iPad en een miljoen plakbriefjes bij me droeg. Als ik iets snel moest opschrijven, gebruikte ik een plakbriefje. Dat was niet duurzaam en het voelde onzinnig om al die briefjes mee te nemen. Daarom ben ik weer een notitieboek gaan gebruiken.

Ben Aston:

Interessant. Dat is ook een strijd waar ik mee te maken heb. Mijn huidige aanpak is Evernote. Ik heb één notitieboek voor mijn takenlijst en een ander dat ik een kladblok noem. Dat is een plek waar alles ongeordend terechtkomt. Als ik mijn takenlijst netjes en overzichtelijk wil houden, maakte ik die steeds opnieuw rommelig.

Met dat kladblok kan alle ruwe informatie ergens terecht en zet ik die later over naar mijn takenlijst. Het klinkt als een vergelijkbaar systeem. Ik heb ook een heel klein notitieblok waarin ik geen volledige notities kan maken, alleen herinneringen. Daardoor word ik gedwongen mijn systeem te gebruiken. Anders zou ik op verschillende plaatsen verschillende lijsten aanmaken en zou het een grote chaos worden.

Maar laten we het over het artikel hebben. Dit was een casestudy die je voor ons hebt geschreven. Het gaat over de overstap van contracten in watervalstijl naar contracten op basis van duur en prijs. We hebben het eerder over agile contracten gehad. In de DPM-school vroeg iemand deze week om een voorbeeld van een agile contract. Ik stuurde hem de link naar een geweldig artikel van Alexa over agile contracten. Kun je voor mensen die niet bekend zijn met agile contracten kort uitleggen wat een contract op basis van duur en prijs is en hoe het werkt?

Tucker Sauer-Pivonka:

Ik leg uit hoe wij dit bij Crema toepassen. Dat betekent niet dat iedereen exact dezelfde formule moet gebruiken, maar dit is waar ik het meest vertrouwd mee ben. Een contract op basis van duur en prijs draait in essentie om een project rond een toegewijd team. Dat kan bijvoorbeeld bestaan uit twee fulltime ontwikkelaars, een testengineer voor de helft van de tijd, een ontwerper voor een kwart of de helft van de tijd, een productmanager en misschien een strateeg, ieder voor een kwart van de tijd.

De focus ligt dus meer op het team en de doelen waar je naartoe werkt dan op een lijst met exacte opleveringen en functies met daarnaast precieze urenramingen. Software is te complex om alles vooraf te ramen en ervan uit te gaan dat alles precies volgens plan verloopt. Dat gebeurt simpelweg nooit.

Met deze contracten kunnen wij en onze klanten ons richten op het werk met de hoogste prioriteit. Aan het einde van de looptijd, en ook tijdens de iteratieve cycli, leveren we zo de hoogste waarde voor het bedrijf. Bij een contract met een vaste scope kunnen prioriteiten in de loop van de tijd veranderen. Als een contract bijvoorbeeld zes maanden duurt, kun je aan het einde functies hebben opgeleverd die niet langer relevant zijn. Met deze aanpak kunnen we de richting aanpassen aan wat de klant nodig heeft.

Ben Aston:

Je hebt verteld voor welke projecten agile contracten geschikt zijn, zoals software- en productontwikkeling, waarbij flexibiliteit om tijdens het project bij te sturen belangrijk is. Zijn er projecten geweest waarbij je dit probeerde, maar waarbij een agile contract op basis van duur en prijs niet goed werkte?

Tucker Sauer-Pivonka:

Je moet het soort werk evalueren. Dit werkt voor ons omdat we producten ontwikkelen waarvan het moeilijk is om elk detail vooraf vast te leggen en het risico nauwkeurig te berekenen. Als iets herhaalbaar is, bijvoorbeeld standaardwebsites met een vast aantal pagina’s en een vast ontwerp, kan een contract met een vaste prijs of scope logischer zijn. Het gaat uiteindelijk om voorspelbaarheid versus onvoorspelbaarheid.

Ben Aston:

Er ontstaat ook steeds meer discussie over waardegestuurde prijsstelling. Dat verschilt duidelijk van prijsstelling op basis van duur en prijs. Bij waardegestuurde prijsstelling verkoop je de waarde in plaats van de uren. Hoe verhoudt dat zich tot eerlijke contracten op basis van duur en prijs, waarbij je betaalt voor de inzet van een team? En wat betekent dit voor de winstgevendheid?

Tucker Sauer-Pivonka:

Het zijn in wezen twee verschillende dingen. Bij softwareontwikkeling volgens een model op basis van duur en prijs weet je niet noodzakelijk wat het uiteindelijke resultaat zal zijn. Omdat het resultaat niet voorspelbaar is, is het moeilijk om er vooraf een prijskaartje aan te hangen. Waardegestuurde prijsstelling werkt goed wanneer je kunt zeggen dat je iets oplevert dat een bepaalde waarde voor het bedrijf creëert, bijvoorbeeld een ontwerpsprint. Bij een groot product is dat moeilijker.

Wat winstgevendheid betreft, zit die bij contracten op basis van duur en prijs ingebouwd in de aanpak. De klant koopt een bepaalde teamcapaciteit gedurende een bepaalde periode. Je werkt niet met een exacte urenraming per functie. Je levert sprint na sprint waarde. Je kunt niet echt onder of boven het aantal uren uitkomen, omdat het contract niet op die manier is ingericht.

Ben Aston:

Koopt de klant dus een team voor een bepaalde periode? Wat doe je als de klant na een paar sprints zegt dat hij niet genoeg waarde ziet?

Tucker Sauer-Pivonka:

Dat gebeurt niet vaak, omdat we hard werken aan afstemming met onze klanten. Niet alleen tijdens de start van elke sprint, maar ook gedurende de sprint houden we hen op de hoogte van veranderingen. Goede communicatie en klantmanagement zijn hierin cruciaal.

We zeggen eerlijk: “We dachten dat dit twee sprints zou duren, maar door wat we hebben ontdekt, worden het er waarschijnlijk drie of vier. Dit is wat we hebben gevonden en daarom denken we dat het langer duurt. We kunnen doorgaan, of we kunnen iets anders oppakken.” Door alle feiten op tafel te leggen, kunnen klanten betere beslissingen nemen en wordt de emotionele lading kleiner.

Voor elke sprint stemmen we af wat erin wordt opgenomen. We zorgen dat het team zich comfortabel voelt bij wat het belooft. Aan het einde demonstreren we wat er is opgeleverd. Als er werk is doorgeschoven, bespreken we waarom en zorgen we dat de klant het begrijpt.

Ben Aston:

In de casestudy wist je dat er minstens zeven maanden werk nodig zou zijn. Hoe kwam je tot die schatting als je nog niet precies wist wat je zou bouwen?

Tucker Sauer-Pivonka:

In dit geval, en in de meeste projecten, gebeurde dat na een vorm van prototyping of testen. Dat was een traject van ongeveer zes weken, inclusief een technische audit van het bestaande systeem. Zo kregen we inzicht in de tijd die nodig zou zijn om de doelen te bereiken.

Na de prototype- en testfase ging het productieteam zitten. We probeerden niet elk afzonderlijk verhaal vooraf te definiëren, omdat dat niet nuttig zou zijn. We keken naar de doelen, verdeelden het product in verschillende onderdelen, beoordeelden de complexiteit en gaven die onderdelen globale T-shirtmaten. Daarna bepaalden we de teamsamenstelling: hoeveel ontwikkelaars, hoeveel inzet van een testengineer en dergelijke.

De looptijd draaide niet om een lijst met opleveringen, maar om de bedrijfsdoelen. We wisten dat er voldoende werk was voor zeven maanden en dat het team binnen die periode gefocust kon blijven. Software is nooit echt af; er komen altijd nieuwe zaken bij. We wilden daarom minimaal zeven maanden reserveren om te bouwen wat de klant nodig had en vervolgens elke sprint opnieuw de hoogste prioriteit bepalen.

Ben Aston:

Kun je ook een contract voor slechts drie maanden afsluiten?

Tucker Sauer-Pivonka:

Zeker. Dan zorgen we ervoor dat we binnen die drie maanden aan het werk met de hoogste prioriteit werken. Je kunt het zien alsof je een team huurt. Je krijgt wat dat team in drie maanden, zes maanden, een jaar of twee jaar kan produceren. De duur bepaal je samen.

Ben Aston:

Je noemde een traject rond prototyping en validatie. Was dat een vaste prijs en hoe duidelijk waren de opleveringen na zes weken?

Tucker Sauer-Pivonka:

Technisch gezien valt het nog steeds onder ons model op basis van duur en prijs, maar het lijkt wat meer op een vaste prijs. We spreken bepaalde opleveringen af: een prototype met hoge getrouwheid, de schetsbestanden, gebruikersinterviews, notities en bijbehorend onderzoek.

Als we na drie weken ontdekken dat wat we bouwen niet is wat gebruikers willen, kunnen we terug naar de tekentafel. We zijn niet gebonden aan een exact aantal schermen of een vast ontwerp. Ook dit blijft gebaseerd op duur en prijs.

Ben Aston:

Na zes weken heb je een prototype en feedback uit gebruikerstests. Vervolgens zeg je dat het ongeveer zeven maanden werk is. Hoe kwam je tot het bedrag van een half miljoen tot een miljoen?

Tucker Sauer-Pivonka:

We maakten globale T-shirtinschattingen van de complexiteit, ontwikkelden een technisch plan en bouwden daarmee een mogelijke routekaart. We waren duidelijk dat die routekaart kon en zou veranderen. De technische mensen, de strateeg en ikzelf werkten samen om te bepalen hoe lang onderdelen ongeveer zouden duren. Zo kwamen we uit op zeven maanden.

We maakten duidelijk dat de klant de looptijd kon aanpassen. Als drie maanden beter paste, konden we daarmee beginnen. We waren voldoende afgestemd op de klant om te weten wat zij als minimaal levensvatbaar product beschouwden en konden de routekaart daarop afstemmen.

Ben Aston:

Hoe wijkt jullie aanpak af van Scrum? Welke onderdelen gebruik je wel en welke laat je achter?

Tucker Sauer-Pivonka:

Bij ons staan mensen boven processen. We beoefenen Scrum met een kleine s. Dat betekent dat er voldoende flexibiliteit is zodat mensen niet door het proces worden beperkt. Als een team het proces moet aanpassen om beter met een klant te kunnen werken, heeft het daar volledige autonomie voor.

In een bureauomgeving is het moeilijker om voor elke rol een toegewijd persoon te hebben. De dagelijkse klantcontactpersoon vervult meestal de rol van producteigenaar. Als er een strateeg bij het project betrokken is, kan die persoon als mede-producteigenaar optreden en de klant helpen bij strategische beslissingen.

De productmanager en Scrum Master combineren we in één rol. Dat wijkt af van de traditionele Scrum-aanpak, maar het werkt voor ons. We organiseren de ceremonies, geautomatiseerde stand-ups en dagelijkse controles en verwijderen blokkades. Omdat we alle context hebben, kunnen we ook betere beslissingen rond productmanagement nemen.

De rest lijkt grotendeels op Scrum: sprintplanning, schattingen, retrospectives en productdemo’s. Meestal combineren we die in een bijeenkomst die we een woensdagse kick-off noemen.

Ben Aston:

Hoe beheer je conflicterende prioriteiten wanneer een oud systeem moet blijven werken terwijl je aan iets nieuws bouwt?

Tucker Sauer-Pivonka:

Begin met empathie. Meestal wil de klant de prioriteiten niet veranderen; hij wil dat je het oorspronkelijke werk oplevert. Begrijp daarom eerst waarom de prioriteit verandert. Is het echt dringend? Is het een kwestie van een stakeholder tevredenstellen? Geen van die antwoorden is per definitie verkeerd, maar de reden bepaalt hoe je communiceert.

Leg vervolgens heel duidelijk uit dat een verschuiving de planning volledig verandert. Als het team van een bestaande functie naar een nieuwe dringende functie gaat, betekent dat dat het oorspronkelijke werk later wordt afgerond. Dat is prima, zolang iedereen begrijpt wat de consequenties zijn.

Gebruik daarnaast visuele hulpmiddelen in de tools die je gebruikt, zoals Jira. Klanten begrijpen soms beter wat er gebeurt wanneer ze het gevisualiseerd zien.

Ben Aston:

Krijgen klanten toegang tot Jira?

Tucker Sauer-Pivonka:

We werken volledig transparant. Klanten krijgen toegang tot onze tools en worden als gasten toegevoegd aan ons Slack-team. Ze werken ook in Jira mee om prioriteiten, vereisten en de gekozen richting te controleren.

Ben Aston:

Hoe voorkom je dat klanten overweldigd raken door alle informatie in Jira, zoals de backlog en het werk in uitvoering?

Tucker Sauer-Pivonka:

We verwachten niet dat klanten voortdurend in de tools werken; we zorgen alleen dat ze toegang hebben als ze dat willen. We maken persoonlijke schermopnames waarin we uitleggen hoe de tool werkt, waar ze iets kunnen vinden en welke onderdelen ze kunnen negeren. Daarnaast houden we de deur open voor vragen.

We leveren informatie iteratief en verspreid aan, zodat niet alles tegelijk bij de klant terechtkomt. Bij grote producten kan het aantal schermen anders overweldigend worden. Door het werk geleidelijk aan te leveren, blijft het beheersbaar.

Ben Aston:

Rapporteren jullie over bestede tijd en urenstaten?

Tucker Sauer-Pivonka:

We rapporteren vooral over resultaten. Elke sprint bespreken we wat is afgerond, wat eventueel niet is afgerond en wat onze snelheid was. We rapporteren niet per uur of per functie, omdat de klant een teamcapaciteit koopt.

We gebruiken de rapportage wel om te controleren of onze inzet klopt. Als iemand voor de helft van de tijd op een project zit maar structureel meer tijd nodig heeft, bespreken we of de inzet moet worden verhoogd of dat er werk moet worden verwijderd. Meestal zijn de afspraken redelijk nauwkeurig.

Ben Aston:

Wanneer werken contracten op basis van duur en prijs niet? Is het ooit volledig misgegaan?

Tucker Sauer-Pivonka:

Zaken kunnen zeker misgaan, bijvoorbeeld wanneer een klant teleurgesteld is over de voortgang. Zodra je signalen daarvan opmerkt, moet je het gesprek aangaan: “Ik heb het gevoel dat we niet helemaal op één lijn zitten. Kunnen we dit bespreken?” Wacht niet tot het einde, want dan is het vertrouwen vaak moeilijker te herstellen.

Een keer waren we bezig met een verlenging en was de klant teleurgesteld over de voortgang. We onderzochten dat samen en ontdekten dat we door een veranderde prioriteit twee maanden aan ander werk hadden besteed. Dat werk was belangrijk voor de bedrijfsvoering, maar het betekende wel dat het oorspronkelijke werk twee maanden achterliep. Door dit uit te leggen, begreep de klant de situatie.

Als een klant niet bereid is zich met je af te stemmen, kan het zijn dat jullie geen goede match zijn. Dat is ook toegestaan. We proberen dit al vroeg in het verkoopproces te ontdekken.

Ben Aston:

Een belangrijke les uit jouw verhaal is dat je het juiste type klant nodig hebt. Deze aanpak vraagt om volwassenheid van de klant: begrijpen dat werk tijd kost en dat veranderende prioriteiten gevolgen hebben voor planning en kosten. Een groot deel van het succes zit daarom in het verkoopproces, het opleiden van de klant tijdens prototyping en validatie en het managen van verwachtingen.

Het resultaat is dat de klant gedurende het hele traject waarde ontvangt op basis van zijn prioriteiten. Daardoor krijgt de klant uiteindelijk een beter resultaat dan wanneer een bureau onder tijdsdruk snelkoppelingen neemt of prioriteiten kiest om binnen budget of planning te blijven.

Contracten op basis van duur en prijs zijn dus zeker een interessant concept. Bedankt dat je vandaag bij ons was, Tucker.

Tucker Sauer-Pivonka:

Graag gedaan. Dit was een geweldig gesprek. Bedankt voor de uitnodiging.

Ben Aston:

Wat vind jij ervan? Heb je ooit een agile contract geprobeerd? Ik hoor graag hoe dat is gegaan. Laat weten wat je ervan vindt in de reacties en ga naar TheDigitalProjectManager.com om lid te worden van ons Slack-team. Daar vind je allerlei interessante gesprekken over projectoplevering. We hebben ook een agile-kanaal waarin we dit kunnen bespreken.

Als je hebt genoten van deze aflevering, abonneer je dan en neem een paar minuten de tijd om een eerlijke beoordeling achter te laten voor de DPM-podcast op Apple Podcasts. Beoordelingen en recensies helpen ons enorm en worden zeer gewaardeerd. Tot de volgende keer en bedankt voor het luisteren.