har du hört den om det försvinnande lagret? En dag försvann den-inte från fysisk syn, utan från de vaksamma ögonen på en välkänd återförsäljares automatiserade distributionssystem. En programvarufel hade på något sätt raderat lagerets existens, så att varor avsedda för lagret omdirigerades någon annanstans, medan varor på lagret försvann. Eftersom företaget var i ekonomiska problem och hade slutat andra lager för att spara pengar, höll de anställda på det ”saknade” lagret tyst. I tre år kom ingenting eller lämnade. Anställda fick fortfarande sina lönecheckar, dock, eftersom ett annat datorsystem hanterade lönelistan. När programvarufel äntligen kom fram såldes varorna i lagret och den övre ledningen sa till anställda att inte säga något om avsnittet.

denna historia har varit flytande runt IT-branschen i 20-några år. Det är förmodligen apokryf, men för oss i branschen är det helt troligt. Varför? Eftersom episoder som detta händer hela tiden. I oktober förra året var den jätte Brittiska mathandlaren J Sainsbury PLC tvungen att skriva av sin investering på 526 miljoner US-Dollar i ett automatiserat supply chain management system. Det verkar som om varor fastnade i företagets depåer och lager och inte kom igenom många av sina butiker. Sainsbury tvingades anställa cirka 3000 ytterligare kontorister för att lagra sina hyllor manuellt .

Detta är bara en av de senaste i en lång, dyster historia av IT-projekt gått snett . De flesta IT-experter är överens om att sådana misslyckanden inträffar mycket oftare än de borde. Dessutom är misslyckandena universellt fördomsfria: de händer i alla länder; till stora företag och små; i kommersiella, ideella och statliga organisationer; och utan hänsyn till status eller rykte. Affärs—och samhällskostnaderna för dessa misslyckanden—i form av bortkastade skattebetalare och aktieägardollar samt investeringar som inte kan göras-är nu långt in i miljarder dollar per år.

problemet blir bara värre när det blir allestädes närvarande. I år kommer organisationer och regeringar att spendera uppskattningsvis 1 biljon dollar på IT-hårdvara, programvara och tjänster över hela världen. Av de IT-projekt som initieras kommer från 5 till 15 procent att överges före eller strax efter leveransen som hopplöst otillräcklig. Många andra kommer sent och över budget eller kräver massiv omarbetning. Få IT-projekt, med andra ord, lyckas verkligen.

den största tragedin är att programvarufel för det mesta är förutsägbart och undvikbart. Tyvärr ser de flesta organisationer inte att förebygga misslyckande som en brådskande fråga, även om den uppfattningen riskerar att skada organisationen och kanske till och med förstöra den. Att förstå varför denna attityd kvarstår är inte bara en akademisk övning; det har enorma konsekvenser för näringslivet och samhället.

PROGRAMVARA FINNS ÖVERALLT. Det är det som låter oss få pengar från en bankomat, ringa ett telefonsamtal och köra våra bilar. En typisk mobiltelefon innehåller nu 2 miljoner rader programkod; av 2010 kommer det sannolikt att ha 10 gånger så många. General Motors Corp. uppskattar att dess bilar då kommer att ha 100 miljoner kodrader.

det genomsnittliga företaget spenderar cirka 4 till 5 procent av intäkterna på informationsteknologi, med de som är mycket IT—beroende—som finans-och telekommunikationsföretag-spenderar mer än 10 procent på det. Med andra ord är det nu en av de största företagskostnaderna utanför personalkostnaderna. Mycket av pengarna går till hårdvaru-och mjukvaruuppgraderingar, licensavgifter för programvara och så vidare, men en stor del är för nya mjukvaruprojekt som är avsedda att skapa en bättre framtid för organisationen och dess kunder.

regeringar är också stora konsumenter av programvara. 2003 hade Storbritannien mer än 100 stora statliga IT-projekt på gång som uppgick till 20,3 miljarder dollar. År 2004 katalogiserade den amerikanska regeringen 1200 civila IT-projekt som kostade mer än 60 miljarder dollar, plus ytterligare 16 miljarder dollar för militär programvara.

något av dessa projekt kan kosta över 1 miljard dollar. För att ta två aktuella exempel beräknas datormoderniseringsinsatsen vid US Department of Veterans Affairs att köra $3.5 miljarder, medan automatisering av hälsojournalerna för Storbritanniens nationella hälsovård sannolikt kommer att kosta mer än $14.3 miljarder för utveckling och ytterligare $50.8 miljarder för utplacering.

sådana megasoftware-projekt, en gång sällsynta, är nu mycket vanligare, eftersom mindre IT-operationer förenas i ”system av system.”Flygkontroll är ett utmärkt exempel, eftersom det bygger på anslutningar mellan dussintals nätverk som tillhandahåller kommunikation, väder, navigering och annan data. Men integrationstricket har stymied många en IT-utvecklare, till den punkt där akademiska forskare i allt högre grad tror att datavetenskapen själv kan behöva omprövas mot bakgrund av dessa massivt komplexa system.

när ett projekt misslyckas äventyrar det en organisations utsikter. Om felet är tillräckligt stort kan det stjäla företagets hela framtid. I en stellar meltdown ledde ett dåligt implementerat resursplaneringssystem FoxMeyer Drug Co., ett grossistdistributionsföretag på 5 miljarder dollar i Carrollton, Texas, för att sjunka i konkurs 1996.

it-misslyckande i regeringen kan äventyra nationell säkerhet, vilket FBI: s virtuella Fallfilfel har visat. VCF-systemet på 170 miljoner dollar, en sökbar databas som är avsedd att tillåta agenter att ”ansluta prickarna” och följa upp olika bitar av intelligens, slutade istället för fem månader sedan utan att något system användes .

it-misslyckanden kan också hämma ekonomisk tillväxt och livskvalitet. Tillbaka 1981 började US Federal Aviation Administration undersöka uppgraderingen av sitt föråldrade flygtrafikkontrollsystem, men ansträngningen att bygga en ersättare blev snart full av problem . År 1994, när byrån slutligen gav upp projektet, hade den förutsagda kostnaden tredubblats, mer än 2,6 miljarder dollar hade spenderats och det förväntade leveransdatumet hade minskat med flera år. Varje flygpassagerare som är försenad på grund av gridlocked skyways känner fortfarande denna avbokning; den kumulativa ekonomiska effekten av alla dessa förseningar på bara de amerikanska flygbolagen (tänk inte på passagerarna) närmar sig 50 miljarder dollar.

över hela världen är det svårt att säga hur många mjukvaruprojekt som misslyckas eller hur mycket pengar som slösas bort som ett resultat. Om du definierar misslyckande som det totala övergivandet av ett projekt före eller strax efter det levereras, och om du accepterar en konservativ felfrekvens på 5 procent, slösas miljarder dollar varje år på dålig programvara.

till exempel i 2004, USA. regeringen spenderade 60 miljarder dollar på programvara (räknar inte den inbäddade programvaran i vapensystem); en 5-procentig felfrekvens betyder att 3 miljarder dollar förmodligen slösades bort. Men efter flera decennier som IT-konsult är jag övertygad om att felfrekvensen är 15 till 20 procent för projekt som har budgetar på 10 miljoner dollar eller mer. Titta på den totala investeringen i nya mjukvaruprojekt—både regering och företag—under de senaste fem åren, uppskattar jag att projektfel sannolikt har kostat den amerikanska ekonomin minst 25 miljarder dollar och kanske så mycket som 75 miljarder dollar.

naturligtvis återspeglar de 75 miljarder dollar inte projekt som överstiger deras budgetar—vilket de flesta projekt gör. Det speglar inte heller projekt som levereras sent—vilket majoriteten är. Det misslyckas också med att redogöra för möjlighetskostnaderna för att behöva starta om när ett projekt överges eller kostnaderna för bug-ridit system som måste omarbetas upprepade gånger.

då är det också kostnaden för tvister från irate-kunder som stämmer leverantörer för dåligt implementerade system. När du lägger till alla dessa extra kostnader, går den årliga fliken för misslyckad och orolig programvara konservativt någonstans från $ 60 miljarder till $70 miljarder i USA ensam. För de pengarna kan du starta rymdfärjan 100 gånger, bygga och distribuera hela 24-satellits globala positioneringssystem och utveckla Boeing 777 från början—och har fortfarande några miljarder kvar.

varför misslyckas projekt så ofta?

bland de vanligaste faktorerna:

• orealistiska eller oartikulerade projektmål
• felaktiga uppskattningar av nödvändiga resurser
• dåligt definierade systemkrav
• Dålig rapportering av projektets status
• ohanterade risker
• dålig kommunikation mellan kunder, utvecklare och användare
• användning av omogen teknik
• oförmåga att hantera projektets komplexitet
• slarvig Utvecklingspraxis
• dålig Projektledning
• intressentpolitik
• kommersiellt tryck

naturligtvis projekterar det sällan misslyckas av bara en eller två skäl. FBI: s VCF-projekt led av många av problemen ovan. De flesta misslyckanden kan faktiskt spåras till en kombination av teknisk, projektledning och affärsbeslut. Varje dimension interagerar med de andra på komplicerade sätt som förvärrar projektrisker och problem och ökar sannolikheten för misslyckande.

överväga en enkel programvara syssla: ett inköpssystem som automatiserar beställning, fakturering och frakt av delar, så att en säljare kan mata in en kunds beställning, få den automatiskt kontrollerad mot prissättning och kontraktskrav och ordna att få delarna och fakturan skickad till kunden från lagret.

kraven för systemet anger fyra grundläggande steg. Först, det är försäljningsprocessen, vilket skapar en köpeskilling. Den räkningen skickas sedan genom en juridisk process, som granskar avtalsvillkoren för den potentiella försäljningen och godkänner dem. Tredje i raden är bestämmelseprocessen, som skickar ut de delar som avtalats för, följt av finansprocessen, som skickar ut en faktura.

låt oss säga att när den första processen, för försäljning, skrivs, behandlar programmerarna varje order som om den placerades i företagets huvudplats, även om företaget har filialer i flera stater och länder. Det misstaget påverkar i sin tur hur skatt beräknas, vilken typ av kontrakt som utfärdas och så vidare.

ju tidigare utelämnandet upptäcks och korrigeras, desto bättre. Det är som att sticka en tröja. Om du upptäcker en missad söm direkt efter att du har gjort det, kan du helt enkelt riva upp lite garn och gå vidare. Men om du inte fångar misstaget till slutet kan du behöva riva upp hela tröjan bara för att göra om den där sömmen.

om programvarukodarna inte fångar sin utelämnande förrän slutlig systemtestning—eller värre, tills efter att systemet har rullats ut—kommer kostnaderna för att korrigera felet sannolikt att vara många gånger större än om de hade fångat misstaget medan de fortfarande arbetade med den ursprungliga försäljningsprocessen.

och till skillnad från en missad söm i en tröja är detta problem mycket svårare att hitta; programmerarna ser bara att fel visas, och dessa kan ha flera orsaker. Även efter att det ursprungliga felet har korrigerats måste de ändra andra beräkningar och dokumentation och sedan testa varje steg igen.

faktum är att studier har visat att mjukvaruspecialister spenderar cirka 40 till 50 procent av sin tid på undvikbara omarbetningar snarare än på vad de kallar mervärde, vilket i grunden är arbete som görs rätt första gången. När en mjukvara kommer in i fältet kan kostnaden för att fixa ett fel vara 100 gånger så högt som det skulle ha varit under utvecklingsstadiet.

om fel finns i överflöd, kan omarbetningar börja träska ett projekt, som en jolle i en storm. Vad som är värre, försök att åtgärda ett fel introducerar ofta nya. Det är som om du räddar den jollen, men du skapar också läckor. Om alltför många fel produceras, kostnaden och tiden som krävs för att slutföra systemet blir så stor att pågår inte vettigt.

i de enklaste termerna misslyckas ett IT-projekt vanligtvis när omarbetningen överstiger det mervärde som har budgeterats för. Detta är vad som hände med Sydney Water Corp., den största vattenleverantören i Australien, när den försökte införa ett automatiserat kundinformations-och faktureringssystem 2002 . Enligt en undersökning av Australian Auditor General var bland de faktorer som dömde projektet otillräcklig planering och specifikationer, vilket i sin tur ledde till många ändringsförfrågningar och betydande merkostnader och förseningar. Sydney Water avbröt projektet midway, efter att ha spenderat AU $61 miljoner (US $33.2 miljoner).

som alla leder oss till den uppenbara frågan: varför uppstår så många fel?

Programvaruprojektfel har mycket gemensamt med flygplanskrascher. Precis som piloter aldrig tänker krascha, syftar programutvecklare inte till att misslyckas. När ett kommersiellt plan kraschar tittar utredarna på många faktorer, såsom vädret, underhållsregister, pilotens disposition och utbildning och kulturella faktorer inom flygbolaget. På samma sätt måste vi titta på affärsmiljön, Teknisk Förvaltning, projektledning och organisationskultur för att komma till rötterna till programvarufel.

främst bland affärsfaktorerna är konkurrens och behovet av att sänka kostnaderna. Högre chefer förväntar sig alltmer att IT-avdelningar gör mer med mindre och gör det snabbare än tidigare; de ser mjukvaruprojekt inte som investeringar utan som rena kostnader som måste kontrolleras.

politiska krav kan också orsaka kaos på ett IT-projekts schema, kostnad och kvalitet. När Denver International Airport försökte rulla ut sitt automatiserade bagagehanteringssystem höll statliga och lokala politiska ledare projektet till ett orealistiskt schema efter det andra. Misslyckandet med att leverera systemet i tid försenade 1995 års öppning av flygplatsen (då den största i USA), vilket förvärrade de ekonomiska konsekvenserna många gånger.

även efter att systemet var klart fungerade det aldrig tillförlitligt: det tuggade upp bagage och vagnarna brukade transportera bagage runt ofta spårade. Så småningom stämde United Airlines, flygplatsens huvudhyresgäst, systementreprenören, och avsnittet blev ett bevis på farorna med politisk lämplighet.

en brist på övre ledningsstöd kan också fördöma ett IT-företag. Detta går från att misslyckas med att allokera tillräckligt med pengar och arbetskraft till att inte tydligt fastställa IT-projektets förhållande till organisationens verksamhet. År 2000, återförsäljare Kmart Corp., i Troy, mig., lanserade en $1.4 miljarder it-moderniseringsinsatser som syftar till att länka sina försäljnings -, marknadsförings -, leverans-och logistiksystem för att bättre konkurrera med rival Wal-Mart Corp., i Bentonville, Ark. Wal-Mart visade sig dock vara formidabelt, och 18 månader senare minskade Kmart med kontanter på moderniseringen och skrev av de 130 miljoner dollar som den redan hade investerat i den. Fyra månader senare förklarade det konkurs; företaget fortsätter att kämpa idag.

ofta, IT-projektledare ivriga att få finansierade tillgripa en form av lögnare poker, overpromising vad deras projekt kommer att göra, hur mycket det kommer att kosta, och när det kommer att slutföras. Många, om inte de flesta, mjukvaruprojekt börjar med budgetar som är för små. När det händer måste utvecklarna kompensera för bristen på något sätt, vanligtvis genom att försöka öka produktiviteten, minska ansträngningens omfattning eller ta riskabla genvägar i gransknings-och testfaserna. Dessa ökar alla sannolikheten för fel och i slutändan misslyckande.

ett toppmodernt resebokningssystem som leds av ett konsortium av Budget Rent-A-Car, Hilton Hotels, Marriott och AMR, förälder till American Airlines, är ett typexempel. 1992, tre och ett halvt år och 165 miljoner dollar i projektet, övergav gruppen det och citerade två huvudorsaker: ett alltför optimistiskt utvecklingsschema och en underskattning av de tekniska svårigheterna. Det var samma grupp som tidigare hade byggt det enormt framgångsrika Sabre-bokningssystemet, vilket bevisade att tidigare resultat inte är någon garanti för framtida resultat.

efter kraschutredare anser vädret som en faktor i en flygkrasch, de tittar på själva flygplanet. Var det något i flygplanets design som orsakade kraschen? Bär den för mycket vikt?

i IT-projektfel uppstår alltid liknande frågor om projektets tekniska komponenter: hårdvaran och programvaran som används för att utveckla systemet och utvecklingspraxis själva. Organisationer förförs ofta av sirensången av det tekniska imperativet-den okontrollerbara lusten att använda den senaste tekniken i hopp om att få en konkurrensfördel. Med teknik förändras snabbt och lovande fantastiska nya funktioner, är det lätt att ge efter. Men att använda omogen eller otestad teknik är en säker väg till misslyckande.

1997, efter att ha spenderat 40 miljoner dollar, stängde Staten Washington ett IT-projekt som skulle ha behandlat körkort och fordonsregistreringar. Motorfordonstjänstemän medgav att de fastnade i att jaga teknik istället för att koncentrera sig på att implementera ett system som uppfyllde deras krav. IT-debatten som tog ner FoxMeyer-läkemedlet ett år tidigare härrörde också från att anta ett toppmodernt resursplaneringssystem och sedan driva det utöver vad det kunde göra.

ett projekts storlek är en källa till misslyckande. Studier visar att storskaliga projekt misslyckas tre till fem gånger oftare än små. Ju större projektet är, desto mer komplexitet finns det i både dess statiska element (de diskreta delarna av programvara, hårdvara och så vidare) och dess dynamiska element (kopplingar och interaktioner mellan hårdvara, programvara och användare; anslutningar till andra system och så vidare). Större komplexitet ökar risken för fel, eftersom ingen verkligen förstår alla interaktiva delar av helheten eller har förmågan att testa dem.

nykter men sant: det är omöjligt att noggrant testa ett IT-system av någon verklig storlek. Roger S. Pressman påpekade i sin bok Software Engineering, en av de klassiska texterna inom området, att ”uttömmande testning presenterar vissa logistiska problem….Även ett litet 100-linjers program med några kapslade banor och en enda slinga som körs mindre än tjugo gånger kan kräva 10 till kraften på 14 möjliga banor som ska utföras.”För att testa alla dessa 100 biljoner vägar noterade han, förutsatt att var och en kunde utvärderas på ett millisekund, skulle ta 3170 år.

alla IT-system är i sig bräckliga. I en stor tegelbyggnad måste du ta bort hundratals strategiskt placerade tegelstenar för att få en vägg att kollapsa. Men i en 100 000-line programvara, Det tar bara en eller två dåliga linjer för att producera stora problem. 1991, en del av ATandamp;T: s telefonnät gick ut och lämnade 12 miljoner abonnenter utan service, allt på grund av ett enda felaktigt tecken i en kodrad.

slarviga utvecklingsmetoder är en rik källa till misslyckande, och de kan orsaka fel i alla skeden av ett IT-projekt. För att hjälpa organisationer att bedöma sina mjukvaruutvecklingsmetoder, USA. Software Engineering Institute, i Pittsburgh, skapade Capability Maturity Model, eller CMM. Det betygsätter ett företags praxis mot fem nivåer av ökande mognad. Nivå 1 innebär att organisationen använder ad hoc och eventuellt kaotiska utvecklingsmetoder. Nivå 3 innebär att företaget har präglat sin praxis och nu förstår dem. Nivå 5 innebär att organisationen kvantitativt förstår variationerna i de processer och metoder som den tillämpar.

från och med januari hade nästan 2000 statliga och kommersiella organisationer frivilligt rapporterat CMM-nivåer. Över hälften erkände att vara på antingen nivå 1 eller 2, 30 procent var på nivå 3, och endast 17 procent hade nått nivå 4 eller 5. Procentsatserna är ännu mer dystra när du inser att detta är en självvald grupp; uppenbarligen kommer företag med de värsta IT-metoderna inte att utsätta sig för en CMM-utvärdering. (CMM ersätts av CMM-integrationen, som syftar till en bredare bedömning av en organisations förmåga att skapa mjukvaruintensiva system.)

omogna IT-metoder dömde USA. Internal Revenue Service moderniseringsinsatser på 4 miljarder dollar 1997, och de har fortsatt att plåga IRS nuvarande modernisering på 8 miljarder dollar. Det kan bara vara i sig omöjligt att översätta skattekoden till programkod—skattelagstiftningen är komplex och bygger på ofta vag lagstiftning, och den ändras hela tiden. Ur en IT-utvecklares synvinkel är det en kravmardröm. Men IRS har inte hjälpt av öppen fientlighet mellan interna och externa programmerare, en skrattretande underskattning av arbetet och många andra dåliga metoder.

pilotens handlingar strax innan ett flyg kraschar är alltid av stort intresse för utredare. Det beror på att piloten är den ultimata beslutsfattaren, ansvarig för säker drift av farkosten. På samma sätt spelar projektledare en avgörande roll i mjukvaruprojekt och kan vara en viktig källa till fel som leder till misslyckande.

tillbaka 1986 beslutade Londonbörsen att automatisera sitt system för avveckling av aktietransaktioner. Sju år senare, efter att ha spenderat 600 miljoner dollar, skrotade det Taurus-systemets utveckling, inte bara för att designen var alltför komplex och besvärlig utan också för att projektledningen var, att använda ordet från en av sina egna chefer, ”vilseledande.”Som undersökningar avslöjade verkade ingen vilja veta projektets verkliga status, även om fler och fler problem uppstod, tidsfrister missades och kostnaderna ökade.

it-projektledarens viktigaste funktion är att fördela resurser till olika aktiviteter. Utöver det är projektledaren ansvarig för projektplanering och uppskattning, kontroll, organisation, kontraktshantering, kvalitetshantering, riskhantering, kommunikation och personalhantering.

dåliga beslut av projektledare är förmodligen den enskilt största orsaken till programvarufel idag. Dålig teknisk hantering kan däremot leda till tekniska fel, men de kan i allmänhet isoleras och fixas. Men ett dåligt projektledningsbeslut—som att anställa för få programmerare eller välja fel typ av kontrakt-kan orsaka kaos. Till exempel hävdar utvecklarna av det dömda resebokningssystemet att de delvis hobblades med hjälp av ett fastpriskontrakt. Ett sådant kontrakt förutsätter att arbetet kommer att vara rutinmässigt; bokningssystemet visade sig vara allt annat än.

projektledningsbeslut är ofta knepiga just för att de involverar kompromisser baserade på otydlig eller ofullständig kunskap. Att uppskatta hur mycket ett IT-projekt kommer att kosta och hur lång tid det tar är lika mycket konst som vetenskap. Ju större eller mer roman projektet är, desto mindre exakta uppskattningar. Det är ett löpande skämt i branschen att IT-projektets uppskattningar i bästa fall ligger inom 25 procent av deras verkliga värde 75 procent av tiden.

det finns andra sätt att Dålig Projektledning kan påskynda ett programvaruprojekts bortgång. En studie av Project Management Institute, i Newton Square, Pa., visade att riskhantering är den minst praktiserade av alla projektledningsdiscipliner inom alla branscher, och ingenstans tillämpas den mer sällan än i IT-branschen. Utan effektiv riskhantering har mjukvaruutvecklare liten inblick i vad som kan gå fel, varför det kan gå fel och vad som kan göras för att eliminera eller mildra riskerna. Det finns inte heller något sätt att avgöra vilka risker som är acceptabla, vilket i sin tur gör projektbeslut om avvägningar nästan omöjliga.

Dålig Projektledning tar många andra former, inklusive dålig kommunikation, vilket skapar en ogästvänlig atmosfär som ökar omsättningen; inte investerar i personalutbildning och inte granskar projektets framsteg med jämna mellanrum. Någon av dessa kan hjälpa till att spåra ett mjukvaruprojekt.

det sista området som utredarna undersöker efter en flygkrasch är organisationsmiljön. Har flygbolaget en stark säkerhetskultur, eller betonar det framför allt att flygschemat uppfylls? I IT-projekt är en organisation som värderar öppenhet, ärlighet, kommunikation och samarbete mer benägen att hitta och lösa misstag tillräckligt tidigt som omarbetningar inte blir överväldigande.

om det finns ett tema som går igenom den torterade historien om dålig programvara, är det ett misslyckande att konfrontera verkligheten. Vid flera tillfällen berättade det amerikanska justitiedepartementets inspektörsgeneral, en extern expertpanel och andra chefen för FBI att VCF-systemet var omöjligt enligt definitionen, och ändå fortsatte projektet ändå. Samma attityder fanns bland de ansvariga för resebokningssystemet, Londonbörsens Taurus-system och FAA: s flygtrafikkontrollprojekt-allt tyder på organisationskulturer som drivs av rädsla och arrogans.

en ny rapport från National Audit Office i Storbritannien fann att många fall av statliga IT-projekt rekommenderades att inte gå vidare men fortsätta ändå. Storbritannien har till och med en regeringsavdelning som är ansvarig för att förhindra it-misslyckanden, men som rapporten noterade, ignorerar mer än hälften av de byråer som avdelningen övervakar rutinmässigt sina råd. Jag kallar denna typ av beteende irrationell projektupptrappning—oförmågan att stoppa ett projekt även efter det är uppenbart att sannolikheten för framgång snabbt närmar sig noll. Tyvärr är sådant beteende inte på något sätt unikt.

i slutändan tenderar stora programvarufel att likna den värsta tänkbara flygkraschen , där piloten var oerfaren men ytterst utslag, flög in i en isstorm i ett otestat flygplan och arbetade för ett flygbolag som gav läppservice till säkerhet samtidigt som man minskade utbildning och underhåll. Om du läser utredarens rapport efteråt, du skulle skaka på huvudet och frågar, ”Var inte en sådan krasch oundviklig?”

så också orsakerna till att mjukvaruprojekt misslyckas är välkända och har dokumenterats rikligt i otaliga artiklar, rapporter och böcker . Och ändå fortsätter misslyckanden, nära misslyckanden och vanlig gammal dålig programvara att plåga oss, medan metoder som är kända för att avvärja misstag undviks. Det verkar som att få kvalitetsprogramvara i tid och inom budgeten inte är en brådskande prioritet hos de flesta organisationer.

det verkade inte vara på Oxford Health Plans Inc., i Trumbull, Conn., 1997. Företagets automatiserade faktureringssystem var avgörande för dess slutresultat, och ändå högre chefer det var mer intresserade av att utöka Oxfords verksamhet än att se till att dess faktureringssystem kunde möta sina nuvarande behov . Även som problem uppstod, såsom fakturor skickas ut månader sent, Chefer betalat lite uppmärksamhet. När faktureringssystemet effektivt kollapsade förlorade företaget tiotals miljoner dollar och dess lager sjönk från $68 till $26 per aktie på en dag och torkade ut $3.4 miljarder i företagsvärde. Aktieägare väckte rättegångar, och flera myndigheter undersökte företaget, som så småningom fick böter på 3 miljoner dollar för överträdelser av lagstiftningen.

även organisationer som blir brända av dåliga mjukvaruupplevelser verkar oförmögna eller ovilliga att lära av sina misstag. I en rapport från 2000 noterade US Defense Science Board, ett rådgivande organ till försvarsdepartementet, att olika studier som beställts av DOD hade gjort 134 rekommendationer för att förbättra sin mjukvaruutveckling, men endast 21 av dessa rekommendationer hade agerats. De andra 113 var fortfarande giltiga, noterade styrelsen, men ignorerades, även om DOD klagade över den dåliga utvecklingen av försvarsprogramvara!

vissa organisationer bryr sig om programvarukvalitet, vilket erfarenheten från mjukvaruutvecklingsföretaget Praxis High Integrity Systems, i Bath, England, visar. Praxis kräver att kunderna engagerar sig i projektet, inte bara ekonomiskt, utan som aktiva deltagare i IT-systemets skapande. Företaget spenderar också en enorm tid på att förstå och definiera kundens krav, och det utmanar kunderna att förklara vad de vill och varför. Innan en enda kodrad skrivs kommer både kunden och Praxis överens om vad som önskas, vad som är genomförbart och vilka risker som är inblandade, med tanke på tillgängliga resurser.

därefter tillämpar Praxis en rigorös utvecklingsstrategi som begränsar antalet fel. En av de stora fördelarna med denna modell är att den filtrerar bort de många blivande kunderna som inte vill acceptera ansvaret för att formulera sina IT-krav och spendera tid och pengar för att genomföra dem ordentligt.

någon nivå av programfel kommer alltid att vara med oss. Vi behöver faktiskt verkliga misslyckanden – i motsats till undvikbara misstag—för att fortsätta göra tekniska och ekonomiska framsteg. Men för många av de misslyckanden som uppstår idag kan undvikas. Och när vårt samhälle kommer att förlita sig på IT-system som är allt större, mer integrerade och dyrare, kan kostnaden för misslyckande bli katastrofalt hög.

även nu är det möjligt att satsa på var nästa stora programvarufel kommer att inträffa. En av mina ledande kandidater är IT-systemen som kommer att vara resultatet av den amerikanska regeringens amerikanska Hälsoinformationssamhälle, ett offentlig-privat samarbete som syftar till att definiera datastandarder för elektroniska journaler. Tanken är att när standarder har definierats kommer IT-system att byggas för att låta läkare över hela landet komma in i patientjournaler digitalt, vilket ger läkare, sjukhus, försäkringsbolag och andra vårdspecialister omedelbar tillgång till patientens fullständiga medicinska historia. Hälso-och sjukvårdsexperter tror att ett sådant system av system kommer att förbättra patientvården, sänka kostnaderna med uppskattningsvis 78 miljarder dollar per år och minska medicinska fel, vilket sparar tiotusentals liv.

men detta tillvägagångssätt är bara en rördröm om mjukvarupraxis och felfrekvenser förblir som de är idag. Även med de mest optimistiska uppskattningarna kommer det att krävas 10 års ansträngning för att skapa ett elektroniskt journalsystem, 320 miljarder dollar i utvecklingskostnader och 20 miljarder dollar per år i driftskostnader—förutsatt att det inte finns några fel, överskridanden, schemaläggningar, säkerhetsproblem eller luddig programvara. Detta är knappast ett realistiskt scenario, särskilt eftersom de flesta IT-experter anser att det medicinska samfundet är minst datorkunnigt för alla professionella företag.

patienter och skattebetalare kommer i slutändan att betala priset för utvecklingen, eller misslyckandet, av boondoggles så här. Med tanke på dagens IT-praxis är misslyckande en tydlig möjlighet, och det skulle vara en förlust av aldrig tidigare skådad storlek. Men sedan, länder över hela världen överväger eller redan på jobbet på många initiativ av liknande storlek och påverkan—inom luftfart, nationell säkerhet, och militären, bland andra arenor.

liksom el, vatten, transport och andra kritiska delar av vår infrastruktur blir det snabbt inneboende i vår dagliga existens. Om några decennier kommer ett storskaligt it-misslyckande att bli mer än bara ett dyrt besvär: det kommer att riskera vårt sätt att leva. I avsaknad av den typ av branschomfattande förändringar som kommer att mildra programvarufel, hur mycket av vår framtid är vi villiga att spela på dessa enormt kostsamma och komplexa system?

vi vet redan hur man gör programvara bra. Det kan äntligen vara dags att agera på vad vi vet.