Fælles projektmodel i staten – skal skaleres i forhold til projektets ...

itb.dk

Fælles projektmodel i staten – skal skaleres i forhold til projektets ...

KONTRAKTUNDERSTØTTELSE AF

ITERATIVE PROJEKTMODELLER

Advokat, LL.M. Søren Wolder


AGENDA

13:30 14:00 Registrering

14:00 14:10 Velkomst og introduktion til emnet

14:10 14:30 Generel introduktion til den juridiske vinkling af iterative

projekter og agil programudvikling

14:30 15:00 Kontraktretlige temaer i den iterative it-kontrakt med

15:00 15:15 Pause

særlig focus på emnerne leverancebeskrivelse,

prismodeller, kontrakt/projektstyring

15:15 16:00 Fortsat gennemgang af kontraktretlige emner

16:00 16:15 Pause

16:15 16:30 Iterative projekter og udbudsreglerne

16:30 17:00 Tak for i dag / spørgsmål (buffer)


VELKOMST OG INTRODUKTION TIL EMNET


VELKOMST OG INTRODUKTION TIL EMNET

Advokater og de interne juridiske afdelinger må

nødvendigvis se på kontraktgrundlaget for iterative

projekter med nye og innovative øje og holdninger.


VELKOMST OG INTRODUKTION TIL

EMNET

“Recently, I attended a talk by an excellent lawyer on software contracts. Her

message was quite clear: write a sound and detailed specification and

contract the vendor based on this document. Seems simple enough, but I

raised my hand and asked her how to deal with the fact that projects are

much more efficient and have fewer risks when done iteratively and in an

agile way as compared to the waterfall style she had laid out. "Well, these

are business problems, and I'm not a business expert" was her reply.”

“She was right: the life of a lawyer would be much easier, if perfect

specifications were written right from the beginning - and the life of a

project manager would be easier, too. But project managers have tried this

path for 20 years without any significant success. And some "experts" claim

that the method we use is not right, and we only need to use/buy their great

tool or process to solve any problems. But they have been telling us this for

20 years, and their claims resemble Jerry Weinberg's first law of bad

management: "If what you're doing isn't working, do more of it“.

Kilde: Cutter Consortium


GENEREL INTRODUKTION TIL DEN

JURIDISKE VINKLING AF ITERATIVE

PROJEKTER OG AGIL PROGRAMUDVIKLING


DEN JURIDISKE VINKLING AF ITERATIVE PROJEKTER OG AGIL

PROGRAMUDVIKLING

Den traditionelle kontraktopfattelse

Traditionelle vs. Iterative kontrakter

• forventning om, at kontrakten kan placere og definerer parternes ansvar,

medvirken og roller i projektet

• Kontrakten bør fordele ansvar på en “fair” måde, så enhver kun er ansvarlig

for det kontraktparten faktisk har indflydelse på.

• disse antagelser hviler på en forudsætning om, at målet for projektet er

kendt.

Den agile kontrakts udfordring

• Agile projekter kræver i højere grad, at projekterne er baseret på sharedprofit

kontrakter. (mål-pris, fleksible tidsplaner fleksibelt scope)

• Dvs. et ”skæbnefællesskab”, som ikke er særligt populært i de afdelinger

der tager sig af indkøb, jura og styring.


DEN JURIDISKE VINKLING AF ITERATIVE PROJEKTER OG AGIL

PROGRAMUDVIKLING

Traditionelle vs. Iterative kontrakter


DEN JURIDISKE VINKLING AF ITERATIVE PROJEKTER OG AGIL

PROGRAMUDVIKLING

Traditionelle vs. Iterative kontrakter

Vandfaldsmodellen er baseret på tillid til kundens forberedende arbejde inden

kontraktens indgåelse og mistillid til leverandørens kontraktopfyldelse.

Iterative kontrakter er baseret på tillid til parternes samarbejde ved

kontraktens opfyldelse.


DEN JURIDISKE VINKLING AF ITERATIVE PROJEKTER OG AGIL

PROGRAMUDVIKLING

Traditionelle vs. Iterative kontrakter

• Samarbejde er omdrejningspunkt i iterative kontrakter. Kernen i en iterativ

proces er et tæt og dynamisk samarbejde mellem parterne ofte via fælles

projektteam.

• Samarbejdet omfatter både ”projektet” og udviklere. Forretning og IT skal

arbejde sammen om at skabe forretningsværdi under styret risiko.

• Kontrakten skal derfor styre risiko og facilitere samarbejdet.


DEN JURIDISKE VINKLING AF ITERATIVE PROJEKTER OG AGIL

PROGRAMUDVIKLING

Traditionelle vs. Iterative kontrakter

• Implementering af iterative projekter kræver i høj grad, at fokus flyttes fra

kontraktstyring til projektstyring.

… hvilket stiller krav til kontraktens fokus.


DEN JURIDISKE VINKLING AF ITERATIVE PROJEKTER OG AGIL

PROGRAMUDVIKLING

Den procesorienterede aftale

• I stedet for alene at basere kontrakten på et resultat, baserer man den på en

proces, der skaber dette resultat.

• Og derfor bliver kontrakten som styringsredskab for processen helt

afgørende.

• Kontrakten skal have særlig fokus på reguleringen af processen og styringen

af processen.

• Den skal i (endnu) højere grad styre projekts gennemførelse end en

traditionel vandfaldsbaseret kontrakt


DEN JURIDISKE VINKLING AF ITERATIVE PROJEKTER OG AGIL

PROGRAMUDVIKLING

Den procesorienterede aftale

• Kontrakten skal navnlig have fokus på

• Samarbejdsrelation mellem parterne

• Bemanding af projektet

• Den iterative metode

• Projektledelse og projektstyrelse

• Prioritering af krav og ønsker

• Fremdriftsrapportering og risklogs

• Styring af økonomi og tid


DEN JURIDISKE VINKLING AF ITERATIVE PROJEKTER OG AGIL

PROGRAMUDVIKLING

• ITST 10 arkitekturprincipper

Den procesorienterede aftale

• Nr. 1. ” Forretningsbehov bør drive og definere løsningerne”

• Nr. 3. ”Processer bør optimeres i forbindelse med digitalisering”

• Nr. 8. ” Udnyt mulighederne ved anskaffelser”

• ITST ”15 skarpe”

• Nr. 4. ”Brug agile udviklingsmetoder og spis elefanten i små bidder”

• Nr. 15. ”Del viden og samarbejde på tværs


DEN JURIDISKE VINKLING AF ITERATIVE PROJEKTER OG AGIL

PROGRAMUDVIKLING

IT udredning 2010

• Indsatsområde 1: Kompetenceløft og fælles metoder:

Fælles projektmodel i staten skal skaleres i forhold til projektets størrelse

og risikoprofil, og der udarbejdes en ”light-model” for mindre it-projekter

• Indsatsområde 2: Fokus på de risikofyldte projekter:

Etablering af fem principper for gennemførelse af it-projekter.

• 4. Projekterne skal opdeles i mindre og selvstændige værdiskabende dele,

som besluttes og gennemføres uafhængigt af hinanden.

• Indsatsområde 3: Bedre samarbejde med leverandører og rådgivere

Mindre omfattende kravspecifikationer


DEN JURIDISKE VINKLING AF ITERATIVE PROJEKTER OG AGIL

PROGRAMUDVIKLING

Grundlæggende vilkår for den iterative proces

Kontrakten skal fortsat respektere, at iterative projekter er

hverken rendyrket anarki eller et tag-selv bord for leverandøren


DEN JURIDISKE VINKLING AF ITERATIVE PROJEKTER OG AGIL

PROGRAMUDVIKLING

Grundlæggende vilkår for den iterative proces

Agile kontrakter bør derfor hvile på følgende hovedregler:

• Ændringer er gratis på ikke påbegyndt funktionalitet

• Ændringer i prioritet er gratis, forudsat totalen ikke ændre sig

• Nye funktioner/krav kan lægges ind undervejs så længe funktionaliteter/

krav af tilsvarende størrelse tages ud

• Kunden kan opsige/afbryde samarbejdet når som helst mod betaling af

forud defineret udtrædelsesvederlag

• Kunden skal være i stand til at prioritere alle sine krav indbyrdes

• Kunden er ansvarlig for, at relevante og kompetente brugere følger og

deltager i projektet og at disse er udstyret med tilstrækkeligt ansvar og

beslutningskompetence for at kunne give leverandøren nyttigt feedback og

i øvrigt bidrage uden at forsinke projektet


DEN JURIDISKE VINKLING AF ITERATIVE PROJEKTER OG AGIL

PROGRAMUDVIKLING

• Juli 2008: SKI 02:18

På vej til den iterative kontrakt

• April 2009: SKI vejledning til udformning af kontrakter under 02.18 med brug

af iterative forløb

• Efterår 2009: 01i, 02i, 03i (BvHD DAHL)

• Marts 2010: ITST redegørelse

• Ultimo 2012:K03


DEN JURIDISKE VINKLING AF ITERATIVE PROJEKTER OG AGIL

PROGRAMUDVIKLING

• 01i, 02i og 03i

På vej til den iterative kontrakt

• Mindre projekter kan anvende 01i eller 03i

• Større projekter kan anvende 02i

• 01i er baseret på K01, 02i er baseret på K02

• 03i er formuleret mere frit i forhold til K-kontrakterne


DEN JURIDISKE VINKLING AF ITERATIVE PROJEKTER OG AGIL

PROGRAMUDVIKLING

Fællestræk ved 01i, 02i og 03i

• Krav til modenhed

• Business case

• T&M/Maksimalpris

• Metodeneutral

På vej til den iterative kontrakt

• Fokus på samarbejde, ressourcestyring og prioritering

• Fleksibel udtrædelsesadgang for kunden


KONTRAKTRETLIGE TEMAER I DEN

ITERATIVE IT-KONTRAKT MED SÆRLIG

FOCUS PÅ EMNERNE

LEVERANCEBESKRIVELSE, PRISMODELLER,

KONTRAKT/PROJEKTSTYRING


LEVERANCEBESKRIVELSE OG

PROJEKTGENNEMFØRELSE


KONTRAKTRETLIGE TEMAER -

LEVERANCEBESKRIVELSE

Leverancebeskrivelsen er ikke slutproduktet

• Ydelser - Leverandørens ydelser er andet end blot etablering af forud

fastlagt funktionalitet

• Metodeanvendelse

• Projektledelse

• Ressourcestyring

• Rådgivning

• (SKI vejledning pkt. 2.4 s. 10)

• Procedure og samarbejde - Større krav til forankring i kontrakten af

projektledelse, beslutningskompetence og procedurer.

• Krav - Kravspecifikationen får en anden rolle. Virker som ramme for

samarbejdet og prioriteringsoversigt, mens de konkrete funktionalitetskrav

fastlægges undervejs


KONTRAKTRETLIGE TEMAER -

LEVERANCEBESKRIVELSE

Håndtering i K01 og K02

• Kunden udarbejder kravspecifikation, og denne danner grundlag for

leverandørens besvarelse.

• HR: Kravspecifikation forventes at være udtømmende oplistning.

• U. ”Hvad kunden med føje kan forvente”

• Kunden er hovedansvarlig for, at kravene er formuleret entydigt.

• Leverandøren er primært ansvarlig for opfyldelsen


KONTRAKTRETLIGE TEMAER -

LEVERANCEBESKRIVELSE

Håndtering i iterative kontrakter

• Kunden udarbejder en Behovsopgørelse, som skal indeholde:

(i) beskrivelse af Kundens Business Case,

(ii) de forretningsgange, Leverancen skal understøtte, samt

(iii) overordnet beskrivelse af ønsket funktionalitet

• Dette dokument danner grundlag for leverandørens tilbud


KONTRAKTRETLIGE TEMAER -

LEVERANCEBESKRIVELSE

Håndtering i iterative kontrakter

• Indhold af business case

• Forretningsmæssige mål

• Baggrund for valg af projekt model

• Interessenter

• Beskrivelse af løsning

• Delprojekter

• Specifikke ”constraints”

• Kunderessourcer til rådighed

• Afhængigheder

• Risici

• Opfølgning

• Etc.

• Den Digitale Taskforce, Videnskabsministeriet, KL og Danske Regioner:

”Business case for digitaliseringsprojekter”

http://modernisering.dk/da/projekter/business_case/


KONTRAKTRETLIGE TEMAER -

LEVERANCEBESKRIVELSE

• Brug af business case

• Planlægning

Håndtering i iterative kontrakter

• Dialogværktøj i forholdet kunde leverandør

• Grundlag for leverandørens udarbejdelse af tilbud

• Leverandørens tilbud kan eventuelt kræves relateret direkte til

kundens business case

• Afklaringsfasens forløb kan styres af business case

• enyttes af kunden til efterfølgende intern evaluering af projektets

forløb


KONTRAKTRETLIGE TEMAER -

LEVERANCEBESKRIVELSE

Løsningsbeskrivelse

• På baggrund af kundens behovsopgørelse udarbejder leverandøren en

Løsningsbeskrivelse forud for aftalens indgåelse.

”Leverandørens overordnede besvarelse af Kundens Behovsopgørelse ved

Kontraktens indgåelse. Løsningsbeskrivelsen udgør en del af

Leverancebeskrivelsen og vil som den øvrige del af Leverancebeskrivelsen

løbende undergå ændringer undervejs i Projektet.”


KONTRAKTRETLIGE TEMAER -

LEVERANCEBESKRIVELSE

Løsningsbeskrivelse - detailspecifikation

• Under de efterfølgende iterationer frembringes løbende en række

detailspecifikationer.

• Når detailspecifikationerne er godkendt af Kunden, udgør disse en del af

Leverancebeskrivelsen sammen med Behovsopgørelsen og

Løsningsbeskrivelsen.


KONTRAKTRETLIGE TEMAER -

LEVERANCEBESKRIVELSE

Leverancebeskrivelse

• Leverancebeskrivelsen = Behovsopgørelse+Løsningsbeskrivelse

+detailspecifikationer

• Leverandøren skal holde Leverancebeskrivelsen løbende ajour med

godkendte detailspecifikationer samt foretage de fornødne

konsekvensrettelser af Behovsopgørelsen og Løsningsbeskrivelsen, som den

enkelte Iteration giver anledning til, og indhente Kundens godkendelse heraf

ved Iterationens afslutning.

• Den gældende udgave af Leverancebeskrivelsen skal til enhver tid være

elektronisk tilgængelig for Kunden på et Projektsite eller lignende.


KONTRAKTRETLIGE TEMAER -

LEVERANCEBESKRIVELSE

Leverancebeskrivelse alternativ model uden behovsopgørelse

Kunne baseres på ”sure step” metoden. I den forbindelse gennemføres en

diagnose og analysefase.

• Diagnosefasen

tilvejebringelse af overordnet løsningsbeskrivelse

• Analysefasen

• definere og fastlægge de aktiviteter, der er nødvendige med henblik på at

få defineret og planlagt hele projektet

Denne model er velegnet til mindre projekter, men kræver stor parathed hos

Leverandøren og er baseret på en grundlæggende forudsætning om, at Kunden

ønsker en standardløsning i så vid udstrækning som muligt.


KONTRAKTRETLIGE TEMAER -

LEVERANCEGENNEMFØRELSE

Leverancemodel - iterativt


KONTRAKTRETLIGE TEMAER -

LEVERANCEGENNEMFØRELSE

• De overordnede faser i i01 og i02

• Afklaring

• Design, udvikling og test

• Godkendelse og overtagelse

Leverancemodel i01 og i02


KONTRAKTRETLIGE TEMAER -

LEVERANCEGENNEMFØRELSE

• De overordnede faser i i01 og i02

• Afklaring

Leverancemodel i01 og i02

• Fortsat behov for grundlæggende drøftelser af kundens

behovsopgørelse og belysning af risikofaktorer i projektet


KONTRAKTRETLIGE TEMAER -

LEVERANCEGENNEMFØRELSE

• De overordnede faser i i01 og i02

• Design, udvikling og test

Leverancemodel i01 og i02

• Etablering af udviklingsmiljø og testmiljø

• Design og udvikling baseres på den valgte iterative model

• definition og beskrivelse af trin

• Kontrolpunkter

• Testprocesser

• Delovertagelse og ibrugtagning


KONTRAKTRETLIGE TEMAER -

LEVERANCEGENNEMFØRELSE

• De overordnede faser i i01 og i02

• Godkendelse og overtagelse

Leverancemodel i01 og i02

• Projektet godkendes og overtages samlet

…. men reduceret betydning


KONTRAKTRETLIGE TEMAER -

LEVERANCEGENNEMFØRELSE

Leverancemodel i01 og i02

Aktiviteterne i en fase (vil afhænge af den

valgte iterative model)


KONTRAKTRETLIGE TEMAER -

LEVERANCEGENNEMFØRELSE

Leverancemodel sure step

Bruges sure step metoden gennemløbes følgende faser:

• Diagnose

• Analysefase

• Designfasen

• Udviklingsfasen

• Udrulningsfasen

• Drift

I dette forløb arbejdes der iterativt. Men projekterne er baseret på en

tidsplan og en projektøkonomi. Udfordringen består i håndteringen af dette.


KONTRAKTRETLIGE TEMAER -

LEVERANCEGENNEMFØRELSE

Leverancemodel sure step


KONTRAKTRETLIGE TEMAER -

LEVERANCEGENNEMFØRELSE

• Projektledelse og projektstyring

Centrale elementer

• Metode, kvalitetssikring og risikostyring

• Styring på tid frem for funktionalitet (”time boxing”)

• Fokus på styring af parternes personale

• Samarbejds- og beslutningsprocedurer

• Styring af økonomi v/ fast pris/maksimal pris og/eller stramme krav til

rapportering af tidsforbrug

• Krav til fremdriftsrapportering og risikolog


PAUSE


PRISMODELLER


PRISMODELLER

Prisregulering

• I den ideelle agile verden fraviges udgangspunktet om fast pris, identificeret

leveringstidspunkt og klart definerede krav.

• De tre parametre må behandles ”alternativt” i den agile kontrakt.

• Graden af fleksibilitet på de tre områder er givetvis ikke identisk

• Offentlige kunder operere med bevillinger og private kunder arbejder

under budgetter, og det er derfor ofte ikke muligt at arbejde uden en fast

defineret økonomisk ramme.

• Risikoen for budgetoverskridelser er alt andet lige ofte mindre i et

iterativt end i et vandfaldsprojekt(!)


PRISMODELLER

Specifikationer

Graden af fleksibilitet (udtrykt gennem cirklernes størrelse)

Leveringstid

Pris

Systemet

Billedet kan ikke vises. Computeren har muligvis ikke

hukommelse nok til at åbne billedet, eller billedet er

muligvis blevet beskadiget. Genstart computeren, og åbn

derefter filen igen. Hvis det røde x stadig vises, skal du

muligvis slette billedet og indsætte det igen.

Leveringstid

Prisen

Specifikationer


PRISMODELLER

• Prismodeller

• Forbrugsafregning

Principper

• Forbrugsafregning med shared risk (målpris)

• Forbrugsafregning med maksimal pris (maksimalpris)

• Fast pris

• Bemærk at omfanget af funktionalitet ikke er fast i et iterativt forløb.

Det endelige omfang fastlægges undervejs i projektet, og er delvis

bestemt af de ressourcer, der er til rådighed for projektet

• Forbrugsafregning forudsætter fastlæggelse af krav til registrering af

forbrug, rapportering samt bestemmelser om opfølgning i forhold til

økonomi


PRISMODELLER

Målpris

Anvendelsen af målpris forudsætter at kunden er villig til at give afkald på den

sikkerhed der ligger i det loft maksimalprisen er udtryk for.

Fra IT- og Telestyrelsens vejledning


PRISMODELLER

Målpris i norske kontrakter


PRISMODELLER

Målpris i norske kontrakter


PRISMODELLER

Maksimalpris

• Leverandøren angiver en maksimalpris bestående af;

a) En fast pris for de leverancer, hvor prissætningen af disse

er uafhængig af omfanget af Leverandørens ydelser.

b) En forventet pris på de dele af Leverancen, som skal

udføres efter medgået tid.

c) Et usikkerhedstillæg.

• Maksimalprisen må ikke overskrides.

• Maksimalprisen omfatter ikke vederlag for vedligeholdelse og

support, og løbende betalinger for anvendelse af Programmel.


PRISMODELLER

Maksimalpris


KONTRAKTSTYRING/PROJEKTSTYRING


KONTRAKTSTYRING/PROJEKTSTYRING

Krav til kontraktstyring uanset prismodel

• Jo større fleksibilitet i prismodellen des større krav til styringen

• Opgaverne i kontraktstyringen

• Styringen af udviklingen i risiko-loggen og indflydelsen på prisrammen

• Udvidelser af projekt-scope kontra påregnelig fleksibilitet og betydningen

for prisrammen en udvidelse eller indskrænkning af projektet skal

således også håndteres i forhold til en eventuel ændring i prisrammerne

• Oplysningspligten i forhold til timebaseret afregning


KONTRAKTSTYRING/PROJEKTSTYRING

Styring af timebaserede vederlag

• Specifikationskrav med hensyn til ydelser, der vederlægges på grundlag af

medgået tidsforbrug.

• Det er Leverandørens ansvar til stadighed at give Kunden et retvisende og

fyldestgørende billede af projektets økonomi baseret på Projektets status.

• Leverandøren skal senest hver den 5. i en måned sende Kunden en detaljeret

opgørelse af tidsforbruget i den forgangne måned og om nødvendigt

maksimalpris (i) Leverandørens eventuelle forslag til ændret prioritering, (ii)

aftalte ændringer eller udvidelser af Projektet og (iii) en opdatering af

Risikologgen.

• Maksimalprisen må ikke overskrides uden Kundens forudgående godkendelse.


KONTRAKTSTYRING/PROJEKTSTYRING

Styring af timebaserede vederlag

• Der skal være balance mellem sikkerhed og fleksibilitet

Eksempel på uheldig kontraktformulering (kundevenlig):

Leverandørens vederlagsestimat er baseret på en grundig gennemgang af

kundens krav og forventninger til projektet og er således udtryk for et

ansvarligt estimat. Det er i enhver henseende leverandørens ansvar, at

prisestimatet er forsvarligt. Leverandøren kan ikke kræve større vederlag

end estimeret, medmindre fravigelsen skyldes omstændigheder, som

leverandøren ikke kunne have forudset ved meddelelsen af

prisestimatet.”


KONTRAKTSTYRING/PROJEKTSTYRING

Styring af timebaserede vederlag

• Der skal være balance mellem sikkerhed og fleksibilitet

Eksempel på uheldig kontraktformulering (leverandørvenlig):

”Såfremt en opgave ikke udføres på fast tid, kan der fastsættes et estimat.

Et sådant estimat er baseret på Kundens ønsker og Leverandørens viden om

projektet på aftaletidspunktet og er ikke bindende for Leverandøren.

Såfremt et estimat overskrides væsentligt, skal Kunden informeres herom,

således at Parterne i fællesskab kan aftale de nødvendige

konsekvensrettelser.

Medmindre overskridelserne kan tilregnes Leverandørens væsentlige

misligholdelse, fritages Leverandøren for resultatansvaret, såfremt Kunden

ved overskridelse af estimatet ikke ønsker arbejdet fortsat. Kunden betaler

Leverandøren for de timer, der er erlagt, forinden Kundens anmodning om

afslutning af arbejdet er modtaget.”


KONTRAKTSTYRING/PROJEKTSTYRING

Hvor går projektstyringen typisk galt?

Det kan også gå galt i iterative projekter. Årsagerne kan være:

• Ofte ”glemmer” Leverandøren at gøre opmærksom på, hvad det vil sige at

arbejde agilt.

• Kunden er ikke klar til at arbejde agilt, og omkostninger/tid løber løbsk.

• Manglende fokus på de omkringliggende behov (samspillet med andre dele af

kundens IT-miljø)

• Leverandøren får ikke dokumenteret ændringer og udviklinger i projekter og

der opstår et ”gab” mellem det beskrevne og det realiserede projekt?


KONTRAKTSTYRING/PROJEKTSTYRING

Projektorganisation

• Kvalifikationer hos kundens projektdeltagere

• Kundens deltagere!

• Leverandøren skal være opmærksom på, at der ikke kan forventes

bedre kvalifikationer end angivet af kunden, og leverandøren skal

indrette sine ydelser efter disse oplysninger

• Kundens beslutningstagere i projektet

• Skal sikre at forretningsmæssig viden er tilrådighed

• Skal træffe beslutninger

• Formidle behov og forretningsmæssig viden

• Hurtig og umiddelbar eskalationsvej


TIDSPLAN OG AFPRØVNING


TIDSPLAN OG AFPRØVNING

Tidsplan

• Ved Kontraktens indgåelse angives alene en overordnet hovedtidsplan, der

• Fastlægger projektets overordnede rammer,

• Fastlægger de enkelte trin (funktionelle testbare område og

kontrolpunkter)

• Fastlægger opdelingen i Delleverancer og tidspunktet for levering heraf.

• Aktiviteterne i afklaringsfasen bør dog være detaljeret beskrevet

• Udarbejdelse af detaljeret tidsplan

• Løbende opdatering af hovedtidsplan


TIDSPLAN OG AFPRØVNING

Afprøvning

• Den iterative metode indebærer ofte løbende tests af de det leverede i hver

enkelt iteration.

• De tests, der er en del af den iterative metode, er beskrevet i bilaget, der

indeholder den iterative metode.

• De kontraktuelle tests er beskrevet i prøvebilaget.

• Inden idriftsættelsen af den enkelte delleverance skal der være gennemført

en delleveranceprøve.

• Behov for ændringer i bilaget om afprøvning?


MISLIGHOLDELSESBEFØJELSER


MISLIGHOLDELSESBEFØJELSER

Forsinkelse

• Frister angives som ved vandfaldsmodel-kontrakter

• Bod for forsinkelse

• Reduktion af vederlag indtil milepæl er opfyldt

• ”Klassisk” beregning


MISLIGHOLDELSESBEFØJELSER

Mangler

• Begrebet mangel vil afhænge af prismodel og kravspecifikationen

• mangelsbegrebet er i højere grad relevant i forhold til ”processen og

leverandørens evne til at skabe ”value for money”

• En række mangelsvurderinger vil ikke være ”sort/hvide” men derimod

afhænge af et fagligt skøn.


MISLIGHOLDELSESBEFØJELSER

• Reducerede timesatser

Mangler forslag til sanktion

• ”For arbejde med afhjælpning af Mangler i garantiperioden og andre

garantiarbejder, som ikke er omfattet af en eventuel

vedligeholdelsesaftale, hvor der er aftalt en fast pris, er

Leverandøren berettiget til at fakturere Kunden dette arbejde i

henhold til de aftalte timesatser med fradrag af 25%.”


MISLIGHOLDELSESBEFØJELSER

Ophævelse

• Fortsat nødvendigt med mulighed for hel eller delvis ophævelse.

• Bør kun være en mulighed for ophævelse ”ex nunc” (fremadrettet).

• Skal ses i lyset af den løbende opsigelsesadgang og ”working software”.

• Opfyldelse af vedligeholdelses- og driftsaftaler ingen afsmittende virkning.

• Erstatningskravet ved ophævelse.


UDTRÆDELSESADGANG


UDTRÆDELSESADGANG

Kunden kan altid udtræde

• Den iterative tankegang bygger på forudsætning om fuldstændig fleksibilitet

• Derfor skal kunden også have mulighed for at stoppe undervejs;

• Når som helst men varsel skal indbygges

• Forpligtelser bortfalder

• Frembragt materiale ret til efterfølgende brug

• Betaling af vederlag

• Allerede gennemførte leverancer

• Allerede bestilte leverancer

• Kompensation?


UDTRÆDELSESADGANG

Særlige problemstillinger

• Garantier for allerede foretagne leverancer

• Support- og vedligeholdelse

• Udlevering af oplysninger


UDTRÆDELSESADGANG

• Vederlaget kan opgøres som:

Udtrædelsesvederlag

a. Det beløb som Leverandøren har til gode for den del af Projektet, som

allerede er gennemført,

b. Dokumenterede direkte udlæg og direkte omkostninger i tilknytning til

Projektet, som Leverandøren har pådraget sig, inden Leverandørens

modtagelse af Kundens Meddelelse om at ville udtræde, og som ikke er

dækket af Leverandørens krav på vederlag i henhold til punkt a).

Leverandøren er i forbindelse med opgørelsen af punkt (b) ovenfor

forpligtet til at søge at begrænse udgifterne mest muligt.


PAUSE


ITERATIVE PROJEKTER OG

UDBUDSREGLERNE


ITERATIVE PROJEKTER OG

UDBUDSREGLERNE

IT- og Telestyrelsens vejledning om agil udvikling i den offentlige sektor


ITERATIVE PROJEKTER OG

UDBUDSREGLERNE

IT- og Telestyrelsens vejledning om agil udvikling i den offentlige sektor


ITERATIVE PROJEKTER OG

UDBUDSREGLERNE

IT- og Telestyrelsens vejledning om agil udvikling i den offentlige sektor

• Udgangspunktet for udbud af kontrakten er den samme som ”almindelige

projekter”

• Den udbudte genstand er ikke et detaljeret beskrevet slutprodukt

• Leverandørens ydelser er andet end etablering af forud fastsat funktionalitet

• Metodeanvendelse / Projektledelse

• Ressourcestyring

• Rådgivning

• Kontrakten er opbygget om andet end slutresultatet

• Projektledelse, metoder og procedurer

• Kravspecifikationen får en anden betydning end i vandfaldsprojekter

• Konkret funktionalitet fastlægges undervejs i projektet


ITERATIVE PROJEKTER OG

UDBUDSREGLERNE

Gennemsigtighedsprincippet og ligebehandlingsprincippet

Gennemsigtighedsprincippet

• Kontrakten skal give en klar og præcis beskrivelse af den opgave

leverandøren skal løse og ydelseskategorier beskrevet. Beskrivelsen af

funktionelle krav eller funktionsdygtighed skal være så præcis, at

tilbudsgiver kan identificere kontraktens genstand.

Ligebehandlingsprincippet

• Fortsat forbud mod at ”skræddersy” kravspecifikation og mod at anvende

diskriminerende standarder eller krav.


ITERATIVE PROJEKTER OG

UDBUDSREGLERNE

Gennemsigtighed kan bl.a. opnås ved at

• Kontrakten er med i udbudsmaterialet og den er udformet specifikt for et

agilt projektforløb

• Kravspecifikation og kontrakten giver et klart billede af den opgave, der skal

løses (men ikke af slutproduktet)

• Kundens business case indgår i kontrakten (kravspecifikationen)

• Leverandørens ydelser omkring projektledelse, ressourcestyring og

rådgivning beskrives i kontrakten (kravspecifikationen)

• Udbudsmaterialet angiver tydeligt kundens fastlagte rammer for økonomi,

tidsrammer, overholdelse af standarder, integrationer m.v.


ITERATIVE PROJEKTER OG

UDBUDSREGLERNE

Ligebehandling kan bl.a. opnås ved at

• Undgå bilateral dialog med tilbudsgiver omkring udbudsmaterialet

• Sikre gennemsigtighed og klarhed i forhold til evaluering


ITERATIVE PROJEKTER OG

UDBUDSREGLERNE

Evaluering


ITERATIVE PROJEKTER OG

UDBUDSREGLERNE

Evaluering


ITERATIVE PROJEKTER OG

UDBUDSREGLERNE

Evaluering


ITERATIVE PROJEKTER OG

UDBUDSREGLERNE

Ændring af projekt under udbudsreglerne


TAK FOR I DAG / SPØRGSMÅL (BUFFER)


KONTAKTOPLYSNINGER

Søren Wolder

E-mail: swk@dahhlaw.dk

Telefon: 88 91 92 45

More magazines by this user
Similar magazines