Budgetstyring i agile udviklingsprojekter

To softwareudviklere i Centic

Skab de bedste forudsætninger for at styre økonomien i softwareudviklingsprojekter

Når man som virksomhed skal have udviklet software, er omkostningerne for udviklingsarbejdet noget af det første, man ønsker at få overblik over. Derfor er det tillokkende at bede om en fast pris på projektet, da det giver et umiddelbart overblik over økonomien.

 

Men al erfaring viser, at fastprisprojekter ender med at blive et problem for både kunde og leverandør, og det gør det fordi de reelle detaljerede specifikationer først bliver til undervejs i udviklingen, også selvom der er brugt et stort antal timer på analyse.

 

Det betyder så, at der kommer masser af ændringsønsker, som vil være dyre for kunden og besværlige at styre for leverandøren. Og derfor bør man kontrollere økonomien i et softwareprojekt på en anden måde.

 

Nedenfor går vi i dybden, med hvad I som virksomhed skal være opmærksomme på, når I skal styre økonomien i jeres softwareudviklingsprojekt.

“Samlet set vil det typiske resultatet af en fastprisaftale være, at den endelige løsning er mindre optimal og det samlede tidsforbrug er væsentligt højere.”

Fast pris og softwareudvikling

For at give en fast pris på et projekt, som ender med at tage måske 1.000 timer, skal leverandøren bruge 100-200 timer for at kunne give et estimat der virkelig holder vand. Disse timer bruges til at gennemskue og modne kravene, lave beskrivelser og mockups, estimere hundredevis af delopgaver samt gennemgå det hele med kunden.

 

Dette store tidsforbrug er et problem.

 

Enten kan I stå i den situation, at leverandøren gør alt dette uden betaling, hvilket umiddelbart virker attraktivt som kunde. Men skal man så huske at gøre sig overvejelser omkring hvad er det for en virksomhed, der bruger så mange ressourcer på at give et tilbud – er den virksomhed levedygtig?

 

En anden mulighed er, at leverandøren kræver betaling for analyse og estimering, f.eks. til kostpris. Så skal I som kunde betale et betydeligt beløb for at få en pris, men hvad så hvis denne pris viser sig at være problematisk?

 

Udviklingsprocessen i fastprisprojekter

Kommer man så alligevel videre fra de to bespænd ovenfor og indgår en fastprisaftale, skal man være opmærksom på, at det vil være i leverandørens interesse at kræve merbetaling for enhver lille forskel mellem opgavebeskrivelsen og det der viser sig reelt at være den bedste løsning. Og det er også i leverandørens interesse at lave den billigst mulige version af det der er beskrevet. Uden blik for hvad der skal ske med løsningen om fem eller ti år – det gælder for leverandøren om at få leveret det aftalte med færrest mulige timer.

 

Samlet set vil det typiske resultatet af en fastprisaftale så være, at den endelige løsning ikke er optimal og at det samlede tidsforbrug er betydeligt højere end forventet, fordi der bruges meget tid på administration, diskussioner og ændringer.

 

Merforbruget af tid kan have en af to konsekvenser. Den ene er, at timerne ender på regningen, så projektet bliver markant dyrere end den faste pris, som kunden mente at have. Den anden mulighed er, at leverandøren ikke evner at køre en hård kravstyring, og derfor påtager sig ekstratimerne og kommer ud af projektet med et tab. Og så er vi tilbage ved det med leverandører, der ikke kan finde ud af at tjene penge. Hvordan ser deres fremtid ud?

It-system pris

Hvordan styrer I bedst økonomien som kunde i softwareudvikling?

Udfordringerne ved at gå efter en fast pris på at få udviklet en softwareløsning vil tit påvirke brugen af løsningen i hele levetiden. Derfor er et fastprisprojekt generelt ikke en god idé – især ikke hvis man er en større virksomhed, der skal indkøbe en løsning, som skal anvendes i en længere årrække, og som har råd til at anskue økonomien i et livscyklusperspektiv.

 

Så man skal holde sig til at få udviklet sin løsning efter agile principper, som al erfaring viser, giver de bedste resultater, og så er der en række tiltag, man bør gøre brug af for at styre økonomien. Dem går vi igennem nedenfor.

 

Brug en rådgiver

Det første tip er, at man bør have en kompetent rådgiver indover. Det gælder både i forbindelse med at træffe valget om at få lavet en skræddersyet løsning og hvilken leverandør og teknologi man går med. Men det gælder også før opstart og undervejs.

 

Rådgiveren bør være en person, der har god erfaring med udvikling af softwareløsninger, men som også har forstand på økonomi og forstår branchen m.m.

 

Rådgiveren skal sikre, at man tager sine forholdsregler for at styre økonomien i projektet. Og det handler både om, at der er styr på den måde, leverandøren agerer på, men også om at kunden selv agerer på en måde, der er hensigtsmæssig.

Ideelt set er rådgiveren en intern person, som ikke har andre aktier i projektet.

 

Prisindikation

En fornuftig leverandør bør være i stand til at lave en overordnet liste af funktioner i løsningen (såkaldte epics) og ud fra denne sammenligne med andre projekter, som virksomheden har lavet. Herudfra bør leverandøren kunne give et overslag på timetal og i forlængelse heraf en prisindikation.

 

En variant af dette er, at man afdækker den datamodel, som den nye løsning vil have sammen med antallet af visninger og snitflader til andre systemer og herudfra bruger sin erfaring til at vurdere projektets omfang.

 

Det er vigtigt, at leverandøren ikke bare sender en mail og skriver at det tager ca. 800 timer, men også overleverer grundlaget for overslaget, så man som kunde kan vurdere, om det matcher hele projektet og også kan bruge det til at følge op på senere.

“Start med at bygge en helt simpel version af løsningen og byg først mere avancerede funktioner på, efter brugerne har haft mulighed for at teste den simple version.”

Gå efter MVP – og styr de interne krav

Mange virksomheder har fået udviklet softwareløsninger, der indeholder funktioner, som aldrig bliver brugt. Funktionerne forekom værdifulde, da man byggede løsningen, men viste sig at være overflødige i reel brug.

 

Til gengæld har man efterfølgende typisk været nødt til at bruge penge på andre funktioner, som man ikke havde tænkt over, men som er nødvendige, for at løsningen fungerer godt i praksis for brugerne.

Dette er helt normalt, når man bygger en softwareløsning, men man minimerer problematikken ved at starte med at lave en såkaldt MVP-løsning.

 

MVP (minimal viable product) betyder, at man starter med at bygge en helt simpel version af løsningen og først bygger mere avancerede funktioner på, efter brugerne har haft mulighed for at teste den simple version. Når brugerne så har den konkrete løsning i hænderne, har de meget bedre forudsætninger for at vurdere systemets detaljer, end hvis det er abstrakt formulerede krav.

 

MVP-tilgangen gør det også nemmere for kunden at styre sine egne krav, og inden for software der udvikles efter god branchestandard, er tidsforbruget for en ikke afhængigt af, om man laver den med det samme eller afventer om det er nødvendigt og så bygger det på senere.

“Som kunde bør man gå efter en leverandør, der holder på den lange bane. Men samtidig bør man også sikre sig, at man har en situation, hvor man kan skifte udviklingsleverandør uden større konsekvenser”

Kontrakter og agil udvikling

I mange kontrakter hvor der skal bygges noget nyt – f.eks. et hus eller et skib – vil der være en gensidig forpligtelse for kunde og leverandør for at opfylde kontrakten. Leverandøren skal levere det aftalte og kunden er forpligtet til at modtage leverancen og til at betale.

 

Sådan bør det ikke nødvendigvis være ved en softwareleverance.

 

Hvis man har gjort sit forarbejde godt, vil man have sikret sig, at løsningen er bygget på en måde, så man er fornuftigt stillet, hvis man finder det rigtigt at afbryde samarbejdet, før softwaren er færdigudviklet.

 

Oplever man som kunde, at leverancen er for dyr, at kvaliteten ikke er som ventet, eller at leveringen er for langsom, bør man have sikret, at man kan tage den kildekode, som man har betalt for og gå videre med et andet udviklingshus. Og leverandøren bør faktisk også være interesseret i en sådan kontrakt, da den bør være nemmere for kunden at tiltræde.

It konsulent i Centic

Vær godt klædt på til at få udviklet en softwareløsning

Ved at have ovenstående in mente når I overvejer at få udviklet en softwareløsning til jeres virksomhed, er I godt klædt på, hvis I vælger at få udviklet en løsning sammen med et udviklingshus.

 

For at styre økonomien bedst muligt, skal I fokusere på disse forhold:

 

 
Ovenstående er skrevet med med fokus på økonomistyring, når man vil investere i et stykke software, men vi har også skrevet blogindlæg omkring hvad god kvalitet handler om inden for software, om hvad agil udvikling egentlig er og om hvorfor man skal forholde sig til hele løsningens levetid, når man investerer i software.
 

Og har I spørgsmål vedrørende softwareudvikling, er I velkomne til at række ud til os hos Centic. Så er vi klar til at rådgive jer om den rette løsning til jeres projekt.