Upload
gary
View
54
Download
0
Embed Size (px)
DESCRIPTION
Ohjelmistotekniikka Projektinhallinta, osa 2. Kevät 2002 Päivi Ovaska LTKK/Tite. Työ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 - PowerPoint PPT Presentation
Citation preview
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ä.