Hvad bruges uviklingsaftaler til?
- Når noget skal skræddersyes (programmeres) til virksomheden – standardløsning er ikke nok.
- Forventningsafstemning imellem parterne ift. hvad der skal laves og hvad planen er.
- Aftale præcis hvad der skal levere/gennemføres. (realindhold)
Hvad ligger til grund for udviklingen?
- Udviklingen sker på baggrund af en kravspecifikation (fra kunden) og en løsningsbeskrivelse (fra leverandør)
Hvad er regelgrundlaget for udviklingsaftaler?
- Udviklingsaftaler tager ofte udgangspunkt i standardkontrakterne (K01, K02, K03, K04)
- Den konkrete udviklingsaftale vil bestå af, parternes indbyrdes forpligtelser.
- Ved standardløsninger har leverandøren ansvaret for, at systemerne overholder præceptive regler, hvorimod det er modsat for udviklingsaftaler.
Hvad er vigtigst før kontrakten udarbejdes?
- KEND FORMÅLET FØR KONTRAKTEN UDARBEJDES!!
- Den vigtigste del af formålet, er selve leverancen – hvad skal leveres / gennemføres – og hvad er REALINDHOLDET?
Vandfaldsmodellen og udviklingsaftaler
- Kravene til systemet er blevet aftalt forud for udvikling.
- K01 og K02 er ofte vandfaldsleverancer.
o Der er udarbejdet ændringsbestemmelser, hvis der skal foretages ændringer af det planlagte. - Fordele:
Kunder og leverandør kender til omkostninger og tidsplan. - Ulemper:
I praksis kan alt ikke planlægges på denne vis
Hvad er K01?
o K01 er målrettet standardleverancer hvortil der kun tilføjes specialændringer.
Kortvarige projekter på 0-6 mdr.
Målrettet leverancer af standardløsninger, med kun få specialtilpasninger.
Kundens deltagelse er begrænset.
Hvad er K02
o K02 er velegnet store IT Projekter, som indebærer en faseopdelt projektplan med delleverancer.
Længere varende IT Projekter +6 mdr.
I højere grad specialtilpasning af systemet
Som udgangspunkt leveres systemet som én leverance, men kan godt deles op i delleverancer.
Den agile udviklingsmodel
- Kravene til systemet fastlægges løbende imellem parterne. Det er ikke muligt at fastlægge dem på forhånd.
- K03 er en oplagt standardkontrakt
- Fordele:
Forandringsparathed – Man skubber beslutningskompetencen. - Ulempen:
Der kan ikke sættes en fast pris ved indgåelse af kontrakten.
Kan stikke af prismæssigt.
Hvad er K03?
o Er velegnet til IT Projekter der følger den agile leverancemodel
o Dækker også over rådgivning og ledelse af IT Projektet.
o Mindsker risiko, da delleverancer bliver testet løbende, og der kan tage bedre beslutninger grundet den øgede risiko.
o Høj inddragelse af kunder (aktivt og løbende)
Hvordan vælges leverencemodeller?
- Man vælger leverancemodel ud fra 3 parametre:
Kravene til systemet
Betaling
- Fast beløb eller pr. time
Tidsplan
- K01 og K02 har en fast defineret tidsplan forud for projektet påbegyndelse.
- K03 har ikke en fast defineret tidsplan, da kravene endnu ikke er lavet, og projektet derfor ikke kan estimeres.
resultatforpligtigelse
Resultatforpligtelse er en kontraktmæssig forpligtelse til at tilvejebringe et bestemt slutresultat.
Indsatsforpligtelse
En kontraktmæssig forpligtelses til at præstere en arbejdsindsats for at realisere et vist mål, selv om dette ikke måtte blive opnået.
Betaling af udviklingskontrakt
- Fast pris / Fixed price
- T&M (Time & Material)
- Kombinationer:
Maksimalpriskontrakt – T&M med loft
Fast pris med minimum scope - Tidspunkt for betaling
Fremgår af betalingsplanen.
Realydelser for udviklingskontrakter:
o Programmering o Projekt Ledelse o Etablering og drift af IT Miljø o Dokumentation o Test Data o Test og afprøvning o Undervisning o Medvirken / Deltagelse / Tilgængelighed
Realydelser - Forhold imellem leverandør og kunder
- Leverandør skal ALTID levere realydelser, men ofte skal kunderne også (eks. I form af data til test)
Derfor: Sørg for at afdække ALLE realydelser, og beskriv dem i et nødvendigt omfang. - Det er essentielt også at få beskrevet kundens omfang i projektet, da det ofte kan være en kritisk vej, hvis ikke det er tydeliggjort.
Ovenstående er en nødvendighed, fordi de fleste IT Projekter efterhånden er blevet
samarbejdsprojekter
Hvilke Krav kan stilles til leverancen / systemet:
- Funktionelle krav
- Svartid / efficiens
- Kompatibilitet
- Uddybningsmuligheder
- Dokumentation
- (Bløde emner: God IT Skik og best practices)
- Jo flere krav, desto dyrere bliver projektet i sidste ende
Levering og afprøvning
- Levering sker, når det endelige system er blevet afprøvet, og at kunden godkender, at det var hvad de bedte om (afhænger af aftale self)
- Levering kan enten ske direkte, successivt eller løbende.
- Ved levering overgår risikoen fra Sælger til Køber. (Ligesom ved købeloven)
Ændringshåndtering i kontrakten
o K01 og K02 -> ændringsbestemmelser, som dikterer hvordan ændringer skal indføres.
o K03 -> Agil metode der tager højde for ændringer undervejs, og blot inkluderer ændringer i næste interation.
Rettigheder til det udviklede system
- Hvis ikke andet er bestemt, tilfalder ophavsretten udvikleren af systemet (Er personen arbejdstager
tilfalder ophavsretten arbejdsgiver), så længe kravet om originalitet gør sig gældende. - Hvis andet, defineres det i kontrakten. Typisk skal kunden have nogle rettigheder.
Normalvis i store udviklingsprojekter, så vil kunden få ALLE rettigheder, også ophavsretten.
Nogle projekter nøjes kunden med brugsretten, hvorfor sælger har mulighed for at genbruge
produktet, hvilket gør det billigere for kunden.
Misligholdelse - Hvad skal man være opmærksom på ved udviklingsaftaler?
- Når aftalen skal laves, og der skal bestemmes misligholdelsesbeføjelser, skal man tænke over hvilke beføjelser, der giver det resultat man gerne vil opnå.
Eks. Hvis man skal bruge software, kan man ikke bruge en ophævelse til noget.
Her vil man langt hellere have mulighed for at erstatte leverandøren.
Obs: Faseopdeling muliggør at man kan gå fra hinanden i mellem faserne
Uenigheder ved udviklingsaftaler - Et ’nyt’ men klassisk princip
o Er man blevet uvenner, må man få det bedste ud af det. Det bliver anerkendt ved kontrakt indgåelse, at
kontrakten er kompleks og derfor kræver samarbejde for at blive løst.
o Parterne forpligtiger sig til loyalt at løse problemer og uenigheder.
Samarbejdet skal være efter præmissen ”Udbedre først – afregn/afklar senere”.
Leverandøren skal altså levere produktet, og hvis kunden har uret, skal leverandøren kompenseres
fuldt ud.
o Leverandøren må på INTET tidspunkt tilladt at tilbageholde leverancer eller ydelser, som er blevet
forpligtiget til kunden.
