Faktat tiskiin: maailmanlaajuisesti lähes joka kolmas ohjelmistoprojekti epäonnistuu. The Standish Groupin tekemän tutkimuksen mukaan noin 16 % ohjelmistoprojekteista onnistuu siten, että ohjelmistokehityksen lopputulos on suunnitellun kaltainen, ja projekti pysyy sekä aikataulussa että budjetissa. Hieman reilu 52 % projekteista myöhästyy aikataulusta, ylittää budjetin tai lopputulos, joka kuitenkin toimii, ei vastaa alkuperäistä suunnitelmaa. Loput, eli noin 32 % ohjelmistoprojekteista epäonnistuu siten, että ne keskeytetään jossakin kohtaa projektin elinkaarta.
Tässä blogitekstissä käymme läpi yleisimpiä tekijöitä, jotka aiheuttavat ohjelmistoprojektin epäonnistumisen ja miten näitä haasteita voidaan minimoida.
Tutkimuksessa on mukana laaja otanta suuria ohjelmistoalan toimijoita, mutta projektien onnistumiseen vaikuttaa samat lainalaisuudet myös pienemmissä ohjelmistoyrityksissä. Yleisimpiä syitä ohjelmistoprojektin epäonnistumiselle ovat seuraavat:
Edellä mainitut asiat ovat usein haasteina läsnä myös meidän toteuttamissa ohjelmistoprojekteissa, vaikka en yhtään täysin epäonnistunutta projektia muistakaan. Miten haasteiden vaikutuksia voidaan minimoida? Tässä blogissa pohdin neljää ensimmäistä, yleisimmin projektin epäonnistumisen aiheuttavaa aihetta.
Alussa oli suo kuokka ja Jussi – ohjelmistoprojekteissa olisi syytä olla selkeä visio, eli selvyys siitä mitä ollaan tekemässä, kenelle ja miksi? Mitä asioita toteutettava ohjelmisto tehostaa, tai mitä ongelmia se ratkaisee? Mikä on ohjelmiston arvo kilpailijoihin nähden? Miten ohjelmiston toimivuutta ja tuottavuutta mitataan? Visio tulee olla selvillä tottakai asiakkaalla itsellään, mutta myös koko toteutustiimillä.
Ilman selkeää visiota toteutuksessa keskitytään helposti vain ohjelmiston yksittäisten toimintojen toteuttamiseen, ilman linkitystä loppukäyttäjään ja erilaisiin käyttötapauksiin. Selkeä visio, kokonaisuuden ja tulevaisuuden hahmottaminen tehostaa myös käytännön työtä pidemmässä mittakaavassa – ohjelmistokomponenteista voidaan tehdä esimerkiksi suoraan yhteensopivia tulevaisuuden kehitystoimien kanssa. Näin jatkossa säästyy sekä aikaa että rahaa.
Ohjelmistojen toteuttamisessa on tavallista, että alkuperäisiä määrittelyjä muokataan projektin aikana. Ketterässä ohjelmistokehitysmallissa se on jopa aivan normaali toimintatapa. Riski siihen, että projekti lähtee niin sanotusti lapasesta, on olemassa, jos vaatimusmäärittely on alunperin riittämätön tai se on tehty liian yleisellä tasolla. Täydellisen vaatimusmäärittelyn tekeminen ennen projektia on kuitenkin työlästä, eikä välttämättä edes järkevää.
Silti vähintään päälinjat toiminnallisista vaatimuksista (kuvaus ohjelmiston ominaisuuksista ja toiminnoista) sekä laadullisista vaatimuksista (kuvaus siitä miten ohjelman tulee toimia) tulisi olla selvät. Määrittelyvaiheessa käyttökelpoisia työkaluja ovat esimerkiksi
Ohjelmiston toiminnallisten ja laadullisten määrittelyiden perusteella voidaan laskea arvio projektiin kuluvasta toteutusajasta, joka puolestaan voidaan muuntaa projektin kustannuksiksi. Yksi osa vaatimusmäärittelyä onkin huomioida myös resurssivaatimukset, eli se kuinka paljon projektiin on ylipäätään mahdollista käyttää rahaa ja aikaa. Käytettävissä oleva budjetti olisi hyvä olla tiedossa heti alusta alkaen, sillä usein se vaikuttaa toteutettaviin toiminnallisuuksiin, toteutustapoihin ja aikataulutukseen.
On punnittava, mitkä ovat kriittisen tärkeitä vaatimuksia ja mitkä voidaan jättää vaikka kokonaan pois. Kaikkia ohjelmiston toiminnallisuuksia ei välttämättä ole pakko toteuttaa heti, ja kokonaisuuden voi jakaa usein pidemmälle aikajänteelle. Tällöin myös ohjelmiston kustannukset jakaantuvat tasaisemmin pidemmälle ajalle.
Avoin viestintä suunnittelussa, kehityksessä ja tuotantoon viennissä on onnistuneessa ohjelmistoprojektissa ensiarvoisen tärkeää. Kommunikaatiokatkokset ja viestinnässä tapahtuvat väärinkäsitykset ovat yksi varmimmista tavoista joilla projektin saa epäonnistumaan. Mitä suuremmasta projektista on kyse, sitä enemmän siinä on mukana eri rooleissa toimivia henkilöitä. On tärkeää, että projektitiimi kootaan oikeanlaisista tekijöistä ja sovitaan kunkin vastuualueet. Olennaista on myös sopia projektin viestintäkeinot ja -tavat; mitä viestitään, missä vaiheessa ja kuka viestii.
Viestinnän kulmakivinä voivat toimia vaikkapa riittävän usein kehitystiimin kesken pidettävät kevyet ja nopeat statuspalaverit, pidempien kehitysjaksojen jälkeen pidettävät sprinttikatselmukset ja laajemman kokonaisuuden välitarkastelut yhdessä asiakkaan kanssa. Sekä asiakkaan että kehittäjätiimin on työskenneltävä läheisesti, jotta kaikki ajatukset, ideat ja tieto vaatimuksista siirtyvät selkeästi kehittäjille. Oletukset ja asiakkaan roolin väheksyminen projektissa johtavat yleensä siihen, että lopputulos eroaa siitä mitä asiakkaalla oli alunperin mielessä.
Selkeä näkemys lopputuloksesta, huolelliset alkutyöt, riittävät määritykset ja projektin aikainen viestintä auttavat pitämään kokonaisuuden oikeilla raiteilla. Projektin onnistumiseen vaikuttaa edellä mainittujen lisäksi todella moni muukin asia, kuten
Onnistuneet ohjelmistoprojektit asettavatkin usein kovat vaatimukset ammattimaiselle projektinhallinnalle. Lue lisää ohjelmistoprojektin ostamisesta!
Lataa ostajan opas
