IT-projektin hallinta: vaiheet, menetelmät ja yleisimmät sudenkuopat

IT-projektinhallinta tarkoittaa ohjelmisto-, järjestelmä- tai infrastruktuuriprojektin suunnittelua, ohjaamista ja päättämistä niin, että valmis ratkaisu otetaan käyttöön sovitussa laajuudessa, aikataulussa ja budjetissa. IT-projekti eroaa muista projekteista siinä, että vaatimukset tarkentuvat usein vasta tekemisen aikana — siksi sen hallinta on ennen kaikkea muutosten, riippuvuuksien ja tilaajan ja toimittajan välisten odotusten hallintaa.

Tässä artikkelissa käydään läpi IT-projektin vaiheet, menetelmän valinta, yleisimmät syyt epäonnistumiseen, tilaajan ja toimittajan välinen työnjako sekä se, millaisia työkaluja kehittäjätiimi oikeasti tarvitsee.

Mitkä ovat IT-projektin vaiheet?

Menetelmästä riippumatta lähes jokainen ohjelmistoprojekti kulkee samojen vaiheiden läpi. Ketterässä projektissa vaiheet toistuvat lyhyinä kierroksina, vesiputousmallissa ne seuraavat toisiaan kerran. Sisältö on silti sama.

Vaihe	Mitä tehdään	Tyypillinen tuotos
1. Esiselvitys	Ongelma, tavoite, hyödyt ja karkea kustannusarvio. Kannattaako projekti käynnistää?	Projektin perustelu, päätös käynnistämisestä
2. Vaatimusmäärittely	Mitä järjestelmän pitää tehdä, kenelle ja millä laatutasolla	Vaatimuslista tai käyttäjätarinat, rajaukset
3. Suunnittelu	Arkkitehtuuri, integraatiot, tietomalli, käyttöliittymä, tietoturva	Tekninen suunnitelma, aikataulu, budjetti
4. Toteutus	Ohjelmointi, konfigurointi, tietojen siirto	Toimivat ominaisuudet testiympäristössä
5. Testaus	Yksikkö-, integraatio- ja järjestelmätestaus sekä tilaajan hyväksymistestaus	Hyväksytty testiraportti
6. Käyttöönotto	Tuotantoon vienti, koulutus, viestintä, vanhan järjestelmän alasajo	Järjestelmä tuotannossa
7. Päättäminen ja ylläpitoon siirto	Takuuaika, ylläpitosopimus, dokumentaatio, loppuraportti	Luovutus ylläpidolle

Kaksi vaihetta jää useimmin liian ohueksi: vaatimusmäärittely ja käyttöönotto. Ensimmäisen puute näkyy myöhemmin muutospyyntöinä, jälkimmäisen puute siinä, että valmis järjestelmä ei ole käytössä. Yleisemmin projektin vaiheista kerrotaan artikkelissa projektin vaiheet aloituksesta päättämiseen.

Ketterä vai vesiputousmalli — miten IT-projektin menetelmä valitaan?

Valinta ei ole maku- eikä muotiasia. Se riippuu siitä, kuinka hyvin tiedetään alussa, mitä rakennetaan.

• Vesiputousmalli sopii, kun vaatimukset ovat vakaat ja tiedossa: esimerkiksi valmiin järjestelmän käyttöönotto, lainsäädännön vaatima muutos tai infrastruktuurin uusiminen. Vaiheet ja hyväksynnät ovat selkeät.
• Scrum sopii uuden tuotteen tai palvelun kehittämiseen, kun vaatimukset tarkentuvat käyttäjiltä saatavan palautteen myötä. Työ tehdään lyhyinä iteraatioina, ja jokaisen lopussa on jotain näytettävää.
• Kanban sopii jatkuvaan kehitykseen ja ylläpitoon, jossa työtä tulee tasaisena virtana ilman selkeää loppua.
• Hybridi on IT-projekteissa käytännössä yleisin: kiinteä kehys (budjetti, päätavoite, välitavoitteet ja käyttöönottopäivä) ja ketterä toteutus sen sisällä.

Menetelmien tarkempi vertailu: Scrum, Kanban, vesiputousmalli vai PRINCE2.

Ketteryys ei poista suunnittelua. Ketterässäkin IT-projektissa tarvitaan IT-projektisuunnitelma, joka kertoo tavoitteen, rajaukset, budjetin, roolit ja välitavoitteet. Ero on siinä, että yksittäisiä ominaisuuksia ei lukita etukäteen. Ohje suunnitelman laatimiseen: projektisuunnitelma-opas.

IT-projektisuunnittelussa kannattaa kiinnittää erityistä huomiota kolmeen asiaan, jotka yleisistä projektisuunnitelmapohjista usein puuttuvat. Ensinnäkin ympäristöt: milloin kehitys-, testi- ja tuotantoympäristö ovat käytettävissä ja kuka ne hankkii. Toiseksi tietojen siirto: vanhan järjestelmän tiedot pitää siivota, muuntaa ja testata, ja se on lähes aina oletettua työläämpää. Kolmanneksi tietoturva ja tietosuoja: käyttöoikeudet, henkilötietojen käsittely ja lokitus on helpompi suunnitella alussa kuin lisätä valmiiseen järjestelmään. Merkitse jokainen näistä omaksi työpaketikseen, jolla on omistaja ja määräaika.

Miksi IT-projektit epäonnistuvat?

IT-projektien ongelmat ovat harvoin teknisiä. Useimmiten syy löytyy jostakin seuraavista:

Syy	Miltä se näyttää	Mitä tehdä
Epäselvät vaatimukset	Toimittaja rakentaa sitä, mitä luuli tilaajan tarkoittavan	Hyväksymiskriteerit jokaiselle vaatimukselle, demot säännöllisesti
Laajuuden hiipiminen	"Pieniä" lisäyksiä tulee viikoittain, kukaan ei laske niiden summaa	Muutospyyntömenettely ja kirjattu rajaus
Liian optimistinen aikataulu	Arviot tehdään ennen kuin työtä ymmärretään; testaukselle ja tietojen siirrolle ei varata aikaa	Arviot tekijöiltä, testaus omana vaiheenaan, puskuri
Puuttuva omistajuus tilaajalla	Kukaan ei ehdi tehdä päätöksiä tai testata; toimittaja odottaa vastauksia viikkoja	Nimetty tuoteomistaja tai pääkäyttäjä, jolla on aikaa
Aliarvioidut integraatiot	Vanhan järjestelmän rajapinta osoittautuu puutteelliseksi vasta toteutuksessa	Integraatiot selvitetään suunnitteluvaiheessa, riskirekisteriin
Käyttöönotto unohdetaan	Järjestelmä on valmis, mutta käyttäjät jatkavat vanhalla tavalla	Koulutus, viestintä ja tuki projektin työpaketteina
Avainhenkilöriippuvuus	Yksi kehittäjä tietää kaiken, ja hänen lomansa pysäyttää projektin	Dokumentointi, työparit, resurssisuunnittelu

Yhteistä näille on, että ne ovat nähtävissä jo suunnitteluvaiheessa. IT-projektin onnistuminen ratkeaa siis paljolti ennen ensimmäistä koodiriviä: siinä, kuinka hyvin vaatimukset, rajaukset, riippuvuudet ja riskit on kirjattu. Laajuuden hiipimisestä on oma artikkelinsa: scope creep ja miten sen tunnistaa, ja riskien arvioinnista riskimatriisi ja riskianalyysi.

Tilaaja ja toimittaja: kuka vastaa mistäkin?

Moni IT-projekti on kahden organisaation yhteinen: tilaaja omistaa tarpeen ja liiketoiminnan, toimittaja osaamisen ja toteutuksen. Suurin osa riidoista syntyy, kun vastuunjako on jäänyt sopimuksessa ja käytännössä epäselväksi.

Vaatimusmäärittely on tilaajan vastuulla — mutta yhteistyönä

Tilaaja tietää, mitä liiketoiminta tarvitsee; toimittaja tietää, mitä on järkevää rakentaa. Hyvä määrittely syntyy työpajoissa, ei yksin kirjoitettuna dokumenttina. Jokaiselle vaatimukselle kannattaa kirjata hyväksymiskriteeri: miten tilaaja testaa, että vaatimus täyttyy.

Hyväksymistestaus kuuluu tilaajalle

Toimittaja testaa, että järjestelmä toimii teknisesti. Tilaaja testaa, että se toimii hänen prosesseissaan. Hyväksymistestaukseen tarvitaan oikeita käyttäjiä, testitapauksia ja aikaa — ja se pitää varata aikatauluun ja resursseihin jo projektin alussa. Liian usein hyväksymistestaus tehdään "muiden töiden ohessa" kahdessa päivässä, ja virheet löytyvät tuotannossa.

Muutospyynnöt käsitellään sovitulla tavalla

Muutoksia tulee aina, eikä se ole merkki epäonnistumisesta. Ongelma on käsittelemätön muutos. Sovi alussa menettely: kuka voi tehdä muutospyynnön, kuka arvioi sen vaikutuksen aikatauluun ja kustannuksiin, ja kuka sen hyväksyy. Jokainen hyväksytty muutos kirjataan päätöksenä. Silloin loppuvaiheessa ei tarvitse kiistellä siitä, mikä kuului alkuperäiseen hintaan.

Yhteinen tilannekuva

Kun tilaaja ja toimittaja seuraavat eri listoja, tilannekuva hajoaa. Säännöllinen, molempien hyväksymä tilanneraportti — mitä valmistui, mikä on myöhässä, mitä päätöksiä tarvitaan — on yksinkertaisin tapa pitää odotukset linjassa.

IT-projektin johtaminen: roolit, jotka pitää nimetä

Moni IT-projekti kompastuu siihen, että roolit oletetaan eikä nimetä. Vähintään nämä kannattaa kirjata projektisuunnitelmaan nimeltä:

Rooli	Vastuu
Projektin omistaja (tilaaja)	Päättää budjetista, laajuudesta ja hyväksyy lopputuloksen
Tilaajan projektipäällikkö	Koordinoi tilaajan puolen: päätökset, testaajat, käyttöönotto
Tuoteomistaja tai pääkäyttäjä	Priorisoi vaatimukset ja vastaa kysymyksiin nopeasti
Toimittajan projektipäällikkö	Vastaa toteutuksen etenemisestä, resursseista ja raportoinnista
Arkkitehti tai tekninen vastaava	Tekniset ratkaisut, integraatiot ja tietoturva
Ohjausryhmä	Ratkaisee asiat, jotka ylittävät projektipäälliköiden valtuudet

Pienessä projektissa sama ihminen voi hoitaa useampaa roolia, mutta silloinkin on hyvä tietää, missä roolissa hän kulloinkin päättää. Tärkein yksittäinen kohta on tuoteomistajan aika: jos hänellä ei ole projektille varattua aikaa kalenterissa, toimittaja odottaa vastauksia ja aikataulu venyy ilman, että kukaan teki varsinaista virhettä. Vastuunjaon kirjaamiseen sopii RACI-matriisi, katso sidosryhmien hallinta ja RACI-matriisi.

Esimerkki: verkkokaupan uudistus

Oululainen tekninen tukkukauppa uudistaa verkkokauppansa ja ostaa toteutuksen ohjelmistotalolta. Projekti hoidetaan hybridimallilla:

• Kiinteä kehys: budjetti, julkaisu ennen kevätsesonkia ja kolme välitavoitetta (määrittely hyväksytty, testiympäristö valmis, hyväksymistestaus läpäisty).
• Ketterä toteutus: kahden viikon iteraatiot, joiden lopussa tilaajan pääkäyttäjä näkee demon ja priorisoi seuraavan kierroksen.
• Tunnistetut riskit: toiminnanohjausjärjestelmän rajapinta (selvitetään ensimmäisessä iteraatiossa), tuotetietojen laatu (tilaajan vastuulla, oma työpaketti), pääkäyttäjän aika (varattu 40 % ajasta projektille).
• Muutospyynnöt: pääkäyttäjä kirjaa, toimittaja arvioi, tilaajan projektipäällikkö hyväksyy alle sovitun rajan, sen yli ohjausryhmä.

Rakenne ei ole raskas, mutta se vastaa kaikkiin kysymyksiin, joihin IT-projektit tavallisesti kaatuvat: kuka päättää, mitä testataan, mitä muutos maksaa ja mitä tehdään, jos rajapinta ei toimi.

Millaisia työkaluja IT-projekti tarvitsee?

IT-projektin työkalut jakautuvat karkeasti kahteen tasoon, ja moni kehittäjätiimille projektinhallintaratkaisua etsivä huomaa tarvitsevansa molempia.

Taso	Kenelle	Mitä tarvitaan
Kehitystyön taso	Kehittäjät	Tehtävät ja tiketit, versionhallinta, koodikatselmointi, testaus- ja julkaisuputki, virheiden seuranta
Projektin taso	Projektipäällikkö, tilaaja, ohjausryhmä	Suunnitelma, aikataulu ja välitavoitteet, budjetti, riskit, päätökset, tilanneraportointi, resurssit

Kehittäjien tikettijärjestelmä on erinomainen tehtävien hallintaan, mutta se ei yleensä vastaa ohjausryhmän kysymyksiin: pysytäänkö budjetissa, mitkä riskit ovat kasvaneet, mitä on päätetty ja milloin julkaisu oikeasti on. Jos käytössä on raskas kehitystyökalu ja kaipaat kevyempää projektitason näkymää, vertailu löytyy sivulta Jira-vaihtoehto. Yleiskatsaus välineisiin: parhaat projektinhallinnan työkalut ja projektinhallintaohjelmiston valinta.

Valitessasi IT-projektityökaluja kysy ainakin: näkyykö aikataulu riippuvuuksineen, onko budjetti samassa paikassa kuin tehtävät, voiko tilaajan kutsua katsomaan tilannetta, ja syntyykö tilanneraportti ilman kopiointia.

Miten Projektiassistentti auttaa

Projektiassistentti toimii projektin tasolla. Kun luot projektin ja valitset tyypiksi IT-kehityksen ja menetelmäksi esimerkiksi Scrumin, vesiputousmallin tai hybridin, tekoäly laatii kuvauksesi pohjalta suunnitelman: tavoitteet, työn osituksen, aikataulun ja riskit. Voit liittää mukaan toimeksiannon tai vaatimusdokumentin, jota tekoäly käyttää suunnitelman pohjana. Sen jälkeen samaa projektia hallitaan tehtävinä, Gantt-aikatauluna, Kanban-tauluna, riskirekisterinä ja budjettina, ja tilaajan voi kutsua projektiin.

Business-tilauksessa mukana ovat lisäksi projektisalkku, resurssisuunnittelu ja integraatiot (esimerkiksi Slack/Teams, API-tunnisteet ja webhookit). IT-alan erityispiirteistä lisää sivulla IT- ja teknologia-alan projektinhallinta.

Usein kysyttyä

Mitä IT-projektipäällikkö tekee?

IT-projektipäällikkö vastaa siitä, että projekti etenee suunnitellusti: hän pitää suunnitelman, aikataulun, budjetin ja riskit ajan tasalla, sovittaa yhteen tilaajan ja toimittajan, hoitaa muutospyynnöt ja raportoi ohjausryhmälle. Tekniset ratkaisut tekee yleensä tiimi tai arkkitehti.

Tarvitaanko ketterässä projektissa projektisuunnitelmaa?

Tarvitaan, mutta kevyempänä. Tavoite, rajaukset, budjetti, roolit, välitavoitteet ja riskit kirjataan; yksittäisiä ominaisuuksia ei lukita etukäteen.

Mikä on IT-projektin yleisin epäonnistumisen syy?

Epäselvät vaatimukset ja niistä seuraava hallitsematon muutosten virta. Toiseksi yleisin on se, ettei tilaajalla ole nimettyä ihmistä, jolla on aikaa tehdä päätöksiä ja testata.

Kuka hyväksyy IT-projektin tuotokset?

Tilaaja hyväksymistestauksen perusteella. Hyväksymiskriteerit kannattaa sopia jo vaatimusmäärittelyssä, ei vasta testausvaiheessa.

Yhteenveto

IT-projekti onnistuu, kun vaatimukset ja rajaukset on kirjattu, menetelmä valittu sen mukaan kuinka hyvin lopputulos tunnetaan, muutoksille on sovittu menettely, hyväksymistestaukselle on varattu aikaa ja käyttöönotto on suunniteltu osaksi projektia. Työkaluja tarvitaan kahdelle tasolle: kehittäjille ja projektin ohjaamiseen.

Jos haluat projektitason suunnitelman, aikataulun ja riskit yhteen paikkaan muutamassa minuutissa, aloita maksuton kokeilu.