Sitoumusten hallinta ohjelmistoprojektisopimuksissa

Luonnos artikkeliksi oikeustieteelliseen julkaisuun Olli Pitkänen, Sari Kela, Jyrki Kontio, Reijo Sulonen Sitoumusten hallinta ohjelmistoprojektisopimuksissa 1 JOHDANTO Kirjoitetun lain ja oikeustapausten kautta muotoutunut sopimusoikeus ei riittävästi pysty vastaamaan niihin käytännön kysymyksiin, joiden kanssa keskenään sopimuksia tekevät yritykset joutuvat nykyisin painiskelemaan. Sopimusoikeuden oppikirjojen mukaisesti laaditut sopimukset ovat kyllä päteviä ja niiden avulla tuomioistuin pystyy yleensä löytämään laillisen ratkaisun osapuolten välisiin riitoihin. Nykyiset sopimukset eivät sen sijaan tarpeeksi tue menestyvää yritystoimintaa, projektien etenemistä sekä taloudellisesti ja liiketoiminnallisesti järkevien toimintatapojen muotoilemista. Erityisesti ongelma korostuu nopeasti kehittyvillä aloilla, kuten ohjelmistoteollisuudessa. Ulkomailla sopimusoikeuden uudistamisen tarvetta on jonkin verran käsitelty (esim. [38]). Suomessa sen sijaan keskustelu perinteisten ajatusmallien muutostarpeesta on ollut tähän asti vähäistä. Viitteitä uudesta ajattelusta sopimusoikeudessa on ollut havaittavissa esimerkiksi Wilhelmssonin ja Pöyhösen teoksissa, mutta vasta Nystén-Haaralan väitöskirjassa [34] ja artikkelissa Sopimusoikeus ja sopimusten hallinta [35] on selkeästi tuotu esiin uudistuksen tarve. Teknillisessä korkeakoulussa ohjelmistotuotannon tutkimusryhmässä (SEG) on jo usean vuoden ajan tutkittu, minkälaisilla sopimuksilla tai muilla sitoumuksilla voitaisiin nykyistä paremmin auttaa ohjelmistoprojekteja onnistumaan. Tutkimuksessamme pyrimme ottamaan huomioon sekä oikeudelliset, taloudelliset että tekniset näkökulmat. Tämän vuoksi emme voi soveltaa yksinomaan perinteisiä oikeustieteellisiä tutkimusmenetelmiä, vaan käytämme runsaasti myös case-tutkimuksen ja muun empiirisen tutkimuksen menetelmiä. Tutkimuksen tuloksena on rakennettu artikkelissa esitettävä sitoumusten hallinnan malli. Sen tarkoituksena on erityisesti tarjota parempaa tukea ohjelmistotuotannon sopimusten määrittelyyn. Mallin avulla voidaan valita toimintasuunnitelma sitoumusten määrittelemiseksi ja niihin liittyvien riskien tunnistamiseksi. Mallin kehittäminen jatkuu edelleen, mutta jo tutkimuksen tässä vaiheessa on selvästi todettavissa, että sopimusten ja sitoumusten hallinnan muiden osa-alueiden kehittäminen auttaa ohjelmistoprojekteja menestymään nykyistä paremmin. Viime aikoina tutkimuksemme painopiste on siirtynyt muihin kuin tässä artikkelissa esitettäviin sitoumuksen hallinnan osa-alueisiin, muun muassa

sitoumusten dokumentointiin, näkyvyyteen ja hierarkiaan sekä verkostoitumiseen liittyviin kysymyksiin. Lisäksi osallistumme tutkimustyöhön, jota Teknillisen korkeakoulun ja Helsingin yliopiston yhteinen tutkimuslaitos, Helsinki Institute for Information Technology (HIIT) tekee Internetiin liittyvien aineettomien oikeuksien hallinnasta [37] professori Jukka Kemppisen johdolla. 2 SITOUMUSTEN HALLINTA Ohjelmistoprojektiin voi osallistua ihmisiä monista organisaatioista ja oikeushenkilöistä. Ohjelmistoalalla tyypillisissä alihankintaverkostoissa osallistuvien yritysten määrä voi olla suurikin. Yhteistyö ohjelmiston kehittämiseksi vaatii aina sitoumuksia kaikilta projektin osapuolilta: esimerkiksi ohjelmiston käyttäjien on sitouduttava esittämään vaatimuksia ja antamaan palautetta sekä rahoittamaan projekti, kehittäjien puolestaan on tarjottava työpanoksensa, taitonsa ja muut tarpeelliset resurssit projektin toteuttamiseksi sovitussa aikataulussa. Ohjelmistoprojektit ovat tyypillisesti monelta osin vaikeammin ennakoitavia kuin ns. perinteisten teollisuudenalojen projektit. Sitoutuminen on siten yleensä tehtävä jo siinä vaiheessa, kun projektiin vielä liittyy huomattavia epävarmuustekijöitä. Hyviä malleja ja ohjeita, jotka auttaisivat ohjelmistoammattilaista sopimusten ja muiden sitoumusten tekemisessä ei juurikaan ole. Nykyiset sopimuskäytännöt ja mallit eivät riittävästi huomioi muun muassa ohjelmistotuotantoon liittyvää epävarmuutta. Sitoumuksilla tarkoitetaan tässä kaikkia niitä sitoumuksia, joita projektin osapuolet tekevät riippumatta siitä tuleeko niitä oikeudellisesti arvioida esimerkiksi sopimuksina. Kirjallinen projektisopimus ja siihen liittyvä projektisuunnitelma ovat luonnollisesti selkein ja suositeltavin tapa käytännössä tuoda julki osapuolten väliset sitoumukset. Sitoumusten hallinta tarkoittaa prosessia, jolla määritellään projektin osapuolten sitoumukset sekä ylläpidetään ja päivitetään näitä sitoumuksia projektin kuluessa. Kyseessä on projektijohtamisen osaalue, jossa tietyillä toimenpiteillä, prosesseilla ja taidoilla varmistetaan, että osapuolten sitoumukset ovat tiedossa, että ne on tehty tietoisesti ja että niitä ylläpidetään koko projektin ajan. Sitoumusten määrittely on osa sitoumusten hallintaa. Se viittaa joko dokumentoituun joukkoon sitoumuksia tai prosessiin, jolla sitoumukset määritellään. Tämän artikkelin näkökulmasta katsottuna sitoumusten määrittely tarkoittaa projektin alussa suoritettavaa joukkoa toimenpiteitä, joiden tarkoituksena on määritellä projektissa tarvittavien sitoumusten laajuus ja taso. 3 SITOUMUSTEN HALLINTAAN LIITTYVÄ AIKAISEMPI TUTKIMUS JA AINEISTOT Tämä artikkeli perustuu 20:nnessa International Conference on Software Engineering konferenssissa (ICSE 98) Kiotossa, Japanissa julkaistuun artikkeliin [30] sekä sen jälkeen Teknillisessä korkeakoulussa jatkettuun tutkimustyöhön. Aikaisemmin sitoumusten hallintaa ei ole juurikaan käsitelty tästä näkökulmasta. Sekä henkilöstön (esimerkiksi [10, 19]) että johdon (esimerkiksi [9, 12, 26, 31]) sitoutumista on korostettu monissa projekteja ja muita hankkeita käsittelevissä teoksissa. Sen sijaan sitoumusten määrittelyä osapuolten tasolla projektin alkaessa ei juurikaan ole käsitelty. 2

Ohjelmistoprojekteja koskevat sopimukset ja projektisuunnitelmat tarjoavat perusmallit ja ohjeet projektin sitoumusten määrittämiselle. Joitain standardeja ja esimerkkejä on olemassa siitä, mitä tällaisten sopimusten ja suunnitelmien tulisi sisältää. Nämä eivät kuitenkaan kata kaikkia sitoumusten hallinnan osa-alueita. Projektisuunnitelmamallit korostavat lähinnä aikatauluun ja kustannuksiin liittyviä tavoitteita, määrittelevät jossain määrin käytettävän prosessin ja edellyttävät joidenkin riskienhallintaan liittyvien perustoimintojen määrittelyä. Ne eivät sen sijaan tuo esiin projektin taustalla olevia motiiveja eivätkä projektien ongelmien hallintaan liittyviä kysymyksiä [20]. Ne eivät myöskään mitenkään esitä sitoumusten hallinnan prosessia. Edellä mainitut lähestymistavat ja aineistot eivät auta konkreettisesti päättämään, miten projektista tulisi sopia, mihin asioihin pitäisi sitoutua ja miten kaikkien projektin osapuolten tekemiä sitoumuksia voisi hallita. Vaikka parhaatkaan nykyiset käytännöt eivät juurikaan anna tukea, on kaikissa ohjelmistoprojekteissa kuitenkin pakko tehdä ja hallita sitoumuksia. 4 OHJELMISTOPROSESSI Tietokoneohjelmiston tekeminen on monivaiheinen prosessi. Jotta ohjelmistoprojektia koskevia sitoumuksia ja sopimuksia voisi tehdä, hallita ja tulkita oikein, on ymmärrettävä ohjelmiston valmistusprosessia. Alla esitetään sitoumusten hallintaan liittyvien piirteiden ymmärtämisen pohjaksi yksi mahdollinen ohjelmistotuotannon malli. Ohjelmistotuotanto on varsin nuori teollisuuden ala. Sen sanotaankin elävän vielä esiteollista aikaa: ohjelmistoteollisuudessa ei ole toistaiseksi pystytty kehittämään samanlaisia teollisia valmistusmenetelmiä ja prosesseja kuin perinteisemmillä teollisuuden aloilla. Käytännössä tämä näkyy siten, että tuotanto tapahtuu hyvin pitkälle käsityönä: ohjelmistojen suunnitteluun, ohjelmointiin ja testaukseen ei ole vielä saatavissa kovin paljoa automaattisia apuvälineitä. Seurauksena valmistusprosessin kesto ja kustannukset vaihtelevat suuresti aikatauluissa ja budjeteissa pysyminen on suorastaan harvinaista. Myös laatuongelmat saattavat olla merkittäviä. Tähän vaikuttaa myös merkittävästi se, että ohjelmistotuotannossa suunnittelun ja kehitystyön osuus on erittäin suuri kun taas lopputuotteen valmistaminen vaatii vain erittäin vähän resursseja. Niinpä ohjelmistotuotantoa olisikin monessa suhteessa paras verrata muiden alojen tuotekehitystoimintaan, jossa epävarmuudet myös ovat suuria. Ohjelmiston tuotantoprosessia voi mallittaa monella eri tavalla. Tähän on valittu jonkinlainen mukaelma klassisesta vesiputousmallista. On kuitenkin korostettava, että kyseessä on vain yksi tapa tulkita tuotantoprosessia. Esimerkiksi niin kutsuttu spiraalimalli antaa vesiputousmallia todellisemman kuvan siitä, miten tuotannossa usein toistetaan samoja vaiheita ja palataan edellisiin vaiheisiin tarkentamaan ja korjaamaan niiden tuloksia. [5, 6] Tällaiseen prosessiin pyrkivät muun muassa monet ohjelmistotuotteita valmistavat yritykset. Yksittäisen sovelluksen valmistaminen projektiluonteisesti sen sijaan on usein järkevää mallittaa vesiputouksena. Lisäksi on syytä huomata, että kuvattu malli on pitkälle idealisoitu. Käytännössä yrityksissä esiintyvät prosessit vain harvoin ovat yhtä selviä ja jakautuvat yhtä siististi eri vaiheisiin kuin kuvattavassa mallissa. Varsin usein ohjelmiston tuotantoprosessi muistuttaa enemmänkin kaaosta: prosessiin osallistuvat henkilöt koheltavat edestakaisin eri vaiheiden välillä tajuamatta jatkuvasti itsekään, mitä 3

vaihetta parhaillaan suorittavat. Tilanne lienee tässä suhteessa muuttumassa ja ohjelmistoprosessit ovat selkiytymässä ja kypsymässä. Mallin osalta on myös huomattava, että samat henkilöt yhdestä organisaatiosta voivat osallistuvat ohjelmiston tekemiseen kaikissa vaiheissa. Usein kuitenkin ohjelmiston tekemiseen osallistuu eri vaiheissa eri ihmisiä eri organisaatioista. ongelman analysointi määrittely suunnittelu ohjelman koodaaminen testaus käyttöönotto ja koulutus ylläpito Kuva 1 Ohjelmistoprosessi vesiputousmallin mukaisesti Prosessi alkaa asiakkaan ongelman analysoinnilla. Asiakas on yleensä tiedostanut jonkin osan ongelmastaan ja pyytää vaikkapa konsulttia selvittämään, miten ongelma voitaisiin ratkaista. Konsultti ammattitaitonsa ja kokemuksensa avulla pyrkii selvittämään ongelman ja sen syyt kokonaisuudessaan. Toisessa vaiheessa määritellään uuden järjestelmän tarve: minkälaisia palveluja tietokoneohjelmiston olisi tarjottava, jotta se voisi auttaa ongelmassa. Tässä vaiheessa ei vielä suunnitella ohjelmistoa lainkaan, vaan ainoastaan sitä, minkälaisia palveluja ohjelmiston tulisi tarjota käyttäjälleen. Tarpeiden määrittelyssä voidaan käyttää apuna erilaisia kuvausmenetelmiä ja kaavioita. Kolmannessa vaiheessa suunnitellaan ne toiminnot, jotka tietokoneohjelmistossa täytyy olla, jotta se täyttäisi edellisessä vaiheessa tehdyt määrittelyt. Tässä vaiheessa suunnitellaan yksityiskohtaisesti tulevan ohjelmiston ulkoinen ja sisäinen rakenne: tarvittavat algoritmit kehitetään tai valitaan olemassa olevista, tietorakenteet määritellään yksityiskohtaisesti, ohjelma jaetaan pieniin moduuleihin, jotka sitten kuvataan täsmällisesti. Vaiheen tuloksena on käytettävissä täsmälliset yksityiskohtaiset kaaviot ja kuvaukset, joiden perusteella atk-alan ammattilainen voi yksiselitteisesti ymmärtää, minkälainen ohjelmistosta on tulossa. Varsinaista ohjelmointia koodausta ei siis ole vielä tehty lainkaan. On huomattava, että edellisessä vaiheessa näkökulma oli vielä ongelmassa ja tarpeessa, tässä vaiheessa siirretään katse laadittavaan ohjelmaan. Niinpä edellisen vaiheen perusteella voitaisiin vielä suunnitella lähes äärettömän monta erilaista ohjelmaa, jotka kaikki täyttäisivät määritellyn tarpeen. Sen sijaan tässä vaiheessa tehdään ne valinnat, jotka johtavat yhteen tiettyyn ohjelmaan. Neljännessä vaiheessa ohjelma kirjoitetaan jollain ohjelmointikielellä. Ohjelmointi vaatii paljon taitoa ja huolellisuutta, mutta jos edelliset vaiheet on tehty oikein ja huolellisesti, tämä vaihe voi olla varsin 4

mekaaninen. Kyse on pääasiassa tehtyjen suunnitelmien koodaamisesta. Formalismi on eri kuin edellisessä vaiheessa, mutta uutta tietoa järjestelmästä tässä vaiheessa syntyy enää vähän tieto lähinnä muuttaa muotoaan. Viidennessä vaiheessa tehty ohjelma testataan virheiden löytämiseksi. Tämä vaihe edellyttää suurta huolellisuutta ja kurinalaisuutta, mutta on tehtävissä valmiiden periaatteiden mukaan. Testausmenetelmiä ei siis tarvitse keksiä joka kerta uudestaan. Riittää, että huolellisesti suunnitellaan, miten valittuja menetelmiä tällä kerralla sovelletaan. Itse asiassa testauskin kannattaisi yleensä suunnitella samalla, kun ohjelmisto suunnitellaan. Tällöin testausvaiheeseen ei jää edes suunnittelutyötä, vaan ainoastaan mekaanista testauksen suorittamista. Testattu ohjelmisto asennetaan asiakkaalle, asiakkaan henkilöstö koulutetaan käyttämään ohjelmistoa ja ohjelmisto voidaan ottaa käyttöön. Jatkossa ohjelmistoon tehdään muutoksia ja korjauksia sopimuksen mukaan. Tätä kutsutaan ohjelmiston ylläpidoksi. Siihen saattaa liittyä myös uusien ominaisuuksien lisäämistä ohjelmistoon, mikä puolestaan saattaa vaatia jopa erillisen projektin käynnistämistä. Näin ylläpitoon saattaa sisältyä kaikkia edellä kuvattuja vaiheita uudelleen ja uudelleen. Muutosten ja lisäysten tuloksena ohjelmistosta syntyy uusia versioita (engl. version, revision jne.). Siirtymistä uudempaan versioon kutsutaan päivitykseksi (engl. update, upgrade). Eri yrityksillä on varsin erilaisia tapoja nimetä tai numeroida tuoteversioitaan. Usein yritykset käyttävät sisäisessä kehitystyössään erilaista versiointia kuin asiakkaille suuntautuvassa markkinoinnissaan. Paitsi ajallisesti peräkkäisiä versioita, ohjelmistotuotteista tuodaan toisinaan markkinoille myös rinnakkaisia versioita. Esimerkiksi ilmaiseksi tai erittäin edullisesti asiakkaille tarjottavat kevytversiot on tarkoitettu tutustuttamaan asiakas tuotteeseen ja saamaan tämä myöhemmin siirtymään laajemman version käyttöön. Erilaisia alfa-, beta- ja muita esiversioita käytetään paitsi testaukseen myös asiakkaiden sitouttamiseen jo ennen varsinaisen tuotteen markkinoille tuomista (lock-in -ilmiöstä katso esim. [42]). Usein myös erotetaan toisistaan suuremmat ja pienemmät päivitykset (engl. major update, minor update). Suuren päivityksen tarkoituksena on yleensä tuoda ohjelmistoon oleellisia lisäominaisuuksia, kun taas pieni päivitys saattaa lähinnä korjata ohjelmistossa olleita virheitä. Esimerkiksi sopimustekstissä saattaa olla tarve erottaa nämä päivitykset toisistaan, mutta yksikäsitteisen määrittelyn kirjoittaminen ei ole helppoa. Ohjelmiston elinkaari päättyy, kun ohjelmisto poistetaan käytöstä. 5 SITOUMUSTEN MÄÄRITTELY Sitoumusten hallinnan mallissa osapuolten väliset sitoumukset on jaettu neljään eri sitoumusaiheeseen. Jaottelu pohjautuu case-tutkimuksiin sekä alan sopimusten analysoitiin. Sitoumusten tarkastelu mallin avulla auttaa osapuolia hahmottamaan projektin kannalta keskeiset sitoumusaiheet sekä ohjaa osapuolia kommunikoimaan oleellisista sitoumusaiheista. Samalla sitoumusaiheet muodostavat mallin, jota voidaan käyttää tarkistuslistana projektin sitoumuksia määriteltäessä. Taulukossa kuvataan yhteenveto sitoumusaiheista sekä kuhinkin sitoumusaiheeseen liittyviä sitoumuskohteita. 5

Sitoumusaihe Taustamotiivit Miksi projekti tehdään? Tavoitteet Mitä projektin tuloksena syntyy, milloin ja millä hinnalla? Prosessi Miten projekti tehdään? Riskien ja ongelmien hallinta Mitä jos jotain menee pieleen? Kuva 2 Sitoumusaiheet Sitoumuksen kohteita Liiketoiminnalliset tavoitteet Strategiset suunnitelmat ja aikomukset Yrityksen visio ja missio ja niiden liitynnät projektiin Projektin lopputulos Aikataulu Kustannukset Muut tavoitteet (uudelleenkäyttö, osaamisen kehittäminen jne.) Hallinnolliset menettelytavat Ohjelmistoprosessin vaatimukset Muutoksenhallinta Hyväksymismenettely Prosessimallit ja standardit Riskienhallintaprosessi Osapuolten välinen kommunikointi ja tiedonhallinta Oletukset Osapuolten yhteiset oletukset Riskien hallinta Riskienhallinnan ala Hyväksyttävät riskit Riskien vastuunjako Ongelmien hallinta Sopimusrikkomukset Vahingonkorvausvelvollisuus ja vastuunrajaukset Oikeuspaikka, sovellettava laki Seuraavassa tarkastellaan yleisesti eri sitoumusaiheita sekä yksityiskohtaisesti niitä sitoumusaiheisiin liittyviä sitoumuksen kohteita, joihin on havaittu liittyvän ohjelmistoprojektien yhteydessä erityisiä ongelmia. Tällaisia ovat ennen kaikkea aineettomia oikeuksia, riskienhallintaa ja vahingonkorvausta koskevat seikat. Ennen sitoumusaiheiden tarkastelua kuvataan lyhyesti ohjelmistoprojektin kannalta olennaisten sitoumusaiheiden valintaa. 6 SITOUMUSAIHEIDEN PAINOPISTEEN VALINTA Useimmissa projekteissa ei ole mahdollista etukäteen määritellä tyhjentävästi kaikkia sitoumuksia. Yleensä käytettävissä olevat tiedot ja resurssit riittävät vain osittaisen sitoumusmäärittelyn tekemiseen. Esimerkiksi jo projektin alkaessa voi olla selvää, että projektin tulokset, aikataulu tai menettelytavat muuttuvat useaan otteeseen projektin edetessä. Myöskään taloudellisesti ei ole mielekästä uhrata liikaa aikaa sellaisten asioiden määrittelyyn, jotka eivät ole projektin kannalta tärkeitä. Sitoumusmäärittelyssä 6

onkin keskityttävä niihin sitoumusaiheisiin, jotka ylipäätänsä ovat määriteltävissä ja jotka ovat projektin kannalta tärkeimpiä. Yksittäisellä projektilla voi olla paljon erilaisia ominaisuuksia, jotka vaikuttavat siihen, mitkä sitoumusaiheet tulisi määritellä. Määrääviä ominaisuuksia ovat muun muassa projektin koko, osapuolten lukumäärä, käytettävä prosessimalli, ohjelmiston osien uudelleenkäytön määrä, uusien teknologioiden käyttö sekä projektin luonne siinä mielessä, onko kyse organisaation sisäisestä projektista vai esimerkiksi asiakasprojektista. Projektin alussa kaikkein keskeisin ominaisuus on kuitenkin projektin yleinen riskitaso. Niinpä sillä tulisi olla eniten merkitystä valittaessa määriteltäviä sitoumusaiheita. Projektin yleisellä riskitasolla tarkoitetaan tässä osapuolten subjektiivista käsitystä siitä, miten vakavia riskejä kyseiseen projektiin liittyy verrattuna muihin projekteihin. Hyvin riskialttiissa projektissa, jossa riskit saattavat tehdä tavoitteet saavuttamattomiksi, saattaa olla turhaa sitoutua tiukasti tavoitteisiin. Parempi olisikin sellaisessa tilanteessa yleisesti kuvata taustamotiiveja, miksi projektiin ollaan ryhtymässä, ja keskittyä sitten siihen, miten projekti viedään läpi. Voidaan esimerkiksi sitoutua säännöllisiin tapaamisiin, muutostenhallintakäytäntöihin, raportointiin, tiedon vaihtoon ja niin edelleen. Keskitytään tavoitteisiin (tuotteeseen, täsmällisiin määrittelyihin jne.) ongelmien hallintaan Keskitytään motiiveihin prosessiin (muutosten hallintaan yms.) riskienhallintaan matala Riskitaso korkea Kuva 3 Riskitason vaikutus sitoumusaiheiden valintaan 7 TAUSTAMOTIIVIT Taustamotiiveilla tarkoitetaan muun muassa liiketoiminnallisia tavoitteita, joiden vuoksi osapuolet ylipäätään osallistuvat projektiin. Esimerkkinä voisi olla vaikkapa pystyä tarjoamaan parempaa asiakaspalvelua ja sen avulla saavuttaa parempi kilpailukyky, lisätä tuottavuutta tai vähentää 7

kustannuksia. Taustamotiivit kuvaavat siten lähinnä sopimuksen henkeä, kun taas tavoitteet määrittävät sopimuksen kirjaimen. Taustamotiivien kirjaamisella sopimukseen on kaksi tarkoitusta. Ensinnäkin ne auttavat osapuolia ymmärtämään toistensa todelliset motiivit ja edut, joita tavoitellaan. Näin projektin tavoitteet tulevat ymmärrettävämmiksi ja projektia voidaan suorittaa osapuolten edun kannalta tarkoituksenmukaisimmalla tavalla. Toinen taustamotiivien dokumentoinnin tarkoitus on tarjota ohjeita sen tulkitsemiseen, mihin osapuolet ovat projektin alussa sitoutuneet. Perinteisimmillään taustamotiivien dokumentointi auttaa sopimuksen tulkintatilanteissa. Erityisesti silloin, kun ulkopuolinen, vaikkapa tuomioistuin, joutuu tulkitsemaan sopimuksen sisältöä, voidaan hyödyntää kirjattuja taustamotiiveja sen selvittämiseksi, mikä on ollut osapuolten todellinen tahto sopimusta laadittaessa, sekä reaalisten argumenttien etsimiseksi. [16, 34, 35, 40] Monissa tilanteissa osapuolten saattaa olla vaikeaa kuvata muille osapuolille kaikkia taustamotiivejaan. Jotkut niistä saattavat olla luottamuksellisia, toiset muuten vain hankalia määritellä. Tutkimuksissamme onkin käynyt ilmi, ettei taustamotiiveja usein tuoda selvästi esille toiselle osapuolelle, saati kirjata sopimuksiin. Taustamotiivien mahdollisimman laaja ja avoin dokumentointi, joko sopimuksissa tai vähintäänkin muissa projektiin liittyvissä dokumenteissa on kuitenkin suositeltavaa. Näin erityisesti ohjelmistoprojektien yhteydessä. Edellä todetulla tavalla ohjelmistoprojektit ovat usein vaikeasti ennakoitavia projekteja. Tästä johtuen projektin tavoitteiden ja prosessinkin yksityiskohtainen kirjaaminen sopimuksiin voi olla vaikeampaa kuin on perinteisten teollisuudenalojen yhteydessä. Ohjelmistoprojektien yhteydessä on myös täysin mahdollista, etteivät osapuolet projektia aloittaessa ole vielä selvillä siitä mitä konkreettisia lopputuloksia projektissa pitäisi syntyä. Toisin sanoen lopputulokset hahmotuvat vasta projektin edetessä. Vastaavasti on tavallista, että projektin edetessä osapuolet muuttavat lopputuloksia koskevia tavoitteitaan. Kirjatut taustamotiivit toimivat edellä kuvatun kaltaisissa muutos- ja epävarmuustilanteissa perustana, jota vasten sopimusmuutoksista on helpompi päästä yhteisymmärrykseen. Erikseen on huomattava, että sopimustekstin muotoilulla on tehtävä selväksi, ettei taustamotiivien saavuttamatta jääminen sinällään aiheuta vahingonkorvausvelvollisuutta. Jos esimerkiksi tilaajan tuottavuuden lisääntyminen on määritelty taustamotiiviksi, toimittaja ei ole korvausvelvollinen, vaikkei tuottavuus lisääntyisikään, kunhan tavoitteet ja muut sopimusvelvollisuudet on tullut täytettyä. Sopimusta laadittaessa onkin kiinnitettävä huomiota siihen, mitkä asiat määritellään tavoitteiksi ja mitkä taustamotiiveiksi. 8 TAVOITTEET Jokaisessa projektissa tulisi ensi alkuun päästä yhteisymmärrykseen projektin tavoitteista. Niihin kuuluvat projektin lopputulokset (esimerkiksi vaatimusmäärittelyn mukainen ohjelmisto ja siihen liittyvät aineettomat oikeudet), laatutavoitteet, aikataulu, kustannukset ja muut vastaavat projektin ominaisuudet. Tavoitteiden luokittelemiseen voidaan tarvittaessa käyttää vaikkapa Riskit-menetelmän mukaista jakoa päämääriin (objective), pyrkimyksiin (driver) ja rajoitteisiin (constraint). [28] Päämäärällä tarkoitetaan saavutettavissa olevaa, hyvin määriteltyä tavoitetta, kuten ohjelmiston on pystyttävä suorittamaan toiminto X. Pyrkimys on sellainen tavoite, joka kertoo mihin päin pyritään ilman, että voitaisiin yksikäsitteisesti todeta, milloin tavoite on saavutettu. Pyrkimys voi olla esimerkiksi 8

parannetaan hakutoiminnon käytettävyyttä. Pyrkimykset ovat ongelmallisia, jos joudutaan arvioimaan sitä, ovatko osapuolet täyttäneet sitoumuksensa. Niinpä pyrkimyksiä tulisi välttää ja mieluummin muotoilla ne päämääriksi. Rajoite puolestaan ilmaisee, missä rajoissa projektissa saadaan liikkua. Tyypillisiä rajoitteita ovat muun muassa aikatauluun ja budjettiin liittyvät tavoitteet. Tosin päämäärän ja rajoitteen välinen ero saattaa olla vain näkökulmassa ja sanamuodossa: toinen osapuoli näkee saman tavoitteen päämääränä, toinen rajoitteena. Tavoitteet tulisi yleensä pyrkiä ilmoittamaan selkeästi toiselle osapuolelle. On kuitenkin huomattava, että toisen osapuoleen tavoitteet voivat sitoa myös toista osapuolta, vaikkei niistä olisi erikseen sovittu. Esimerkiksi jos toimittaja on ymmärtänyt, mihin tarkoitukseen tilaaja aikoo ohjelmistoa käyttää, toimittajan voidaan katsoa olevan sitoutunut toimittamaan tarkoituksenmukaisen ohjelmiston laajemminkin kuin mistä on erityisesti sovittu. [40] Usein asiakas tilaa toimittajalta erikseen osaprojekteja ohjelmistoprosessin eri vaiheisiin. Tällöin yksittäisen osaprojektin osalta saatetaan sopia varsin suppeista tavoitteista. Jos viimeisen osaprojektin tuloksena syntyvä ohjelmisto ei vastaakaan tilaajan tarkoitusta, vaikka se onkin osaprojektia koskevan sopimuksen kirjaimen mukainen, voidaan toimittajan vastuuta laajentaa sillä perusteella, että toimittaja on myös edellisten osaprojektien yhteydessä saanut tietoonsa tilaajan tavoitteita. Molempien osapuolten edun mukaista onkin ilmoittaa toiselle osapuolelle tavoitteistaan mahdollisimman selkeästi ja yksityiskohtaisesti ja toisaalta kertoa heti, jos jotkut toisen osapuolen tavoitteet eivät vaikuta saavutettavilta. 9 AINEETTOMAT OIKEUDET PROJEKTIN TAVOITTEINA Tietokoneohjelmisto on aineeton olio, jota suojaavat aineettomat oikeudet. Meillä ohjelmistojen keskeisin oikeudellinen suojamuoto on luovaa työtä yleisesti suojaava tekijänoikeus. Yhdysvalloissa ja monissa muissa maissa patentti on viime aikoina lisännyt merkitystään ohjelmistojen suojana. Euroopan unionin piirissä on parhaillaan käynnissä vilkas keskustelu siitä, tulisiko ohjelmistojen patentointi sallia täälläkin nykyistä laajemmin. On korostettava sitä, ettei tämä kehitys ole yksinomaan myönteistä, mutta juuri nyt patentin vahvistuva asema näyttää varsin vääjäämättömältä. [1, 13, 32, 33, 37, 41] Teknisestä näkökulmasta ohjelmistoprojektin tavoitteena on yleensä tuottaa tietyt vaatimukset täyttävä ohjelmisto määräajassa, sovituilla kustannuksilla. Valmiilla ohjelmistolla ei kuitenkaan oikeudellisesti ole paljoa merkitystä elleivät sitä koskevat oikeudet ole järjestetty osapuolten tarpeiden mukaisesti. Hieman kärjistäen voisi sanoa, että on saman tekevää valmistuuko ohjelmisto vai ei, jos tilaaja ei saa ohjelmistoon tarvitsemiaan oikeuksia. Näin ollen kysymys aineettomien oikeuksien järjestämisestä tulisi nähdä keskeisenä osana projektin tavoitteita. Eri osapuolilla saattaa olla varsin erilaiset tarpeet valmiin ohjelmiston osalta. Joku haluaa ehkä vain käyttää sitä itse, joku myydä käyttöoikeuksia myös muille, joku tehdä ohjelmistoon muutoksia ja joku käyttää sitä osana muiden ohjelmistojen kehitystyössä. Varsin tyypillisesti ohjelmistoprojektin alkuvaiheessa kaikki osapuolet haluavat kaikki oikeudet lopputulokseen itselleen. Tarkempi analyysi omista tarpeista voi kuitenkin paljastaa sen, ettei kaikkia oikeuksia suinkaan tarvita eikä niistä siis myöskään kannata maksaa (katso myös [42, s. 98 102]). Oikeaan win-win-tilanteeseen päästään, kun tunnistetaan omat ja muiden osapuolten todelliset tarpeet ja jaetaan ohjelmistoon kohdistuvat aineettomat oikeudet näiden tarpeiden mukaisesti. Usein saattaa unohtua esimerkiksi, että tilaajalle saattaa olla hyvinkin edullista, jos ohjelmistolla on käyttäjiä muissakin organisaatioissa. Tällöin muun 9

muassa ohjelmiston ylläpito ja jatkuvuus tyypillisesti paranevat merkittävästi ja tilaaja pääsee hyötymään laajemmasta käyttäjäverkostosta [42]. Toisaalta ohjelmisto itsessään tyypillisesti koostuu useanlaisista osista eli komponenteista, joihin saattaa kohdistua erilaisia aineettomia oikeuksia. Tätä ei yleensä sopimuksissa osata ottaa huomioon, vaan ohjelmistoa sekä siihen kohdistuvia oikeuksia ja vastuita käsitellään yhtenä kokonaisuutena. Edes ohjelmistoalalla yleisesti käytössä olevissa vakioehdoissa ei ole kunnolla osattu tehdä eroa erilaisten ohjelmiston osien välillä. Käytännössä komponentteja on kolmenlaisia. Ensinnäkin kyseisessä projektissa erityisesti tätä ohjelmistoa ja tätä tilaajaa varten luodut komponentit. Toiseksi saman tekijän luomat komponentit, joita ei ole luotu yksinomaan tätä tilaajaa varten, vaan joita on tarkoitus käyttää myös muiden projektien toteutuksessa. Kolmanneksi ohjelmistoissa käytetään kolmannen osapuolen luomia valmiita komponentteja. Ensimmäisen ryhmän komponentit, jotka siis on luotu kyseisessä projektissa erityisesti tätä ohjelmistoa ja tätä tilaajaa varten, ovat yleensä oikeudellisesti helpoimpia käsitellä. Niitä koskevista oikeuksista on tavallisesti mahdollista sopia varsin vapaasti. Voidaan vaikkapa sopia, että kaikki oikeudet näihin komponentteihin siirretään tilaajalle. Käytännössä tietysti esimerkiksi toimittajan pyrkimys ohjelmakoodin uudelleenkäyttöön tai tilaajan halu itse hallita käyttämiään ohjelmistoja lähdekooditasolla saattavat tosiasiassa vähentää neuvotteluvaraa. Tällainenkin komponentti saattaa kyllä loukata vaikkapa kolmannen patenttioikeutta, mutta etenkään tekijänoikeuden loukkauksesta ei yleensä ole pelkoa, jos komponentti on todella luotu kyseisessä projektissa. Edelleen toimittaja voi näiden komponenttien osalta esimerkiksi sitoutua varsin laajaan vastuuseen virheistä sekä takuuseen ja ylläpitovastuuseen, koska toimittaja tuntee nämä komponentit hyvin. Toisen ryhmän komponentteja ovat siis ne, jotka ovat saman tekijän luomia, mutta tarkoitettuja käytettäviksi myös muissa ohjelmistoissa. Niihin ei luonnollisestikaan voida antaa kaikkia oikeuksia tilaajalle. Toisaalta näidenkin komponenttien osalta toimittaja voi sitoutua samankaltaiseen vastuuseen virheistä, takuuseen ja ylläpitoon kuin ensimmäisenkin ryhmän komponenttien osalta. Käytännössä toisen ryhmän komponenttien ylläpito ja esimerkiksi uusien versioiden toimittaminen kaikille tilaajille, jotka käyttävät jotain tietyn komponentin versiota, on varsin hankalaa. Toimittajan ei pitäisi sopimuksessa sitoutua liian kevyesti kovin tiukkoihin ehtoihin tässä suhteessa selvittämättä ensin, millaisia tuotteenhallinnallisia ongelmia siitä voi aiheutua. Kolmannen ryhmän komponentit eivät ole toimittajan itsensä tekemiä. Niinpä niiden käyttöä säätelevät kolmannen kanssa sovitut ehdot. Toimittaja ei tietenkään voi antaa asiakkaalleen parempaa oikeutta näihin komponentteihin kuin mitä on itse saanut kolmannelta osapuolelta. Myös vastuun virheistä, takuun ja ylläpidon osalta on otettava huomioon se, mihin komponenttien tekijä on suostunut sitoutumaan. Tämä ei tarkoita sitä, etteikö ohjelmiston toimittaja voisi komponenttien osalta ottaa laajempaakin vastuuta kuin komponenttien tekijä on suostunut ottamaan, jos se liiketoiminnallisesti nähdään järkeväksi. 10

10 PROSESSI Prosessi määrittelee sen, miten tavoitteet aiotaan saavuttaa, miten osapuolet toimivat yhteistyössä ja miten ohjelmisto kehitetään. Tähän sisältyy toisaalta hallinnollisia menettelytapoja, kuten projektikokousten aikataulujen ja työjärjestysten määrittelyt. Toisaalta siihen kuuluu itse ohjelmistokehitysprosessin määrittely. Tässä voidaan viitata esimerkiksi erilaisiin ohjelmistojen elinkaarimalleihin, viitekehyksiin ja standardeihin, kuten ISO 9000-3 [22] tai SEI:n CMMkypsyysmalliin [36]. Voidaan myös sopia esimerkiksi, että käytetään prototyyppilähestymistapaa ja että käyttöliittymän ensimmäinen prototyyppi toteutetaan projektin ensimmäisen vaiheen aikana. Ohjelmistoprojekteissa yhteydessä erittäin tärkeitä prosessiseikkoja ovat myös muutosmenettelyä sekä lopputulosten hyväksymismenettelyä koskevat seikat. Muutosmenettelyn osalta on tavallista sopia, että sopimusta voidaan muuttaa ainoastaan molempien osapuolten kirjallisella sopimuksella. Tällainen muutosmenettely lauseke on sinällään tarpeellinen. Lauseke ei kuitenkaan yksinään anna tukea sille, kuinka muutokset käytännössä olisi toteutettava. Ainakin sellaisten projektien yhteydessä, jossa jo projektia aloitettaessa on selvillä, että projektia joudutaan oleellisilta osin täsmentämään, esimerkiksi lopputuloksia koskevat tavoitteet muuttuvat projektin edetessä, on syytä harkita sopimista muutosmenettelyn yksityiskohdista. Muutosmenettelyn osalta voidaan esimerkiksi sopia, kenen aloitteesta muutoksia tehdään, onko osapuolilla tietyissä tilanteissa velvollisuus ehdottaa muutosta, missä aikataulussa toisen osapuolen muutosehdotukseen on vastattava ja mitä vaikutuksia sillä on, jos osapuoli ei hyväksy muutosehdotusta, ja miten muutostyö hinnoitellaan. Yksi keskeinen osa prosessia on osapuolten välinen kommunikointi. Tutkimuksissamme on erityisesti korostunut projektin lopputulokseen vaikuttavana tekijänä se, miten osapuolet antavat toisilleen tietoja, mitä tietoja annetaan ja missä vaiheessa projektia mitäkin tietoja annetaan. Yleistäen ei voida todeta, että aina on hyvä antaa mahdollisimman paljon tietoa. Paitsi että jotkut tiedot on tarpeellista säilyttää luottamuksellisina, toista osapuolta ei ole syytä rasittaa sellaisilla tiedoilla, joita se ei tarvitse. Siirrettävien tietojen laatuun ja määrään vaikuttaa monia tekijöitä, kuten projektin luonne, osapuolten toimintatavat ja kypsyys sekä niiden luottamus toisiaan kohtaan. Oleellista sen sijaan onkin, että osapuolet tarpeeksi ajoissa pohtivat, mitä tietoja ja missä projektin vaiheessa niiden on syytä sitoutua antamaan muille osapuolille. Erityisesti on kiinnitettävä huomioita siihen, että ongelmien korjaaminen saattaa olla hyvin työlästä myöhäisemmissä vaiheissa, jos projektin alussa on annettu puutteellisia tietoja. 11 RISKIEN JA ONGELMIEN HALLINTA Riskien ja ongelmien hallinta käsittää velvollisuuden ennakoivasti tunnistaa ja välttää mahdollisia ongelmia sekä määritellä, miten toimitaan, jos ongelmia kuitenkin syntyy. Projektin oletusten avulla pyritään dokumentoimaan sellaisia osapuolten yhteisiä käsityksiä, joilla on vaikutusta projektin onnistumiseen. Ne saattavat liityä esimerkiksi käytettävään teknologiaan, ohjelmiston toteutettavuuteen ja ulkoisiin tapahtumiin. Kirjoittamalla keskeiset oletukset näkyviin osapuolet voivat varmistautua, että niillä on samanlainen käsitys oletuksista ja että niiden sitoumukset perustuvat tietoisuuteen näistä oletuksista. 11

Riskien hallinnasta sovittaviin asioihin kuuluvat riskienhallintavastuiden määritteleminen, tiettyjä riskejä koskevien vastuiden jakaminen osapuolten kesken, hyväksyttävien riskien määritteleminen sekä riskien hallinnan kustannusten jakamisen periaatteet. Ongelmien hallinnalla tarkoitetaan niitä sopimusehtoja, joista sovitaan sen tilanteen varalle, että jotain projektissa on jo mennyt pieleen. Tällaisia ovat esimerkiksi vahingonkorvausvastuuta, sopimussakkoja, oikeuspaikkaa ja sovellettavaa lakia koskevat ehdot. Riskienhallinnan tulisi olla jatkuvaa, koko projektin ajan kestävää toimintaa. Tilanteet ja olosuhteet muuttuvat ja osapuolten tieto ja ymmärrys projektista lisääntyy jatkuvasti. Jos projektin kuluessa löydetään uusia riskejä tai riskitekijöitä, on ratkaistava, miten ne vaikuttavat osapuolten sitoumuksiin. Osapuolten tulisi projektin alussa sitoutua sellaiseen riskienhallintaprosessiin, joka mahdollistaa sitoumusten päivittämisen projektin aikana. Useimmissa projektisopimuksissa on pyritty perinteisesti määrittelemään projektin lopputulokset, taloudelliset ja aikatauluun liittyvät reunaehdot sekä menettelytavat ja seuraamukset siltä varalta, ettei tavoiteltua lopputulosta saavuteta. Mallit tällaisiin sopimuksiin on yleensä alunperin saatu muilta teollisuudenaloilta. Koska sopimus on lähtökohtaisesti osapuolia sitova, useimmat sopimukset määrittelevät tietyt staattiset tavoitteet ja toimintatavat aivan kuin voitaisiin olettaa ohjelmistokehityksen etenevän alusta loppuun suunnitellulla tavalla. Tavallisesti käytetään kahta tapaa epävarmuuden hallintaan. Ensinnäkin sopimusrikkomuksia koskevilla ehdoilla voidaan sopia vahingonkorvausten suuruudesta ja laajuudesta siltä varalta, ettei alkuperäisiä tavoitteita saavuteta. Toinen vaihtoehto käsitellä projektiin liittyviä epävarmuustekijöitä on luottaa siihen mahdollisuuteen, että sopimusta voidaan aina muuttaa sopimalla asiasta yhdessä uudelleen. Periaatteessa tällaiset ehdot edustavat reagoivaa, jälkikäteistä riskienhallintaa tai ongelmienhallintaa. Ne eivät välttämättä auta toimimaan ennakoivasti riskien välttämiseksi tai pienentämiseksi [8]. Vaikka tällaiset ehdot periaatteessa muodostavatkin yllykkeen hallita riskejä ennakolta, ehdot ovat kuitenkin luonteeltaan staattisia ja ne laaditaan projektin alussa, kun vielä ei ole käytettävissä riittävästi tietoa oikeista seuraamusten ehdoista, laaduista ja suuruuksista sopimiseen. Staattiset sanktioehdot kääntävät myös helposti projektin osapuolet toisiaan vastaan, vaikka saattaisi olla mahdollista neuvottelemalla päästä tyydyttävämpään ratkaisuun. Edellä todetulla tavalla muutosmahdollisuudesta sopiminen on luonnollisesti käytännöllinen ratkaisu muuttuvassa ympäristössä. Tähän vaihtoehtoon liittyy tietysti myös huomattavia ongelmia: se voi heikentää sopimukseen liittyvien sitoumusten arvoa ja sillä on ylipäätään merkitystä vain, jos osapuolet pystyvät vielä uudelleen sopimaan asiasta. Sama ongelma liittyy myös projektisuunnitelmien malleihin, koska niissäkin on yleensä oletettu, että vaatimukset säilyvät muuttumattomina ja kehitysympäristössä ei tapahdu muutoksia. Ohjelmistoprojektien riskienhallinta liittyy sitoumusten hallintaan ja määrittelyyn. Kuva 4 esittää Riskitmenetelmän [28] mukaisesti, miten riski määräytyy sen toteutumisen todennäköisyyden ja mahdollisen vahingon suuruuden mukaan. Vahinko taas määräytyy sen mukaan, mitä tietty osapuoli on odottanut saavuttavansa. Osapuoli arvottaa odotuksensa omista lähtökohdistaan. Differenssiopin mukaisesti vahingon voidaan sanoa olevan hypoteettisen tuloksen ja toteutuneen tuloksen erotus, vaikkapa positiivisen sopimusedun saavuttamatta jääminen [15]. Sitoumusten määrittelyssä odotukset määritellään selvästi. Niinpä vaikka monet riskienhallinnan menetelmät jättävät erikseen mainitsematta odotusten ja riskien välisen suhteen, riskien perusluonteesta johtuen ne kuitenkin tukevat jossain määrin sitoumusten hallintaa. 12

riski osatekijänä osatekijänä todennäköisyys vahinko määräytyy odotukset arvottuu osapuoli Kuva 4 Riskin määritelmä Riskit-menetelmän mukaisesti Kiinnostus ohjelmistotuotannon riskienhallintaa kohtaan on lisääntynyt viime aikoina teollisuudessa. Tästä kehityksestä on raportoitu julkaisuissa [21] ja konferensseissa [42] ja siitä kertoo myös riskienhallinnan ottaminen osaksi ohjelmistoprosesseja koskevia standardeja [22, 43] ja arviointimalleja [23, 36]. Vaikka kirjallisuudessa on esitetty useita riskienhallinnan lähestymistapoja [3, 4, 7, 11, 25, 28] ja monet niistä ovat jopa käytössä, vain harvoissa niistä on erityisesti tuotu esiin osapuolten välistä riskienhallintaa ja sitoumusten määrittelyä. Monet menetelmät kuitenkin epäsuorasti tuovat nämäkin kysymykset esiin. Software Engineering Institute (SEI) on kehittänyt Team Risk Management menetelmän, jossa oletetaan, että osapuolet voivat saavuttaa yksimielisyyden ja että kaikista riskeihin liittyvistä näkökohdista voidaan keskustella avoimesti. Tähän lähestymistapaan liittyy kolme mahdollista ongelmakohtaa. Ensinnäkin on varsin ilmeistä, etteivät kaikki osapuolet ole valmiita avoimesti keskustelemaan riskeistään. Toiseksi osapuolilla saattaa olla varsin erilaisia näkökulmia riskeihin. Pakottamalla heidät olemaan yhtä mieltä riskeistä tai tekemään riskianalyyseissään kompromisseja saatetaan riskejä tulkita virheellisesti. Kolmanneksi SEI:n lähestymistapa ei tuo esiin riskeihin liittyviä sopimuksellisia näkökohtia eikä neuvotteluprosessia. Barry Boehmin kehittämä riskienhallinnan WinWin-malli [5, 6] ottaa huomioon eri osapuolten erilaiset näkökulmat ja neuvotteluprosessin. Boehmin lähestymistapa on tunnetuin menetelmä, jossa otetaan huomioon osapuolten odotukset. Se rajoittuu kuitenkin tavoitteiden määrittelyyn eikä tarjoa ohjeita siihen, miten sitoumukset tulisi täsmentää. Jyrki Kontion Riskit-menetelmä [28, 29] tunnistaa myös erityisesti projektin osapuolet ja heidän mahdollisesti erilaiset odotuksensa projektin suhteen. Riskit-menetelmä sisältää lähestymistavan, jolla voidaan löytää osapuolten riskit, odotukset ja tavoitteet. Riskit-menetelmäkään ei kuitenkaan tuo riittävästi esiin sitoumusmäärittelyn sisältöä eikä siihen johtavaa prosessia. 13

12 VAHINGONKORVAUS OSANA RISKIENHALLINTAA Ohjelmistoprojektin osapuolten sopimusrikkomukset, kuten viivästyminen tai ohjelmistossa oleva virhe, saattavat aiheuttaa suuriakin vahinkoja muille osapuolille. Niinpä onkin tavallista sopia vahingonkorvausvastuusta ohjelmistoprojektia koskevassa sopimuksessa. Tavanomainen lauseke on Sopijapuoli ei vastaa välillisistä vahingoista. Muun muassa ohjelmistoprojekteissa melko yleisesti käytetyissä ATK94/YSE-, IT2000/YSE- ja IT2000/PTE-ehdoissa on tämän kaltainen virke. [2, 24] Samansisältöinen ehto on myös monissa niissä sopimuksissa ja vakioehdoissa, joihin ei sovelleta ATK94- eikä IT2000-ehtoja. Syy välillisten vahinkojen rajaamiselle pois korvattavien vahinkojen piiristä on varsin selkeä. Välillisten vahinkojen määrää on vaikeaa ennakoida ja esimerkiksi tilaajalle aiheutuvien välillisten vahinkojen suuruus ei yleensä ole toimittajan kontrolloitavissa. Välillisiä vahinkoja ei kuitenkaan ole erikseen määritelty ATK94- eikä IT2000-ehdoissa sen enempää kuin useimmissa muissakaan ohjelmistoprojekteja koskevissa sopimuksissa. Niinpä saattaa jälkikäteen aiheutua epäselvyyttä siitä, mitkä vahingot ovat välittömiä ja toisen osapuolen korvattavia, mitkä vahingot puolestaan välillisiä. Välittömän ja välillisen vahingon voi käsitteinä ajatella tarkoittavan sitä, että esimerkiksi sopimusrikkomuksesta, viivästyksestä tai tuotteen virheestä aiheutuu toiselle osapuolelle ensin välitön vahinko, josta puolestaan aiheutuu välillistä vahinkoa (Kuva 5). [15, 27] Käytännössä ei kuitenkaan ole lainkaan yksinkertaista määritellä, mitkä vahingot seuraavat välittömästi esimerkiksi sopimusrikkomuksesta, mitkä taas ovat välittömän vahingon seurauksia. Tämä saattaa johtaa välittömien vahinkojen alan suppenemiseen tarpeettomankin pieneksi tai aiheuttaa melkoista tulkinnanvaraisuutta. Viivästys tai virhe Välitön vahinko Välillinen vahinko Kuva 5 Viivästys tai virhe aiheuttaa välittömän vahingon, joka puolestaan aiheuttaa välillisen vahingon. Asiasta ei ole nimenomaista lainsäännöstä. Kauppalaissa tehdään ero välillisen ja välittömän vahingon kesken, mutta kauppalaki ei ensinnäkään ole yleensä suoraan sovellettavissa ohjelmistoprojekteihin. Toiseksi kauppalaissa esitetty määritelmä on itsessään jonkin verran epäselvä ja tulkinnanvarainen. Hemmon mukaan välittömän ja välillisen vahingon määrittelyssä ilmenevät detaljierot saavat aikaan epäselvyyttä. Välillisten vahinkojen ydinsisällöstä vallitsee kuitenkin yksimielisyys. Niiden piiriin kuuluvat ennen kaikkea sopimusrikkomuksen aiheuttama tulon menetys ja sivullisten kanssa tehdyissä sopimuksissa ilmenevät häiriöt [ ] Alaviitteessä Hemmo kuitenkin lisää, että sopimuksen mukainen voitto, joka seuraa suorituksen markkina-arvon ja velkojan maksaman hinnan erotuksesta, ei luonnollisestikaan ole välilliseksi vahingoksi luettavaa tuloa. Tämä sopimusvaihdannan keskeisimpiin kuuluva intressi korvataan aina välittömänä vahinkona. [15] Lukijalle ei täysin selviä, mikä oleellinen ero tässä on tulolla ja sopimuksen mukaisella voitolla. Vaikka asiassa ehkä periaatteessa vallitseekin yksimielisyys, käytännössä ei ole kovinkaan helppoa Hemmon esittämällä tavalla erottaa välitöntä ja välillistä vahinkoa toisistaan. 14

Kirjallisuudessa ja kauppalain esitöissä [14] on yleisesti kannatettu välittömien ja välillisten vahinkojen erottamista toisistaan sen mukaan, miten hyvin ennakoitavia ne ovat. Erityisesti tämä on kirjattu näkyviin kauppalain 67 2 momentin 5 kohdassa: [Välillisenä vahinkona pidetään] muuta saman kaltaista, vaikeasti ennakoitavaa vahinkoa. Tällainen adekvanssioppiin perustuva tulkinta ei ehkä kovin hyvin vastaa sanojen välitön ja välillinen yleistä merkitystä, mutta ennalta-arvattavuus muuten antaa kieltämättä järkevän perusteen vahingonkorvausvastuun rajaamiselle. Vahingon ennakoitavuuden eli adekvaattisuuden on yleensäkin katsottu olevan vahingonkorvausvelvollisuuden keskeinen edellytys syy-yhteyden ohella. Täysin ennalta-arvaamaton vahinko ei yleensä ole vahingonkorvausvastuun piirissä. [15, 16, 27, 45] Niinpä voitaisiin hyvin ajatella, että mitä helpommin ennakoitavissa vahinko on, sitä laajempi on korvausvastuu. Helposti ennakoitavien eli välittömien vahinkojen osalta voitaisiin edellyttää vähäisempää tuottamusta tai soveltaa jopa kauppalain tyyliin kontrollivastuuta. Vaikeammin ennakoitavien eli välillisten vahinkojen kohdalla edellytettäisiin suurempaa tuottamusta ja erittäin vaikeasti ennakoitavat vahingot jäisivät adekvanssiopin mukaisesti korvausvelvollisuuden ulkopuolelle. Saarinen on ehdottanut, että sopimuksissa voitaisiin vahingonkorvausvelvollisuutta rajata esimerkiksi seuraavasti: sopijapuolella on oikeus vahingonkorvaukseen [ ] sopimuksen täyttämisen viivästymisestä aiheutuvasta vahingosta, ellei viivästyvä sopijapuoli osoita, että viivästys johtuu hänen vaikutusmahdollisuuksiensa ulkopuolella olevasta esteestä, jota hänen ei voida kohtuudella edellyttää ottaneen huomioon sopimusta tehtäessä ja jonka seurauksia hän ei olisi voinut välttää eikä voittaa. Vahingot, joiden syntymistä, laatua tai määrää sopimusta rikkoneen sopijapuolen on erityisen vaikea arvioida ennalta, hän on velvollinen korvaamaan vain, mikäli ne aiheutuvat tuottamuksesta hänen puolellaan. [39] Saarisen ehdotus tarjoaa hyvän pohjan sopimuksen laatijalle. Se ei kuitenkaan vielä lopullisesti ratkaise välittömien ja välillisten vahinkojen rajanveto-ongelmaa. Vahinkojen ennakoitavuus saattaa olla jälkikäteen varsin hankalaa näyttää toteen. Niinpä olisikin syytä sopimustekstiin kirjata näkyviin selkeämpi määrittely vahinkotyyppien erottelusta, jos välilliset vahingot halutaan sulkea korvausvastuun ulkopuolelle. Tapauskohtaisesti tässä voi auttaa esimerkkiluettelon ottaminen mukaan. Tällöin edellytetään osapuolilta sopimusneuvotteluvaiheessa kohtalaisen hyvää näkemystä siitä, minkälaisia vahinkoja sopimusrikkomuksesta saattaisi seurata. Työväline tämän analyysin tekemiseen saadaan riskienhallinnasta. Tunnistamalla ja analysoimalla projektin riskit ennen sopimuksen solmimista, voidaan luoda perusteltu näkemys siitä, minkälaisia ongelmia saattaa olla odotettavissa ja minkälaisia vahinkoja niistä saattaa seurata. Riski on mahdollisesti tulevaisuudessa sattuva epätoivottu, vahingollinen tapahtuma. Riskillä on syynsä eli riskitekijät. Riski siis on riskitekijöiden seuraus. Tarkasteltaessa sopimussuhdetta, jossa on ainakin kaksi osapuolta, voidaan huomata monien riskien olevan sellaisia, että niiden syyt, riskitekijät ovat yhden osapuolen vaikutuspiirissä, kun taas mahdollinen vahinko aiheutuu toiselle osapuolelle. Tällaiset riskit ovat sopimussuhteen ja vastuunjaon kannalta keskeisiä. Projektissa voidaan yleisen käytännön mukaisesti sopia, että osapuolet vastaavat vain välittömistä vahingoista. Sopimussuhteen alussa suoritettavassa riskien tunnistuksessa osapuolten tulisi pyrkiä mahdollisimman kattavasti löytämään kaikki riskit. Vahingonkorvausoikeudelliselta kannalta on erityisen tärkeää pyrkiä löytämään ne riskitekijät, jotka ovat omassa vaikutuspiirissä, sekä ne riskit, joiden mahdollinen vahinko aiheutuu itselle. Ilmoittamalla näin löydetyt riskitekijät ja riskit toiselle osapuolelle, on mahdollista tehokkaasti ja järkevästi sopia vahingonkorvausvastuusta samalla, kun voidaan mielekkäällä tavalla käynnistää hankkeeseen liittyvä riskienhallinta. Selvyyden vuoksi välitön 15

vahinko määritellään sopimuksessa ennalta-arvattavaksi vahingoksi. Erityisesti ennalta-arvattavia vahinkoja ovat sellaiset, jotka osapuoli on etukäteen kirjallisesti ilmoittanut toiselle osapuolelle. Näin osapuolen kannattaa tehdä mahdollisimman perusteellinen riskien tunnistus ja ilmoittaa sen tulokset toiselle osapuolelle. Mikäli korvattavista vahingoista jouduttaisiin jälkeenpäin riitelemään, olettamaksi muodostuisi, että osapuoli joutuu korvaamaan aiheuttamansa vahingon, mikäli toinen osapuoli on riskin etukäteen ilmoittanut. Muussa tapauksessa korvausvelvollisuutta ei ole, ellei vahinkoa kärsinyt pysty näyttämään jälkikäteen, että riski oli ennalta-arvattava. Myös omassa vaikutuspiirissä olevat riskitekijät kannattaa ilmoittaa toiselle osapuolelle etukäteen. Tällöin on mahdollista sopia siitä, että toinen osapuoli hyväksyy riskitekijän ja ottaa vastaavan riskin kantaakseen tai että vastuu riskistä jaetaan osapuolten kesken. Jos taas osapuoli ei ilmoita riskitekijän olemassaoloa toiselle osapuolelle, vastuu riskin mahdollisesti aiheuttamista vahingoista on lähtökohtaisesti osapuolella itsellään. Riskitekijöiden ilmoittaminen toiselle osapuolelle ei toki aina ole helppoa. Neuvoteltaessa sopimuksesta, voi tuntua siltä, että sopimuksen syntyminen vaarantuu, jos omia riskitekijöitä tuodaan esille. Tällaista oloa ei voi vähätellä perustuupa se sitten tosiasioihin tai ei. Avoimuus riskitekijöistä ja heikkouksista voi kuitenkin parhaimmillaan lisätä uskottavuutta ja luottamusta sen lisäksi, että samalla oikeudellisesti turvataan selustaa pahimman varalle. 13 PROJEKTIN ETENEMISTÄ TUKEVAT RISKIEN HALLINTAKEINOT Edellä on todettu, että tavallisesti sopimuksissa käytettävät riskienhallintakeinot edustavat lähinnä ns. jälkikäteistä riskienhallintaa, eivätkä siten välttämättä auta toimimaan ennakoitavasti riskien välttämiseksi. Lukuun ottamatta tietenkin keinojen mahdollista epäsuoraa pelote- tai ennalta ehkäisevää vaikutusta. Alihankintaa koskevissa case-tutkimuksissa on selvästi käynyt ilmi, että huolimatta toimittajan ja alihankkijan väliseen sopimukseen kirjatusta vahingonkorvaus-, sopimus- tai viivästyssakkolausekkeesta, ei toimittaja alihankkijan viivästys tai virhe tilanteissa usein ole ollut halukas turvautumaan näihin keinoihin. Toimittajan kannalta tärkeämpää on ollut yhteistyön säilyttäminen alihankkijan kanssa sekä sopimusten lopputulosten saavuttaminen vaikka myöhässäkin tai hiukan muuttuneessa muodossa. Saman voisi arvella koskevan myös monia muita sopimussuhteita. Esitetyt käytännön kokemukset ovat kiinnostavia kahdessa mielessä. Perinteisesti yhtenä tärkeänä sopimusten painopisteenä on ollut jälkikäteiset riskienhallintakeinot. Edellä esitettyjen kokemusten perusteella voidaan kuitenkin ehdottaa, että ennen yksittäisten vahingonkorvaus tai sopimussakkolausekkeiden kirjaamista on syytä tarkoin harkita niiden merkitystä projektin kannalta. Jos on todennäköistä, ettei niihin esimerkiksi viivästystilanteissa haluta turvautua, ei sopimuksen painopistettä kannata siten kohdistaa näihin lausekkeisiin. Vastaavasti vahingonkorvaus- ja sopimussakkolausekkeista ei tällöin ole järkevää tehdä sopimusneuvottelun kynnyskysymystä. Käytännön kokemukset ohjaavat hakemaan myös muita kuin perinteisiä riskienhallintakeinoja. Olisiko olemassa riskienhallinta keinoja, joilla tuettaisiin projektien etenemistä? Yhtenä vaihtoehtona voidaan esittää erilaiset kannustinjärjestelmät, esimerkiksi bonuksen antaminen alihankkijalle hyvin edenneen projektin yhteydessä. 16

14 YHTEENVETO Ohjelmistoprojektit epäonnistuvat varsin usein. Nykyiset sopimukset eivät juurikaan tue projektin menestyksellistä läpivientiä eivätkä välttämättä auta edes ratkaisemaan projektista aiheutuvia riitoja. Ohjelmistoprojektin alkaessa osapuolilla on vain rajalliset mahdollisuudet sopia kaikista asioista, jotka mahdollisesti saattavat aiheuttaa ongelmia projektin aikana. On tärkeää keskittää sopimuksen teossa niukat resurssit oikeisiin kysymyksiin. Tunnistamalla projektin riskitaso ja muut oleelliset ominaisuudet, voidaan keskittyä määrittelemään tärkeimmät sitoumukset kunnolla. Riskialttiissa projektissa kannattaa määritellä huolellisesti motiivit, prosessit ja riskienhallinta, kun taas vähemmän riskialttiissa projektissa voidaan yksityiskohtaisemmin määritellä tavoitteet ja ongelmien hallinta. LÄHTEET 1 G. Aharonian. Does the Patent Office Respect the Software Community? IEEE Software, Jul/Aug, 1999. 2 ATK94 Tietojenkäsittelyalan sopimusehdot, Keskuskauppakamari ja Tietotekniikan liitto ry, 1994. 3 B.W. Boehm. Tutorial: Software Risk Management, IEEE Computer Society Press, 1989. s. 1-469. 4 B.W. Boehm, Software Risk Management: Principles and Practices, IEEE Software, vol. 8, s. 32-41, 1991. 5 B.W. Boehm & Bose P., A Collaborative Spiral Software Process Model Based on Theory W, 1994. Proceedings of the 3rd International Conference on the Software Process. IEEE Computer Society. Washington, DC. 6 B.W. Boehm & Ross R, Theory W Software Project Management: Principles and Examples IEEE Transactions on Software Engineering, vol. s. 902-916, 1989. 7 R.N. Charette. Software Engineering Risk Analysis and Management, New York: McGraw-Hill, 1989. 8 R.N. Charette, Building Bridges over Intelligent Rivers American Programmer, vol. s. 2-9, 1992. 9 J.D. Cooper, Corporate Level Software Management IEEE Transactions on Software Engineering, vol. SE-4, 1978. 10 T. DeMarco & T.R. Lister. Peopleware: Productive Projects & Teams, Dorset House Publishing Company, 1987. 11 R.E. Fairley. Risk Management: The Key to Successful Software Projects. In: Proceedings of the 3rd IFAC/IFIP Workshop, toim. F.J. Mowle and P.F. Elzer. Oxford: Pergamon, 1989.s. 45-50. 12 H. Glover, H.J. Watson, & R.K. Rainer Jr., 20 Ways to Waste an EIS Investment Information Strategy: The Executive's Journal, vol. 8, s. 11-17, 1992. 13 P-L. Haarmann. Tekijänoikeus ja lähioikeudet, Kauppakaari, 1999. 14 Hallituksen esitys Eduskunnalle kauppalaiksi, HE 93/1986 vp, 1996. 17

15 J. Hellner, Skadeståndsrätt, Juristförlaget, Stockholm, 1995. 16 M. Hemmo. Sopimusoikeus I, Kauppakaari Oy, Helsinki, 1997. 17 M. Hemmo. Sopimusoikeus II, Kauppakaari Oy, Helsinki, 1997. 18 A. Huhtamäki, Luotonantajavastuu, Lakimiesliiton kustannus, 1993. 19 W.S. Humphrey. Managing for Innovation: Leading Technical people, Englewood Cliffs, New Jersey: Prentice-Hall, 1987. 20 IEEE. IEEE Standard for Software Project Management Plans, Std 1058.1-1987, New York: IEEE, 1987. 21 IEEE, Managing Risk, IEEE Software, vol. 14, no. 3, 1997. 22 ISO. ISO 9000-3, Guidelines for the application of ISO 9001 to the development, supply and maintenance of software, ISO 9000-3:1991(E), International Standards Organization, 1991. 23 ISO. SPICE: Baseline Practices Guide, an unfinished draft of a standard being developed for ISO, version 1.00, 1994. (julkaisematon) 24 IT2000. Tietotekniikka-alan yleiset sopimusehdot, Keskuskauppakamari, Suomen Logistiikkayhdistys ry, Tietotekniikan liitto ry ja Tietotekniikan Palveluliitto TIPAL ry, 1999. 25 D.W. Karolak. Software Engineering Risk Management, Washington, DC: IEEE, 1996. 26 S.P. Keider, Why Projects Fail Datamation, vol. 1974. 27 T. M. Kivimäki & M. Ylöstalo, Suomen siviilioikeuden oppikirja. Yleinen osa, 1973. 28 J. Kontio, The Riskit Method for Software Risk Management, version 1.00, CS-TR-3782, 1997b. Computer Science Technical Reports. University of Maryland. College Park, MD. 29 J. Kontio & V.R. Basili, Empirical Evaluation of a Risk Management Method, 1997. Proceedings of the SEI Conference on Risk Management. Software Engineering Institute. Pittsburgh, PA. 30 J. Kontio, O. Pitkänen, & R. Sulonen, Towards Better Software Projects and Contracts: Commitment Specifications in Software Development Projects, 1998. Proceedings of the 20th International Conference on Software Engineering, ICSE 98. IEEE Computer Society. Washington, DC. 31 P.L. McDoniel, J. Palko, & T.P. Cronan, Information systems development: issues affecting success J.Comput.Inf.Syst., vol. 34, s. 50-62, 1993. 32 R. Merges, P. Menell, M. Lemley. Intellectual Property in the New Technological Age. 2nd edition, Aspen Law & Business, 2000. 33 R. Merges. As Many as Six Impossible Patents Before Breakfast: Property Rights for Business Concepts and Patent System Reform. Berkeley Technology Law Journal, 14:2, 1999. 34 S. Nystén-Haarala, The Long-Term Contract, Contract Law and Contracting, Kauppakaari Oyj, Finninsh Lawyers Publishing, Helsinki 1998. 35 S. Nystén-Haarala, Sopimusoikeus ja sopimusten hallinta. Lakimies 2, 1999. 18

36 M.C. Paulk, B. Curtis, M.B. Chrissis, & C.V. Weber, Capability Maturity Model for Software, Version 1.1. SEI Technical Report. Software Engineering Institute, Carnegie Mellon University, 1993. 37 O. Pitkänen, M. Välimäki, Towards A Digital Rights Management Framework, IeC2000 Conference Proceedings, Manchester, UK, 2000. 38 Preventive Law Reporter, University of Denver College of Law, 1983 1999. 39 T. Saarinen, Sopimusoikeudellisesta vahingonkorvausvastuusta erityisesti kauppalain valossa, Turun yliopiston oikeustieteellisen tiedekunnan julkaisuja, Yksityisoikeuden julkaisusarja B:28, 1996. 40 J. Salonen, Tietojärjestelmän hankinta, Tutkimus järjestelmän oikeaa mitoitusta ja toimivuutta koskevasta sopimusvastuusta, Finn Lectura, 2000. 41 P. Samuelson. Good News and Bad News on the Intellectual Property Front. Communications of the ACM, vol. 42 no. 3, March 1999. 42 C. Shapiro & H. R. Varian, Information Rules, A Strategic Guide to the Network Economy, Harvard Business School Press, 1999. 43 SEI. Proceedings of the SEI Conferences on Software Risk Management, Pittsburgh, PA: Software Engineering Institute, 1993, 1994, 1995, 1997 44 SPICE, Software Process Assessment Part 1: Concepts and introductory guide ISO/IEC/JTC1/SC7/WG10/N111, Oct 6, 1996. ISO. 45 L. E. Taxell, Skadestånd vid avtalsbrott, Åbo Akademis Förlag, 1993. 19