Få agile kontrakter til at fungere for dine teams og kunder

Men der opstår problemer. Prioriteter ændrer sig. Uforudsete udfordringer dukker op. Nu har du den unikke fornøjelse at skulle håndtere alle mulige udfordringer, jonglere med ændringsordrer og i sidste ende gøre alt, hvad der står i din magt, for at sikre, at kunden er tilfreds, og at bureauet forbliver rentabelt. Eftersom alle projektledere er superhelte i forklædning, er der stor sandsynlighed for, at du får styr på det hele, men det stramt fastlåste omfang, de var underlagt, hjælper bestemt ikke.

Hvad nu hvis jeg fortalte dig, at der findes måder at udforme dine kontrakter på, som kan mindske noget af den neglebidende stress og give teamet mulighed for at levere deres bedste arbejde?

I denne artikel vil jeg beskrive en type agil kontrakt, som vores produktudviklingsbureau har taget til sig i løbet af de seneste år, og som vi har kaldt en varigheds- og priskontrakt. Efter at have skiftet til denne agile kontrakt har vi været i stand til operationelt at understøtte vores agile metoder og fokusere på værdien og resultaterne af et projekt frem for de små detaljer, der ofte står anført i andre typer SOW'er.

Målet med denne artikel er at hjælpe dig med at forstå en anden måde at strukturere bureaukontrakter og agile metoder i bureauet på for at skabe resultater og omsætning på bundlinjen.

Varigheds- og priskontrakter: Hvad er de?

Varigheds- og priskontrakter er et begreb, vi har fundet frem til for at beskrive vores foretrukne måde at drive forretning med vores kunder på. Med varigheds- og priskontrakter fastsættes projektomkostningen ud fra, hvor længe vores teammedlemmer arbejder på projektet. Vi går i detaljer med det senere.

Kan du huske, at du læste det agile manifest og så den del, hvor der står: “kundesamarbejde frem for kontraktforhandling”? Det var her, det hele begyndte for os.

Crema er et produktudviklingsbureau med et distribueret team fordelt over hele landet og hovedkontor i Kansas City, Missouri. Efter mere end seks år med kontrakter baseret på fastlagt omfang og vandfaldsmodellen brugte vores team i stigende grad agile metoder til at bygge produkter. Vi ønskede at skabe en agil kontrakt, der fungerede for os og vores kunder. På samme måde ville en agil kontrakt bedre understøtte vores samarbejdskultur og vores fokus på den værdi, vi skabte for de kundeteams, vi arbejdede sammen med. Vi mente, at der måtte være en bedre måde end at opremse specifikke leverancer eller klart afgrænsede funktioner, før produktet overhovedet var påbegyndt.

Efter noget research, som vi vender tilbage til senere i denne artikel, indså vores team, at vi havde brug for at skabe en prisstruktur, der gjorde det muligt for os at være fleksible, samtidig med at det blev tydeligt, hvad en kunde købte. Hvis vores kunder i sidste ende køber adgang til vores teammedlemmer, hvorfor forsøgte vi så at blive målt på en liste over specifikationer, som vi kunne forvente ville ændre sig? Vi begyndte at fokusere på idéen om et dedikeret produktteam, det vil sige et sæt individuelle roller, der var knyttet til et bestemt projekt over en periode.

Vi begyndte at eksperimentere med formuleringer, der understøttede denne idé og skabte klarhed for vores kunder. Vi ønskede, at de skulle forstå, at det produktteam, de ville arbejde sammen med for at nå deres mål, kunne gøre det uden at være bundet til et specifikt omfang. Det er muligt, fordi vi forhandler omfanget med vores kunder undervejs. De betaler for at arbejde sammen med et team i en bestemt periode. Prisen beregnes ud fra antallet af teammedlemmer, deres varierende grad af tilknytning og en fastsat tidsperiode.

Således opstod navnet varigheds- og priskontrakter. Over for vores kunder kalder vi dem engagementssammendrag, men vi gør dem fortrolige med terminologien “varighed og pris” gennem salgsprocessen, indtil aftalen er indgået.

Hvis man opdeler elementerne, ser det sådan ud:

• Varighed er længden på samarbejdet fra den godkendte startdato til opsigelsesdatoen.
• Pris er de gebyrer, der er knyttet til projektsamarbejdet, og som fastsættes ud fra de ugentlige satser for medlemmerne af produktionsteamet.

Stay Ahead of What Deserves Your Attention

Get timely perspective on the shifts, decisions, and trade-offs shaping your role, plus practical resources you can put to work.

Get Free Access

Have an account? Log In

Yderligere kontekst

Det skete ikke i et vakuum. Vi så i høj grad på andre produktbureauer, som vi beundrede, for at hente inspiration. Teamet hos Hanno har altid været en inspirationskilde for os. Deres model var tilgængelig online på det tidspunkt, og de skrev helt enkelt, at de havde en tilgang, hvor de “sælger mennesker pr. uge”. Denne helt enkle strategi skilte sig ud for os, fordi den stemte overens med vores koncept om dedikerede produktteams. Vi tog det, vi kunne finde hos Hanno og andre i branchen, og begyndte at udforme vores egen version af det.

Dette skete heller ikke fra den ene dag til den anden. Der var masser af forsøg og fejl, når det gjaldt om at få sproget rigtigt, finde ud af hvordan og hvor vi skulle integrere det i salgsprocessen, og – naturligvis – hvordan vi skulle føre det ud i livet, når vi havde landet aftalen. Vi ville udfordre os selv til at ændre os og nå frem til et bedre sted, fordi faste omfang fik os til at absorbere ekstraarbejde i månedsvis og nogle gange bandt vores team på hænder og fødder, så de ikke kunne levere deres bedste arbejde.

Mens vi eksperimenterede med et mere agilt sprog i aftaler med fast omfang, begyndte vi at holde møder med en potentiel kunde ved navn tilr. På det tidspunkt var de en nystartet virksomhed i vækst, der arbejdede på at forandre rekrutteringsområdet. Vi indledte en 3-dages strategisession med dem, som resulterede i grove skitser samt mere end 100 brugerhistorier. De ønskede at gå videre med fuld udvikling til web- og mobilplatforme, men vi følte os ikke trygge ved at definere alt i en fast kontrakt. Det ville være ren gætværk, og det føltes ikke som den bedste måde at indlede et nyt partnerskab med en gruppe, som vi havde en virkelig god kemi med.

Internt forsøgte vi at finde en måde at levere en agil kontrakt, der var større end noget, vi tidligere havde gjort, uden at gennemføre en fuld afdækningsproces. Hvis der nogensinde var et perfekt tidspunkt til at udnytte en aftale om varighed og pris, var det dér. Efter at have identificeret, hvor lang tid vi ville bruge på at designe, udvikle og teste dette helt nye produkt, samt hvilke teammedlemmer der skulle involveres, brugte vi brugerhistorierne som vores udgangspunkt. Vi gjorde det klart, at tilr-teamet skulle betale for det aftalte niveau af teamets dedikation – ikke for omfanget.

Misforstå mig ikke – der var en intern debat om denne tilgang. Nogle anbefalede, at vi gennemførte en fuld afdækning for at indsnævre og specificere omfanget, men andre frygtede, at det ville få dem til at trække sig. Vi ønskede et langsigtet forhold til denne kunde.

Til sidst blev vi alle enige, og vi sendte vores første fulde aftale om varighed og pris af sted lige før Thanksgiving i 2015 og krydsede fingre for, at det bedste ville ske. Det var et spring ud i det ukendte, og helt ærligt gik det imod nogle af vores konventioner på det tidspunkt.

Da aftalen var på kundens banehalvdel, fulgte der nogle efterfølgende drøftelser med deres team samt en ret intens juridisk gennemgang, der tog et par uger. Denne proces gjorde det muligt for vores team at gennemgå den agile kontrakt igen og igen, stramme formuleringerne op og finpudse hele tilgangen. Set i bakspejlet var det en god ting. Vi følte, at den samlede tre vigtige ting:

1. Hvad vores kunder ønskede
2. Hvordan vi ønskede at lede os selv
3. Hvordan vores kultur fungerede

Og ved du hvad? Det virkede. De var kunde hos os i næsten 3 år.

Overvejelser ved implementering

Lad os gå tilbage til scenariet, der startede hele denne artikel. Den vigtigste anbefaling, jeg kan give for at forebygge den smerte, der er forbundet med dette, er at involvere projektledelsen i salgsprocessen (eller i det mindste kigge nærmere i softwaren til styring af kunderelationer). Ud over produktionsmedlemmerne i teamet bliver de nemlig dem, der arbejder helt nede i detaljerne for at sikre, at det, der er afgrænset og lovet, rent faktisk kan leveres. Hvis projektledere holdes ude af salgsprocessen, resulterer det normalt i mindre optimale kontrakter, hvor detaljer overses, og forventninger til ting som tilgængelighed for kunder ikke stemmer overens.

Det vigtigste ved implementering af enhver form for agil kontrakt er at etablere processer og samtaler, så kunden ikke tror, at de skriver en blankocheck. Vi er omhyggelige med at sikre, at den agile kontrakt ikke antyder, at vi ikke ved, hvad vi laver. Tværtimod investerer vi stadig en hel del tid i begyndelsen på at identificere hvad og hvordan vi vil få arbejdet udført. Desuden har vi opbygget en produktudviklingsproces, som vi kender og stoler på.

Før vi går ind i de konkrete detaljer, bør jeg nævne, at du skal sikre, at din MSA eller andre eksisterende aftaler bliver gennemgået, så de understøtter denne type arbejdsforhold. Det er afgørende for at sikre, at du kan gøre en agil kontrakt operationel.

Når vi har vurderet, at en mulighed er kvalificeret, udarbejder vi et første udkast til et forslag, der gentager beskrivelsen af samarbejdet, hvad kundens mål er, og hvordan vi vil strukturere teamet omkring målsætningerne. Det er et arbejdsdokument, som vi ender med at redigere et par gange sammen med kundens team. Vi vil danne os et indtryk af, om budgettet stemmer overens, ligesom vi ser på tidsplanen og andre specifikke detaljer. Typisk starter vi med et samarbejde på 4-6 uger, hvor vi skaber prototyper af produkter med høj detaljeringsgrad for at teste & validere antagelser. Samtidig planlægger vores tekniske team teknologistakken og undersøger de integrationer og tredjepartsværktøjer, vi får brug for.

Når vi er enige, bruger vi PandaDoc til at levere alle vores kontrakter. Vi har oprettet en skabelon til vores team, så vi nemt kan oprette en aftale om varighed og pris, når vi har fået grønt lys til forslaget. Den er bevidst enkel.

Ideelt set vil alle disse fremhævede sektioner – eller »tokens«, som PandaDoc kalder dem – være blevet identificeret, før vi begynder at udarbejde kontrakten. Vi udfylder hver sektion med det overordnede mål, vi sigter mod at opnå sammen med vores kunder, og uddyber den tilgang, vi vil anvende for at nå dertil (dvs. 2 runder med brugertests, 3 måneders produktudviklingssprints osv.).

Derefter opstiller vi teammedlemmerne og graden af dedikation, som hver af dem vil have gennem hele samarbejdet. I dette eksempel brugte jeg et 12-ugers samarbejde med et komplet produktteam med varierende grader af dedikation og en blandet sats på $100 i timen. Det er nemt at lege med dette og se, hvordan dedikation, varighed og sats påvirker prisen.

Af hensyn til gennemsigtigheden bør jeg også nævne et par ting:

• Selv hvis teammedlemmerne fakturerer til forskellige satser, kan du justere det i den anden kolonne for at nå frem til hver delsum.
• Vi betragter »fuld tid« som 35 timer om ugen på kundeopgaver. Vi holder yderligere 7 timer fri hver uge, så teammedlemmerne kan fokusere på interne projekter og administration.
  • Det forklarer vi vores kunder. Det hjælper med at begrænse forestillingen om, at kunderne kan have ubegrænset adgang til teammedlemmerne under hele samarbejdet.
  • Hvis vi har brug for at angive mere specifikke arbejdstider eller supporttider for et bestemt projekt, kan vi gøre det i samarbejdsoversigten. Den er beregnet til at blive udbygget for at understøtte kundens mål.

Sådan opnår du opbakning til en agil kontrakt

Hvis der er ét gennemgående tema i denne artikel, er det kommunikation. For at opnå opbakning til en agil kontrakt bør du forvente at investere betydelig tid i at undersøge, informere og gentage din tilgang internt. Kast idéerne ud til gruppen. Eksperimentér med en agil kontrakt på et internt projekt. Gennemfør projektre­trospektiver for at følge med i, hvad der fungerer, og hvad der skal ændres. Spørg dit produktionsteam, om de tidligere har arbejdet med forskellige typer af agile kontrakter.

Når I internt er på samme side, skal du informere dine potentielle og endelige kunder – ikke kun indledningsvist, men gennem hele processen. Tal med dem om de regelmæssige sessioner til klargøring af backloggen. Mind dem om, at de sidder i førersædet, når det gælder om at fastlægge prioriteter og beslutte, hvad der bliver gennemført i hvert sprint. Gentag fokusset på værdi og resultater frem for specifikke funktioner. Der vil være masser af tid til at gå i detaljer med funktionerne, når et sprint planlægges og er i gang.

Der findes ingen mirakelkur til at få alle til at være på linje. Det kræver tro på idéen, vilje til at eksperimentere og løbende oplysning. Hvis du mener, at denne type agile kontrakt kunne fungere for din virksomhed, så find nogle interne fortalere, der har det på samme måde, og kom i gang!

Fordele og ulemper

Som med det meste i livet er der fordele og ulemper ved varigheds- og priskontrakter. Vi har gjort dette i omkring 3 år og har fundet frem til, at følgende ting er sande. Lad os begynde med det positive.

Fordele:

• Varigheds- og priskontrakter gør det hurtigt at få det formelle papirarbejde for et projekt på plads.
• De reducerer betydningen af kontraktlige forpligtelser, når et projekt først er sat i gang. Teamet kan ændre retning, hvis eller når der opstår nye forhold.
• På grund af dette kan teamet fokusere på at udføre sit bedste arbejde.
• Teamet kan også foreslå ting til gavn for produktet uden frygt for, at det bringer hele omfanget ud af balance. Det kan skabe mere værdi på kortere tid, fordi teamet ikke er bundet af et omfangsdokument.
• Det placerer kunden for bordenden. Kunden får lov til at træffe beslutninger undervejs. Uanset hvor godt en kunde ved, hvad vedkommende ønsker, før et projekt begynder, vil tingene ændre sig. Varigheds- og priskontrakter understøtter denne virkelighed.
• Fordi kontrakten generelt kan træde i baggrunden, gavner det forholdet som helhed. Teamet kan fokusere på produktet og den værdi, det tilfører virksomheden.
• De gør ressourceplanlægningen lettere. Vi holder vores dedikationer så enkle som: en fjerdedel tid, halv tid eller fuld tid.
• Fuld tids dedikation for vores teammedlemmer er ideel set fra et udnyttelsesperspektiv. Vi forsøger at tilbyde dette så ofte som muligt, især i udviklingsroller.
• Ved dagens slutning får vi stadig betaling, men der er mindre administrativt arbejde forbundet med ændringsordrer og andre problemer, der opstår ved et fast omfang. Sig farvel til nogle administrative hovedpiner!

Ulemper:

• Det er et sværere salg. Du skal forpligte dig til uddannelsesdelen fra dag ét over for potentielle kunder og gentage processen og værdien, så en kunde føler sig tryg ved en agil kontrakt. De, der har stor erfaring, er som regel blevet brændt før og forstår det. Mindre erfarne kunder kan have brug for nogle analogier for bedre at forstå, hvad en agil kontrakt er. Brug tiden på at uddanne dem!
• Du kan være nødt til at forlænge den tid, det tager at afslutte en aftale, for at sikre, at alle er trygge ved målene for samarbejdet.
• Fra et forretningsperspektiv begrænser det muligheden for at ramme plet med hensyn til rentabilitet. Hvis teamet bliver færdigt med noget før tid, kan du ikke høste fordelene ved den fortjeneste. Den gode nyhed er, at marginen er pålidelig, men du får ikke lov til at beholde noget overskud på grund af effektiviteten.
• Hvis disse agile kontrakter bliver bredt anvendt, kan de blive et alt for oplagt valg til alt. Realistisk set egner nogle projekter sig ikke til aftaler baseret på varighed og pris. Hvis dit team er uerfarent eller nyt inden for agile processer, er det ikke en anbefalet tilgang.
• Tilsvarende er det helt i orden, efterhånden som en organisation vokser, at bruge kontrakter med fast omfang til mindre projekter med et veldefineret omfang.

Forholdet til andre kontrakttyper

Der findes mange andre typer arbejdsomfang, som virksomheder bruger til denne type arbejde. Her er, hvordan vi mener, at aftaler om varighed og pris adskiller sig fra andre muligheder.

• Værdibaseret prissætning: Det er vanskeligt at gøre i et bureau uden en solid forståelse af, hvor meget arbejdet på lang sigt vil spare kunden for, og uden at basere prissætningen på det. Aftaler om varighed og pris fokuserer på værdien, men vi baserer ikke beløbet på selve værdien.
• Fast omfang: Vi har gennem hele denne artikel sat denne type kontrakt i kontrast til andre, men i en kontrakt med fast omfang er teams strengt bundet til et fastlagt sæt leverancer. Varighed og pris er ikke knyttet til leverancer, men snarere til en fælles vision & forventede resultater.
• Tid og materialer: I denne ordning får du kun betaling for det, du færdiggør. Med aftaler om varighed og pris fakturerer vi et fast beløb for de ressourcer, der arbejder på et projekt i en fastlagt periode. Vi fakturerer ikke timer, selvom vi holder øje med, hvordan teammedlemmerne bruger deres tid, især når det gælder ressourcer, der arbejder halvtid eller kvart tid, så vi kan hjælpe med at håndtere udfordringer med tidsstyring.

Visdomsord fra vores COO

Jeg gik direkte til vores COO, Dan Linhart, da jeg besluttede mig for at skrive denne artikel, for at få det fulde billede af den indvirkning, det har haft og fortsat har på vores virksomhed. Han gav mig nogle visdomsord, som er værd at dele.

Til at begynde med sagde han: “Det er utrolig vigtigt at få alle roller involveret i de indledende faser. Det omfatter ejerne, forretningsudviklingen, produktionsrollerne og strategerne. Hvis I ikke bliver enige om det, kommer det simpelthen ikke til at ske.”

Han fremhævede betydningen af internt at sælge idéen og uddanne alle interessenter i bureauet. Selv hvis du oplever bedragersyndrom, skal du fortsætte og lære mere om modellen. Han sagde til mig: “Hvis du kan sælge dit team idéen, kan du sælge den til din kunde.” Potentielle kunder har brug for at kende fordelene ved agile metoder og agile kontrakter, så du kan mindske deres usikkerhed. De skal kunne videreformidle dette til andre interessenter på deres side.

Men derudover har denne type agile kontrakt og virksomhedskultur en enorm betydning. Du skal sikre dig, at dette hænger sammen med den måde, I arbejder som team på. Hos Crema passer denne agile kontrakt godt sammen med vores filosofi og den måde, vi udvikler produkter på. Hvis din organisation i højere grad er baseret på vandfaldsmodellen, er det helt i orden at holde fast i specifikationer.

Endelig skal du ikke være bange for at prøve. Du kan eksperimentere med aftaler om varighed og pris i så lidt som én uge. Det smukke ved denne model er, at den kan skaleres fra en uge til flere år, afhængigt af organisationens processer og modenhed. Få de rigtige mennesker involveret til at styre tiden, giv teamet og kunden de nødvendige beføjelser, og spænd sikkerhedsselen til en agil arbejdsform, der er ideel for et team.

Ansvarsfraskrivelse: Denne artikel har til formål at uddanne og inspirere til en lettere måde at arbejde med en mere agil kontrakt på. Den er hverken udtømmende eller juridisk rådgivende. Jeg håber, at noget af det, du har læst, kan være nyttigt i dit bureau eller din virksomhed.

Hvad er det næste?

Få mere at vide om agile metoder og centrale agile begreber ved at tage en af disse agile certificeringer.