Här är en siffra som borde få vilken företagare som helst att tveka innan ett utvecklingskontrakt skrivs på: under mer än tre decennier av Standish Groups CHAOS-forskning har bara omkring 31 % av alla mjukvaruprojekt levererats framgångsrikt. Ungefär hälften blir försenade, över budget eller saknar funktioner. Resterande ~19 % läggs ner helt — pengarna spenderade, ingenting levererat.
Det här handlar inte om startup kontra storföretag, och det är inget 90-talsproblem som vi sedan löst. Det är anmärkningsvärt stabilt. Så den intressanta frågan är inte om mjukvaruprojekt misslyckas — utan varför, för när man tittar på de faktiska orsakerna framträder ett mönster som nästan inte alls handlar om tekniken.
Pengarna försvinner på förutsägbara sätt
McKinsey studerade tillsammans med Oxfords BT Centre for Major Programme Management över 5 400 IT-projekt. Huvudfyndet: i genomsnitt går stora IT-projekt 45 % över budget och 7 % över tid, samtidigt som de levererar 56 % mindre värde än utlovat. Läs den sista delen två gånger. Även projekten som "blir klara" levererar rutinmässigt knappt hälften av det värde de lovade.
Och det blir skarpare: 17 % av stora IT-projekt går så illa att de hotar själva existensen för företaget som driver dem. Det här är inga avrundningsfel. Det är affärsavslutande händelser som började som ett optimistiskt uppstartsmöte.
Det är nästan aldrig ett kodproblem
När projekt obduceras är dödsorsaken sällan "tekniken funkade inte". Det är kommunikation. Project Management Institute fann att bristande kommunikation är den främsta bidragande orsaken till att projekt misslyckas en tredjedel av gångerna, och att mer än hälften av de pengar som riskeras i ett givet projekt kan spåras tillbaka till just bristande kommunikation.
Låt det sjunka in. Den enskilt största faktorn för om din mjukvara blir byggd är inte ramverket, molnleverantören eller hur smarta utvecklarna är. Det är om alla var överens om vad som skulle byggas — och förblev överens när saker förändrades.
Scope creep är bara ett tydlighetsproblem i förklädnad
Den andra pålitliga mördaren är scope creep, och det är värt att vara precis med varför den är så dyr. Ett krav som ändras i vecka ett kostar ungefär en timmes utvecklingstid. Samma ändring i vecka åtta kan kosta tio gånger så mycket, eftersom allt som byggts ovanpå det gamla antagandet måste nystas upp.
Men scope creep beror sällan på illvilja eller obeslutsamhet. Det är nästan alltid symptomet på ett tidigare misslyckande: kraven var aldrig tillräckligt tydliga från början. Dåligt definierade mål rankas genomgående bland de främsta orsakerna till misslyckande — när ingen tydligt kan säga hur "klart" ser ut, glider målet, och varje glidning förstärks.
De goda nyheterna gömda i datan
Här kommer det genuint uppmuntrande. Oklara krav, scope creep, bristande kommunikation, ingen tydlig ägare — inget av detta är svåra tekniska problem. Det är processproblem, och processproblem går att lösa. Du behöver ingen genialisk algoritm för att undvika dem. Du behöver tydlighet, täta ärliga avstämningar och någon som äger resultatet.
Det är ingen slump att vi arbetar som vi gör på True Dev — det är hela designen. Vi levererar fungerande mjukvara varje vecka, så att du ser den riktiga saken i stället för en statusrapport, och varje avvikelse fångas till vecka-ett-kostnad i stället för vecka-åtta-kostnad. Vi låser scope innan vi börjar, så att "klart" definieras dag ett — inte förhandlas under press senare. Och du pratar direkt med dem som bygger — ingen projektledare som viskar en visklek mellan dig och koden.
Inget av detta är exotiskt. Det är helt enkelt byggt för att ta bort exakt de felmoder som datan ständigt pekar på. Om du har sett ett projekt glida förut och vill att nästa ska bete sig annorlunda är det ett samtal värt att ta — berätta vad du bygger, eller titta på hur vi arbetar.
De flesta mjukvaror misslyckas inte för att de är svåra att bygga. De misslyckas för att ingen höll bilden tydlig. Just den delen ligger åtminstone helt inom din kontroll.
