It Project Management | By Duncan Haughey | Read time minutes

Let ’ s start with some concerning statistics. Vain 29% ohjelmistoprojekteista onnistui, 52% haastettiin (kustannusylitykset, budjetin ylitykset tai sisällölliset puutteet) ja 19% epäonnistui, Standish Groupin vuoden 2015 raportin mukaan. Vaikka nämä havainnot tulivat ensimmäisen kerran esiin muutama vuosi sitten, tulokset ovat yhtä totta nykyään.

lisäksi asiakkaan arvokkaina pitämien hankkeiden osuus on 59% ja asiakkaan tyydyttävinä pitämien hankkeiden osuus 56%.

epätyydyttävistä projektituloksista on tullut IT-alan normi, jossa asiakas ei ollut tyytyväinen lopputulokseen. Mitä voimme tehdä asialle?

hyvä lähtökohta on käsitellä joitakin kriittisiä syitä ohjelmistoprojektien epäonnistumiseen.

syy 1: ei tarpeeksi aikaa

usein takaraja päätetään ennen projektin alkua eikä siitä neuvotella. Tämä määräaika johtaa päistikkaa kiire päästä alkuun oletus, mitä nopeammin aloitat koodauksen, sitä nopeammin saat projektin valmiiksi.

kiire aloittaa koodaaminen on lähes aina väärä lähestymistapa. On tärkeää käyttää aikaa luoda hyvä muotoilu. Hyvän suunnittelun puute johtaa jatkuviin muutoksiin koko kehitysvaiheen ajan. Kun näin tapahtuu, aikaa ja budjettia kuluu hurjaa vauhtia.

liuos:

• älä anna kiusauksen hypätä suoraan sisään ja aloittaa koodausta.
• anna riittävästi aikaa hyvän suunnittelun luomiseen, niin muu projekti sujuu paljon paremmin.

tämä lähestymistapa parantaa mainettasi, kun toimitat jotain, joka täyttää asiakkaidesi odotukset ja toimii ensimmäisellä kerralla oikein.

Syy 2: riittämätön budjetti

monilla hankkeilla on alhaisin hinta, onnistunein toimittajapolitiikka tai epärealistisen pieni budjetti, joka ei perustu hankkeen vaatimuksiin. Kun näin tapahtuu, kaikki hidastuu. Resurssit ovat hitaita saapumaan tai eivät koskaan saavu; mutkia karsitaan, ja laatu kärsii.

liuos:

• ole realistinen talousarvion suhteen ja perusta se täydellisiin vaatimuksiin.
• vältä perustamasta tavarantoimittajan valintaa pelkästään alimpaan hintaan.
• mene tavarantoimittajalle tai tiimille, jolla on todistetusti kokemusta budjetin puitteissa toimittamisesta.
• käytä alla olevan kaltaista toimittajan valinnan tarkistuslistaa löytääksesi oikean toimittajan projektillesi.

Syy 3: Huono viestintä

on sanonta, ”Älä koskaan oleta mitään”, mikä pätee erityisesti ohjelmistoprojekteihin. Hyvä viestintä asiakkaan, käyttäjien ja kehitystiimin kanssa on tärkeää projektin onnistumisen kannalta. Kysy itseltäsi kolme kysymystä:

1. ymmärtävätkö kaikki tiimissä sinua?
2. tietävätkö he, mitä heiltä odotat, vai oletko olettanut heidän tietävän?
3. kommunikoivatko ne hyvin keskenään, käyttäjien ja muiden osastojen kanssa?

liuos:

• Etsikää yhteyshäiriöt. Nämä voivat aiheuttaa sekaannusta ja komplikaatioita myöhemmin projektissa.
• Älä koskaan oleta, että kaikki ymmärtävät kaiken, mitä projektissa tapahtuu.
• käytä aikaa sellaisen ympäristön luomiseen, jossa viestintä on esteetöntä, avointa ja tiheää.

Reason 4: Never Review Project Progress

kun projekti etenee, asiat muuttuvat, mikä vaikuttaa merkittävästi projektiin. On tärkeää jatkaa hankkeen edistymisen tutkimista, jotta haasteista voidaan selviytyä varhaisessa vaiheessa ja sidosryhmiä varoitetaan mahdollisista viivästyksistä ja tulosten muutoksista.

liuos:

• aseta aina välitavoitteet, joiden avulla voit tarkastella edistymistä tiimisi ja sidosryhmien kanssa projektin aikana. Säädä tarpeen mukaan pysyäksesi kurssissa.
• pysy lähellä tiimiäsi ymmärtääksesi, mitä tapahtuu ja mitä haasteita he kohtaavat.

syy 5: riittämätön testaus

kun luovutuspaine on päällä, testaus usein kärsii. Testaus jää kehityssyklin loppuun asti mahdollisimman vähällä testaukseen käytetyllä vaivalla. Yleensä tuloksena on tuote täynnä vikoja ja tyytymätön asiakas.

liuos:

• suorittaa testausta koko kehityksen elinkaaren ajan, testaamalla jokaisen moduulin tai komponentin sitä mukaa kuin se on kehitetty.
• jätä integraatiotestaus vain kehityksen elinkaaren loppuun, jolloin stressi vähenee ja tuote paranee.

syy 6: testaus tuotantoympäristössä

on yllättävää, kuinka moni organisaatio testaa tuotteita tuotantoympäristössään. Tuotantoympäristön käyttö on korkean riskin strategia, joka voi johtaa tietoturvaloukkauksiin ja vahingossa tapahtuvaan päästöön ilman testausta, mikä häiritsee tuotantojärjestelmiä.

liuos:

• kehittää prosessi laadunvarmistus ja vapauttaa uusia ohjelmistotuotteita.
• tarjoa tuotantoympäristöstä erotettu ympäristö testausta ja vikojen korjaamista varten.

syy 7: laadunvarmistuksen puute

usein kiireessämme toimittamaan ohjelmistoa laadunvarmistus kärsii. Dokumentointi on puutteellista koodimuutosten osalta, suunnittelussa on puutteita ja toteutukset voivat olla keskeneräisiä. Nämä kaikki johtavat uudelleenkäsittelyyn, menetettyyn aikaan ja lopulta onnettomiin asiakkaisiin.

liuos:

• varaa aikaa ohjelmiston laadun tarkistamiseen ja dokumentointiin ennen julkaisua.
• Review Michael L Young article 6 Success Factors for Managing Project Quality

Reason 8: Toimialan standardien

alan standardien noudattaminen ohjelmistoprojekteissa voi osoittautua hyödylliseksi varmistamalla hyvän saavutettavuuden, siirrettävyyden, käytettävyyden, kestävyyden ja vähentämällä nykyisiä ja tulevia ongelmia. Sellaiset elimet kuin World Wide Web Consortium (W3C) ja International Organization for Standardisation (ISO) ovat kehittäneet avoimia standardeja, joita on vaikea haastaa.

liuos:

• käytä aikaa standardointimenetelmän käyttöönottoon projekteissasi.
• etsi se, mikä toimii hyvin, ja jatka sen tekemistä.
• muuta kaikki, mikä ei toimi.
• Tarkista ja päivitä standardisi säännöllisesti.

seuraavan kerran kun projektisi hallinnoi ohjelmistokehitysprojektia, käy tämä lista läpi ja muistuta itseäsi siitä, mitä tarvitaan onnistumisen varmistamiseksi. Tulet yllättymään; sillä on merkitystä.

Recommended read: the Curious Case of the CHAOS Report 2009 by Jorge Dominguez.