Mida tuleks kontrollida lepingutes süsteemiarenduse puhul alltöövõtu korras?

Majandus- ja tööstusministeerium on esitanud “Juhtnöörid infotehnoloogia süsteemide usaldusväärsuse parandamiseks” IT-süsteemide arenduslepingute mudelklauslite. Interneti leviku ja muude tegurite tõttu on infotehnoloogia süsteemide rikete põhjustatud äritegevuse ja teenuste katkestuste või funktsionaalsuse vähenemise sotsiaalne mõju üha süvenemas. Samal ajal, kui IT-süsteemide arendamise lepingute mudel on sageli ebaselge, on selle mudeli eesmärk selgitada ja visualiseerida rollide jaotust ja vastutussuhteid. Selles artiklis selgitame, viidates majandus- ja tööstusministeeriumi mudellepingu klauslitele, mida tuleks kontrollida, kui sõlmitakse leping IT-süsteemide arendustööde teostamiseks.

Süsteemiarendus ja alltöövõtuleping

Mis on alltöövõtuleping?

Alltöövõtuleping on tsiviilõiguses määratletud järgmiselt:

Artikkel 632
Alltöövõtt tekib siis, kui üks osapool lubab töö lõpule viia ja teine osapool lubab selle töö tulemuse eest tasu maksta.

Alltöövõtulepingus on seaduse järgi nõutav, et “töö lõpuleviimine” on kokkulepitud. Näiteks, kui lepingu eesmärk on luua kindel süsteem kindlaks kuupäevaks, siis on tarnija kohustus “süsteem lõpule viia kindlaks kuupäevaks”. Kui süsteemi ei suudeta lubatud kuupäevaks lõpule viia, võib tarnijale määrata vastutuse lepingu rikkumise eest. Kuid, kui süsteem on kuupäevaks lõpule viidud ja tarnitud, kuid hiljem leitakse puudusi, siis tarnija kohustus on juba täidetud, seega lepingu rikkumine ei ole probleem ja edaspidi on küsimus puuduste garantii vastutuses. Millistel juhtudel “töö lõpuleviimine” süsteemiarenduses tunnustatakse, selgitatakse üksikasjalikult järgmises artiklis.

https://monolith.law/corporate/completion-of-work-in-system-development[ja]

Erinevused volituse alusel sõlmitud lepingutega

Alltöövõtulepingutes on tarnijal kohustus töö lõpule viia, seega kui tarnitud tulemusel on puudusi, on tarnijal puuduste garantii vastutus. Seevastu volituse alusel sõlmitud lepingutes ei ole töö lõpuleviimise kohustust, seega ei ole alltöövõtulepingu sarnast puuduste garantii vastutust. Siiski, kui äritegevuse käigus tunnustatakse hoolsuskohustust, võib eraldi tekkida kahju hüvitamise või muu lepingu rikkumise vastutus. Milline vastutus võib süsteemiarenduslepingutes probleemiks muutuda, selgitatakse üksikasjalikult järgmises artiklis.

https://monolith.law/corporate/responsibility-system-development[ja]

Lepingulise mudeli sõnastus ja kontrollpunktid

Nõuete määratluse loomise tugiteenused

Nõuete määratlus on protsess, kus kasutajad koondavad süsteemi, mida nad soovivad ehitada, nõudmisspetsifikatsioonid. Nõuete määratluse etapis kaalutakse süsteemi ehitamise suunda ja otsustatakse, millist süsteemi ehitada. Kuna tulemused ei ole konkreetsete ootuste osas selged, on Jaapani Majandus-, Kaubandus- ja Tööstusministeeriumi mudelleping määratlenud selle kui poolvolituse. Üksikasju selgitatakse allpool toodud artiklis.

https://monolith.law/corporate/system-development-contract-check-quasi-mandate[ja]

Välise kujunduse dokumentatsiooni koostamise teenused

(Välise kujunduse dokumentatsiooni koostamise teenuste osutamine)
Paragrahv ○. Teine pool peab sõlmima eraldi lepingu paragrahvi ○ alusel ning teostama käesoleva lepingu alusel välise kujunduse dokumentatsiooni koostamise teenuseid, mis põhinevad nõuete määratluse dokumendil, mis on kindlaks määratud paragrahvi ○ alusel.

2. Välise kujunduse dokumentatsiooni koostamise teenuste osutamisel võib teine pool nõuda esimeselt poolt vajalikku koostööd ning esimene pool peab sellele õigeaegselt vastama, kui teine pool seda nõuab.

Välise kujunduse dokumentatsiooni koostamine hõlmab ekraanide, aruannete jms kasutamise planeerimist, mis on seotud liidestega. Välise kujunduse dokumentatsioonis peab olema kõik vajalik info, mille alusel tarnija saab programmi arendada. Välise kujunduse dokumentatsioon sisaldab üksikasjalikku teavet vormide kasutamise kohta, kuid nõuete muutmise õigus on kasutajal, kes määrab äritegevuse sisu. Siiski, kui nõuete määratluse dokument, mis on välise kujunduse dokumentatsiooni koostamise teenuste eelnev etapp, on selgelt määratlenud kasutaja vajadused ja tarnija poolt täidetava töö sisu, võib välise kujunduse dokumentatsiooni koostamise lepingu sõlmida tarnijapõhiselt.

Esimeses lõigus on sätestatud, et kuna see protsess on tarnijapõhine, on tarnija töö teostamise peamine osapool. Siiski, isegi kui leping on tarnijapõhine, on välise kujunduse osa suuresti seotud kasutaja äritegevuse kindlaksmääramisega, seega on vaja kasutaja aktiivset osalemist. Seetõttu sätestab teine lõik, et tarnija võib nõuda kasutajalt süsteemi spetsifikatsioonide arutelu ja otsustamiseks vajalikku koostööd ning kasutaja peab sellele õigeaegselt vastama, selgitades, et süsteemi spetsifikatsioonide arutelu on tarnija ja kasutaja ühine töö.

(Välise kujunduse dokumentatsiooni koostamise teenuste eraldi lepingu sõlmimine)
Paragrahv ○. Esimene ja teine pool otsustavad välise kujunduse dokumentatsiooni koostamise teenuste osas paragrahvi ○ lõike ○ alusel kirjeldatud tehingutingimused läbirääkimiste teel ning sõlmivad välise kujunduse dokumentatsiooni koostamise teenuste eraldi lepingu.

Välise kujunduse dokumentatsiooni koostamise teenuste ulatuse osas on eelnevalt sätestatud tehingutingimuste alusel sõlmitud eraldi leping.

(Välise kujunduse arutelukomisjon)
Paragrahv ○. Teine pool korraldab vajaduse korral välise kujunduse dokumentatsiooni koostamiseks vajalike küsimuste selgitamiseks või sisu kinnitamiseks välise kujunduse arutelukomisjoni (edaspidi selles jaotises “välise kujunduse arutelukomisjon”) paragrahvi ○ alusel ning esimene pool osaleb selles.

2. Kui esimene pool peab vajalikuks välise kujunduse dokumentatsiooni koostamist, võib esimene pool korraldada välise kujunduse arutelukomisjoni ning teine pool osaleb selles.

3. Kui esimene pool soovib muuta nõuete määratluse dokumenti välise kujunduse arutelukomisjoni arutelude tulemusena ning see nõuab tööperioodi, tasu jms eraldi lepingu tingimuste muutmist, tuleb järgida paragrahvi 33 (lepingu ja eraldi lepingu sisu muutmine) protseduure.

Ekraanide, aruannete jms liideste määramiseks välise kujunduse dokumentatsiooni koostamisel on vajalik kasutaja ja tarnija koostöö. Kuna see protsess on tarnijapõhine, on esimeses lõigus sätestatud, et arutelukomisjoni korraldab tarnija ja kasutaja osaleb selles. Välise kujunduse dokumentatsiooni koostamiseks vajalike küsimuste selgitamine või sisu kinnitamine toimub välise kujunduse arutelukomisjonis ning tarnija ja kasutaja on arutelukomisjoni arutelutulemustega seotud.

Teises lõigus on sätestatud, et kasutaja võib korraldada välise kujunduse arutelukomisjoni, kui ta peab seda välise kujunduse dokumentatsiooni koostamise teenuste osutamiseks vajalikuks.
Kolmandas lõigus on sätestatud, et kui arutelude tulemusena soovib kasutaja muuta nõuete määratluse dokumenti ja see mõjutab eraldi lepingu tööperioodi, tasu jms, tuleb järgida teise paragrahvi protseduure, mis käsitlevad lepingu ja eraldi lepingu sisu muutmist.

(Välise kujunduse dokumentatsiooni esitamine)
Paragrahv ○. Teine pool esitab eraldi lepingus määratud tähtajaks välise kujunduse dokumentatsiooni ja välise kujunduse dokumentatsiooni vastuvõtmise taotluse (koos tarnedokumendiga) esimesele poolele.

Kuna see protsess on tarnijapõhine, peab tarnija esitama välise kujunduse dokumentatsiooni jms tulemusena.

(Välise kujunduse dokumentatsiooni heakskiitmine ja kinnitamine)
Paragrahv ○. Esimene pool kontrollib eraldi lepingus määratud perioodi jooksul (edaspidi “välise kujunduse dokumentatsiooni kontrollimise periood”), kas välise kujunduse dokumentatsioon vastab paragrahvi ○ alusel kinnitatud nõuete määratluse dokumendile ja paragrahvi ○ alusel määratud välise kujunduse arutelukomisjoni otsustele ning kas seal ei ole loogilisi vigu, ning kinnitab selle sobivuse ja loogiliste vigade puudumise tõendina märgivad mõlema poole vastutavad isikud välise kujunduse dokumentatsiooni heakskiitmisdokumendile oma nime ja pitseri. Kuid kui kontrollimise tulemusena leitakse, et välise kujunduse dokumentatsioon ei vasta paragrahvi ○ alusel kinnitatud nõuete määratluse dokumendile ja välise kujunduse arutelukomisjoni otsustele või on seal loogilisi vigu, peab teine pool koostama parandatud versiooni määratud tähtaja jooksul pärast konsulteerimist ja esitama selle esimesele poolele ning esimene pool peab uuesti läbi viima eespool nimetatud kontrollimise ja heakskiitmise protseduuri.

2. Kui esimene pool ei esita välise kujunduse dokumentatsiooni kontrollimise perioodi jooksul kirjalikult konkreetseid põhjuseid, loetakse, et esimene pool on välise kujunduse dokumentatsiooni kontrollimise perioodi lõppemisel välise kujunduse dokumentatsiooni heaks kiitnud.

3. Esimese poole heakskiitmine vastavalt eelmisele lõikele tähendab, et välise kujunduse dokumentatsioon on kinnitatud.

Välise kujunduse etapis määratakse kindlaks nõuded, mis on vajalikud järgnevate sisemise kujunduse dokumentatsiooni koostamise jms teostamiseks, kuid kui nõuete kinnitamine on ebamäärane, võib see põhjustada probleeme järgnevas arenduses. Selles paragrahvis on sätestatud protseduur, millega kinnitatakse välise kujunduse dokumentatsioon, mis on aluseks järgnevatele arendustöödele, kasutaja kontrolli ja heakskiidu alusel.

Esimeses lõigus on sätestatud, et kasutaja kontrollib, kas eraldi paragrahvi alusel kinnitatud nõuete määratluse dokument ja välise kujunduse arutelukomisjoni arutelutulemused vastavad välisele kujundusele ning kas seal ei ole loogilisi vigu. Välise kujunduse dokumentatsiooni heakskiitmiseks vajaliku kontrolli käigus võib olla vajalik teha parandusi ja selle paragrahvi märkus sätestab selle protseduuri.
Teises lõigus on sätestatud, et isegi kui heakskiidu allkirjastamine on lõpetamata, kuid kasutaja ei ole teatud aja jooksul esitanud vastuväiteid, loetakse, et kasutaja on heakskiidu andnud. Kui kasutaja heakskiidu olemasolu või puudumine jääb ebamääraseks ja siseneb sisemise kujunduse faasi, võib see hiljem põhjustada probleeme, seega on selle paragrahvi eesmärk vältida selliseid probleeme.

Ja kolmandas lõigus on sätestatud, et kasutaja heakskiit kinnitab välise kujunduse dokumentatsiooni.

(Vastutus defektide eest)
Paragrahv ○. Kui pärast eelmise paragrahvi kinnitamist leitakse välise kujunduse dokumentatsioonis nõuete määratluse dokumendi ja paragrahvi ○ alusel määratud välise kujunduse arutelukomisjoni otsuste mittevastavus või loogilised vead (edaspidi selles paragrahvis “defektid”), võib esimene pool nõuda teiselt poolelt nimetatud defektide parandamist ning teine pool peab need defektid parandama. Kuid teine pool vastutab sellise parandamise eest ainult siis, kui esimene pool on esitanud taotluse eelmise paragrahvi kinnitamise järgse ○ kuu jooksul.

2. Sõltumata eelmisest lõigust, kui defekt on väike ja välise kujunduse dokumentatsiooni parandamine nõuab ebaproportsionaalselt suuri kulusid, ei pea teine pool eelmises lõigus sätestatud parandamiskohustust täitma.

3. Esimese lõigu sätteid ei kohaldata, kui defekt on tekkinud esimese poole poolt esitatud materjalide või juhiste tõttu. Kuid see ei kehti, kui teine pool teadis, et need materjalid või juhised on ebasobivad, kuid ei teavitanud sellest.

Selles paragrahvis on sätestatud välise kujunduse dokumentatsiooni defektide vastutus. Defektide vastutusperioodi määravad osapooled läbirääkimiste teel, võttes arvesse infotehnoloogiasüsteemi suurust, tasu jms.

Esimeses lõigus on välise kujunduse dokumentatsiooni ja nõuete määratluse dokumendi ning välise kujunduse arutelukomisjoni otsuste mittevastavus ning välise kujunduse dokumentatsiooni loogilised vead määratletud defektidena.

Teises lõigus on sätestatud, et isegi kui defekt on väike, kuid tarnitud toote parandamine nõuab ebaproportsionaalselt suuri kulusid, ei pea tarnija täitma tasuta parandamise kohustust, järgides tsiviilseadustiku artikli 634 lõike 1 märkust, et kaitsta tarnijat.

Kolmandas lõigus on sätestatud, et tsiviilseadustiku artikli 636 märkuse kohaselt, kui defekt on tingitud kasutaja juhistest või esitatud materjalidest, ei pea tarnija vastutama, välja arvatud juhul, kui tarnija teadis, et need materjalid või juhised on ebasobivad, kuid ei teavitanud sellest.

Märkus: defektide vastutus on vabatahtlik sätte, seega kui sellist sätet ei ole, kohaldatakse tsiviilseadustiku üldpõhimõtteid. Defektide vastutus on suuresti mõjutatud 2020. aasta aprillis jõustunud tsiviilseaduse muudatustest, seega pärast tsiviilseaduse muudatuste jõustumist on see valdkond, kus käsitlemine erineb varasemast. Üksikasju selgitatakse järgmises artiklis.

https://monolith.law/corporate/defect-warranty-liability[ja]

Tarkvaraarenduse teenused

(Tarkvaraarenduse teenuste osutamine)
Paragrahv 〇. Teine pool (vendor) teostab pärast individuaalse lepingu sõlmimist, mis on sätestatud paragrahvis 25, tarkvaraarenduse teenuseid, mis põhinevad süsteemi spetsifikatsioonidel, mis on kindlaks määratud eelnevates lõikudes, alates sisemisest disainist kuni süsteemi testimiseni.

2. Tarkvaraarenduse teenuste osutamisel võib teine pool (vendor) nõuda esimeselt poolelt (klient) vajalikku koostööd ja esimene pool (klient) peab sellele õigeaegselt vastama, kui teine pool (vendor) nõuab koostööd.

Järgnevalt on sätestatud tingimused, mille alusel tarkvaraarenduse teenusepakkuja (vendor) teostab tarkvaraarendust allhanke korras. Süsteemi sisemise disaini etapis on tavaliselt määratletud arenduse eesmärgid ja spetsifikatsioonid, seega on majandusministeeriumi mudellepingus see sätestatud allhanke korras.

(Individuaalse lepingu sõlmimine tarkvaraarenduse teenuste osas)
Paragrahv 〇. Esimene pool (klient) ja teine pool (vendor) määravad pärast läbirääkimisi kindlaks tehingutingimused, mis on sätestatud paragrahvis 〇, lõikes 〇, ja sõlmivad individuaalse lepingu tarkvaraarenduse teenuste osas.

Tarkvaraarenduse teenuste ulatuse osas on ette nähtud, et see määratakse kindlaks individuaalse lepinguga, mis põhineb eelnevalt määratletud tehingutingimustel.

(Tarnitavate toodete tarnimine)
Paragrahv 〇. Teine pool (vendor) peab esimesele poolele (klient) tarnima individuaalse lepinguga määratud tähtajaks individuaalse lepinguga määratud tarnitavad tooted koos vastuvõtu taotluse vormiga (kaubaarvega).
2. Esimene pool (klient) peab tarnimise korral läbi viima kontrolli vastavalt järgmise paragrahvi kontrolli spetsifikatsioonidele ja lähtudes paragrahvi 〇 (käesoleva tarkvara vastuvõtmine) sätetest.
3. Teine pool (vendor) võib tarnitavate toodete tarnimisel nõuda esimeselt poolelt (klient) vajalikku koostööd ja esimene pool (klient) peab sellele viivitamatult vastama, kui teine pool (vendor) nõuab koostööd.
4. Tarnitavate toodete hävimise, kahjustumise jms riski kannab enne tarnimist teine pool (vendor) ja pärast tarnimist esimene pool (klient).

Kuna see protsess on allhanke korras, tuleb lõpetatud tarkvara jms esitada vastuvõetavate tulemustena kontrollimiseks. Esimene lõige sätestab, et tarnitavad tooted tuleb esitada koos vastuvõtu taotluse vormiga (kaubaarvega).

Teine lõige sätestab kasutaja poolt läbiviidava kontrolli.
Kolmas lõige sätestab kasutaja koostöökohustuse, kuna on võimalik, et individuaalse lepinguga määratud tarnimiskohta tarnimisel on vaja kasutaja koostööd (näiteks kui tooted tuleb tarnida kasutaja kontorisse või kui need tuleb tarnida kasutaja tegelikus töökeskkonnas töötavas olekus).
Neljas lõige on tarnitavate toodete hävimise või kahjustumise riski käsitlev sätte, mis jagab riski vastavalt füüsilise kontrolli üleandmisele.

(Käesoleva tarkvara vastuvõtmine)
Paragrahv 〇. Tarnitavate toodete hulgas tuleb esimesel poolel (klient) kontrollida käesolevat tarkvara individuaalse lepinguga määratud perioodi jooksul (edaspidi “kontrolliperiood”) vastavalt eelmise paragrahvi kontrolli spetsifikatsioonidele ja kontrollida, kas süsteemi spetsifikatsioonid ja käesolev tarkvara vastavad üksteisele.

2. Kui esimene pool (klient) leiab, et käesolev tarkvara vastab eelmise lõigu kontrollile, peab ta allkirjastama ja pitserdama kontrolli läbimise dokumendi ning andma selle teisele poolele (vendor). Lisaks peab esimene pool (klient), kui ta leiab, et käesolev tarkvara ei vasta eelmise lõigu kontrollile, viivitamatult andma teisele poolele (vendor) kirjaliku dokumendi, milles on selgelt märgitud põhjused, miks see ei vastanud, ning nõudma parandusi või täiendusi. Kui põhjused on tunnustatud, peab teine pool (vendor) parandama need tasuta määratud tähtaja jooksul pärast läbirääkimisi ja esimene pool (klient) peab vajadusel uuesti läbi viima eelmise lõigu kontrolli.

3. Kui kontrolli läbimise dokumenti ei anta, kuid esimene pool (klient) ei esita kontrolliperioodi jooksul kirjalikult konkreetseid põhjuseid, loetakse, et käesolev tarkvara on läbinud käesoleva paragrahvi kontrolli.

4. Käesoleva paragrahvi kontrolli läbimist peetakse käesoleva tarkvara vastuvõtmise lõpetamiseks.

Kuna see protsess on allhanke korras, sätestatakse käesolevas paragrahvis menetlus, mille kohaselt viiakse läbi tarnitud tarkvara vastuvõtmine.

Esimene lõige sätestab, et käesoleva tarkvara osas tuleb kontrolliperioodi jooksul läbi viia kontroll vastavalt kontrolli spetsifikatsioonidele ja kontrollida, kas süsteemi spetsifikatsioonid ja käesolev tarkvara vastavad üksteisele.
Teine lõige sätestab, et kui selgub, et käesolev tarkvara ei vasta süsteemi spetsifikatsioonidele, peab teenusepakkuja selle parandama ja esitama parandatud versiooni kasutajale.
Kolmas lõige on säte, mis käsitleb vastuvõtmist, et vältida vastuvõtmise edasilükkamist kasutaja mugavuse tõttu.
Neljas lõige sätestab selgelt, et vastuvõtmine lõpeb kontrolli läbimisega.

(Vastutus defektide eest)
Paragrahv 〇. Kui pärast eelmise paragrahvi kontrolli lõppu avastatakse tarnitavates toodetes süsteemi spetsifikatsioonidega mittevastavusi (sealhulgas vead, edaspidi “defektid”), võib esimene pool (klient) nõuda teiselt poolelt (vendor) defekti parandamist ja teine pool (vendor) peab defekti parandama. Siiski on teise poole (vendor) kohustus parandada defekt ainult siis, kui esimene pool (klient) on seda nõudnud eelmise paragrahvi vastuvõtmise lõppemisest alates ○ kuu jooksul.
2. Sõltumata eelmisest lõigust, kui defekt on väike ja tarnitavate toodete parandamine nõuab ebaproportsionaalselt suuri kulusid, ei pea teine pool (vendor) eelmises lõigus sätestatud parandamiskohustust täitma.
3. Esimese lõigu sätteid ei kohaldata, kui defekt on tekkinud esimese poole (klient) poolt esitatud materjalide või juhiste tõttu. Siiski ei kehti see, kui teine pool (vendor) ei teavitanud, et teadis, et need materjalid või juhised on ebasobivad.

Kuna see protsess on allhanke korras, sätestatakse käesolevas paragrahvis tarnitavate toodete defektide eest vastutamise kohustus. Praktikas on raske eristada kohustuste mittetäitmise vastutust (töö pole lõpetatud) ja defektide eest vastutamise kohustust (töö on lõpetatud). On olemas kohtuotsus (Tokyo District Court, 22. aprill 2002), mis sätestab, et süsteemiarenduse puhul tuleks otsustada, kas süsteem on lõpetatud, sõltuvalt sellest, kas töö on lõpetatud vastavalt esialgsele allhankelepingule kavandatud viimasele etapile. Kui pärast tarkvara lõpetamist ja tarnimist ning vastuvõtmist avastatakse defekt, kohaldatakse põhimõtteliselt defektide eest vastutamise kohustust.

Esimene lõige määratleb “süsteemi spetsifikatsioonide mittevastavuse” defektina tarkvaraarenduse teenuste osas. Välise disaini etapis tekkinud funktsioonipuudujääkide osas määratakse vastutus vastavalt välise disaini etapi defektide eest vastutamise kohustuse või muude sätete alusel. Defektide eest vastutamise perioodi määravad pooled läbirääkimiste käigus, võttes arvesse infosüsteemi suurust, tasu jms.

Teine lõige sätestab, et isegi kui defekt on väike, on ebamõistlik nõuda teenusepakkujalt tasuta parandamist, kui tarnitavate toodete parandamine nõuab ebaproportsionaalselt suuri kulusid, seega on sätestatud sätte, mis on sarnane tsiviilseadustiku artikli 634 lõike 1 märkusega.

Kolmas lõige on sarnane tsiviilseadustiku artikli 636 märkusega, mis sätestab, et kui defekt on tingitud kasutaja juhistest või esitatud materjalidest, ei vastuta teenusepakkuja, kuid kui teenusepakkuja ei teavita, et teadis, et need materjalid või juhised on ebasobivad, ei vabasta see teda vastutusest.

Millistel juhtudel tunnistatakse defektiks ja millised on vastutuse konkreetsed sisud, kui defekt on tunnistatud, on selgitatud järgmises artiklis.

https://monolith.law/corporate/defect-warranty-liability[ja]

Tarkvara kasutuselevõtu ja ülemineku toetamise teenused

Süsteemi vastuvõtmise ja juurutamise etapis on tavaliselt kasutaja see, kes tegevusi juhib. Seetõttu on Jaapani Majandus-, Kaubandus- ja Tööstusministeeriumi (Japanese Ministry of Economy, Trade and Industry) mudellepingus sätestatud, et kasutaja on peamine osapool ning tarkvara müüja toetab teda, määratledes selle kui pooldelegeeritud vormi.

Lepingu olemuse määramine

Lepingu olemuse kindlaksmääramiseks tuleb vaadata lepingu terviklikkust ja selle eesmärki, kas see on “valmis tulemuse pakkumine” või on see, et tarnija “täidab mõistlikult oma ülesandeid”. Üldiseks juhiseks on see, kas projekti eesmärk, mida tuleb täita, on teatud määral kindlaks määratud ja kas projekt on selle poole liikunud. Konkreetsete punktide kohta, millele tähelepanu pöörata, selgitame üksikasjalikult järgmises artiklis.

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