Du ser kanskje helt feil på milepæler (med John Carter fra TCGen)

Les transkripsjonen:

Vi prøver ut å transkribere podkastene våre ved hjelp av et program. Tilgi eventuelle skrivefeil, ettersom roboten ikke er korrekt 100 % av tiden.

Galen Low

Der sitter du igjen og stirrer på prosjektplanen din, og gruer deg til selve milepælene du var med på å lage. De ser ut til å krype nærmere hver gang du ser på dem, som diamantformede Space Invaders. I begynnelsen virker de så harmløse: De var bare streker i sanden som skulle hjelpe deg med å planlegge i grove trekk. Nå er de en byrde rundt halsen: tunge, urokkelige tidsfrister som det ikke går an å diskutere med. De er de dempede murringene av tvil som truer med å trekke deg inn i et dragehi fullt av sinte interessenter når den skjebnesvangre dagen kommer. Hvis dette høres kjent ut, beklager jeg å måtte fortelle deg at du er en av disse prosjektlederne som har brukt prosjektmilepæler helt feil. Ikke bekymre deg, de fleste av oss er i samme båt. Men hvis du vil forvandle prosjektmilepælene dine fra en skremmende byrde til en ledestjerne for samarbeid mellom teamet og interessentene, bør du fortsette å lytte.

Takk for at du lytter. Jeg heter Galen Low og kommer fra The Digital Project Manager. Vi er et fellesskap av digitale fagfolk med et mål om å hjelpe hverandre med å bli dyktigere, tryggere og bedre knyttet sammen, slik at vi kan levere bedre prosjekter. Hvis du vil høre mer om dette, kan du gå til thedigitalprojectmanager.com.

Greit. Hei alle sammen, og takk for at dere henger med oss på DPM-podkasten. Dagens gjest er en høyt respektert ekspert på produktutvikling, og han er heller ikke ukjent med prosjektledelse. Han er en av de viktigste hjernene bak Bose’ støydempende hodetelefoner, i tillegg til Apples prosess for utvikling av nye produkter. I dag gir selskapet hans, TCGen, råd til tungvektere som Amazon, Apple, Cisco, Hewlett-Packard, IBM, Mozilla, Roche og 3M. Han har også nettopp ansatt en lærer for å hjelpe seg med å lære musikkteori, og komponerer nå musikk. Så, alle sammen, ønsk John Carter velkommen. Hei, John.

John Carter

Hei, Galen. Hyggelig å være her.

Galen Low

Det er flott å ha deg med i programmet. Jeg setter virkelig pris på det. John, CV-en din. Da jeg så på den, tenkte jeg at alle sikkert misunner deg CV-en. Vi snakker om produktinnovasjon for Bose, arbeid med Apple, at du nå driver din egen virksomhet og skriver bøker. Så jeg tenkte å begynne med å spørre: Hva ville du bli da du ble voksen?

John Carter

Det er et morsomt spørsmål. Og jeg gjør faktisk fortsatt dette på fritiden, nemlig å være ingeniør. Jeg har alltid ønsket å designe ting, gjøre beregninger og forutsi ytelse. Det er noe som har drevet meg helt frem til i dag. Det driver meg fortsatt.

Galen Low

Det liker jeg! Var dette en stor inspirasjon til å gå inn på den mer innovasjonsrettede siden av ting? Jeg antar at ingeniørtenkemåten egner seg godt til å skape nye ting som er levedyktige, gjennomførbare og som folk faktisk vil bruke.

John Carter

Jeg er ikke sikker på at det var så gjennomtenkt da jeg først begynte, men jeg var den prototypiske gutteforskeren. Jeg hadde kjemisett, mikroskop og teleskop. Jeg tok amatørradiolisens. Jeg gjorde alle disse nerdenes aktivitetene. Jeg elsket virkelig det jeg gjorde. Og jeg tror det henger sammen med det jeg liker å gjøre nå: Jeg elsket elektronikk, og jeg elsket at man ikke kunne se elektrisitet eller elektroner, men likevel kunne måle dem og gjøre noe med dem. I dag kan man gjøre det samme med lyd. Du kan ikke se den, men den har enorm innvirkning på hvordan du føler og tenker og så videre. Jeg har derfor alltid likt å prøve å forstå fenomener man ikke kan se.

Galen Low

Der har du det. Var det et inspirerende øyeblikk da du bestemte deg for å ta dette ut av en ingeniørkontekst og dreie det mer mot teknologi, den digitale verdenen eller produkter?

John Carter

På en måte oppsto det helt naturlig gjennom arbeidet mitt med dr. Bose i Bose Corporation, der jeg begynte. Han var fenomenal både innen markedsføring og ingeniørfag samtidig – det er en svært uvanlig kombinasjon. Han stilte grunnleggende spørsmål om hva folk bryr seg om, hva de ønsker å gjøre og hva som er viktig for dem. Gjennom hans måte å leve og arbeide på forsto jeg virkelig hvor viktig det er å prøve å forstå kundenes behov og sørge for at du leverer det som faktisk er viktig for dem. Vi lærte dette på mange måter. Selv som oppfinnere hadde vi egentlig ingen anelse om hva kundene ville verdsette før vi la produktet i hendene deres. Jeg tror derfor at det var en gradvis introduksjon gjennom dr. Bose og hans enorme markedsinnsikt som fikk meg til å gå fra ren ingeniørkunst til innovasjon.

Galen Low

Det er fantastisk. Jeg liker det. Og du har gjort så mye i løpet av karrieren din. Er det noe du prøver å bli bedre på for tiden?

John Carter

Alltid, alltid. Det er et par ting. Noe jeg synes er veldig interessant, er skjæringspunktet mellom smidig utvikling og prosjektledelse. Jeg synes det er fascinerende. Det andre er konsekvensene av det jeg vil kalle digital produktutvikling. Hvordan er det å jobbe med maskinlæring sammenlignet med typisk produktutvikling? Hvordan innoverer man i et slikt digitalt miljø og i denne nye virkeligheten med fjernarbeid? Det er fascinerende å se hva som foregår. Jeg prøver derfor virkelig å forstå hva som driver innovasjonsfronten.

Galen Low

Fantastisk. Det liker jeg.

Jeg ville også spørre om det er noe annet du nylig har oppdaget som gjør livet ditt fantastisk.

John Carter

Jeg tror noe av det som virkelig har fornyet troen min på menneskeheten, er evnen til å innovere kontinuerlig. Hvis du ser på problemene vi står overfor nå, og på det faktum at verden i stor grad har måttet snu seg mot ting som fjernarbeid, utdanning og utvikling og levering av legemidler, finnes det positive forandringer som følge av krisen vi er inne i. Det bygger virkelig opp troen min på vår evne til å innovere oss ut av enhver situasjon vi møter. Det gir meg mye håp.

Galen Low

Jeg liker det lyspunktet i et ellers kanskje suboptimalt år for oss. Flott. Jeg tenkte at vi kunne snakke om innlegget du nylig publiserte på Thedigitalprojectmanager.com om prosjektmilepæler. For det første fikk det meg til å føle at jeg hadde gått helt feil frem med prosjektmilepæler. For det andre fikk det meg virkelig til å tenke på forbindelsen mellom prosjektmilepæler og et produkts suksess eller fiasko i markedet. Det er en måte å se problemet på som jeg aldri egentlig hadde vurdert før. Men la oss kanskje spole tilbake og begynne fra starten. Hva er prosjektmilepæler i dine øyne, og hvorfor bør noen bry seg om dem?

John Carter

Det er et godt spørsmål og et godt sted å begynne, fordi jeg tror folks oppfatning av milepæler er feil når det gjelder digital prosjektledelse. Feilen er at milepæler ikke er en måte å måle fremdrift på. Det finnes mange andre og bedre måter å måle fremdrift på som ikke sliter ut teamet, produserer store mengder irrelevante rapporter og fører til detaljstyring fordi man plutselig har oversikt over flere ting. Den vanlige misoppfatningen er at man skal bruke milepæler til sporing. Men hvis du ser på hva milepæler egentlig er, er de vendepunkter i prosjektet. De er kritiske perioder eller beslutningspunkter i prosjektets liv, der du enten skal investere mer, ta på deg mer risiko eller inngå avtaler med partnere. Da fortjener du sannsynligvis å ha gjort hjemmeleksen din. I tillegg finnes det i den komplekse, sammenkoblede digitale verdenen vår mange avhengigheter mellom prosjektegenskaper, og milepæler er en god måte å synkronisere slike avhengigheter på. Du kan ha to team som begge arbeider smidig, men på et tidspunkt trenger det ene teamets arbeid resultatet fra det andre. Milepæler er en god måte å samordne denne typen aktivitet på.

Galen Low

Jeg liker det. Når du tenker gjennom dette, nevnte du noen av de vanlige misoppfatningene om milepæler – at man henger seg opp i sporing og rapportering. Hvilken innvirkning har det på et prosjekt hvis man nærmer seg milepæler på den måten i stedet for å tenke på avhengigheter mellom team?

John Carter

Det er så mange ting. For det første undergraver det på en måte troen på at ledelsen stoler på teamet. Hvis prosjektene er fulle av innsjekkinger, ledelsesgjennomganger og milepælsgjennomganger, ser teamet hele tiden seg over skulderen og lurer på hva ledelsen tenker.

Dette er en nedbrytende holdning, fordi den ikke styrker teamets selvtillit eller evne til å levere et fremragende prosjekt på eget initiativ, selv om alle i teamet tror de kan gjøre det.

I tillegg er det en belastning for teamet, fordi man hele tiden produserer rapporter som blir skumlest, ikke lest eller raskt oversett, i tillegg til omstendelige diagrammer og oppdateringer. Hva er poenget? Er det for å ta en beslutning? Er det for å kommunisere? Hvis det er for å kommunisere, kan du bruke prosjektdashbord, restlister eller en rekke andre måter å kommunisere fremdrift på. Hvis det gjelder beslutninger, hva er det egentlig som må løftes ut av teamet? Det er da du trenger en stor milepæl. Og de bør være sjeldne. Tanken er derfor å redusere hyppigheten og antallet slike gjennomganger og sørge for at de tilfører verdi for teamet.

Det er virkelig viktig når man skal innføre effektive milepæler.

Galen Low

Jeg liker det. Det handler mer om å gjøre arbeidet enn å stoppe opp for å evaluere eller rapportere om det.

John Carter

Nettopp. Og så får du en uheldig situasjon der ledelsen prøver å «tilføre verdi» og legger en mengde tomme kalorier på teamet. Teamet må bruke energi på å lage enda en rapport, slik at noen kan se mer. Det blir en endeløs strøm av ledere som kaster stoler i veien for teamet, når ledelsen egentlig bør fjerne hindringer og komme seg ut av veien.

Det er en annen måte milepæler kan slå begge veier på. For mange oppmuntrer til detaljstyring, mens riktig antall oppmuntrer til riktig type beslutningstaking.

Galen Low

Flott. Var det et tidspunkt da du stoppet opp i et prosjekt du ledet og sa: «Greit, jeg gjør dette på feil måte. Dette burde egentlig handle mer om teamet og samarbeid enn om rapportering»?

John Carter

Ja, det var kort tid etter at jeg ble forfremmet til sjefingeniør i Bose. I den situasjonen hadde jeg en tendens til å detaljstyre, innkalle til flere gjennomganger og strø inn flere prosjektmilepæler. Plutselig innså jeg at jeg holdt på å gå under, fordi jeg ikke fant nok tid i uken til å planlegge alle disse detaljene og gjennomgangene fulle av detaljer. Det andre var at det heller ikke hjalp teamene. Jeg druknet, teamene druknet. Så innså jeg – og dette var så kjedelig – at noen av disse teamlederne og tekniske ekspertene kunne mye mer enn meg. Mye mer. Jeg burde bare komme meg ut av veien. Jeg visste ikke hva jeg snakket om. Da en ingeniør i utviklingsorganisasjonen sa at jeg bare skapte forstyrrelser, forsinkelser og støy, var det sannsynligvis tidspunktet da jeg sluttet med så mange milepælsgjennomganger.

Galen Low

Da du sluttet, merket du en forskjell over natten i måten teamet arbeidet på?

John Carter

Nei, egentlig ikke. Jeg tror det gradvis ble mer produktivt, og jeg ble mye lykkeligere i jobben min. Jeg oppdaget at teamet faktisk leverte like godt, om ikke bedre, uten at jeg blandet meg inn. Jeg tror det som skjer, er at sløret løftes fra teamet, slik at de blir mer produktive, lykkeligere og mer tilfredse, og leverer bedre produkter.

Galen Low

Ja, det er fantastisk hvor tung mistillit kan være. Når ting kommer fra et sted med mistillit, er det en tung byrde for teamet, sammenlignet med tillit: Jobben blir gjort, og alle samarbeider og styrer seg selv effektivt.

John Carter

Ja, det er som en konstant etsende atmosfære. Jeg er enig.

Galen Low

Flott. La oss snakke litt mer om hvordan man gjør dette på riktig måte, og hvordan det ser ut når man gjør det riktig når det gjelder prosjektmilepæler. Du nevnte at milepæler er mer for teamet enn for prosjektledere eller ledelsen. Hvordan lærer man opp et team til å se det på den måten hvis man ikke allerede gjør det?

John Carter

Dette går tilbake til miljøet med mistillit som du snakket om. Det som er avgjørende, er at teamet har en kompetent produkteier, en kompetent Scrum-master, en digital prosjektleder og en kompetent teknisk leder. Hvis du har disse tre tingene, bør ledelsen stole på deg og systemet. Hvis teamet ditt har kompetanse, er det ikke behov for konstant detaljstyring. Da kan du samarbeide med teamet slik at de forstår hvilke milepæler som er viktige, og hvorfor de er viktige. Jeg tror det er det viktigste. Milepæler bør heller aldri være knyttet til faste intervaller.

Du bør altså ikke ha faste ukentlige møter eller månedlige gjennomganger eller stadig nye gjennomganger. Noen er nødvendige, men generelt ikke på detaljnivå. Milepæler bør være hendelsesstyrte.

De er prosjektstyrte. De er basert på teamets hastighet, modenhet, størrelse, risiko og så videre, i tillegg til selve utfordringen og oppgaven. Hvis milepælene dine ligger på regelmessige kalenderdatoer, er det et tydelig tegn på at det er et problem.

Galen Low

Det signaliserer nesten mistillit. «Jeg skal sjekke inn med deg annenhver uke.»

John Carter

Nettopp.

Galen Low

«Jeg må forsikre meg om at du holder kursen», i stedet for: «På dette tidspunktet må vi se på hvor vi står, fordi andre ting er avhengige av dette. Hvordan skal vi planlegge eller samarbeide om de neste stegene?»

John Carter

Nettopp. Eller: «Vi skal skrive ut en sjusifret sjekk. Er vi sikre på at vi gjør det riktige?» Absolutt.

Galen Low

Når du sier det slik, er det veldig viktig.

John Carter

Det kan være store sjekker.

Galen Low

Ja, absolutt. Når det gjelder å vite når et team er klart, liker jeg å ha disse rollene og vite at de er sterke i rollene de har i teamet. Hvilken type atferd forventer du fra et team som virkelig er klare til å eie sine egne milepæler og forstå hva de handler om?

John Carter

Galen, dette er et fantastisk spørsmål, og jeg tror det kan besvares veldig enkelt. Unnskyld meg. Svaret er historikk. Har dette teamet vært forutsigbart tidligere? Viser historien deres, suksessen og prestasjonene deres tidligere at resultatet sannsynligvis blir positivt? Hele denne tilliten bygges over tid. Den beste målestokken for ethvert prosjektteam er tidligere historikk og suksess i programmet. Det er det aller viktigste. I hver av de sentrale rollene trenger du for eksempel i produktteamet noen som forstår hvorfor og hva. De må virkelig kunne dette, og teamet må tro på dem. Det samme gjelder den tekniske lederen og utvikling og kvalitetssikring: Du må stole på deres evne til å ta riktige arkitekturvalg og gjøre riktige avveininger for å nå prosjektmålene. Når det gjelder den digitale prosjektlederen, må du være trygg på at vedkommende er åpen. Når det oppstår et problem, må det gjøres kjent raskt, og ting må ikke skjules.

Denne typen atferd i disse tre nøkkelrollene viser at teamet er klart, i tillegg til historikken.

Galen Low

Jeg liker det. Jeg liker hele konseptet med teamsammensetning og strategi for teambygging. Man ønsker erfarne folk som møter arbeidet med et modent perspektiv og forstår konteksten. Kanskje de støttes av mer junior medarbeidere. Det er absolutt fortsatt plass til dem. Men når du snakker om å ha de riktige personene, mener du da erfarne teammedlemmer som kan se på prosjektet og produktet de skaper på riktig måte, slik at de kan forstå hva milepælen betyr og bidra til å planlegge milepælene for prosjektet?

John Carter

Absolutt. Juniorroller kan være langt flere enn seniorrollene, men det handler ikke om alder. Du trenger erfaringssykluser, såkalte læringssykluser. Hvis de har flere slike bak seg og det har vært gode erfaringer, kan du absolutt stole på teamet.

Galen Low

Læringssykluser.

John Carter

Ja.

Galen Low

Det er flott. Det andre spørsmålet mitt gjelder motsatt side. Hvis du jobber med et lederteam som er vant til månedlige milepælsinnsjekkinger, eller som legger inn et dusin milepæler på svært kort tid fordi de er så vant til det – kanskje de stoler på teamet, men er programmert til å ville sjekke inn og detaljstyre – hvordan får du et slikt leder- eller administrasjonsteam til å tenke annerledes om milepæler, slik at de blir færre, ligger lenger fra hverandre og ikke følger en fast rytme?

John Carter

Det er et godt spørsmål. Og svaret er: Det kommer an på. Hvis organisasjonen har en mekanisme for å måle fremdrift, enten det er restlister, brukerhistoriepoeng eller leveranser som er ferdigstilt, finnes det alle slags enkle, objektive fremdriftsmål. Hvor lette og objektive de er, er viktig. De kan brukes som en erstatning. Utfordringen med ledere er at de blander sammen åpenhet og overvåking av prosjektfremdrift med beslutningstaking. Dette er to helt forskjellige kommunikasjonsformer. Når det gjelder sporing av fremdrift, kan det gjøres med dashbord eller alle slags åpne indikatorer. I verste fall kan det gjøres i et møte, men da med én person og med en hyppighet som styres av behovet.

Det finnes altså en forvirring hos ledere. Vi må forsikre dem om at de kan se fremdriften åpent, og at de vil få beskjed hvis noe går galt. Selv om vi ikke snakket om rammebetingelser i denne artikkelen, finnes det en idé om at teamet har grenser for hva som ligger innenfor terskelen de har blitt enige om i den digitale produktutviklingen. Hvis de ikke kommer til å nå disse grensene, er det teamets ansvar å informere ledelsen. Hvis ledelsen derfor kan se teamets fremdrift på en åpen måte og være trygg på at det finnes en mekanisme som sørger for at de får dårlige nyheter raskt, bør det være tilstrekkelig. Når de i tillegg har sett teamets historikk, kan de stole på teamet. Med disse tre faktorene kan vi argumentere overbevisende for behovet for færre milepæler.

Gir det mening, Galen?

Galen Low

Absolutt. Jeg liker dette skillet mellom rapportering og sporing på den ene siden og beslutningstaking på den andre. Det er egentlig det milepæler handler om: et øyeblikk der man spør hvordan det går.

Ikke når det gjelder fremdrift, men når vi skal gå inn i neste fase eller ta med et annet team for å samarbeide med oss. Er vi klare for det? Er det fortsatt riktig å gjøre?

John Carter

Nettopp. Er de klare for oss?

Det er et godt poeng, og det er en verdifull innsjekking.

Galen Low

Det leder meg til neste spørsmål. Når vi planlegger milepæler, endrer dette perspektivet ditt på milepæler måten vi faktisk lager dem på i utgangspunktet, eller måten vi utvikler prosjektplanen på? Hvis vi tidligere har sagt at vi sjekker inn kvartalsvis eller må oppdatere styringsgruppen, endrer det måten du planlegger prosjekter på når du tenker på milepæler som noe for prosjektet og teamet?

John Carter

Ja, absolutt. Alle de andre statusrapportene, oppdateringene til styringsgruppen og så videre ville blitt redusert eller fjernet. Vi snakker om et lett rammeverk for digital produktutvikling. Dette rammeverket bør ha et sett med standardiserte vendepunkter som passer for virksomheten din. Ulike organisasjoner har ulike begrensninger. Hvis du lager fysiske produkter, må du bestille lager og deler. Det er en stor utgift, og du vil sannsynligvis forsikre deg om at de riktige delene er spesifisert. Det er viktig. På samme måte må du, hvis du skal skalere et digitalt prosjekt, sørge for at riktig instrumentering er inkludert i produktet, slik at du kan hente inn analysene teamet trenger. Det er viktig at instrumenteringen er klar når du lanserer produktet. Det avhenger altså av virksomheten din. Men milepælene bør generelt standardiseres. Det bør være få av dem. Jeg liker å si at det bør være så lite prosess som mulig, men ikke mindre enn nødvendig. Tanken er å gjøre det lett og plassere standardiserte milepæler der virksomheten vanligvis tar de store beslutningene. Det bør være et lite antall, kanskje tre til fem.

Galen Low

Jeg liker eksempelet med fysiske produkter. Hvis du må bestille deler, gir det mening. Du har disse avhengighetene, og før du gjør det, vil du forsikre deg om at du er på et punkt der det faktisk gir mening.

John Carter

Absolutt. Når det gjelder typisk digital utvikling, har du skyaktiviteter, det som skjer hos klienten, kanskje skrivebordsløsninger, mange ulike systemer som må integreres, og DevOps som må koordineres. Hver virksomhet er forskjellig.

Galen Low

En av tingene jeg syntes var veldig fascinerende i artikkelen din, var at du snakket om tre store milepæler eller vendepunkter i løpet av et prosjekt som skulle samsvare med viktige forretningsmål. Kan du forklare litt hva de er og hvorfor de er viktige?

John Carter

Den første er svært viktig, særlig når vi snakker om innovasjon og om det vi kalte innovasjon med stor I. Det vil si innovasjoner som endrer spillet. Allerede i begynnelsen av det digitale prosjektet bør du spørre: Er dette konseptet virkelig i tråd med strategien vår? Passer det med hvem vi er som merkevare? Er dette et produkt eller en idé vi ønsker å bringe ut på markedet? Vil det påvirke inntekter eller marginer? Vi kommer til å binde oss til denne aktiviteten i tre, seks, ni eller kanskje 18 måneder, potensielt med et stort team. Er dette i tråd med strategien vår og vil det ha en reell effekt? Det første du gjør, er altså å kontrollere om konseptet passer.

Det nest viktigste, når du har et konsept som er i tråd med strategien, er å sikre at du har produkt–markeds-tilpasning. Har du faktisk noe forbrukerne vil velge? Har du unike salgsargumenter som betyr noe for forbrukerne? Har du livskraft i markedet? Kan du oppmuntre flere brukere eller skape større handlekurver, eller hva målet nå er? Har du bevis på anskaffelseskostnaden? I den digitale tidsalderen er alle disse tingene målbare. Denne neste fasen er derfor svært viktig, særlig før du virkelig skalerer teamet: Sørg for at du har produkt–markeds-tilpasning.

Den siste milepælen gjelder utvikling og markedslansering. Organisasjonen sier nå at konseptet er i tråd med strategien, og at produktet passer i markedet. Forbrukerne liker faktisk det vi gjør. For å lage en komplett lansering, først som et minimumsprodukt og deretter med alle funksjoner, hva må vi utvikle for å få dette på plass? Hvilke partnere trenger vi på infrastruktursiden? Hvilke utviklingspartnere trenger vi for de ulike mobilplattformene? Vi skal håndtere skrivebord og nettbrett. Hvordan skal vi dele dette opp? Vi må investere i brukergrensesnitt, grafisk design og så videre. Vi kommer til å måtte bruke mye penger. Skal vi forplikte oss til det? Dette er beslutningen om å gå videre med utvikling og markedslansering.

Dette er altså de tre viktigste vendepunktene som styrer det meste av digital produktutvikling, og de kan selvfølgelig tilpasses. Kanskje du legger til en idéfase i starten, en tydeligere valideringsfase på slutten eller en DevOps-fase. Det finnes mange detaljer du kan legge til. Men når en virksomhet skalerer, er det viktig å ha noen få standardiserte milepæler. Da kan ledere sammenligne hvor prosjektene befinner seg, styre pengebruken over tid og forstå prosjektets faktiske status når det gjelder kundetilgang og investering.

Galen Low

Jeg liker ideen om å sammenligne prosjekter, særlig hvis en virksomhet utvikler flere prosjekter eller produkter samtidig. Da må man se på denne porteføljen og forstå hvor ting står, ikke når det gjelder prosjektets fremdrift, men når det gjelder helsen til selve produktkonseptet, hvordan produktet utvikler seg, når det skal lanseres og når det vil kreve bestemte ressurser.

John Carter

Hvis du ser på de tre milepælene vi snakket om, var ingen av dem knyttet til et tidspunkt.

Galen Low

Mhm.

John Carter

De handlet om: Er dette i tråd med strategien? Bra. Finnes det produkt–markeds-tilpasning? Bra. Ønsker vi virkelig å investere og bruke penger på å lansere dette? Bra. Dette er tre svært viktige, ikke-tidsbestemte elementer i programmet. Det bør ikke være for krevende for noen organisasjon å håndtere dem.

Galen Low

Hvis du har disse tre i prosjektplanen, er de urokkelige? Mange ser på milepæler i prosjektplanlegging som ting som ikke kan flyttes. Hva mener du om milepæler i den sammenhengen?

John Carter

Det er forskjell på håp og virkelighet. Ved ren smidig programvareutvikling er det teoretisk mulig å ikke «gå glipp av» en milepæl. Men egentlig flytter eller går man glipp av en sprint, ikke en milepæl. Selv i smidig utvikling finnes det et konsept som heter komplett funksjonalitet, og det er viktig. Jeg tror derfor at disse milepælene er generiske, gjelder i alle situasjoner og virkelig kan bidra til å fremskynde innovasjon.

Galen Low

Jeg liker det.

Jeg lurer på om du kan snakke om noen eksempler for å gjøre dette mer konkret for lytterne våre. Hva kan for eksempel være en milepæl for konsepttilpasning, og hva ville den påfølgende produkt–markeds-tilpasningen være? Har du noen eksempler fra virkeligheten, eller kan vi bruke et hypotetisk eksempel?

John Carter

Jeg har nylig satt opp et system vi kalte venture-styret. Det var et risikokapitaloppsett i en stor teknologiorganisasjon. Vi gikk gjennom dette grunnleggende rammeverket, og det kom frem noen interessante og konkrete lærdommer.

Noe som er viktig for konsepttilpasning, er først og fremst at konseptet er i tråd med selskapets sanne nord. Vi laget ofte et strategisk kart over prosjektideer. Ideen din kunne være på kartet, sammen med andre kandidater for digital utvikling. Kartet hadde to dimensjoner. Den ene var samsvar med strategien, det sanne nord. Den andre var økonomisk innvirkning: Hvor mye vil det påvirke resultatene? Først og fremst spør du derfor, når du vurderer konsepttilpasning: Vi har denne samlingen av ideer. Vil ideen du ønsker å utvikle, påvirke resultatene og virkelig passe med merkevaren vår? Det finnes en sjekkliste for dette.

Når det gjelder produkt–markeds-tilpasning, er det annerledes, fordi den involverer eksterne forhold. Anskaffelseskostnaden er sannsynligvis det viktigste målet man ser på. Det handler også om å forstå det unike salgsargumentet. Hva ønsker forbrukerne? Dette går for eksempel tilbake til erfaringen min med hodetelefoner. Jeg var oppfinneren, og sammen med dr. Bose var vi de to første på patentet. Da vi utviklet produktet, utviklet vi det for bedre lyd. Det skulle gi bedre bass og være jevnere på tvers av ulike hoder og brukssituasjoner.

Vi la det i hendene på folk. De brydde seg ikke om dette. De ønsket støyreduksjon. Tro det eller ei, vi hadde ikke egentlig produkt–markeds-tilpasning, selv om vi var oppfinnerne. Derfor endret vi retning og fokuserte på å maksimere støyreduksjonen, ikke total balanse, frekvensrespons og alt det andre. Produkt–markeds-tilpasning er virkelig viktig, og den eneste måten å måle den på er gjennom kontakt med kunder i en eller annen form.

Den siste milepælen gjelder forretningsmodellen. Har du en forretningsplan? Henger anskaffelseskostnaden sammen med produkt–markeds-tilpasningen og strategien? Er marginen du tjener på produktet betydelig større enn anskaffelseskostnaden? Hvor må du lansere produktet? Hvis du kan overbevise deg selv gjennom tallene om at du kan skape et lønnsomt digitalt produkt med høyt volum, er det verdt å gå videre. Dette er de tre vendepunktene: strategisk tilpasning, anskaffelseskostnad og produkt–markeds-tilpasning, og til slutt om tallene går opp. Dette er tre viktige milepæler som selskaper kan bruke effektivt, og som tilfører verdi. Ethvert team bør gå gjennom dem. Det går tilbake til poenget ditt om at milepæler ikke bør være tidsstyrte. Spørsmålet er: Hva skal gjøre dette produktet vellykket?

Galen Low

Det jeg liker, er at milepælen i hodetelefoneksempelet ikke ble brukt til å si at dette var en fiasko eller at vi hadde gått glipp av en milepæl. Dere brukte den som et tidspunkt for å evaluere produktet, innså at dere måtte endre retning og brukte resten av løpetiden til å gjøre produktet til riktig løsning.

John Carter

Riktig. Og vi gjorde det tidlig. Det er nøkkelen.

Galen Low

Jeg liker det.

Jeg må spørre: Du nevnte tidligere fokuset på smidig utvikling. Hvorfor trenger man fortsatt milepæler? Bør prosjektledere som planlegger et prosjekt med en smidig metode, fortsatt bry seg om milepæler? Hvordan ser de ut der?

John Carter

Dette er en vanlig og etter min mening svært dårlig misoppfatning: at smidig utvikling og milepæler ikke er kompatible. Sannheten er en liten hemmelighet. Nesten alle selskaper jeg kjenner som «driver smidig», har milepæler. Ikke bare én, men mange. Myten er blitt spredt av religiøse fanatikere, sier jeg med både humor og en viss sannhet. Jeg holdt en gang en presentasjon for en gruppe Scrum-mastere, og det var første gang på kanskje fem år at ordet fossefallsmetode ble nevnt i en presentasjon. Jeg forstår betydningen av smidig utvikling, men den er ikke i konflikt med milepæler. Som vi har snakket om, trenger du milepæler for å håndtere avhengigheter, og ethvert smidig program av en viss kompleksitet har avhengigheter. Som en del av sprint null lager du en lanseringsplan og kartlegger hvilken sprint avhengighetene skal komme inn i. Dette er milepæler. Du kan kalle dem noe annet, men de er milepæler. For det andre vil enhver organisasjon som skal investere mye i et digitalt prosjekt, spørre teamet om de er klare til å bruke penger, og om dette er en god investering. Det er en milepæl. Jeg mener derfor at dette er et falskt valg: smidig utvikling eller milepæler. De fungerer svært godt sammen. De beste systemene bruker begge deler.

Galen Low

Flott. Ja, det vet jeg.

John Carter

Jeg vil også legge til at jeg tror på smidig utvikling med liten s. Hvilke smidige praksiser verdsetter du, og hvilke bidrar virkelig til å føre virksomheten fremover på måter som er viktige for deg?

Jeg tror for eksempel sprintplanlegging kan være én praksis, demonstrasjoner en annen og tilbakemeldinger fra kunder en tredje. Finn ut hva som er viktig for smidig utvikling, og bruk det.

Galen Low

Jeg liker virkelig dette. John, disse tipsene om produktmilepæler er svært verdifulle. Det som traff meg mest, og som jeg tror vil endre hvordan jeg arbeider fremover, er tanken om standardiserte milepæler. Jeg hadde aldri tenkt på det som en måte å måle på tvers av prosjekter, eller som en måte å avklare forventninger med interessenter og toppledelsen om hva vi måler på tvers av alle prosjektene våre. Det driver beslutningstakingen, særlig når du skal signere en sjekk på sju eller åtte sifre for å finansiere neste del eller bestille alle delene.

Det er min viktigste lærdom fra dette.

John Carter

Flott. Og det er der …

Galen Low

For de som ønsker å endre måten de bruker milepæler på og ta dette i bruk: Hva er det første steget du anbefaler?

John Carter

Det viktigste er å forstå hvilke beslutninger virksomheten må ta. Hvor er de få viktige punktene alle prosjekter må gjennom? Hva er flaskehalsene? Hva er de sentrale områdene? Bli enige om dem, og gi dem samme navn. Det er ganske enkelt: Bli enige om dem, kall dem det samme og la alle team bruke dem. Det er en god måte å begynne på. Slik skalerte vi Apples prosess for nye produkter: Vi ble enige om noen få milepæler, bestemte hva de skulle hete og hva som måtte være gjort innen hvert punkt, og begynte å bruke dette språket. Det høres enkelt ut, men det første steget er faktisk å tilpasse seg.

Galen Low

Det gir mening. Når du først har begynt å bruke milepæler på denne måten, hva er det viktigste å huske underveis?

John Carter

Jeg tror det handler om denne ideen vi startet samtalen med, Galen: sammenhengen mellom tillit, beslutningstaking og overvåking. Hvis vi kan skape et tillitsbasert system der kompetente mennesker driver prosjektene sine, og skille ut milepælene som kun gjelder beslutningstaking, kan vi la overvåkingen være noe som krever svært lite friksjon og gir lederne informasjonen de trenger uten å belaste teamet.

Galen Low

Jeg liker det. John, tusen takk for at du var med i programmet i dag. Jeg setter virkelig pris på alle innsiktene du har delt. Jeg tror dette har forandret mye for meg, og forhåpentligvis også vil være betydningsfullt for noen av lytterne våre.

John Carter

Takk for muligheten til å snakke om dette. Du kan tydeligvis mye om temaet, og jeg synes du har sammenfattet hovedpunktene godt. Takk for denne muligheten, Galen.

Galen Low

Hva synes du? Hvilke tips og triks har du for prosjektmilepæler? Hva fungerer, og hva fungerer ikke? Fortell oss en historie. Når har prosjektmilepælene dine sviktet? Hvilke beste praksiser har ført til dine største seire? Fortell oss i kommentarfeltet nedenfor. Hvis du vil lære mer og komme videre i arbeidet ditt, kan du bli med i stammen vår med DPM-medlemskap. Gå til thedigitalprojectmanager.com/membership for tilgang til ekspertforumet vårt, mentorgrupper, verksteder, direktesendte mentorsamtaler, spør meg om hva som helst-sesjoner, e-bøker, maler og mer. Hvis du likte det du hørte i dag, kan du abonnere og holde kontakten på thedigitalprojectmanager.com. Vi høres neste gang. Takk for at du lyttet.