OhjelmistotekniikkaOhjelmistotekniikkaProjektinhallinta, osa 2Projektinhallinta, osa 2

Kevät 2002

Päivi Ovaska

LTKK/Tite

Työmäärien arviointiTyömäärien arviointi

Edellytys aikataulun ja budjetin laatimiselle.Vaikeaa mm. koska

– ihmisten työn tuottavuus vaihtelee (edes 10-20 -kertaiset erot eivät ole harvinaisia

– työn vaativuus vaikuttaa tuottavuuteen (kerroin 1-20)

– yllättävät ongelmat eivät ole harvinaisia. – tuotteen kokoa on vaikea arvata

Koon arviointi Koon arviointi •Montako koodiriviä

•Pascal-kääntäjä•Unix-shell•Assembler-kääntäjä•Reaaliaika-KJ (hissi, GSM-puhelin, televisio)•Yleiskäyttöinen KJ.

Menetelmiä työmäärien Menetelmiä työmäärien arviointiinarviointiin

Kolmen arvion malliCocomo (Constructive cost model)FPA (function point analysis)Analogia (kokemukseen perustuva arvaus)Historiatiedon merkitys!Murheellinen paradoksi: kaupan saa usein

se joka arvioi työmäärän eniten väärin.

Kolmen arvion malliKolmen arvion malli

Maximum likelihood -estimaati

p+4a+o / 6 , missä p= pessimistinen arvio,

a=todennäköinen arvio,

o=optimistinen arvio

esim. jos projektin työmääräksi arvioidaan optimistisesti 10 viikkoa, todennäköisenä pidetään 12 viikkoa ja pessimistinen arvio on 20 viikkoa, saadaan projektin kestoksi 13 viikkoa

CocomoCocomo

Barry Boehmin laajoihin tutkimuksiin ohjelmistotyön tuottavuutten vaikuttavista tekijöistä perustuva menetelmät

osoitteesta http://sunset.usc.edu/research/COCOMOII löytyy kaikenlaista materiaalia kyseisestä mallista

KLOC (KLinesOfCode)-> COCOMO->työpanos MM (htkk) ja kalenteriaika T(kk)

Cocomon kertoimet kansainvälisesti kerättyä tilastotietoa kattaen koko projektin vaatimusmäärittelystä testaukseen, kehittyneemmässä versiossa (Intermediate, Detailed) voidaan painottaa erilaisilla vaikeusasteilla

Basic CocomoBasic Cocomo Helppo tehtävä

MM=2.4*KLOC1.05

Tdev=2.5*MM0.38

Normaali tehtäväMM=3.0*KLOC1.12

Tdev=2.5*MM0.35

Vaikea tehtäväMM=3.6*KLOC1.20

Tdev=2.5*MM0.32

Esimerkkiohjelmisto, jossa tuotetaan palvelu matkapuhelinverkkoon, 35 000 riviä koodia :jos luokitellaan normaaliksi, KLOC=35-> MM=160 htkk, T=15 kkjos luokitellaan vaikeaksi, KLOC=35 ->MM=257htkk, T= 15 kk

*) Mallissa työmäärä kasvaa ohjelmiston koon funktiona, mutta tuottavuus ei juurikaan laske projektin koon kasvaessa

Intermediate CocomoIntermediate Cocomo Projektin vaativuutta arvioidaan basic mallin karkean vaikeusastejaottelun lisäksi

tuotetta, henkilöstöä, kehitysympäristöä ja projektia kuvaavien kustannuskertoimien avulla. Kukin näistä tekijöistä arvioidaan 6-arvoisella asteikolla: hyvin alhainen, alhainen, normaali, korkea, hyvin korkea ja erittäin korkea

Normaali hommanMM=3.0*KLOC1.12

Tdev=2.5*MM0.35

Vaikea hommanMM=3.6*KLOC1.20

Tdev=2.5*MM0.32

Esimerkkiohjelmisto: Seuraavat tekijät otetaan huomioon:tuotteen monimutkaisuus korkea 1.17, sovellusalueen tuntemus alhainen 1.13, -> tällöin

normaalin homman MM=1.13*1.17*160=211 htkk, T=16kk ja vaikean homman MM=1.13*1.17*257=339 htkk, T=16 kk

Cocomo mallin arviointiaCocomo mallin arviointia

Käytännössä on todettu tuottavan työmääräarviot noin 20% tarkkuudella

Mallia on erityisesti hyvä käyttää projektien jälkiarviointiin vertaamalla mallin ennustamaa tulosta projektin toteumaan

On olemassa vielä Detailed Cocomo, jossa käytetään erilaisia kustannuskertoimia ohjelmiston eri osissa

Mallin toteuttavia ohjelmistoja on kaupallisesti saatavissa, arvioiden perustanan yrityskohtaisesti kalibroidut (historiatieto) tietokannat

Kustannuskertoimet

Very Low Normal Extra HighProduct VL L N H VH EH

Required Software Reliability 0.82 0.92 1.00 1.10 1.26Database Size 0.90 1.00 1.14 1.28

Documentation Match to Lifecycle Needs 0.81 0.91 1.00 1.11 1.23Product Complexity 0.73 0.87 1.00 1.17 1.34 1.74

Required Reusability 0.95 1.00 1.07 1.15 1.24Platform 1.00

Execution Time Constraint 1.00 1.11 1.29 1.63Main Storage Constraint 1.00 1.05 1.17 1.46

Platform Volatility 0.87 1.00 1.15 1.30Personnel 1.00

Analyst Capability 1.42 1.19 1.00 0.85 0.71Applications Experience 1.22 1.10 1.00 0.88 0.81

Programmer Capability 1.34 1.15 1.00 0.88 0.76Platform Experience 1.19 1.09 1.00 0.91 0.85

Language and Tool Experience 1.20 1.09 1.00 0.91 0.84Personnel Continuity 1.29 1.12 1.00 0.90 0.81

Project 1.00Use of Software Tools 1.17 1.09 1.00 0.90 0.78Multisite Development 1.22 1.09 1.00 0.93 0.86 0.80

Required Development Schedule 1.43 1.14 1.00 1.00 1.00

alusta

Toimintopisteanalyysi Toimintopisteanalyysi (Function Point Analysis, (Function Point Analysis,

FPA)FPA) Tarkastelee ohjelman tietojenkäsittelyn laajuutta ja

teknistä monimutkaisuutta Tietojenkäsittelyn laajuusi UFP Tekninen kompleksisuus TCF Toimintopisteet FP=UFP*TCF Toimintopisteet muutetaan tilastollisen tiedon

mukaan tietyillä kertoimilla työmääriksi Auttaa myös sovelluksen toiminnallisuuden ja

kompleksisuuden läpikäynnissä

                                                                                          

                           

Slide 13 of 18

Työmäärien Työmäärien arviointimenetelmistäarviointimenetelmistä

Yksinkertaisimmat menetelmät perustuvat arvaukseen, joko projektin tekijöiden, asiantuntijoiden tai esimerkiksi kilpailijan antamaan tarjoukseen

Kehittyneemmät menetelmät perustuvat historiatietojen hyväksikäyttöön

Kannattaa käyttä useampia menetelmiä paremman lopputuloksen saamiseksi

Arvioista ei tulisi tehdä kovin tiukkoja, sillä arviot ovat helposti liian optimistisia

Riskien hallintaRiskien hallinta Riskien tunnistaminen Riskien analysointi Riskien priorisointi Riskienhallinnan suunnitelu Riskien toteutumisen seuranta ja hallinta

– riskien ennakointi (ennusmerkit ??) – riskien eliminointi (poistaminen, torjunta ennakolta)– riskien väistäminen (jos riski uhkaa)– seurausten minimointi (jos riski on toteutunut).

Riskien luokittelu– asiakkaaseen liittyvät– tekniikkaan liittyvät– omaan henkilöstöön liittyvät riskit.

Top risks, USATop risks, USA Avainhenkilö vaihtaa työpaikkaa Epärealistiset aikataulut ja budjetit Kehitetään ohjelmistoon vääriä toimintoja ja turhia

piirteitä Huono käyttöliittymä Muutokset määrittelyssä = "liikkuva maali" Ongelmat muualta hankituissa komponenteissa ja/tai

palveluissa Tekniset ongelmat (suoritusteho, reaaliaikaisuus,

muistitila).

Top risks, LappeenrantaTop risks, Lappeenranta MITEN

– aikataulu petti– kustannukset ylittyivät– asiakas tyytymätön tuotteeseen (ei vastaa tavoitteita,

liiketaloudelliset menetykset) jälkihoidon työmäärä valtava.

MIKSI ? – työmääräarvio virheellinen– määrittely puutteellinen– liian suuri projekti– asiakkaan/toimittajan asiantuntemattomuus– suunnittelematon käyttöönotto– henkilöstön vaihtuvuus– huono projektipäällikkö– ongelmat työvälineissä/laitteissa.

Critical (anti) success factors Critical (anti) success factors in software projects in software projects

(J. S. Reel, IEEE Software May/June 1999) 1. projektinvetäjä ei ymmärrä asiakasvaatimuksia 2. projektin laajuutta ei ole määritelty kunnolla 3. muutostenhallinta on puutteellista 4. teknologiassa tapahtuu muutoksia 5. asiakasvaatimukset muuttuvat 6. aikataulu on epärealistinen 7. käyttäjien vastustus 8. tuki projektille loppuu 9. projektiryhmässä ei ole tarvittavaa ammattitaitoa 10. ei oteta oppia toimivista käytännöistä ja tehdyistä virheistä.

Johtopäätös: Projektien ongelmat eivät niinkään ole teknisiä,vaan liittyvät projektinhallintaan, ihmisten johtamiseen, ryhmätyöhön,kommunikointiin, asiakastarpeiden ymmärtämiseen…

HallintaHallinta

Projektipäällikkö ja ohjausryhmä. Riskit projektisuunnitelmaan tai erilliseen

riskienhallintasuunnitelmaan. Jokaisesta riskistä

– Miksi riski on tärkeä.– Miten hallitaan (kuka vastaa, havaitseminen, reagointi)

ja milloin hallintaan liittyviä asioita tehdään.– Miten toteutumistodennäköisyys minimoidaan.– "Plan B" toteutumisen varalle.

Mikä ohjelmistotyössä Mikä ohjelmistotyössä maksaa?maksaa?

Työvoimakustannukset (palkat, henkilösivukulut), yleensä 50-70% kaikesta

yleiskustannukset (tilojen vuokra, konttorikustannukset, puhelin, posti,...)

alihankinta kalusto- ja tilajärjestelyt koulutus palkitseminen projektiryhmän huolto, edustus (syöttäminen, juottaminen, saunotus,

seminaarit korpihotellissa) matkakustannukset kirjallisuus yms. tiedonhankinta laitteet pääomakustannukset katetavoite…

Ihmistyön kustannustekijätIhmistyön kustannustekijät palkka (kk-palkka, ylityöt, palkkiot) pakolliset henkilösivukulut (lomakorvaukset,

sosiaaliturva, eläke- yms. vakuutukset, palkalliset sairauspäivät, arkipyhät, yhteensä 50-60% palkasta)

vapaaehtoiset henkilösivukulut (ruoka, auto, terveydenhoito, virkistys...)

koulutus rekrytointi (voi olla merkittäväkin, esimerkiksi 6-

10 kk palkka).

Eräs karkea hinta-arvioEräs karkea hinta-arvioPerustuntihinta: laskutettavan työtunnin

hinta yrityksessä, – nyrkkisääntö: Keskimääräinen palkka pitäisi

saada laskutettua perustuntihinnalla 2,5-4 kertaisena.

Projektin hinnoittelu saadaan summaamalla– aika-arvio * perustuntihinta (*hhh-vakio)1

– projektiin ulkoa ostettavat laitteet, ohjelmistot, laitteet

– mahdolliset muut kulut…

1) hhh-vakio = hiha, hanska ja hattu, voi joskus olla ykköstä pienempikin.

Perustuntihinnan Perustuntihinnan määrääminenmäärääminen

Perustuntihinta saadaan jakamalla kustannustekijöiden summa laskutuskelpoisten tuntien kokonaismäärällä.

Laskutuskelpoisten tuntien määrä saadaan vähentämällä kaikesta työajasta (n. 225 päivää/henkilö vuodessa, eli n. 1700 tuntia)– johtajien, sihteerien yms. työaika sekä– laskutettavaa työtä tekevien henkilöiden työpanoksesta

esimerkiksi 25% (perustuu kokemukseen).

Summittainen esimerkkiSummittainen esimerkki 10 hengen ohjelmistotalo Päätoiminen johtaja, ei sihteeriä Muut tekevät laskutettavaa työtä 75% työajasta Vaihtuvuus n. 1 hlö / vuosi Palkat ja henkilösivukustannukset 1.6 * 15 kmk *

12 kk Otetaan huomioon vuokrat, laitteiden poistot,

leasing-autot, konttorikustannukset jne... kertomalla summa 1.5:llä =>> menopuolella n. 4500 kmk.

……summittainen esimerkkisummittainen esimerkki Laskutettavia tunteja voi arvioida tulevan vuoden

aikana yhdeksälle työtekijälle. Vaihtuvuuden ja sairaslomien yms. huomioon

ottamiseksi käytetään kertoimena kuitenkin lukua 8: 8*1700*0.75 = noin 10000 laskutettavaa tuntia.

Työtunnin hinnaksi tulee siis noin 450 mk/tunti ja päivähinnaksi 3600 mk.

esimerkiksi 3 KDSI kokoisen ohjelman teettäminen tässä firmassa maksaisi siis suunnilleen: 16*22*8*450 = noin 1300 kmk !!!

•Konsulttityön tuntiveloitus on tyypillisesti välillä 300 - 800 mk.

ProjektinhallintatyökalutProjektinhallintatyökalut

Perustietojen hallinta.– kalenteri, jossa vapaapäivät (sekä henkilöille)

että muille resursseille)– resurssit ja kustannukset (henkilöt, laitteet ...)– aikataulun laatiminen.

Edut ja haitat.

Moniprojektihallinta?

……projektinhallintatyökalutprojektinhallintatyökalut Syötetään tehtävät ja niiden työmäärät. Määritetään tehtävien riippuvuudet. Kerrotaan kuka/ketkä tehtävät suorittavat. Aikataulua muokataan kunnes resursseja kuormitetaan

tasaisesti ja kokonaiskustannukset ovat mahdollisimman pienet.

Tuloksena saadaan aikataulut ja kustannusarviot. Valmis aikataulu (baseline) voidaan jäädyttää. Järjestelmaan voidaan tallettaa toteutumatietoja, joita

voidaan verrata suunniteltuun (projektin seuranta ja raportointi).

Hyödyt ja haitatHyödyt ja haitat

paperinpyöritys väheneemahdollistaa kokeilut (hylkää tehdyt

muutokset)helpompi ylläpitäävirheiden mahdollisuus vähenee mahdollistaa kokemustietojen keruun

Kokouskäytäntöjen Kokouskäytäntöjen ryhdistäminen, tulos ryhdistäminen, tulos

Pahimmat syyt tehottomiin kokouksiin (% vastaajista mainitsi);

1. kokoukseen ei oltu valmistauduttu kunnolla (85 %)

2. keskustelu harhautui asiasta (77 %)

3. kokouksen olisi voinut viedä läpi lyhyemmässä ajassa (68 %)

4. joku poistui ennen kokouksen päättymistä (60 %)

5. joku poistui välillä hoitamaan asioitaan (57 %)

6. joku ulkopuolinen häiritsi kokousta (40 %)

7. kokouksen tarkoitus ja tavoitteet eivät olleet selvillä (40 %)

8. kokous alkoi myöhässä (31 %)

9. kaikkia asioita ei ehditty käsittelemään (31 %)

10. kokouksen tekemiä päätöksiä ei ole pantu toimeen (31 %).

Kokouskäytäntöjen Kokouskäytäntöjen ryhdistäminenryhdistäminen

Onko kokous välttämätön, voidaanko asia hoitaa muuten Optimoi osallistujien määrä Mieti palaverin tavoite, tarkoitus ja käsiteltävät asiat

etukäteen Valitse sopiva aika ja paikka Varmista että kokoukseen on valmistauduttu Tiedota ajoissa, aloita ajoissa, lopeta ajoissa Tärkeä asiat esityslistan alkuun Varmista, että joku tekee muistion Varmista, että päätöksentekovalta on kunnossa Valitse asioiden käsittelytapa tavoitteen mukaan

(ideointipalaveri vs. päätöksenteko)

… … kokouskäytäntöjen kokouskäytäntöjen ryhdistäminen ryhdistäminen

Tee yhteenvetoja: aluksi, lopuksi, tarvittaessa välilläkin Pysy asiassa, keskeytä pitkät kaksinpuhelut Huolehdi tavoitteen saavuttamisesta Varmista osallistujien sitoutuminen päätöksiin, esitä tarvittaessa

provosoivia kysymyksiä. Varmista päätösten toteutumisen seuranta Kertaa lopuksi johtopäätökset ja toimeksiannot sekä kirjaa ne

ylös Pidä kokous tilassa, jossa ei ole tuoleja ("stand-up meeting") Jokainen kännykkään saapunut puhelu aiheuttaa 1 euron maksun

kahvikassaan Pullia yksi vähemman kuin osallistujia?

IdeointipalaveritIdeointipalaverit Generointi

– yritetään generoida mahdollisimman paljon ideoita– rikotaan rajoja ja totunnaisia menettelytapoja– ei kritiikkiä -- älä ammu "mahdottomiakaan" ideoita alas– usein on hyvä, jos ideat eivät "personoidu": kirjallinen aivoriihi,

ideakävely, "innotiimi". Arviointi

– ideoiden ryhmittely ja näkyville asettaminen– hyvät & huonot puolet– vastaesimerkki ei välttämättä tee ideaa käyttökelvottomaksi– pisteyttäminen toisinaan tehokas keino vaihtoehtojen valitsemiseksi– jatkojalostus.

Ihmisten (ja itsensä) Ihmisten (ja itsensä) johtaminenjohtaminen

Yksilön ja ryhmän tavoitteiden tulee olla samansuuntaisia Ihmiset tarvitsevat onnistumisen kokemuksia Johtaminen on helppoa niin kauan kun asiat menevät hyvin Asiat, joita seurataan, tehdään hyvin Asiat, joista palkitaan, tehdään hyvin Pelisääntöjen pitää olla vakiintuneita ja kaikkien tiedossa Avoimuus uusille asioille -- etsi positiiviset puolet ensin Kuuntele muita, ole aidosti kiinnostunut Ihmiset eivät kerro mielellään huonoja uutisia Sitoutuminen yhteisiin päätöksiin (vaikka olisikin eri mieltä) Erilaisuuden salliminen Turhan muodollisuuden ja byrokratian karttaminen Leadership vs. Management: molempien oltava kunnossa Ihmiset tärkeämpiä kuin tekniikka Muista positiivinen palaute (se ei maksa mitään) Pohdi (epä)onnistumisen syitä.

Itsensä johtaminenItsensä johtaminen Seuraa ajankäyttöä ainakin ajoittain tarkasti, tulevaisuuden suunnittelu

helpottuu Varaa kalenteriin aikaa pikku hommille ja yllättäville tehtäville Realismi: kaikkia tehtäviä ei ehdi tekemään Priorisoi tehtävät; valitse tehtävät prioriteettijärjesteyksessä, älä

mielihyväohjautuvasti -- yritä tehdä keljut hommat ensin Minimoi keskeytykset, lyhyimpääkin hukkautuu 15 min Estä keskeytykset, sulje ovi, pane lappu luukulle Tee mahdollisimman pitkään samaa asiaa, älä hypi tehtävästä toiseen Aloita aikaisemmin Delegoi Pysähdy välillä miettimään, mitä voit oppia lähihistoriasta Miten hallita stressiä?

Kansanviisauksia 1Kansanviisauksia 1

On tyhmää toistaa samoja virheitä (tai toisten virheitä) Valitse projektiin mahdollisimman harvoja ja mahdollisimman hyviä

tekijöitä jotka kykenevät kiinteään yhteistoimintaan Projektin tarkempi suunnittelu on tehtävä uudestaan vähintään kahden

kuukauden välein, koska vain tällä aikamarginaalilla tehtävät voidaan tuntea etukäteen tarkasti

Asiat joita seurataan (palkitaan) tulevat tehdyiksi Projektin osallistujat osallistuvat myös työmääräarvioiden tekemiseen Älä esitä (edes) alustavaa aikatauluarviota liian aikaisin, tai tuo

ainakin selkeästi esille mihin arvio perustuu, arvion epävarmuustekijät ja se, että arvioon ei voi mitenkään sitoutua.

Kansanviisauksia 2Kansanviisauksia 2

Käytä työmääräarvioijina aina useampia kuin yhtä henkilöä Älä hyväksy muutoksia ja lisäyksiä määrittelyyn projektin aikana

ilman, että niiden vaikutus aikatauluun ja kustannuksiin arvioidaan ja tehdään selväksi kaikille osapuolille

Projektiin osallistuvat seuraavat itse omaa ajankäyttöään Seuraa toteutumatietoja, päivitä projektisuunnitelmaa Tee jälkiarviointi: mitä opit projektista (loppuraportti) Palkitse hyvät suoritukset (aika-arvioiden alitukset). Mieti mitä

palkitset (toivottu suoritus). "Tee tärkeät asiat ennen kiireellisiä." "Kahvipöytä on firman tärkein projektinhallinnan apuväline."

Kansanviisauksia 3 Kansanviisauksia 3

Aina ei kannata paljastaa todellisia aikataulutavoitteita Julkistetut tavoitteet voi asettaa esimerkiksi siten, että niistä 50% myöhästynyt projekti ei todellisuudessa ole täysin epäonnistunut

Projekti täyttää aina sille varatun ajan, varataanpa aikaa sitten kuinka paljon hyvänsä

Jos projektinhallinta on liian byrokraattinen, töitä aletaan tehdä salaa projektihallinnan ulottumattomissa

Raportointi on määriteltävä projektisuunnitelmassa riittävän formaaliksi, muuten se unohtuu projektikiireiden keskellä

80% maailman ongelmista johtuu pohjimmiltaan puutteellisesta kommunikoinnista. Lisää projektisuunnitelmaan suunnitelma tiedottamisesta sekä projektin sisällä että projektin ja ulkomaailman välillä: kuka kertoo, mitä, kenelle ja kuinka usein.

Tiedottaminen on yksisuuntaista, viestintä kaksisuuntaista.

Syitä erään suuren projektin Syitä erään suuren projektin epäonnistumiseen 1/2epäonnistumiseen 1/2

Järjestelmän ominaisuuksia ja kokoa ei pystytty mitenkään arvioimaan suunnitteluvaiheessa

Järjestelmästä tuli huomattavasti suurempi kuin oli alunperin suunniteltu

Järjestelmään tehtiin projektin aikana jatkuvasti muutoksia: uusia piirteitä lisättiin ja vanhoja muutettiin

Koordinointi osaprojektien välillä oli lähes olematonta

Projektin loppupuolella vallitsi tavaton kiire.

Syitä erään suuren projektin Syitä erään suuren projektin epäonnistumiseen 2/2epäonnistumiseen 2/2

Projektin loppupuolella projektipäällikkö sairastui ja hänen tilalleen tuli verraten kokematon henkilö

Järjestelmässä oli useita piirteitä, joita ei oltu kokeiltu aikaisemmissa vastaavissa tuotteissa

Järjestelmätestauksessa todettiin, että järjestelmä on liian epästabiili käyttöönotettavaksi. Projekti oli kuitenkin jo myöhässä ja paine asiakkaan taholta oli kova, joten järjestelmä otettiin tästä huolimatta käyttöön

Jälkikäteen pystyttiin arvioimaan, että järjestelmän rakenne oli sellainen, ettei se olisi mitenkään voinut toimia: ... paarlastia olisi tarvittu niin paljon, että alemmat tykkiportit olisivat joutuneet veden alle.

Lähde; Curt Borgenstam: Why the Wasa Capsized.

Tekevälle sattuu...Tekevälle sattuu... Verohallitus aloitti syyskuussa 1988 ATK-projektin

verotusohjelmistojen uudistamiseksi. Vanhat FAS-kielellä kirjoitetut ohjelmistot päätettiin korvata kokonaan uusilla

Projekti oli erittäin laaja. Parhaimmillaan projektin kimpussa hääräsi yli 100 henkeä

Kesäkuussa 1989 määrittelyvaihe oli valmis (muutamalla kuukaudella myöhästyneenä)

Marraskuussa 1989 toteutusvaihe alkoi, mutta määrittelyt osoittautuivat epätäsmällisiksi.

Tammikuussa 1990 tekijät havaitsivat aikataulun epärealistiseksi, mutta eivät raportoineet tästä riittävän äänekkäästi: edes johtoryhmä ei saanut tietoa tästä

Huhtikuussa 1990 projektin piti päättyä, mutta loppua ei ollut näkyvissä.

……tapaus verohallitustapaus verohallitus Kesäkuussa 1990 projektista tuli suosittu uutisaihe Joulukuussa 1990 viimeiset osat laskentaohjelmistosta valmistuivat Huhtikuu 1991: vuoden 1989 verotus valmistuu? Myös vuoden 1990 verotus viivästyi

SYYT:– epärealistinen aikataulu– paloittelu ja vaiheistus unohtui– riskejä ei analysoitu– poikkeamista ei raportoitu tai niitä ei havaittu– "uudet" työkalut: Cobol ja Oracle– Oracle-konsultit eivät tunteneet sovellusalueen kieltä.