heb je die gehoord over het verdwijnende magazijn? Op een dag verdween het—niet uit fysiek oogpunt, maar uit de waakzame ogen van het geautomatiseerde distributiesysteem van een bekende retailer. Een softwarefout had op de een of andere manier het bestaan van het magazijn gewist, zodat goederen die bestemd waren voor het magazijn elders werden omgeleid, terwijl goederen in het magazijn wegkwijnen. Omdat het bedrijf financiële problemen had en andere magazijnen had afgesloten om geld te besparen, hielden de medewerkers van het “ontbrekende” magazijn zich stil. Drie jaar lang kwam of bleef er niets over. Werknemers kregen nog steeds hun loonstrookjes, echter, omdat een ander computersysteem de payroll behandelde. Toen de software glitch eindelijk aan het licht kwam, de merchandise in het magazijn werd verkocht, en het hogere management vertelde werknemers om niets te zeggen over de aflevering.

dit verhaal zweeft al meer dan 20 jaar rond in de informatietechnologie-industrie. Het is waarschijnlijk apocrief, maar voor ons in het vak, is het heel aannemelijk. Waarom? Want dit soort episodes gebeuren de hele tijd. Afgelopen oktober, bijvoorbeeld, de gigantische Britse food retailer J Sainsbury PLC moest afschrijven zijn US $ 526 miljoen investering in een geautomatiseerd supply-chain management systeem. Het lijkt erop dat merchandise zat vast in de depots en magazijnen van het bedrijf en was niet door te dringen tot veel van de winkels. Sainsbury werd gedwongen om ongeveer 3000 extra Klerken in te huren om de planken handmatig op te slaan .

Dit is slechts een van de nieuwste in een lange, sombere geschiedenis van IT-projecten die verkeerd zijn gegaan . De meeste IT-deskundigen zijn het erover eens dat dergelijke mislukkingen veel vaker voorkomen dan zou moeten. Wat meer is, de mislukkingen zijn universeel onbevooroordeeld: ze gebeuren in elk land; bij grote en kleine bedrijven; in commerciële, non-profit, en gouvernementele organisaties; en zonder rekening te houden met status of reputatie. De zakelijke en maatschappelijke kosten van deze mislukkingen—in termen van verspilde belastingbetaler en aandeelhouder dollars evenals investeringen die niet kunnen worden gemaakt-zijn nu ver in de miljarden dollars per jaar.

het probleem wordt alleen maar erger naarmate het alomtegenwoordig wordt. Dit jaar zullen organisaties en overheden wereldwijd naar schatting $1 biljoen uitgeven aan IT-hardware, software en diensten. Van de geïnitieerde IT-projecten wordt 5 tot 15 procent voor of kort na de oplevering opgegeven als hopeloos ontoereikend. Vele anderen zullen te laat komen en over het budget heen komen of zullen enorme aanpassingen nodig hebben. Weinig IT-projecten, met andere woorden, echt slagen. De grootste tragedie is dat softwarefouten meestal voorspelbaar en vermijdbaar zijn. Helaas zien de meeste organisaties het voorkomen van mislukking niet als een dringende zaak, ook al dreigt dat de organisatie te schaden en misschien zelfs te vernietigen. Begrijpen waarom deze houding aanhoudt is niet alleen een academische oefening; het heeft enorme gevolgen voor het bedrijfsleven en de samenleving.

SOFTWARE IS OVERAL. Zo kunnen we geld uit een geldautomaat halen, een telefoontje plegen en in onze auto rijden. Een typische mobiele telefoon bevat nu 2 miljoen regels software code; tegen 2010 zal het waarschijnlijk 10 keer zoveel. General Motors Corp. schat dat tegen die tijd de auto ‘ s zullen elk hebben 100 miljoen regels code.

het gemiddelde bedrijf besteedt ongeveer 4 tot 5% van de omzet aan informatietechnologie, waarbij degenen die sterk afhankelijk zijn van IT—zoals financiële en telecommunicatiebedrijven—meer dan 10% aan IT uitgeven. Met andere woorden, het is nu een van de grootste bedrijfskosten buiten de personeelskosten. Veel van dat geld gaat naar hardware en software upgrades, software licentiekosten, enzovoort, maar een groot deel is voor nieuwe software projecten bedoeld om een betere toekomst voor de organisatie en haar klanten te creëren.

ook overheden zijn grote gebruikers van software. In 2003 had het Verenigd Koninkrijk meer dan 100 grote IT-projecten van de overheid aan de gang die in totaal $20,3 miljard bedroegen. In 2004 catalogiseerde de Amerikaanse overheid 1200 civiele IT-projecten die meer dan $60 miljard kostten, plus nog eens $ 16 miljard voor militaire software.

elk van deze projecten kan meer dan 1 miljard dollar kosten. Om twee huidige voorbeelden te nemen, de computer modernisering inspanning bij het Amerikaanse Ministerie van Veterans Affairs wordt geprojecteerd op $3,5 miljard, terwijl het automatiseren van de gezondheidsdossiers van de Britse National Health Service zal waarschijnlijk meer dan $14,3 miljard kosten voor ontwikkeling en nog eens $50,8 miljard voor de implementatie.

dergelijke megasoftware-projecten, die ooit zeldzaam waren, komen nu veel vaker voor, omdat kleinere IT-operaties worden samengevoegd tot “systemen van systemen.”Luchtverkeersleiding is een goed voorbeeld, omdat het afhankelijk is van verbindingen tussen tientallen netwerken die communicatie, weer, navigatie en andere gegevens bieden. Maar de truc van integratie heeft veel IT-ontwikkelaars tegengehouden, tot het punt waarop academische onderzoekers steeds meer geloven dat de informatica zelf misschien moet worden heroverwogen in het licht van deze enorm complexe systemen.

wanneer een project mislukt, brengt het de vooruitzichten van een organisatie in gevaar. Als de mislukking groot genoeg is, kan het de hele toekomst van het bedrijf stelen. In een stellaire meltdown, een slecht geïmplementeerd resource planning systeem leidde FoxMeyer Drug Co. een groothandelaar van 5 miljard dollar in de distributie van drugs in Carrollton, Texas, die in 1996 failliet ging.

it-falen in de overheid kan de nationale veiligheid in gevaar brengen, zoals het virtuele debacle van het FBI-dossier heeft aangetoond. De $ 170 miljoen VCF-systeem, een doorzoekbare database bedoeld om agenten in staat te stellen “de punten te verbinden” en follow-up op ongelijksoortige stukken van intelligentie, in plaats daarvan eindigde vijf maanden geleden zonder dat een systeem wordt ingezet . It-mislukkingen kunnen ook de economische groei en de kwaliteit van het bestaan belemmeren. In 1981 begon de Amerikaanse Federal Aviation Administration te kijken naar het upgraden van zijn verouderde luchtverkeersleidingssysteem, maar de poging om een vervanging te bouwen werd al snel doorzeefd met problemen . In 1994, toen het Agentschap het project uiteindelijk opgaf, waren de voorspelde kosten verdrievoudigd, was meer dan $2,6 miljard uitgegeven en was de verwachte leveringstermijn enkele jaren verstreken. Elke vliegtuigpassagier die is vertraagd vanwege gridlocked skyways voelt nog steeds deze annulering; de cumulatieve economische impact van al die vertragingen op alleen de Amerikaanse luchtvaartmaatschappijen (laat staan de passagiers) nadert $50 miljard.

wereldwijd is het moeilijk te zeggen hoeveel softwareprojecten mislukken of hoeveel geld er als gevolg daarvan wordt verspild. Als u mislukking definieert als de totale stopzetting van een project voor of kort nadat het wordt geleverd, en als u een conservatieve mislukking van 5 procent accepteert, worden elk jaar miljarden dollars verspild aan slechte software.

bijvoorbeeld, in 2004, de VS de overheid spendeerde $ 60 miljard aan software (de ingebedde software in wapensystemen niet meegerekend); een foutpercentage van 5 procent betekent dat $3 miljard waarschijnlijk werd verspild. Echter, na enkele decennia als IT-consultant, ik ben ervan overtuigd dat het percentage mislukkingen is 15 tot 20 procent voor projecten met een budget van $10 miljoen of meer. Kijkend naar de totale investering in nieuwe softwareprojecten—zowel de overheid als het bedrijfsleven—in de afgelopen vijf jaar, schat ik dat mislukkingen van projecten de Amerikaanse economie waarschijnlijk minstens $25 miljard en misschien wel $75 miljard hebben gekost.

natuurlijk weerspiegelt die $ 75 miljard geen projecten die hun budget overschrijden—wat de meeste projecten wel doen. Het is evenmin een afspiegeling van projecten die te laat zijn uitgevoerd, wat de meerderheid is. Er wordt ook geen rekening gehouden met de alternatieve kosten van het opnieuw moeten beginnen als een project wordt opgegeven of met de kosten van door bug geteisterde systemen die herhaaldelijk moeten worden herwerkt.

dan zijn er ook de kosten van rechtszaken van woedende klanten die leveranciers aanklagen voor slecht geïmplementeerde systemen. Als je al deze extra kosten optelt, loopt het jaarlijkse tabblad voor mislukte en onrustige software conservatief ergens van $60 miljard tot $70 miljard alleen al in de Verenigde Staten. Voor dat geld kun je de spaceshuttle 100 keer lanceren, het volledige 24-satelliet Global Positioning System bouwen en implementeren, en de Boeing 777 vanaf nul ontwikkelen—en nog een paar miljard over hebben.

waarom mislukken projecten zo vaak?

een van de meest voorkomende factoren:

• Onrealistisch of onuitgesproken doelstellingen van het project
• Onnauwkeurige schattingen van de benodigde middelen
• Slecht gedefinieerde systeem vereisten
• Slechte rapportage van het project de status
• Onbeheerde risico ‘ s
• Slechte communicatie tussen klanten, ontwikkelaars, en gebruikers
• Gebruik van onvolwassen technologie
• Onvermogen om te gaan dat het project de complexiteit
• Slordig ontwikkeling praktijken
• Slecht project management
• Stakeholder politiek
• Commerciële druk

natuurlijk, IT-projecten zelden falen om een of twee redenen. Het VCF-project van de FBI leed onder veel van de hierboven genoemde problemen. De meeste mislukkingen, in feite, kan worden herleid tot een combinatie van technische, projectmanagement, en zakelijke beslissingen. Elke dimensie interageert met de andere op ingewikkelde manieren die projectrisico ‘ s en problemen verergeren en de kans op mislukking vergroten.

overweeg een eenvoudig software karwei: een inkoopsysteem dat de bestelling, facturering en verzending van onderdelen automatiseert, zodat een verkoper de bestelling van een klant kan invoeren, deze automatisch kan laten controleren op prijsstelling en contractvereisten, en ervoor kan zorgen dat de onderdelen en factuur vanuit het magazijn naar de klant worden verzonden.

de vereisten voor het systeem specificeren vier basisstappen. Ten eerste is er het verkoopproces, dat een factuur van de verkoop creëert. Deze factuur wordt vervolgens verstuurd via een juridisch proces, dat de contractuele voorwaarden van de potentiële verkoop beoordeelt en goedkeurt. Derde in lijn is het voorzieningsproces, waarbij de gecontracteerde onderdelen worden verzonden, gevolgd door het financieringsproces, waarbij een factuur wordt verzonden.

laten we zeggen dat terwijl het eerste proces, voor verkoop, wordt geschreven, de programmeurs elke bestelling behandelen alsof deze op de hoofdlocatie van het bedrijf is geplaatst, ook al heeft het bedrijf vestigingen in verschillende staten en landen. Deze fout heeft weer gevolgen voor de berekening van de belasting, voor het soort contract dat wordt gesloten, enzovoort.

hoe eerder de omissie wordt gedetecteerd en gecorrigeerd, hoe beter. Het is net als een trui breien. Als u ter plaatse een gemiste steek direct nadat u het, u kunt gewoon ontrafelen een beetje van garen en verder gaan. Maar als je niet vangen de fout tot het einde, kan het nodig zijn om de hele trui te ontrafelen alleen maar om die ene steek opnieuw.

als de software-programmeurs hun weglating niet zien tot de laatste systeemtest—of erger nog, tot nadat het systeem is uitgerold—zullen de kosten om de fout te corrigeren waarschijnlijk vele malen groter zijn dan wanneer ze de fout hadden opgelopen terwijl ze nog bezig waren met het eerste verkoopproces.

en in tegenstelling tot een gemiste steek in een trui, is dit probleem veel moeilijker te lokaliseren; de programmeurs zullen alleen zien dat er fouten optreden, en deze kunnen verschillende oorzaken hebben. Zelfs nadat de oorspronkelijke fout is gecorrigeerd, moeten ze andere berekeningen en documentatie wijzigen en vervolgens elke stap opnieuw testen. In feite hebben studies aangetoond dat softwarespecialisten ongeveer 40 tot 50% van hun tijd besteden aan vermijdbare herwerking in plaats van aan wat zij werk met toegevoegde waarde noemen, wat in feite werk is dat de eerste keer goed wordt gedaan. Zodra een stuk software het in het veld haalt, kunnen de kosten van het repareren van een fout 100 keer zo hoog zijn als tijdens de ontwikkelingsfase.

als er veel fouten zijn, dan kan rework een project beginnen te overspoelen, zoals een bijboot in een storm. Wat erger is, pogingen om een fout op te lossen introduceren vaak nieuwe. Het is alsof je die bijboot redt, maar je creëert ook lekken. Als er te veel fouten worden gemaakt, worden de kosten en de tijd die nodig is om het systeem te voltooien zo groot dat het geen zin heeft.

in de eenvoudigste termen, een IT-project mislukt meestal wanneer de rework groter is dan de toegevoegde waarde werk dat is begroot. Dit is wat er gebeurde met Sydney Water Corp., de grootste waterleverancier in Australië, toen het probeerde om een geautomatiseerde klant informatie en facturering systeem in te voeren in 2002 . Volgens een onderzoek van de Australische Auditor General, een van de factoren die het project gedoemd waren waren ontoereikende planning en specificaties, wat op zijn beurt leidde tot tal van verzoeken om wijziging en aanzienlijke extra kosten en vertragingen. Sydney Water afgebroken het project midway, na de uitgaven AU $ 61 miljoen (US $ 33,2 miljoen).

dit alles leidt ons tot de voor de hand liggende vraag: waarom komen er zoveel fouten voor?

mislukkingen van softwareprojecten hebben veel gemeen met vliegtuigcrashes. Net zoals piloten nooit van plan om te crashen, software-ontwikkelaars niet streven om te falen. Wanneer een commercieel vliegtuig crasht, kijken onderzoekers naar vele factoren, zoals het weer, onderhoud records, de opstelling en training van de piloot, en culturele factoren binnen de luchtvaartmaatschappij. Op dezelfde manier moeten we kijken naar de zakelijke omgeving, technisch beheer, projectmanagement en organisatiecultuur om bij de wortels van softwarefouten te komen.

de belangrijkste economische factoren zijn de concurrentie en de noodzaak om de kosten te drukken. In toenemende mate verwachten senior managers dat IT-afdelingen meer doen met minder en sneller dan voorheen; zij zien softwareprojecten niet als investeringen, maar als pure kosten die gecontroleerd moeten worden.

politieke vereisten kunnen ook schade toebrengen aan het schema, de kosten en de kwaliteit van een IT-project. Toen Denver International Airport probeerde zijn geautomatiseerd bagageafhandelingssysteem uit te rollen, hielden politieke leiders van de staat en de lokale politiek het project aan het ene onrealistische schema na het andere. Het niet tijdig leveren van het systeem vertraagde de opening in 1995 van de luchthaven (toen de grootste in de Verenigde Staten), wat de financiële gevolgen vele malen verergerde.

zelfs nadat het systeem was voltooid, werkte het nooit betrouwbaar: het kauwde bagage op, en de karren gebruikt om bagage rond te brengen ontspoorden vaak. Uiteindelijk klaagde United Airlines, de belangrijkste huurder van de luchthaven, de systeemaannemer aan, en de episode werd een bewijs van de gevaren van politieke opportuniteit.

een gebrek aan ondersteuning van het Hoger management kan ook een IT-onderneming verdoemen. Dit loopt het gamma van niet genoeg geld en mankracht toe te wijzen aan niet duidelijk vaststellen van de relatie van het IT-project tot de organisatie ‘ s business. In 2000, retailer Kmart Corp., in Troy, Mich., lanceerde een $1.4 miljard it-modernisering gericht op het koppelen van de verkoop, marketing, levering, en logistieke systemen, om beter te concurreren met rivaal Wal-Mart Corp., in Bentonville, Ark. Wal-Mart bleek te formidabel, hoewel, en 18 maanden later, cash-krap Kmart bezuinigen op de modernisering, het afschrijven van de $ 130 miljoen het al had geïnvesteerd in het. Vier maanden later werd het bankroet verklaard; het bedrijf blijft vandaag de dag worstelen.

vaak nemen it-projectmanagers die graag gefinancierd willen worden hun toevlucht tot een vorm van liar ‘ s poker, waarbij ze te veel beloven wat hun project zal doen, hoeveel het zal kosten en wanneer het zal worden voltooid. Veel, zo niet de meeste, softwareprojecten beginnen met budgetten die te klein zijn. Wanneer dat gebeurt, de ontwikkelaars moeten compenseren voor het tekort een of andere manier, meestal door te proberen om de productiviteit te verhogen, het verminderen van de reikwijdte van de inspanning, of het nemen van risicovolle snelkoppelingen in de herziening en testen fasen. Deze verhogen allemaal de kans op fouten en uiteindelijk falen. Een voorbeeld hiervan is een state-of-the-art reisreserveringssysteem dat wordt geleid door een consortium van Budget Rent-A-Car, Hilton Hotels, Marriott en AMR, de moedermaatschappij van American Airlines. In 1992, drie en een half jaar en 165 miljoen dollar aan het project, heeft de groep het opgegeven en daarbij twee belangrijke redenen aangevoerd: een te optimistisch ontwikkelingsschema en een onderschatting van de technische moeilijkheden die ermee gepaard gaan. Dit was dezelfde groep die eerder het enorm succesvolle reserveringssysteem Sabre had gebouwd, waaruit bleek dat prestaties uit het verleden geen garantie zijn voor toekomstige resultaten. Nadat onderzoekers het weer als een factor bij een vliegtuigcrash beschouwen, kijken ze naar het vliegtuig zelf. Was er iets in het ontwerp van het vliegtuig dat de crash veroorzaakte? Droeg het te veel gewicht?

bij mislukkingen van IT-projecten doen zich steevast soortgelijke vragen voor met betrekking tot de technische componenten van het project: de hardware en software die worden gebruikt om het systeem te ontwikkelen en de ontwikkelingspraktijken zelf. Organisaties worden vaak verleid door de sirene van de technologische imperatief—de oncontroleerbare drang om de nieuwste technologie te gebruiken in de hoop een concurrentievoordeel te krijgen. Met technologie snel veranderende en veelbelovende fantastische nieuwe mogelijkheden, is het gemakkelijk om te bezwijken. Maar het gebruik van onvolwassen of ongeteste technologie is een zekere weg naar mislukking. In 1997 sloot de staat Washington, na 40 miljoen dollar te hebben uitgegeven, een IT-project dat rijbewijzen en voertuigregistraties zou hebben verwerkt. Automobilisten gaven toe dat ze verstrikt raakten in het najagen van technologie in plaats van zich te concentreren op het implementeren van een systeem dat aan hun eisen voldeed. Het IT-debacle dat Foxmeyer-medicijn een jaar eerder naar beneden bracht, kwam ook voort uit het aannemen van een state-of-the-art resource-planning-systeem en het vervolgens verder te duwen dan wat het mogelijk kon doen.

de omvang van een project is een bron van mislukking. Uit Studies blijkt dat grootschalige projecten drie tot vijf keer vaker mislukken dan kleine. Hoe groter het project, hoe meer complexiteit er is in zowel de statische elementen (de discrete stukken software, hardware, enzovoort) en de dynamische elementen (de koppelingen en interacties tussen hardware, software en gebruikers; verbindingen met andere systemen; enzovoort). Grotere complexiteit verhoogt de kans op fouten, omdat niemand echt begrijpt alle op elkaar inwerkende delen van het geheel of heeft de mogelijkheid om ze te testen.

ontnuchterend maar waar: het is onmogelijk om een IT-systeem van enige echte grootte grondig te testen. Roger S. Pressman wees er in zijn boek Software Engineering, een van de klassieke teksten in het veld, op dat “exhaustieve testen bepaalde logistieke problemen oplevert….Zelfs een klein programma van 100 lijnen met een aantal geneste paden en een enkele lus die minder dan twintig keer uitvoert, kan 10 tot de kracht van 14 mogelijke paden vereisen om te worden uitgevoerd.”Om al die 100 biljoen paden te testen, merkte hij op, ervan uitgaande dat elk in een milliseconde geëvalueerd kon worden, zou het 3170 jaar duren.

alle IT-systemen zijn intrinsiek kwetsbaar. In een groot bakstenen gebouw moet je honderden strategisch geplaatste bakstenen verwijderen om een muur te laten instorten. Maar in een 100 000-line software programma, het duurt slechts een of twee slechte lijnen om grote problemen te produceren. In 1991, een deel van ATandamp;T ‘ s telefoonnetwerk ging uit, waardoor 12 miljoen abonnees zonder service, allemaal als gevolg van een enkele mistyped teken in een regel code.

slordige ontwikkelingspraktijken zijn een rijke bron van mislukkingen en kunnen fouten veroorzaken in elk stadium van een IT-project. Om organisaties te helpen bij het beoordelen van hun software-ontwikkeling praktijken, de VS Software Engineering Institute, in Pittsburgh, creëerde het Capability Maturity Model, of CMM. Het beoordeelt de praktijken van een bedrijf tegen vijf niveaus van toenemende volwassenheid. Niveau 1 betekent dat de organisatie gebruik maakt van ad hoc en mogelijk chaotische ontwikkelingspraktijken. Niveau 3 betekent dat het bedrijf zijn praktijken heeft gekarakteriseerd en ze nu begrijpt. Niveau 5 betekent dat de organisatie kwantitatief de variaties in de processen en praktijken begrijpt die zij toepast.

sinds januari hadden bijna 2000 overheids-en commerciële organisaties vrijwillig CMM-niveaus gemeld. Meer dan de helft erkende op niveau 1 of 2 te zijn, 30 procent was op niveau 3, en slechts 17 procent had niveau 4 of 5 bereikt. De percentages zijn nog somberder als je je realiseert dat dit een zelfgeselecteerde groep is; bedrijven met de slechtste it-praktijken zullen zich uiteraard niet onderwerpen aan een CMM-evaluatie. (Het CMM wordt vervangen door de CMM-integratie, die gericht is op een bredere beoordeling van het vermogen van een organisatie om software-intensieve systemen te creëren.)

onrijpe it praktijken gedoemd de VS Interne Revenue Service ’s $ 4 miljard modernisering inspanning in 1997, en ze zijn blijven pest de IRS’ s huidige $ 8 miljard modernisering. Het kan gewoon intrinsiek onmogelijk zijn om de belastingcode in softwarecode te vertalen—het belastingrecht is complex en is gebaseerd op vaak vage wetgeving, en het verandert voortdurend. Vanuit het standpunt van een IT-ontwikkelaar, het is een vereisten nachtmerrie. Maar de IRS is niet geholpen door open vijandigheid tussen interne en externe programmeurs, een lachwekkende onderschatting van het betrokken werk, en vele andere slechte praktijken.

de acties van de piloot vlak voor het neerstorten van een vliegtuig zijn altijd van groot belang voor onderzoekers. Dat komt omdat de piloot de ultieme beslisser is, verantwoordelijk voor de veilige werking van het vaartuig. Ook projectmanagers spelen een cruciale rol in softwareprojecten en kunnen een belangrijke bron van fouten zijn die tot mislukking leiden.

in 1986 besloot de London Stock Exchange haar systeem voor de afwikkeling van aandelentransacties te automatiseren. Zeven jaar later, na het uitgeven van $600 miljoen, schrapt het de ontwikkeling van het Taurus-systeem, niet alleen omdat het ontwerp te complex en omslachtig was, maar ook omdat het beheer van het project, om het woord van een van zijn eigen senior managers te gebruiken, “waanvoorstellingen was.”Uit onderzoek bleek dat niemand de ware status van het project wilde weten, ook al verschenen er steeds meer problemen, werden deadlines gemist en stegen de kosten .

de belangrijkste functie van de IT-projectmanager is het toewijzen van middelen aan verschillende activiteiten. Daarnaast is de projectmanager verantwoordelijk voor projectplanning en-schatting, controle, organisatie, contractbeheer, kwaliteitsmanagement, Risicobeheer, communicatie en human resource management.

slechte beslissingen van projectmanagers zijn waarschijnlijk de grootste oorzaak van softwarefouten vandaag de dag. Slecht technisch beheer kan daarentegen tot technische fouten leiden, maar die kunnen over het algemeen worden geïsoleerd en verholpen. Echter, een slechte project management beslissing-zoals het inhuren van te weinig programmeurs of het kiezen van de verkeerde soort contract—kan schade aanrichten. Zo beweren de ontwikkelaars van het doomed travel reservation system dat zij gedeeltelijk werden gehinderd door het gebruik van een contract tegen een vaste prijs. Een dergelijk contract veronderstelt dat het werk routinematig zal zijn; het reserveringssysteem bleek allesbehalve te zijn.

Projectmanagementbeslissingen zijn vaak lastig, juist omdat er sprake is van afwegingen op basis van vage of onvolledige kennis. Schatten hoeveel een IT-project zal kosten en hoe lang het zal duren is net zoveel kunst als wetenschap. Hoe groter of meer nieuw het project, hoe minder accuraat De schattingen. Het is een lopende grap in de industrie dat het project schattingen zijn op zijn best binnen 25 procent van hun werkelijke waarde 75 procent van de tijd.

er zijn andere manieren waarop slecht projectmanagement de ondergang van een softwareproject kan bespoedigen. Een studie van het Project Management Institute, in Newton Square, Pa., toonde aan dat risicomanagement het minst wordt toegepast van alle disciplines voor projectmanagement in alle sectoren van de industrie, en nergens wordt het minder vaak toegepast dan in de IT-industrie. Zonder effectief risicobeheer hebben softwareontwikkelaars weinig inzicht in wat er mis kan gaan, waarom het mis kan gaan en wat er kan worden gedaan om de risico ‘ s te elimineren of te beperken. Ook is er geen manier om te bepalen welke risico ‘ s aanvaardbaar zijn, waardoor projectbeslissingen over afwegingen bijna onmogelijk worden.

slecht projectmanagement neemt vele andere vormen aan, waaronder slechte communicatie, die een onherbergzame sfeer creëert die de omzet verhoogt; niet investeren in opleiding van personeel; en niet regelmatig de voortgang van het project evalueren. Elk van deze kan helpen ontsporen een software project.

het laatste gebied waar onderzoekers naar kijken na een vliegtuigcrash is de organisatorische omgeving. Heeft de luchtvaartmaatschappij een sterke veiligheidscultuur of legt ze de nadruk op het voldoen aan het vluchtschema? In IT-projecten is een organisatie die openheid, eerlijkheid, communicatie en samenwerking hoog in het vaandel draagt meer geneigd om fouten vroeg genoeg te vinden en op te lossen zodat rework niet overweldigend wordt.

als er een thema is dat door de gekwelde geschiedenis van slechte software loopt, is het een mislukking om de realiteit onder ogen te zien. Bij tal van gelegenheden vertelden de inspecteur-generaal van het Amerikaanse Ministerie van Justitie, een extern panel van deskundigen, en anderen het hoofd van de FBI dat het VCF-systeem onmogelijk was zoals gedefinieerd, en toch ging het project toch door. Dezelfde houding bestond onder degenen die verantwoordelijk waren voor het reisreserveringssysteem, het Taurus-systeem van de London Stock Exchange en het air-traffic—control-project van de FAA-allemaal indicatief voor organisatieculturen gedreven door angst en arrogantie. In een recent rapport van de National Audit Office in het Verenigd Koninkrijk werd een groot aantal gevallen geconstateerd van de aanbeveling van de overheid om toch niet verder te gaan met IT-projecten. Het Verenigd Koninkrijk heeft zelfs een ministerie belast met het voorkomen van IT-mislukkingen, maar zoals het rapport opgemerkt, meer dan de helft van de agentschappen het ministerie toezicht houdt routinematig negeren haar advies. Ik noem dit soort gedrag irrationele projectescalatie – het onvermogen om een project te stoppen, zelfs nadat het duidelijk is dat de kans op succes snel nul nadert. Helaas is dergelijk gedrag op geen enkele manier uniek.

uiteindelijk lijken grote softwarefouten vaak op de ergste denkbare vliegtuigcrash, waarbij de piloot onervaren was, maar buitengewoon onbezonnen, in een ijsstorm vloog in een niet-getest vliegtuig, en werkte voor een luchtvaartmaatschappij die lippendienst verleende aan veiligheid terwijl hij bezuinigde op training en onderhoud. Als je het rapport van de onderzoeker zou lezen, zou je je hoofd schudden en vragen: “was zo’ n crash niet onvermijdelijk?”

ook de redenen waarom softwareprojecten mislukken zijn bekend en zijn uitvoerig gedocumenteerd in talloze artikelen, rapporten en boeken . En toch, mislukkingen, bijna-mislukkingen, en gewoon oude slechte software blijven ons teisteren, terwijl praktijken bekend om fouten te voorkomen worden gemeden. Het lijkt erop dat het op tijd en binnen het budget krijgen van kwaliteitssoftware bij de meeste organisaties geen dringende prioriteit is.

het leek niet op Oxford Health Plans Inc., in Trumbull, Conn., in 1997. Het geautomatiseerde factureringssysteem van het bedrijf was van vitaal belang voor de bottom line, en toch waren senior managers er meer geïnteresseerd in het uitbreiden van Oxford ‘ s bedrijf dan in ervoor te zorgen dat het factureringssysteem kon voldoen aan de huidige behoeften . Zelfs toen zich problemen voordeden, zoals het maandenlang te laat versturen van facturen, gaven managers weinig aandacht. Toen het factureringssysteem effectief instortte, verloor het bedrijf tientallen miljoenen dollars, en zijn aandeel daalde van $68 naar $26 per aandeel in één dag, waardoor $3,4 miljard aan bedrijfswaarde werd weggevaagd. Aandeelhouders brachten rechtszaken, en verschillende overheidsinstanties onderzocht het bedrijf, die uiteindelijk werd beboet $3 miljoen voor schendingen van de regelgeving.

zelfs organisaties die gebrandmerkt raken door slechte software ervaringen lijken niet in staat of niet bereid om te leren van hun fouten. In een rapport uit 2000 merkte de U. S. Defense Science Board, een adviesorgaan van het Ministerie van Defensie, op dat verschillende studies in opdracht van het ministerie van Defensie 134 aanbevelingen hadden gedaan voor het verbeteren van de softwareontwikkeling, maar slechts 21 van die aanbevelingen waren opgevolgd. De andere 113 waren nog steeds geldig, merkte de Raad op, maar werden genegeerd, zelfs als de DOD klaagde over de slechte staat van Defensie software ontwikkeling!

sommige organisaties geven om softwarekwaliteit, zoals de ervaring van het softwareontwikkelingsbedrijf Praxis High Integrity Systems in Bath, Engeland, bewijst. Praxis eist dat haar klanten zich niet alleen financieel inzetten voor het project, maar ook als actieve deelnemers aan de creatie van het IT-systeem. Het bedrijf besteedt ook een enorme hoeveelheid tijd aan het begrijpen en definiëren van de eisen van de klant, en het daagt klanten uit om uit te leggen wat ze willen en waarom. Voordat er één regel code wordt geschreven, komen zowel de klant als de Praxis overeen wat gewenst, haalbaar en wat de risico ‘ s zijn, gezien de beschikbare middelen.

daarna past Praxis een rigoureuze ontwikkelingsbenadering toe die het aantal fouten beperkt. Een van de grote voordelen van dit model is dat het filtert uit de vele would-be klanten niet bereid om de verantwoordelijkheid van articuleren hun IT-eisen en de uitgaven van de tijd en geld om ze goed te implementeren accepteren.

een bepaald niveau van softwarefout zal altijd bij ons aanwezig zijn. We hebben inderdaad echte mislukkingen nodig—in plaats van vermijdbare blunders-om technische en economische vooruitgang te blijven boeken. Maar te veel van de mislukkingen die zich vandaag voordoen, zijn te vermijden. En als onze samenleving gaat vertrouwen op IT-systemen die steeds groter, meer geïntegreerd en duurder zijn, kunnen de kosten van falen rampzalig hoog worden.

zelfs nu is het mogelijk om weddenschappen aan te gaan op waar het volgende grote software debacle zal plaatsvinden. Een van mijn toonaangevende kandidaten is de IT-systemen die het resultaat zullen zijn van de Amerikaanse Overheid ‘ s American Health Information Community, een publiek-private samenwerking die streeft naar het definiëren van gegevensstandaarden voor elektronische medische dossiers. Het idee is dat zodra de normen zijn gedefinieerd, IT-systemen zullen worden gebouwd om medische professionals in het hele land in te voeren patiëntendossiers digitaal, waardoor artsen, ziekenhuizen, verzekeraars, en andere gezondheidszorg specialisten onmiddellijke toegang tot de volledige medische geschiedenis van een patiënt. Gezondheidszorgdeskundigen geloven dat een dergelijk systeem van systemen de patiëntenzorg zal verbeteren, de kosten met naar schatting $78 miljard per jaar zal verminderen en medische fouten zal verminderen, waardoor tienduizenden levens zullen worden gered.

maar deze aanpak is slechts een droom als de softwarepraktijken en het aantal mislukkingen zoals ze nu zijn blijven. Zelfs door de meest optimistische schattingen, om een elektronisch medisch record systeem te creëren zal 10 jaar van inspanning, $320 miljard aan ontwikkelingskosten, en $20 miljard per jaar in operationele kosten—ervan uitgaande dat er geen storingen, overschrijdingen, schema slips, beveiligingsproblemen, of slordige software. Dit is nauwelijks een realistisch scenario, vooral omdat de meeste IT-experts beschouwen de medische gemeenschap als de minst computer-savvy van alle professionele ondernemingen.

patiënten en belastingbetalers zullen uiteindelijk de prijs betalen voor de ontwikkeling, of het falen, van boondoggles als deze. Gezien de huidige IT-praktijken, mislukking is een duidelijke mogelijkheid, en het zou een verlies van ongekende omvang. Maar dan, landen over de hele wereld overwegen of al aan het werk op vele initiatieven van vergelijkbare omvang en impact—in de luchtvaart, nationale veiligheid, en het leger, onder andere arena ‘ s. Net als elektriciteit, water, transport en andere kritieke onderdelen van onze infrastructuur, is het snel intrinsiek aan het worden in ons dagelijks bestaan. Over een paar decennia zal een grootschalige IT-mislukking meer worden dan alleen maar een duur ongemak.: het zal onze manier van leven in gevaar brengen. Bij gebrek aan veranderingen in de hele industrie die softwarefouten zullen verminderen, hoeveel van onze toekomst zijn we bereid om te gokken op deze enorm dure en complexe systemen?

we weten al hoe we software goed kunnen gebruiken. Het is misschien eindelijk tijd om te handelen naar wat we weten.