Du ser måske helt forkert på milepæle (med John Carter fra TCGen)

Læs transskriptionen:

Vi afprøver at transskribere vores podcasts ved hjælp af et softwareprogram. Tilgiv venligst eventuelle slåfejl, da robotten ikke er korrekt 100 % af tiden.

Galen Low

Så sidder du igen og stirrer på din projektplan og frygter de milepæle, som du selv har været med til at skabe. De synes at komme tættere på, hver gang du ser på dem, ligesom diamantformede Space Invaders. I begyndelsen virker de så uskyldige: De var blot streger i sandet, som skulle hjælpe dig med at planlægge i store træk. Nu er de en byrde om halsen: tunge, urokkelige deadlines, der ikke kan forhandles med. De er de tvivlens hvisken, som truer med at trække dig ind i en hule af vrede interessenter, når den skæbnesvangre dag oprinder. Hvis det lyder bekendt, er jeg ked af at fortælle dig, at du er en af de projektledere, der har brugt projektmilepæle helt forkert. Bare rolig, de fleste af os er i samme båd. Men hvis du vil forvandle dine projektmilepæle fra en skrækindjagende byrde til en ledestjerne for samarbejdet mellem team og interessenter, så lyt videre.

Tak, fordi du lytter med. Jeg hedder Galen Low og kommer fra Digital Project Manager. Vi er et fællesskab af digitale fagfolk med en mission om at hjælpe hinanden med at blive dygtigere, mere selvsikre og bedre forbundne, så vi kan levere projekter bedre. Hvis du vil høre mere om det, så gå ind på thedigitalprojectmanager.com.

Okay. Hej alle sammen, og tak fordi I hænger ud med os i DPM Podcast. Min gæst i dag er en bredt respekteret ekspert i produktudvikling og samtidig ikke fremmed for projektledelse. Han er en af de vigtigste hjerner bag Boses støjreducerende hovedtelefoner samt Apples proces for udvikling af nye produkter. I dag rådgiver hans virksomhed, TCGen, tunge brands som Amazon, Apple, Cisco, Hewlett-Packard, IBM, Mozilla, Roche og 3M. Og han har netop hyret en lærer til at hjælpe sig med at lære musikteori og komponerer nu musik. Så tag godt imod hr. John Carter. Hej John.

John Carter

Hej Galen. Det er dejligt at være her.

Galen Low

Det er fantastisk at have dig med i programmet. Det sætter jeg virkelig pris på. John, dit CV. Da jeg så på det, tænkte jeg: Alle er sikkert misundelige på det CV. Vi taler om produktinnovation for Bose, arbejde med Apple, drift af din egen virksomhed og bogskrivning. Så jeg tænkte, at jeg ville begynde med at spørge: Hvad ville du være, når du blev voksen?

John Carter

Det er et sjovt spørgsmål. Og jeg gør det faktisk stadig i min fritid, nemlig at være ingeniør. Jeg har altid ønsket at designe ting, lave beregninger og forudsige ydeevne. Og det er noget, der har drevet mig lige siden. Det driver mig stadig.

Galen Low

Det elsker jeg! Var det en stor inspiration at bevæge dig ind på den mere innovative del af tingene? Jeg forestiller mig, at ingeniørtankegangen egner sig til at skabe nye ting, som er levedygtige, gennemførlige, og som folk rent faktisk vil bruge.

John Carter

Jeg er ikke sikker på, at det var så gennemtænkt, da jeg begyndte, men jeg var den prototypiske drengeforsker. Jeg havde et kemisæt, et mikroskop og et teleskop. Jeg fik en amatørradiolicens. Jeg lavede alle mulige nørdede ting. Jeg elskede virkelig det, jeg lavede. Og jeg tror, det hænger sammen med det, jeg elsker at lave nu, nemlig at jeg elskede elektronik og elskede det faktum, at man ikke kunne se elektricitet eller elektroner, men alligevel kunne måle det og gøre noget med det. I dag kan man gøre det samme med lyd. Man kan ikke se den, men den har enorm indflydelse på, hvordan man føler og tænker og så videre. Jeg har altid syntes, det var spændende at prøve at forstå fænomener, man ikke kan se.

Galen Low

Netop. Var der et inspirerende tidspunkt, hvor du besluttede: Ved du hvad, lad os tage det her ud af en ingeniørmæssig sammenhæng og rette det mere mod teknologi og den digitale verden eller produkter?

John Carter

På en måde opstod det helt naturligt gennem mit arbejde med dr. Bose hos Bose Corporation, hvor jeg begyndte. Han var fantastisk, både inden for markedsføring og teknik på samme tid – det er en meget, meget usædvanlig evne. Han stillede grundlæggende spørgsmål om, hvad folk går op i, hvad de gerne vil gøre, og hvad der er vigtigt for dem. Gennem hans tilgang til livet forstod jeg virkelig vigtigheden af at forsøge at forstå kundernes behov og sikre, at man leverer det, der virkelig er vigtigt for dem. Vi lærte det på så mange måder. Selv om vi var opfinderne, havde vi i virkeligheden ingen idé om, hvad kunderne ville værdsætte, før man lagde det i hænderne på dem. Så jeg tror, at det var en gradvis introduktion gennem dr. Bose og hans enorme markedsindsigt, der fik mig til at bevæge mig fra ren teknik til innovation.

Galen Low

Det er fantastisk. Det elsker jeg. Og du har jo opnået så meget i din karriere. Er der noget, du forsøger at blive bedre til i disse dage?

John Carter

Altid, altid. Der er et par ting. Noget, jeg synes er virkelig interessant, er mødet mellem agil udvikling og projektledelse. Det synes jeg er fascinerende. Det andet er konsekvenserne af det, jeg vil kalde digital produktudvikling. Hvordan er det at arbejde med maskinlæring sammenlignet med typisk produktudvikling? Hvordan innoverer man i den slags digitale miljø og i hele denne nye virkelighed med fjernarbejde? Det er fascinerende, hvad der foregår. Så jeg prøver virkelig at forstå, hvad der skubber innovationsfronten fremad.

Galen Low

Fantastisk. Det elsker jeg.

Jeg ville også spørge: Har du for nylig fundet noget andet, der bare gør dit liv fantastisk?

John Carter

Jeg tror, at noget af det, der virkelig har fornyet min tro på menneskeheden, er evnen til konstant at innovere. Hvis man ser på de aktuelle problemer foran os og på det faktum, at vi som verden grundlæggende har måttet tilpasse os ting som fjernarbejde, uddannelse og udvikling og levering af lægemidler, så er der positive forandringer, der er resultatet af den krise, vi befinder os i. Det styrker virkelig min tillid til vores evne til at innovere os ud af enhver situation, vi møder. Det giver mig meget håb.

Galen Low

Jeg elsker den positive side af et ellers måske mindre optimalt scenarie for os i år. Fantastisk. Jeg tænkte, at vi måske kunne tale om dit nylige indlæg på Thedigitalprojectmanager.com om projektmilepæle. For det første fik det mig til at føle, at jeg havde grebet projektmilepæle helt forkert an. For det andet fik det mig virkelig til at tænke over forbindelsen mellem projektmilepæle og et produkts succes eller fiasko på markedet, hvilket er en måde, jeg aldrig rigtig havde betragtet problemet på før. Men lad os måske spole tilbage og begynde fra starten. Hvad er projektmilepæle efter din mening, og hvorfor bør nogen interessere sig for dem?

John Carter

Det er et godt spørgsmål og et godt sted at begynde, for jeg tror, at folks opfattelse af milepæle er forkert, når det gælder digital projektledelse. Fejlen er, at milepæle ikke er en måde at måle fremskridt på. Der findes mange andre og langt bedre måder at måle fremskridt på, som ikke slider teamet ned, skaber store mængder irrelevante rapporter og derefter fører til detailstyring, fordi man nu er blevet opmærksom på endnu flere ting. Den almindelige misforståelse er, at man bruger milepæle til sporing. Men hvis man ser på, hvad milepæle egentlig er, så er de vendepunkter i projektet. De er kritiske perioder eller beslutningspunkter i et projekts liv, hvor man enten står over for at investere mere, påtage sig større risiko eller indgå aftaler med partnere – og hvor det sandsynligvis er værdifuldt at have gjort sit hjemmearbejde. Den anden ting er, at der i den komplekse, sammenkoblede digitale verden, vi lever i, er mange afhængigheder mellem projektattributter, og milepæle er en god måde at synkronisere disse afhængigheder på. Man kan have to teams, der begge arbejder agilt, men på et tidspunkt har det ene teams arbejde brug for outputtet fra det andet. Milepæle er en god måde at koordinere den slags aktivitet på.

Galen Low

Det elsker jeg. Når man tænker over det, nævnte du nogle af de almindelige misforståelser om milepæle – at man fokuserer på sporing og rapportering. Hvilken indvirkning har det på et projekt, hvis man griber milepæle an på den måde i stedet for at tænke på teamafhængigheder?

John Carter

Der er så mange ting. For det første underminerer det enhver tro på, at ledelsen har tillid til teamet. Hvis projekterne er fyldt med masser af opfølgninger, ledelsesgennemgange og milepælsgennemgange, ser teamet hele tiden sig over skulderen og spekulerer på, hvad ledelsen tænker.

Det er en nedbrydende holdning, fordi den ikke styrker teamets selvtillid eller dets evne til på eget initiativ at levere et fremragende projekt, som de alle tror, de kan levere.

Desuden er det en byrde for teamet, fordi man hele tiden producerer rapporter, som kun skimmes, ikke læses eller hurtigt overses, samt kedelige diagrammer og opdateringer. Hvad er formålet med det? Er det at træffe en beslutning? Er det at kommunikere? Hvis det er for at kommunikere, kan man bruge projektdashboards, backlogge eller et hvilket som helst antal andre måder at kommunikere fremskridt på. Hvis det handler om beslutninger, hvad er det så, der virkelig skal løftes ud over teamet? Det er dér, man har brug for en stor milepæl. Og dem er der få af og langt imellem. Ideen er derfor at reducere hyppigheden og antallet af disse gennemgange og sikre, at de skaber værdi for teamet.

Det er virkelig vigtigt, og sådan kan man implementere milepæle, der er effektive.

Galen Low

Det kan jeg lide. Det handler mere om at udføre arbejdet end om at holde pause for at evaluere eller rapportere om det.

John Carter

Præcis. Præcis. Og så får ledelsen desværre mulighed for at tilføje værdi og lægge en masse tomme kalorier oven på teamet, som de derefter skal bruge energi på for at producere endnu en rapport, så nogen kan se mere. Det er en endeløs strøm af ledelse, der placerer stole i teamets vej, selv om ledelsen egentlig burde fjerne forhindringer og holde sig ude af vejen.

Og det er endnu en måde, hvorpå milepæle kan slå begge veje. For mange opmuntrer til detailstyring; det rigtige antal opmuntrer til den rigtige slags beslutningstagning.

Galen Low

Fantastisk. Var der et tidspunkt, hvor du satte projektet, du ledte, på pause og sagde: Okay, jeg gør det her på den forkerte måde. Det burde faktisk handle mere om teamet og teamwork end om rapportering?

John Carter

Ja, det var kort efter, at jeg blev forfremmet til chefingeniør hos Bose. I den situation havde jeg en tendens til at detailstyre, indkalde til flere gennemgange og indsætte flere projektmilepæle. Pludselig indså jeg, at jeg var ved at drukne, fordi jeg ikke kunne finde al den tid i ugen, der skulle til for at planlægge alle disse detaljerede gennemgange fyldt med detaljer. Den anden ting var, at det heller ikke hjalp teamene. Jeg druknede, teamene druknede. Så indså jeg – og det var så ydmygende – at nogle af disse teamledere og tekniske eksperter vidste langt mere end jeg gjorde. Langt mere. Jeg burde bare holde mig væk. Jeg vidste ikke, hvad jeg talte om. Den erkendelse, at en ingeniør i udviklingsorganisationen sagde, at jeg bare skabte forvrængning, forsinkelser og støj, var sandsynligvis det tidspunkt, hvor jeg holdt op med at gennemføre så mange milepælsgennemgange.

Galen Low

Da du stoppede, bemærkede du så en forskel fra den ene dag til den anden i den måde, teamet arbejdede på?

John Carter

Nej, ikke rigtigt. Jeg tror, det blev gradvist mere produktivt, og jeg blev meget gladere i mit arbejde. Jeg fandt ud af, at teamet faktisk udførte arbejdet lige så godt, hvis ikke bedre, uden min indblanding. Så jeg tror, at det, det gør, er at løfte sløret fra teamet, gøre dem mere produktive, gladere og mere tilfredse og få dem til at levere bedre produkter.

Galen Low

Ja, det er utroligt, hvor tung mistillid er. Når ting kommer fra et sted med mistillid, er det en tung byrde for teamet sammenlignet med tillid. Så bliver arbejdet gjort, og alle samarbejder og styrer sig selv effektivt.

John Carter

Ja, det er som en konstant ætsende atmosfære. Det er jeg enig i.

Galen Low

Lad os tale lidt mere om, hvordan man gør det på den rigtige måde, og hvordan det ser ud, når man gør det rigtigt, når det gælder projektmilepæle. Du nævnte, at milepæle er mere for teamet end for projektledere eller ledelsen. Hvordan lærer man et team at se det sådan, hvis man ikke allerede selv ser det på den måde?

John Carter

Det hænger faktisk sammen med det miljø præget af mistillid, som du talte om. Det, der er afgørende, er, at teamet har en kompetent produktejer, en kompetent scrum-master, en digital projektleder og en kompetent teknisk leder. Hvis man har de tre ting, bør ledelsen have tillid til én og til systemet. Hvis teamet er kompetent, er der ikke behov for konstant detailstyring. Derefter kan man arbejde med teamet, så de forstår: Her er de vigtigste milepæle, og her er grunden til, at de er vigtige. Det er efter min mening det vigtigste. Milepæle bør heller aldrig ligge med et fast interval.

Man bør ikke have ugentlige faste møder eller månedlige evalueringsmøder eller indkalde til sene gennemgange. Nogle er nødvendige, men generelt ikke på det detaljerede niveau. Pointen er, at milepæle skal være hændelsesdrevne.

De er projektdrevne. De afhænger af teamets hastighed, modenhed, størrelse, risiko osv. og naturligvis af udfordringen og opgaven. Det er en klar indikator: Hvis dine milepæle ligger på regelmæssige kalenderdatoer, er der et problem.

Galen Low

Det lyder næsten som mistillid. Det er som om, jeg vil følge op på dig hver anden uge.

John Carter

Præcis. Præcis.

Galen Low

Sikre, at det holder sig på sporet, i stedet for at sige: På dette tidspunkt er vi nødt til at se på, hvor vi står, fordi der er andre ting, der afhænger af det. Hvordan planlægger eller samarbejder vi om de næste skridt?

John Carter

Præcis. Eller vi skal skrive en check på syv cifre. Er vi sikre på, at vi gør det rigtige? Absolut.

Galen Low

Når du siger det sådan, ja, så er det meget vigtigt.

John Carter

Det kan være store checks.

Galen Low

Ja, helt sikkert. Og når det gælder om at vide, hvornår et team er klar, kan jeg godt lide at have de roller og vide, at de er stærke i den rolle, de spiller på teamet.

Hvilken adfærd forventer du af et team, der virkelig er klar til at eje sine egne milepæle og forstå, hvad de handler om?

John Carter

Galen, det er et fantastisk spørgsmål, og jeg tror, det kan besvares meget enkelt. Undskyld. Det handler om historik. Med andre ord: Har dette team tidligere været forudsigeligt? Indikerer deres historik, deres tidligere succeser og resultater et positivt udfald? Jeg tror, at hele denne tillid opbygges over tid. Den bedste målestok for ethvert projektteam er deres tidligere historik og succes i programmet. Det er det første og vigtigste, man har brug for. I hver af de centrale roller, for eksempel inden for produkt, har man brug for en person, der forstår hvorfor'et og hvad'et. De skal virkelig kende det stof, og teamet skal tro på dem. Det samme gælder den tekniske leder samt udvikling og kvalitetssikring: Man skal have tillid til deres evne til at træffe de rigtige arkitektoniske beslutninger og afvejninger for at nå projektets mål. For den digitale projektleder skal man have tillid til, at vedkommende er transparent. Når der er et problem, skal det gøres kendt hurtigt, og tingene må ikke skjules.

Jeg tror, at denne slags adfærd i de tre centrale roller sammen med historikken viser, om teamet er klar.

Galen Low

Det elsker jeg. Jeg elsker hele konceptet med teamsammensætning og strategi for teambuilding. Man ønsker erfarne mennesker, der går til det fra et modent perspektiv og forstår sammenhængen i det, de laver. De kan måske være støttet af mere junior medarbejdere. Der er bestemt stadig plads til dem. Men når du taler om at have de rigtige mennesker, mener du så erfarne teammedlemmer, der kan se på projektet og det produkt, de skaber, på den rigtige måde, så de kan forstå, hvad milepælen betyder, og hjælpe med at planlægge projektets milepæle?

John Carter

Absolut. Juniorroller kan sagtens være langt flere end seniorroller, men man har brug for – og jeg taler ikke om alder – erfaringscyklusser, såkaldte læringscyklusser. Hvis de har flere af dem bag sig, og det har været gode erfaringer, kan man bestemt have tillid til teamet. Absolut.

Galen Low

Læringscyklusser.

John Carter

Ja.

Galen Low

Det er fantastisk. Mit andet spørgsmål ville så være på den anden side. Hvis du arbejder med et ledelsesteam, der er vant til månedlige opfølgninger på milepæle eller til at have et dusin milepæle på meget kort tid, fordi de er så vant til at følge op og måske detailstyre – selv om de faktisk har tillid til teamet – hvordan får man så et ledelses- eller managementteam til at adoptere en anden måde at tænke på milepæle på, så de bliver færre og ligger længere fra hinanden, uden en fast rytme?

John Carter

Det er et rigtig godt spørgsmål. Og svaret er, Galen, at det kommer an på det. Hvis organisationen har en mekanisme til at give en form for mål for fremskridt, hvad enten det er backlogge, story points eller leverancer, der er færdiggjort, findes der alle mulige enkle målepunkter, som objektivt viser fremdrift. Det er vigtigt, at de er lette og objektive. De kan leveres som en stedfortræder. Udfordringen med ledere er, at de forveksler transparens og overvågning af projektets fremdrift med beslutningstagning. Det er to helt forskellige kommunikationsformer. Når det gælder sporing af fremdrift, kan det gøres med dashboards eller alle mulige transparente indikatorer, eller i værste fald på et møde.

Men kun med én person og med en hyppighed, der styres af behovet. Der er en forveksling hos ledere. Derfor skal vi forsikre dem om, at de kan se fremskridtene transparent, og at de får besked, hvis noget går galt. Selvom vi ikke rigtig talte om rammebetingelser i denne artikel, er der en idé om, at et team har grænser for, hvad der ligger inden for den tærskel, de har aftalt i forbindelse med deres digitale projektudvikling. Hvis de ikke kommer til at nå disse grænser, er det teamets ansvar at informere ledelsen. Hvis ledelsen derfor både kan se teamets fremskridt transparent og være sikker på, at der findes en mekanisme, så de hurtigt får dårlige nyheder, bør det være tilstrækkeligt. De kan have tillid til teamet, fordi de har set dets historik med disse tre faktorer. Så kan vi argumentere overbevisende over for ledelsen for behovet for færre milepæle.

Giver det mening, Galen?

Galen Low

Absolut. Jeg elsker den adskillelse og tydeliggørelse mellem rapportering og sporing på den ene side og beslutningstagning på den anden – hvilket i virkeligheden er det, milepæle handler om: Et tidspunkt, hvor man siger: Hvordan går det?

Ikke fremdriftsmæssigt, men på det tidspunkt, hvor vi skal ind i den næste fase eller tilføje et andet team, som skal samarbejde med os. Er vi klar til det? Er det stadig det rigtige at gøre?

John Carter

Præcis. Præcis. Er de klar til os?

Det er et godt punkt og en værdiskabende opfølgning.

Galen Low

Det leder mig til mit næste spørgsmål: Når vi planlægger milepæle, ændrer dette perspektiv på milepæle så den måde, vi faktisk opretter dem på fra begyndelsen eller udvikler vores projektplan? Hvis man tidligere tænkte: Vi følger op hvert kvartal, eller vi følger op, fordi vi skal opdatere styregruppen, ændrer det så den måde, man planlægger projekter på, hvis man tænker på milepæle som noget for projektet og teamet?

John Carter

Ja, helt sikkert. Alle de andre statusrapporter, opdateringer til styregruppen og så videre ville blive reduceret eller fjernet. Det, vi taler om, er en letvægtsramme til digital produktudvikling. Denne ramme bør have et sæt standardiserede vendepunkter, der passer til virksomheden. Forskellige organisationer har forskellige begrænsninger. Hvis man for eksempel fremstiller produkter, skal man bestille lager og dele. Det er en stor udgift. Man vil sandsynligvis sikre sig, at de rigtige dele er specificeret. Det er vigtigt. På samme måde vil man, hvis man forsøger at opskalere et digitalt projekt, sikre sig, at den rigtige form for instrumentering er inkluderet i produktet. Man vil sikre sig, at man kan få den type analyser, teamet ønsker. Det er vigtigt, at instrumenteringen er klar, når man lancerer produktet i stor skala. Det afhænger altså virkelig af, hvad virksomheden laver. Men disse milepæle bør generelt standardiseres. Der bør være få af dem. Jeg plejer at sige, at der bør være så lidt proces som muligt – og ikke mindre. Ideen er at gøre det let og indsætte standardmilepæle dér, hvor virksomheden typisk træffer de store beslutninger. Det bør være en lille håndfuld, måske tre til fem.

Galen Low

Jeg elsker eksemplet med produkter. Hvis man skal bestille dele, giver det bare mening. Man har disse afhængigheder, og før man gør det, vil man naturligvis sikre sig, at man er nået til et punkt, hvor det giver mening.

John Carter

Absolut. I typiske digitale udviklingsprojekter har man cloudaktiviteter, det der foregår på klienten, måske desktop, mange forskellige systemer, der skal integreres, og DevOps, der skal koordineres. Så hver virksomhed er forskellig.

Galen Low

En af de ting, jeg fandt virkelig fascinerende i din artikel, var, at du talte om tre store milepæle eller vendepunkter under et projekt, som skulle hænge sammen med de vigtigste forretningsmål. Kan du forklare lidt om, hvad de er, og hvorfor de er vigtige?

John Carter

Den første er efter min mening meget vigtig, især når man taler om innovation og den idé, vi kaldte innovation med stort I. Altså innovationer, der ændrer spillet. Helt i begyndelsen af dit digitale projekt skal du overveje, om konceptet virkelig stemmer overens med vores strategi. Passer det til, hvem vi er som brand? Er det den slags produkt eller idé, vi ønsker at bringe på markedet? Vil det flytte nålen, når det gælder omsætning eller avance? Vi kommer til at forpligte os til denne aktivitet i de næste tre, seks, ni eller måske 18 måneder og potentielt et stort team. Er det på linje med vores strategi, og vil det flytte nålen? Det første, man gør, er at kontrollere konceptet.

Den næstvigtigste ting, når man har et koncept, der stemmer overens med strategien, er at sikre sig, at man har produkt-marked-tilpasning. Har man faktisk noget, som forbrugerne vil vælge? Har man unikke salgsargumenter, der betyder noget for forbrugerne? Har man gennemslagskraft på markedet? Kan man tiltrække flere brugere eller skabe større indkøbskurvoplevelser eller hvad målet nu er? Har man dokumentation for sine anskaffelsesomkostninger? I den digitale tidsalder kan alt dette måles. Denne næste fase er virkelig vigtig, især før man opskalerer teamet, fordi man skal sikre sig, at man har produkt-marked-tilpasning.

Den sidste er udvikling og markedsintroduktion. Organisationen siger nu: Konceptet er på linje med strategien, og produktet passer til markedet. Forbrugerne kan virkelig lide det, vi laver. For at gøre dette til en funktionskomplet udgivelse, først en MVP og derefter en komplet version, hvad skal vi så udvikle for at få det ombord? Hvilke partnere har vi brug for på infrastruktursiden? Hvilke udviklingspartnere får vi brug for til de forskellige mobile platforme? Vi klarer desktop- og tabletarbejdet. Hvordan opdeler vi det? Vi skal investere i brugergrænseflade, grafisk design osv. Vi får brug for at bruge mange penge. Vil vi forpligte os til det? Det er beslutningen om at gå videre med udvikling og markedsintroduktion.

Det er altså de tre centrale vendepunkter, der styrer de fleste digitale produktudviklingsprojekter, og de kan naturligvis tilpasses. Måske er der en idefase, man vil sætte foran. Måske har man en mere udtrykkelig valideringsfase til sidst. Måske foregår der DevOps. Der er alle mulige detaljer, man kan føje til. Men med en fælles ramme kan ledere, når en virksomhed vokser, have nogle få standardmilepæle, så de kan sammenligne, hvor projekterne befinder sig. Det gør det muligt for ledere at styre forbruget over tid. De standardiserede milepæle og disse vigtige vendepunkter fortæller, hvor projektet reelt befinder sig i forhold til kundeinteresse og investering.

Galen Low

Jeg elsker idéen om at kunne sammenligne på tværs af projekter. Hvis man er en virksomhed, der udvikler flere projekter eller produkter på én gang, skal man se på denne pipeline og se, hvor tingene står – ikke projektets sundhed i forhold til fremdrift, men den faktiske sundhed i produktkonceptet, og hvordan produktet udvikler sig i forhold til lancering og behovet for bestemte ressourcer.

John Carter

Ja. Hvis man ser på de tre milepæle, vi talte om, var ingen af dem knyttet til et bestemt tidspunkt.

Galen Low

Mm-hm.

John Carter

De handlede alle om: Er det her på linje med strategien? Godt. Er der produkt-marked-tilpasning? Godt. Vil vi virkelig investere og bruge penge på at lancere dette produkt? Godt. Det er tre meget vigtige ikke-tidsbestemte elementer i programmet. Det bør bestemt ikke være for tungt for nogen organisation at styre disse tre.

Galen Low

Hvis man nu har oprettet disse tre i sin projektplan, er de så urokkelige? Mange ser milepæle i projektplanlægning som ting, der ikke kan flyttes. Hvad mener du om milepæle i den henseende?

John Carter

Der er forskel på håb og virkelighed. I ren agil softwareudvikling er det teoretisk muligt ikke at misse en milepæl. Men i virkeligheden misser eller flytter man en sprint i stedet for en milepæl. Selv i agil udvikling er der en idé som funktionskomplethed, der er meget vigtig. Jeg tror derfor, at disse milepæle er generiske, gælder i enhver situation og virkelig kan bidrage til at fremskynde innovation.

Galen Low

Det elsker jeg.

Jeg spekulerer på, om du måske kan tale om nogle eksempler, så det bliver mere konkret for vores lyttere. Hvad kunne en milepæl for koncepttilpasning være? Og hvad ville den efterfølgende produkt-marked-tilpasning være? Hvis du har eksempler fra den virkelige verden, må du gerne bruge dem, ellers kan du bruge et hypotetisk eksempel.

John Carter

Nej, jeg har for nylig oprettet systemet. Vi kaldte det venturebestyrelsen. Det var en venturekapitalenhed i en stor teknologiorganisation. Vi gennemgik denne grundlæggende ramme, og der kom nogle virkelig interessante og konkrete læringspunkter ud af det.

Noget, vi mener er meget vigtigt for koncepttilpasning, og som er et håndgribeligt eksempel på den slags milepæl, er først og fremmest, om det er på linje med virksomhedens sande nord. Vi ville ofte udarbejde et strategisk kort over projektidéer. Din idé kunne være på kortet, og der ville også være andre kandidater til digital udvikling. Kortet indeholder to dimensioner. Den ene er overensstemmelsen med strategien, det sande nord. Den anden er den økonomiske påvirkning. Hvor meget vil det flytte nålen? Først og fremmest ser man på koncepttilpasning: Vi har denne kurv af idéer. Vil den idé, du gerne vil udvikle, flytte nålen, og er den virkelig på linje med vores brand? Der findes en tjekliste til det.

Der findes også et strategisk kort, der kan hjælpe med denne type beslutning. Produkt-marked-tilpasning er anderledes, fordi den involverer eksterne parametre. Jeg tror, at anskaffelsesomkostningerne sandsynligvis er det vigtigste mål, man ser på i forbindelse med produkt-marked-tilpasning. Det kan også være en vigtig forståelse af det unikke salgsargument. Hvad ønsker forbrugerne? Det fører for eksempel tilbage til min erfaring med hovedtelefoner. Jeg var opfinderen, og sammen med dr. Bose var vi de to første på patentet. Da vi udviklede dem, gjorde vi det for at opnå bedre lyd. Basgengivelsen skulle faktisk være bedre og mere ensartet på tværs af forskellige hovedformer og bæresituationer osv.

Vi lagde dem i hænderne på folk. De var ligeglade med det. De ønskede støjreduktion. Så tro det eller ej, vi havde ikke rigtig produkt-marked-tilpasning, selv om vi var opfinderne. Derfor ændrede vi retning og fokuserede på at maksimere støjreduktionen i stedet for den samlede balance, frekvensresponsen og alt det andet. Produkt-marked-tilpasning er virkelig, virkelig vigtig, og den eneste måde, den kan måles korrekt på, er gennem kontakt med kunder i en eller anden form.

Den sidste milepæl er efter min mening et spørgsmål om, hvorvidt man har en forretningscase. Kort sagt: Giver regnestykket mening? Produkt-marked-tilpasningen er på plads, og det er i overensstemmelse med strategien. Nu skal man se på tallene. Overstiger den avance, man får fra produktet, i høj grad anskaffelsesomkostningerne? Hvor skal produktet lanceres osv.? Hvis man kan overbevise sig selv gennem regnestykket om, at man kan skabe et digitalt produkt med høj volumen og god indtjening, er det værd at gå videre. Det er de tre vendepunkter: strategisk tilpasning, anskaffelsesomkostninger og produkt-marked-tilpasning og endelig, om regnestykket går op. Det er tre centrale milepæle, som jeg har set virksomheder bruge effektivt. Man vil gennemgå dem med ethvert team, der skal skaleres, og det går tilbage til din pointe om, at milepæle ikke skal være tidsplanstyrede. Spørgsmålet er: Hvad skal gøre dette produkt succesfuldt?

Galen Low

Det, jeg godt kan lide, er, at beslutningspunktet i eksemplet med hovedtelefonerne ikke var: Vi skal starte forfra, eller det her er en fiasko, eller vi missede milepælen. I brugte det som et tidspunkt til at evaluere produktet, indså, at I skulle ændre retning, og brugte derefter resten af den tid, I havde, på at gøre det til det rigtige produkt.

John Carter

Ja. Og vi gjorde det tidligt. Det er det afgørende. Det er det afgørende.

Galen Low

Det kan jeg lide.

Jeg er nødt til at spørge, fordi du tidligere nævnte fokus på agil udvikling: Hvorfor har man stadig brug for milepæle? Bør projektledere, der planlægger et projekt ved hjælp af en agil metode, stadig interessere sig for milepæle? Hvordan ser de ud dér?

John Carter

Det er en almindelig og efter min mening meget dårlig misforståelse, at agil udvikling og milepæle ikke passer sammen. Faktum er, at næsten alle virksomheder, jeg kender, som siger, at de arbejder agilt, har milepæle. Ikke bare én; jeg kender et dusin. Det er en myte, der spredes af religiøse fanatikere – det siger jeg både med humor og en vis sandhed. Jeg holdt engang en præsentation for en gruppe af Scrum Masters, og det var første gang i måske fem år, at ordet vandfald blev nævnt i præsentationerne. Jeg forstår betydningen af agil udvikling, men det er ikke i konflikt med milepæle. Som vi talte om, Galen, har man brug for milepæle til at styre afhængigheder, og ethvert agilt program af en vis kompleksitet har afhængigheder. Som en del af Sprint 0 laver man en udgivelsesplan og fastlægger, i hvilken sprint disse afhængigheder skal indtræffe. Det er milepæle. Man kan kalde dem noget andet, men faktum er, at det er milepæle. For det andet vil enhver organisation, der står foran en stor investering i et digitalt projekt, spørge teamet: Er I klar til at bruge pengene? Er det en god investering? Det er en milepæl. Så jeg mener, at det er et falsk valg at stille agil udvikling op mod milepæle. De eksisterer fint sammen. De bedste systemer bruger begge dele.

Galen Low

Fantastisk. Ja, det ved jeg.

John Carter

Jeg vil også tilføje, at jeg tror på agil udvikling med lille a, altså hvilke agile praksisser man værdsætter, og som virkelig flytter virksomheden fremad på måder, man finder vigtige.

Jeg tror for eksempel, at sprintplanlægning kan være én ting, demonstrationer og kundefeedback kan være en anden. Men find ud af, hvad der er vigtigt for agil udvikling, og anvend det.

Galen Low

Det kan jeg virkelig godt lide. John, disse råd om produktmilepæle er alle meget værdifulde. Det, der især gjorde indtryk på mig, og som jeg tror vil ændre den måde, jeg arbejder på fremover, er idéen om standardiserede milepæle. Jeg havde aldrig tænkt på det som en måde også at måle på tværs af projekter eller som en måde at afstemme forventninger med interessenter og den øverste ledelse om, hvilke ting vi måler på tværs af alle vores projekter. Det driver virkelig beslutningstagningen, især når man står foran at underskrive en check på syv eller otte cifre for at finansiere den næste del eller bestille alle produkterne.

Det er min vigtigste pointe herfra.

John Carter

Godt. Og det er her...

Galen Low

Hvad er det første skridt, du vil anbefale til folk, der vil begynde at ændre den måde, de bruger milepæle på, og indføre denne tilgang?

John Carter

Det vigtigste er efter min mening, at de forstår, hvilke centrale beslutninger virksomheden skal træffe. Hvor er de få vigtige punkter, som hvert projekt virkelig skal igennem? Hvad er knudepunkterne? Hvilke områder er afgørende? Bliv enige om dem, og kald dem det samme. Det er ret enkelt: Bliv enige, kald dem det samme, og lad alle teams bruge dem. Det er en god måde at begynde på. Det var sådan, vi opskalerede Apples proces for nye produkter: Vi blev ganske enkelt enige om, hvilke få milepæle der skulle være, hvad vi skulle kalde dem, og hvad der skulle være gjort på hvert tidspunkt, og så begyndte vi at bruge det samme sprog. Det lyder enkelt, men det første skridt er faktisk at tilpasse sig.

Galen Low

Det giver god mening. Når man først er begyndt at bruge milepæle på denne måde, hvad er så det vigtigste at huske undervejs?

John Carter

Det handler om den cirkel omkring tillid, beslutningstagning og overvågning, som vi begyndte samtalen med. Hvis vi kan skabe et tillidsbaseret system med dygtige mennesker, der driver deres projekter, og hvis vi kan adskille milepælene, som kun er til beslutningstagning, kan vi overlade overvågningen til noget, der har meget lav friktion og giver lederne de oplysninger, de har brug for, uden at belaste teamet.

Galen Low

Det elsker jeg.

John, tusind tak, fordi du var med i programmet i dag. Jeg sætter virkelig pris på alle de indsigter, du har givet os. Jeg tror, det har ændret mit liv, og forhåbentlig også vil være betydningsfuldt for nogle af vores lyttere.

John Carter

Tak for muligheden for at tale om det. Du ved tydeligvis noget om emnet, og jeg tror, du har sammenfattet hovedpunkterne. Tak for denne mulighed, Galen.

Galen Low

Hvad synes du? Hvilke tips og tricks har du til projektmilepæle? Hvad virker? Hvad virker ikke? Fortæl os en historie. Hvornår har dine projektmilepæle svigtet dig? Hvilke bedste praksisser har ført til dine største sejre? Fortæl os det i kommentarerne nedenfor. Hvis du vil lære mere og komme foran i dit arbejde, så slut dig til vores fællesskab med DPM-medlemskab ved at gå til thedigitalprojectmanager.com/membership, hvor du får adgang til vores ekspertforum, mentorgrupper, workshops, live mentorsessioner, Spørg mig om hvad som helst-sessioner, e-bøger, skabeloner og meget mere. Hvis du kunne lide det, du hørte i dag, så abonnér, og hold kontakten på thedigitalprojectmanager.com. Indtil næste gang. Tak, fordi du lyttede.