Bing Hodneland logo

Fra 1. august 2012 vil jeg være advokat på heltid som partner i Bing Hodneland.



Nye bøker


Mer >>
Flere nye bøker

Gå til "bokhandelen"

Geocaching i Norge
Amazon US
In Association with Amazon.co.uk


Previous page:

Innledning

Next page:
Previous page: Kap 6. Spesifikasjon av kontraktsgjenstanden Next page: I hvilken grad kan ytelsen spesifiseres på forhånd?

Det viktigste element i enhver avtale er spesifikasjon av den ytelse som skal presteres. På nesten alle andre punkter kan man fylle ut en avtale. Hvis prisen ikke er angitt, kan man falle tilbake på kjl § 45 (1), som sier at det skal betales gjengs pris, eventuelt det som er rimelig etter forholdene dersom det ikke er noen gjengs pris. For entrepriseavtaler gjelder i stor grad regelen om kostpris når ikke annet er avtalt.(55) Når man ikke har andre holdepunkter, gjelder et alminnelig regningsprinsipp, som innebærer at kunden i mangel av annen avtale må betale det som kreves, når dette er rimelig. Se Rt 1978 s. 702 Interiørarkitektens royalty. Førstvoterende, dommer Elstad, uttaler på s. 708:(56)

«Utgangspunktet ved suppleringen må etter min oppfatning være at NHK plikter å betale det Christiansen forlanger såfremt han krav ikke må anses ubillig. For kjøpsrettens område er prinsippet kommet til uttrykk i kjøpslovens [av 1907] § 5. Jeg mener at prinsippet også må ha gyldighet der en unyansert avtale skapt ved passivitet fra den ene parts side, trenger å fylles ut.»

Selvig(57) mener at man må se bort fra det regningsprinsippet som ble lagt til grunn i Rt 1978 s. 702 etter at prinsippet om gjengs pris på avtaletiden slo igjennom i kjøpsloven, mens Krüger(58) synes å mene at man fortsatt må basere seg på dette. Jeg kan ikke se at man kan komme utenom et slikt regningsprinsipp i de tilfellene hvor det ikke er mulig å påvise noen «gjengs pris». Kjl § 45 (1) er basert på at man i slike tilfeller skal betale det som er rimelig, uten at den sier noe om hvem som har «utspillet» ved slik prisfastsettelse. I praksis vil det neppe bli noen særlig forskjell om man legger det ene eller det annet prinsipp til grunn i slike tilfeller.

Er leveringstiden ikke angitt, skal det etter kjl § 11 (1) leveres innen rimelig tid. Det er ikke sikkert partene så lett vil enes om hva som er rimelig pris eller rimelig tid, men man har i alle fall et utgangspunkt. Men vet man ikke hva som skal leveres, da har man ingen avtale som kan oppfylles. Hvis en kjøper spør selgeren om han kan levere «varer», og selger svarer ja, så er det likevel ikke inngått noen avtale (med mindre forholdet mellom partene er slik at det er klart hva som menes med «varer»).(59)

I større og/eller kompliserte leveranser vil man nok ikke konkludere med at det er inngått bindende avtale dersom de nærmere betingelser ikke er avklart. Men man vil i utgangspunktet ikke stå helt på bar bakke når det er angitt hva som skal leveres.(60)

Det primære formål med en spesifikasjon av ytelsen, er at partene ?? i praksis leverandøren ?? skal vite hva man må gjøre for å oppfylle den forpliktelse man har påtatt seg. Enhver seriøs leverandør er interessert i å oppfylle de kontrakter han inngår, og de fleste kontrakter blir oppfylt uten at det oppstår noen alvorlige problemer. Spesifikasjon av leverandørens ytelse (se kapittel 7), sammen med spesifikasjon av kundens ytelse ( kapittel 13), leveringsplan ( kapittel 9) og prosjektorganisering ( kapittel 8) er sentrale styringsdokumenter når leveransen skal gjennomføres. Selv om også denne fremstillingen vil handle mest om spesifikasjonens betydning i forhold til mangelsvurderingen, og dermed spørsmålet om hvorvidt kontrakten er oppfylt eller ikke, må man ikke tape av syne at det primære formål er å sikre at slike spørsmål ikke blir aktuelle.

En god og presis spesifikasjon vil kunne forebygge konflikter. Er det uklart hva som skal presteres, øker for det første risikoen for at partene har ulik oppfatning av hva leverandøren faktisk har påtatt seg. Leverandøren kan lojalt gjøre alt som er nødvendig for å oppfylle kontrakten slik leverandøren har oppfattet denne, og så viser det seg at kunden har oppfattet kontrakten på en helt annen måte. Kunden får noe annet enn han hadde ventet og mener at leverandøren har misligholdt, mens leverandøren mener at han har levert i henhold til kontrakten. Når man så får en slik konflikt på bordet, vil den også bli vanskeligere å håndtere når kontrakten ikke er klar med hensyn til hva som faktisk skal presteres.

Det er også en viss risiko for at en leverandør vil utnytte uklarheter i kontrakten til å komme fri fra eller redusere sitt ansvar dersom han får problemer med å levere. Også seriøse leverandører får til tider problemer med å oppfylle sine kontraktsmessige forpliktelser, og de er ikke alltid så enkle å ha med å gjøre når problemene først har oppstått.

En uklar spesifikasjon kan utfylles på bakgrunn av hva som har vært sagt i markedsføringen, i møter og forhandlinger. Leverandøren kan være bundet av utsagn som ikke fremgår direkte av kontrakten, se nærmere avsnitt 5.2 og 22.2.3). Men en spesifikasjon i kontrakten vil fremstå som mer forpliktende enn utsagn som ikke er direkte kontraktsfestet. Kunden vil rent faktisk stå sterkere når han kan vise direkte til kontrakten enn når han må basere seg på møtereferater, utsagn fra selgere, osv. I 1990-11-04 Voldgift(61) uttalte voldgiftsretten at anbudsinnbydelsen ikke var gjort til en del av kontrakten, og at den dermed bare var ett, om enn tungtveiende, hjelpemiddel blant flere for tolkingen av kontrakten. I tillegg kan det være vanskeligere å bevise hva leverandøren måtte ha forpliktet seg til utover det som direkte fremgår av kontrakten.

Ved denne typen leveranser bør man også ta hensyn til at IT-bransjen fortsatt er en ung bransje, og at den har hatt en rask og turbulent utvikling. Man har sett en del mindre seriøse elementer. Hvorvidt en leverandør er seriøs eller ikke, oppdager man som regel ikke før man ser hvordan de oppfyller de forpliktelser de har tatt på seg. I tillegg kommer ?? og det er kanskje det viktigste ?? at det er en bransje med mange optimister. Det er ikke vanskelig å finne eksempler på leverandører med overdrevne forventninger til hva de selv kan få til, og ikke minst til hvor lang tid utviklingen vil ta og hva det vil koste.

Mange IT-prosjekter har dårlig prosjektkvalitet i den forstand at de er urealistiske når det gjelder muligheten for i det hele tatt å nå målene, samt tids- og kostnadsestimater. Men prosjektkvalitet og kontraktskvalitet er ikke nødvendigvis det samme. Hvis kontrakten gir de nødvendige mekanismer til å håndtere de problemer som oppstår i et dårlig prosjekt, så har kontrakten fungert godt. En klar, men urealistisk spesifikasjon leder til mislighold fra leverandøren. Men den fører ikke til vanskeligheter med å konstatere om det foreligger mislighold eller ikke. På den annen side vil en i og for seg realistisk, men uklar spesifikasjon lett kunne ende i mislighold, til tross for at leverandøren i utgangspunktet ikke skulle ha problemer med en slik leveranse. Uklarheten gir risiko for misforståelser. Og det vil være vanskelig å konstatere hvorvidt det foreligger mislighold eller ikke. Legger man til at kombinasjonen urealistisk og uklar spesifikasjon ikke er helt sjelden, er det lett å forstå at man lett kan få problemer.

I en undersøkelse av 24 større amerikanske bedrifter, fant IBM Consulting Group at 55% av alle programvareprosjekter koster mer enn forventet, 68% holder ikke tidsfristene og 88% må gjennomgå omfattende redesign.(62) Det synes som om disse tallen gjelder bedriftsintern utvikling av programmer, og ikke oppdrag om utvikling for andre. Man kan derfor ikke uten videre trekke den konklusjon at en like stor andel av utviklingsoppdrag ikke gjennomføres som forutsatt. Men det gir en pekepinn om at forsinkelser, mangler m.v. ikke er uvanlig.

Hvorvidt forsinkelser og eventuell funksjonssvikt skal regnes som kontraktsbrudd, avhenger av hva leverandøren har forpliktet seg til. Det samme gjelder spørsmålet om hvorvidt leverandøren kan kreve ekstra betaling ved kostnadsoverskridelser.

Det har utviklet seg en egen edb-sjargong som beskriver programmer som markedsføres før de er ferdige. Foilware er slikt som foreløpig bare finnes på selgernes overhead-transparenter. Promiseware er slikt som loves, men som slett ikke alltid leveres. Vapourware er programmer som har blitt lovet, men som aldri har blitt levert og som ingen lenger vil snakke om. Motsatsen er shelfware, som er produkter som finnes i hyllene, og som forblir der fordi den ikke selger. Presentasjon av uferdige programmer brukes ofte bevisst i markedsføringen, for å hindre at eksisterende og potensielle kunder kjøper et konkurrerende produkt i stedet for å vente på det denne leverandøren håper på å kunne utvikle og ha klart «real soon now». Leverandørene er også flinke til å «lekke» slike informasjoner til en datapresse som ikke akkurat utmerker seg ved seriøsitet og journalistisk integritet, og som ofte lar seg bruke av leverandørene.

Klare spesifikasjoner i kontrakten kan dels føre til at leverandøren tenker seg om en ekstra gang, dels at han i ettertid ikke så lett kan løpe fra sine løfter.

Noen bøker om IT-kontrakter


More >>
The Managers Guide to Understanding Commonly Used Contract Terms: Comm
RefNr: 0852977581
Bestill fra:
Amazon UK
Amazon US
Bokkilden

More >>
The Outsourcing Revolution: Why it Makes Sense to do it Right: Why It
The Outsourcing Revolution" features case studies detailing how specific companies planned, implemented, and are managing BPO. Results from surveys of more than 1,500 companies provide real data on what organizations around the world are doing and why, as well as what does and doesn't work.
RefNr: 0793192145
Bestill fra:
Amazon UK
Amazon US
Bokkilden

More >>
Kontrakter for utvikling av programvare
Boka tar for seg utviklingskontrakter for dataprogramvare.
RefNr: 9788202196912
Bestill fra:
Bokkilden

More >>
Outsourcing: The Legal Contract
Providing an introduction to outsourcing, this title identifies and discusses the main aspects which should be specified in the contract and indicates the factors which facilitate a successful outsourcing relationship.
RefNr: 1841523607
Bestill fra:
Amazon UK
Amazon US
Bokkilden

Gå hit for full oversikt over bøker om IT-kontrakter.


Previous page: Previous page: Kap 6. Spesifikasjon av kontraktsgjenstandenNext page: I hvilken grad kan ytelsen spesifiseres på forhånd? Next page: