Mikä on projektinhallintavelvollisuus järjestelmäkehityksessä?

Järjestelmän kehittäminen on prosessi, joka edellyttää molemminpuolista yhteistyötä tilaajan ja palveluntarjoajan välillä.

Yritysten käyttämien IT-järjestelmien kehittämisprojektit eivät useinkaan etene suunnitelmien tai odotusten mukaisesti. Pikemminkin projektit kohtaavat usein suurempia tai pienempiä ongelmia ja haasteita, jotka on voitettava etenemisen mahdollistamiseksi. Tässä yhteydessä on tärkeää, että sekä tilaaja että palveluntarjoaja pyrkivät yhteisymmärrykseen, mutta myös konfliktitilanteiden ennakointi ja kriisinhallinta ovat tärkeitä.

Laillisesta näkökulmasta ensimmäinen askel kriisinhallinnassa on selkeyttää, mitä velvollisuuksia molemmilla osapuolilla on ja mitä oikeuksia he voivat vaatia toisiltaan. Tässä artikkelissa keskitymme selittämään, mitä laillisia velvollisuuksia palveluntarjoajalla on koko projektin ajan, keskittyen erityisesti projektinhallintavelvollisuuksiin.

Mitä toimittajan projektinhallintavelvollisuudet ovat

Aloitetaan tarkastelemalla toimittajan projektinhallintavelvollisuuksien sisältöä.

Oikeuskäytännön mukaan projektinhallintavelvollisuudet ovat seuraavat:

– Velvollisuus edistää kehitystyötä sopimuksen mukaisesti, hallita jatkuvasti edistymistä, pyrkiä havaitsemaan kehitystyötä haittaavat tekijät ja käsitellä ne asianmukaisesti

– Velvollisuus hallita asianmukaisesti käyttäjän osallistumista kehitykseen ja pyrkiä estämään, että kehitystyötä haittaavia toimia ei tehdä käyttäjän toimesta, jolla ei ole erityistä tietämystä järjestelmän kehittämisestä

Tämä tarkoittaa, että toimittajan on osoitettava käyttäjälle kysymykset ja määräajat, joissa käyttäjän on tehtävä päätöksiä tai ratkaistava huolenaiheita, osoitettava haitat, jotka syntyvät, jos käyttäjän päätöksenteko viivästyy, annettava neuvoja käyttäjälle päätöksenteon edistämiseksi, ja jos kehityksen etenemisen vuoksi ei voida hyväksyä tiettyjä vaatimuksia, selitettävä syyt perusteellisesti ja kieltäydyttävä käyttäjän vaatimuksista.

Näin ollen toimittajalla on velvollisuus edistää kehitystyötä samalla kun hän kannustaa käyttäjää tekemään päätöksiä ja pyrkii varmistamaan järjestelmän kehittämisen onnistumisen.

Käyttäjän yhteistyövelvollisuus

Kuitenkin, järjestelmän kehittämisessä ei ole niin, että toimittaja ottaa yksipuolisesti vastaan kaikki velvollisuudet. Koska kyseessä on IT-järjestelmä, jota käytetään tilaajan yrityksessä, tilaajan ei pitäisi olla välinpitämätön järjestelmän kehittämisprojektista.

Vaikka ulkopuolisia asiantuntijoita käytettäisiin luottamaan järjestelmän kehittämisen tekniseen ja organisatoriseen kykyyn, sisäisen hallinnon pitäisi olla mukana. Ilman ponnisteluja ulkopuolisten asiantuntijoiden potentiaalin hyödyntämiseksi, on mahdotonta toimittaa tarvittavaa tuotetta täysin ulkopuolisena. Tässä mielessä myös käyttäjällä on velvollisuus yhteistyöhön järjestelmän kehittämisessä.

Käyttäjän tulisi täyttää seuraavat yhteistyövelvollisuudet:

　① Käyttäjän on aktiivisesti tehtävä riskianalyysi, sovitettava sisäiset näkemykset asianmukaisesti ja ilmoitettava vaatimuksensa toimittajalle yhtenäisen näkemyksen perusteella

　② Tarkista tuotokset

　③ Vastaa toimittajan yhteistyöpyyntöihin

Käyttäjän odotetaan selkeästi ilmaisevan toimittajalle järjestelmältä vaadittavat toiminnot ja osallistuvan aktiivisesti kehitykseen.

Projektinhallinta ei ole helppoa

IT-järjestelmän olemassaolo, joka koostuu pienistä osista, saattaa olla vaikea havaita käyttäjille, jotka tarkastelevat vain näyttöä. Kuitenkin, kun pohditaan järjestelmän kehittämisprojektin hallinnan vaikeutta, tämä on erittäin tärkeää. Koska IT-järjestelmä on tällainen, toimittajalta vaaditaan sekä huolellista huomiota että kykyä järjestää koko kuva yksinkertaisesti ja tarkastella sitä yleiskuvana.

On olemassa vaikeuksia, joita ei voida kuvitella vain katsomalla näyttöä, ja tämä on myös syy, miksi projektit “palavat”. Ensimmäinen askel on ymmärtää nämä seikat ja tietää, että “IT-järjestelmän kehittämisprojektin hallinta ei ole helppoa”, mikä on suuri edellytys projektin riskienhallinnan oppimiselle.

Mitä voi tapahtua projektinhallinnan velvollisuuksien rikkomisen tapauksessa

Mitä konkreettisesti tapahtuu, jos projektinhallinnan velvollisuuksia on rikottu?

Tässä asiassa ei ole mitään selkeää pykälää, joka määrittelisi, että “projektinhallinnan velvollisuudet ovat tällaisia”.

Kuitenkin, aikaisempien oikeustapausten perusteella, voimme päätellä jonkinlaisen johdonmukaisen kannan siihen, mitä käyttäjä voi tehdä, jos toimittajalla on ollut velvollisuuksien rikkomus.

Jos toimittajalla on ollut velvollisuuksien rikkomus, käyttäjä voi vaatia toimittajalta vahingonkorvausta tai sopimuksen purkamista. Kuitenkin, jos käyttäjällä on myös ollut ongelmia, toimittaja saattaa todeta, ettei ole vastuussa, tai vähentää vahingonkorvausta kompensoimalla virheitä.

Toisaalta, jos käyttäjällä on ollut yhteistyövelvollisuuksien rikkomus, toimittaja voi vaatia käyttäjältä palkkion vastaavaa määrää, jos työ ei ole valmistunut tämän seurauksena, perustuen vaaraan (Japanin siviililaki, artikla 536, kohta 2) tai velvollisuuden laiminlyöntiin.

Oikeustapaus, joka osoittaa projektinhallintavelvollisuuden

Projektinhallintavelvollisuudesta on olemassa seuraavat merkittävät oikeustapaukset.

Alla oleva tapaus liittyy järjestelmän kehittämiseen, jossa toimitusaikataulu viivästyi ja toimittaja vaati alkuperäisen arvion ylittävää korotusta, mikä johti oikeudenkäyntiin. Tämä on tyypillinen esimerkki niin sanotusta “palavasta tapauksesta”, jossa käyttäjän ja toimittajan vastuun jakaminen johti oikeudenkäyntiin.

Syytetty, järjestelmän kehittämisen asiantuntijana, oli velvollinen rakentamaan järjestelmän sopimuksen ja ehdotuksen mukaisesti, perustuen omaan korkeatasoiseen asiantuntemukseensa ja kokemukseensa, ja saattamaan järjestelmän valmiiksi sovitun toimitusajan kuluessa. Näin ollen, syytetyn olisi pitänyt edetä kehitystyössä sopimuksen ja ehdotuksen mukaisesti esitettyjen kehitysprosessien, -menetelmien ja -vaiheiden mukaisesti, hallita jatkuvasti edistymistä, pyrkiä löytämään tekijät, jotka estävät kehitystyön, ja käsitellä niitä asianmukaisesti. Lisäksi, koska järjestelmän kehittäminen edellyttää neuvotteluja tilaajan kanssa ja sen suorittamista ottaen huomioon tilaajan toiveet, syytetyn olisi pitänyt hallita asianmukaisesti tilaajan, tässä tapauksessa kantajan, osallistumista järjestelmän kehittämiseen ja pyrkiä estämään kantajan, jolla ei ole asiantuntemusta järjestelmän kehittämisestä, tekemästä toimia, jotka estävät kehitystyön. Tätä kutsutaan “projektinhallintavelvollisuudeksi”.

Tokion alioikeuden päätös, 10. maaliskuuta 2004 (Heisei 16)

Yllä olevan tuomion ydin ei ole tärkeää ymmärtää yksityiskohtaisia sanamuotoja tai monimutkaista tapahtumien kulkua. Tärkeintä on, että termiä “projektinhallintavelvollisuus” käytetään sellaisenaan. Vaikka ei olekaan olemassa kirjallista lakipykälää, tuomioistuin pyrkii vahvistamaan ohjeet oikeudellisen vastuun jakamiseksi.

Yllä olevan tuomion sisältö on yksinkertaistettu ja järjestetty luetteloksi. Tässä yhteydessä “projektinhallintavelvollisuus” tarkoittaa:

• Työn eteneminen suunnitelman (kehitysprosessit, -menetelmät, -vaiheet jne.) mukaisesti
• Työn etenemisen seuranta
• Jos on olemassa tekijöitä, jotka estävät työn sujuvan etenemisen, niiden havaitseminen ja asianmukaisten toimenpiteiden toteuttaminen

Lisäksi yllä mainittuihin kolmeen kohtaan liittyen,

• Toimittajan on tehtävä yhteistyötä käyttäjän kanssa tarvittaessa, eikä vain pyrkiä ratkaisemaan ongelmia yksin. Tämä sisältää myös viestinnän.

Tämä voidaan ymmärtää yhteenvetona.

Järjestelmän kehittäminen on pääasiassa joko mandaatti- tai urakkasopimuksen muodossa. Mandaattisopimus on yksinkertaisesti sopimus, jossa “tehdään työtä palkkion saamiseksi ja suoritetaan työ palkkion mukaisella tarkkuudella”. Näin ollen projektinhallintavelvollisuus voidaan ymmärtää käsitteenä, joka sisältyy “tarkkuuteen” jota tulee saavuttaa.

Vaikka onkin kiistanalainen aihe, myös urakkasopimuksissa, jotka ovat sopimuksia “tehdä pyydetty työ”, voidaan katsoa syntyvän projektinhallintavelvollisuus. Syynä on, kuten aiemmin mainittiin, että järjestelmän kehittäminen, olipa kyseessä sitten mandaatti- tai urakkasopimus, edellyttää aina projektinhallintaa, ja toimittajan katsotaan olevan velvollinen suorittamaan sen.

https://monolith.law/corporate/contract-and-timeandmaterialcontract[ja]

Oikeustapaus, joka osoittaa projektinhallintavelvollisuuden, joka voidaan määrätä myös ennen sopimuksen tekemistä

On myös ajateltu, että projektinhallintavelvollisuus voi olla voimassa jo ennen sopimuksen tekemistä. Seuraavassa lainatussa oikeustapauksessa osoitetaan, että myös sopimuksen tekemistä edeltävässä vaiheessa, eli kun erilaisia ehdotuksia ja suunnitelmia esitetään, myyjällä on projektinhallintavelvollisuus.

Seuraavassa tapauksessa kyse oli projektista, joka keskeytyi kesken kaiken, ja riidanalaiseksi tuli, voiko projektinhallintavelvollisuuden tunnustaa suunnittelun ja ehdotusten tekemisen vaiheessa tai tarjousvaiheessa käyttäjälle annettujen selitysten puutteiden vuoksi. Yleisesti ottaen suunnittelu- ja ehdotusvaihe on ennen sopimuksen tekemistä, joten kysymys oli siitä, onko tällaisen velvollisuuden tunnustaminen laillisesti mahdollista. Tuomioistuin tunnusti tämän.

Projektinhallintavelvollisuuden ajattelutapa edellä mainitussa oikeustapauksessa ulottuu myös sopimuksen tekemistä edeltävään vaiheeseen, kuten seuraavasta käy hyvin ilmi.

Suunnittelu- ja ehdotusvaiheessa määritellään projektin tavoitteet, kehityskustannukset, kehityksen laajuus ja kehitysaika sekä projektin suunnitelma ja toteutettavuus. Lisäksi tähän mukautuen määritellään myös projektiin liittyvät riskit. Siksi suunnittelu- ja ehdotusvaiheessa myyjältä vaadittava projektin suunnittelu ja riskianalyysi ovat välttämättömiä järjestelmän kehittämisen kannalta. Tästä seuraa, että myyjänä heidän on tutkittava ja varmennettava itse ehdottamansa järjestelmän toiminnot, käyttäjän tarpeiden tyydyttävyys, järjestelmän kehitysmenetelmät, kehitysorganisaatio tilauksen jälkeen jne. suunnittelu- ja ehdotusvaiheessa, ja heillä on velvollisuus selittää käyttäjälle odotettavissa olevat riskit. Tällainen myyjän tutkimus- ja selitysvelvollisuus voidaan sijoittaa sopimuksen tekemiseen tähtäävän neuvotteluprosessin aikana hyvän uskon periaatteen mukaiseksi velvollisuudeksi vahingonkorvausoikeuden mukaan, ja valittajalla on myyjänä tällainen velvollisuus (projektinhallintavelvollisuus tässä vaiheessa).

Tokion korkeimman oikeuden päätös 26. syyskuuta 2013 (Heisei 25)

Huomautettakoon, että tämä ajattelutapa, jonka mukaan on olemassa tiettyjä laillisia velvollisuuksia myös ennen sopimuksen tekemistä, ei rajoitu vain IT-projekteihin, vaan se on ollut olemassa alun perin kaikissa kaupallisissa transaktioissa ja oikeudellisissa neuvotteluissa.

Yleensä suuremmat kaupat vaativat pitkän “lähestymisprosessin” ennen sopimuksen tekemistä. Tässä prosessissa on selvää, että ainakin moraalisesti tulisi olla rehellinen toista osapuolta kohtaan. Yksinkertaisesti sanottuna, tämä ei ole vain tunneperäinen moraalinen tunne, vaan sillä on myös laillinen merkitys. (Seuraavassa lainataan lainkohta. Kirjoittaja on lisännyt alleviivauksen.)

Siviililaki, 1 § 2 momentti
Oikeuksien käyttämisen ja velvollisuuksien täyttämisen on tapahduttava rehellisesti ja hyvässä uskossa.

Yllä oleva sisältö tiivistetään oikeuden päätöksessä käytettyyn “hyvän uskon periaate” -avainsanaan.

Huomautettakoon, että tässä artikkelissa esitetyt oikeustapaukset ovat myös eräänlaisia ohjeita “käyttäjän yhteistyövelvollisuuden ja myyjän projektinhallintavelvollisuuden rajan vetämiseksi”. Lisätietoja IT-järjestelmän kehittämisen yhteydessä käyttäjän yhteistyövelvollisuudesta löytyy seuraavasta artikkelista.

https://monolith.law/corporate/user-obligatory-cooporation[ja]

Yhteenveto: Konsultoi asianajajaa, jos projektinhallinnan velvollisuuksien rikkomiseen liittyviä ongelmia ilmenee

Tässä artikkelissa olemme yrittäneet järjestää yleisesti asioita, jotka liittyvät projektinhallinnan velvollisuuksiin järjestelmäkehityksessä. Järjestelmäkehitykseen liittyy monia haasteita ja ongelmia, mutta kun tällaisia tilanteita kohtaamme, tärkeää näyttäisi olevan “perusta”, joka on yhteinen kaikille kiistatilanteille. On totta, että yksittäisten epäsäännöllisten tilanteiden olemassaolossa on loputtomasti variaatioita.

Kuitenkin, kun kohtaamme tällaisia tilanteita, kysymyksen “Kuka ja kuinka paljon oli alun perin ottanut vastuun laillisista velvollisuuksista?” merkitys ylittää tapauksen yksilöllisyyden ja sillä on tiettyä universaalisuutta.

Sen sijaan, että keskittyisimme ad hoc -ongelmanratkaisuun, ratkaisun etsiminen rakentavan haasteen jakamisen kautta, vihjeet näyttävät olevan myös laissa ja aikaisemmissa oikeustapauksissa.

Jos projektinhallinnan velvollisuuksien rikkomiseen liittyviä ongelmia ilmenee, ota heti yhteyttä asianajajaan.