Tarpeen jatkuva kirkastaminen tuottaa parempia ohjelmistoprojekteja
-
date post
19-Oct-2014 -
Category
Business
-
view
119 -
download
0
description
Transcript of Tarpeen jatkuva kirkastaminen tuottaa parempia ohjelmistoprojekteja
Projektiyhdistyksen suuret saappaat s. 4-5
Suomalaisorganisaatiot Megasuuntauksen jälkijunassa? s. 16-18
Oi Suomi, päiväs' vielä koittaa s. 6-9
Projektitoiminnan menestysresepti!IPMA Delta case: Swisscom IT Services s. 28-31
Comparing PM Certifications s. 20-22
Puolivallaton projektinjohtaja s. 100-105
Olemme uudistaneetsivumme!käy klikkaamassa > www.pry.fi
2/2013 OSAAMINEN KUNTOON
Parempia ohjelmistoprojekteja
Osaaminen kuntoon
Ohjelmistoprojekteissa puhutaan paljon tilaajan ja toimittajan vastuusta. Rajanveto on vaikeaa ja ohjelmistoprojektit epäonnistuvat turhan usein. Käsittelen tämän artikkelin puitteissa erästä merkittävää juurisyytä epäonnistumisille.
Tilaaja haluaa saada tarpeenmukaisen ratkaisun, mutta ei välttämättä tiedosta, että hän ei voi kaikilta osin tietää tarvettaan. Tämä takia ratkaisu itse asiassa löytyy tilaajan ja toi-mittajan yhteistyöllä sen sijaan, että se voidaan etukäteen määritellä. Jos projektin tilaaja delegoi omien tarpeidensa kirkastamisen toimittajalle, hän altistaa projektin lähes var-malle epäonnistumiselle. Onnistuakseen paremmin, tilaajan tulee itse kirkastaa tarvet-taan jatkuvasti ja valmistautua tekemään päätöksiä. Artikkelin tavoite on kertoa, miten tilaaja ja toimittaja huolehtivat tarpeenmukaisen ratkaisun syntymisestä.
Vertaan toisiinsa kahta projektin tilaamisen lähestymistapaa: 1) ”Ratkaisu edellä”, missä tarpeen ymmärtäminen delegoidaan projektin toimittajalle ja 2) ”Tarvetta kirkastetaan jatkuvasti”, missä projektin tilaaja huolehtii tarpeestaan koko projektin ajan.
Tarpeen jatkuva kirkastaminen tuottaa
Teksti: Marko Taipale
42
Ratkaisu edelläProjektin tilaaja on tehnyt liiketoimintalaskelman ja päättää tilata uuden ohjelmistoprojektin. Projektin toi-mittaja tulee paikalle ja sitoutuu toimittamaan. Parin vuoden päästä ohjelmistoa otetaan käyttöön. Tarkas-telen tätä lähestymistapaa kuvan 1 mukaisella kuvaa-jalla.
Tyypillinen tilaajan lähtökohta on epäselvä kuvi-telma siitä, mitä lähdetään tekemään, ja toisaalta vä-häinen ymmärrys omasta ympäristöstä, prosesseista, käyttäjistä ja yritysarkkitehtuurista. Tilattavan ohjel-miston kuitenkin toivotaan täyttävän jokin tunniste-tuista tarpeista ja täten päätetään aloittaa ohjelmis-toprojekti.
Ohjelmistoprojekti vedetään läpi mallikkaasti (kohta 1), tilaajan toiveiden tynnyri toimitetaan, ainakin joltain osin, ja näin alkaa käyttöönotto. Käyttöönoton yhte-ydessä esiintyy joukko ongelmia: tuotettu ratkaisu ei palvelekaan käyttäjiä, eikä se sovikaan yhteen tilaajan yrityksen toimintatapojen kanssa ja muuttaa vain van-han toimintatavan sähköiseksi. Ongelmat tuottavat paljon muutospyyntöjä (kohta 2) ja niiden seuraukse-na ohjelmistoprojekti ylittää taloudelliset sekä ajalliset raamit. Ja mikä pahinta, tilaaja voi silti todeta toimi-neensa oikein, koska hän on antanut toimeksiannon ja sitä on noudatettu - tai jos ei ole, niin hän voi syyttää toimittajaa väärintulkinnoista ja osaamattomuudesta.
Lopulta tilaajan sidosryhmät (käyttäjät, päättäjät jne.) eivät halua, voi tai osaa sitoutua uuden ratkaisun käyttöönottoon. Tilaaja miettii, mikä oikein meni pie-leen.
Teollisuuden asianajotoimisto
Projektirakentaminen . Energia . Teknologia
p. +358 9 6962 070
www.bergmann.fi
Asianajotoimisto Bergmann Oy
Eteläranta 4 B 9
00130 Helsinki
A t t o r n e y s a t L a w
E R GM A N N
Kuva 1.
Tarvetta kirkastetaan jatkuvastiPieleen menneen projektin jälkeen tilaaja pohtii, mitä hänen ja hänen sidosryhmiensä pitäisi tarpeestaan ymmärtää, jotta ohjelmistoprojekti voisi tuottaa tar-peenmukaisia ratkaisuja. Hän listaa:- Nykyiset prosessit, joita ohjelmisto tulee jollain ta-
paa palvelemaan- Tulevaisuuden prosessit, joissa tietojärjestelmä hoi-
taa oman osuutensa- Kuka käyttää tätä järjestelmää ja mihin?- Mitä tarpeita, toiminnallisia tai laadullisia, tähän oh-
jelmistoon tai koko prosessiin liittyy?- Mihin tekniseen ja toiminnalliseen ympäristöön oh-
jelmisto tulee osaksi?- Mitä riskejä tähän kokonaisuuteen liittyy ja mitä mi-
nun pitää päättää nyt, mitä voin päättää myöhem-min?
Tekninen ratkaisu
Epäselvyys
Tarpeen mukainen ratkaisu
1
2
Tarp
een
jatk
uva
kirk
asta
min
en
43PROJEKTITOIMINTA 2/2013
On tärkeää, että jokainen ohjelmistoprojekti
nähdään myös toiminnan kehittämisen projektina
Kuva 2.
Tekninen ratkaisu
Epäselvyys
Tarpeen mukainen ratkaisu
1
2
4
3
Tarp
een
jatk
uva
kirk
asta
min
en
44
Tilaaja lähtee työstämään tarpeenmukaista ratkaisua yhteistyössä toimit-tajan kanssa kuvan 2 mukaisesti.
Tilaaja ymmärtää, että ensisijaisesti hänen pitäisi sisäistää oma tarpeensa ja uuden ohjelmiston vaikutus toimintatapoihin jo ennen tilaamista. Tarkaste-lemalla aikaisempia hankkeitaan hän on oppinut, että tarve tai siihen sovitet-tu ratkaisu ei kaikilta yksityiskohdiltaan ole määriteltävissä etukäteen, vaan ratkaisu ja tarpeet kirkastuvat ohjelmistoprojektin edetessä. Tilaaja päättää panostaa ensimmäiseen loikkaan (kohta 3) kohti lopullista tavoitetta ja löy-tää ne kohdat, joiden ratkaiseminen on nyt välttämätöntä. Tilaaja osallistaa
sidosryhmän pohtimaan nykyistä toimintatapaa ja tulevaa muutosta, missä uusi ohjelmisto hoitaa omaa tonttiansa. Osallistaminen sitouttaa sidos-ryhmän ratkaisemaan yhteisiä haasteita ja aut-taa sisäistämään, mistä oikein on kysymys. Kun ensimmäinen loikka on tehty, tilaaja ja toimittaja tarkastelevat tuloksia. Seuraava loikka (kohta 4) aloitetaan tarkastelemalla tarpeita ja niihin koh-distuneita muutoksia yhdessä, jotta varmistetaan mahdollisimman tarpeenmukainen ratkaisu. Näin jatketaan aina projektin loppuun asti.
Toimittajan ja tilaajan välinen yhteistyö loikkien yhteydessä luo puitteet molemminpuoliselle ite-ratiiviselle oppimiselle. Oppiminen konkretisoituu tilaajalle siten, että hän ymmärtää paremmin oman tarpeensa. Toimittaja pystyy puolestaan kohdis-tamaan ratkaisun paremmin tilaajan tarpeeseen. Oppimisen myötä molemmille osapuolille kirkas-tuu, kuinka ratkaisu soveltuu ympäristöön. Tilaajan, toimittajan ja sidosryhmien osallistaminen jatkuu koko projektin ajan, jotta tarpeenmukaisesta rat-kaisusta voidaan varmistua loikka-loikalta.
Tarinan opetusTarinan tarkoitus on osoittaa, että olitpa sitten ohjelmistoprojektin ostaja tai yrityksen sisäinen tilaaja, tarpeen kirkastamiseen kannattaa kiinnit-tää huomiota. On tärkeää, että jokainen ohjelmis-toprojekti nähdään myös toiminnan kehittämisen projektina, mikä korostaa jatkuvan tarpeen kirkas-tamisen merkitystä entisestään.
Tarpeenmukaisuutta vaalimalla tilaaja saa pa-remman ratkaisun nopeammin ja edullisemmin. Lisäksi osallistamalla sidosryhmät mukaan tilaaja sitouttaa heidät käyttöönottoon.
Kun tilaajan huomio siirtyy lopputuloksen sijasta matkaan, määränpäässä odottaa tarpeenmukai-nen ratkaisu – ratkaisu, joka on löytynyt yhteis-työssä toimittajan ja oman sidosryhmän kanssa.
Marko Taipale toimii johtavana konsulttina Goseilla ja kehittää ketterään hankintaan liittyviä palveluita hankintavalmistelu.fi:ssa.
[email protected] +358 40 578 6447 twitter: @markotaipale
Osallistaminen sitouttaa sidosryhmän ratkaisemaan yhteisiä haasteita ja auttaa sisäistämään, mistä oikein on kysymys