har du hørt den om det forsvindende lager? En dag forsvandt det—ikke fra fysisk synspunkt, men fra de opmærksomme øjne på en velkendt forhandlers automatiserede distributionssystem. En programmelfejl havde på en eller anden måde slettet lagerbygningens eksistens, så varer bestemt til lageret blev omdirigeret andetsteds, mens varer på lageret forsvandt. Fordi virksomheden var i økonomiske problemer og havde forskudt andre lagre for at spare penge, holdt medarbejderne på det “manglende” lager stille. I tre år ankom eller forlod intet. Medarbejderne fik dog stadig deres lønsedler, fordi et andet computersystem håndterede lønningslisten. Da programmelfejlen endelig kom frem, blev varerne på lageret solgt, og den øverste ledelse bad medarbejderne om ikke at sige noget om episoden.
denne historie har svævet rundt i informationsteknologibranchen i 20-nogle år. Det er nok apokryf, men for dem af os i branchen er det helt plausibelt. Hvorfor? Fordi episoder som dette sker hele tiden. I oktober sidste år måtte den gigantiske Britiske fødevareforhandler J Sainsbury PLC for eksempel afskrive sin investering på 526 millioner dollars i et automatiseret supply chain management system. Det ser ud til, at merchandise sad fast i virksomhedens depoter og lagre og ikke kom igennem til mange af sine butikker. Sainsbury blev tvunget til at ansætte omkring 3000 ekstra kontorister til at lagre hylderne manuelt .
dette er kun en af de seneste i en lang, dystre historie af IT-projekter gået galt . De fleste IT-eksperter er enige om, at sådanne fejl forekommer langt oftere, end de burde. Hvad mere er, fejlene er universelt fordomsfri: de sker i alle lande; til store virksomheder og små; i kommercielle, nonprofit, og statslige organisationer; og uden hensyntagen til status eller omdømme. De forretningsmæssige og samfundsmæssige omkostninger ved disse fiaskoer—i form af spildte skatteydere og aktionær dollars samt investeringer, der ikke kan foretages—er nu godt ind i milliarder af dollars om året.
problemet bliver kun værre, da det vokser allestedsnærværende. I år vil organisationer og regeringer bruge en anslået $ 1 billioner på IT-udstyr, programmel og tjenester over hele verden. Af de IT-projekter, der igangsættes, vil fra 5 til 15 procent blive opgivet før eller kort efter levering som håbløst utilstrækkelig. Mange andre ankommer sent og over budgettet eller kræver massiv omarbejdning. Få IT-projekter, med andre ord, lykkes virkelig.
den største tragedie er, at programfejl for det meste er forudsigelig og undgåelig. Desværre ser de fleste organisationer ikke forebyggelse af fiasko som et presserende spørgsmål, selvom denne opfattelse risikerer at skade organisationen og måske endda ødelægge den. At forstå, hvorfor denne holdning vedvarer, er ikke kun en akademisk øvelse; Det har enorme konsekvenser for erhvervslivet og samfundet.
PROGRAMMER ER OVERALT. Det er det, der lader os få kontanter fra en pengeautomat, foretage et telefonopkald og køre vores biler. En typisk mobiltelefon indeholder nu 2 millioner linjer programkode; i 2010 vil det sandsynligvis have 10 gange så mange. General Motors Corp. estimerer, at dets biler på det tidspunkt hver vil have 100 millioner kodelinjer.
den gennemsnitlige virksomhed bruger omkring 4 til 5 procent af omsætningen på informationsteknologi, med dem, der er stærkt it—afhængige—såsom finansielle og teleselskaber-bruger mere end 10 procent på it. Med andre ord er det nu en af de største virksomhedsudgifter uden for medarbejderomkostninger. Mange af disse penge går til maskinopgraderinger, licensafgifter og så videre, men en stor del er til nye programmelprojekter, der skal skabe en bedre fremtid for organisationen og dens kunder.
regeringer er også store forbrugere af programmel. I 2003 havde Det Forenede Kongerige mere end 100 store offentlige IT-projekter i gang, der udgjorde 20,3 milliarder dollars. I 2004 katalogiserede den amerikanske regering 1200 civile IT-projekter, der kostede mere end 60 milliarder dollars plus yderligere 16 milliarder dollars til militærprogram.
ethvert af disse projekter kan koste over 1 milliard dollars. For at tage to aktuelle eksempler forventes computermoderniseringsindsatsen ved US Department of Veterans Affairs at løbe 3,5 milliarder dollars, mens automatisering af sundhedsjournalerne for Storbritanniens National Health Service sandsynligvis vil koste mere end 14,3 milliarder dollars til udvikling og yderligere 50,8 milliarder dollars til implementering.
sådanne megasoftvareprojekter, der engang var sjældne, er nu meget mere almindelige, da mindre IT-operationer er forbundet med “systems of systems.”Flyvekontrol er et godt eksempel, fordi den er afhængig af forbindelser mellem snesevis af netværk, der leverer kommunikation, vejr, navigation og andre data. Men integrationstricket har forhindret mange IT-udviklere, til det punkt, hvor akademiske forskere i stigende grad tror, at datalogi i sig selv muligvis skal genovervejes i lyset af disse massivt komplekse systemer.
når et projekt mislykkes , bringer det en organisations udsigter i fare. Hvis fejlen er stor nok, kan den stjæle virksomhedens hele fremtid. I en stjernernes nedsmeltning førte et dårligt implementeret ressourceplanlægningssystem Rævmeyer Drug Co. et engrosdistributionsselskab på 5 milliarder dollars i Carrollton, der styrtede ned i konkurs i 1996.
IT-svigt i regeringen kan bringe national sikkerhed i fare, som FBIs virtuelle sagsmappe-debakel har vist. VCF-systemet på 170 millioner dollars, en søgbar database, der er beregnet til at give agenter mulighed for at “forbinde prikkerne” og følge op på forskellige intelligensstykker, sluttede i stedet for fem måneder siden uden at noget system blev implementeret .
IT-fiaskoer kan også hæmme økonomisk vækst og livskvalitet. Tilbage i 1981 begyndte US Federal Aviation Administration at undersøge at opgradere sit forældede lufttrafikstyringssystem, men bestræbelserne på at opbygge en erstatning blev hurtigt fyldt med problemer . I 1994, da agenturet endelig opgav projektet, var de forventede omkostninger tredoblet, mere end 2, 6 milliarder dollars var brugt, og den forventede leveringsdato var faldet med flere år. Hver flypassager, der er forsinket på grund af gitterlåste himmelveje, føler stadig denne aflysning; den kumulative økonomiske virkning af alle disse forsinkelser på kun de amerikanske flyselskaber (husk passagererne) nærmer sig 50 milliarder dollars.
på verdensplan er det svært at sige, hvor mange programmelprojekter der fejler, eller hvor mange penge der spildes som følge heraf. Hvis du definerer fiasko som den totale nedlæggelse af et projekt før eller kort efter det er leveret, og hvis du accepterer en konservativ fejlrate på 5 procent, spildes milliarder af dollars hvert år på dårligt program.
for eksempel, i 2004, USA. regeringen brugte 60 milliarder dollars på programmel (ikke medregnet det indlejrede programmel i våbensystemer); en fejlrate på 5 procent betyder, at 3 milliarder dollars sandsynligvis blev spildt. Efter flere årtier som IT-konsulent er jeg imidlertid overbevist om, at fejlfrekvensen er 15 til 20 procent for projekter, der har budgetter på $10 millioner eller mere. Når man ser på den samlede investering i nye programmelprojekter—både regeringen og erhvervslivet—i løbet af de sidste fem år, vurderer jeg, at projektfejl sandsynligvis har kostet den amerikanske økonomi mindst $25 milliarder og måske så meget som $75 milliarder.
selvfølgelig afspejler de 75 milliarder dollars ikke projekter, der overstiger deres budgetter—hvilket de fleste projekter gør. Det afspejler heller ikke projekter, der leveres sent-som flertallet er. Det tager heller ikke højde for mulighedsomkostningerne ved at skulle starte forfra, når et projekt er opgivet, eller omkostningerne ved fejlstyrede systemer, der gentagne gange skal omarbejdes.
så er der også omkostningerne ved retssager fra vrede kunder, der sagsøger leverandører for dårligt implementerede systemer. Når du tilføjer alle disse ekstra omkostninger, løber den årlige fane for mislykkede og urolige programmer konservativt et sted fra $60 milliarder til $70 milliarder i USA alene. For de penge kan du starte rumfærgen 100 gange, Bygge og implementere hele 24-satellit Global Positioning System og udvikle Boeing 777 fra bunden—og stadig have et par milliarder tilbage.
hvorfor fejler projekter så ofte?
blandt de mest almindelige faktorer:
- urealistiske eller uartikulerede projektmål
- unøjagtige skøn over nødvendige ressourcer
- dårligt definerede systemkrav
- dårlig rapportering af projektets status
- ikke-administrerede risici
- dårlig kommunikation mellem kunder, udviklere og brugere
- brug af umoden teknologi
- manglende evne til at håndtere projektets kompleksitet
- sjusket udviklingspraksis
- dårlig Projektledelse
- interessentpolitik
- kommercielt pres
selvfølgelig projicerer det sjældent mislykkes af kun en eller to grunde. FBIs VCF-projekt led af mange af de ovennævnte problemer. De fleste fejl kan faktisk spores til en kombination af teknisk, projektledelse og forretningsbeslutninger. Hver dimension interagerer med de andre på komplicerede måder, der forværrer projektrisici og problemer og øger sandsynligheden for fiasko.
overvej et simpelt program opgave: et indkøbssystem, der automatiserer bestilling, fakturering og forsendelse af dele, så en sælger kan indtaste en kundes ordre, få den automatisk kontrolleret mod pris-og kontraktkrav og sørge for at få dele og faktura sendt til kunden fra lageret.
kravene til systemet angiver fire grundlæggende trin. For det første er der salgsprocessen, som skaber en salgsregning. Denne regning sendes derefter gennem en juridisk proces, der gennemgår kontraktvilkårene og betingelserne for det potentielle salg og godkender dem. For det tredje er leveringsprocessen, der sender de dele, der er indgået kontrakt om, efterfulgt af finansieringsprocessen, der sender en faktura.
lad os sige, at som den første proces, for salg, bliver skrevet, behandler programmørerne hver ordre som om den var placeret i virksomhedens hovedplacering, selvom virksomheden har filialer i flere stater og lande. Denne fejl påvirker igen, hvordan skat beregnes, hvilken type kontrakt der udstedes osv.
jo før udeladelsen registreres og korrigeres, jo bedre. Det er lidt som at strikke en trøje. Hvis du ser en savnet søm lige efter du har lavet den, kan du bare løsne lidt garn og gå videre. Men hvis du ikke fanger fejlen indtil slutningen, skal du muligvis løsne hele trøjen bare for at gentage den ene søm.
hvis programmelkoderne ikke fanger deres udeladelse, før den endelige systemtest—eller værre, før systemet er rullet ud—vil omkostningerne til at rette fejlen sandsynligvis være mange gange større, end hvis de havde fanget fejlen, mens de stadig arbejdede på den indledende salgsproces.
og i modsætning til en savnet søm i en trøje er dette problem meget sværere at finde ud af; programmørerne vil kun se, at der opstår fejl, og disse kan have flere årsager. Selv efter at den oprindelige fejl er rettet, skal de ændre andre beregninger og dokumentation og derefter teste hvert trin igen.
faktisk har undersøgelser vist, at programmelspecialister bruger omkring 40 til 50 procent af deres tid på undgåelig omarbejdning snarere end på det, de kalder værditilvækst arbejde, hvilket dybest set er arbejde, der er gjort rigtigt første gang. Når et stykke program kommer ind i feltet, kan omkostningerne ved at rette en fejl være 100 gange så høje som det ville have været i udviklingsfasen.
hvis fejl bugner, kan omarbejdning begynde at sump et projekt, som en jolle i en storm. Hvad er værre, forsøg på at rette en fejl introducerer ofte nye. Det er som om du redder den jolle, men du skaber også lækager. Hvis der produceres for mange fejl, bliver omkostningerne og tiden, der er nødvendig for at fuldføre systemet, så store, at det ikke giver mening.
i de enkleste termer mislykkes et IT-projekt normalt, når omarbejdet overstiger det merværdiarbejde, der er budgetteret til. Dette er, hvad der skete med Sydney vand Corp., den største vandudbyder i Australien, da det forsøgte at indføre et automatiseret kundeinformations-og faktureringssystem i 2002 . Ifølge en undersøgelse foretaget af den australske rigsrevisor var blandt de faktorer, der dømte projektet, utilstrækkelig planlægning og specifikationer, hvilket igen førte til adskillige ændringsanmodninger og betydelige ekstra omkostninger og forsinkelser. Sydney vand afbrød projektet midtvejs efter at have brugt AU $61 millioner (US $33,2 millioner).
alt dette fører os til det åbenlyse spørgsmål: Hvorfor opstår der så mange fejl?
projektfejl har meget til fælles med flyulykker. Ligesom piloter aldrig har til hensigt at gå ned, har programmeludviklere ikke til formål at mislykkes. Når et kommercielt fly styrter ned, ser efterforskerne på mange faktorer, såsom vejret, vedligeholdelsesregistre, pilotens disposition og træning og kulturelle faktorer inden for flyselskabet. På samme måde er vi nødt til at se på erhvervsklimaet, teknisk ledelse, projektledelse og organisationskultur for at komme til rødderne af programfejl.
Chief blandt de forretningsmæssige faktorer er konkurrence og behovet for at reducere omkostningerne. I stigende grad forventer seniorledere, at it-afdelinger gør mere med mindre og gør det hurtigere end før; de ser programmelprojekter ikke som investeringer, men som rene omkostninger, der skal kontrolleres.
politiske krav kan også skabe kaos på et IT-projekts tidsplan, omkostninger og kvalitet. Da Denver International Airport forsøgte at udrulle sit automatiserede bagagehåndteringssystem, holdt statslige og lokale politiske ledere projektet til den ene urealistiske tidsplan efter den anden. Manglen på at levere systemet til tiden forsinkede åbningen af lufthavnen i 1995 (dengang den største i USA), hvilket forværrede den økonomiske virkning mange gange.
selv efter at systemet var afsluttet, fungerede det aldrig pålideligt: det tyggede bagage op, og vognene, der blev brugt til at transportere bagage rundt, afsporede ofte. Til sidst sagsøgte United Airlines, lufthavnens hovedlejer, systementreprenøren, og episoden blev et bevis på farerne ved politisk hensigtsmæssighed.
mangel på øverste ledelsesstøtte kan også forbande en IT-virksomhed. Dette kører farveskalaen fra ikke at afsætte nok penge og arbejdskraft til ikke klart at etablere IT-projektets forhold til organisationens forretning. I 2000, detailhandler Kmart Corp., i Troy, Mich., lanceret en $1.4 milliarder it-moderniseringsindsats med det formål at forbinde sine salgs -, marketing -, forsynings-og logistiksystemer for bedre at konkurrere med rivaliserende Val-Mart Corp., i Bentonville, Ark. Val-Mart viste sig dog for formidabel, og 18 måneder senere skar Kmart ned på moderniseringen og afskrev de 130 millioner dollars, den allerede havde investeret i den. Fire måneder senere erklærede Det konkurs; virksomheden fortsætter med at kæmpe i dag.
ofte, it-projektledere ivrige efter at få finansieret ty til en form for liar ‘ s poker, overpromising hvad deres projekt vil gøre, hvor meget det vil koste, og når det vil blive afsluttet. Mange, hvis ikke de fleste, programmer starter med budgetter, der er for små. Når det sker, skal udviklerne på en eller anden måde kompensere for underskuddet, typisk ved at forsøge at øge produktiviteten, reducere omfanget af indsatsen eller tage risikable genveje i gennemgangs-og testfaserne. Disse øger alle sandsynligheden for fejl og i sidste ende fiasko.
et avanceret rejsereservationssystem ledet af et konsortium af Budget Rent-A-Car, Hilton Hotels, Marriott og AMR, forælder til American Airlines, er et eksempel. I 1992, tre og et halvt år og 165 millioner dollars i projektet, opgav gruppen det med henvisning til to hovedårsager: en alt for optimistisk udviklingsplan og en undervurdering af de involverede tekniske vanskeligheder. Dette var den samme gruppe, der tidligere havde bygget det enormt succesrige Sabre-reservationssystem, hvilket beviser, at tidligere præstationer ikke er nogen garanti for fremtidige resultater.
efter styrtundersøgere betragter vejret som en faktor i et flystyrt, ser de på selve flyet. Var der noget i flyets design, der forårsagede styrtet? Var det bærer for meget vægt?
i IT-projektfejl opstår der altid lignende spørgsmål vedrørende projektets tekniske komponenter: det udstyr og programmel, der bruges til at udvikle systemet, og selve udviklingspraksis. Organisationer forføres ofte af sirenesangen fra det teknologiske imperativ – den ukontrollerbare trang til at bruge den nyeste teknologi i håb om at få en konkurrencefordel. Med teknologi, der ændrer sig hurtigt og lovende fantastiske nye muligheder, er det let at bukke under. Men at bruge umoden eller uprøvet teknologi er en sikker vej til fiasko.
i 1997, efter at have brugt 40 millioner dollars, lukkede staten et IT-projekt, der ville have behandlet kørekort og køretøjsregistreringer. Motorkøretøjsembedsmænd indrømmede, at de blev fanget i at jagte teknologi i stedet for at koncentrere sig om at implementere et system, der opfyldte deres krav. IT-debaklen, der bragte Rævmeyer-stoffet ned et år tidligere, stammede også fra at vedtage et avanceret ressourceplanlægningssystem og derefter skubbe det ud over, hvad det kunne gøre.
et projekts store størrelse er en fountainhead of failure. Undersøgelser viser, at store projekter fejler tre til fem gange oftere end små. Jo større projektet er, jo mere kompleksitet er der i både dets statiske elementer (de diskrete dele af programmer, udstyr osv.) og dets dynamiske elementer (koblinger og interaktioner mellem udstyr, programmer og brugere; forbindelser til andre systemer osv.). Større kompleksitet øger muligheden for fejl, fordi ingen virkelig forstår alle de interagerende dele af helheden eller har evnen til at teste dem.
nøgternt men sandt: det er umuligt at grundigt teste et IT-system af nogen reel størrelse. Roger S. Pressman påpegede i sin bog Programmelteknik, en af de klassiske tekster på området, at “udtømmende test giver visse logistiske problemer….Selv et lille 100-linjeprogram med nogle indlejrede stier og en enkelt sløjfe, der udfører mindre end tyve gange, kan kræve 10 til kraften af 14 mulige stier, der skal udføres.”For at teste alle disse 100 billioner stier bemærkede han, at forudsat at hver kunne evalueres i et millisekund, ville det tage 3170 år.
alle IT-systemer er iboende skrøbelige. I en stor murstensbygning skal du fjerne hundredvis af strategisk placerede mursten for at få en mur til at kollapse. Men i et program på 100 000 linjer tager det kun en eller to dårlige linjer at producere store problemer. I 1991 gik en del af atandamp;T ‘ s telefonnetværk ud og efterlod 12 millioner abonnenter uden service, alt sammen på grund af et enkelt forkert indtastet tegn i en kodelinje.
sjusket udviklingspraksis er en rig kilde til fiasko, og de kan forårsage fejl på ethvert trin i et IT-projekt. For at hjælpe organisationer med at vurdere deres programmeludviklingspraksis, USA. I Pittsburgh oprettede man Capability Maturity Model eller CMM. Det vurderer en virksomheds praksis mod fem niveauer af stigende modenhed. Niveau 1 betyder, at organisationen bruger ad hoc og muligvis kaotisk udviklingspraksis. Niveau 3 betyder, at virksomheden har karakteriseret sin praksis og nu forstår dem. Niveau 5 betyder, at organisationen kvantitativt forstår variationerne i de processer og praksis, den anvender.
fra januar havde næsten 2000 offentlige og kommercielle organisationer frivilligt rapporteret CMM-niveauer. Over halvdelen erkendte at være på enten niveau 1 eller 2, 30 procent var på niveau 3, og kun 17 procent havde nået niveau 4 eller 5. Procenterne er endnu mere dystre, når du indser, at dette er en selvvalgt gruppe; selvfølgelig vil virksomheder med den værste IT-praksis ikke underkaste sig en CMM-evaluering. CMM bliver afløst af CMM-integrationen, der sigter mod en bredere vurdering af en organisations evne til at skabe programmelintensive systemer.)
umoden it-praksis dømte USA. Internal Revenue Service ‘s moderniseringsindsats på 4 milliarder dollars i 1997, og de har fortsat plaget IRS’ nuværende modernisering på 8 milliarder dollars. Skattelovgivningen er kompleks og baseret på ofte vag lovgivning, og den ændrer sig hele tiden. Fra en IT-udviklers synspunkt er det et krav mareridt. Men IRS er ikke blevet hjulpet af åben fjendtlighed mellem interne og eksterne programmører, en latterlig undervurdering af det involverede arbejde og mange andre dårlige praksis.
pilotens handlinger lige før et flystyrt er altid af stor interesse for efterforskere. Det skyldes, at piloten er den ultimative beslutningstager, der er ansvarlig for sikker drift af fartøjet. På samme måde spiller projektledere en afgørende rolle i programmelprojekter og kan være en vigtig kilde til fejl, der fører til fiasko.
tilbage i 1986 besluttede Londons børs at automatisere sit system til afvikling af aktietransaktioner. Syv år senere, efter at have brugt 600 millioner dollars, skrottede det Taurus-systemets udvikling, ikke kun fordi designet var for komplekst og besværligt, men også fordi ledelsen af projektet var at bruge ordet fra en af sine egne seniorledere, “vildfarende.”Som undersøgelser afslørede, syntes ingen at ville vide projektets sande status, selv da flere og flere problemer dukkede op, deadlines blev savnet, og omkostningerne steg .
it-projektlederens vigtigste funktion er at allokere ressourcer til forskellige aktiviteter. Derudover er projektlederen ansvarlig for projektplanlægning og estimering, kontrol, organisation, kontraktstyring, kvalitetsstyring, risikostyring, kommunikation og human resource management.
dårlige beslutninger fra projektledere er sandsynligvis den største enkeltstående årsag til programfejl i dag. Dårlig teknisk styring kan derimod føre til tekniske fejl, men de kan generelt isoleres og rettes. Imidlertid kan en dårlig projektstyringsbeslutning—såsom at ansætte for få programmører eller vælge den forkerte type kontrakt—skabe kaos. For eksempel hævder udviklerne af det dømte rejsereservationssystem, at de delvist blev hobbled ved brug af en fastpriskontrakt. En sådan kontrakt forudsætter, at arbejdet vil være rutinemæssigt; reservationssystemet viste sig at være alt andet end.
Projektledelsesbeslutninger er ofte vanskelige netop fordi de involverer kompromiser baseret på uklar eller ufuldstændig viden. At estimere, hvor meget et IT-projekt vil koste, og hvor lang tid det vil tage, er lige så meget kunst som videnskab. Jo større eller mere roman projektet er, jo mindre nøjagtige estimaterne. Det er en løbende vittighed i branchen, at it-projektestimater i bedste fald er inden for 25 procent af deres sande værdi 75 procent af tiden.
der er andre måder, hvorpå dårlig projektstyring kan fremskynde et programprojekts død. En undersøgelse foretaget af Project Management Institute,Pa., viste, at risikostyring er den mindst praktiserede af alle projektledelsesdiscipliner på tværs af alle industrisektorer, og ingen steder anvendes den sjældnere end i IT-branchen. Uden effektiv risikostyring har udviklere kun lidt indsigt i, hvad der kan gå galt, hvorfor det kan gå galt, og hvad der kan gøres for at eliminere eller afbøde risiciene. Der er heller ikke en måde at bestemme, hvilke risici der er acceptable, hvilket igen gør projektbeslutninger vedrørende afvejninger næsten umulige.
dårlig Projektledelse tager mange andre former, herunder dårlig kommunikation, hvilket skaber en ugæstfri atmosfære, der øger omsætningen; ikke investere i personaleuddannelse; og ikke gennemgå projektets fremskridt med jævne mellemrum. Enhver af disse kan hjælpe afspore et program projekt.
det sidste område, som efterforskere ser på efter et flystyrt, er det organisatoriske miljø. Har flyselskabet en stærk sikkerhedskultur, eller lægger det vægt på at overholde flyveplanen frem for alt? I IT-projekter er en organisation, der værdsætter åbenhed, ærlighed, kommunikation og samarbejde, mere tilbøjelig til at finde og løse fejl tidligt nok til, at omarbejdning ikke bliver overvældende.
hvis der er et tema, der løber gennem dårlige programmers torturerede historie, er det en fiasko at konfrontere virkeligheden. Ved adskillige lejligheder fortalte det amerikanske justitsministeriums Inspektørgeneral, et eksternt ekspertpanel og andre lederen af FBI, at VCF-systemet var umuligt som defineret, og alligevel fortsatte projektet alligevel. De samme holdninger eksisterede blandt dem, der var ansvarlige for rejsereservationssystemet, Londons børs Taurus-system og FAA ‘ s lufttrafikstyringsprojekt-alt sammen tegn på organisatoriske kulturer drevet af frygt og arrogance.
en nylig rapport fra National Audit Office i Storbritannien fandt talrige tilfælde af regeringens it-projekter anbefales ikke at gå videre endnu fortsætter alligevel. Det Forenede Kongerige har endda en regeringsafdeling, der har til opgave at forhindre it-fiaskoer, men som rapporten bemærkede, ignorerer mere end halvdelen af de agenturer, afdelingen fører tilsyn med, rutinemæssigt dets råd. Jeg kalder denne type adfærd irrationel projektoptrapning—manglende evne til at stoppe et projekt, selv efter at det er indlysende, at sandsynligheden for succes hurtigt nærmer sig nul. Desværre er en sådan adfærd på ingen måde unik.
i sidste ende har store programmelfejl tendens til at ligne det værste tænkelige flyulykke , hvor piloten var uerfaren, men meget udslæt, fløj ind i en isstorm i et uprøvet fly og arbejdede for et flyselskab, der gav læbe service til sikkerhed, mens han skar ned på træning og vedligeholdelse. Hvis du læser efterforskerens rapport bagefter, du ryster på hovedet og spørger, “var ikke sådan et nedbrud uundgåeligt?”
så også årsagerne til, at programmelprojekter mislykkes, er velkendte og er blevet rigeligt dokumenteret i utallige artikler, rapporter og bøger . Og alligevel fortsætter fiaskoer, næsten fiaskoer og almindelige gamle dårlige programmer med at plage os, Mens praksis, der vides at afværge fejl, undgås. Det ser ud til, at det ikke er en presserende prioritet hos de fleste organisationer at få kvalitetsprogrammer til tiden og inden for budgettet.
det så ikke ud til at være hos
selv organisationer, der bliver brændt af dårlige programoplevelser, synes ude af stand til eller uvillige til at lære af deres fejl. I en rapport fra 2000 bemærkede U. S. Defense Science Board, et rådgivende organ for Forsvarsministeriet, at forskellige undersøgelser bestilt af DOD havde fremsat 134 anbefalinger til forbedring af dets programudvikling, men kun 21 af disse anbefalinger var blevet fulgt. De andre 113 var stadig gyldige, bemærkede bestyrelsen, men blev ignoreret, selv da DOD klagede over den dårlige forsvarsprogramudvikling!
nogle organisationer bekymrer sig om programmelkvalitet, som erfaringerne fra Programudviklingsfirmaet Pracis High Integrity Systems i Bath, England, viser. Praksis kræver, at dets kunder engagerer sig i projektet, ikke kun økonomisk, men som aktive deltagere i IT-systemets oprettelse. Virksomheden bruger også en enorm mængde tid på at forstå og definere kundens krav, og det udfordrer kunderne til at forklare, hvad de vil have, og hvorfor. Før en enkelt kodelinje skrives, er både kunden og praksis enige om, hvad der ønskes, hvad der er muligt, og hvilke risici der er involveret i betragtning af de tilgængelige ressourcer.
derefter anvender praksis en streng udviklingsmetode, der begrænser antallet af fejl. En af de store fordele ved denne model er, at den filtrerer de mange potentielle kunder, der ikke er villige til at acceptere ansvaret for at formulere deres IT-krav og bruge tid og penge på at implementere dem korrekt.
et vist niveau af programfejl vil altid være hos os. Vi har faktisk brug for ægte fiaskoer – i modsætning til undgåelige tabber—for fortsat at gøre tekniske og økonomiske fremskridt. Men for mange af de fejl, der opstår i dag, kan undgås. Og når vores samfund kommer til at stole på IT-systemer, der bliver stadig større, mere integrerede og dyrere, kan omkostningerne ved fiasko blive katastrofalt høje.
selv nu er det muligt at satse på, hvor den næste store programdebakel vil forekomme. En af mine førende kandidater er de IT-systemer, der vil være resultatet af den amerikanske regerings American Health Information Community, et offentligt-privat samarbejde, der søger at definere datastandarder for elektroniske medicinske poster. Ideen er, at når standarder er defineret, vil IT-systemer blive bygget for at lade læger over hele landet indtaste patientjournaler digitalt, hvilket giver læger, hospitaler, forsikringsselskaber og andre sundhedsspecialister øjeblikkelig adgang til en patients komplette medicinske historie. Sundhedseksperter mener, at et sådant system af systemer vil forbedre patientplejen, reducere omkostningerne med anslået 78 milliarder dollars om året og reducere medicinske fejl, hvilket sparer titusinder af liv.
men denne tilgang er en ren drøm, hvis programmelpraksis og fejlfrekvenser forbliver som de er i dag. Selv efter de mest optimistiske skøn vil det kræve 10 års indsats at oprette et elektronisk medicinsk journalsystem, 320 milliarder dollars i udviklingsomkostninger og 20 milliarder dollars om året i driftsomkostninger—forudsat at der ikke er fejl, overskridelser, tidsplan, sikkerhedsproblemer eller sjusket program. Dette er næppe et realistisk scenario, især fordi de fleste IT-eksperter anser det medicinske samfund for at være den mindst computerkyndige af alle professionelle virksomheder.
patienter og skatteydere vil i sidste ende betale prisen for udviklingen eller fiaskoen af boondoggles som denne. I betragtning af nutidens IT-praksis er fiasko en tydelig mulighed, og det ville være et tab af hidtil uset størrelse. Men så overvejer lande over hele verden eller arbejder allerede på mange initiativer af samme størrelse og indflydelse—blandt andet inden for luftfart, national sikkerhed og militæret.
ligesom elektricitet, vand, transport og andre kritiske dele af vores infrastruktur bliver det hurtigt iboende for vores daglige eksistens. Om et par årtier vil en storstilet it-fiasko blive mere end bare en dyr ulempe: det vil bringe vores livsstil i fare. Hvor meget af vores fremtid er vi villige til at spille på disse enormt dyre og komplekse systemer i mangel af den slags industrielle ændringer, der vil afbøde programfejl?
vi ved allerede, hvordan man gør programmel godt. Det kan endelig være tid til at handle på det, vi ved.