De flesta externa utvecklingssamarbeten är faktiskt dyrare än vad de borde vara. Inte på grund av timpriset, utan på grund av allt det andra.
Möten som inte leder någonstans, agila ritualer som blivit självändamål, kortsiktiga tekniska beslut som blir dyra på sikt, och konsulter som väntar på beslut eller hårdvara. Detta ser vi hos många företag vi träffar idag. Och det är också anledningen till att vi nyligen samlade våra observationer i ett webinar där vår VD Fredrik Hjort och embedded-specialisten Jonas Svensson gick igenom var pengarna faktiskt tar vägen i utvecklingsprojekt.
Möteshysteri och rollinflation
Det vanligaste vi ser är att en stor del av arbetsveckan går åt till möten. Inte för att teamen är dåligt organiserade, utan för att organisationen försökt lösa komplexitet genom att lägga till fler roller och fler avstämningar. Innan en utvecklare ens börjat skriva en rad kod har idén passerat sju roller: från marknad till Product Manager, Product Owner, kravingenjör, Scrum Master, systemarkitekt och slutligen utvecklaren själv. I varje överlämning tappas något.
Detta är vad vi kallar viskleken och den kostar mer än vad man kan tro. Det är inte så många som faktiskt räknat på vad detta kostar.
Ett räkneexempel från våra egna projekt
Ett team på sju personer som kör Scrum ”by the book” med tvåveckorssprintar spenderar cirka 230 timmar per person och år bara i mötestid. Det motsvarar cirka 1,2 miljoner kronor på ett år, bara i möten.
Ett team som kör samma metod men ”light” (med gemensam retro och review, tre dailies i veckan istället för fem) landar på strax under 900 000 kronor. Skillnaden är 340 000 kronor. Från samma leverans.
Vi använder Scrum själva, så det här handlar inte om att metoden är fel. Det handlar om att den ofta appliceras utan att någon räknat på vad den faktiskt kostar. I ett av våra egna 2500-timmarsprojekt varierade mötestiden mellan 4 och 15 procent beroende på fas. Genom att våga anpassa upplägget efter projektets faser, istället för att köra samma modell rakt igenom, gjorde vi en märkbar besparing. Uträkningarna bygger på svenska marknadspriser för seniora utvecklare. Kompletta antaganden och beräkningar finns i fördjupningen.
Det här är ett av flera räkneexempel vi tagit fram. I vår fördjupning visar vi hur olika sprintstrukturer, teamstorlekar och samarbetsmodeller påverkar totalkostnaden. Du kan ladda ned fördjupningen nedan genom att trycka på ”Ladda ned”.
Ladda ned fördjupningen med alla räkneexempel, den strategiska modellen med utfall från våra egna projekt, och en utökad checklista inför nästa avtal.
Timmar eller leverans, vad köper du egentligen?
Det som ofta har större ekonomisk effekt än mötesstrukturen är hur samarbetet med externa leverantörer struktureras.
När du köper timmar ställer du inga krav på din partner. När du har en partner är det partnern som tar ansvaret. Skillnaden låter liten, men den avgör hur ditt utvecklingsprojekt faktiskt landar. En konsult som hyrs per timme kan vara hur ambitiös som helst, men avtalsstrukturen belönar inte kortare ledtid. En partner som betalas på leverans har den drivkraften inbyggd i modellen.
Trenden vi ser är tydlig. Företag går från renodlad konsultuthyrning mot värdebaserade partnerskap, där risk och belöning delas. Från att låsa upp namngivna individer till att avtala om garanterad kapacitet. Från att räkna timmar till att räkna milstolpar.
Innan du skriver på nästa avtal
Om du står inför en upphandling eller ett förnyat samarbete, är det här frågorna vi tycker att du ska ställa dig innan du signerar:
→ Har vi en tydlig bild av vad som är vår kärnverksamhet och vad vi bör ta in extern hjälp med?
→ Är strategin kommunicerad så att beslutsvägarna faktiskt fungerar?
→ Kravställer och följer vi upp externa leveranser lika detaljerat som interna?
→ Konkurrensutsätter vi rätt saker, och är vi tydliga med vad vi vill ha snarare än hur det ska lösas?
→ Har vi förflyttat oss från reaktiv till proaktiv i valet av samarbetspartners?
Sista punkten är viktig. Vi jobbar med kunder som är riktigt bra på att komma till oss och säga: ”Vi behöver lösa de här problemen, men vi har inte svaret. Kan ni titta på det?” Det öppnar för ett helt annat samarbete än att komma med en färdigskriven kravspec.
