Oletko kuullut yhden katoavasta varastosta? Eräänä päivänä se katosi-ei fyysisestä näkökulmasta, vaan tunnetun jälleenmyyjän automatisoidun jakelujärjestelmän valvovista silmistä. Ohjelmistovika oli jotenkin pyyhkinyt varaston olemassaolon niin, että varastoon tarkoitetut tavarat ohjattiin muualle, kun taas varastossa olevat tavarat riutuivat. Koska yhtiö oli taloudellisissa vaikeuksissa ja oli sulkenut muita varastoja säästääkseen rahaa, ”kadonneen” varaston työntekijät vaikenivat. Kolmeen vuoteen ei tullut eikä lähtenyt mitään. Työntekijät saivat kuitenkin vielä palkkasekkinsä, koska toinen tietokonejärjestelmä hoiti palkanmaksun. Kun ohjelmistovika lopulta paljastui, varastossa olleet tavarat myytiin pois, ja ylempi johto käski työntekijöitä olemaan sanomatta episodista mitään.

tämä tarina on leijunut tietotekniikkateollisuudessa jo 20-joitakin vuosia. Se on ehkä apokryfistä, mutta meille alalla toimiville se on täysin uskottavaa. Miksi? Koska tällaisia jaksoja sattuu koko ajan. Esimerkiksi viime lokakuussa jättimäinen Brittiläinen elintarvikekauppias J Sainsbury PLC joutui mitätöimään 526 miljoonan dollarin investointinsa automatisoituun toimitusketjun hallintajärjestelmään. Näyttää siltä, että kauppatavaraa oli juuttunut yhtiön varastoihin ja varastoihin, eikä se päässyt läpi moniin sen myymälöihin. Sainsbury joutui palkkaamaan noin 3000 ylimääräistä virkailijaa varastoimaan hyllynsä manuaalisesti .

tämä on vain yksi viimeisimmistä epäonnistuneiden IT-projektien synkässä historiassa . Useimmat tietotekniikan asiantuntijat ovat yhtä mieltä siitä, että tällaisia epäonnistumisia tapahtuu paljon useammin kuin niiden pitäisi. Lisäksi epäonnistumiset ovat yleisesti ennakkoluulottomia: niitä tapahtuu kaikissa maissa; suurille yrityksille ja pienille; kaupallisille, voittoa tavoittelemattomille ja valtiollisille järjestöille; ja statuksesta tai maineesta piittaamatta. Näiden epäonnistumisten aiheuttamat liiketoiminnalliset ja yhteiskunnalliset kustannukset-tuhlatut veronmaksajien ja osakkeenomistajien dollarit sekä investoinnit, joita ei voida tehdä—ovat nyt miljardeja dollareita vuodessa.

ongelma vain pahenee, kun se yleistyy kaikkialla. Tänä vuonna organisaatiot ja hallitukset käyttävät arviolta 1 biljoona dollaria IT-laitteistoihin, ohjelmistoihin ja palveluihin maailmanlaajuisesti. Aloitetuista IT-hankkeista 5-15 prosenttia luovutetaan ennen toimitusta tai pian sen jälkeen toivottoman puutteellisina. Monet muut saapuvat myöhässä ja yli budjetin tai vaativat massiivista uudistamista. Harva IT-hanke, toisin sanoen, todella onnistuu.

suurin tragedia on, että ohjelmistovika on suurimmaksi osaksi ennustettavissa ja vältettävissä. Valitettavasti useimmat organisaatiot eivät näe epäonnistumisen estämistä kiireellisenä asiana, vaikka tämä näkemys uhkaa vahingoittaa organisaatiota ja ehkä jopa tuhota sen. Sen ymmärtäminen, miksi tällainen asenne jatkuu, ei ole vain akateemista työtä, vaan sillä on valtavia vaikutuksia liike-elämään ja yhteiskuntaan.

OHJELMISTO ON KAIKKIALLA. Sen avulla saamme rahaa pankkiautomaatista, soitamme puhelun ja ajamme autojamme. Tyypillinen matkapuhelin sisältää nyt 2 miljoonaa riviä ohjelmistokoodia; vuoteen 2010 mennessä se on todennäköisesti 10 kertaa niin paljon. General Motors Corp. arvioi, että siihen mennessä sen autoissa on kussakin 100 miljoonaa koodiriviä.

keskivertoyritys käyttää noin 4-5 prosenttia tuloista tietotekniikkaan, ja ne, jotka ovat erittäin TIETOTEKNIIKKARIIPPUVAISIA—kuten rahoitus—ja teleyhtiöt-käyttävät yli 10 prosenttia tietotekniikkaan. Toisin sanoen se on nyt yksi suurimmista yritysten kuluista henkilöstökulujen ulkopuolella. Suuri osa tuosta rahasta menee laitteisto-ja ohjelmistopäivityksiin, ohjelmistolisenssimaksuihin ja niin edelleen, mutta iso osa on uusille ohjelmistoprojekteille, joiden tarkoituksena on luoda parempi tulevaisuus organisaatiolle ja sen asiakkaille.

Hallituksetkin ovat ohjelmistojen suurkuluttajia. Vuonna 2003 Yhdistyneessä kuningaskunnassa oli käynnissä yli 100 suurta valtion TIETOTEKNIIKKAHANKETTA, joiden yhteenlaskettu arvo oli 20,3 miljardia dollaria. Vuonna 2004 Yhdysvaltain hallitus luetteloi 1 200 siviilien IT-projektia, jotka maksoivat yli 60 miljardia dollaria, ja lisäksi 16 miljardia dollaria sotilasohjelmistoille.

mikä tahansa näistä projekteista voi maksaa yli miljardi dollaria. Ottaa kaksi nykyistä esimerkkiä, tietokoneen modernisointi vaivaa US Department of Veterans Affairs ennustetaan ajaa $3.5 miljardia, kun taas automatisointi terveystiedot Yhdistyneen kuningaskunnan National Health Service todennäköisesti maksaa yli $14.3 miljardia kehittämiseen ja toinen $50.8 miljardia käyttöönottoa.

tällaiset aiemmin harvinaiset megasoftware-projektit ovat nykyään paljon yleisempiä, kun pienempiä IT-operaatioita yhdistetään ”systems of systems-järjestelmiksi.”Lennonjohto on erinomainen esimerkki, koska se luottaa yhteyksiin kymmenissä verkoissa, jotka tarjoavat tietoliikennettä, säätä, navigointia ja muita tietoja. Mutta integraation juju on hiertänyt monia tietotekniikan kehittäjiä siinä määrin, että akateemiset tutkijat uskovat yhä enemmän siihen, että tietojenkäsittelytiedettä itseään on ehkä harkittava uudelleen näiden massiivisen monimutkaisten järjestelmien valossa.

kun hanke epäonnistuu , se vaarantaa organisaation tulevaisuudennäkymät. Jos vika on tarpeeksi suuri, se voi viedä yhtiön koko tulevaisuuden. Yhdessä tähtien sulamisen, huonosti toteutettu resurssien suunnittelujärjestelmä johti FoxMeyer Drug Co., 5 miljardin dollarin tukkukauppa huumeiden jakeluyhtiö Carrolltonissa, Texasissa, syöksyy konkurssiin vuonna 1996.

it-epäonnistuminen hallituksessa voi vaarantaa kansallisen turvallisuuden, kuten FBI: n Virtuaalitapausfiaskon fiasko on osoittanut. 170 miljoonan dollarin VCF-järjestelmä, haettavissa oleva tietokanta, jonka avulla agentit voivat ”yhdistää pisteet” ja seurata erilaisia tiedustelutietoja, sen sijaan loppui viisi kuukautta sitten ilman, että mitään järjestelmää olisi otettu käyttöön .

IT-epäonnistumiset voivat myös jarruttaa talouskasvua ja elämänlaatua. Vuonna 1981 Yhdysvaltain ilmailuhallinto (Federal Aviation Administration) alkoi tutkia vanhanaikaisen lennonjohtojärjestelmänsä päivittämistä, mutta uuden järjestelmän rakentaminen tuotti pian ongelmia . Vuoteen 1994 mennessä, jolloin virasto lopulta luopui hankkeesta, ennustetut kustannukset olivat kolminkertaistuneet, yli 2,6 miljardia dollaria oli käytetty ja odotettu toimituspäivä oli liukunut useilla vuosilla. Jokainen lentomatkustaja, joka myöhästyy ruuhkaisten taivaskatujen vuoksi, tuntee yhä tämän peruutuksen.; kaikkien näiden viivästysten kumulatiivinen taloudellinen vaikutus pelkästään yhdysvaltalaisiin lentoyhtiöihin (puhumattakaan matkustajista) lähestyy 50 miljardia dollaria.

maailmanlaajuisesti on vaikea sanoa, kuinka moni ohjelmistoprojekti epäonnistuu tai kuinka paljon rahaa sen seurauksena menee hukkaan. Jos määrittelet epäonnistumisen projektin täydellisenä hylkäämisenä ennen tai pian sen jälkeen, kun se on toimitettu, ja jos hyväksyt konservatiivisen epäonnistumisprosentin 5 prosenttia, niin miljardeja dollareita tuhlataan vuosittain huonoihin ohjelmistoihin.

esimerkiksi vuonna 2004 Yhdysvalloissa. hallitus käytti 60 miljardia dollaria ohjelmistoihin (lukuun ottamatta sulautettuja ohjelmistoja asejärjestelmissä); 5 prosentin vikaantumisaste tarkoittaa, että 3 miljardia dollaria meni todennäköisesti hukkaan. Oltuani useita vuosikymmeniä IT-konsulttina olen kuitenkin vakuuttunut siitä, että epäonnistumisprosentti on 15-20 prosenttia hankkeissa, joiden budjetti on vähintään 10 miljoonaa dollaria. Tarkasteltaessa kokonaisinvestointeja uusiin ohjelmistoprojekteihin-sekä valtion että yritysten – viimeisten viiden vuoden aikana, arvioin, että projektien epäonnistumiset ovat todennäköisesti maksaneet Yhdysvaltain taloudelle vähintään 25 miljardia dollaria ja ehkä jopa 75 miljardia dollaria.

tuo 75 miljardin dollarin summa ei tietenkään kerro hankkeista, jotka ylittävät niiden budjetit—mitä useimmat hankkeet tekevät. Se ei myöskään heijasta myöhässä toteutettuja hankkeita, joita suurin osa on. Siinä ei myöskään oteta huomioon vaihtoehtokustannuksia, jotka aiheutuvat siitä, että hanke joudutaan aloittamaan alusta, kun hanke hylätään, tai kustannuksia, joita aiheutuu vikojen runtelemista järjestelmistä, joita on muokattava toistuvasti uudelleen.

myös kustannukset, jotka aiheutuvat siitä, että suuttuneet asiakkaat haastavat tavarantoimittajat oikeuteen huonosti toteutetuista järjestelmistä. Kun kaikki nämä lisäkustannukset lasketaan yhteen, epäonnistuneiden ja ongelmallisten ohjelmistojen vuosittainen välilehti on varovaisesti 60 miljardista 70 miljardiin dollariin yksistään Yhdysvalloissa. Sillä rahalla voisi laukaista avaruussukkulan 100 kertaa, rakentaa ja ottaa käyttöön Koko 24 satelliitin maailmanlaajuisen paikannusjärjestelmän ja kehittää Boeing 777: n tyhjästä—ja vielä olisi muutama miljardi jäljellä.

miksi hankkeet epäonnistuvat niin usein?

yleisimpiä tekijöitä:

• epärealistiset tai määrittelemättömät projektin tavoitteet
• epätarkat arviot tarvittavista resursseista
• huonosti määritellyt järjestelmävaatimukset
• huono raportointi projektin tilasta
• hallitsemattomat riskit
• asiakkaiden, kehittäjien ja käyttäjien huono viestintä
• epäkypsän teknologian käyttö
• kyvyttömyys käsitellä hankkeen monimutkaisuutta
• huolimattomat Kehityskäytännöt
• huono projektinhallinta
• sidosryhmäpolitiikka
• kaupalliset paineet

tietenkin it-hankkeet harvoin epäonnistua vain yhdestä tai kahdesta syystä. FBI: n VCF-projekti kärsi monista edellä mainituista ongelmista. Useimmat epäonnistumiset, itse asiassa, voidaan jäljittää yhdistelmä tekninen, projektinhallinta, ja liiketoiminnan päätöksiä. Jokainen ulottuvuus on vuorovaikutuksessa muiden kanssa monimutkaisilla tavoilla, jotka pahentavat projektin riskejä ja ongelmia ja lisäävät epäonnistumisen todennäköisyyttä.

harkitse yksinkertaista ohjelmistotyötä: ostojärjestelmä, joka automatisoi osien tilaamisen, laskutuksen ja kuljetuksen niin, että myyjä voi syöttää asiakkaan tilauksen, tarkistuttaa sen automaattisesti hinnoittelu-ja sopimusvaatimuksia vastaan ja järjestää niin, että osat ja lasku lähetetään asiakkaalle varastosta.

järjestelmän vaatimuksissa on määritelty neljä perusvaihetta. Ensin on myyntiprosessi, joka luo kauppakirjan. Lasku lähetetään sitten oikeusprosessin kautta, jossa käydään läpi mahdollisen myynnin sopimusehdot ja hyväksytään ne. Kolmantena on varausprosessi, joka lähettää tilatut osat, ja sen jälkeen rahoitusprosessi, joka lähettää laskun.

sanotaan, että kun ensimmäistä myyntiprosessia kirjoitetaan, ohjelmoijat suhtautuvat jokaiseen tilaukseen ikään kuin se olisi tehty yrityksen pääpaikalle, vaikka yrityksellä on sivukonttoreita useissa osavaltioissa ja maissa. Se virhe puolestaan vaikuttaa siihen, miten vero lasketaan, millainen sopimus tehdään ja niin edelleen.

mitä nopeammin laiminlyönti havaitaan ja korjataan, sen parempi. Se on vähän kuin neuloisi villapaitaa. Jos havaitset missatun ompeleen heti sen jälkeen, kun olet tehnyt sen, voit yksinkertaisesti purkaa hieman lankaa ja siirtyä eteenpäin. Mutta jos virhe jää kiinni vasta lopussa, voi olla, että koko villapaita joutuu purkamaan sen yhden tikin uusiksi.

jos ohjelmistokoodarit eivät huomaa virhettään ennen järjestelmän lopullista testausta—tai pahempaa, ennen kuin järjestelmä on otettu käyttöön—virheen korjaamisesta aiheutuvat kustannukset ovat todennäköisesti moninkertaiset verrattuna siihen, jos he olisivat huomanneet virheen, kun he vielä työskentelivät alkuperäisen myyntiprosessin parissa.

ja toisin kuin neulepuserossa oleva puuttuva ommel, tätä ongelmaa on paljon vaikeampi paikantaa; ohjelmoijat näkevät vain, että virheitä esiintyy, ja niihin voi olla useita syitä. Vaikka alkuperäinen virhe on korjattu, heidän on muutettava muita laskelmia ja dokumentaatiota ja sitten uusittava jokainen vaihe.

itse asiassa tutkimukset ovat osoittaneet, että ohjelmistoasiantuntijat käyttävät noin 40-50 prosenttia ajastaan vältettävissä olevaan uudelleentyöskentelyyn eivätkä niin sanottuun lisäarvotyöhön, joka on pohjimmiltaan työtä, joka tehdään oikein ensimmäisellä kerralla. Kun ohjelmistopala pääsee kentälle, virheen korjauskustannukset voivat olla 100-kertaiset siihen verrattuna, mitä se olisi ollut kehitysvaiheessa.

jos virheitä on runsaasti, niin remontti voi alkaa suottaa projektia kuin Jollaa myrskyssä. Mikä pahempaa, yritykset korjata virhe usein käyttöön uusia. Kuin pelastaisit Jollan, mutta aiheutat myös vuotoja. Jos virheitä syntyy liikaa, kustannukset ja järjestelmän loppuun saattamiseen tarvittava aika nousevat niin suuriksi, että jatkaminen ei ole järkevää.

yksinkertaisimmillaan tietotekniikkahanke yleensä epäonnistuu, kun uusintatyö ylittää budjetoidun arvonlisätyön. Näin kävi Australian suurimmalle veden tarjoajalle Sydney Water Corpille, kun se yritti ottaa käyttöön automaattisen Asiakastieto-ja laskutusjärjestelmän vuonna 2002 . Australian Auditor General-yhtiön tutkimuksen mukaan hankkeen tuhoon vaikuttivat muun muassa riittämätön suunnittelu ja tekniset tiedot, mikä puolestaan johti lukuisiin muutospyyntöihin ja merkittäviin lisäkustannuksiin ja viivästyksiin. Sydney Water keskeytti projektin puolivälissä käytettyään 61 miljoonaa dollaria (33,2 miljoonaa euroa).

jotka kaikki johdattavat meidät ilmeiseen kysymykseen: miksi tapahtuu niin paljon virheitä?

ohjelmistoprojektien epäonnistumisilla on paljon yhteistä lentokoneonnettomuuksien kanssa. Aivan kuten lentäjät eivät koskaan aio kaatua, ohjelmistokehittäjät eivät pyri epäonnistumaan. Kun liikelentokone syöksyy maahan, tutkijat tarkastelevat monia seikkoja, kuten säätä, huoltotietoja, lentäjän asennetta ja koulutusta sekä lentoyhtiön kulttuurisia tekijöitä. Samoin meidän on tarkasteltava liiketoimintaympäristöä, teknistä johtamista, projektinhallintaa ja organisaatiokulttuuria päästäksemme ohjelmistovikojen juurille.

tärkeimpiä liiketoiminnallisia tekijöitä ovat kilpailu ja tarve leikata kustannuksia. Ylemmät johtajat odottavat yhä useammin IT-osastojen tekevän enemmän vähemmällä ja nopeammin kuin ennen; he eivät pidä ohjelmistoprojekteja investointeina vaan puhtaina kustannuksina, joita on valvottava.

poliittiset pakotteet voivat myös vaikuttaa TIETOTEKNIIKKAHANKKEEN aikatauluun, kustannuksiin ja laatuun. Kun Denverin kansainvälinen lentokenttä yritti ottaa käyttöön automatisoidun matkatavaroiden käsittelyjärjestelmänsä, osavaltion ja paikallisten poliittisten johtajien piti hankkeen epärealistinen aikataulu toisensa jälkeen. Koska järjestelmää ei toimitettu ajoissa, lentoaseman avaaminen viivästyi vuonna 1995 (tuolloin Yhdysvaltojen suurin lentoasema), mikä lisäsi sen taloudellista vaikutusta moninkertaisesti.

järjestelmän valmistumisen jälkeenkään se ei koskaan toiminut luotettavasti: se pureskeli matkatavaroita, ja matkatavaroiden kuljetukseen käytetyt kärryt suistuivat usein raiteilta. Lopulta lentoaseman päävuokralainen United Airlines haastoi järjestelmäurakoitsijan oikeuteen, ja episodista tuli osoitus poliittisen tarkoituksenmukaisuuden vaaroista.

ylemmän johdon tuen puute voi myös kirota tietotekniikkayrityksen. Tämä johtaa siihen, että rahaa ja työvoimaa ei ole osoitettu riittävästi, eikä TIETOTEKNIIKKAHANKKEEN suhdetta organisaation liiketoimintaan ole selvästi määritetty. Vuonna 2000 kauppias Kmart Corp., Troy, Mich., laukaisi $1.4 miljardia IT modernisointi pyrkimyksenä yhdistää sen myynti, markkinointi, tarjonta, ja logistiikkajärjestelmät, paremmin kilpailla kilpailija Wal-Mart Corp., Bentonville, Ark. Wal-Mart osoittautui liian pelottavaksi, vaikka, ja 18 kuukautta myöhemmin, käteisellä rahapulassa Kmart leikata modernisointi, kirjallisesti pois $130 miljoonaa se oli jo investoinut siihen. Neljä kuukautta myöhemmin se teki konkurssin; yhtiö jatkaa kamppailuaan tänään.

usein rahoituksesta innostuneet it-projektipäälliköt turvautuvat eräänlaiseen valehtelijan Pokeriin ja ylikorostavat, mitä heidän projektinsa tekee, paljonko se maksaa ja milloin se valmistuu. Monet, ellei useimmat, ohjelmistoprojektit alkavat liian pienillä budjeteilla. Kun näin tapahtuu, kehittäjien on korvattava vaje jotenkin, tyypillisesti yrittämällä lisätä tuottavuutta, vähentää vaivaa, tai ottamalla riskialtista oikoteitä tarkastelun ja testauksen vaiheissa. Nämä kaikki lisäävät virheen ja lopulta epäonnistumisen todennäköisyyttä.

huippumatkavarausjärjestelmä, jota johtaa Budget Rent-A-Car, Hilton Hotels, Marriott ja American Airlinesin emoyhtiö AMR. Vuonna 1992, kolme ja puoli vuotta ja 165 miljoonaa dollaria hankkeeseen, ryhmä luopui siitä vedoten kahteen pääsyyn: liian optimistiseen kehitysaikatauluun ja siihen liittyvien teknisten vaikeuksien aliarvioimiseen. Kyseessä oli sama ryhmä, joka oli aiemmin rakentanut valtavan menestyneen Sabren varausjärjestelmän, osoittaen, ettei aiempi suoritus ole tae tulevista tuloksista.

kun onnettomuustutkijat pitävät säätä syynä lento-onnettomuuteen, he tarkastelevat itse lentokonetta. Oliko koneen suunnittelussa jotain, mikä aiheutti turman? Kantoiko se liikaa painoa?

IT-projektien epäonnistumisissa tulee poikkeuksetta esiin samanlaisia kysymyksiä projektin teknisistä komponenteista: järjestelmän kehittämiseen käytetystä laitteistosta ja ohjelmistosta sekä itse kehittämiskäytännöistä. Organisaatioita houkuttelee usein teknologisen imperatiivin seireenilaulu-hallitsematon halu käyttää uusinta teknologiaa siinä toivossa, että he saisivat kilpailuetua. Teknologian muuttuessa nopeasti ja lupaillessa fantastisia uusia ominaisuuksia on helppo sortua. Mutta epäkypsän tai testaamattoman teknologian käyttäminen on varma tie epäonnistumiseen.

vuonna 1997 Washingtonin osavaltio lakkautti 40 miljoonaa dollaria maksaneen IT-projektin, joka olisi käsitellyt ajokortteja ja ajoneuvojen rekisteröintejä. Autoviranomaiset myönsivät ajautuneensa tekniikan perässä sen sijaan, että olisivat keskittyneet toteuttamaan heidän vaatimuksensa täyttävää järjestelmää. IT-fiasko, joka kaatoi Foxmeyerin lääkkeen vuotta aiemmin, johtui myös siitä, että se otti käyttöön huipputeknisen resurssisuunnittelujärjestelmän ja työnsi sen pidemmälle kuin mitä se voisi helposti tehdä.

pelkkä projektin koko on epäonnistumisen lähde. Tutkimukset osoittavat, että suuret hankkeet epäonnistuvat kolmesta viiteen kertaa useammin kuin pienet. Mitä suurempi projekti, sitä monimutkaisempaa on sekä sen staattisissa elementeissä (ohjelmistojen, laitteistojen ja niin edelleen erillisissä kappaleissa) että sen dynaamisissa elementeissä (laitteiston, ohjelmiston ja käyttäjien väliset kytkennät ja vuorovaikutukset; yhteydet muihin järjestelmiin ja niin edelleen). Monimutkaistuminen lisää virheiden mahdollisuutta, koska kukaan ei oikein ymmärrä kaikkia kokonaisuuden vuorovaikutuksellisia osia tai osaa testata niitä.

Raitistavaa mutta totta: on mahdotonta testata perusteellisesti minkään todellisen kokoista IT-järjestelmää. Tri Roger S. Pressman huomautti kirjassaan Software Engineering, yksi alan klassikoista, että ” tyhjentävä testaus aiheuttaa tiettyjä logistisia ongelmia….Jopa pieni 100-rivinen ohjelma, jossa on joitakin sisäkkäisiä polkuja ja yksi silmukka, joka suoritetaan alle kaksikymmentä kertaa, voi vaatia 10 potenssiin 14 mahdollista polkua suoritettavaksi.”Kaikkien noiden 100 biljoonan polun testaaminen veisi hänen mukaansa 3170 vuotta, olettaen, että jokainen voitaisiin arvioida millisekunnissa.

kaikki tietojärjestelmät ovat luonnostaan hauraita. Isossa tiilirakennuksessa pitäisi poistaa satoja strategisesti sijoitettuja tiiliä, jotta seinä sortuisi. Mutta 100 000 linjan ohjelmistossa tarvitaan vain yksi tai kaksi huonoa riviä tuottamaan suuria ongelmia. Vuonna 1991 osa ATandamp;T: n puhelinverkkoa sammui ja 12 miljoonaa tilaajaa jäi ilman palvelua, kaikki yhden koodirivin väärin kirjoitetun merkin takia.

huolimattomat kehityskäytännöt aiheuttavat runsaasti epäonnistumisia, ja ne voivat aiheuttaa virheitä missä tahansa IT-projektin vaiheessa. Auttaakseen järjestöjä arvioimaan ohjelmistokehityskäytäntöjään U. S. Pittsburghissa sijaitseva Software Engineering Institute loi Capability Maturity-mallin eli CMM: n. Se luokittelee yrityksen käytännöt viiteen kasvavaan kypsyystasoon. Taso 1 tarkoittaa, että organisaatio käyttää ad hoc-ja mahdollisesti kaoottisia kehityskäytäntöjä. Taso 3 tarkoittaa, että yhtiö on luonnehtinut toimintatapojaan ja ymmärtää niitä nyt. Taso 5 tarkoittaa, että organisaatio ymmärtää kvantitatiivisesti sovellettavien prosessien ja käytäntöjen vaihtelut.

tammikuusta lähtien lähes 2000 valtiollista ja kaupallista organisaatiota oli vapaaehtoisesti ilmoittanut CMM-tason. Yli puolet tunnusti olevansa tasolla 1 tai 2, 30 prosenttia oli tasolla 3 ja vain 17 prosenttia oli saavuttanut tason 4 tai 5. Prosenttiosuudet ovat vieläkin lohduton, kun huomaat, että tämä on itse valittu ryhmä; ilmeisesti yritykset, joilla on pahin IT-käytännöt eivät alistu CMM arviointi. (CMM: n syrjäyttää CMM-integraatio, jonka tavoitteena on laajempi arviointi organisaation kyvystä luoda ohjelmistopainotteisia järjestelmiä.)

epäkypsät IT-käytännöt tuomitsivat USA: n Internal Revenue Service N $4 miljardia modernisointi vaivaa 1997, ja ne ovat jatkaneet rutto IRS nykyinen $8 miljardia modernisointi. Verolain kääntäminen ohjelmistokoodiksi voi vain olla luontaisesti mahdotonta-verolaki on monimutkainen ja perustuu usein epämääräiseen lainsäädäntöön, ja se muuttuu koko ajan. IT-kehittäjän näkökulmasta se on vaatimusten painajainen. Mutta IRS: ää ei ole auttanut avoin vihamielisyys omien ja ulkopuolisten ohjelmoijien välillä, naurettava työn aliarviointi ja monet muut huonot käytännöt.

lentäjän toiminta juuri ennen lentokoneen maahansyöksyä kiinnostaa tutkijoita aina suuresti. Tämä johtuu siitä, että luotsi on lopullinen päätöksentekijä, joka vastaa aluksen turvallisesta toiminnasta. Vastaavasti projektipäälliköt ovat ratkaisevassa asemassa ohjelmistoprojekteissa ja voivat olla merkittävä epäonnistumiseen johtavien virheiden lähde.

jo vuonna 1986 Lontoon pörssi päätti automatisoida järjestelmänsä osakekauppojen selvittämiseen. Seitsemän vuotta myöhemmin, käytettyään 600 miljoonaa dollaria, se romutti Taurus-järjestelmän kehityksen, ei vain siksi, että sen suunnittelu oli liian monimutkaista ja hankalaa, vaan myös siksi, että projektin johto oli, erään Oman ylimmän johdon sanaa käyttääkseni, ”harhainen.”Kuten tutkimukset osoittivat, kukaan ei näyttänyt haluavan tietää hankkeen todellista tilaa, vaikka yhä enemmän ongelmia ilmaantui, määräajat jäivät täyttymättä ja kustannukset nousivat huimasti .

IT-projektipäällikön tärkein tehtävä on resurssien kohdentaminen erilaisiin toimintoihin. Sen lisäksi projektipäällikkö vastaa projektin suunnittelusta ja arvioinnista, valvonnasta, organisaatiosta, sopimusten hallinnasta, laadunhallinnasta, riskienhallinnasta, viestinnästä ja henkilöstöjohtamisesta.

projektipäälliköiden huonot päätökset lienevät suurin yksittäinen syy ohjelmistovirheisiin nykyään. Huono tekninen johtaminen sen sijaan voi johtaa teknisiin virheisiin, mutta ne voidaan yleensä eristää ja korjata. Huono projektijohtopäätös—kuten liian vähän ohjelmoijia tai vääränlaisen sopimuksen valitseminen-voi kuitenkin aiheuttaa tuhoa. Esimerkiksi tuhoon tuomitun matkavarausjärjestelmän kehittäjät väittävät, että he horjuivat osittain kiinteähintaisen sopimuksen avulla. Tällaisessa sopimuksessa oletetaan, että työ on rutiinia; varausjärjestelmä osoittautui kaikkea muuta.

Projektinhallintapäätökset ovat usein hankalia juuri siksi, että niissä on kyse epäselvään tai puutteelliseen tietoon perustuvista kaupoista. Sen arvioiminen, kuinka paljon IT-projekti tulee maksamaan ja kuinka kauan se kestää, on yhtä paljon taidetta kuin tiedettä. Mitä suurempi tai romaanisempi hanke, sitä epätarkemmat arviot. Se on käynnissä vitsi alalla, että IT-projektin arviot ovat parhaimmillaan sisällä 25 prosenttia niiden todellinen arvo 75 prosenttia ajasta.

on muitakin tapoja, joilla huono Projektinhallinta voi jouduttaa ohjelmistoprojektin kaatumista. Tutkimus Project Management Institute, Newton Square, Pa., osoitti, että riskienhallinta on vähiten harjoiteltu kaikista projektinhallinnan tieteenaloista kaikilla toimialoilla, ja missään sitä ei käytetä harvemmin kuin IT-alalla. Ilman tehokasta riskienhallintaa ohjelmistokehittäjillä on vain vähän tietoa siitä, mikä voi mennä pieleen, miksi se voi mennä pieleen ja mitä voidaan tehdä riskien poistamiseksi tai lieventämiseksi. Ei ole myöskään olemassa keinoa määrittää, mitkä riskit ovat hyväksyttäviä, mikä puolestaan tekee kaupantekoa koskevista hankepäätöksistä lähes mahdottomia.

huono Projektinhallinta ilmenee monissa muissakin muodoissa, kuten huonossa viestinnässä, joka luo karun ilmapiirin, joka lisää vaihtuvuutta; Ei Investoida henkilöstön koulutukseen eikä arvioida hankkeen edistymistä säännöllisin väliajoin. Mikä tahansa näistä voi auttaa suistamaan ohjelmistoprojektin raiteiltaan.

viimeinen alue, jota tutkijat tutkivat lento-onnettomuuden jälkeen, on organisaation ympäristö. Onko lentoyhtiöllä vahva turvallisuuskulttuuri, vai korostaako se ennen kaikkea lentoaikataulun täyttämistä? Tietotekniikkaprojekteissa avoimuutta, rehellisyyttä, kommunikaatiota ja yhteistyötä arvostava organisaatio löytää ja ratkaisee helpommin virheet riittävän ajoissa, ettei uudistaminen tule ylivoimaiseksi.

jos on olemassa teema, joka kulkee läpi huonojen ohjelmistojen kidutetun historian, se on epäonnistuminen todellisuuden kohtaamisessa. Yhdysvaltain oikeusministeriön ylitarkastaja, ulkopuolinen asiantuntijapaneeli ja muut kertoivat useaan otteeseen FBI: n johtajalle, että VCF-järjestelmä oli määrittelemällään tavalla mahdoton, ja silti projekti jatkui joka tapauksessa. Samanlaisia asenteita oli matkavarausjärjestelmästä, Lontoon pörssin Taurus-järjestelmästä ja FAA: n lennonjohtoprojektista vastaavilla-kaikki viittasivat pelon ja ylimielisyyden ajamiin organisaatiokulttuureihin.

Yhdistyneen kuningaskunnan Valtiontalouden tarkastusviraston tuoreessa raportissa todettiin lukuisia tapauksia, joissa valtion TIETOTEKNIIKKAHANKKEITA suositeltiin olemaan jatkamatta niitä kuitenkaan. Yhdistyneessä kuningaskunnassa on jopa hallituksen osasto, jonka tehtävänä on estää tietoteknisiä epäonnistumisia, mutta kuten raportissa todettiin, yli puolet osaston valvomista virastoista jättää rutiininomaisesti huomiotta sen neuvot. Kutsun tällaista käyttäytymistä irrationaaliseksi projektin eskalaatioksi-kyvyttömyydeksi pysäyttää projekti senkin jälkeen, kun on ilmeistä, että onnistumisen todennäköisyys lähestyy nopeasti Nollaa. Valitettavasti tällainen käytös ei ole mitenkään ainutlaatuista.

loppujen lopuksi suuret ohjelmistovirheet muistuttavat yleensä pahinta mahdollista lentokoneonnettomuutta , jossa lentäjä oli kokematon mutta äärimmäisen harkitsematon, lensi jäämyrskyyn testaamattomalla lentokoneella ja työskenteli lentoyhtiölle, joka antoi tyhjiä lupauksia turvallisuudesta samalla, kun koulutus ja huolto vähenivät. Jos tutkijan raportin lukisi jälkeenpäin, pudistaisi päätään ja kysyisi: ”eikö tällainen rysähdys ollut väistämätön?”

myös ohjelmistoprojektien epäonnistumisten syyt ovat hyvin tunnettuja ja ne on dokumentoitu runsaasti lukemattomissa artikkeleissa, raporteissa ja kirjoissa . Ja kuitenkin epäonnistumiset, lähes epäonnistumiset ja tavallinen vanha huono ohjelmisto vitsaavat meitä edelleen, kun taas käytäntöjä, joiden tiedetään välttävän virheitä, kartetaan. Näyttää siltä, että saada laadukkaita ohjelmistoja ajoissa ja budjetissa ei ole kiireellinen prioriteetti useimmissa organisaatioissa.

se ei näyttänyt olevan Oxford Health Plans Inc.- Trumbullissa., vuonna 1997. Yhtiön automatisoitu laskutusjärjestelmä oli elintärkeä sen tulokselle, ja silti ylemmät johtajat olivat kiinnostuneempia Oxfordin liiketoiminnan laajentamisesta kuin sen varmistamisesta, että sen laskutusjärjestelmä voisi vastata sen nykyisiin tarpeisiin . Silloinkin kun ilmeni ongelmia, kuten laskujen lähettäminen kuukausia myöhässä, johtajat eivät kiinnittäneet juurikaan huomiota. Kun laskutusjärjestelmä käytännössä romahti, yhtiö menetti kymmeniä miljoonia dollareita, ja sen osake putosi 68 dollarista 26 dollariin osakkeelta yhdessä päivässä pyyhkien pois 3,4 miljardin dollarin yritysarvon. Osakkeenomistajat nostivat oikeusjuttuja, ja useat valtion virastot tutkivat yhtiötä, joka sai lopulta 3 miljoonan dollarin sakot sääntörikkomuksista.

huonojen ohjelmistokokemusten polttamat organisaatiotkin näyttävät olevan kykenemättömiä tai haluttomia oppimaan virheistään. Yhdysvaltain puolustusministeriön neuvoa-antava elin U. S. Defense Science Board totesi vuonna 2000 julkaisemassaan raportissa, että puolustusministeriön tilaamat eri tutkimukset olivat antaneet 134 suositusta ohjelmistokehityksen parantamiseksi, mutta suosituksista vain 21 oli toteutettu. Muut 113 olivat yhä voimassa, johtokunta totesi, mutta ne sivuutettiin, vaikka puolustusministeriö valitti huonosta tilasta puolustus-ohjelmistokehityksen!

jotkin organisaatiot välittävät ohjelmistojen laadusta, kuten Bathissa Englannissa toimivan ohjelmistokehitysyritys Praxis High Integrity Systemsin kokemus osoittaa. Praxis vaatii asiakkaitaan sitoutumaan hankkeeseen paitsi taloudellisesti, myös aktiivisina osallistujina tietojärjestelmän luomisessa. Yhtiö käyttää myös valtavasti aikaa asiakkaan vaatimusten ymmärtämiseen ja määrittelyyn, ja se haastaa asiakkaita selittämään, mitä he haluavat ja miksi. Ennen kuin yhtäkään koodiriviä kirjoitetaan, sekä asiakas että Praxis sopivat, mitä halutaan, mikä on toteutettavissa ja mitä riskejä siihen liittyy, kun otetaan huomioon käytettävissä olevat resurssit.

tämän jälkeen Praxis soveltaa tiukkaa kehityskäytäntöä, joka rajoittaa virheiden määrää. Yksi tämän mallin suurista eduista on se, että se suodattaa pois monet mahdolliset asiakkaat, jotka eivät halua ottaa vastuuta it-vaatimusten ilmaisemisesta ja käyttää aikaa ja rahaa niiden toteuttamiseen kunnolla.

jonkinasteinen ohjelmistovika on aina mukanamme. Tarvitsemme todellakin todellisia epäonnistumisia—vältettävissä olevien kömmähdysten sijaan—jatkaaksemme teknistä ja taloudellista kehitystä. Mutta liian monet nykyisistä epäonnistumisista ovat vältettävissä. Ja kun yhteiskuntamme tulee riippuvaiseksi IT-järjestelmistä, jotka ovat yhä suurempia, integroituneempia ja kalliimpia, epäonnistumisen kustannukset voivat nousta katastrofaalisen korkeiksi.

nytkin on mahdollista lyödä vetoa siitä, missä seuraava suuri ohjelmistofiasko tapahtuu. Yksi johtavista ehdokkaistani on IT-järjestelmät, jotka syntyvät Yhdysvaltain hallituksen American Health Information Community-yhteisöstä, julkisen ja yksityisen sektorin yhteistyöstä, joka pyrkii määrittelemään sähköisten potilastietojen datastandardit. Ajatuksena on, että kun standardit on määritelty, IT-järjestelmät rakennetaan niin, että lääketieteen ammattilaiset eri puolilla maata pääsevät potilastietoihin digitaalisesti, jolloin lääkärit, sairaalat, vakuutusyhtiöt ja muut terveydenhuollon asiantuntijat pääsevät välittömästi käsiksi potilaan täydelliseen sairaushistoriaan. Terveydenhuollon asiantuntijat uskovat, että tällainen järjestelmä parantaa potilaiden hoitoa, vähentää kustannuksia arviolta 78 miljardilla dollarilla vuodessa ja vähentää hoitovirheitä säästäen kymmeniätuhansia ihmishenkiä.

mutta tämä lähestymistapa on pelkkä toiveuni, jos ohjelmistokäytännöt ja vikaantumisasteet säilyvät nykyisellään. Jopa kaikkein optimistisimpien arvioiden mukaan sähköisen potilastietojärjestelmän luominen vaatii 10 vuoden ponnistelun ,320 miljardin dollarin kehityskulut ja 20 miljardin dollarin vuotuiset toimintakulut-olettaen, että ei ole epäonnistumisia, ylityksiä, aikatauluvikoja, tietoturvaongelmia tai kehnoja ohjelmistoja. Tämä on tuskin realistinen skenaario, varsinkin koska useimmat IT-asiantuntijat pitävät lääketieteellinen yhteisö on vähiten tietokone-taju kaikista ammatillisista yrityksistä.

potilaat ja veronmaksajat joutuvat viime kädessä maksamaan hinnan tämänkaltaisten hömpötysten kehittämisestä tai epäonnistumisesta. Nykypäivän TIETOTEKNIIKKAKÄYTÄNNÖT huomioon ottaen epäonnistuminen on selvä mahdollisuus, ja se olisi ennennäkemättömän suuri menetys. Mutta sitten eri puolilla maailmaa maat harkitsevat tai ovat jo toteuttamassa monia samankokoisia ja-vaikutteisia aloitteita-muun muassa ilmailussa, kansallisessa turvallisuudessa ja armeijassa.

kuten sähkö, vesi, liikenne ja muut infrastruktuurimme kriittiset osat, siitä on nopeasti tulossa olennainen osa päivittäistä olemassaoloamme. Laajamittaisesta IT-epäonnistumisesta tulee muutamassa vuosikymmenessä muutakin kuin kallis haitta: se vaarantaa elämäntapamme. Koska ei ole sellaisia toimialanlaajuisia muutoksia, jotka lieventäisivät ohjelmistovikoja, kuinka suuren osan tulevaisuudestamme olemme valmiita panostamaan näihin suunnattoman kalliisiin ja monimutkaisiin järjestelmiin?

osaamme jo tehdä ohjelmistoja hyvin. Voi olla aika toimia sen mukaan, mitä tiedämme.