Mistä kehitysprojektien ylimääräiset kustannukset syntyvät?

Mistä kehitysprojektien ylimääräinen työ ja kustannus syntyvät?

Pari viikkoa sitten eräs tuttu, kokenut johtaja, laskeskeli ääneen: ”WMS-projektin budjetti on 1 milj. Euroa, eli hmmm… 2,3 milj. Euroa lienee realistinen arvio.” Hän oletti kylmän viileästi projektin ylittävän budjetin kaksinkertaisesti ennen kuin projekti oli suunniteltukaan. Kun kysyin asiasta, hän vain totesi olankohautuksella, että näin ne projektit vaan aina menevät..

Kaikki olemme kuulleet näitä lukuja ja tilastoja:

  • 17% of large IT projects go so badly that they can threaten the very existence of the company!
  • One in six IP projects has an average cost overrun of 200% and a schedule overrun of 70%.
  • 75% of IT project leaders believe their projects are “doomed from the start”.

Näille luvuille nyökytellen naureskellaan. Lukuihin on turruttu, ja monelle on jäänyt hällä väliä- fiilis. ”Joo, näinhän ne projektit aina menee…” Mutta jokainen hukattu Euro on pois kassasta ja jokainen työtunti on pois tärkeästä tekemisestä.

Pilviä.jpg

Oletko koskaan pysähtynyt miettimään, mitä kehitysprojekti maksaa yrityksellesi?

Erityisesti silloin, jos projekti ei mene ihan putkeen.

Otetaan esimerkiksi 18kk ERP-projekti. Projektissa työskentelee eri vaiheissa 15-25 henkilöä jotka käyttävät suuren osan (80%) työajastaan projektiin. Projektin resurssin keskimääräinen tuntikustannus on 40€/h ja laskennallinen työaika on 7,5h/pvä

Jos projekti menee kaksi kuukautta pitkäksi, suora kustannus pelkästä työstä voi olla 258 000€.

Mistä ylimääräinen työ ja kustannukset syntyvät?

Ongelmat juontavat juurensa usein puutteelliseen projektin johtamiseen ja suunnitteluun, ja ne realisoituvat usein hyväksymistestausvaiheessa. Ennen hyväksymistestausta ongelmia voidaan vähätellä, niitä voidaan lakaista maton alle ja toivoa, että kaikki järjestyy.

Kaikkein kalleinta on olla puuttumatta projektin ongelmiin välittömästi

Jos ollaan uskottu, että asiat menevät hyvin, ilman todellista tietoa, ajetaan ennemmin tai myöhemmin karille. Tässä on esimerkki elävästä elämästä, kun hyväksymistestausta edeltäviä vaiheita ei ole tehty kunnolla:

  • Toteutus ei ole täysin valmis. ”Enää raportit ja tulosteet tekemättä. Nämä eivät estä hyväksymistestauksen aloittamista.” (+ 40 h työtä)

  • Noin 50 virhettä avoinna. ”Enää pari kriittistä.” Virheiden korjaus ja uudelleentestaus paljastavat uusia virheitä. (+ 155 h työtä)

  • Hyväksymistestauksen ensimmäiset testit eivät ole luotettavia, koska niiden jälkeen on tehty yli 100 muutosta järjestelmään. Uudelleen testataan. (+ 50 h työtä)

  • Suunniteltuja koulutuksia ei voitu suorittaa. Koulutusympäristö ei ollutkaan valmis. (+ 20 h työtä)

  • Hyväksymistestauksen aloitusta ei tehty huolella. Testauksessa löydetään turhia virheitä.  (+ 20 h työtä)

Sait juuri 305 tuntia suunnittelematonta työtä! Käyttöönottoa joudutaan siirtämään kuukaudella

Hyväksymistestausvaiheessa on kaiken lisäksi aina paineita siirtyä tuotantoon. Joudutaan tasapainoilemaan kahden huonon vaihtoehdon välillä. Toisaalta projektin jatkaminen maksaa 129 000€/kk ja toisaalta tuotantoon meneminen puolivalmiilla ohjelmistolla on valtava riski liiketoiminnalle.

GoNoGo.png

Kun huomioit nämä neljä pointtia, olet jo lähellä onnistumista

1) Ensimmäinen asia, mitä tarvitaan, on yhteinen, realistinen projektisuunnitelma, jonka toteutumista seurataan reaaliajassa. Tämä mahdollistaa projektin johtamisen ja proaktiivisen reagoinnin ongelmiin.

2) Seuraavaksi tarvitaan tapa tehdä määrittelyt kunnolla. Niin, että kaikki ymmärtävät tarkalleen, mitä projekti on tuottamassa, ja mikä on muutosten vaikutus liiketoimintaan.

3) Kolmanneksi tarvitaan selkeä muutoksenhallinnan prosessi, joka päästää vain projektin kannalta olennaiset muutokset projektin toteutukseen.

4) Neljänneksi tarvitaan hyvät käytännöt ja prosessit testaukseen ja virheiden korjaukseen, jotta virheiden korjaus ei muodosta pullonkaulaa, eikä näkyvyys ratkaisun laatuun katoa.

Tässä postauksessa en ehdi paneutumaan ratkaisuihin syvemmin, mutta tule mukaan Quality Gate Best Practice- koulutuswebinaariin. Koulutuksen jälkeen tiedät, miten onnistut projektissasi aikataulussa ja budjetissa.


Quality Gate Best Practice -mallilla varmistetaan, että kehitysprojekti pysyy aikataulussa ja budjetissa

- Satojen kehitysprojektien kokemuksella

Ilmoittaudu koulutukseen!

Ilmainen koulutus

Päivää
Tuntia
Minuuttia
Sekuntia

Keskiviikkona, 3. toukokuuta

klo 14.00

ProjectTOP Quality Gate
Toteuta kehitysprojektit laadukkaammin

Tehokkaampaa testaamista, 70% vähemmän sähköposteja ja reaaliaikainen raportointi


Lue lisää

Roadmap on helppokäyttöinen ohjelmisto kehitysprojekteille

Suunnittele ja toteuta helposti kaikkein haastavimmatkin kehitysprojektit


Lue lisää