Lav en agil kontrakt, der fungerer (med Alexa Huston fra Crema)

Læs transskriptionen:

Vi er i gang med at afprøve transskription af vores podcasts ved hjælp af et softwareprogram. Tilgiv venligst eventuelle tastefejl, da botten ikke er korrekt 100 % af tiden.

Ben Aston:

Velkommen til Digital PM-podcasten, hvor vi går videre end teorien for at give ekspertråd til projektledere, så de kan lede digitale projekter bedre.

Tak fordi du lytter med. Jeg er Ben Aston, grundlægger af Digital Project Manager. Jeg spekulerer på, om du kender dette klassiske projektledelsesmareridt, hvor du overtager et projekt fra et forretningsudviklingsteam, og af en eller anden grund – en mærkelig grund – ser det budget, der er blevet tildelt projektet, ikke ud til overhovedet at hænge sammen med det arbejde, der bliver udført.

Det sker hele tiden, ikke? Og det er utroligt stressende for projektlederen, for teamet, der leverer arbejdet, og i sidste ende kunden, som oftere end ikke ender med at blive skuffet over det leverede arbejde.

Denne episode er sponsoreret af Resource Guru, planlægningsværktøjet til ressourcer, som bruges af teams hos virksomheder som Apple, Ogilvy, Deloitte og Publicis. DPM-lyttere kan få 20 % rabat i hele kontoens levetid med kuponkoden DPM2018.

Læs mere på resourceguru.io/dpm

I dag taler vi altså om en bedre vej ud af det kontraktkaos, som så mange af os kæmper med. Og jeg synes virkelig, at denne samtale rækker langt ud over projektledelse – det er en større samtale. Det er på en måde en samtale, der krydser projektledelse og ny forretning, kontrakter og drift, og vi er nødt til at finde en bedre måde. Så hvis du overhovedet kender til de udfordringer med kontrakter og arbejdsbeskrivelser, som jeg netop nævnte, vil du elske dagens program, der handler om en anderledes samarbejdsmodel. Lyt videre for at opdage, hvordan du kan forhindre en hel verden af problemer ved at reducere projektets scope, før det overhovedet er begyndt.

Min særlige gæst i dag er Alexa Huston fra Crema. Alexa er tidligere DPM og arbejder nu med ny forretning. Hun forstår derfor denne udfordring fra både den nye forretnings perspektiv, hvor man forsøger at sælge, og projektlederens perspektiv, hvor man skal levere. Jeg ser frem til en interessant samtale.

Alexa er også en af vores faste DPM-eksperter på Digital Project Management School. Hvis du vil lære mere af hende, kan du se vores Mastering Digital Project Management School, hvor hun medvirker. Gå til Resourceguru.io/dpm.

Hej, og velkommen, Alexa!

Alexa Huston:

Tak fordi jeg måtte være med!

Ben Aston:

Alexa, fortæl os, hvad er nyt i Alexas verden? Jeg tror, du snart skal ud på et stort eventyr.

Alexa Huston:

Kender du udtrykket: »Når det regner, så styrter det ned«?

Det er normalt noget negativt, men der sker en masse positive ting. Jeg blev forlovet for halvanden måned siden, og en uge senere tilbød min forlovedes virksomhed ham en ny rolle i Phoenix, så vi flytter til ørkenen.

Som følge af det lavede jeg et forslag til, hvordan jeg kunne beholde mit job hos Crema, fordi jeg elsker det. Og jeg er heldig nok til at kunne sige, at de accepterede det, så jeg kommer til at arbejde på distancen for første gang i mit liv. Og du ved, vi planlægger et bryllup – der er bare en masse ting.

Ben Aston:

Fortæl os så om bryllupsplanlægningen. Bryllupsplanlægning er jo projektledelse. Har I en bryllupsplanlægger? Projektleder du hele processen?

Alexa Huston:

Jeg smiler helt vildt. Vi endte med at hyre en bryllupskoordinator og -planlægger, fordi vi holder det i Mexico, og vi har valgt et sted, vi ikke engang har besøgt, i en by, vi aldrig har været i. Det er lidt skræmmende at vælge et sted uden at have set det, og vi skal giftes om otte måneder, så alle de ting tilsammen fik mig til at sige: »Jeg har brug for hjælp.«

Ben Aston:

Så din risikohåndteringsstrategi er at hyre en bryllupsplanlægger og håbe på, at hun kan klare det.

Alexa Huston:

Helt seriøst. Vi havde faktisk vores første samtale med hende i går aftes, og hun er fantastisk. Men som tidligere projektleder har jeg spurgt hende – det er jo interessenthåndtering – om hendes præferencer for processen. Jeg har spurgt: »Hvad synes du om denne proces? Jeg kan se, at du gør tingene på denne måde. Er det sådan, du helst vil gå videre, eller er der noget, vi kunne gøre anderledes?« Så det har været en sjov lille balance.

Ben Aston:

Ja, jeg tror, at når man selv er projektleder, hyrer en projektleder og derefter projektleder en projektleder, bliver man altid nervøs – i hvert fald i begyndelsen – og tænker: »Ved de, hvordan det her skal gøres?«

Alexa Huston:

Jeg ved det. Selv i går sagde jeg: »Har du noget imod at sende mig en fuldt underskrevet kontrakt? Jeg har kun en version med mine underskriftsfelter.« Og hun tænker sikkert bare: »Selvfølgelig.«

Ben Aston:

Det er sjovt. Held og lykke med bryllupsplanlægningen.

Alexa Huston:

Tak!

Ben Aston:

Og i Mexico, på et sted du aldrig har været før …

Alexa Huston:

Det skal nok gå. Det er en mangolund, en restaurant, og de har træhuse, man kan bo i. Det er smukt.

Ben Aston:

Jeg glæder mig allerede.

Alexa Huston:

Ja.

Ben Aston:

Fortæl os lidt mere om, hvordan din rolle kommer til at ændre sig. Det er et interessant emne: Hvordan ændrer ens rolle sig, når man går fra at være intern medarbejder til at arbejde på distancen? Hvis andre overvejer at blive fjernarbejdere og ikke længere skal ind på kontoret, hvad var så din strategi? Hvordan har du tænkt dig at arbejde på distancen?

Alexa Huston:

Du ramte det helt rigtigt. Min strategi var: »Jeg flytter uanset hvad, men lad mig lave en liste over fordelene for virksomheden og forklare, hvorfor det vil være godt for mig at arbejde på distancen.« Jeg er heldig, for flere og flere medarbejdere hos Crema har arbejdet på distancen det seneste halvandet år, især de sidste tre måneder, hvor det har været en meget interessant tendens.

Det har derfor allerede været noget, virksomheden har fokuseret på: Hvordan tænker vi på en distribueret arbejdsstyrke? Hvordan tænker vi på et fjernteam? På den måde føler jeg mig heldig. Men fordi jeg arbejder med ny forretning, indrammede jeg mulighederne på et nyt marked og forklarede, hvorfor det ville være godt for mig at være der. Jeg pegede også på de resultater, jeg har opnået i vores resultatorienterede kultur. Selvom jeg normalt er på kontoret, har jeg mulighed for at arbejde på distancen, så jeg forsøgte blot at fremhæve alle grundene til, at det er godt for virksomheden. Derefter lavede jeg en kommunikationsstrategi og en overordnet tidsplan, så alle kunne føle sig trygge ved det.

Derudover er der et lille plot twist. Der er en anden medarbejder inden for ny forretning i virksomheden, og vi har gjort det samme. Men efterhånden som vi er vokset, indså vi, at vi havde brug for at specialisere rollerne lidt mere, og jeg blev anbefalet en bog, der hedder Predictable Revenue. Den har været fantastisk, og vi har grundlæggende tilpasset den til, hvad den betyder for os.

Jeg kommer derfor til at arbejde højere oppe i salgstragten med mere opsøgende salg, hvilket er nyt for mig. Det betyder e-mailkampagner til virksomheder, som ikke aner, hvem vi er, i håb om at skabe flere leads. Derefter vil jeg forhåbentlig kvalificere nogle leads og give dem videre til Nate, min kollega, som så genkvalificerer dem og fører dem gennem vores salgspipeline.

Lige nu har vi været meget afhængige af anbefalinger og andre strategier, der ikke er lige så forudsigelige. Det er endnu en forandring i mit liv, som jeg forsøger at tage til mig.

Ben Aston:

Alt forandrer sig. Jeg har selv arbejdet for et bureau med kontraktarbejde, og det er 100 % distribueret. Det er et helt andet dyr at arbejde for et fuldstændigt distribueret team end at arbejde, når alle er på kontoret, og man bare kan gå hen til folk. Det er altid en udfordring at få fat på folk.

Alexa Huston:

Det er en udfordring, og det er nyt. Selv i denne uge har jeg sendt beskeder til folk og følt, at de faldt for døve øren. Jeg tror ikke nødvendigvis, det var tilfældet; jeg skal bare formulere mine samtaler anderledes og gøre dem mere handlingsorienterede, hvis jeg virkelig har brug for et svar. Eller også skal jeg ikke være bange for bare at ringe, hvis de er ledige.

Man skal finde måder at afslutte kommunikationen på …

Ben Aston:

Helt sikkert. Jeg synes, én ting, der er virkelig nyttig, er at bruge Zoom hele tiden. Fristelsen kan være, at man bare begynder at leve i Slack, men man bør altid vende tilbage til et rigtigt møde. Det forstyrrer mere, og man skal gøre en større indsats. Man skal sørge for, at man ikke har mad på tøjet. Men det kan være meget nyttigt faktisk at tale med nogen i stedet for bare at skrive til dem i Slack.

Alexa Huston:

Det er jeg enig i.

Ben Aston:

Har du fundet andet for nylig, der har gjort dit liv bedre?

Alexa Huston:

Det er et meget enkelt eksempel, men det har virkelig hjulpet. Jeg købte en god notesbog på Amazon med et lille bogmærkebånd og en lille holder til min pen i siden. Jeg har forsøgt at finde den rette balance mellem digitale noter og at skrive nogle ting ned. Før jeg købte denne notesbog, brugte jeg noget, der ikke havde nogen markering af, hvor jeg var. Alle mine noter var derfor ude af rækkefølge, og det drev mig til vanvid. Det er en så enkel ændring, men det gør mit liv meget bedre, fordi jeg føler, at jeg har styr på mine ting.

Ben Aston:

Båndeffekten.

Alexa Huston:

Det er båndeffekten. Ja.

Ben Aston:

Det er fantastisk. Vidste du, at jeg også er begyndt at bruge en notesbog igen? Jeg har mine Trello-kort, mit Trello-system og Evernote, men jeg er faktisk vendt tilbage til at skrive ting ned, fordi jeg bliver distraheret alt for let.

Hvis jeg forsøger at tænke over noget og skrive noter ned, er jeg langt mere effektiv på den måde. Hvad kalder man det – at skrive? Jeg er langt mere effektiv, når jeg skriver det ned og går analogt, end når jeg sidder ved computeren eller telefonen og skriver, og noget pludselig dukker op og distraherer mig.

Alexa Huston:

Helt klart. Det er et godt eksempel på selvbevidsthed og på at eksperimentere med forskellige metoder, for jeg bruger også en masse værktøjer, og nogle gange bliver jeg bare lidt træt af værktøjer. Derfor forsøger jeg at forenkle tingene. Skriv det ned.

Ben Aston:

Ja. Og brug dit bånd. Få en notesbog med et bånd.

Alexa Huston:

Få et bånd!

Ben Aston:

Vi inkluderer et link i transskriptionen.

Lad os tale om din artikel og vende tilbage til det scenarie, jeg nævnte i begyndelsen, og som vi alle kender alt for godt. Forretningsteamet vil sælge. Det er din rolle inden for forretningsudvikling. Jeg har faktisk selv netop forladt en rolle inden for forretningsudvikling. Vi vil sælge, så for at sælge kommer vi med et stort og tilsyneladende generøst tilbud til kunden. Vi forsøger at vinde arbejdet. Fristelsen er ofte at sælge os selv lidt for billigt og få os til at se fordelagtige ud i forhold til konkurrenterne. Nogle gange tænker man, at det første produkt kan være en tabsleder, hvilket efter min mening er en frygtelig idé.

Nogle gange skyldes det bare, at scope ikke er blevet afgrænset godt nok. Vi tænker måske, at det er et langskud, og siger til kunden: »Ja, vi gør det for 100.000.« Men det er faktisk et projekt til 200.000.

Typisk forsøger et bureau at sælge en løbende aftale, hvilket nogle gange er ideelt. En fastpriskontrakt, en kontrakt baseret på tid og materialer – og jeg ved, at der har været stor begejstring for værdibaserede kontrakter. Men med alle disse modeller begynder problemerne ofte, efter at kunden har underskrevet. Projektet gives videre til projektlederen, som derefter skal levere projektet uden et tilstrækkeligt budget til at gøre det ordentligt.

Så hvad er den bedre løsning? Alexa har skrevet en artikel om en anden type kontrakt, så læs artiklen for at få mere at vide. Men i dag diskuterer vi den, og det er en kontrakt baseret på varighed og pris.

Kan dette være løsningen på vores kontraktproblemer? Alexa, fortæl os om kontrakter baseret på varighed og pris. Hvordan fungerer det? Hvad er det for noget?

Alexa Huston:

Først en ansvarsfraskrivelse: Vi har selv fundet på dette begreb. Det er bare det, vi nåede frem til for et par år siden, og det hang ved. Men det er defineret af ordene i det. Vi har udarbejdet aftaler, der operationelt understøtter vores agile metoder og fokuserer på værdien og resultaterne af et projekt frem for et fast scope eller alle de specifikke detaljer.

Helt enkelt er varigheden den tid, en person skal arbejde sammen med vores team, og prisen er resultatet af timeprisen gange den tid, vi arbejder sammen med dem. Det adskiller sig fra en løbende aftale, en fast pris eller endda værdibaseret prissætning, som er så vanskelig og svær at gennemføre i bureauverdenen. Det er en enklere metode, selv om der naturligvis er komplikationer, og der følger meget uddannelse med.

Vi føler, at det giver kunderne en definition af, hvad de betaler for, samtidig med at vores team ikke bliver bundet af en arbejdsbeskrivelse, der er udarbejdet uden alle fakta.

Selv en kontrakt med et fast scope kan have gode grunde til at eksistere, hvis den er veldefineret. Men i produktudvikling bruger teams ofte masser af tid på at tænke over de forskellige milepæle og funktioner, der skal indgå i et projekt, og de ændrer sig undervejs, efter at noget er sat i gang.

Vi forsøgte derfor at mindske disse risici og undgå situationen, hvor vi ender med at absorbere en masse ekstraarbejde, som ofte følger med en mere fastpræget kontrakt.

Relateret podcast: Sådan finder du det perfekte samspil mellem drift og PMO (med Alyson Caffrey fra Operations Agency)

Ben Aston:

Sådan som det fungerer, sælger du som medarbejder inden for ny forretning et team på fem personer. Teamet koster 5.000 om ugen. Du siger derfor til kunden: »Det bliver 25.000 om ugen.« Hvordan fastsætter I så budgettet? Siger I: »Vi tror, det bliver et projekt på fire uger, altså en måned, så vi anslår 100.000«, og forsøger at få dem til at godkende 100.000? Eller siger I bare: »Vi ved ikke, hvor længe det kommer til at vare. Det koster 25.000 om ugen, så begynd venligst bare at skrive checks«? Hvordan fungerer det?

Alexa Huston:

Det er et godt spørgsmål. Uden at gå for meget i detaljer forsøger vi at starte med et mindre og mere afgrænset scope, for eksempel fire til seks ugers design og test af en prototype. Men derefter forsøger vi at fremme idéen om, at vi vil give kunden et dedikeret produktteam. Det betyder, som du siger, de fem roller – eksempelvis en kvalitetssikringsperson, projektstrateger samt design og udvikling. Vi siger: »Baseret på vores erfaring vil det tage cirka tre til seks måneder at nå fase X eller udgivelse X af jeres applikation efter denne prototypefase.« Så forhandler vi om, hvor lang tid det skal være, og tanken er også, at vi arbejder helt frem til dette tidspunkt. Selv hvis vi når målene tidligt, har kunden stadig adgang til teamet, som kan arbejde på forskellige dele af applikationen eller produktet, indtil perioden er udløbet. Forhåbentlig giver det os flere muligheder for at fortsætte samarbejdet.

Vi arbejder ud fra backloggen eller en form for køreplan, og ofte når vi slutningen af vores første kontrakt baseret på varighed og pris, er der stadig mere arbejde, der skal udføres. Fra det tidspunkt er det nemt at forny aftalen.

»Vi har haft et fantastisk samarbejde, og vi ved, at der er flere ting på vej. Lad os forlænge aftalen og fortsætte med at arbejde sammen, fordi vi har givet os selv mulighed for at nå disse mål.«

Ben Aston:

I forsøger altså at give kunden en idé om, hvor lang varigheden kan blive. I siger tre til seks måneder. Hvordan håndterer I kundens forventninger til, hvor detaljeret det, I producerer, bliver? Og hvordan hjælper I kunden med at sælge det op gennem organisationen, når de internt siger: »Jeg har brug for 300.000 til at skabe denne prototype, som er første fase af projektet. Vi er ikke helt sikre på, hvor vi ender, men de har fortalt os, at det normalt tager mellem tre og seks måneder. Så vi burde få lavet noget, der er sådan nogenlunde«?

Alexa Huston:

Det er svært at sælge, det vil jeg ikke lyve om. Der er flere dele i det. En måde at indramme idéen om, at kunden ikke skriver en blankocheck, er at fokusere på deres forretningsproblemer: Hvor er de udfordrede, og hvordan vil dette løse problemerne? Man skal være meget specifik omkring det mulige afkast af investeringen, hvis man kan.

Kunderne befinder sig ofte i en gruppe, der skal træffe en fælles købsbeslutning. Vi har måske adgang til én eller to personer eller forhåbentlig et større team, men oftere end ikke skal de sælge det videre op gennem organisationen. Derfor fokuserer vi meget på vores agile metoder og henviser til andre relevante kundecases.

Relateret læsning: Hvad er Scaled Agile Framework®? Forklaret for projektledere

Det hjælper med at vise, hvilket detaljeringsniveau kunden kan forvente af produktet. Vi fokuserer meget på kvalitet, fordi vi har investeret betydeligt i vores produktudviklingsproces, og vi ønsker, at kunden føler, at de får et ekspertteam til produktet. Det er det bedste alternativ til den udfordring, de står over for.

En nem måde at forenkle prissætningen på er, at jeg nogle gange rejser mig og begynder at skrive på en tavle: »I får brug for disse fem roller, og dette er timeprisen.« Så skriver jeg det op i et tabelformat, så de kan se, hvordan vi når frem til prisen. Derefter giver vi kunden mulighed for at sige: »I får denne værdi ud af det, fordi I selv sidder i førersædet og træffer beslutninger om fokus for hvert sprint. Vi rådgiver jer undervejs og kommer med vores anbefalinger.« Kunden sidder altså i førersædet, når produktet skal besluttes, backloggen skal prioriteres, og alt skal klargøres sammen med vores team.

Ben Aston:

Oplever I nogle gange, at kunden siger: »I solgte mig dette team, men de arbejder bare ikke hurtigt nok. De producerer ikke nok, og vi har denne lange backlog. Teamet leverer simpelthen ikke nok«?

Det var det, der skræmte mig.

Alexa Huston:

Helt sikkert. Det er her, man virkelig skal læne sig op ad Scrum-metoder eller agile praksisser, for ideelt set bør man kunne udgive noget, som kunden kan se, inden for de første par uger. Vi oplever faktisk den modsatte effekt. Der kan være en del uro i begyndelsen, men når vi kommer i gang med udviklingen, og kunden ser tingene regelmæssigt – og som en sidebemærkning inviterer vi dem ind i vores projektstyringssoftware og i Slack – kan de se tingene ske. Det kræver, at der opbygges tillid tidligt, men hvis de stadig er lidt usikre, forsvinder det normalt, når de begynder at se faktiske udgivelser. Selv hvis det endnu ikke er noget, de kan bruge, kan de se og opleve det og forestille sig, hvordan det kommer til at blive, når det udvides over den aftalte periode.

Ben Aston:

I forsøger altså at opbygge tillid ved at skabe gennemsigtighed omkring processen og det, der foregår. Giver I dem fuld adgang til de interne kanaler og værktøjer, så de kan se alt?

Alexa Huston:

Det kan de. Vi har to forskellige Slack-kanaler for hvert projekt, fordi der er ting, man gerne vil holde internt. Hvis man for eksempel skal rapportere et stort problem og først vil tale om, hvordan man vil præsentere det, bruger vi en intern Slack-kanal. Derefter har vi en kanal, som vi kalder projektets navn efterfulgt af »_collab«, hvor alle interessenterne er, og hvor vi opdaterer dem regelmæssigt om status.

Det giver et meget højt niveau af gennemsigtighed, som hjælper.

Ben Aston:

Hvilke andre ting nævnte du i din artikel? Noget, der igen hænger sammen med tillid, er at forhandle scopet undervejs med kunderne. Jeg vil gerne forstå, hvordan I støtter kunderne gennem den proces. Vi arbejder normalt med en forholdsvis uempowered kunde, der rapporterer op gennem organisationen. Forsøger I at komme højere op i organisationen, så I kan få en bedre forståelse? Hvordan fungerer det?

Alexa Huston:

En forudsætning for, at dette bliver effektivt, er, at man har en forholdsvis bemyndiget person på kundesiden, som kan træffe beslutningerne. Vi skal håndtere noget bureaukrati omkring, hvem den egentlige beslutningstager er, og hvordan vi får adgang til vedkommende. Det forsøger vi at afdække i salgsprocessen. Ideelt set har kunden en produktansvarlig, der er teknisk eller designmæssigt stærk. Derefter arbejder vi sammen med dem og sikrer, at de både har adgang til alt og kan træffe beslutninger, og at de ser på køreplanen og omprioriterer ting i backloggen uden for de normale sprints.

Ugen før sprintets opstart omorganiserer de måske produktbackloggen, mens vi støtter dem og giver vores anbefalinger. Nogle gange kan der ske det, at vi har en idé om, hvor vi er efter to måneder, fordi man bør have et overordnet mål. Det er ikke sådan, at man slet ikke ved, hvad man vil bygge.

Det er derfor afgørende at få disse antagelser og overvejelser frem.

Hvis der eksempelvis opstår en situation, hvor en integration ikke kan lade sig gøre, eller et produkt, vi ville licensere, pludselig lukker, er vi nødt til at skifte retning hurtigt og spørge: »Hvilke muligheder har vi?« Det er det, jeg mener med at forhandle scopet. Det var ikke en del af planen, men fordi vi ikke havde en kontrakt med fast scope, behøvede vi ikke nødvendigvis bekymre os om en ændringsordre. Vi sagde bare: »Det er træls. Hvordan kan vi gøre det bedre?« Så traf vi en beslutning som team og bevægede os trygt i den retning. Kundens input og tillid til at gå videre gjorde det muligt.

Ben Aston:

Du nævnte kontrakten. Hvordan ser arbejdsbeskrivelsen ud?

Alexa Huston:

Den er ret enkel. Vi måtte også ændre vores MSA, så den understøttede dette. Den generelle måde, man arbejder med kunderne på, skal passe til denne type samarbejde. Vi tilpassede den derfor lidt og holder derefter kontrakten meget enkel.

Hvis man ser på artiklen, har jeg nogle skærmbilleder med. Vi bruger PandaDoc til at levere vores kontrakter. Det er et godt værktøj, men vi holder det på et højt niveau og fokuserer på: »Hvad er forretningsmålene, og hvilken vej fører til, at de bliver realiseret?« Det er vigtigt at have et billede af, hvad man bygger. Link til brugerhistorier, hvis man har dem, eller til prototypen eller en form for design, hvis man har de aktiver.

Det hjælper med at tegne et billede for både de direkte projektdeltagere og interessenter uden for projektet. Derefter laver vi en tabel, der viser ressourcerne, deres time- eller ugepris og hvor længe de skal være på projektet.

Vi tilføjer også yderligere ting og klausuler, afhængigt af om kunden har brug for support uden for normal arbejdstid eller lignende. Vi kan helt sikkert tilpasse det til kundens behov. Generelt er det dog meget ligetil. Det var en ændring for os, fordi vi tidligere leverede kontrakter på otte eller ni sider, som ingen læste. Det fungerede ikke rigtigt, så vi forsøgte at forenkle det og sikre, at kunderne ved, hvad de køber, før de skriver under.

Hvis det går godt, kommer papirarbejdet bare i baggrunden. Kontrakten skal være underskrevet, og der skal være en fælles forståelse. Men hvis man gør det ordentligt, kan man næsten glemme kontrakten, fordi man kan fokusere på hvert sprint på den måde, der er nødvendig.

Ben Aston:

Du sagde, at man ideelt set begynder med nogle brugerhistorier, et billede eller en idé. Betyder det, at I investerer mere i salgsprocessen og faktisk begynder at definere tingene mere, end I normalt ville, for at mindske risikoen?

Alexa Huston:

Vi forsøger at undgå at give arbejde væk gratis, så det er en fin balance at identificere behovene i salgsprocessen uden at bruge for meget af teamets tid på det. Vi kan for eksempel starte med en eller to ugers teknisk afklaring, en generel strategi- og tilpasningssession, der kickstarter projektet. Derefter skalerer teamet op.

De første to uger er alle måske involveret med en lidt lavere dedikation. Derefter ændrer prisen sig, og teamet skalerer op, så man går fuldt ind i det, der blev afdækket i begyndelsen af samarbejdet.

Du har ret i, at nogle kunder kommer med alle deres ting og siger: »Jeg er klar.« Så siger vi: »Det er fantastisk. Lad os gennemgå dem og sikre, at vi er afstemt, og hvor komfortabel er du, hvis tingene ændrer sig?« For det gør de sandsynligvis. Derfor skal der ske en masse uddannelse fra starten og også undervejs.

Ben Aston:

Hvor falder det så typisk fra hinanden efter din erfaring? Har du historier om, at I prøvede denne tilgang, men at den ikke virkede? Eller at kunden stadig blev skuffet, eller at projektlederen stadig følte sig snydt?

For det lyder fantastisk.

Alexa Huston:

Det er ikke en mirakelkur. Det kræver et team, der er modent omkring det. Hvis nogen er helt nye inden for agile metoder, eller hvis teamet ikke har arbejdet sammen i længere tid, kan det være grunden til, at man ikke vælger denne model. Hvis man har et meget veldefineret scope, og projektet er mere vandfaldspræget, er det også helt fint. Så behøver man ikke tilpasse noget.

Det, der tidligere er gået galt, er, når vi har forsøgt at bevæge os væk fra den måde, vi bedst bygger produkter på, og den måde vi er optimeret på, for i stedet at passe ind i kundens proces på en måde, der skader os. Jeg vil ikke lyde for rigid, for jeg mener, at der altid skal være et samspil og et kompromis mellem to grupper, der mødes i en fælles kontekst.

Men denne model giver projektlederen mulighed for at komme med forslag til produktets bedste, i stedet for at være bange for at gøre det, når der er et fast scope. Ved et fast scope er der altid en frygt for: »Hvis jeg anbefaler dette, sprænger det fuldstændig det, vi arbejder på.« Denne model forebygger det.

Ben Aston:

Som projektleder vil man gerne være strategisk og gøre det rigtige, men nogle gange bliver det vigtigere at levere til tiden, inden for budgettet og det definerede scope. Det er et sørgeligt sted at være, hvis vi ikke faktisk gør det bedste for kunden.

Alexa Huston:

En rigtig god ting for os, da vi begyndte på dette, var, at der naturligvis skal være en juridisk gennemgang mellem kundens team og ens eget team. Det tvinger os til at overveje det sprog, vi bruger, og hvordan det bliver til et juridisk bindende forhold. Man kan begynde med at afprøve det på et internt projekt – man fakturerer naturligvis ikke sig selv – og overveje, hvordan modellen kan anvendes på noget, der ikke er kundevendt. Eksperimentér og stil spørgsmål undervejs, og gennemfør måske retrospektiver for at finde ud af, hvordan det kan gøres bedre.

Tal med udviklerne og designerne for at se, om de tidligere har været en del af denne type samarbejde. Det føles bedre for dem ikke at være bundet af et stramt scope, som de ofte ikke engang kender, før de er på projektet. Det er ikke ideelt.

Tal med det team, der i sidste ende skal udføre arbejdet, og find ud af, hvordan de har det med det.

Ben Aston:

For folk, der lytter og tænker, at de måske skal prøve noget lignende og få kunderne med på idéen – og det bliver sandsynligvis nødt til at være en ny kunde – foreslog du at afprøve det med et internt team og et internt projekt. Er der bestemte typer projekter, hvor du har oplevet, at det fungerer bedre end andre?

Alexa Huston:

Det fungerer rigtig godt ved udvikling på flere platforme. Det første eksempel, hvor vi brugte det, var en ny startup, der ønskede en iOS-app, en Android-app og en webapp. Der var over hundrede brugerhistorier, og det var så stort, at det næsten var umuligt at definere scopet.

Det fungerer derfor rigtig godt ved et produktudviklingsforløb, der er langt, og hvor man skal bruge mange mennesker for at få arbejdet udført. Det fungerer ikke nær så godt til ting som marketingwebsites. Vi laver ikke meget indholdsproduktion, men der er ting, der er mere lineære, og hvor denne løsning måske ikke passer. Det er helt fint; jeg siger ikke, at det skal gælde for alt.

Hvis man har en overordnet idé om, hvor meget man kan nå, eller hvor meget man kan dedikere en person over en uge eller måned, kan man anvende dette på sin virksomhed og se, om det passer.

Det kræver i høj grad et team, der i et vist omfang er vant til at arbejde sammen, kan organisere sig selv omkring forretningsmål og samarbejde. På kundesiden er det afgørende at have en person, der kan træffe beslutninger.

Ben Aston:

Det, jeg godt kan lide ved det, du sagde, er idéen om, at man skal danne teams. Du sagde, at det er godt, når de har arbejdet sammen før og forstår, hvordan det fungerer. Et af de første skridt kan derfor være at danne nogle teams. Jeg kan godt lide idéen om at arbejde på interne projekter.

Få folk til at arbejde på et internt projekt for at se, hvordan det kan fungere. Hvor meget arbejde kan de gennemføre på en måned, to måneder eller tre måneder? Hvordan udvikler det sig? Man skal huske, at tingene ikke altid går efter planen. Ofte skal vi lave omarbejde, men det er en del af processen. Prøv faktisk at finde ud af det, opret nogle teams, og undersøg, hvor meget de kan levere. Derefter kan man begynde at sælge det til en kunde: »Dette er den slags, vi tror, vi kan producere på tre eller seks måneder.« Det er virkelig nyttige råd.

Alexa Huston:

Helt sikkert, og det er anderledes. Vi hentede meget inspiration fra Hanna, som er et fantastisk bureau. De havde mange ressourcer online, og det har de måske stadig, men for cirka tre år siden, da vi satte dette sammen, havde de offentliggjort deres projekter og sagde, at de solgte folk pr. uge. Det var sådan, vi begyndte at tænke på disse dedikerede produktteams, hvilket er anderledes end blot at sælge en person fra bureauet til en kunde og sige: »Ja, I kan få adgang til denne udvikler i to måneder.«

Det skaber nogle problemer og siloer, som vi ikke ønskede at tage med ind i vores virksomhed. Dette er derfor til et større team end blot én person.

Ben Aston:

Det er ikke bare bodyshopping.

Alexa Huston:

Nej.

Ben Aston:

Hvad vil være dit bedste råd til en person, der kæmper med at føre denne idé videre, hvis du tænker på nogle af de udfordringer, I har mødt undervejs? Er der nogle guldkorn, man kan tage med sig?

Alexa Huston:

Jeg hader at reducere det til ét ord, men kommunikation er afgørende. Også internt. Man skal sikre, at teamet har det godt med det. Få alle roller involveret i de tidlige faser af kontraktudarbejdelsen. Kommunikér derefter det til kunden, forklar hvorfor det er godt for dem, og hvorfor det skaber værdi for deres virksomhed. Sørg for, at det understøtter den måde, teamet arbejder på. Vi har en meget agil kultur, og dette hjalp os med at operationalisere noget af den. Det vil være en fordel at kommunikere fordelene og resultaterne frem for aktiviteten.

Men kommuniker.

Ben Aston:

Gode råd. Det er en af de ting, hvor ledelsen nogle gange kan få en idé og bare sætte den i værk: »Det er den nye måde at gøre tingene på.« Men det er virkelig godt råd at kommunikere gennem hele processen og få folks opbakning.

Alexa, mange tak fordi du ville være med i dag. Det har været fantastisk at have dig med.

Alexa Huston:

Det sætter jeg stor pris på.

Ben Aston:

Som jeg nævnte i begyndelsen, kommer Alexa med på vores kommende kursus, der starter i september: Mastering Digital Project Management. Hvis du ikke ved, hvad jeg taler om, men ved, at du har brug for projektlederuddannelse, så kig på det. Det er et syvugers intensivt kursus med en masse interaktive elementer, videolektioner, opgaver, gruppediskussioner og valgfrie coaching-sessioner. Gå til dpmschool.com, og tilmeld dig, før kurset bliver fyldt op.

Hvis du vil bidrage til samtalen om dette og om at indgå kontrakter på en agil måde, kan du kommentere på indlægget. Gå til ressourcesektionen på digitalprojectmanager.com og tilslut dig vores Slack-team, hvor der foregår alle mulige interessante samtaler.

Men indtil næste gang: Tak fordi du lyttede med.