Ohjelmiston toimitus voi kestää sekunneista (netistä suoraan otettavat palvelut) muutamaan päivään (kustomoitu, mutta hyvin kevyesti) tai viikkoihin (kustomoitu, mutta tehdään esim. integraatio verkkomaksujärjestelmään, sähköiseen allekirjoituspalveluun tai käyttäjätunnistus palveluun, joissa toimitusprojektin valmistuminen on kiinni kolmannesta osapuolesta ja/tai tilaajan aikataulusta).

Kuukausia kestävissä ohjelmistoprojekteissa tilaajalle kehitetään merkittävästi räätälöityjä toiminnallisuuksia, kustomoituja näkymiä ja uusia työkaluja (uuden koodaus, isot konfiguraatiotyöt). Mitä valmiimpi ohjelmisto on, sen paremmin toimittaja voi käyttää kuukaudet tuotteen sovittamiseksi tilaajan toimintaympäristöön. Työ on komponenttien yhdistelyä, ei enää niinkään uuden koodausta. Tämä on tyypillisin case Gemilossa ja toimintamallien sujuvoittamiseen tilatut toimitusprojektit vaihtelevat parista viikosta puoleen vuoteen.

Vuosia kestävissä projekteissa on yleensä monta aliprojektia tai osaprojekti - tai todella hidas toimittaja tai asiakas itse.

Kun tilaajalle toteutetaan valmis digitaalinen toimintamalli operatiiviseen tai strategiseen käyttöön, projektissa katsotaan asiakkaan kanssa läpi esim. oikeusasetukset, erilaiset sisältötyypit, niiden tilat, automaattiset oikeusasetukset, mahdolliset tilaajan haluamat erilaiset kategoriat avainsanoituksen lisäksi (metadata) ja rakennetaan valmiiksi sähköiset kuittaukset käyttöönotettavana prosessina. Tälllaisessa ohjelmistoprojektissa toimittaja toimittaa valmiin ohjelmiston eikä käytä aikaa niinkään uuden koodin kirjoittamiseen kuin siihen, että tuote tai moniohjelmisto sovitetaan asiakkaan käyttöön.

Joskus mikä tahansa ohjelmistoprojekti voi venyä kuukausiin, jos tilaaja ei tiedä mitä haluaa ja joudutaan tekemään monta kertaa sama asia uudelleen. Tämän välttää tekemällä vaatimusmäärittelyn kunnolla yhdessä (toimittaja ja tilaaja) tai hyväksymällä, että ratkaisua etsitään kokeilemalla käytännössä. Epäonnistumisen riski on suurin, jos toimittaja ei ole ymmärtänyt, mitä tilaaja haluaa. Kun osuu tuulettimeen, toimittaja toimittaa tilaajalle ratkaisun, joka on tehtävä uudelleen tai tilattava toiselta toimittajalta tai tyydyttävä toimitajan ratkaisuun. Aktiivisella asiakasviestinnällä estettävissä!

Pitkissä ohjelmistoprojekteissa tilaaja voi tarkoituksella haluta "pitkän" projektin. Tällainen asiakas ei osta toimitusta, jos kokee, että toimitusprojekti on "liian lyhyt", vaikka ohjelmiston laajuus olisi täysin sama pitkässä ja lyhyessä projektissa. Työ saatetaan jakaa useille kuukausille (tai pitkittyy itsekseen), koska tilaaja kokee, ettei ehdi hoitaa projektia oman työn ohessa tai koska tilaajalla on strategisesti tai toiminnan kannalta tärkeitä muita deadlineja, joiden aikatauluihin ohjelmistoprojekti sovitetaan. Sama tietysti toisin päin eli on ohjelmistotoimittajia, jotka eivät pysty toimittamaan ratkaisuja. Onneksi ei koske omaa yritystäni.

Mitä pidemmälle ajalle toimitusprojekti halutaan jyvittää, vaikka projekti olisi hankintainvestointina edullinen, sen kalliimmaksi toteutus yleensä tulee sekä tilaajalle että toimittajalle. Ohjelmistoprojektissa pitää löytyä myös tilaajan omassa organisaatiossa sisäinen palo laittaa asioita kuntoon.

Ohjelmistoprojekti yhteiskehittämisellä ei ole sen pidempi kuin "valmiilla" ohjelmistotuotteella, joka kustomoidaan. Tilaajan kannattaisikin hankintakilpailutuksessa vertailla, saako toimitusprojektissa, miten valmista. Ohjelmiston toimitus tarkoittaa, että se on käyttövalmis.

Mikä vaikuttaa ohjelmistoprojektin kestoon? -muistilista

  • asiakkaan oma aikataulu
  • toimituksen budjetti
  • toimittajan tekninen osaaminen
  • tiedot omasta organisaatiosta ja toiminnasta
  • kummankin osapuolen projektinhallinta-taidot
  • valittu toimitustapa (ketterä vs perinteinen)
  • yhteinen näkemys, mitä on sovittu
  • muutostoiveiden määrä ja laajuus
  • kysy päättää asioita
  • vuorovaikutus- ja neuvottelutaidot
  • alkuperäisen ja/tai muutetun suunnitelman realistisuus
  • ohjelmiston valmiusaste
  • kummankin osapuolen päällekkäiset muut projektit
  • avainhenkilöiden vaihtuminen joko tilaajan tai toimittajan tai molempien organisaatioissa.

Nuo voi hoitaa huonosti tai hyvin kummassa tahansa toimitusprojektissa:

  • siinä, missä kustomoidaan asiakkaalle valmisohjelmisto ohjelmiston omistajan ehdoin (valmis tuote, jota voi jonkin verran räätälöidä, mutta ohjelmistossa on omat rajoituksensa, kuten voiko vain konfiguroida vai oikeasti muuttaa koodia)
  • tai siinä, missä toimittaja toteuttaa ohjelmiston / sovelluksen tilaajalle yhteiskehittämisen keinoin
  • "tyhjästä" koodattava tietokone-ohjelma / sovellus
  • tai osista koottava tietokone-ohjelma / sovellus
  • tai näiden yhdistelmä

Projektin kestoa pidentää, jos muutoksista aiheutuu uutta päätettävää ja mahdollisesti uusia muutoksia. Jossain kohtaa pitää vain päättää, että tämä on hyvä ja antaa myös käytölle ja omaksumiselle aikansa.

Jos omaa toimintaprosessia ja käytäntöjä koskevat vaikeat asiat sivuutettiin eikä selkeitä tavoitteita ymmärretty kuvata, käyttöönotto(kin) venyy ja pitkittyy. Huonossa projektissa tavoitteet voi toki olla niinkin, että tavoitteet kuvattiin, mutta toteutustiimi ohittaa ne joko tarkoituksella tai epähuomiossa. Keskustele enemmän, kuvaile ja avaa, mitä halutaan ja mitä ollaan toimittamassa. Uskalla kokeilla ja varaa aika muutoksille.
Kirjoittajat
Katri Lietsala
Toimitusjohtaja
040 749 9072
comments powered by Disqus