Därför misslyckas IT-projekt

Att diskutera projekt med personer från andra branscher än IT-branschen är många gånger upplyftande och nästan alltid intressant. De blir de ofta förvånade när jag beskriver de problem vi dagligen brottas med och hur förtvivlat svårt det är att driva stora mjukvaruprojekt. Skillnaden ligger i de grundläggande olika förutsättningar man har inom vad vi kan kalla hårda och mjuka vetenskaper.
 
Egenskaper Hårda vetenskaper Mjuka vetenskaper
Kännetecknas av... förankring i bevisade fysikaliska lagar outforskade områden som behöver upptäckas
Problem löses genom... planering, definition och beräkning hypotes, experiment, test och revidering av hypotes
Exempel är... att bygga hus, broar och vägar att komponera symfonier, göra film, utveckla mjukvara
 
Det är lätt att inse att det inte går att tillämpa samma projektmetoder på både mjuk och hård vetenskap. Ändå är det så man inledningvis gjorde i IT-erans barndom. I brist på egna metoder sneglade man på etablerade branscher som t.ex. byggbranschen. Så länge ett projekt var tillräckligt litet så fungerade det hyggligt eftersom små projekt bara kan ha relativt små problem. Men när man försökte göra på samma sätt för allt större och mer komplexa projekt stötte man omedelbart på svårigheter. Man hade sprungit in i uppskalningsproblemet - roten till allt ont i IT-branschen!

När jag förklarar svårigheterna med stora IT-projekt för byggingenjörer så skakar de oförstående på huvudet. För en byggingenjör är nämligen inte storleken på projektet ett problem i sig, eftersom samma principer och metoder går att tillämpa oavsett om man avser att bygga en villa, ett flerfamiljshus eller en skyskrapa. För en byggingenjör är det bara en linjär skalförändring; förvisso fler människor, större budget, längre byggtid och fler ingående komponenter, men fundamentalt samma angrepssätt.

Det är i princip möjligt att i detalj beskriva ett helt byggprojekt, innan man har tagit det första spadtaget. Inte nog med det, ju mer tid man lägger ner i början på att rita, räkna och planera innan man börjar gräva, spika och gjuta, desto mindre risk kommer projektet att bära. Man har med andra ord det bra förspänt eftersom man kan luta sig tillbaks på en väl fungerande byggprocess och kan fokusera sin ansträngning på innehållet i stället för metoden. Man kan i stället låta teknik- och materialutveckling vara drivande i att skapa större och mer komplexa byggnationer när inte processen är en begränsande faktor.

Intuitivt kan man tro att man kan uppnå samma fördelar i ett IT-projekt men för mjukvaruutveckling har man bara en negativ utväxling av en initial hög detaljeringsgrad. Om man försöker tillämpa samma modell kommer att man mycket snart köra huvudet i väggen. Tyvärr finns det en utbredd och missriktad övertro att om man bara detaljerar, begränsar och planerar ännu mer så kommer nästa projekt att gå bättre. Resultatet blir dessvärre tvärtom. Mjuka vetenskaper i allmänhet och mjukvaruprojekt i synnerhet kan inte tyglas och styras genom planer och detaljer utan måste tillåtas växa fram genom tillämpning av vetenskaplighet och kreativitet. Det är det enda sättet att utveckla framgångsrik mjukvara. Metoder kommer och metoder går, men i grund och botten måste de vara baserade på den vetenskapliga metoden att formulera hypoteser (krav) och genom upprepade experiment (kod) validera (test) och modifiera hypotesens korrekthet (iterativitet).
 

Om författaren

Mats Wessberg är VD och medgrundare av Inceptive. Han har verkat i IT-branschen sedan 1995 och mestadels som konsult. Hans huvudsakliga expertis är inom Quality Management och utvecklingsmetodik.