Gode råd for bedre IT-prosjekter ØK-IT
Gode råd for bedre IT-prosjekter ØK-IT Konferansen 2015 Grete F. Stillum Advokat og partner i Brækhus Dege Advokatfirma www.bd.no Aktualitet – mål • Mange IT-prosjekter får store kostnadsoverskridelser og forsinkelser. Dårlige ressursutnyttelse for både kunder og leverandører. Store muligheter for forbedring. • Min bakgrunn: Jurist i 1994 og «IT-advokat» fra 1997 Både kunde- og leverandørsiden, små og store prosjekter, i alle faser fra avtaleinngåelse, prosjektoppfølging, krisestadiet med reforhandling, samt krav om heving og erstatning • Mål: • Flere bedre IT-prosjekter! • Hovedfokus på implementering av standardsystemer, men relevans utover det. 2 Elementene i en vanlig IT-leveranse • Standard programvare (lisens/bruksrett/disposisjonsrett) • Maskinvare, ev. krav til maskinvare eller infrastruktur • Tjenester (implementering): • Konfigurering: Innstillinger og oppsett • Tilpasninger/modifikasjoner (bransje- eller kundebasert) • Integrasjoner/grensesnitt med andre systemer • Konvertering/datamigrering • Testing og godkjenning • Opplæring • Idriftsettelse/oppstart • Garanti med rettelser • Vedlikehold/drift med rettelser og oppdateringer, og ev. andre tjenester 3 Hva karakteriserer tjenesteelementet? • • • • • • • • • • • Langvarig tett samarbeid i prosjektperioden og driftsfasen Mennesker som skal jobbe med andre mennesker Store eksterne og interne kostnader Behov for forventningsavklaringer, innledningsvis og underveis Kundens behov og ønsker oppstår/klargjøres sent og det blir fristende å undervurdere konsekvenser av endrede krav Høy grad av personavhengighet Behov for prosjektoppfølging Store krav til kundens prosjektdeltakerne - kunnskap, formidle og foredle/forankre Leverandøren får en monopollignende posisjon Behov for samtidige organisasjonsendringer - ny måte å jobbe på Behov for å prioritere: Tid - Kost - Kvalitet / omfang 4 Tilfredshetskurven i IT-prosjekter - Grønn: Kundens tro og leverandørens håp? - Gul: Et vanlig prosjekt - Rød: Et ikke uvanlig prosjekt Tilfredshet Kontraktpunkt, Godkjennelse og Drift Tid 5 Kontraktsregulering - lov og avtaler Lov: • Ingen særlig lov eller forskrift om IT-avtaler/prosjekter… • Ulovfestet kontraktsrett som er vanskelig tilgjengelig, og som normalt kan fravikes ved avtale Avtaler som normalt inngås ved en IT- leveranse: • Kjøps-/prosjektavtale • Lisens-/bruksrettavtale • Vedlikeholdsavtale og brukerstøtteavtale • Driftsavtale • Databehandleravtale • Skytjenester: Tjenesteavtale og databehandleravtale, ev. også prosjektavtale for implementeringsstøtte 6 Kontraktsarbeidet: Hva bør vi gjøre? • Sett av tid! • Velg korrekt kontraktstype og mal • Tre «grupper» standardkontraktsleverandører: Difi (SSA-avtalene) - IKT Norge – Dataforeningen • Dekker mye av de samme, men også forskjellige leveransetyper • Balansen og ansvar/risiko er noe ulikt fordelt • Difi (SSA-avtalene) er revidert pr. juli 2015 etter leverandørdialog • Malenes innhold: • Generell avtaletekst som på et overordnet nivå angir avtalens omfang, gjennomføring av leveransene og partenes plikter, samt sanksjoner. • Bilag med noe forslag til tekst og innholdselementer. 7 Hovedkontraktstypene (I) • Kjøp/tilpasning: Leveranser som kan inneholde standard programvare og utstyr, samt tilpasninger og/eller noe spesialutvikling av programvare, samt tjenester som konfigurering, oppsett, konvertering og opplæring. Benyttes til anskaffelse og implementering av IT-systemer. Eks: SSA-T (ikke lenger SSA-K for tjenester), IKT Norge Kjøp. • Konsulentoppdrag: Konsulenten får et selvstendig ansvar for å levere et ferdig produkt, definert av kunden, til avtalt tid og pris. Kan brukes til større og mindre IT-prosjekter. • Konsulentbistand: Kjøp av konsulenttimer under ledelse av kunden. Konsulentens ansvar er, innenfor avtalt tid og pris, begrenset til å yte faglig bistand i aktiviteter styrt av kunden. 8 Hovedkontraktstypene (II) • Systemutvikling m/ulike prosjektmetodikk: Prosjekter for utvikling av programvare med varierende grad av ansvar, styring og overvåking. • Vedlikehold: Regulerer feilretting, brukerstøtte, forebyggende vedlikehold, programoppdateringer. Kan gjelde både standard og spesialutviklet programmer. • Drift: Levering av driftstjenester over flere år. • ASP/Sky (SaaS): Levering av funksjonaliteten i programvare som løpende tjeneste fra leverandørens driftssted/over internett. 9 Kontraktsskriving • Med utgangspunkt i korrekt valgte kontraktsmal … • Jobb med bilagene! Innhold i enkeltbilag og sammenhengen mellom bilagene. Ikke skriv noe flere steder, men henvis ved behov. • Ensartet bruk av begreper - ikke tilbudsspråk - bruk av definisjoner • Eks: Løsningen, Leverandøren / Kunde (ikke «vi») • Prosjektmetodikk- og styringsmekanismen: Hvordan skal veien være fra start til mål? • Sammenhengen mellom kundens behov og krav til løsningen, og det leverandøren skal levere (konfigurering, utvikling mv), tester og godkjenning, samt garanti • Hvordan kunden skal bidra, samhandling/samarbeid • Hvem bør skrive? Involvering av prosjektledere • Uklarheter gir fare for konflikter og tillegg (tid og kostand) 10 Kundens kravspesifikasjon • Kundens behov og krav må presenteres • • • • • • • • • Overordnet: Bakgrunn, mål og føringer Funksjoner - snarere enn program eller komponenter Husk også funksjoner som fungerer i dagens løsning Brukerhistorier som beskriver en eller flere prosesser løsningen bør dekke Brukeropplevelse: Hvem er brukerne og hva «krever» de, responsivt design. Tilgjengelighet (oppetid og responstid) Lov-/myndighetskrav til løsningen og arbeidsprosessene Sikkerhet Personvern • Beskrivelse av teknisk plattform og systemlandskap m/grensesnitt 11 Leverandørens løsningsspesifikasjon • Primært et svar på kundens krav/behov: • Svar pr. krav/behov: Dekkes i standard - Dekkes ved tilpasning - Dekkes ikke - Dekkes delvis/uklart – Kommentar/forbehold • Besvarelse av Brukerhistorier: Beskrivelse av hvordan løsningen vil dekke prosessene • Opplisting av programvare og moduler • Angivelse av maskinvare, ev. krav til maskinvare, og krav til infrastruktur og andre forutsetninger • Ta bort «tilbudsspråk» 12 Rettigheter • Hvilke rettigheter har partene behov for? • Bruksrettigheter: • Hvem? Regnskapsfører? Andre samarbeidspartnere? • Hvordan begrenses bruken? Antall navngitte personer, attestanter, antall A-meldinger? Opp-/ og nedjustering • Lisensvilkår: Tungt tilgjengelige lisensvilkår. Del av avtalen, motstrid/forrang? • Andre rettigheter: • Opphavsrett vs begrensninger i salg til andre? • Rett til å gjøre endringer og videreutvikling? Feilretting? Praktisk mulig (kildekode)? • Escrow • Referanse 13 Rev. spesifikasjon etter fase 1 og kontraktsrevisjon? • Fruktbart med revidert spesifikasjon med rettighetsavklaring etter en innledende fase • Aktiviteter i den innledende fasen • Kunden utdyper, klargjør og konkretiserer sitt behov og sine krav • Leverandøren viser muligheter, forklarer og stiller spørsmål • Dokumentasjon • Omfang og detaljnivå • Funksjon/virkning av at noe er glemt/feil • Det eneste som skal være grunnlag for test, godkjenning og garanti innenfor avtalt kalendertid og kostnad? • Tidspunkt for kontraktsrevisjon ut fra avtalte kriterier? • Endringer av «scope» og lisenser/rettigheter, gir ofte behov for endringer av estimater/pris og fremdrift. Ev. uthopp? 14 Prosjektaktiviteter Beskriv følgende med konkrete oppgaver, mål og beslutninger, samt estimat for leverandørens og kundens ressursinnsats! • Analyse og design av løsningen • Installering av programvare, database, test- og driftsmiljø, malklient mv • Prosjektstyring med planverktøy • Detaljering av løsningen med – – – – • • • • • Konfigurering/parametersetting Utarbeidelse/utvikling av rapporter og spørrefunksjoner Utvikling av integrasjoner/grensesnitt Utvikling av modifikasjoner/tilpasninger Konvertering/migrering Test Opplæring av prosjektdeltakere og ev. sluttbrukere Dokumentasjon av løsning og driftsrutiner Bistand under oppstart 15 Hvordan skal partene jobbe i prosjektet? (I) • Arbeidsmetodikk • Leverandørens arbeidsmetodikk anbefales normalt, ev. nedskalert (Forutsatt at Leverandørens prosjektdeltakere kan den) • Krever at Kunden forstår den og at den passer kontrakten, og forklares i kontrakten m/klargjøring av sammenhengen med kontraktens faser/tester • Hvordan dokumentere? Språk? • Rutiner for referat • Varslingsplikt dersom forventninger ikke innfris • Fossefall vs. Smidig utvikling... • Fossefall («klassisk»): «Alt» spesifiseres før utviklingen starter og partene har ikke kontakt før godkjenning • Smidig/agile («nyere» f.eks Scrum): Kunden har en funksjonsliste (produktkø) som løpende prioriteres og utvikles i korte iterasjoner (sprint) og demonstreres før neste velges. Endringer/forbedringer legges i produktkøen. 16 • Bevissthet og klarhet gir det beste! Hvordan skal partene jobbe i prosjektet? (II) • Prosjektorganisasjon – styringsmodell • Rollebeskrivelser med mandat (oppgaver og fullmakt) • Kunden speiler leverandørens roller • Styringsgruppe for overordnet styring og konfliktløsning • Ikke detaljstyring • Bør være andre personer • Nøkkelressurser: Navngis, bytterett? • Også kundens nøkkelressurser bør kontraktsfestes • Opplæring av superbrukere og sluttbrukere Innføring av ny måte å jobbe på hos kunden – involvering av leverandøren, del av kontrakten?? 17 Fremdriftsplan • • • • • • Estimert tjenesteomfang planlegges til kalendertid Overordnet med «faste» sentrale kontraktspunkter (milepæler) Detaljert plan knyttet til aktiviteter og ressurser som «lever» Oppstart i en eller flere faser (funksjonelt eller lokasjoner) Bør det planlegges med «dø-perioder»? Hva bør skjer dersom et tidspunkt ikke nås? • Milepæler vs andre tidspunkter • Forskyvning vs forsinkelse med sanksjon (dagbot, ev. heving) • Dokumentasjon • Kontraktens faseoppdeling m/milepæler vs leverandørens metodikk 18 Endringshåndtering • Det vil komme kontraktsendringer… Så avtal en prosess og følg den! Og kanskje passer en annen prosess bedre enn valgte avtalemal? • Hva kan være en kontraktsendring? • Hva gjelder hvis ikke avtalt endringsordreprosess er fulgt? • Punkter som bør vurderes i en endringsordreprosess: • Endringsanmodning (EA) - utredning og tilbud - undertegnet Endringsordre (EO) • Hvem kan signere, rammer? Frist? • Samme prosess uansett hva og hvem som ønsker endring? • Krever EO enighet? Begrensinger for hva leverandøren må akseptere av endringer? • Omtvistede endringsordre («scope» eller prisdiskusjon) – hoppeplikt? 19 Endringsordre (EO) – innhold • • • • Ofte «for tynt», «for sent», ikke signet, feilnummeret og ikke «arkivert» Hva endringen består i Omfang/tidsforbruk for alle roller (ikke bare utviklingstid) Virkning på kontraktsprisen, inkl. prismodell (justering av målprisgrunnlaget eller T&M) • Krav til kunden i form av nye tekniske krav eller medvirkning • Konsekvensvurdering/avhengigheter: fremdriftsplan, testplaner, lisens/vedlikeholdskostnad (inkl. økt grunnlag), annet? • Endringer som berører tid: • Re-planleging av når alle ressursene skal bidra, husk kunden og tredjepartsleverandører • Konsekvenser for dagbot (og andre forsinkelsessanksjoner) • Sammenhengen med kontrakten og andre EOer 20 Test og godkjenning • Testgrunnlag: – Hva skal løsningen testes opp mot? Hvilke krav og beslutninger? Ansvar for feil i standardprogramvare? • Testregime og plan: – Hva skal testes av hvem, når og hvordan? Ansvar for testcaser – Krav til leverandørens tester og rapportering før kundens test? – Konsekvenser av aksepterte tester? Nye feil? • Melde- og feilrettingsrutiner: Hvor og hvordan skal feil meldes og følges opp med klargjøring og retesting, inkl. dokumentasjon • Testkriterier: Inngangs-/utgangskriterier for test(ene), antall og feilkategorier • Rettetider i testfasene, og konsekvenser ved fortsatt feil • Godkjenningsdag: Ofte dagbotsanksjonert og betalingsmilepæl 21 Overlevering drift, garanti og vedlikehold • IT-systemer er ikke feilfrie. Feil kan forekomme uten at det medfører at det foreligger et kontraktsmislighold. • Garantinnhold: Retting av nye feil etter godkjenningsdag, ev. nyrapporterte feil. Frister? • Prismodell: Inkludert i prosjektvederlaget/forhåndsbetalt, løpende timer/målpris • Varighet av garantiforpliktelsen • Sammenheng med vedlikeholdsavtale • Oppdateringer og videre samarbeid 22 Valg av prismodell • Hovedtyper: Løpende timer (T&M) - fastpris - målpris - enhetspriser • Målpris: Leverandøren estimerer sannsynlig tidsforbruk og kunden betaler iht. medgått tid, men til en (ev. økende) rabatert timepris dersom estimatene overskrides. Ev. påslag dersom prosjektet leverer under estimat. • Kombinasjon av prismodeller. Ulike faser og oppgaver. Hva vil man oppnå? Viktig å avklare hva som er hva, inkl. endringer. • Eks på målprismodell: Forutsetning Ved leveranse der forbrukt volum er redusert med mer enn 10 % av estimert volum Ved leveranse der forbrukt volum er redusert med mellom 0-10 % av estimert volum Tjenester opp til 110 % av det totale estimat Godtgjørelse Gevinsten av redusert leveranse deles 50/50 mellom partene Gevinsten av redusert leveranse går til Kunden Overskridelse på mellom 10-25 % av det totale tjenestevolum Overskridelse på mellom 25-50 % av det totale tjenestevolum Overskridelse på over 50 % av det totale tjenestevolum Godtgjøres med fratrekk av 30 % 23 Godtgjøres etter de oppgitte timepriser Godtgjøres med fratrekk av 50 % Godtgjøres med fratrekk av 75% Fakturering og forfall • Lag en samlet oversikt over de ulike elementene i leveransen og tjenestene, ev. også oppdelt pr. fase • Mulig å rapportere på • Også kostander etter GD/Garanti? Levetidskostanden • Flere modeller • Løpende (etterskuddsvis), ev. med tilbakeholdt del • Betaling oppdelt etter fremdrift/milepæler • Detaljeringsgrad – oversikt og detaljer • Lisens: • Forfallstidspunkt? • Hva skjer ved terminering av prosjektet? 24 Sanksjoner - Krav ved kontraktsbrudd • Avhjelp/retting: «Gjøre om igjen» • Dagbot: Kompensasjon for forsinkelse for angitt€ milepæl(er). Prosentsats av kontraktssummen i et definert antall dager. • Prisavslag: Kompensasjon for en mangel • Erstatning: Krav om (dokumentert) tap. Direkte / indirekte tap? Ansvarsbegrensning. • Heving: • Krav om vesentlig kontraktsbrudd. Ofte først etter dagbotperioden. • Helt eller delvis heving: • Deler av leveransen/løsningen • For det leverte eller for fremtidige ytelser • Særlig problemstilling vedr. standard programvare • Bruk av sanksjoner krever reklamasjon – ofte formelle krav 25 Prosjektoppfølging • Mye å hente! • Kontrakten et viktig prosjektverktøy • Rapportering og avsjekk av oppgaver for å unngå misforståelser, ha kontroll og styring: • På flere nivåer og former – bruk av maler • Prosjektøkonomi med status forbrukte timer vs estimater og gjenstående omfang - oppdelt pr. tjeneste/element • Fremdrift – milepælsplan/detaljert plan og metodikkens faser • Samarbeidsklima: overordnet og pr område • Beslutninger for løsningen og annet - grensen mot endringer • Risikovurderinger av definerte elementer: Grønt, gult og rødt • Møter og samtaler – den menneskelige faktor • Prioriteringer av tid, kostnader og kvalitet, og ev. andre parametere • Prosjektleders rolle 26 «Et hvert IT-prosjekt bør ha en prest, en psykolog og en stand-up komiker» 27 Håndtering av faresignaler • Fang opp faresignaler tidlig, før de er virkelige «farer» • Håndtering av mindre endringer på prosjektledernivå (dersom kontrakten åpner for det eller ved utvidede fullmakter) • Involvering av styringsgruppen som ressurs til å styre • Reklamasjon? Behov - formen - oppfølging • Snakk sammen – ikke bare brev/eposter • Eksempler på faresignaler: • Lav terskel for krav om endringsordre/tilleggsbetaling og nedprioritering av endringsønsker • Diskusjon om hvem som ikke har gjort det de skal , hvem som har uttrykt seg uklart, ev. burde gjort noe eller gitt flere opplysninger • Stans i betaling – varsel om dagbøter og ev. erstatningsansvar 28 Andre virkemidler enn sanksjonskrav • • • • • • • • • • • • • Vær åpen for at alt ikke er «svart/hvit», og at det kan finnes bedre alternativer enn «sanksjonsveien» Prosess for å avklare og finne løsninger på «scopediskusjoner» og «fremdriftsutfordringer» underveis uten at prosjektet påvirkes negativt Bytte av ressurser, styrking av noen roller (Del)avbestilling/midlertidig stans Oppdeling av prosjektet Bruk / endring av prismodell mv: Målpris eller bonus Økt dagbot og/eller økt mulighet for heving senere Se kostnader i prosjektfasen sammen med levetidskostanden Tillegg/flere oppdrag for kunden Garantier fra morselskap/eiere Tilgang til kildekoden Bytte/støtte av ny implementeringspartner Det som vil gi ny giv til prosjektet og måloppnåelse! 29 Spørsmål / innspill Takk for meg! Kontaktdetaljer: Grete F. Stillum - Brækhus Dege Advokatfirma DA Web: www.bd.no Epost: [email protected] Mobil: 990 90 710 30 Lovvalg og tvisteløsning • Norsk rett, ofte mulig å få til • Tvisteløsningsorgan (hvor en tvist skal avgjøres og domstoltype) – I EU/EØS: Alminnelige domstoler OK – Utenfor: Ofte behov for voldgift for at en dom skal kunne håndheves Oslo: Sandvika: Ski: Dronning Maudsgt. 10, 0250 Oslo Tel. +47 23 23 90 90 Rådmann Halmrasts vei 7, 1300 Sandvika 31 Tel. +47 67 21 69 00 Jernbaneveien 4, 1400 Ski Tel. +47 64 91 41 41
© Copyright 2024