For et par uger siden skrev jeg omkring udfordringen med leverancer på timeafregning. Min hensigt med nyhedsbrevet var, at prøve at nuancere det lidt rosenrøde billede, som agile software development har fået.

Det er uden tvivl en super god proces for software udvikling, men når modellen anvendes i et forhold mellem en kunde og en leverandør, kan den være problematisk.

I dag kunne jeg godt tænke mig at kaste lidt grus i maskineriet på en model, der er baseret på faste priser på projektleverancer.

Og hvorfor så det, tænker du måske?

Hvorfor skal man nødvendigvis være så kritisk overfor begge de primære modeller?

Årsagen er egentlig, at jeg faktisk ikke mener, at nogen af modellerne er perfekte.

De har begge fejl og mangler. Desværre.

Og faktisk er det jo de to modeller, vi typisk anvender hos Twentyfour. Leverancer på fast pris er fundamentet for langt størstedelen af vores projekter. Det hænder dog, at vi kører efter en model baseret på timeafregning. Særligt på mindre opgaver.

Anyway.

Jeg har ikke tænkt mig, at sælge dig idéen, om at du skal købe en masse software i min virksomhed, fordi projekter på fast pris bare er lykken.

Jeg har heller ikke tænkt mig at prøve at sælge dig idéen om det modsatte.

Faktisk er min mission slet ikke at sælge dig noget. Min mission er at få dig til at reflektere over emnet, så du kan stille de rigtige spørgsmål, næste gang du køber et projekt. Alternativt kan du bruge det i din egen forretning.

Nu til sagen.

De primære ulemper ved projekter på fast pris er følgende:

1. Hvis man sætter en fast pris, som er uafhængig af timeantal, er det i leverandørens interesse at bruge så få timer som muligt på at levere. Jo færre timer (og øvrige ressourcer) der anvendes, des flere penge tjener leverandøren.
2. Hvis der er aftalt en fast leverance, kan projektet blive meget rigidt fra både leverandør og kunde. Det er således ikke i leverandørens interesse at ændre på noget som helst i scope uden prisen også ændres. Hvis et projekt er meget stort, kan det skabe enorme problemer, hvis et uforudset og udefineret element af et projekt pludselig opdages. Hvem skal betale? Skal det overhovedet leveres? Hvem har ansvaret for at opdage, at dette element overhovedet burde have været med i projektet?
3. Det er svært at motivere sin leverandør til at finde på nye og smarte løsninger undervejs i et projekt, da dette ikke gør nogen forskel for leverandørens indtjening på projektet.

Hvad dælen er så den perfekte model?

Umiddelbart er det sgu nok lidt deprimerende, men sandheden er - efter min mening - at den ikke findes.

Hos Twentyfour prøver vi selvfølgelig hele tiden at blive bedre, men vejen til perfektion er belagt med trial and error, skuffelser og up’s ’n’ down’s.

Vi har dog for nyligt fundet en model, som vi virkelig holder af.

Og bare roligt - jeg er ikke i gang med at prøve at sælge dig noget, så læs endelig videre :-)

Vi har nemlig over de sidste par år ændret vores model, så vi prøver - så vidt muligt - at få leverancer til at være så standiserede som muligt.

Hvorfor nu det?

Vores store udfordring har været, at vi gerne vil have at medarbejdere hos Twentyfour fokuserer på bl.a. følgende.

1. Høj kvalitet til kunderne (dvs. meget tid og energi skal bruges på alle projekter og detaljer i disse).
2. Der skal ikke bruges mere tid, end der er betalt for (da vi så arbejder gratis)
3. Vi er løbende nødt til at sælge mere (hvor det skaber værdi), da vi jo er afhængige af projekter - og dermed salg.

Ovenstående 3 punkter er dog svære at forene, hvorfor vi har fundet på en ny model.

For et par år siden begyndte vi nemlig at produktificere en del af vores leverancer. På samme tid fokuserede vi på et smallere segment af kunder, således at vi kunne genbruge. Sidst - men bestemt ikke mindst - introducerede vi faste aftaler (abonnementer) på bl.a. følgende ydelser fire ydelser;

1. Opdatering af software/websystemer (Som f.eks. CMS’er)
2. Hosting og drift (Herunder skalering af servere)
3. Integrationsløsninger (F.eks. Ax, Nav, SAP og diverse CMS’er)
4. Diverse produkter (F.eks. sikkerhedsprodukter, NemID, UniLogin og diverse features)

Ovenstående ændring har betydet, at vi i dag får cirka halvdelen af vores omsætning på faste aftaler. Når halvdelen af omsætningen kommer som recurring, betyder det, at vi faktisk ikke længere er nødt til at sikre, at vores medarbejdere kan fakturere alle timer. Helt konkret har vi råd til, at vores medarbejdere bruger endnu mere tid på kvalitet, service og produktudvikling. Kort sagt, alt det som en 100% projektbaseret virksomhed dårligt kan prioritere (da det er for dyrt og ikke giver afkast på kort sigt).

Vi har derfor fået startet en positiv spiral, hvor vores medarbejdere kan bruge mere og mere energi på at gøre vores produkter og drifts- og serviceaftaler endnu bedre. Det giver gladere kunder, bedre leverancer og faktisk også gladere medarbejdere.

Det betyder også, at vi kan tillade os at sige "nej" til flere projekter og i stedet blot tage de projekter ind, som vi synes skaber værdi for os og for kunden.

Det er jo ret banalt, men det er en enormt svær overgang for langt de fleste traditionelle konsulenthuse og bureauer, da man på kort sigt opgiver omsætning.

Vi har været heldige (og dygtige), for vi har formålet at skifte fokus, således at vi ikke længere er en traditionel projektbaseret bureau-biks, men det betyder dog ikke at udfordringerne stopper.

Vores model med faste aftaler og fokus på produktudvikling har ikke løst alle problemer med projekter, men det har gjort problemerne væsentligt mindre. Vi er nemlig ikke afhængige af en enkelt kundes projekt og vi er ikke afhængige af, at skulle presse enhver krone ud af kunderne.

Det gør både mig glad og det gør mine medarbejdere glade.

Tak fordi du læste med i dag! Kritik og tanker modtages med kyshånd.

Ha’ en skøn dag.