SlideShare a Scribd company logo
1 of 4
Download to read offline
2/2013

OSAAMINEN KUNTOON

Olemme
uudistaneet
sivumme!
käy klikkaamassa > www.pry.fi

Projektiyhdistyksen suuret
saappaat s. 4-5

Oi Suomi,
päiväs' vielä koittaa s. 6-9

Comparing PM
Certifications
s. 20-22

Suomalaisorganisaatiot
Megasuuntauksen
jälkijunassa? s. 16-18

Projektitoiminnan
menestysresepti!
IPMA Delta case:
Swisscom IT Services s. 28-31

Puolivallaton
projektinjohtaja
s. 100-105
Osaaminen kuntoon

Tarpeen jatkuva kirkastaminen tuottaa

Parempia
ohjelmistoprojekteja

	Teksti: Marko Taipale

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 toimittajan 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 varmalle epäonnistumiselle. Onnistuakseen paremmin, tilaajan tulee itse kirkastaa tarvettaan 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.

42
Ratkaisu edellä

On tärkeää, että jokainen
ohjelmistoprojekti
nähdään myös toiminnan
kehittämisen projektina

Tarvetta kirkastetaan jatkuvasti
Pieleen menneen projektin jälkeen tilaaja pohtii, mitä
hänen ja hänen sidosryhmiensä pitäisi tarpeestaan
ymmärtää, jotta ohjelmistoprojekti voisi tuottaa tarpeenmukaisia ratkaisuja. Hän listaa:
-	 Nykyiset prosessit, joita ohjelmisto tulee jollain tapaa palvelemaan
-	 Tulevaisuuden prosessit, joissa tietojärjestelmä hoitaa oman osuutensa
-	 Kuka käyttää tätä järjestelmää ja mihin?
-	 Mitä tarpeita, toiminnallisia tai laadullisia, tähän ohjelmistoon tai koko prosessiin liittyy?
-	 Mihin tekniseen ja toiminnalliseen ympäristöön ohjelmisto tulee osaksi?
-	 Mitä riskejä tähän kokonaisuuteen liittyy ja mitä minun pitää päättää nyt, mitä voin päättää myöhemmin?

Tarpeen
mukainen
ratkaisu

Tarpeen jatkuva kirkastaminen

Projektin tilaaja on tehnyt liiketoimintalaskelman ja
päättää tilata uuden ohjelmistoprojektin. Projektin toimittaja tulee paikalle ja sitoutuu toimittamaan. Parin
vuoden päästä ohjelmistoa otetaan käyttöön. Tarkastelen tätä lähestymistapaa kuvan 1 mukaisella kuvaajalla.
Tyypillinen tilaajan lähtökohta on epäselvä kuvitelma 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 ohjelmiston kuitenkin toivotaan täyttävän jokin tunnistetuista tarpeista ja täten päätetään aloittaa ohjelmistoprojekti.
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 yhteydessä esiintyy joukko ongelmia: tuotettu ratkaisu ei
palvelekaan käyttäjiä, eikä se sovikaan yhteen tilaajan
yrityksen toimintatapojen kanssa ja muuttaa vain vanhan toimintatavan sähköiseksi. Ongelmat tuottavat
paljon muutospyyntöjä (kohta 2) ja niiden seurauksena ohjelmistoprojekti ylittää taloudelliset sekä ajalliset
raamit. Ja mikä pahinta, tilaaja voi silti todeta toimineensa 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 pieleen.

2
1

Epäselvyys
Tekninen ratkaisu
Kuva 1.

ERGMANN
Attorneys at Law

Teollisuuden
asianajotoimisto
Projektirakentaminen . Energia . Teknologia

Asianajotoimisto Bergmann Oy
Eteläranta 4 B 9
00130 Helsinki

p. +358 9 6962 070
office@bergmann.fi
www.bergmann.fi

PROJEKTITOIMINTA 2/2013

43
Tarpeen jatkuva kirkastaminen

Tarpeen
mukainen
ratkaisu

4

2

3
1

Epäselvyys
Tekninen ratkaisu
Kuva 2.

Tilaaja lähtee työstämään tarpeenmukaista ratkaisua yhteistyössä toimittajan 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. Tarkastelemalla aikaisempia hankkeitaan hän on oppinut, että tarve tai siihen sovitettu 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öytää ne kohdat, joiden ratkaiseminen on nyt välttämätöntä. Tilaaja osallistaa

Osallistaminen sitouttaa sidosryhmän
ratkaisemaan yhteisiä haasteita ja
auttaa sisäistämään, mistä oikein on
kysymys

sidosryhmän pohtimaan nykyistä toimintatapaa
ja tulevaa muutosta, missä uusi ohjelmisto hoitaa
omaa tonttiansa. Osallistaminen sitouttaa sidosryhmän ratkaisemaan yhteisiä haasteita ja auttaa 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 kohdistuneita 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 iteratiiviselle oppimiselle. Oppiminen konkretisoituu
tilaajalle siten, että hän ymmärtää paremmin oman
tarpeensa. Toimittaja pystyy puolestaan kohdistamaan ratkaisun paremmin tilaajan tarpeeseen.
Oppimisen myötä molemmille osapuolille kirkastuu, kuinka ratkaisu soveltuu ympäristöön. Tilaajan,
toimittajan ja sidosryhmien osallistaminen jatkuu
koko projektin ajan, jotta tarpeenmukaisesta ratkaisusta voidaan varmistua loikka-loikalta.

Tarinan opetus
Tarinan tarkoitus on osoittaa, että olitpa sitten
ohjelmistoprojektin ostaja tai yrityksen sisäinen
tilaaja, tarpeen kirkastamiseen kannattaa kiinnittää huomiota. On tärkeää, että jokainen ohjelmistoprojekti nähdään myös toiminnan kehittämisen
projektina, mikä korostaa jatkuvan tarpeen kirkastamisen merkitystä entisestään.
Tarpeenmukaisuutta vaalimalla tilaaja saa paremman 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 tarpeenmukainen ratkaisu – ratkaisu, joka on löytynyt yhteistyössä toimittajan ja oman sidosryhmän kanssa.

Marko Taipale toimii johtavana konsulttina
Goseilla ja kehittää ketterään hankintaan
liittyviä palveluita hankintavalmistelu.fi:ssa.
marko.taipale@gosei.fi
+358 40 578 6447
twitter: @markotaipale

44

More Related Content

Similar to Tarpeen jatkuva kirkastaminen tuottaa parempia ohjelmistoprojekteja

Hankekoulu presentaatio koralli_21_3_13
Hankekoulu presentaatio koralli_21_3_13Hankekoulu presentaatio koralli_21_3_13
Hankekoulu presentaatio koralli_21_3_13lansisuomenhelmet
 
Lupapiste asiakaspäivät FAQ
Lupapiste asiakaspäivät FAQLupapiste asiakaspäivät FAQ
Lupapiste asiakaspäivät FAQLupapiste
 
Avoimen lähdekoodin raamimalli ruotsissa
Avoimen lähdekoodin raamimalli ruotsissaAvoimen lähdekoodin raamimalli ruotsissa
Avoimen lähdekoodin raamimalli ruotsissaTimoSimell
 
Digitaalisen palvelun kehittäminen
Digitaalisen palvelun kehittäminenDigitaalisen palvelun kehittäminen
Digitaalisen palvelun kehittäminenMikko Eerola
 
ValueFrame - myynnistä toimitukseen -seminaari 17.11.2011 (id 2134) (id 2212)
ValueFrame - myynnistä toimitukseen -seminaari 17.11.2011 (id 2134) (id 2212)ValueFrame - myynnistä toimitukseen -seminaari 17.11.2011 (id 2134) (id 2212)
ValueFrame - myynnistä toimitukseen -seminaari 17.11.2011 (id 2134) (id 2212)ValueFrame Oy
 
Projektityokalut raportti VIDICO
Projektityokalut raportti VIDICOProjektityokalut raportti VIDICO
Projektityokalut raportti VIDICOVIDICOhanke
 
JIT 2014 - Poimintoja muutoksista
JIT 2014 - Poimintoja muutoksistaJIT 2014 - Poimintoja muutoksista
JIT 2014 - Poimintoja muutoksistaKarolina Lehto
 
Tietojärjestelmien hankinta Suomessa 2013
Tietojärjestelmien hankinta Suomessa 2013Tietojärjestelmien hankinta Suomessa 2013
Tietojärjestelmien hankinta Suomessa 2013TIVIA ry
 
Innovaatioseteliopas - Mikä Innovaatioseteli on?
Innovaatioseteliopas - Mikä Innovaatioseteli on?Innovaatioseteliopas - Mikä Innovaatioseteli on?
Innovaatioseteliopas - Mikä Innovaatioseteli on?Kwork Innovaatiot
 
Lyhyt Opas Tietojärjestelmän Hankintaan v 0.3
Lyhyt Opas Tietojärjestelmän Hankintaan v 0.3Lyhyt Opas Tietojärjestelmän Hankintaan v 0.3
Lyhyt Opas Tietojärjestelmän Hankintaan v 0.3MP-Plan Oy
 
DigiKilta: GDPR-valmistelut – sisällön- ja palveluntuottajan näkökulma 2016-2...
DigiKilta: GDPR-valmistelut – sisällön- ja palveluntuottajan näkökulma 2016-2...DigiKilta: GDPR-valmistelut – sisällön- ja palveluntuottajan näkökulma 2016-2...
DigiKilta: GDPR-valmistelut – sisällön- ja palveluntuottajan näkökulma 2016-2...Suomen eOppimiskeskus ry
 
Creuna: Digin 7 kuolemansyntiä
Creuna: Digin 7 kuolemansyntiäCreuna: Digin 7 kuolemansyntiä
Creuna: Digin 7 kuolemansyntiäcreuna_fi
 
AgileTool ja ketterät vaatimukset verkkopalvelulle
AgileTool ja ketterät vaatimukset verkkopalvelulleAgileTool ja ketterät vaatimukset verkkopalvelulle
AgileTool ja ketterät vaatimukset verkkopalvelulleM. Muhonen
 
Haaga-Helian erikoistumisopinnot sähköinen markkinointi: Kehittämistyö
Haaga-Helian erikoistumisopinnot sähköinen markkinointi: KehittämistyöHaaga-Helian erikoistumisopinnot sähköinen markkinointi: Kehittämistyö
Haaga-Helian erikoistumisopinnot sähköinen markkinointi: KehittämistyöAtte Järvelä
 
9 faktaa teknologiahankkeista
9 faktaa teknologiahankkeista9 faktaa teknologiahankkeista
9 faktaa teknologiahankkeistaSysart Oy
 
Sosiaalitoimisto 2.0. Ajatuksia rivien välistä, taustalta ja työn jälkeen. Ii...
Sosiaalitoimisto 2.0. Ajatuksia rivien välistä, taustalta ja työn jälkeen. Ii...Sosiaalitoimisto 2.0. Ajatuksia rivien välistä, taustalta ja työn jälkeen. Ii...
Sosiaalitoimisto 2.0. Ajatuksia rivien välistä, taustalta ja työn jälkeen. Ii...Socca_osaamiskeskus
 

Similar to Tarpeen jatkuva kirkastaminen tuottaa parempia ohjelmistoprojekteja (20)

Avoimen tuotteen hallinta
Avoimen tuotteen hallintaAvoimen tuotteen hallinta
Avoimen tuotteen hallinta
 
Hankekoulu presentaatio koralli_21_3_13
Hankekoulu presentaatio koralli_21_3_13Hankekoulu presentaatio koralli_21_3_13
Hankekoulu presentaatio koralli_21_3_13
 
Lupapiste asiakaspäivät FAQ
Lupapiste asiakaspäivät FAQLupapiste asiakaspäivät FAQ
Lupapiste asiakaspäivät FAQ
 
Avoimen lähdekoodin raamimalli ruotsissa
Avoimen lähdekoodin raamimalli ruotsissaAvoimen lähdekoodin raamimalli ruotsissa
Avoimen lähdekoodin raamimalli ruotsissa
 
Digitaalisen palvelun kehittäminen
Digitaalisen palvelun kehittäminenDigitaalisen palvelun kehittäminen
Digitaalisen palvelun kehittäminen
 
ValueFrame - myynnistä toimitukseen -seminaari 17.11.2011 (id 2134) (id 2212)
ValueFrame - myynnistä toimitukseen -seminaari 17.11.2011 (id 2134) (id 2212)ValueFrame - myynnistä toimitukseen -seminaari 17.11.2011 (id 2134) (id 2212)
ValueFrame - myynnistä toimitukseen -seminaari 17.11.2011 (id 2134) (id 2212)
 
Projektityokalut raportti VIDICO
Projektityokalut raportti VIDICOProjektityokalut raportti VIDICO
Projektityokalut raportti VIDICO
 
JIT 2014 - Poimintoja muutoksista
JIT 2014 - Poimintoja muutoksistaJIT 2014 - Poimintoja muutoksista
JIT 2014 - Poimintoja muutoksista
 
Tietojärjestelmien hankinta Suomessa 2013
Tietojärjestelmien hankinta Suomessa 2013Tietojärjestelmien hankinta Suomessa 2013
Tietojärjestelmien hankinta Suomessa 2013
 
Innovaatioseteliopas - Mikä Innovaatioseteli on?
Innovaatioseteliopas - Mikä Innovaatioseteli on?Innovaatioseteliopas - Mikä Innovaatioseteli on?
Innovaatioseteliopas - Mikä Innovaatioseteli on?
 
Lyhyt Opas Tietojärjestelmän Hankintaan v 0.3
Lyhyt Opas Tietojärjestelmän Hankintaan v 0.3Lyhyt Opas Tietojärjestelmän Hankintaan v 0.3
Lyhyt Opas Tietojärjestelmän Hankintaan v 0.3
 
DigiKilta: GDPR-valmistelut – sisällön- ja palveluntuottajan näkökulma 2016-2...
DigiKilta: GDPR-valmistelut – sisällön- ja palveluntuottajan näkökulma 2016-2...DigiKilta: GDPR-valmistelut – sisällön- ja palveluntuottajan näkökulma 2016-2...
DigiKilta: GDPR-valmistelut – sisällön- ja palveluntuottajan näkökulma 2016-2...
 
Creuna: Digin 7 kuolemansyntiä
Creuna: Digin 7 kuolemansyntiäCreuna: Digin 7 kuolemansyntiä
Creuna: Digin 7 kuolemansyntiä
 
AgileTool ja ketterät vaatimukset verkkopalvelulle
AgileTool ja ketterät vaatimukset verkkopalvelulleAgileTool ja ketterät vaatimukset verkkopalvelulle
AgileTool ja ketterät vaatimukset verkkopalvelulle
 
Asiakas- ja toimintalähtöisen digikehittämisen toimintamalli
Asiakas- ja toimintalähtöisen digikehittämisen toimintamalliAsiakas- ja toimintalähtöisen digikehittämisen toimintamalli
Asiakas- ja toimintalähtöisen digikehittämisen toimintamalli
 
webimprovements.com-esittely
webimprovements.com-esittelywebimprovements.com-esittely
webimprovements.com-esittely
 
Haaga-Helian erikoistumisopinnot sähköinen markkinointi: Kehittämistyö
Haaga-Helian erikoistumisopinnot sähköinen markkinointi: KehittämistyöHaaga-Helian erikoistumisopinnot sähköinen markkinointi: Kehittämistyö
Haaga-Helian erikoistumisopinnot sähköinen markkinointi: Kehittämistyö
 
Avoin lähdekoodi Suomessa
Avoin lähdekoodi SuomessaAvoin lähdekoodi Suomessa
Avoin lähdekoodi Suomessa
 
9 faktaa teknologiahankkeista
9 faktaa teknologiahankkeista9 faktaa teknologiahankkeista
9 faktaa teknologiahankkeista
 
Sosiaalitoimisto 2.0. Ajatuksia rivien välistä, taustalta ja työn jälkeen. Ii...
Sosiaalitoimisto 2.0. Ajatuksia rivien välistä, taustalta ja työn jälkeen. Ii...Sosiaalitoimisto 2.0. Ajatuksia rivien välistä, taustalta ja työn jälkeen. Ii...
Sosiaalitoimisto 2.0. Ajatuksia rivien välistä, taustalta ja työn jälkeen. Ii...
 

More from Marko Taipale

Finding a product that people want to buy and use
Finding a product that people want to buy and useFinding a product that people want to buy and use
Finding a product that people want to buy and useMarko Taipale
 
Mashing up customers, users, product and business
Mashing up customers, users, product and businessMashing up customers, users, product and business
Mashing up customers, users, product and businessMarko Taipale
 
How do we use lean startup in service development
How do we use lean startup in service developmentHow do we use lean startup in service development
How do we use lean startup in service developmentMarko Taipale
 
6+ keinoa tuottaa arvoa projektissa
6+ keinoa tuottaa arvoa projektissa6+ keinoa tuottaa arvoa projektissa
6+ keinoa tuottaa arvoa projektissaMarko Taipale
 
Osaaminen uuden yrityksen johtajan näkökulmasta
Osaaminen uuden yrityksen johtajan näkökulmastaOsaaminen uuden yrityksen johtajan näkökulmasta
Osaaminen uuden yrityksen johtajan näkökulmastaMarko Taipale
 
Confessions of a Coach
Confessions of a CoachConfessions of a Coach
Confessions of a CoachMarko Taipale
 
Product Owners, Santa and other Goblins
Product Owners, Santa and other GoblinsProduct Owners, Santa and other Goblins
Product Owners, Santa and other GoblinsMarko Taipale
 
From a concept to viable business — How do we know if we are building the rig...
From a concept to viable business — How do we know if we are building the rig...From a concept to viable business — How do we know if we are building the rig...
From a concept to viable business — How do we know if we are building the rig...Marko Taipale
 
Agile & Lean at Tekes
Agile & Lean at TekesAgile & Lean at Tekes
Agile & Lean at TekesMarko Taipale
 
Teknisen taitamisen merkitys ketteryydessä - näpertelyä vai elinehto?
Teknisen taitamisen merkitys ketteryydessä - näpertelyä vai elinehto?Teknisen taitamisen merkitys ketteryydessä - näpertelyä vai elinehto?
Teknisen taitamisen merkitys ketteryydessä - näpertelyä vai elinehto?Marko Taipale
 
Julkishallinnon IT-hankinnat @Mearra
Julkishallinnon IT-hankinnat @MearraJulkishallinnon IT-hankinnat @Mearra
Julkishallinnon IT-hankinnat @MearraMarko Taipale
 
Showing the unseen @Scan-Agile 2012
Showing the unseen @Scan-Agile 2012Showing the unseen @Scan-Agile 2012
Showing the unseen @Scan-Agile 2012Marko Taipale
 
How to be a Lean Product Developer? @Agile Riga Day 2012
How to be a Lean Product Developer? @Agile Riga Day 2012How to be a Lean Product Developer? @Agile Riga Day 2012
How to be a Lean Product Developer? @Agile Riga Day 2012Marko Taipale
 
Maneuver Warfare and Other Badass Habits of a Lean Product Developer

Maneuver Warfare and Other Badass Habits of a Lean Product Developer
Maneuver Warfare and Other Badass Habits of a Lean Product Developer

Maneuver Warfare and Other Badass Habits of a Lean Product Developer
Marko Taipale
 
Provocation to the Product Owner challenge - Agile Coaching Circle
Provocation to the Product Owner challenge - Agile Coaching CircleProvocation to the Product Owner challenge - Agile Coaching Circle
Provocation to the Product Owner challenge - Agile Coaching CircleMarko Taipale
 
Agile Finland Coaching Circle - intro
Agile Finland Coaching Circle - introAgile Finland Coaching Circle - intro
Agile Finland Coaching Circle - introMarko Taipale
 
Continuous Deployment – Nextdoor.fi released every day at Scan-Agile 2011
Continuous Deployment – Nextdoor.fi released every day at Scan-Agile 2011Continuous Deployment – Nextdoor.fi released every day at Scan-Agile 2011
Continuous Deployment – Nextdoor.fi released every day at Scan-Agile 2011Marko Taipale
 
Case Nextdoor.fi at LESS2010
Case Nextdoor.fi at LESS2010Case Nextdoor.fi at LESS2010
Case Nextdoor.fi at LESS2010Marko Taipale
 
Lean Startup for AaltoES Summer of Startups
Lean Startup for AaltoES Summer of StartupsLean Startup for AaltoES Summer of Startups
Lean Startup for AaltoES Summer of StartupsMarko Taipale
 
8 lessons learned from becoming agile
8 lessons learned from becoming agile8 lessons learned from becoming agile
8 lessons learned from becoming agileMarko Taipale
 

More from Marko Taipale (20)

Finding a product that people want to buy and use
Finding a product that people want to buy and useFinding a product that people want to buy and use
Finding a product that people want to buy and use
 
Mashing up customers, users, product and business
Mashing up customers, users, product and businessMashing up customers, users, product and business
Mashing up customers, users, product and business
 
How do we use lean startup in service development
How do we use lean startup in service developmentHow do we use lean startup in service development
How do we use lean startup in service development
 
6+ keinoa tuottaa arvoa projektissa
6+ keinoa tuottaa arvoa projektissa6+ keinoa tuottaa arvoa projektissa
6+ keinoa tuottaa arvoa projektissa
 
Osaaminen uuden yrityksen johtajan näkökulmasta
Osaaminen uuden yrityksen johtajan näkökulmastaOsaaminen uuden yrityksen johtajan näkökulmasta
Osaaminen uuden yrityksen johtajan näkökulmasta
 
Confessions of a Coach
Confessions of a CoachConfessions of a Coach
Confessions of a Coach
 
Product Owners, Santa and other Goblins
Product Owners, Santa and other GoblinsProduct Owners, Santa and other Goblins
Product Owners, Santa and other Goblins
 
From a concept to viable business — How do we know if we are building the rig...
From a concept to viable business — How do we know if we are building the rig...From a concept to viable business — How do we know if we are building the rig...
From a concept to viable business — How do we know if we are building the rig...
 
Agile & Lean at Tekes
Agile & Lean at TekesAgile & Lean at Tekes
Agile & Lean at Tekes
 
Teknisen taitamisen merkitys ketteryydessä - näpertelyä vai elinehto?
Teknisen taitamisen merkitys ketteryydessä - näpertelyä vai elinehto?Teknisen taitamisen merkitys ketteryydessä - näpertelyä vai elinehto?
Teknisen taitamisen merkitys ketteryydessä - näpertelyä vai elinehto?
 
Julkishallinnon IT-hankinnat @Mearra
Julkishallinnon IT-hankinnat @MearraJulkishallinnon IT-hankinnat @Mearra
Julkishallinnon IT-hankinnat @Mearra
 
Showing the unseen @Scan-Agile 2012
Showing the unseen @Scan-Agile 2012Showing the unseen @Scan-Agile 2012
Showing the unseen @Scan-Agile 2012
 
How to be a Lean Product Developer? @Agile Riga Day 2012
How to be a Lean Product Developer? @Agile Riga Day 2012How to be a Lean Product Developer? @Agile Riga Day 2012
How to be a Lean Product Developer? @Agile Riga Day 2012
 
Maneuver Warfare and Other Badass Habits of a Lean Product Developer

Maneuver Warfare and Other Badass Habits of a Lean Product Developer
Maneuver Warfare and Other Badass Habits of a Lean Product Developer

Maneuver Warfare and Other Badass Habits of a Lean Product Developer

 
Provocation to the Product Owner challenge - Agile Coaching Circle
Provocation to the Product Owner challenge - Agile Coaching CircleProvocation to the Product Owner challenge - Agile Coaching Circle
Provocation to the Product Owner challenge - Agile Coaching Circle
 
Agile Finland Coaching Circle - intro
Agile Finland Coaching Circle - introAgile Finland Coaching Circle - intro
Agile Finland Coaching Circle - intro
 
Continuous Deployment – Nextdoor.fi released every day at Scan-Agile 2011
Continuous Deployment – Nextdoor.fi released every day at Scan-Agile 2011Continuous Deployment – Nextdoor.fi released every day at Scan-Agile 2011
Continuous Deployment – Nextdoor.fi released every day at Scan-Agile 2011
 
Case Nextdoor.fi at LESS2010
Case Nextdoor.fi at LESS2010Case Nextdoor.fi at LESS2010
Case Nextdoor.fi at LESS2010
 
Lean Startup for AaltoES Summer of Startups
Lean Startup for AaltoES Summer of StartupsLean Startup for AaltoES Summer of Startups
Lean Startup for AaltoES Summer of Startups
 
8 lessons learned from becoming agile
8 lessons learned from becoming agile8 lessons learned from becoming agile
8 lessons learned from becoming agile
 

Tarpeen jatkuva kirkastaminen tuottaa parempia ohjelmistoprojekteja

  • 1. 2/2013 OSAAMINEN KUNTOON Olemme uudistaneet sivumme! käy klikkaamassa > www.pry.fi Projektiyhdistyksen suuret saappaat s. 4-5 Oi Suomi, päiväs' vielä koittaa s. 6-9 Comparing PM Certifications s. 20-22 Suomalaisorganisaatiot Megasuuntauksen jälkijunassa? s. 16-18 Projektitoiminnan menestysresepti! IPMA Delta case: Swisscom IT Services s. 28-31 Puolivallaton projektinjohtaja s. 100-105
  • 2. Osaaminen kuntoon Tarpeen jatkuva kirkastaminen tuottaa Parempia ohjelmistoprojekteja Teksti: Marko Taipale 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 toimittajan 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 varmalle epäonnistumiselle. Onnistuakseen paremmin, tilaajan tulee itse kirkastaa tarvettaan 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. 42
  • 3. Ratkaisu edellä On tärkeää, että jokainen ohjelmistoprojekti nähdään myös toiminnan kehittämisen projektina Tarvetta kirkastetaan jatkuvasti Pieleen menneen projektin jälkeen tilaaja pohtii, mitä hänen ja hänen sidosryhmiensä pitäisi tarpeestaan ymmärtää, jotta ohjelmistoprojekti voisi tuottaa tarpeenmukaisia ratkaisuja. Hän listaa: - Nykyiset prosessit, joita ohjelmisto tulee jollain tapaa palvelemaan - Tulevaisuuden prosessit, joissa tietojärjestelmä hoitaa oman osuutensa - Kuka käyttää tätä järjestelmää ja mihin? - Mitä tarpeita, toiminnallisia tai laadullisia, tähän ohjelmistoon tai koko prosessiin liittyy? - Mihin tekniseen ja toiminnalliseen ympäristöön ohjelmisto tulee osaksi? - Mitä riskejä tähän kokonaisuuteen liittyy ja mitä minun pitää päättää nyt, mitä voin päättää myöhemmin? Tarpeen mukainen ratkaisu Tarpeen jatkuva kirkastaminen Projektin tilaaja on tehnyt liiketoimintalaskelman ja päättää tilata uuden ohjelmistoprojektin. Projektin toimittaja tulee paikalle ja sitoutuu toimittamaan. Parin vuoden päästä ohjelmistoa otetaan käyttöön. Tarkastelen tätä lähestymistapaa kuvan 1 mukaisella kuvaajalla. Tyypillinen tilaajan lähtökohta on epäselvä kuvitelma 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 ohjelmiston kuitenkin toivotaan täyttävän jokin tunnistetuista tarpeista ja täten päätetään aloittaa ohjelmistoprojekti. 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 yhteydessä esiintyy joukko ongelmia: tuotettu ratkaisu ei palvelekaan käyttäjiä, eikä se sovikaan yhteen tilaajan yrityksen toimintatapojen kanssa ja muuttaa vain vanhan toimintatavan sähköiseksi. Ongelmat tuottavat paljon muutospyyntöjä (kohta 2) ja niiden seurauksena ohjelmistoprojekti ylittää taloudelliset sekä ajalliset raamit. Ja mikä pahinta, tilaaja voi silti todeta toimineensa 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 pieleen. 2 1 Epäselvyys Tekninen ratkaisu Kuva 1. ERGMANN Attorneys at Law Teollisuuden asianajotoimisto Projektirakentaminen . Energia . Teknologia Asianajotoimisto Bergmann Oy Eteläranta 4 B 9 00130 Helsinki p. +358 9 6962 070 office@bergmann.fi www.bergmann.fi PROJEKTITOIMINTA 2/2013 43
  • 4. Tarpeen jatkuva kirkastaminen Tarpeen mukainen ratkaisu 4 2 3 1 Epäselvyys Tekninen ratkaisu Kuva 2. Tilaaja lähtee työstämään tarpeenmukaista ratkaisua yhteistyössä toimittajan 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. Tarkastelemalla aikaisempia hankkeitaan hän on oppinut, että tarve tai siihen sovitettu 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öytää ne kohdat, joiden ratkaiseminen on nyt välttämätöntä. Tilaaja osallistaa Osallistaminen sitouttaa sidosryhmän ratkaisemaan yhteisiä haasteita ja auttaa sisäistämään, mistä oikein on kysymys sidosryhmän pohtimaan nykyistä toimintatapaa ja tulevaa muutosta, missä uusi ohjelmisto hoitaa omaa tonttiansa. Osallistaminen sitouttaa sidosryhmän ratkaisemaan yhteisiä haasteita ja auttaa 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 kohdistuneita 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 iteratiiviselle oppimiselle. Oppiminen konkretisoituu tilaajalle siten, että hän ymmärtää paremmin oman tarpeensa. Toimittaja pystyy puolestaan kohdistamaan ratkaisun paremmin tilaajan tarpeeseen. Oppimisen myötä molemmille osapuolille kirkastuu, kuinka ratkaisu soveltuu ympäristöön. Tilaajan, toimittajan ja sidosryhmien osallistaminen jatkuu koko projektin ajan, jotta tarpeenmukaisesta ratkaisusta voidaan varmistua loikka-loikalta. Tarinan opetus Tarinan tarkoitus on osoittaa, että olitpa sitten ohjelmistoprojektin ostaja tai yrityksen sisäinen tilaaja, tarpeen kirkastamiseen kannattaa kiinnittää huomiota. On tärkeää, että jokainen ohjelmistoprojekti nähdään myös toiminnan kehittämisen projektina, mikä korostaa jatkuvan tarpeen kirkastamisen merkitystä entisestään. Tarpeenmukaisuutta vaalimalla tilaaja saa paremman 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 tarpeenmukainen ratkaisu – ratkaisu, joka on löytynyt yhteistyössä toimittajan ja oman sidosryhmän kanssa. Marko Taipale toimii johtavana konsulttina Goseilla ja kehittää ketterään hankintaan liittyviä palveluita hankintavalmistelu.fi:ssa. marko.taipale@gosei.fi +358 40 578 6447 twitter: @markotaipale 44