Lag en smidig kontrakt som fungerer (med Alexa Huston fra Crema)

Les transkripsjonen:

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

Ben Aston:

Velkommen til Digital PM-podkasten, der vi går utover teorien for å gi ekspertråd om hvordan prosjektledere kan lede digitale prosjekter bedre.

Takk for at du lytter. Jeg heter Ben Aston og er grunnlegger av Digital Project Manager. Jeg lurer på om du kjenner til denne klassiske prosjektledelseskatastrofen, der du arver et prosjekt fra et forretningsutviklingsteam, og av en eller annen merkelig grunn ser det ut til at budsjettet som er tildelt prosjektet, ikke har noen som helst sammenheng med arbeidet som skal utføres.

Det skjer hele tiden, ikke sant? Og det er utrolig stressende for prosjektlederen, for teamet som skal levere arbeidet og til syvende og sist for kunden, som oftere enn ikke ender opp med å bli skuffet over arbeidet som leveres.

Denne episoden er sponset av Resource Guru, planleggingsverktøyet for ressurser som brukes av team i selskaper som Apple, Ogilvy, Deloitte og Publicis. DPM-lyttere kan få 20 % rabatt i hele kontoens levetid med kupongkoden DPM2018.

Les mer på resourceguru.io/dpm

I dag skal vi altså snakke om en bedre vei ut av kontraktskaoset som så mange av oss sliter med. Og egentlig tror jeg dette er en samtale som går langt utover prosjektledelse – det er en større samtale. Det er på en måte en samtale som krysser prosjektledelse og ny forretning, kontrakter og drift, og vi må virkelig finne en bedre måte å gjøre dette på. Så hvis du kjenner deg igjen i utfordringene med kontrakter og arbeidsbeskrivelser som jeg nettopp nevnte, kommer du til å like dagens program, som handler om en annen samarbeidsmodell. Fortsett å lytte for å oppdage hvordan du kan forhindre en hel verden av smerte når du prøver å redusere prosjektomfanget før prosjektet i det hele tatt har startet.

Dagens spesielle gjest er Alexa Huston fra Crema. Alexia er tidligere DPM og jobber nå med ny forretning. Derfor forstår hun denne utfordringen både fra perspektivet til den som prøver å selge, og prosjektlederen som skal levere. Jeg ser frem til en interessant samtale.

Alexa er også en av våre faste DPM-eksperter ved Digital Project Management School. Hvis du vil lære mer av henne, kan du sjekke ut Mastering Digital Project Management School, der hun skal bidra. Gå til Resourceguru.io/dpm.

Hei, og velkommen, Alexa!

Alexa Huston:

Takk for at jeg fikk komme!

Ben Aston:

Alexa, fortell oss: Hva er nytt i Alexas verden? Jeg har forstått det slik at du skal ut på et stort eventyr.

Alexa Huston:

Kjenner du uttrykket «Når det regner, så øser det ned»?

Vanligvis er det noe negativt, men det skjer mye positivt også. Jeg forlovet meg den siste halvannen måneden, og en uke senere tilbød forlovedens selskap ham en ny stilling i Phoenix, så vi flytter til ørkenen.

Som følge av det satte jeg sammen et forslag om å beholde jobben min i Crema, fordi jeg elsker den. Og jeg er heldig nok til å kunne si at de godtok forslaget, så jeg skal jobbe eksternt for første gang i livet. Og du vet, vi planlegger et bryllup – det er bare masse som skjer.

Ben Aston:

Fortell oss om bryllupsplanleggingen. Bryllupsplanlegging er jo prosjektledelse. Har dere en bryllupsplanlegger? Er det du som prosjektleder hele greia?

Alexa Huston:

Jeg smiler så stort. Vi endte opp med å ansette en bryllupskoordinator og -planlegger fordi vi skal gjøre det i Mexico, og vi har valgt et sted vi ikke engang har besøkt, i en by vi aldri har vært i. Det er litt skummelt å dra dit uten å ha sett stedet, og vi skal gifte oss om åtte måneder. Alt dette til sammen gjorde at jeg tenkte: «Jeg trenger hjelp.»

Ben Aston:

Så risikoreduseringsstrategien din er å ansette en bryllupsplanlegger og håpe at hun klarer det.

Alexa Huston:

Absolutt. Vi hadde faktisk vår første samtale med henne i går kveld, og hun er fantastisk. Men som tidligere prosjektleder har jeg spurt henne om ting – det er jo interessenthåndtering – som: «Hva foretrekker du når det gjelder denne prosessen? Jeg ser at du gjør ting på denne måten. Er det slik du ønsker å gå videre, eller er det noe vi kunne gjort annerledes?» Så det har vært en morsom liten balansegang.

Ben Aston:

Ja, jeg tror det å prosjektlede en prosjektleder når du selv er prosjektleder og ansetter en prosjektleder, gjør at du alltid er litt nervøs, i hvert fall i begynnelsen, og tenker: «Vet de hvordan dette skal gjøres?»

Alexa Huston:

Jeg vet. I går sa jeg til og med: «Har du noe imot å sende meg en ferdig signert kontrakt? Jeg har bare en versjon med signaturlinjene mine på.» Og hun tenker sikkert bare: «Klart det.»

Ben Aston:

Det er morsomt. Lykke til med bryllupsplanleggingen.

Alexa Huston:

Takk!

Ben Aston:

Og i Mexico, på et sted du aldri har vært …

Alexa Huston:

Det går fint. Det er en mangolund kombinert med restaurant, og de har trehytter man kan bo i. Det er vakkert.

Ben Aston:

Jeg gleder meg allerede.

Alexa Huston:

Ja.

Ben Aston:

Fortell oss litt mer om hvordan rollen din kommer til å endre seg. Dette er et interessant tema: Hvordan endrer rollen seg når man går fra å være fast ansatt til å jobbe eksternt? For andre som tenker «Jeg liker egentlig tanken på å jobbe eksternt og slippe å dra til kontoret hver dag» – hva var strategien din? Du skal jo flytte, så på noen måter hadde de ikke noe valg, men hvordan la du dette opp, og hva er tilnærmingen din til fjernarbeid?

Alexa Huston:

Nettopp. Du traff spikeren på hodet. Strategien min var: «Jeg flytter uansett, men la meg lage en liste over fordelene for virksomheten og hvorfor det vil være bra for meg å jobbe eksternt.» Jeg er heldig. Det siste halvannet året har stadig flere Crema-ansatte jobbet eksternt, særlig de siste tre månedene, da det har vært en veldig interessant trend.

Dette er altså allerede noe virksomheten har fokusert på: Hvordan tenker vi om en distribuert arbeidsstyrke? Hvordan tenker vi om et eksternt team? På den måten føler jeg meg heldig. Men siden jeg jobber med ny forretning, rammet jeg inn mulighetene i et nytt marked og hvorfor det ville være bra for meg å være der. Jeg viste også til resultatene jeg har oppnådd i den resultatbaserte kulturen vår. Selv om jeg vanligvis er på kontoret, har jeg mulighet til å jobbe eksternt, så jeg prøvde bare å fremheve alle grunnene til at dette er bra for virksomheten. Deretter satte jeg sammen en kommunikasjonsstrategi og en overordnet tidsplan, slik at alle skulle føle seg komfortable med det.

I tillegg kommer en liten vending: Det er én annen person som jobber med ny forretningsutvikling i selskapet, og vi har gjort dette sammen. Etter hvert som vi vokser, har vi innsett at vi må spesialisere rollene våre mer. Derfor ble jeg anbefalt en bok som heter Predictable Revenue. Den har vært fantastisk, og vi har i praksis formet innholdet etter hva det betyr for oss.

Jeg skal derfor bevege meg høyere opp i salgstrakten og jobbe mer med utgående salg, noe som er nytt for meg. Det innebærer e-postkampanjer til selskaper som ikke aner hvem vi er. Forhåpentligvis vil det skape flere potensielle kunder, og til slutt kan jeg kvalifisere noen av dem og sende dem videre til Nate, kollegaen min, som kvalifiserer dem på nytt og fører dem gjennom salgsprosessen vår.

Akkurat nå har vi vært svært avhengige av anbefalinger og andre strategier som ikke er like forutsigbare. Det er enda en endring i livet mitt som jeg prøver å omfavne.

Ben Aston:

Alt er i endring. Jeg har selv begynt å jobbe for et byrå på kontrakt, og det er også 100 % eksternt. Det er et helt annet dyr å jobbe for et fullstendig distribuert team enn når alle er på kontoret og du bare kan gå bort til dem. Det er alltid en utfordring å få tak i folk.

Alexa Huston:

Det er en utfordring, og det er nytt. Denne uken har jeg sendt meldinger til folk og følt at de har falt for døve ører. Jeg tror ikke de faktisk har gjort det – jeg må bare formulere samtalene annerledes og gjøre dem mer handlingsorienterte hvis jeg virkelig trenger et svar. Eller jeg må ikke være redd for å ringe dem hvis de er tilgjengelige.

Man må finne måter å lukke kommunikasjonssirkelen på …

Ben Aston:

Ja, absolutt. Én ting jeg synes er veldig nyttig, er å bruke Zoom hele tiden. Fristelsen kan være at du bare begynner å leve i Slack, men det er lurt å gå tilbake til video. Det forstyrrer mer, og du må legge inn mer innsats. Du må sørge for at du ikke har mat på klærne. Men det å faktisk snakke med noen i stedet for bare å sende Slack-meldinger kan være veldig nyttig.

Alexa Huston:

Enig.

Ben Aston:

Har du funnet noe annet i det siste som har gjort livet ditt bedre?

Alexa Huston:

Dette er et veldig enkelt eksempel, men det har virkelig hjulpet. Jeg kjøpte en fin notatbok fra Amazon med et lite bånd som bokmerke og en liten holder på siden til pennen. Jeg har prøvd å finne den rette balansen mellom å skrive notater digitalt og å skrive ned ting for hånd. Før jeg fikk denne notatboken, brukte jeg bare noe som ikke viste hvor jeg var. Alle notatene var ute av rekkefølge, og det gjorde meg gal. Det er en så enkel endring, men livet mitt har blitt mye bedre fordi jeg føler at jeg har kontroll.

Ben Aston:

Båndeffekten.

Alexa Huston:

Det er båndeffekten. Ja.

Ben Aston:

Så flott. Visste du at jeg også har begynt å bruke notatbok igjen? Jeg har Trello-kortene mine, Trello-systemet mitt og Evernote, men jeg har gått tilbake til å skrive for hånd. Når jeg prøver å tenke på noe og skrive ned notater, er jeg mye mer effektiv da. Hva kaller man det – å skrive? Jeg er mye mer effektiv når jeg skriver det ned og går analogt, enn når jeg sitter ved datamaskinen eller telefonen og skriver. Da dukker det hele tiden opp noe som distraherer meg.

Alexa Huston:

Helt klart. Det er et godt eksempel på å være bevisst på seg selv og eksperimentere med ulike metoder. Jeg bruker også mange verktøy, og noen ganger blir jeg bare litt verktøysliten. Derfor prøver jeg å forenkle ting. Bare skriv det ned.

Ben Aston:

Ja. Og bruk båndet ditt. Skaff deg en notatbok med bånd.

Alexa Huston:

Skaff deg et bånd!

Ben Aston:

Vi legger inn en lenke i transkripsjonen.

La oss snakke om artikkelen din og gå tilbake til situasjonen jeg nevnte i begynnelsen – den vi alle kjenner altfor godt. Forretningsteamet vårt vil selge. Det er rollen din innen forretningsutvikling. Jeg har faktisk nettopp kommet fra en rolle innen forretningsutvikling. Vi vil selge, og for å få til det kommer vi med et stort og tilsynelatende generøst tilbud til kunden. Vi prøver å vinne arbeidet. Fristelsen er ofte å selge oss litt billig, slik at vi ser bedre ut enn konkurrentene. Noen ganger kan tanken være at det første produktet er en tapsleder. Det synes jeg for øvrig er en forferdelig idé.

Andre ganger er det ganske enkelt fordi prosjektet ikke er godt nok avgrenset. Vi tenker at det er et langskudd og sier til kunden: «Klart, vi gjør det for 100 000.» Men egentlig er det et prosjekt til 200 000.

Vanligvis tror jeg et byrå ofte prøver å selge inn en løpende avtale. Det er noen ganger det ideelle. En kontrakt med fast pris, en kontrakt basert på tid og materiell – og jeg vet at det har vært mye entusiasme rundt verdibaserte kontrakter. Men med alle disse variantene begynner problemene ofte etter at kunden har signert. Prosjektet overleveres til prosjektlederen, som får i oppgave å levere prosjektet uten tilstrekkelig budsjett til å gjøre det ordentlig.

Hva er den bedre måten? Alexa har skrevet en artikkel om en annen type kontrakt, så les artikkelen for å finne ut mer. Men i dag skal vi diskutere en kontrakt basert på varighet og pris.

Kan dette være løsningen på kontraktsproblemene våre? Alexa, fortell oss om kontrakter basert på varighet og pris. Hvordan fungerer dette?

Alexa Huston:

Først en ansvarsfraskrivelse: Vi fant på dette uttrykket selv. Det er bare det vi kom frem til for et par år siden, og det festet seg. Men det beskrives av ordene i uttrykket. Vi har utarbeidet avtaler som operasjonelt støtter de smidige metodene våre og fokuserer på verdien og resultatene av et prosjekt i stedet for et fast omfang eller alle de konkrete detaljene.

Enkelt sagt er varigheten den tiden noen skal arbeide med teamet vårt, og prisen er et resultat av timesatsen multiplisert med tiden vi arbeider med kunden. Dette skiller seg fra det du beskrev, som en løpende avtale, en fastprisavtale eller til og med en verdibasert avtale, som er så vanskelig å få til i byråverdenen. Det er en enklere metode, selv om den har komplikasjoner og krever mye opplæring.

Vi føler at dette gir kundene en tydelig definisjon av hva de betaler for, samtidig som teamet vårt slipper å være bundet av en arbeidsbeskrivelse som ble laget uten at man hadde alle fakta.

Selv den beste kontrakten med fast omfang kan ha gode grunner for å eksistere, dersom omfanget er godt definert. Men innen produktutvikling bruker team ofte mye tid på å tenke gjennom milepæler og funksjoner som skal inn i et prosjekt, og disse vil endre seg underveis når prosjektet først er startet.

Vi prøvde derfor å redusere risikoen og unngå situasjonen der vi må absorbere mange tilleggskostnader som ofte følger med en mer fastprisbasert kontrakt.

Relatert podkast: Finn den perfekte forbindelsen mellom drift og PMO (med Alyson Caffrey fra Operations Agency)

Ben Aston:

Slik det fungerer, selger du som person innen ny forretning inn et team på fem personer. Teamet koster 5 000 per uke. Du sier til kunden: «Det blir 25 000 per uke.» Hvordan kommer dere frem til et budsjett? Sier dere «Vi tror dette blir et prosjekt på fire uker, altså en måned, så vi anslår 100 000», og prøver å få kunden til å godkjenne 100 000? Eller sier dere bare «Vi vet ikke hvor lenge dette vil vare. Det koster 25 000 per uke, så bare begynn å skrive ut sjekker»? Hvordan fungerer det?

Alexa Huston:

Godt spørsmål. Uten å gå for langt ned i detaljene prøver vi å starte med et mindre og mer avgrenset arbeidsomfang, kanskje fire til seks uker med design og testing av en prototype. Deretter prøver vi å fremme ideen om at vi skal gi kunden et dedikert produktteam. Det betyr, som du sier, de fem rollene – for eksempel en kvalitetssikringsperson, prosjektstrateger samt design og utvikling. Vi sier: «Basert på erfaringen vår vil det, når denne prototypefasen er over, ta omtrent tre til seks måneder å komme til fase X eller lansering X av applikasjonen.» Deretter forhandler vi om hvor lenge det skal vare.

Tanken er også at vi skal arbeide helt frem til dette tidspunktet. Selv om vi når målene tidlig, har kunden fortsatt tilgang til teamet for å arbeide med andre deler av applikasjonen eller produktet frem til varigheten er over. Forhåpentligvis gir det oss flere muligheter til å fortsette samarbeidet.

Vi arbeider ut fra en oppgaveliste eller en slags veikart, og ofte kommer vi til slutten av den første kontrakten basert på varighet og pris mens det fortsatt gjenstår arbeid. Da er det enkelt å fornye avtalen.

«Vi har hatt et godt samarbeid, og vi vet at det kommer mer i horisonten. La oss forlenge avtalen og fortsette å jobbe sammen, siden vi har gitt oss selv mulighet til å nå disse målene.»

Ben Aston:

Dere prøver altså å gi kunden en idé om hvor lenge prosjektet kan vare – for eksempel tre til seks måneder. Hvordan håndterer dere forventningene til hvor detaljert eller ferdig produktet kommer til å være? Og hvordan hjelper dere kunden med å selge dette videre internt, når de sier: «Jeg trenger 300 000 for å lage denne prototypen, som er første fase i prosjektet. Vi er ikke helt sikre på hvor vi ender, men de har sagt at det vanligvis tar mellom tre og seks måneder. Vi bør altså få laget noe som er sånn passe»?

Alexa Huston:

Det er vanskelig å selge inn, det skal jeg ikke legge skjul på. Det er flere deler av dette. Én måte å ramme inn ideen på – at kunden ikke skriver ut en blankosjekk – er å fokusere på virksomhetens utfordringer. Hvor er de utfordret, og hvordan vil dette løse problemene? Vi må være svært konkrete når det gjelder hvilken avkastning investeringen kan gi.

Kunder er ofte i en kjøpsgruppe der vi kanskje har tilgang til én eller to personer, eller forhåpentligvis et større team. Men oftere enn ikke må de selge dette oppover i organisasjonen. Derfor fokuserer vi på de smidige metodene våre og viser til relevante kundehistorier.

Relatert lesing: Hva er Scaled Agile Framework®? Forklart for prosjektledere

Det hjelper med å vise hvilket detaljnivå kunden kan forvente i produktet. Vi fokuserer sterkt på kvalitet, fordi vi har investert mye i produktutviklingsprosessen vår og ønsker at kunden skal føle at de får et ekspertteam. Det er det beste alternativet for utfordringen de står overfor.

En enkel måte å gjøre prissettingen mer forståelig på er at jeg noen ganger bare reiser meg og begynner å skrive på en tavle: «Dere trenger disse fem rollene, og dette er timesatsen.» Jeg skriver det i tabellform, slik at kunden kan se hvordan vi kommer frem til prisen. Deretter gir vi kunden mulighet til å si: «Dere vil få denne verdien fordi dere sitter i førersetet og tar beslutninger om fokus for hver sprint. Vi gir råd underveis og kommer med anbefalinger.» Dette setter kunden i førersetet når det gjelder produktet, prioritering av oppgavelisten og bearbeiding av den sammen med teamet vårt.

Ben Aston:

Opplever dere noen ganger at kunden sier: «Dere solgte inn dette teamet, men de arbeider ikke raskt nok. De produserer ikke nok, og vi har denne lange oppgavelisten»?

Det var det som skremte meg.

Alexa Huston:

Absolutt. Det er da man virkelig må lene seg på Scrum-metoder eller smidig praksis. Ideelt sett bør man lansere noe kunden kan se i løpet av de første ukene. Derfor opplever vi faktisk ofte det motsatte. Det kan være litt uro i begynnelsen, men når utviklingen starter og kunden ser ting jevnlig, avtar uroen.

Vi inviterer dem inn i prosjektstyringsverktøyet vårt og i Slack, slik at de ser ting skje. Det krever at tillit etableres tidlig, men hvis de fortsatt er litt usikre, forsvinner det vanligvis når de ser faktiske lanseringer. Selv om det ennå ikke er noe de kan «bruke», kan de se og oppleve det og forestille seg hva det vil bli når man projiserer det over hele varigheten vi har avtalt.

Ben Aston:

Dere prøver altså å bygge tillit ved å være åpne om prosessen og det som skjer. Gir dere full innsikt i interne kanaler og verktøy?

Alexa Huston:

Det kan de få. Vi bruker to ulike Slack-kanaler for hvert prosjekt. Det finnes ting man ikke vil dele med kunden, for eksempel interne diskusjoner om hvordan man skal presentere en alvorlig utfordring. Derfor har vi en intern Slack-kanal. I tillegg har vi en kanal som heter prosjektnavn underscore collab, der alle interessentene er med og der vi jevnlig oppdaterer dem om status.

Det gir et høyt nivå av åpenhet, og det hjelper.

Ben Aston:

Du nevnte i artikkelen at man forhandler om omfanget underveis med kundene. Hvordan støtter dere kundene gjennom denne prosessen? Ofte arbeider vi med en kunde som ikke har så mye myndighet, og som rapporterer oppover i organisasjonen. Prøver dere å få inn noen høyere opp slik at dere har en felles forståelse?

Alexa Huston:

En forutsetning for at dette skal fungere effektivt, er at kunden har en person med tilstrekkelig myndighet til å ta beslutninger. Vi møter en del byråkrati når det gjelder hvem som egentlig tar beslutningene, og hvordan vi får tilgang til vedkommende. Dette prøver vi å avdekke i salgsprosessen. Ideelt sett har kunden en produktansvarlig med god teknisk eller designmessig forståelse.

Vi arbeider med denne personen og sørger for at vedkommende har tilgang til alt og kan ta beslutninger. Samtidig må personen se på veikartet og omprioritere oppgavene i oppgavelisten utenfor de vanlige sprintene.

Uken før sprintens oppstart kan den produktansvarlige for eksempel omorganisere oppgavelisten. Vi støtter vedkommende og kommer med anbefalinger. Det kan hende vi har en idé om hvor vi skal være etter to måneder, fordi prosjektet bør ha et overordnet mål. Det er ikke slik at man ikke aner hva man skal bygge.

Derfor er det viktig å gjøre antakelser og hensyn tydelige.

Men hvis noe oppstår – for eksempel at en integrasjon ikke er mulig – må man kunne snu seg raskt. For noen år siden opplevde vi at produktet vi skulle lisensiere, gikk konkurs. Vi måtte spørre: «Hva er alternativene våre?» Det er det jeg mener med å forhandle om omfanget. Dette var ikke en del av planen, men fordi vi ikke hadde en kontrakt med fast omfang, trengte vi ikke nødvendigvis en endringsordre. Vi sa bare: «Dette var kjedelig. Hvordan kan vi gjøre det bedre?» Så kom vi frem til en beslutning som team og gikk trygt videre i den retningen, med kundens innspill og støtte.

Ben Aston:

Du nevnte kontrakten. Hvordan ser arbeidsbeskrivelsen ut?

Alexa Huston:

Den er ganske enkel. Vi måtte også endre hovedavtalen vår for å støtte dette. Den generelle måten vi arbeider med kundene på, må passe til denne typen samarbeid. Vi justerte den litt og holdt den enkel.

I artikkelen viser jeg noen skjermbilder. Vi bruker PandaDoc til å levere kontraktene, og det er et flott verktøy. Vi holder likevel kontrakten på et overordnet nivå og fokuserer på «Hva er virksomhetsmålene, og hva er veien for å nå dem?» Det er viktig å ha et bilde av hva man bygger. Lenke til brukerhistorier, en prototype eller en form for design hvis slike ressurser finnes.

Det hjelper med å tegne et bilde både for interessentene som er direkte involvert i prosjektet og for dem som står utenfor. Deretter lager vi en tabell som viser hvilke ressurser som inngår, hvilken time- eller ukespris de har, og hvor lenge de skal være med på prosjektet.

Vi legger også inn ekstra klausuler ved behov, for eksempel hvis kunden trenger støtte utenfor normal arbeidstid. Vi kan tilpasse avtalen etter kundens behov. Generelt er den likevel ganske rett frem. Dette var en endring for oss, fordi kontraktene våre tidligere var åtte eller ni sider lange, og ingen leste dem. Det fungerte ikke særlig godt, så vi forenklet dem og sørget for at kundene visste hva de kjøpte før de signerte.

Hvis det fungerer godt, kommer papirarbeidet bare i bakgrunnen. Kontrakten må være signert, og man må ha en felles forståelse, men når dette er på plass, kan man nesten glemme kontrakten og fokusere på hver sprint slik man bør.

Ben Aston:

Du nevnte at dere ideelt sett starter med brukerhistorier, et bilde eller en idé. Betyr det at dere investerer mer i salgsprosessen og begynner å definere ting mer enn dere vanligvis ville gjort?

Alexa Huston:

Vi prøver å unngå å gi bort arbeid gratis, så det er en balansegang mellom å identifisere behovene i salgsprosessen og å bruke for mye av teamets tid. Vi kan for eksempel starte med én eller to ukers teknisk kartlegging, en generell strategi- og avklaringsøkt for å starte prosjektet. Deretter skaleres teamet opp.

De to første ukene kan alle være med på et litt lavere engasjement. Deretter øker teamet gradvis, prisene endres, og man går for fullt inn i det som ble avklart i starten av samarbeidet.

Noen kunder kommer til oss med en ferdig liste og sier: «Jeg har alt dette og er klar til å starte.» Da sier vi: «Det er flott. La oss gå gjennom det, sørge for at vi har samme forståelse og snakke om hvor komfortabel du er med at ting kan endre seg.» For det kommer de sannsynligvis til å gjøre. Det krever mye opplæring i starten og underveis.

Ben Aston:

Hvor kan dette mislykkes? Har du historier der dere prøvde denne tilnærmingen, men det ikke fungerte, eller der kunden fortsatt ble skuffet eller prosjektlederen følte seg lurt?

For det høres jo fantastisk ut.

Alexa Huston:

Det er ikke en mirakelkur. Det krever et modent team. Hvis noen er helt nye innen smidig arbeid, eller teamet ikke har arbeidet sammen over lengre tid, kan det være grunner til å ikke velge denne modellen. Hvis omfanget er svært tydelig og prosjektet er mer fossefallsbasert, er det også helt greit. Da trenger man ikke å tilpasse noe.

Det som har gått galt tidligere, er når vi har prøvd å bevege oss bort fra måten vi er best på å bygge produkter på, og forsøkt å passe inn i kundens prosess på en måte som skader oss. Det betyr ikke at vi er for rigide til å samarbeide. Det finnes alltid en kombinasjon og en kompromissløsning mellom to grupper som møtes i en naturlig setting.

Modellen gir prosjektlederen myndighet til å foreslå ting som er til fordel for produktet, i stedet for at prosjektlederen er redd for å gjøre det fordi omfanget er fast. Da kan man frykte at en anbefaling vil ødelegge hele planen. Denne modellen hindrer det.

Ben Aston:

Som prosjektleder kan man noen ganger ønske å være strategisk og gjøre det riktige, men det å levere i tide, innenfor budsjett og avtalt omfang blir viktigere. Det er trist hvis vi ikke faktisk gjør det beste for kunden.

Alexa Huston:

En nyttig ting da vi startet med dette, var at den juridiske gjennomgangen mellom kundens team og vårt team tvang oss til å tenke over språket vi brukte, og hvordan det ville fungere i et juridisk bindende forhold. Vær villig til å prøve dette på et internt prosjekt først. Dere skal selvfølgelig ikke fakturere dere selv, men tenk på hvordan modellen kan brukes på noe som ikke er rettet mot en kunde. Eksperimenter, still spørsmål og gjennomfør gjerne noen evalueringer underveis.

Snakk med utviklerne og designerne for å finne ut om de har vært eksponert for denne typen samarbeid tidligere. Jeg kan love deg at det føles bedre for dem å slippe å være bundet av et stramt omfang som de ofte ikke engang kjenner før de begynner på prosjektet. Det er ikke ideelt.

Snakk med teamet som faktisk skal arbeide med prosjektet, og finn ut hvordan de opplever det.

Ben Aston:

For dem som lytter og tenker at de kanskje bør prøve dette og få kundene med på det – sannsynligvis med en ny kunde – foreslo du å teste det med et internt team og prosjekt. Finnes det bestemte typer prosjekter der dette fungerer bedre enn andre?

Alexa Huston:

Det fungerer svært godt med bygging på flere plattformer. Det første eksempelet vårt var en ny oppstartsbedrift som ønsket en iOS-app, en Android-app og en nettapp. Det var over hundre brukerhistorier, og prosjektet var så stort at det nesten var umulig å avgrense.

Det fungerer godt når produktutviklingsperioden er lang og man trenger mange mennesker for å få arbeidet gjort. Det fungerer ikke like godt for ting som markedsføringsnettsteder. Vi lager ikke mye innhold, men det finnes oppgaver som er mer lineære, og da er kanskje ikke dette riktig løsning. Det er greit – jeg sier ikke at modellen skal brukes på alt.

Men hvis du har en generell idé om hvor mye du kan få gjort, eller hvor mye én person kan arbeide med i løpet av en uke eller måned, kan du bruke modellen i virksomheten din og se om den passer.

Mye av dette krever et team som er vant til å arbeide sammen. Teamet må kunne organisere seg selv rundt virksomhetsmål og samarbeide. På kundesiden er det avgjørende å ha noen som kan ta beslutninger.

Ben Aston:

Det jeg liker ved det du sier, er ideen om at man må bygge teamene. Du sa at det er flott når folk har arbeidet sammen før og forstår hvordan dette fungerer. Kanskje ett av de første stegene er å sette sammen noen team og la dem arbeide på interne prosjekter for å se hvordan det fungerer. Hvor mye arbeid kan folk fullføre på én, to eller tre måneder? Hvordan utvikler det seg? Man må huske at ting ikke alltid går etter planen og at omarbeiding er en del av prosessen.

Man kan lage noen grupper, finne ut hvor mye de klarer å levere og deretter begynne å selge det inn til en kunde: «Dette er det vi tror vi kan produsere på tre eller seks måneder.» Det er svært nyttige råd.

Alexa Huston:

Helt klart. Vi hentet mye inspirasjon fra Hanna, som er et fantastisk byrå. De hadde mange ressurser på nettet. For rundt tre år siden, da vi satte dette sammen, publiserte de prosjektene sine og sa at de solgte folk per uke. Det var slik vi begynte å tenke på dedikerte produktteam.

Dette er noe annet enn å selge inn én person fra byrået til en kunde og si: «Ja, dere kan få tilgang til denne utvikleren i to måneder.» Det skaper noen problemer og siloer som vi ikke ønsket i virksomheten vår. Dette er derfor ment for et større team enn bare én person.

Ben Aston:

Det er altså ikke bare å leie ut folk.

Alexa Huston:

Nei.

Ben Aston:

Hva er ditt beste råd til noen som sliter med å ta denne ideen videre, med tanke på noen av utfordringene du har møtt underveis?

Alexa Huston:

Jeg skulle ønske jeg kunne redusere det til ett ord, men kommunikasjon er avgjørende. Også internt. Du må sørge for at teamet føler seg komfortabelt med dette. Få alle rollene i kontakt med hverandre i de første fasene av kontraktsarbeidet.

Deretter må du kommunisere dette til kunden: hvorfor det er bra for dem, og hvorfor det vil skape verdi for virksomheten deres. Sørg også for at modellen støtter måten teamet arbeider på. Vi har en svært smidig kultur, og denne modellen hjelper oss med å gjøre den operasjonell. Det er nyttig å kommunisere fordelene og resultatene, ikke bare aktivitetene.

Men bare kommuniser.

Ben Aston:

Gode råd. Dette er en av de tingene der ledelsen kan få en idé og bare sette den ut i livet: «Dette er den nye måten å gjøre ting på.» Men det å kommunisere gjennom hele prosessen og få folk med på laget er virkelig gode råd.

Alexa, tusen takk for at du ble med oss i dag. Det har vært flott å ha deg her.

Alexa Huston:

Takk, det setter jeg stor pris på.

Ben Aston:

Som jeg nevnte i begynnelsen, skal Alexa bidra i vårt kommende kurs, som starter i september: Mastering Digital Project Management. Hvis du ikke vet hva jeg snakker om, men vet at du trenger opplæring i prosjektledelse, bør du sjekke det ut. Det er et sju ukers intensivkurs med mange interaktive elementer, videoleksjoner, oppgaver og gruppediskusjoner. Det finnes også valgfrie veiledningsøkter. Gå til dpmschool.com og meld deg på før kurset blir fullt.

Hvis du vil bidra til samtalen om dette og om kontraktsarbeid på en smidig måte, kan du kommentere innlegget. Gå til ressursseksjonen på digitalprojectmanager.com og bli med i Slack-teamet vårt, der du finner mange interessante samtaler.

Men frem til neste gang: Takk for at du lyttet.