Läser ett inlägg om att 7 av 10 IT-projekt helt eller delvis havererar.( http://definitionofdone.blogspot.com/2010/01/it-ar-varldens-mest-misslyckade-bransch.html ) Man funderar i sitt stilla sinne hur det hade fungerat om byggbranschen med samma effektivitet. Hade folk accepterat att bo i halvfärdiga hus där värmen inte fungerar eller där det inte går att reglera värmen i duschen på grund av att utvecklaren inte lyckats konstruera en fungerande kran?
Inom BI och data warehouseing är detta problem ännu större tror jag lite ovetenskapligt. Oräkneliga timmar med utveckling förbrukas till att skapa databaser, rapporter och analytiska applikationer som sedan aldrig används eller som är direkt felaktiga. Problemet är att vi i denna del av IT-branschen ofta rör oss på obruten mark, där det inte är helt självklart vilken väg som är den rätta. Det i sig ställer höga krav på att de som anlitar och de som anlitas för uppdrag av denna sort kan sina saker väl. Frågan är väl om så alltid är fallet.
Molnigt på idg.se?
Ser ingen som helst jämförelse med andra branscher i den där texten. När det gäller byggbranschen så skulle jag lugnt säga att 60% är försenade, över budget och saknar väsentliga funktioner.
Har hört hur många historier som helst där nybyggda hus där det regnar in, i Stockholm är Hammarby sjöstad bara ett exempel.
I byggbranschen är dessutom automatiseringen och uppfinningsrikedomen på oerhört låg nivå.
När det gäller IT-branschen så är problemet att de som beställer inte vet något om systemet de vill ha eller vilka funktioner de vill ha. Det blir inte bättre av att det finns massor av inkompetenta projektledare.
Hej LX96,
vad jag vet står husen i Hammarby upp. Det är mer än man kan säga om många IT-projekt. Ett byggprojekt är otroligt komplicerat, ofta mycket mer komplicerade än IT-projekt. Därför är det intressant att göra jämförelsen. Varför lyckas byggbranschen så mycket bättre? Det finns bland annat en mycket tydlig kontroll av byggen i form av bygglov och annat. Designprocessen är helt annorlunda med tex arkitektarbeten, detaljerade planritningar och mycket annat. Rollfördelningarna är tydliga och reglerade i lag. Har dessa saker något med det hela att göra?
Hls Håkan B
Jämförelsen är bra.
Byggbranschen använder standarder inom virkesdimensioner, regelavstånd, höjder på strömbrytare, fuktspärrar, takbeläggningar, avstånd mellan vattenledningsrör med MYCKET mera.
Frasen ”på grund av att utvecklaren inte lyckats konstruera en fungerande kran” är perfekt: Utvecklarna försöker konstruera kranar istället för att använda sådana som redan finns och är beprövade.
Det som byggbranschen kallar för hemmafixare kallar it-branschen för innovatörer.
Det enklaste sättet att belysa detta är att fundera på hur många sätt det finns att flytta en fil mellan två datorer.
Eller fundera på vad som gick fel med icke-standarden FTP (det enda som är standardiserat med FTP är just namnet, hur protokollet beter sig verkar vara helt upp till den som implementerar).
Jag forskar på knowledge management och IT inom produktutveckling. En stor del av problemen är att det finns relativt svaga drivkrafter för standardisering.
Problemet jag ser hos de företag jag studerat är att leverantörer driver på att sälja in sina grejer (som ju funkar dåligt ihop med konkurrenters grejer) samtidigt som kunderna (IT-ägare och dylikt) vill ha just sina behov tillgodosedda (och där standarder gör att man tappar en del funktionalitet) = två drivkrafter bort från standardisering.
I praktiken väljer man någon med helhetsansvar som också har ett intresse i underhållet av ditt system. Tänk om byggherren underhöll ditt hus efter att du flyttade in och hade dessutom procent på allt material (t.ex. vattenkranar) och även på underhållsarbetet? Om du bara beställer funktionen kontrollerat vattenflöde finns det absolut inga som helst skäl för byggherren att välja en standardiserad anslutning och vattenkran som du (när det är dags att byta) kan köpa annanstans och som dessutom kan installeras av någon annan.
Frågan är bara vilken ände man börjar standardisera? Hos kunderna eller leverantörerna.
Visst finns det poänger med liknelsen; dock tror jag att det stora skälet till att de allra flesta IT-projekten havererar är bristen på kommunikation mellan utvecklare och användare.
Jag skulle vilja göra jämförelsen med hur ett Formel 1-team utvecklar och sätter upp bilen för en tävling – det är en oerhört iterativ process där man ändrar bilen, testkör, får feedback från föraren (och stödsystemen), ändrar igen, testkör igen, osv.
Vad är då skillnaden mellan oss och dem? Jag tror den stora skillnaden bottnar i en oerhört dålig förståelse för ”den andra sidan” – ofta kan utvecklarna väldigt lite om verksamheten, och lika ofta kan användarna väldigt lite om datan och/eller teknologin. Det är först när vi kan överbrygga detta kunskaps- och kompetensgap vi kan skriva kravspecifikationer och genomföra tester som både utvecklare och användare förstår och har nytta av.
Hej Anders, bra kommentar! Ofta har man olika syn på hur lång tid något får ta mellan verksamhet och IT kan jag tycka. Kanske är värt att ha många dialoger kring förväntningar och att man gemensamt kommer fram till hur lång tid en aktivitet får ta. F1-bilen måste ju vara tillräckligt bra när starten går, men den behöver kanske inte vara ”perfekt”.
hls håkan b