Ohjelmistoprojektin pysähtyminen on kova isku molemmille osapuolille. Asiakas on investoinut toimintaansa parantavaan järjestelmään ja katsoo määräaikojen vierenevän ilman toimivaa tulosta. Toimittaja näkee usein toisenlaisen kuvan: asiakkaan, joka esittää jatkuvasti uusia toiveita, lykkää päätöksiä tai toimittaa liian vähän tietoa.
Kuka siis kantaa tappion? Aluksi neljä asiaa:
- Epäonnistunut ohjelmistoprojekti ei automaattisesti tarkoita toimittajan epäonnistumista.
- Asiakkaan yhteistyöllä voi olla myös oikeudellisesti merkitystä.
- Hyvät projektitiedot ja sopimusjärjestelyt rajoittavat oikeudenkäyntiriskiä.
- Asiantuntijan tekemä tutkimus voi olla ratkaiseva teknisen arvioinnin kannalta.
Seuraavaksi käsittelemme vuorotellen yleisiä syitä, oikeudellista arviointia, asiakkaan yhteistyövelvollisuutta, asiantuntijalausuntoa, menettelyjen mahdollisia lopputuloksia, käytännön esimerkkien osoitusta ja riidan ehkäisemiseen tähtääviä toimenpiteitä.
Yleiset syyt
Käytännössä useat syyt toistuvat.
- Laajuushyökkäys eli tehtävän asteittainen laajeneminen. Järjestelmälle asetettavat vaatimukset kasvavat jatkuvasti ilman virallista muutosmenettelyä, joka käsittelisi suunnittelun ja budjetin seurauksia.
- Epäselvät tai puutteelliset toiminnalliset määritykset. Jos järjestelmän toimintojen määrittelyä ei ole etukäteen määritetty, myöhemmin syntyy kiistaa siitä, onko toimitettu tulos vaatimusten mukainen.
- Huono järjestelmäsuunnittelu. Arkkitehtuuria ei ole rakennettu varsinaista kuormitusta, rajapintoja muiden järjestelmien kanssa tai tulevaa laajennusta varten.
- Monimutkaisuuden ja läpimenoajan aliarviointi, erityisesti projekteissa, joissa on yhdistettävä useita olemassa olevia järjestelmiä.
- Asiakkaan myöhäinen tai rajoittunut yhteistyö.
Nämä syyt harvoin esiintyvät yksin. Ne usein vahvistavat toisiaan. Projekti, joka aluksi vain myöhästyy, voi sen seurauksena epäonnistua kokonaan.
Oikeudellinen arviointi: laiminlyönti ja myötävaikutus
Ensimmäinen oikeudellinen kysymys on, onko toimittaja syyllistynyt sopimusrikkomukseen. Alankomaiden siviililain 6:74 § velvoittaa velallisen korvaamaan velkojalle laiminlyönnistä aiheutuneen vahingon, ellei laiminlyöntiä voida katsoa toimittajan syyksi.
Onnistunut korvausvaatimus edellyttää siis sen osoittamista, että toimittaja ei ole toimittanut sovittua, esimerkiksi siksi, että ohjelmisto ei täytä kirjattuja toiminnallisia eritelmiä. Ja vian on oltava toimittajan aiheuttama, eli kyseessä ei ole ylivoimainen este.
Käytännössä vastuu on usein jaettu. Asiakas selvensi tiettyjä vaatimuksia myöhässä, muutti toiveitaan projektin aikana hyväksymättä seurauksia suunnittelun ja kustannusten kannalta tai ei asettanut käyttökelpoista testiympäristöä saataville.
Tällaisessa tapauksessa tuomioistuin voi alentaa toimittajan korvausvelvollisuutta Alankomaiden siviililain 6:101 §:n nojalla suhteessa siihen, missä määrin asiakkaasta johtuvat olosuhteet ovat myötävaikuttaneet tappioon. Tämä myötävaikutusoppi voi alentaa korvausta huomattavasti ja poikkeustapauksissa johtaa sen hylkäämiseen kokonaan.
Käytännön neuvoja molemmille osapuolille: dokumentoi koko projektin ajan, kuka tekee mitäkin päätöksiä, mitä muutoksia tehdään ja mitä tietoja toimitetaan milloin. Menettelyissä tämä dokumentointi ratkaisee usein täyden vastuun ja voimakkaasti maltillisen lopputuloksen välillä.
Asiakkaan velvollisuus tehdä yhteistyötä
Ohjelmiston käyttöönotto on yhteistyöprojekti. Toimittaja rakentaa ja konfiguroi ohjelmiston, mutta on jatkuvasti riippuvainen asiakkaasta: oikea-aikaiset ja täydelliset määrittelyt, käyttökelpoinen testidata, nopeat päätökset avoimista kysymyksistä ja toimitettujen komponenttien oikea-aikainen vastaanotto.
Jos tätä yhteistyötä ei tapahdu, toimittaja ei voi suorittaa työtään. Laissa on tähän seurauksia. Alankomaiden siviililain 6:58 § ja sitä seuraavat pykälät sääntelevät velkojan maksukyvyttömyyttä, joka syntyy, kun velallisen suoritus estyy, koska velkojalta vaadittua yhteistyötä ei tapahdu.
Käytännössä: jos toimittaja viivästyy, koska asiakas ei toimita tarvittavaa ajoissa, toimittaja ei syyllisty sopimusrikkomukseen eikä ole vastuussa viivästyksestä. Asiakas itse saattaa olla sopimusrikkomuksessa. Koska ohjelmistoprojektit ovat yleensä iteratiivisia ja jokainen vaihe perustuu edellisen vaiheen palautteeseen ja hyväksyntään, puuttuvaa palautetta käytetään oikeuskäytännössä säännöllisesti viivästyksen selittämiseen kokonaan tai osittain asiakkaalla.
Asiakkaiden kannalta tämä on huomionarvoista: edistymisen kritiikillä on vain vähän painoarvoa, jos oma päätöksenteko on hidasta. Toimittajien kohdalla pätee päinvastoin: merkitse asiakkaasta johtuva viivästys välittömästi ja kirjallisesti esimerkiksi selkeällä varoituksella tai viivästysilmoituksella heti, kun tarvittavat tiedot eivät ole toteutuneet. Jos näin ei tapahdu, on usein mahdotonta jälkikäteen rekonstruoida, kuka aiheutti minkäkin viivästyksen.
Asiantuntijatutkimus
Ohjelmistoprojektit ovat luonteeltaan teknisiä. Täyttikö toimitettu ohjelmisto spesifikaatiot? Oliko viivästys toimittajan vai asiakkaan syytä? Oliko laskutettu lisätyö perusteltua? Kysymykset arkkitehtuurista, lähdekoodista, vaatimusten jäljitettävyydestä kehitysprosessin aikana ja testiraporttien sisällöstä vaativat teknistä tietämystä, jota ei voida odottaa tuomarilta.
Tästä syystä näissä riita-asioissa tilataan usein tuomioistuimen määräämä asiantuntijalausunto Alankomaiden siviiliprosessilain pykälien 194–207 nojalla. Riippumaton asiantuntija arvioi sitten, täyttikö ohjelmisto sovitut ehdot, missä viivästys johtui ja olivatko aiheutuneet kustannukset kohtuullisia. Käytännössä lopputuloksella on suuri merkitys tuomioistuimen päätöksessä.
Asiantuntija tarvitsee yleensä seuraavat asiakirjat:
- sopimus ja sen liitteet;
- toiminnalliset ja tekniset eritelmät;
- muutospyynnöt;
- projektin suunnittelu ja edistymisraportit;
- testiraportit;
- viivästyksiä ja hyväksymistä koskeva kirjeenvaihto;
- lähdekoodi ja dokumentaatio.
Jos osa tästä puuttuu, asiantuntija ei usein pysty vastaamaan kysymykseen. Tämä heijastuu näihin tosiseikkoihin vetoavan osapuolen todistusasemaan. Siksi kannattaa pitää tämä tiedosto järjestyksessä koko projektin ajan, ei vasta riidan syntymisen jälkeen.
Menettelyjen mahdolliset lopputulokset
Jos vain osa sopimuksesta on mennyt pieleen, esimerkiksi siksi, että yksi moduuli ei toimi, kun taas loput ovat käyttökelpoisia, tuomioistuin voi määrätä osittaisen purkamisen Alankomaiden siviililain 6:265 §:n ja 6:270 §:n nojalla. Onnistunut osa pysyy tällöin voimassa.
Vahingonkorvauksia voidaan myöntää myös 6:74 artiklan nojalla, joita voidaan sitten alentaa 6:101 artiklan nojalla myötävaikuttavan tuottamuksen perusteella. Lopuksi tuomioistuin voi kohtuullistaa vahingonkorvausta 6:109 artiklan nojalla esimerkiksi silloin, kun vaaditulla määrällä ei ole mitään yhteyttä alkuperäiseen sopimusarvoon. Tuomioistuimet soveltavat tätä kohtuullistamisvaltaa säästeliäästi.
Käytännössä epäonnistunut ohjelmistoprojekti päättyy usein uudelleenkäynnistykseen toisella toimittajalla. Sekään ei juurikaan etene ilman keskustelua. Kuka saa lähdekoodin? Kenellä on rakennetun järjestelmän immateriaalioikeudet? Onko olemassa escrow-sopimusta, jonka nojalla lähdekoodi talletetaan riippumattomalle kolmannelle osapuolelle? Jokainen, joka ei sopinut mitään tästä alusta alkaen, huomaa sen juuri nyt.
Mitä käytännön esimerkit osoittavat
Yleisten tuomioistuinten ohella automaatioriitojen ratkaisusäätiöllä (SGOA) on tärkeä rooli IT-alalla. Tämä riippumaton riitojenratkaisuelin on toiminut vuodesta 1989 lähtien ja tarjoaa sovittelua, välimiesmenettelyä, yhteenvetorakentamismenettelyjä, sitovia neuvoja, asiantuntijalausuntoja ja konfliktien ehkäisyä. Sen välimiehet ovat alan ammattilaisia, minkä vuoksi monet IT-riidat ratkaistaan tällä tavalla tuomioistuinmenettelyjen sijaan.
Julkaistuista SGOA:n päätöksistä paljastuu muutamia toistuvia oppeja, jotka ovat hyödyllisiä myös oikeudenkäyntien ulkopuolella:
- Vastuu on harvoin kokonaan yhden osapuolen harteilla; vastuunjako seuraa siitä, mitä kukin heistä todellisuudessa teki ja jätti tekemättä;
- Projektin edetessä muuttuvat eritelmät ovat yleisimpiä kiistanaiheita, ja virallisen muutosmenettelyn puuttuminen yleensä puhuu alkuperäiseen sopimukseen luottavaa osapuolta vastaan.
- Projektitietojen laatu on usein ratkaisevaa, koska se määrää, mitkä tosiasiat voidaan vielä todentaa.
Nämä ovat hyödyllisiä signaaleja kenelle tahansa sopimusta laativalle: ne ovat juuri ne asiat, jotka on parasta sopia etukäteen.
Ennaltaehkäisevät toimenpiteet
Monet riidat voidaan estää oikeanlaisella sopimusjärjestelyllä.
- Työskentele vaiheittaisten sopimusten kanssa. Jaa projekti julkaisuihin tai välitavoitteisiin, joilla kullakin on omat hyväksymiskriteerinsä. Näin vältyt kokonaisuuden arvioimiselta vasta kuukausien kuluttua.
- Sovitaan virallisista hyväksyntätesteistä ennen laskutusta. Sen jälkeen määritetään, mitä toimitetun komponentin on täytettävä ennen kuin maksu erääntyy.
- Kirjaa muutosmenettely, jossa esitetään kuka voi pyytää muutosta, kuka tekee päätökset ja miten suunnittelun ja hinnoittelun seuraukset käsitellään.
- Sovi asian käsittely etenemisestä: ensin keskustelu projektiryhmän sisällä, sitten ohjausryhmä korkeammalla tasolla, sitten sovittelija ja vasta sitten oikeudenkäynti.
- Harkitse riitojenratkaisua SGOA:n kautta. Huomaa yksi käytännön seikka: välimiehet voivat käsitellä vain tapausta, jossa osapuolet ovat etukäteen myöntäneet säätiölle toimivallan, joten kyseisen lausekkeen on oltava sopimuksessa. SGOA tarjoaa tätä varten mallilausekkeita.
Eskalointiportaat varmistavat, että konflikteista keskustellaan varhaisessa vaiheessa ja oikealla tasolla, eikä vasta sitten, kun suhteet ovat katkenneet. Tilanteissa, joissa projekti pysähtyy kriittiseen pisteeseen eikä toinen osapuoli suostu yhteistyöhön, SGOA:n välimiesmenettely tarjoaa nopeaa helpotusta.
Lopuksi
Epäonnistunut ohjelmistoprojekti on harvoin seurausta yhdestä virheestä. Se johtuu yleensä epäselvien spesifikaatioiden, muuttuvien toiveiden, teknisen aliarvioinnin ja huonon yhteistyön yhdistelmästä. Alankomaiden laki tarjoaa vivahteikkaan kehyksen sen määrittämiseksi, kuka kantaa tappiot suorituksen laiminlyönnin, myötävaikutuksen ja velkojan maksukyvyttömyyden vuoksi, mutta sen soveltaminen edellyttää sekä lain että teknologian tuntemusta.
Onko ohjelmistoprojektisi pysähtynyt? Law & More Neuvoo asiakkaita ja toimittajia vastuuseen, projektitietoihin, sopimusten ehkäisyyn ja riitojenratkaisuun liittyvissä asioissa. Ota meihin yhteyttä sopimuksesi ja projektitiedostosi arvioimiseksi.
Usein kysyttyjä kysymyksiä
Alla vastaamme useimmin kysyttyihin kysymyksiin tästä aiheesta.
Onko toimittajani vastuussa, jos ohjelmistoprojekti epäonnistuu?
Ei automaattisesti. On osoitettava, että se ei täyttänyt sovittua ja että tämä on sen syytä. Käytännössä vastuu on usein jaettu molempien osapuolten kesken.
Entä jos asiakkaana olen itse myötävaikuttanut viivästykseen?
Tuomioistuin voi sitten alentaa toimittajan korvausvelvollisuutta Alankomaiden siviililain 6:101 §:n nojalla suhteessa siihen, missä määrin oma toimintasi on vaikuttanut tappioon. Tämä voi alentaa korvausta huomattavasti ja poikkeustapauksissa johtaa sen hylkäämiseen.
Mitä yhteistyövelvollisuus pitää sisällään?
Asiakkaana sinun on toimitettava eritelmät, testitiedot, päätökset ja hyväksynnät ajoissa. Jos näin ei tapahdu eikä toimittaja tämän seurauksena pysty suorittamaan sopimusta, kyseessä ei ole sopimusrikkomus, ja saatat itse joutua velkojan velvollisuuden laiminlyöntiin (Alankomaiden siviililain 6:58 artikla ja sitä seuraavat pykälät).
Miksi asiantuntija usein määrätään?
Koska arkkitehtuuria, lähdekoodia ja testiraportteja koskevat kysymykset vaativat teknistä tietämystä, jota ei voida odottaa tuomarilta, Alankomaiden siviiliprosessilain pykälien 194–207 nojalla voidaan tilata tuomioistuimen määräämä asiantuntijalausunto, jonka tuloksella on suuri painoarvo.
Mitä projektidokumentteja minun tulisi säilyttää?
Sopimus liitteineen, toiminnalliset ja tekniset eritelmät, muutospyynnöt, projektisuunnittelu- ja edistymisraportit, testiraportit, viivästystä ja hyväksyntää koskeva kirjeenvaihto sekä lähdekoodi dokumentaatioineen. Ilman näitä asiakirjoja asiantuntija ei usein pysty vastaamaan kysymykseen.
Miksi muutosprosessilla on niin suuri merkitys?
Ilman virallista menettelyä toimeksianto laajenee huomaamatta, kun taas suunnittelu ja budjetti pysyvät samoina. Riitatilanteissa on mahdotonta selvittää, milloin ja miksi laajuus muuttui. Kirjaa ylös, kuka voi pyytää muutosta, kuka päättää siitä ja miten suunnittelun ja hinnan seuraukset käsitellään.
Mikä on hyväksymiskriteerien tarkoitus?
Ne määrittävät objektiivisesti, milloin toimitettu komponentti on vaatimusten mukainen. Tämä tekee selväksi, milloin maksu erääntyy, ja estää pitkälti myöhemmät kiistat toimituksen moitteettomuudesta. Ne on mieluiten sidottava julkaisuihin tai virstanpylväisiin, joissa on viralliset hyväksyntätestit.
Mitä lähdekoodille tapahtuu, kun aloitan uudelleen toisen toimittajan kanssa?
Se riippuu sopimuksestasi. Ilman sopimuksia lähdekoodin julkaisemisesta, rakennetun järjestelmän immateriaalioikeuksista ja mahdollisista escrow-järjestelyistä uudelleenkäynnistys voi viivästyä huomattavasti. Sovi tästä sopimusta tehdessäsi, älä jälkikäteen.
Mitä tuloksia menettelyillä voi olla?
Osittainen purkaminen, kun vain osa on mennyt virheellisesti (Alankomaiden siviililain 6:265 § luettuna yhdessä 6:270 §:n kanssa), vahingonkorvaukset 6:74 §:n nojalla, vähennys myötävaikutuksen perusteella 6:101 §:n nojalla ja kohtuullinen korvaus 6:109 §:n nojalla. Tuomioistuimet soveltavat kohtuullista korvausvaatimusta säästeliäästi.
Voinko ratkaista riidan tuomioistuimen ulkopuolella?
Kyllä. Välimiesoikeus tarjoaa sovittelua, välimiesmenettelyä, välimiesmenettelyn yhteenvetomenettelyä, sitovia neuvoja ja asiantuntijalausuntoja, ja päätöksentekijöinä toimivat alan ammattilaiset. Välimiehet voivat käsitellä vain tapauksia, joissa osapuolet ovat etukäteen myöntäneet toimivallan säätiölle, joten sisällytä tämä lauseke sopimukseen.
Miten voin välttää pitkittyneen riidan?
Työskentele vaiheittaisten sopimusten ja julkaisukohtaisten hyväksymiskriteerien kanssa, sovi virallisista hyväksymistesteistä ennen laskutusta, kirjaa muutosmenettely ja sovi prosessista, joka kulkee projektiryhmästä ohjausryhmään, sovittelijaan ja vasta sitten oikeudenkäyntiin.
Onko sinulla riita IT-toimittajan kanssa tai haluatko IT-sopimuksen tarkistuksen? IT-lakimiehemme auttavat mielellään.
Miten Law & More voi auttaa sinua tässä, selitetään meidän IT-lakimies sivu.
