Du kanske ser på milstolpar helt fel (med John Carter från TCGen)

Läs transkriberingen:

Vi testar att transkribera våra poddar med hjälp av ett program. Ha överseende med eventuella stavfel eftersom roboten inte har rätt till 100 procent hela tiden.

Galen Low

Där sitter du alltså och stirrar på din projektplan igen och fasar för just de milstolpar som du själv hjälpte till att skapa. De verkar krypa närmare varje gång du tittar på dem, ungefär som diamantformade Space Invaders. I början verkar de så harmlösa: de var bara streck i sanden som skulle hjälpa dig att planera i större drag. Nu är de en tyngd runt halsen: tunga, orubbliga deadlines som inte går att resonera med. De är viskningarna av tvivel som hotar att dra in dig i ett draknäste av arga intressenter när den ödesdigra dagen kommer. Om det här låter bekant måste jag tyvärr berätta att du är en av de projektledare som har använt projektmilstolpar helt fel. Oroa dig inte, de flesta av oss sitter i samma båt. Men om du vill förvandla dina projektmilstolpar från en skräckinjagande börda till en ledstjärna för samarbete mellan team och intressenter, så fortsätt lyssna.

Tack för att du lyssnar. Jag heter Galen Low och arbetar med Digital Project Manager. Vi är en gemenskap av digitala yrkesverksamma med uppdraget att hjälpa varandra att utveckla kompetens, bygga självförtroende och skapa kontakter så att vi kan leverera bättre projekt. Om du vill höra mer om det kan du gå till thedigitalprojectmanager.com.

Okej. Hej allihop, tack för att ni hänger med oss i DPM-podden. Min gäst i dag är en mycket respekterad expert på produktutveckling och dessutom väl bekant med projektledning. Han är en av de viktigaste hjärnorna bakom Boses brusreducerande hörlurar och Apples process för att utveckla nya produkter. I dag ger hans företag, TCGen, råd till tunga varumärken som Amazon, Apple, Cisco, Hewlett-Packard, IBM, Mozilla, Roche och 3M. Han har dessutom nyligen anlitat en lärare för att lära sig musikteori och komponerar nu musik. Så, mina vänner, välkomna John Carter. Hej, John.

John Carter

Hej Galen. Trevligt att vara här.

Galen Low

Fantastiskt att ha dig med i programmet. Jag uppskattar det verkligen. John, ditt CV. När jag tittade på det tänkte jag: alla är förmodligen avundsjuka på ditt CV. Vi talar om produktinnovation för Bose, arbete med Apple, att nu driva ett eget företag och skriva böcker. Så jag tänkte börja med att fråga: vad ville du bli när du blev stor?

John Carter

Det är en rolig fråga. Och faktiskt gör jag fortfarande det på fritiden, nämligen är ingenjör. Jag har alltid velat designa saker, göra beräkningar och förutsäga prestanda. Det är något som har drivit mig ända till i dag. Det driver mig fortfarande.

Galen Low

Jag älskar det! Var det en stor inspiration att ge sig in mer på innovationsområdet? Jag föreställer mig att ingenjörstänkandet lämpar sig väl för att skapa nya saker som är livskraftiga, genomförbara och som människor faktiskt kommer att använda.

John Carter

Jag är inte säker på att det var så genomtänkt när jag började, men jag var den prototypiska pojkvetenskapsmannen. Jag hade ett kemiset, ett mikroskop och ett teleskop. Jag tog amatörradiocertifikat. Jag gjorde alla de där nördiga sakerna. Jag älskade verkligen det jag gjorde. Och jag tror att det hänger ihop med det jag tycker om att göra nu: jag älskade elektronik och det faktum att man inte kunde se elektricitet eller elektroner, men ändå kunde mäta dem och göra något med dem. I dag kan man göra samma sak med ljud. Man kan inte se det, men det påverkar starkt hur man känner och tänker och så vidare. Jag har därför alltid tyckt om att försöka förstå fenomen som man inte kan se.

Galen Low

Där ser man. Fanns det något inspirerande ögonblick när du bestämde dig för att ta det här ur ett ingenjörssammanhang och rikta det mer mot teknik, den digitala världen eller produkter?

John Carter

På sätt och vis växte det fram helt naturligt genom mitt arbete med dr Bose på Bose Corporation, där jag började. Han var fenomenal på både marknadsföring och ingenjörskonst samtidigt – det är en mycket, mycket ovanlig förmåga. Han ställde grundläggande frågor om vad människor bryr sig om, vad de vill göra och vad som är viktigt för dem. Genom hans sätt att leva och se på livet förstod jag verkligen vikten av att försöka förstå kundernas behov och säkerställa att man levererar det som verkligen är viktigt för dem. Vi lärde oss det på så många sätt. Även som uppfinnare hade vi egentligen ingen aning om vad kunderna skulle värdesätta förrän vi lade produkten i deras händer. Jag tror därför att det var en gradvis introduktion genom dr Boses enorma marknadsinsikter som fick mig att gå från ren ingenjörskonst till innovation.

Galen Low

Det är fantastiskt. Jag älskar det. Du har gjort så mycket under din karriär – finns det något du försöker bli bättre på nu för tiden?

John Carter

Alltid, alltid. Det finns ett par saker. En sak som jag tycker är väldigt intressant är mötet mellan agilt arbetssätt och projektledning. Jag tycker att det är fascinerande. Den andra saken är konsekvenserna av det jag skulle kalla digital produktutveckling. Hur är det att arbeta med maskininlärning jämfört med typisk produktutveckling? Hur innoverar man i den typen av digital miljö och i hela den nya verkligheten med distansarbete? Det är fascinerande att se vad som händer. Jag försöker verkligen förstå vad som driver innovationens utvecklingsfront.

Galen Low

Fantastiskt. Jag älskar det.

Jag ville också fråga: har du nyligen upptäckt något annat som verkligen gör livet bättre?

John Carter

Jag tror att en av de saker som verkligen har förnyat min tro på mänskligheten är förmågan att fortsätta innovera. Om man ser på problemen vi har framför oss och på hur världen i princip har tvingats ställa om när det gäller distansarbete, utbildning och utveckling och leverans av läkemedel, så finns det positiva omvandlingar som är ett resultat av den kris vi befinner oss i. Det stärker verkligen min tilltro till vår förmåga att överträffa alla situationer vi ställs inför genom innovation. Det ger mig mycket hopp.

Galen Low

Jag älskar den ljusglimten i ett annars kanske mindre optimalt år för oss. Fantastiskt. Jag tänkte att vi kanske kunde prata om ditt nyligen publicerade inlägg på Thedigitalprojectmanager.com om projektmilstolpar. För det första fick det mig att känna att jag hade hanterat projektmilstolpar helt fel. För det andra fick det mig verkligen att tänka på kopplingen mellan projektmilstolpar och en produkts framgång eller misslyckande på marknaden, vilket är ett sätt att se på problemet som jag aldrig riktigt hade övervägt tidigare. Men jag tänkte att vi kanske kunde spola tillbaka och börja från början. Vad är projektmilstolpar enligt dig, och varför borde någon bry sig om dem?

John Carter

Det är en bra fråga och en bra utgångspunkt, eftersom jag tror att människors uppfattningar om milstolpar är felaktiga när det gäller digital projektledning. Felet är att milstolpar inte är ett sätt att mäta framsteg. Det finns många andra, mycket bättre sätt att mäta framsteg som inte sliter ut teamet, producerar mängder av irrelevanta rapporter och sedan leder till detaljstyrning eftersom man plötsligt känner till fler saker. Den vanliga missuppfattningen är att man använder milstolpar för uppföljning. Men om man tittar på vad milstolpar egentligen är, så är de brytpunkter i projektet. De är kritiska perioder eller beslutspunkter under ett projekts liv där man antingen ska investera mer, ta på sig större risk eller göra arrangemang och överenskommelser med partner och liknande – sådant som förmodligen förtjänar att man gör sitt hemarbete. En annan sak är att det i den komplexa, sammanlänkade digitala värld vi lever i finns många beroenden mellan projektets olika egenskaper, och milstolpar är ett utmärkt sätt att synkronisera beroenden. Två team kan arbeta agilt, men det finns en punkt där det ena teamets arbete behöver resultatet från det andra. Milstolpar är ett bra sätt att samordna den typen av aktivitet.

Galen Low

Jag gillar det. När man tänker igenom det du säger och de vanliga missuppfattningarna om milstolpar – att man fokuserar på uppföljning och rapportering – vilken påverkan får det på ett projekt om man använder milstolpar på det sättet i stället för att tänka på teamets beroenden?

John Carter

Det finns så många effekter. För det första urholkar det tron på att ledningen litar på teamet. Om projekten är fyllda av avstämningar, ledningsgranskningar och milstolpsgranskningar tittar teamet hela tiden över axeln och undrar vad ledningen tänker.

Det är en nedbrytande inställning eftersom den inte stärker teamets självförtroende eller dess förmåga att på eget initiativ leverera ett utmärkt projekt – något som alla i teamet tror att de kan göra.

Dessutom blir det en belastning för teamet eftersom man hela tiden producerar rapporter som skummas igenom, inte läses eller bara kastas ett snabbt öga på, liksom omständliga diagram och uppdateringar. Vad är poängen? Är det för att fatta ett beslut? Är det för att kommunicera? Om det handlar om kommunikation kan man använda projektdashbord, ärendeköer eller hur många andra metoder som helst för att kommunicera framsteg. Om det handlar om beslut, vad behöver egentligen lyftas utanför teamet? Det är då man behöver en stor milstolpe. Och sådana är få och sällsynta. Tanken är alltså att minska frekvensen och antalet granskningar och se till att de skapar värde för teamet.

Det är verkligen viktigt när man ska införa effektiva milstolpar.

Galen Low

Jag gillar det. Det handlar mer om att utföra arbetet än om att pausa för att utvärdera eller rapportera om det.

John Carter

Precis. Och sedan får ledningen den olyckliga idén att den ska ”skapa värde” och lägger på en massa tomma kalorier som teamet måste förbruka för att producera ännu en rapport så att någon kan se mer. Det blir en ändlös mängd hinder som ledningen placerar i teamets väg, när ledningen egentligen borde undanröja hinder och hålla sig ur vägen.

Det är ytterligare ett sätt som milstolpar kan slå åt två håll. För många uppmuntrar detaljstyrning; rätt antal uppmuntrar rätt sorts beslutsfattande.

Galen Low

Fantastiskt. Fanns det någon gång när du pausade i ett projekt du ledde och tänkte: Okej, jag gör det här på fel sätt? Det här borde egentligen handla mer om teamet och lagarbetet än om rapportering?

John Carter

Ja, det var kort efter att jag hade befordrats till chefsingenjör på Bose. I den situationen hade jag en tendens att detaljstyra, kräva fler granskningar och lägga in fler projektmilstolpar. Plötsligt insåg jag att jag höll på att gå under eftersom jag inte kunde hitta all den tid under veckan som krävdes för att schemalägga alla dessa detaljer, alla dessa granskningar fyllda av detaljer. Den andra saken var att det inte heller hjälpte teamen. Jag drunknade och teamen drunknade. Sedan insåg jag – och det här var så pinsamt – att några av dessa teamledare och tekniska experter kunde mycket mer än jag. Mycket mer. Jag borde bara hålla mig ur vägen. Jag visste inte vad jag pratade om. När en ingenjör i utvecklingsorganisationen sa att jag bara skapade förvrängning, förseningar och brus, var det förmodligen då jag slutade göra så många milstolpsgranskningar.

Galen Low

När du slutade, märkte du då någon skillnad över en natt i hur teamet arbetade?

John Carter

Nej, inte direkt. Jag tror att teamet blev gradvis mer produktivt och att jag blev mycket lyckligare i mitt arbete. Jag upptäckte att teamet faktiskt levererade lika bra, om inte bättre, utan min inblandning. Jag tror att det man gör är att lyfta slöjan från teamet och göra dem mer produktiva, lyckligare och mer nöjda, så att de kan leverera bättre produkter.

Galen Low

Ja, det är fantastiskt vilken tyngd misstro kan skapa. När saker kommer ur misstro blir det en tung börda för teamet, jämfört med förtroende – då vet man att jobbet blir gjort och att alla samarbetar och leder sig själva effektivt.

John Carter

Ja, det är som en ständigt närvarande frätande atmosfär. Jag håller med.

Galen Low

Fantastiskt. Låt oss prata lite mer om hur man gör det på rätt sätt och hur det ser ut när man gör rätt, när det gäller projektmilstolpar. Du nämnde att milstolpar är mer till för teamet än för projektledare eller ledning. Hur formar man ett team så att det ser det på samma sätt, om man inte redan gör det?

John Carter

Det här går faktiskt tillbaka till den miljö av misstro som du beskrev. Det som är avgörande är att teamet har en kompetent produktägare, en kompetent Scrum-master, en digital projektledare och en kompetent teknisk ledare. Om du har de tre sakerna bör ledningen lita på dig och på systemet. Om teamet är kompetent finns det inget behov av ständig detaljstyrning. Då kan du arbeta med teamet så att de förstår vilka de viktigaste milstolparna är och varför de är viktiga. Jag tror att det är det allra viktigaste. Milstolpar ska dessutom aldrig ligga med fasta intervall.

Du ska alltså inte ha stående veckomöten eller månatliga granskningsmöten eller kalla till sena granskningar. Vissa behövs, men generellt inte på detaljnivå. Milstolpar bör vara händelsestyrda.

De ska vara projektstyrda. De ska baseras på teamets hastighet, mognad, storlek, risk och så vidare, liksom naturligtvis på utmaningen och uppgiften. Om dina milstolpar ligger på regelbundna kalenderdatum är det en tydlig indikation på att det finns ett problem.

Galen Low

Det signalerar nästan misstro. Som att säga: Jag ska kontrollera dig varannan vecka.

John Carter

Precis. Precis.

Galen Low

Se till att allt går på räls, i stället för att säga: Lyssna, nu behöver vi titta på var vi befinner oss eftersom andra saker är beroende av det. Hur ska vi planera eller samarbeta kring nästa steg?

John Carter

Precis. Eller så ska vi skriva en check på sjusiffrigt belopp. Är vi säkra på att vi gör rätt? Absolut.

Galen Low

När du uttrycker det så blir det väldigt viktigt.

John Carter

Det kan handla om stora checkar.

Galen Low

Ja, verkligen. När det gäller att veta när ett team är redo gillar jag att ha de rollerna och att veta att de är starka i sina respektive roller i teamet. Vilka beteenden förväntar du dig av ett team som verkligen är redo att äga sina egna milstolpar och förstå vad de handlar om?

John Carter

Galen, det här är en fantastisk fråga och jag tror att den kan besvaras mycket enkelt. Ursäkta. Svaret är: historik. Har teamet varit förutsägbart tidigare? Visar deras historik, deras tidigare framgångar och prestationer, på ett positivt resultat? Hela det här med förtroende byggs över tid. Det bästa sättet att bedöma ett projektteam är naturligtvis deras tidigare historik och framgångar i programmet. Det är det första och viktigaste du behöver. I var och en av de centrala rollerna behöver du till exempel någon inom produkt som förstår varför och vad. De måste verkligen kunna det och teamet måste tro på dem. Samma sak gäller den tekniska ledaren samt utveckling och kvalitetssäkring: du måste lita på deras förmåga att fatta rätt arkitekturbeslut och göra rätt avvägningar för att nå projektmålen. När det gäller den digitala projektledaren måste du kunna lita på att personen är transparent. När det uppstår ett problem ska de göra det känt snabbt och inte dölja något.

Jag tror att den här typen av beteenden i de tre centrala rollerna, tillsammans med historiken, visar att teamet är redo.

Galen Low

Jag älskar det. Jag gillar hela tanken på teamsammansättning och strategi för teambyggande. Man vill ha erfarna personer som angriper arbetet ur ett moget perspektiv och förstår sammanhanget i det de gör. De kan naturligtvis få stöd av mer juniora personer – det finns definitivt plats även för dem. Men när du talar om att ha rätt personer menar du då erfarna teammedlemmar som kan se på projektet och produkten de skapar på rätt sätt, så att de förstår vad milstolpen betyder och kan hjälpa till att planera projektets milstolpar?

John Carter

Absolut. Juniora roller kan vara betydligt fler än seniora roller, men du behöver – och jag talar inte om ålder – erfarenhetscykler, så kallade lärandecykler. Om de har flera sådana bakom sig och det har varit goda erfarenheter kan du definitivt lita på teamet.

Galen Low

Lärandecykler.

John Carter

Ja.

Galen Low

Det är bra. Min andra fråga gäller den andra sidan. Om du arbetar med ett ledningsteam som är vant vid månatliga avstämningar kring milstolpar, eller vid att ha ett dussin milstolpar under en mycket kort period, eftersom de är så vana vid att kontrollera och kanske detaljstyra – även om de faktiskt litar på teamet – hur får man ett sådant ledarskaps- eller ledningsteam att börja tänka annorlunda kring milstolpar, så att de blir färre, ligger längre från varandra och inte följer en regelbunden rytm?

John Carter

Det är en väldigt bra fråga. Och svaret är: det beror på. Om organisationen har en mekanism för att tillhandahålla någon form av mått på framsteg – oavsett om det handlar om ärendeköer, story points eller leveranser som har slutförts – finns det alla möjliga enkla mått som objektivt visar framsteg. Jag tycker att det är mycket viktigt att de är lättviktiga och objektiva. De kan fungera som en ersättning. Utmaningen med chefer är att de blandar ihop transparens och uppföljning av projektets framsteg med beslutsfattande. Det är två helt olika former av kommunikation. När det gäller uppföljning av framsteg kan det göras med dashbord eller alla möjliga transparenta indikatorer. I värsta fall kan det göras i ett möte.

Men då med en enda person och med en frekvens som styrs av behovet. Chefer blandar ofta ihop sakerna. Vi måste därför försäkra dem om att de kan se framstegen transparent och att de får veta om något går fel. Även om vi inte pratade så mycket om gränsvillkor i artikeln finns det en tanke om att teamet har gränser för vad som ryms inom det de har kommit överens om i sin digitala produktutveckling. Om de inte kommer att nå detta är det teamets ansvar att informera ledningen. Om ledningen alltså kan se teamets framsteg transparent och samtidigt lita på att det finns en mekanism som gör att de snabbt får dåliga nyheter, bör det vara tillräckligt. Om de dessutom litar på teamet eftersom de har sett dess historik utifrån de här tre faktorerna kan vi lägga fram ett övertygande argument för färre milstolpar.

Låter det rimligt, Galen?

Galen Low

Absolut. Jag gillar den uppdelningen och åtskillnaden mellan rapportering och uppföljning å ena sidan och beslutsfattande å andra sidan. Det är egentligen det milstolpar handlar om: ett ögonblick då man säger, hur går det?

Inte när det gäller framsteg, utan den punkt där vi skulle gå in i nästa fas eller lägga till ett annat team för att samarbeta med oss. Är vi redo för det? Är det fortfarande rätt sak att göra?

John Carter

Precis. Är de redo för oss?

Det är en bra poäng och en avstämning som skapar värde.

Galen Low

Det leder mig till nästa fråga: när vi planerar milstolpar, förändrar det här perspektivet på milstolpar sättet vi skapar dem från början eller utvecklar vår projektplan? Om vi till exempel gör en avstämning varje kvartal eller behöver uppdatera styrgruppen – förändrar det hur man planerar projekt om man ser milstolpar som något för projektet och teamet?

John Carter

Ja, absolut. Alla andra statusrapporter och uppdateringar till styrgruppen skulle minska eller försvinna. Det vi talar om är ett lättviktigt arbetsramverk för digital produktutveckling. Ramverket bör ha en uppsättning standardiserade brytpunkter som passar verksamheten. Olika organisationer har olika begränsningar. Om du tillverkar produkter måste du till exempel beställa lager och delar. Det är en stor utgift, så du vill förmodligen säkerställa att rätt delar har specificerats. Det är viktigt. På samma sätt vill du, om du ska skala upp ett digitalt projekt, se till att rätt typ av mätinstrumentering finns i produkten. Du vill säkerställa att du kan få den typ av analysdata som teamet behöver. Det är viktigt att instrumenteringen är klar när du lanserar produkten. Det beror alltså verkligen på verksamheten. Men milstolparna bör i allmänhet vara standardiserade. Det bör vara få av dem. Jag brukar säga att det ska finnas så lite process som möjligt, men inte mindre än så. Tanken är att göra processen lättviktig och lägga in standardmilstolpar där verksamheten vanligtvis fattar de stora besluten. Det bör vara ett litet antal – jag skulle säga tre till fem.

Galen Low

Jag gillar exemplet med produkter. Om du måste beställa delar är det logiskt. Du har beroenden och vill naturligtvis säkerställa att du befinner dig vid en punkt där det är klokt att gå vidare innan du gör det.

John Carter

Absolut. När det gäller typisk digital utveckling har du aktiviteter i molnet, det som händer hos kunden och kanske även datorprogram. Du har många olika system som behöver integreras och DevOps som måste samordnas. Varje verksamhet är annorlunda.

Galen Low

En av sakerna jag tyckte var särskilt fascinerande i din artikel var att du talade om tre stora milstolpar eller brytpunkter under ett projekt som skulle motsvara viktiga affärsmål. Kan du förklara vad de är och varför de är viktiga?

John Carter

Den första är mycket viktig, särskilt när man talar om innovation och det vi kallade innovation med stort I. Det handlar om innovationer som förändrar spelplanen. I början av ett digitalt projekt vill du fråga dig om konceptet verkligen är i linje med vår strategi. Passar det vilka vi är som varumärke? Är det här en produkt eller idé som vi vill ta ut på marknaden? Kommer det att påverka intäkter eller marginaler? Vi kommer att ägna de kommande tre, sex, nio eller arton månaderna åt detta och kanske använda ett stort team. Är det i linje med vår strategi och kommer det att göra verklig skillnad? Det första man gör är alltså att kontrollera konceptet.

Den näst viktigaste saken, när man har ett koncept som är i linje med strategin, är att säkerställa produkt–marknadsanpassning. Har du faktiskt något som konsumenterna kommer att välja? Har du unika säljargument som är meningsfulla för konsumenterna? Har du någon form av livskraft på marknaden? Kan du uppmuntra fler användare eller större kundvagnsupplevelser, eller vad målet nu är? Har du belägg för anskaffningskostnaden? Alla de här sakerna går nu att mäta i digitala projekt och produkter. Den här fasen är därför viktig, särskilt innan du skalar upp teamet: säkerställ produkt–marknadsanpassningen.

Den sista milstolpen är utveckling och marknadslansering. Organisationen säger då: konceptet är i linje med strategin och produkten passar marknaden – konsumenterna gillar verkligen det vi gör. För att göra detta till en komplett MVP och sedan en komplett produkt, vad behöver vi utveckla? Vilka partner behöver vi på infrastruktursidan? Vilka utvecklingspartner behöver vi för olika mobila plattformar? Vi gör arbetet för datorer och surfplattor. Hur ska vi dela upp detta? Vi måste investera i användargränssnitt, grafisk design och så vidare. Vi kommer att behöva göra en stor investering. Ska vi binda oss till det? Det är åtagandet att gå vidare med utveckling och marknadslansering.

Det här är alltså tre centrala brytpunkter som styr den mesta digitala produktutvecklingen, även om de naturligtvis kan anpassas. Kanske vill du lägga till en idéfas i början. Kanske har du en tydligare valideringsfas i slutet. Kanske pågår DevOps-arbete. Det finns alla möjliga delar du kan lägga till. Men när ett företag skalar upp vill man ha ett gemensamt ramverk och några standardmilstolpar, så att ledningen kan jämföra var projekten befinner sig. Det gör det möjligt att styra investeringarna över tid. De standardiserade brytpunkterna visar var projektet verkligen befinner sig i fråga om kundåtkomst och investering.

Galen Low

Jag gillar tanken på att jämföra projekt, särskilt om ett företag utvecklar flera projekt eller produkter samtidigt. Man behöver se på den här portföljen och förstå var saker befinner sig – inte projektets hälsa i form av framsteg, utan den faktiska produktidéns hälsa och hur produkten utvecklas i relation till lansering och resursbehov.

John Carter

Om man tittar på de tre milstolparna vi talade om var ingen av dem knuten till en viss tid.

Galen Low

Mm.

John Carter

De handlade alla om: Är detta i linje med strategin? Bra. Finns det produkt–marknadsanpassning? Bra. Vill vi verkligen investera och lägga pengar på att lansera den här produkten? Bra. Det är tre mycket viktiga, icke-tidsbundna delar av programmet. Att hantera dessa tre kan knappast vara för betungande för någon organisation.

Galen Low

Om man har de här tre inlagda i projektplanen, är de då orubbliga? Många uppfattar projektplaneringens milstolpar som sådant som inte kan flyttas. Hur ser du på det?

John Carter

Det finns en skillnad mellan förhoppning och verklighet. Vid ren agil mjukvaruutveckling är det teoretiskt möjligt att inte missa en milstolpe. Men egentligen missar eller flyttar man en sprint, inte en milstolpe. Även inom agil utveckling finns det begrepp som att en funktion är komplett, vilket är mycket viktigt. Jag tror därför att de här milstolparna är generella, gäller i alla situationer och verkligen kan bidra till att snabba på innovation.

Galen Low

Jag älskar det. Kan du ge några exempel så att det blir mer konkret för våra lyssnare? Vad skulle en milstolpe för konceptpassning kunna vara, och vad skulle den efterföljande produkt–marknadsanpassningen kunna vara? Om du har verkliga exempel får du gärna använda dem, annars går ett hypotetiskt exempel bra.

John Carter

Jag har nyligen satt upp ett system som vi kallade Venture Board. Det var en riskkapitalfunktion inom en stor teknikorganisation. Vi gick igenom det här grundläggande ramverket och fick fram några mycket intressanta och konkreta lärdomar.

När det gäller konceptpassning är ett konkret exempel att först säkerställa att idén ligger i linje med företagets sanna riktning. Vi brukade ofta skapa en strategisk karta över projektidéer. Din idé kunde finnas på kartan tillsammans med andra kandidater för digital utveckling. Kartan innehöll två dimensioner. Den ena var anpassningen till strategin, den sanna riktningen. Den andra var ekonomisk påverkan: hur mycket kommer idén att göra skillnad? Först och främst tittar man alltså på konceptpassningen: vi har den här samlingen idéer – kommer idén du vill utveckla att göra skillnad och är den verkligen i linje med varumärket? Det finns en checklista för detta.

När det gäller produkt–marknadsanpassning är det annorlunda eftersom den omfattar externa parametrar. Anskaffningskostnaden är förmodligen det viktigaste måttet. Men det handlar också om att förstå det unika säljargumentet. Vad vill konsumenterna ha? Det går till exempel tillbaka till mina erfarenheter av hörlurar. Jag var uppfinnaren och stod tillsammans med dr Bose som de två första på patentet. När vi utvecklade dem gjorde vi det för bättre ljud: bättre bas och jämnare ljud för olika människors huvuden och användningssituationer.

När vi lade dem i människors händer brydde de sig inte om det. De ville ha brusreducering. Tro det eller ej, men vi hade alltså inte verklig produkt–marknadsanpassning trots att vi var uppfinnarna. Vi ändrade därför inriktning och fokuserade på maximal brusreducering, inte på total balans och frekvensåtergivning. Produkt–marknadsanpassning är verkligen viktig, och det enda sättet att mäta den på riktigt är kontakt med kunder i någon form.

Den sista milstolpen är affärsfallet. Finns det verkligen en ekonomisk logik? Hur ser anskaffningskostnaden ut? Produkten passar marknaden och är i linje med strategin, men hur ser matematiken ut? Överstiger marginalen på produkten anskaffningskostnaden med god marginal? Var behöver produkten lanseras? Om du kan visa att matematiken fungerar och att du kan skapa en lönsam digital produkt med hög volym är det värt att gå vidare. Det är de tre brytpunkterna: strategisk passning, anskaffningskostnad och kundens produkt–marknadsanpassning, och slutligen om kalkylen går ihop. Det är tre viktiga milstolpar som jag har sett företag använda effektivt. Man vill gå igenom dem med alla team som ska skala upp. Det går tillbaka till din poäng om att milstolpar inte ska vara schemastyrda – frågan är vad som gör produkten framgångsrik.

Galen Low

Det jag gillar är att det i hörlurarsexemplet inte var: Okej, vi måste börja om, det här är ett misslyckande eller vi missade milstolpen. Ni använde det som en punkt för att utvärdera produkten, insåg att ni behövde ändra riktning och använde sedan resten av tiden till att göra den rätt.

John Carter

Precis. Och vi gjorde det tidigt. Det är nyckeln.

Galen Low

Jag gillar det.

Jag måste fråga: med fokus på agilt arbetssätt, varför behöver man fortfarande milstolpar? Bör projektledare som planerar projekt med en agil metod fortfarande bry sig om milstolpar? Hur ser de ut där?

John Carter

Det här är en vanlig och enligt mig mycket dålig missuppfattning: att agilt arbetssätt och milstolpar inte är förenliga. Faktum är att nästan alla företag jag känner till som säger att de arbetar agilt har milstolpar. Inte bara en – jag känner till ett dussin. Det är en myt som sprids av religiösa fanatiker, säger jag med både humor och viss sanning. Jag höll en gång en presentation för en grupp Scrum-masters, och det var första gången på kanske fem år som ordet vattenfallsmodell nämndes i presentationerna. Jag förstår betydelsen av agilt arbetssätt, men det står inte i konflikt med milstolpar. Som vi har talat om behöver man milstolpar för att hantera beroenden, och alla agila program av någon komplexitet har beroenden. Som en del av sprint noll gör man en lanseringsplan och avgör och kartlägger i vilken sprint dessa beroenden kommer in. Det är milstolpar. Man kan kalla dem något annat, men i sak är de milstolpar. Dessutom kommer varje organisation som ska investera stort i ett digitalt projekt att fråga teamet: Är ni redo att spendera? Är det här en bra investering? Det är en milstolpe. Agilt arbetssätt kontra milstolpar är alltså ett falskt motsatspar. De fungerar mycket bra tillsammans. De bästa systemen använder båda.

Galen Low

Fantastiskt.

John Carter

Jag vill också tillägga att jag tror på agilt arbetssätt med litet a – vilka agila metoder värdesätter du och vilka driver verkligen verksamheten framåt på sätt som är viktiga för dig?

Jag tror till exempel att sprintplanering kan vara en sådan metod. Demonstrationer och kundåterkoppling kan vara andra. Ta reda på vad som är viktigt i ett agilt arbetssätt och använd det.

Galen Low

Jag gillar verkligen det. John, de här tipsen om produktmilstolpar är mycket värdefulla. Det som verkligen fastnade hos mig och som jag tror kommer att förändra hur jag arbetar framöver är tanken på standardiserade milstolpar. Jag hade aldrig tänkt på dem som ett sätt att jämföra projekt, eller som ett sätt att skapa förväntningar hos intressenter och ledning kring vad vi mäter i alla våra projekt och hur vi driver beslutsfattandet – särskilt när man ska skriva under en check på sju eller åtta siffror för att finansiera nästa del eller beställa alla delar.

Det är min stora lärdom av det här.

John Carter

Bra.

Galen Low

För dem som vill börja förändra hur de använder milstolpar och ta till sig det här – vilket är det första steget du rekommenderar?

John Carter

Det viktigaste är att förstå vilka centrala beslut verksamheten måste fatta. Var finns de få viktiga punkter som varje projekt verkligen måste passera? Vilka är flaskhalsarna? Vilka är de viktiga områdena? Kom överens om dem och kalla dem samma sak. Det är ganska enkelt: kom överens, använd samma namn och låt varje team använda dem. Det är ett bra sätt att börja. Så skalade vi Apples process för nya produkter: vi kom helt enkelt överens om vilka få milstolparna var, vad vi skulle kalla dem och vad som behövde vara gjort vid varje milstolpe. Sedan började vi använda samma språk. Det låter enkelt, men det första steget är faktiskt att anpassa sig.

Galen Low

Det låter väldigt rimligt. När man väl har kommit igång och använder milstolpar på det här sättet, vad är då det viktigaste att komma ihåg längs vägen?

John Carter

Det går tillbaka till det vi började samtalet med: kretsloppet mellan förtroende, beslutsfattande och uppföljning. Om vi kan skapa ett system byggt på förtroende, baserat på kompetenta personer som driver sina projekt, och skilja ut milstolparna som endast är till för beslutsfattande, kan vi lämna uppföljningen till något som kräver mycket liten friktion och ger ledningen den information den behöver utan att belasta teamet.

Galen Low

Jag älskar det.

John, tack så mycket för att du ville vara med i programmet i dag. Jag uppskattar verkligen alla insikter du har delat med oss. Jag tror att det har förändrat mitt liv och förhoppningsvis också kommer att betyda mycket för några av våra lyssnare.

John Carter

Tack för möjligheten att prata om det här. Du kan uppenbarligen mycket om ämnet och jag tycker att du har sammanfattat huvudpunkterna väl. Tack för möjligheten, Galen.

Galen Low

Vad tycker du? Vilka är dina bästa tips och knep för projektmilstolpar? Vad fungerar? Vad fungerar inte? Berätta en historia. När har dina projektmilstolpar svikit dig? Vilka bästa metoder har lett till dina stora framgångar? Berätta i kommentarerna nedan. Om du vill lära dig mer och komma vidare i ditt arbete kan du ansluta dig till vår gemenskap genom DPM-medlemskap. Gå till thedigitalprojectmanager.com/membership för att få tillgång till vårt expertforum, mentorgrupper, workshoppar, direkta mentorsessioner, frågestunder, e-böcker, mallar och mycket mer. Om du gillade det du hörde i dag får du gärna prenumerera och hålla kontakten på thedigitalprojectmanager.com. Vi hörs nästa gång. Tack för att du lyssnade.