Je Bekijkt Mijlpalen Misschien Helemaal Verkeerd (met John Carter van TCGen)

Lees het transcript:

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

Galen Low

Daar zit je dan weer naar je projectplan te staren, terwijl je opziet tegen de mijlpalen die je zelf hebt helpen creëren. Elke keer dat je ernaar kijkt, lijken ze dichterbij te komen, net als ruitvormige Space Invaders. In het begin leken ze zo onschuldig: het waren slechts lijnen in het zand om je te helpen plannen op hoofdlijnen. Nu zijn ze een last om je nek: zware, onverplaatsbare deadlines waar niet mee te onderhandelen valt. Het zijn de fluisteringen van twijfel die je dreigen mee te slepen naar een drakenhol vol boze belanghebbenden wanneer de noodlottige dag aanbreekt. Als dit bekend klinkt, moet ik je helaas vertellen dat je een van die projectmanagers bent die projectmijlpalen volledig verkeerd gebruikt. Maak je geen zorgen, de meesten van ons zitten in hetzelfde schuitje. Maar als je je projectmijlpalen wilt veranderen van een angstaanjagende last in een Poolster voor samenwerking tussen team en belanghebbenden, blijf dan luisteren.

Bedankt dat je luistert. Mijn naam is Galen Low van de Digital Project Manager. Wij zijn een community van digitale professionals met als missie elkaar te helpen vaardiger, zelfverzekerder en beter verbonden te worden, zodat we projecten beter kunnen opleveren. Als je daar meer over wilt horen, ga dan naar thedigitalprojectmanager.com.

Goed dan. Hé allemaal, bedankt dat jullie bij ons zijn voor de DPM-podcast. Mijn gast vandaag is een alom gerespecteerde expert op het gebied van productontwikkeling en ook zeker geen onbekende in projectmanagement. Hij is een van de belangrijkste denkers achter de hoofdtelefoons met ruisonderdrukking van Bose en achter het proces van Apple voor de ontwikkeling van nieuwe producten. Tegenwoordig adviseert zijn bedrijf, TCGen, toonaangevende merken zoals Amazon, Apple, Cisco, Hewlett-Packard, IBM, Mozilla, Roche en 3M. Hij heeft onlangs ook een tutor ingehuurd om muziektheorie te leren en componeert nu muziek. Dames en heren, verwelkom alstublieft meneer John Carter. Hallo John.

John Carter

Hallo Galen. Fijn om hier te zijn.

Galen Low

Geweldig dat je er bent. Ik waardeer het echt. John, je cv. Toen ik het bekeek, dacht ik: iedereen is waarschijnlijk jaloers op dat cv. We hebben het over productinnovatie voor Bose, samenwerken met Apple, nu je eigen bedrijf runnen en boeken schrijven. Dus ik dacht: laat ik beginnen met de vraag wat je wilde worden toen je opgroeide.

John Carter

Dat is een grappige vraag. En eigenlijk doe ik het nog steeds in mijn vrije tijd: ingenieur zijn. Ik heb altijd dingen willen ontwerpen, berekeningen willen maken en prestaties willen voorspellen. Dat heeft me tot op de dag van vandaag gedreven. Het drijft me nog steeds.

Galen Low

Daar hou ik van! Was dat een grote inspiratie om je meer op de kant van innovatie te richten? Ik kan me voorstellen dat een technische mindset zich goed leent voor het creëren van nieuwe dingen die levensvatbaar en haalbaar zijn en die mensen daadwerkelijk zullen gebruiken.

John Carter

Nou, ik weet niet zeker of het in het begin zo doordacht was, maar ik was de prototypische jongen-wetenschapper. Ik had een scheikundeset, een microscoop en een telescoop. Ik haalde mijn zendamateurrijbewijs. Ik deed gewoon al die nerdy dingen. Ik hield zo ontzettend van wat ik deed. En ik denk dat het verband houdt met wat ik nu graag doe: ik hield van elektronica en van het feit dat je elektriciteit of elektronen niet kon zien, maar ze wel kon meten en er iets mee kon doen. Tegenwoordig kun je hetzelfde doen met geluid. Je kunt het niet zien, maar het heeft enorme invloed op hoe je je voelt en denkt enzovoort. Ik heb er dus altijd van genoten om verschijnselen te proberen begrijpen die je niet kunt zien.

Galen Low

Kijk aan. Was er een inspirerend moment waarop je besloot: weet je wat, laten we dit uit de technische context halen en meer richten op technologie, de digitale wereld of producten?

John Carter

In zekere zin ontstond dat vanzelf uit mijn werk met dr. Bose bij de Bose Corporation, waar ik begon. Hij was fenomenaal in zowel marketing als techniek tegelijk — dat is een zeer ongebruikelijke combinatie. Hij stelde basisvragen over wat mensen belangrijk vinden, wat ze zouden willen doen en wat voor hen van belang is. Door zijn benadering van leven en werken begreep ik echt hoe belangrijk het is om de behoeften van je klanten te begrijpen en ervoor te zorgen dat je levert wat voor hen werkelijk belangrijk is. We leerden dat op allerlei manieren. Zelfs als uitvinder hadden we pas echt een idee van wat klanten waardeerden nadat we het product in hun handen hadden gelegd. Ik denk dus dat ik via dr. Bose en zijn enorme marktinzicht geleidelijk de overstap heb gemaakt van techniek naar innovatie.

Galen Low

Dat is geweldig. Ik vind het prachtig. En je hebt zoveel gedaan in je carrière; is er tegenwoordig iets waarin je beter probeert te worden?

John Carter

Altijd, altijd. Er zijn een paar dingen. Een ervan die ik bijzonder interessant vind, is het snijvlak van Agile en projectmanagement. Dat vind ik fascinerend. Het andere is wat ik de gevolgen van digitale productontwikkeling zou noemen. Hoe is het om aan machinaal leren te werken in plaats van aan traditionele productontwikkeling? Hoe innoveer je in zo'n digitale omgeving en in deze nieuwe wereld van werken op afstand? Het is fascinerend wat er allemaal gebeurt. Ik probeer dus echt te begrijpen wat de voorhoede van innovatie vooruitduwt.

Galen Low

Geweldig. Daar hou ik van.

Ik wilde ook vragen: heb je onlangs nog iets ontdekt dat je leven echt beter maakt?

John Carter

Weet je, een van de dingen die mijn vertrouwen in de mensheid echt heeft vernieuwd, is het vermogen om voortdurend te blijven innoveren. Als je kijkt naar de huidige problemen waarmee we worden geconfronteerd en naar het feit dat de wereld heeft moeten omschakelen naar zaken als werken op afstand, onderwijs en de ontwikkeling en levering van medicijnen, dan zie je positieve veranderingen die uit deze crisis voortkomen. Dat versterkt mijn vertrouwen in ons vermogen om elke situatie waarmee we worden geconfronteerd te overtreffen door innovatie. Dat geeft me veel hoop.

Galen Low

Ik vind die positieve kant van een verder misschien suboptimale situatie voor ons dit jaar geweldig. Mooi. Ik dacht dat we misschien konden praten over je recente artikel op Thedigitalprojectmanager.com over projectmijlpalen. Ten eerste gaf het me het gevoel dat ik projectmijlpalen altijd volledig verkeerd had aangepakt. Ten tweede zette het me echt aan het denken over het verband tussen projectmijlpalen en het slagen of mislukken van een product op de markt — een manier waarop ik nog nooit echt naar het probleem had gekeken. Maar misschien moeten we helemaal teruggaan naar het begin. Wat zijn projectmijlpalen volgens jou en waarom zou iemand zich er druk om maken?

John Carter

Dat is een geweldige vraag en een geweldige plek om te beginnen, want ik denk dat de opvattingen van mensen over mijlpalen verkeerd zijn als het gaat om digitaal projectmanagement. De fout is dat mijlpalen geen manier zijn om voortgang te meten. Er zijn veel betere manieren om voortgang te meten die het team niet uitputten, geen enorme hoeveelheden irrelevante rapporten opleveren en geen micromanagement veroorzaken doordat mensen zich ineens bewust worden van nog meer zaken. De gebruikelijke misvatting is dat je mijlpalen gebruikt om voortgang bij te houden. Maar als je naar mijlpalen kijkt, zijn het eigenlijk kantelpunten in het project: kritieke periodes of beslismomenten in het leven van een project waarop je meer gaat investeren, meer risico neemt of afspraken maakt met partners. Dat zijn momenten waarop het waarschijnlijk wel de moeite waard is om je huiswerk te doen. Daarnaast zijn er in de complexe, onderling verbonden digitale wereld waarin we leven veel afhankelijkheden tussen projectkenmerken. Mijlpalen zijn een geweldige manier om afhankelijkheden op elkaar af te stemmen. Je kunt twee teams hebben die allebei op een agile manier werken, maar er kan een moment komen waarop het werk van het ene team de output van het andere nodig heeft. Mijlpalen zijn een geweldige manier om dat soort activiteiten te coördineren.

Galen Low

Dat vind ik mooi. Als je daarover nadenkt: je noemde enkele veelvoorkomende misvattingen over mijlpalen, zoals je vastbijten in tracking en rapportage. Welke gevolgen heeft dat voor een project als je mijlpalen op die manier benadert in plaats van te kijken naar afhankelijkheden tussen teams?

John Carter

Dat heeft zoveel gevolgen. Om te beginnen ondermijnt het het vertrouwen dat het management in het team heeft. Als projecten vol zitten met controles, managementbeoordelingen en mijlpaalbeoordelingen, kijkt het team voortdurend over zijn schouder om te zien wat het management denkt.

Dat is een schadelijke houding, omdat het het zelfvertrouwen van het team en het vermogen om op eigen initiatief een uitstekend project op te leveren niet versterkt.

Bovendien is het een belasting voor het team, omdat je voortdurend rapporten, saaie grafieken en updates produceert die vluchtig worden bekeken, niet worden gelezen of slechts kort worden doorgenomen. Wat is daar het nut van? Is het om een beslissing te nemen? Is het om te communiceren? Als het om communicatie gaat, kun je projectdashboards, achterstanden of allerlei andere manieren gebruiken om voortgang te communiceren. Als het om beslissingen gaat, wat moet er dan echt buiten het team worden gelegd? Daarvoor heb je een grote mijlpaal nodig. En die komen maar zelden voor. Het idee is dus om de frequentie en het aantal van deze beoordelingen te verminderen en ervoor te zorgen dat ze waarde toevoegen voor het team.

Dat is echt belangrijk bij de manier waarop je effectieve mijlpalen invoert.

Galen Low

Dat vind ik goed. Het gaat er meer om het werk te doen dan te pauzeren om het te beoordelen of erover te rapporteren.

John Carter

Precies. En vervolgens krijg je de ongelukkige neiging van het management om zogenaamd waarde toe te voegen en een hoop lege calorieën op het team af te schuiven. Het team moet die energie vervolgens besteden aan het maken van nog meer rapporten zodat iemand meer kan zien. Het is een eindeloze hoeveelheid management dat obstakels op het pad van het team zet, terwijl het management die obstakels juist zou moeten verwijderen en uit de weg zou moeten gaan.

Dat is nog een manier waarop mijlpalen twee kanten op kunnen werken. Te veel mijlpalen moedigen micromanagement aan; het juiste aantal moedigt het juiste soort besluitvorming aan.

Galen Low

Geweldig. Was er een moment waarop je tijdens een project dat je beheerde stopte en dacht: oké, ik pak dit verkeerd aan? Dit zou eigenlijk meer over het team en teamwork moeten gaan dan over rapportage.

John Carter

Ja, dat was kort nadat ik bij Bose tot hoofdingenieur was gepromoveerd. In die situatie had ik de neiging om te micromanagen, meer beoordelingen te organiseren en extra projectmijlpalen in te plannen. Plotseling besefte ik dat ik eraan onderdoor ging, omdat ik niet genoeg tijd in de week kon vinden om al die details en beoordelingen in te plannen. Het tweede was dat het de teams ook niet hielp. Ik verdronk en de teams verdronken. Toen realiseerde ik me — en dat was zo frustrerend — dat sommige teamleiders en technische experts veel meer wisten dan ik. Veel meer. Ik moest gewoon uit de weg gaan. Ik wist niet waar ik het over had. Een ingenieur in de ontwikkelorganisatie zei dat ik alleen maar verstoring, vertraging en ruis veroorzaakte. Dat was waarschijnlijk het moment waarop ik stopte met zoveel mijlpaalbeoordelingen.

Galen Low

En merkte je, toen je stopte, van de ene op de andere dag verschil in de manier waarop het team werkte?

John Carter

Nee, niet echt. Ik denk dat het team geleidelijk productiever werd en dat ik veel gelukkiger werd in mijn werk. Ik ontdekte dat het team het eigenlijk net zo goed, zo niet beter, deed zonder mijn bemoeienis. Wat er volgens mij gebeurt, is dat je de sluier van het team wegneemt, waardoor het productiever, gelukkiger en tevredener wordt en betere producten oplevert.

Galen Low

Ja, het gewicht van wantrouwen is ongelooflijk. Als dingen voortkomen uit wantrouwen, is dat een zware last voor het team, in tegenstelling tot vertrouwen: het werk wordt gedaan, iedereen werkt effectief samen en beheert zichzelf effectief.

John Carter

Ja, het is als een voortdurend bijtende sfeer. Daar ben ik het mee eens.

Galen Low

Laten we het hebben over hoe je dit op de juiste manier aanpakt en hoe het eruitziet als je het goed doet met betrekking tot projectmijlpalen. Je zei dat mijlpalen er meer voor het team zijn dan voor projectmanagers of het management. Hoe leer je een team om het zo te zien als ze het nog niet op die manier bekijken?

John Carter

Dit brengt ons terug bij de omgeving van wantrouwen waar je het over had. Het is cruciaal dat het team een bekwame producteigenaar, een bekwame scrummaster, een bekwame digitale projectmanager en een bekwame technisch leider heeft. Als je die drie dingen hebt, moet het management je en het systeem vertrouwen. Als je competentie in je team hebt, is er geen behoefte aan voortdurend micromanagement. Vervolgens kun je met het team samenwerken zodat het begrijpt: dit zijn de belangrijkste mijlpalen en daarom zijn ze belangrijk. Dat is volgens mij het allerbelangrijkste. Mijlpalen mogen bovendien nooit op een vast interval plaatsvinden.

Je moet dus geen wekelijkse vaste vergaderingen of maandelijkse beoordelingsvergaderingen hebben en niet steeds beoordelingen inplannen. Sommige zijn noodzakelijk, maar over het algemeen niet op detailniveau. Mijlpalen zouden gebeurtenisgestuurd moeten zijn.

Ze worden door het project bepaald. Ze zijn gebaseerd op de snelheid, volwassenheid, omvang, het risico enzovoort van het team, en natuurlijk op de uitdaging en de taak. Het is een duidelijke aanwijzing dat er een probleem is als je mijlpalen op regelmatige kalenderdata vallen.

Galen Low

Dat klinkt bijna als wantrouwen. Alsof ik elke twee weken bij je kom kijken.

John Carter

Precies. Precies.

Galen Low

Om te controleren of alles op de rails staat, in plaats van te zeggen: luister, op dit punt moeten we bekijken waar we staan omdat andere dingen hiervan afhankelijk zijn. Hoe gaan we de volgende stappen plannen of eraan samenwerken?

John Carter

Precies. Of we gaan die cheque met zeven cijfers uitschrijven. Weten we zeker dat we het juiste doen? Absoluut.

Galen Low

Als je het zo stelt, is het inderdaad erg belangrijk.

John Carter

Het kunnen grote cheques zijn.

Galen Low

Zeker. En als het gaat om weten wanneer een team er klaar voor is: ik vind het goed om die rollen te hebben en te weten dat mensen sterk zijn in de rol die ze in het team vervullen. Welk gedrag verwacht je van een team dat klaar is om zijn eigen mijlpalen te beheren en te begrijpen waar ze over gaan?

John Carter

Galen, dit is een geweldige vraag en ik denk dat het antwoord heel eenvoudig is. Namelijk: de geschiedenis. Is dit team in het verleden voorspelbaar geweest? Wijzen hun eerdere successen en prestaties op een positieve uitkomst? Vertrouwen wordt in de loop van de tijd opgebouwd. De beste graadmeter voor elk projectteam is zeker zijn eerdere geschiedenis en succes in programma's. Dat is dus het eerste en belangrijkste wat je nodig hebt. In elk van die sleutelposities heb je bijvoorbeeld iemand nodig die het waarom en het wat begrijpt. Die persoon moet dat echt weten en het team moet hem of haar geloven. Hetzelfde geldt voor de technische leider. In ontwikkeling en kwaliteitsborging moet je vertrouwen hebben in hun vermogen om de juiste architectuurbeslissingen en afwegingen te maken om de projectdoelen te bereiken. Bij de digitale projectmanager moet je erop kunnen vertrouwen dat die transparant is. Wanneer er een probleem is, moet die het snel bekendmaken en niets verbergen.

Dat soort gedrag in deze drie sleutelrollen laat, naast de geschiedenis, zien dat een team er klaar voor is.

Galen Low

Ik vind het geweldig dat het hele concept van teamsamenstelling en strategie voor teambuilding hierbij betrokken is. Je wilt ervaren mensen die het project vanuit een volwassen perspectief benaderen en de context begrijpen van wat ze doen. Misschien worden ze ondersteund door meer junior medewerkers; daar is zeker nog ruimte voor. Maar bedoel je met de juiste mensen ervaren teamleden die het project en het product dat ze creëren op de juiste manier kunnen bekijken, zodat ze begrijpen wat een mijlpaal betekent en kunnen helpen bij het plannen ervan?

John Carter

Absoluut. Juniorrollen kunnen de seniorrollen ruimschoots in aantal overtreffen, maar je hebt ervaring nodig. Ik heb het niet over leeftijd; je hebt gewoon ervaringscycli nodig, zogenaamde leercycli. Als ze er meerdere achter de rug hebben en dat goede ervaringen waren, kun je het team zeker vertrouwen. Absoluut.

Galen Low

Leercycli.

John Carter

Ja.

Galen Low

Dat is geweldig. Mijn andere vraag gaat over de andere kant. Wat doe je als je te maken hebt met een managementteam dat gewend is aan maandelijkse mijlpaalcontroles of aan een dozijn mijlpalen in een zeer korte periode, omdat het zo gewend is om in te checken en te micromanagen?

Hoe krijg je zo'n leiderschaps- of managementteam zover dat het anders gaat denken over mijlpalen, zodat er minder zijn, ze verder uit elkaar liggen en er geen vaste regelmaat is?

John Carter

Dat is een geweldige vraag. Het antwoord is: dat hangt ervan af. Als er in de organisatie een mechanisme bestaat om een of andere vorm van voortgang te meten, of dat nu achterstanden, verhaalpunten of voltooide opleveringen zijn, dan zijn er allerlei eenvoudige objectieve meetwaarden die de voortgang aangeven. Het is belangrijk dat ze lichtgewicht en objectief zijn. Ze kunnen als vervanging worden aangeleverd. Het probleem met managers is volgens mij dat ze transparantie en het monitoren van projectvoortgang verwarren met besluitvorming. Dat zijn twee totaal verschillende communicatievormen. Voortgang bijhouden kan met dashboards of allerlei transparante indicatoren; in het slechtste geval kan het in een vergadering.

Maar dan met slechts één persoon en met een frequentie die door de behoefte wordt bepaald. Managers halen die zaken door elkaar. We moeten hen dus verzekeren dat ze de voortgang transparant kunnen zien en dat ze bericht krijgen als er iets misgaat. Hoewel we in dit artikel niet echt over randvoorwaarden hebben gesproken, bestaat er het idee dat een team grenzen heeft aan wat binnen de afgesproken drempel van de digitale projectontwikkeling valt. Als het team die grenzen niet gaat halen, is het zijn verantwoordelijkheid om het management te informeren. Als het management de voortgang van het team dus transparant kan zien en erop kan vertrouwen dat er een mechanisme is waardoor slecht nieuws snel wordt gemeld, zou dat voldoende moeten zijn. Als het management het team vertrouwt omdat het de geschiedenis kent en deze drie factoren aanwezig zijn, kunnen we een overtuigend argument maken voor minder mijlpalen.

Is dat logisch, Galen?

Galen Low

Absoluut. Ik vind die scheiding tussen rapporteren en volgen enerzijds en besluitvorming anderzijds geweldig. Dat is waar mijlpalen echt over gaan: een moment waarop je zegt: hoe doen we het?

Niet qua voortgang, maar op het punt waarop we de volgende fase ingaan of een ander team toevoegen om met ons samen te werken. Zijn we daar klaar voor? Is dat nog steeds het juiste om te doen?

John Carter

Precies. Zijn zij klaar voor ons?

Het is een goed punt en een controle die waarde toevoegt.

Galen Low

Dat brengt me bij mijn volgende vraag. Als we mijlpalen plannen, verandert jouw perspectief op mijlpalen dan de manier waarop we ze in eerste instantie creëren of ons projectplan ontwikkelen? Of zouden we anders zeggen: we checken elk kwartaal in of we houden een controle omdat we de stuurgroep moeten bijwerken? Verandert het de manier waarop je projecten plant als je mijlpalen ziet als iets voor het project en het team?

John Carter

Zeker. Al die andere statusrapporten, updates voor de stuurgroep enzovoort zouden worden verminderd of afgeschaft. We hebben het over een lichtgewicht raamwerk voor digitale productontwikkeling. Dat raamwerk moet een aantal standaardkantelpunten bevatten die geschikt zijn voor jouw bedrijf. Verschillende organisaties hebben verschillende beperkingen. Als je bijvoorbeeld widgets maakt, moet je voorraad en onderdelen bestellen. Dat is een grote uitgave. Je wilt waarschijnlijk zeker weten dat je de juiste onderdelen hebt gespecificeerd. Dat is belangrijk. Als je een digitaal project wilt opschalen, wil je er ook voor zorgen dat de juiste meetinstrumenten in het product zijn opgenomen. Je wilt de analyses kunnen verzamelen die je team nodig heeft. Het is belangrijk dat die meetinstrumenten klaar zijn wanneer je het product op grote schaal uitrolt. Het hangt dus echt af van je bedrijf. Maar mijlpalen moeten over het algemeen worden gestandaardiseerd. Er moeten er weinig zijn. Ik zeg graag: zo weinig proces als mogelijk, maar niet minder dan dat. Maak het dus lichtgewicht en voeg standaardmijlpalen toe op de punten waarop je bedrijf doorgaans grote beslissingen neemt. Het zou om een klein aantal moeten gaan, bijvoorbeeld drie tot vijf.

Galen Low

Ik vind dat voorbeeld met widgets geweldig. Als je onderdelen moet bestellen, is het logisch dat je vóór je dat doet wilt controleren of je op een punt bent waarop het zinvol is.

John Carter

Absoluut. Bij typische digitale ontwikkelingen heb je cloudactiviteiten, wat er op de client gebeurt en misschien desktoponderdelen. Je hebt veel verschillende systemen die moeten worden geïntegreerd en DevOps die moet worden gecoördineerd. Elk bedrijf is anders.

Galen Low

Een van de dingen die ik fascinerend vond aan je artikel, is dat je sprak over drie belangrijke mijlpalen of kantelpunten tijdens een project die overeenkomen met grote bedrijfsdoelen. Kun je uitleggen wat die zijn en waarom ze belangrijk zijn?

John Carter

De eerste is volgens mij heel belangrijk, vooral als je het hebt over innovatie en over wat Galen en ik ‘innovatie met een hoofdletter I’ noemden: innovaties die spelveranderend zijn. Helemaal aan het begin van je digitale project moet je je afvragen of dit concept echt aansluit bij onze strategie. Past dit bij wie we als merk zijn? Is dit het soort product of idee dat we op de markt willen brengen? Zal dit iets veranderen voor onze omzet of marge? We verbinden ons de komende drie, zes, negen of mogelijk achttien maanden aan deze activiteit, met misschien een groot team. Sluit dit aan bij onze strategie en zal het verschil maken? De eerste stap is dus controleren of het concept klopt.

De tweede belangrijkste stap, ervan uitgaande dat het concept bestaat en op de strategie aansluit, is controleren of je product-marktfit hebt. Heb je iets wat consumenten daadwerkelijk zullen kiezen? Heb je unieke verkoopargumenten die voor consumenten betekenisvol zijn? Heeft het product voldoende aantrekkingskracht op de markt? Kun je andere gebruikers stimuleren, of grotere winkelmandjes creëren, of wat je doel ook is? Heb je bewijs voor je acquisitiekosten? In het digitale tijdperk zijn al deze zaken meetbaar. Deze volgende fase is heel belangrijk, vooral voordat je het team echt opschaalt: zorg ervoor dat je product-marktfit hebt.

De laatste stap is ontwikkeling en marktintroductie. De organisatie zegt dan: het concept sluit aan, het product past bij de markt en consumenten vinden wat we doen echt goed. Wat moeten we ontwikkelen om een complete release, eerst een MVP en daarna een volledige versie, te maken? Welke partners hebben we nodig voor de cloudinfrastructuur? Welke ontwikkelpartners hebben we nodig voor de verschillende mobiele platforms? We doen het desktop- en tabletwerk. Hoe verdelen we dit? We moeten investeren in gebruikersinterface, grafisch ontwerp enzovoort. We moeten dus flink investeren. Gaan we die verplichting aan? Dat is de beslissing om door te gaan met ontwikkeling en marktintroductie.

Dit zijn de drie belangrijkste kantelpunten die de meeste digitale productontwikkelingsprojecten sturen, en ze kunnen natuurlijk worden aangepast. Misschien voeg je vooraan een ideatiefase toe. Misschien heb je aan het einde een explicietere validatiefase. Misschien is er DevOps. Je kunt allerlei extra onderdelen toevoegen. Maar een gemeenschappelijk raamwerk is belangrijk. Wanneer je met leidinggevenden werkt — dit is wat we bij Apple deden bij het ontwikkelen van hun proces voor nieuwe producten — wil je bij groei van een bedrijf enkele standaardmijlpalen hebben, zodat je kunt vergelijken waar projecten staan. Daardoor kunnen leidinggevenden de uitgaven in de loop van de tijd beheren. De standaardmijlpalen en deze belangrijke kantelpunten laten zien waar het project werkelijk staat met betrekking tot klanttoegang en investeringen.

Galen Low

Ik vind het idee van vergelijken tussen projecten geweldig. Als een bedrijf meerdere projecten of producten tegelijk ontwikkelt, moet je naar die pijplijn kijken en zien waar alles staat. Niet wat betreft de gezondheid van het project in termen van voortgang, maar de gezondheid van het productconcept en hoe het product zich ontwikkelt, wanneer het wordt gelanceerd en wanneer het bepaalde middelen nodig heeft.

John Carter

Als je naar deze drie mijlpalen kijkt, Galen, was geen ervan gekoppeld aan een tijdstip.

Galen Low

Mmm-hmm.

John Carter

Ze gingen allemaal over de vraag: sluit dit aan bij de strategie? Goed. Is er product-marktfit? Goed. Willen we echt investeren en geld uitgeven om dit product te lanceren? Goed. Dat zijn drie zeer belangrijke, niet-tijdgebonden elementen in het programma. Als je die drie goed beheert, kan dat voor geen enkele organisatie te belastend zijn.

Galen Low

Zijn deze drie mijlpalen onveranderlijk als je ze in je projectplan hebt opgenomen? Veel mensen zien mijlpalen bij projectplanning als zaken die niet kunnen verschuiven. Hoe kijk jij daartegenaan?

John Carter

Er is een verschil tussen hoop en werkelijkheid. Bij pure agile softwareontwikkeling is het theoretisch mogelijk om geen mijlpaal te missen. In werkelijkheid mis je dan geen mijlpaal, maar verschuif je een sprint. Zelfs bij agile ontwikkeling bestaat er zoiets als ‘volledig functioneel’, wat belangrijk is. Deze mijlpalen zijn dus algemeen toepasbaar op elke situatie en kunnen innovatie echt versnellen.

Galen Low

Ik vind dat geweldig. Kun je misschien wat voorbeelden geven om het concreet te maken voor onze luisteraars? Wat zou bijvoorbeeld een mijlpaal voor conceptfit kunnen zijn en wat zou daarna product-marktfit zijn? Als je echte voorbeelden hebt, graag; anders mag een hypothetisch voorbeeld ook.

John Carter

Nee, ik heb onlangs een systeem opgezet. We noemden het de venture board. Het was een durfkapitaalstructuur binnen een grote technologieorganisatie. We doorliepen dit basisraamwerk en daaruit kwamen enkele zeer interessante en concrete lessen.

Voor conceptfit is een tastbaar voorbeeld dat het concept in de eerste plaats moet aansluiten bij het ware noorden van het bedrijf. We maakten vaak een strategische kaart van projectideeën. Jouw idee kon op die kaart staan, naast andere kandidaten voor digitale ontwikkeling. De kaart had twee dimensies. De ene was de aansluiting bij de strategie, het ware noorden. De andere was de financiële impact: hoeveel zal het verschil maken? Je kijkt dus eerst naar conceptfit: we hebben deze verzameling ideeën. Zal jouw idee de resultaten beïnvloeden en sluit het echt aan bij ons merk? Daar kun je een checklist voor gebruiken.

Wat product-marktfit betreft, gaat het om externe parameters. De acquisitiekosten zijn waarschijnlijk de belangrijkste meetwaarde. Maar het kan ook gaan om het begrijpen van het unieke verkoopargument. Wat willen consumenten? Dat brengt ons bijvoorbeeld terug bij mijn ervaring met hoofdtelefoons. Ik was de uitvinder en stond samen met dr. Bose als eerste twee personen op het patent. Bij de ontwikkeling richtten we ons op beter geluid: een betere bas en een gelijkmatiger resultaat voor verschillende hoofden en draagomstandigheden.

Toen we het product in handen van mensen legden, vonden ze dat niet belangrijk. Ze wilden ruisonderdrukking. Geloof het of niet, we hadden dus geen product-marktfit, ook al waren wij de uitvinders. We maakten vervolgens een omslag en richtten ons op maximale ruisonderdrukking, niet op totale balans en frequentierespons.

Product-marktfit is dus heel belangrijk en kan alleen echt worden gemeten door op een of andere manier contact met klanten te hebben. De laatste mijlpaal is de bedrijfscase. Klopt de berekening? Is de marge die je op het product maakt veel groter dan de acquisitiekosten? Waar moet je het product lanceren? Als je kunt aantonen dat de berekening klopt en dat je een winstgevend digitaal product met een groot volume kunt maken, is het de moeite waard om door te gaan. Dat zijn dus de drie kantelpunten: strategische fit, acquisitiekosten en klant- en product-marktfit, en ten slotte de vraag of het financieel klopt. Dat zijn drie belangrijke mijlpalen die bedrijven effectief kunnen gebruiken en die waarde toevoegen. Elk team moet ze doorlopen, en dat sluit aan bij je punt dat mijlpalen niet door de planning worden bepaald. De vraag is: wat maakt dit product succesvol?

Galen Low

Wat ik mooi vind, is dat het in het voorbeeld met de hoofdtelefoon niet ging om: oké, we moeten beginnen, dit is een mislukking of we hebben deze mijlpaal gemist. Je gebruikte het als een moment om het product te evalueren, besefte dat je moest bijsturen en gebruikte de resterende tijd om er iets van te maken dat wél goed paste.

John Carter

Precies. En we deden het vroeg. Dat is de sleutel.

Galen Low

Dat vind ik goed. Ik moet je nog iets vragen. Je noemde eerder de focus op Agile. Waarom heb je dan nog mijlpalen nodig? Moet een projectmanager die een project plant met een agile methodologie nog steeds waarde hechten aan mijlpalen? Hoe zien ze er daar uit?

John Carter

Dit is een veelvoorkomende en volgens mij zeer slechte misvatting: dat Agile en mijlpalen niet samengaan. De waarheid is dat vrijwel elk bedrijf dat ik ken en zegt agile te werken, mijlpalen heeft. Niet één, maar tientallen. Het is een mythe die wordt verspreid door religieuze fanatici — dat zeg ik met zowel humor als enige waarheid. Ik gaf ooit een presentatie aan een groep scrummasters en voor het eerst in misschien vijf jaar werd het woord waterval genoemd. Ik dacht: wauw, oké. Ik begrijp het belang van Agile, maar het is niet in strijd met mijlpalen. Zoals we bespraken, heb je mijlpalen nodig om afhankelijkheden te beheren en elk agile programma van enige omvang heeft afhankelijkheden. Als onderdeel van sprint nul maak je een releaseplan en bepaal je in welke sprint deze afhankelijkheden worden opgelost. Dat zijn mijlpalen. Je kunt ze anders noemen, maar feitelijk zijn het mijlpalen. Daarnaast zal elke organisatie die op het punt staat veel te investeren in een digitaal project aan het team vragen: zijn jullie klaar om uit te geven? Is dit een goede investering? Dat is een mijlpaal. Agile versus mijlpalen is dus een valse tegenstelling. Ze bestaan heel goed naast elkaar. De beste systemen gebruiken beide.

Galen Low

Geweldig. Ja, dat weet ik.

John Carter

Ik wil er ook aan toevoegen dat ik geloof in agile met een kleine ‘a’: welke agile praktijken waardeer je die het bedrijf echt vooruithelpen op manieren die jij belangrijk vindt?

Ik denk dat sprintplanning bijvoorbeeld een praktijk kan zijn, demo's een andere en feedback van klanten weer een andere. Bepaal wat belangrijk is voor Agile en pas dat toe.

Galen Low

Ik vind dat echt goed. John, deze tips over productmijlpalen zijn allemaal bijzonder waardevol. Degene die het meest bij me is blijven hangen en die mijn manier van werken waarschijnlijk zal veranderen, is het idee van standaardmijlpalen. Ik had er nooit zo over nagedacht als een manier om projecten onderling te vergelijken en verwachtingen te scheppen bij belanghebbenden en senior management over wat we in al onze projecten meten. Het helpt echt om besluitvorming te sturen, vooral als je op het punt staat een cheque van zeven of acht cijfers uit te schrijven om het volgende onderdeel te financieren of alle widgets te bestellen.

Dat is mijn belangrijkste inzicht hieruit.

John Carter

Mooi. En het is waar.

Galen Low

Voor mensen die de manier waarop ze mijlpalen gebruiken willen veranderen en dit willen invoeren: wat is de eerste stap die je zou aanraden?

John Carter

Het belangrijkste is dat ze als bedrijf begrijpen welke belangrijke beslissingen ze moeten nemen. Waar zijn de enkele belangrijke punten waar elk project doorheen moet? Wat zijn de knelpunten? Welke gebieden zijn cruciaal? Spreek die vervolgens af en geef ze dezelfde naam. Het is vrij eenvoudig: spreek ze af, noem ze hetzelfde en laat elk team ze gebruiken. Dat is een geweldige manier om te beginnen. Zo hebben we het proces voor nieuwe producten bij Apple opgeschaald: we spraken eenvoudig af wat de mijlpalen waren, hoe we ze zouden noemen en wat er tegen die tijd gedaan moest zijn. Daarna zijn we die taal gaan gebruiken. Het klinkt heel eenvoudig, maar de eerste stap is daadwerkelijk aanpassen.

Galen Low

Dat is logisch. En als je eenmaal op deze manier met mijlpalen werkt, wat is dan het belangrijkste om onderweg te onthouden?

John Carter

Ik denk aan de vertrouwenskring waar we het gesprek mee begonnen, Galen: vertrouwen, besluitvorming en monitoring. Als we een systeem van vertrouwen kunnen creëren op basis van bekwame mensen die hun projecten uitvoeren en de mijlpalen kunnen scheiden voor besluitvorming, kunnen we de monitoring overlaten aan iets dat zeer weinig wrijving veroorzaakt en leidinggevenden de informatie geeft die ze nodig hebben zonder het team te belasten.

Galen Low

Daar hou ik van.

John, ontzettend bedankt dat je vandaag te gast wilde zijn. Ik waardeer alle inzichten die je met ons hebt gedeeld enorm. Het heeft mijn manier van werken veranderd en hopelijk betekent het ook veel voor sommige van onze luisteraars.

John Carter

Bedankt dat ik hierover mocht praten. Je weet duidelijk waar je het over hebt en hebt de belangrijkste punten goed samengevat. Bedankt voor deze gelegenheid, Galen.

Galen Low

Wat denk jij? Wat zijn jouw beste tips en trucs voor projectmijlpalen? Wat werkt en wat niet? Vertel ons een verhaal. Wanneer hebben je projectmijlpalen je in de steek gelaten? Welke best practices hebben tot grote successen geleid? Vertel het ons in de reacties hieronder. En als je meer wilt leren en vooruit wilt komen in je werk, sluit je dan aan bij onze community met DPM Membership. Ga naar thedigitalprojectmanager.com/membership voor toegang tot ons expertsforum, mentorgroepen, workshops, live mentorsessies, vraag-maar-raak-sessies, e-books, sjablonen en meer. Als je hebt genoten van wat je vandaag hebt gehoord, abonneer je dan en blijf in contact via thedigitalprojectmanager.com. Tot de volgende keer. Bedankt voor het luisteren.