Artikkeltittel: "Hvordan håndtere endringsstyring i systemutvikling fra et juridisk perspektiv"

I systemutviklingsprosjekter skjer det ofte at brukerne endrer innholdet de tidligere har forklart etter hvert som arbeidet skrider frem. Derfor kan det som leverandør også bli nødvendig å gå med på endringer i kontrakten som allerede er inngått.

I denne artikkelen forklarer vi fra et juridisk perspektiv hvordan man bør håndtere fenomenet “endringer” som oppstår etter at systemutviklingsprosjekter, som sjelden går som planlagt, er påbegynt.

Hvorfor systemutviklingsprosjekter ofte endres i etterkant

Systemutvikling er et samarbeid mellom leverandør og bruker

Systemutvikling følger vanligvis en prosess der man går gjennom planleggings- og forslagstadiet, definerer utviklingskravene, og inngår en kontrakt. Etter kontraktsinngåelsen følger man en rekke designfaser, implementerer i henhold til designet, og avslutter med testing. I hele denne prosessen har leverandøren, som systemutviklingsekspert, omfattende forpliktelser, men brukeren har også en viss samarbeidsplikt. Brukerens samarbeid er spesielt viktig i faser som kravdefinisjon (å identifisere nødvendige funksjoner), grunnleggende design (utseende og brukeropplevelse), og testing eller akseptansetest (å bekrefte at systemet oppfyller kravene). For en generell forklaring på brukerens forpliktelser i systemutvikling, se følgende artikkel.

Selv med samarbeidsplikt, krever brukere ofte endringer

Men selv om brukeren ikke er en systemutviklingsekspert, kan man ikke alltid forvente at de alltid har en plan og gir leverandøren all nødvendig informasjon uten mangler. I virkeligheten, på grunn av den detaljerte og presise naturen av arbeidet, kan brukeren ofte ikke forutse hvilke fakta som vil være avgjørende i senere faser. Ironisk nok kan viktige fakta derfor komme frem i små porsjoner etter hvert. På grunn av disse omstendighetene, selv om det ideelle er en “gjennomgående prosess fra start til slutt”, er det viktig å håndtere endringer som kan oppstå i etterkant. Dette gjør endringsstyring til en kritisk faktor i reelle prosjekter.

Hva er et endringsstyringsdokument?

Når endringsstyringsdokumenter brukes

Et endringsstyringsdokument er et dokument som brukes når en bruker ber en leverandør om å endre spesifikasjoner eller legge til funksjoner fra det som opprinnelig ble forklart. Som nevnt tidligere, har brukeren en plikt til å samarbeide med leverandørens arbeid i faser som kravdefinisjon og grunnleggende design, men det kan faktisk oppstå situasjoner hvor brukeren kommer med nye krav i senere faser.

Eksempler på situasjoner hvor et endringsstyringsdokument kan være nødvendig inkluderer:

• Når det er mangler i kravdefinisjonen eller grunnleggende design, og brukeren ber om å legge til funksjoner i etterkant
• Når det er behov for å endre spesifikasjoner på grunn av en revisjon av forretningsstrategien under utviklingen

Relatert til temaet om å legge til funksjoner eller endre spesifikasjoner, er det viktigste for den som utfører arbeidet å vite om loven tillater endringer i estimatbeløpet. Dette punktet er forklart i detalj i en annen artikkel.

Ved å øke estimatet i etterkant, er endringsstyringsdokumentet grunnlaget for å vurdere rimeligheten av det nye estimatet. For å unngå konflikter med motparten når man fakturerer basert på det økte estimatet (og for å styrke sin egen posisjon i tilfelle en konflikt), er det viktig å utarbeide et endringsstyringsdokument.

Endringsstyringsdokumentets innhold

Hva bør et endringsstyringsdokument inneholde i henhold til loven? Bruken av endringsstyringsdokumenter for å håndtere spesifikasjonsendringer og funksjonsutvidelser er allerede allment kjent. Derfor kan man få en god forståelse av hvilke elementer som bør dokumenteres ved å se på malene for kontraktsvilkår som er utarbeidet av japanske myndigheter, som for eksempel den japanske økonomi-, handels- og industrimodellen.

（Endringsstyringsprosess）
Artikkel 37: Hvis part A eller part B mottar et endringsforslag i henhold til artikkel 34 (endring av systemspesifikasjoner), artikkel 35 (brukergodkjenning av mellomliggende dokumenter) eller artikkel 36 (håndtering av uavklarte saker), skal de innen X dager fra mottaksdatoen utarbeide et dokument (heretter kalt “endringsstyringsdokument”) som inneholder følgende punkter og overlevere det til motparten. Part A og part B skal deretter diskutere endringens gjennomførbarhet i henhold til artikkel 12 i den avtalte kommunikasjonskomiteen.
① Endringens navn
② Forslagsansvarlig
③ Dato
④ Årsak til endringen
⑤ Detaljer om endringen, inkludert spesifikasjoner
⑥ Kostnader knyttet til endringen, hvis aktuelt
⑦ Tidsplan for endringsarbeidet, inkludert vurderingsperiode
⑧ Andre påvirkninger endringen kan ha på hovedkontrakten og individuelle kontraktsvilkår (arbeidsperiode, leveringsdato, honorar, kontraktsvilkår, etc.)

Ved å lese lovteksten direkte og bekrefte de anbefalte elementene, er ytterligere forklaring unødvendig. For å unngå fremtidige tvister om hva som ble sagt eller ikke sagt, bør endringshistorikken dokumenteres detaljert og spesifikt.

Ved å tydelig spesifisere disse elementene og inkludere signaturer eller stempler fra både leverandørens og brukerens ansvarlige og godkjennende parter, vil dokumentet ha samme bevisverdi som en kontrakt i tilfelle en rettssak.

Hva du bør vite om endringsstyring

Endringsstyring bør vanligvis utføres sammen med oppgavestyring

Å utarbeide et endringsstyringsdokument har som formål å administrere endringshistorikken for å lede prosjektet til suksess (eller for å unngå uberettiget ansvar hvis det ikke lykkes). For å oppnå dette formålet, utføres utarbeidelsen av endringsstyringsdokumentet ofte sammen med opprettelse og oppdatering av oppgavelisten. Med andre ord, når endringshistorikken administreres i endringsstyringstabellen, blir de avtalte endringspunktene inkludert som elementer i oppgavelisten som fremtidige oppgaver.

Det er bedre å også fastsette regler for endringsforhandlinger

Det er ikke bare viktig å fastsette metoder for endringsstyring, men også å etablere regler for hvordan endringsforhandlinger skal gjennomføres. Dette kan bidra til en smidig håndtering av endringer. Dette er spesielt viktig når man benytter utviklingsmetoder som Agile, hvor mange endringer forventes etter hvert. I praksis er det mange eksempler på at det er fastsatt regler for når motparten skal delta i forhandlinger om endringer.

Endringsforhandlinger og plikten til å handle i god tro

Når begge parter har blitt enige om en kontrakt og deretter ønsker å endre den, er det som å inngå en ny kontrakt. Siden kontrakter er basert på partenes frie vilje, er det i prinsippet ingen plikt for leverandøren til å gå med på endringskontrakten. Men hvis denne retten blir for sterkt vektlagt, kan det skape bekymringer for at systemutviklingsprosjekter ikke vil gå smidig.

Derfor er det i praksis ofte spesifisert i kontrakter at det er en “plikt til å handle i god tro i endringsforhandlinger”. Hvis leverandøren ikke handler i god tro, kan det være mulig å kreve erstatning. Et eksempel på en slik klausul kan være som følger (utdrag fra den offisielle “ff Basic/Individual Contract Model Basic Contract Draft” utarbeidet av den japanske Information-technology Promotion Agency):

Artikkel 4, paragraf 3: I endringsforhandlinger skal begge parter i god tro diskutere endringsobjektet, muligheten for endring, og påvirkningen på pris og leveringstid, og avgjøre om endringen skal gjennomføres.

Regler for endringsmetoder

Som nevnt tidligere, er det juridisk “tryggere” å holde forhandlinger om hver endring. Men i små prosjekter kan det være tilfeller hvor man ikke spesifiserer hvordan forhandlinger skal gjennomføres. I slike tilfeller kan man vurdere å gjøre endringer gyldige ved å få signaturer og stempler fra ansvarlige personer hos både brukeren og leverandøren på endringsstyringsdokumentet, uten å holde forhandlinger. Hvis man kun baserer seg på muntlige avtaler, kan det bli uklart om endringer er gjort, noe som kan føre til store problemer senere. Derfor bør dokumentstyring være grundig.

Imidlertid kan det være tilfeller hvor det er for tungvint å utarbeide separate dokumenter for hver endring, og man ønsker å prioritere fleksibel håndtering. I slike tilfeller kan man dokumentere endringer i møtereferater. For mer informasjon om hvordan man fører møtereferater i systemutvikling, se følgende artikkel.

Oppsummering

På arbeidsplasser hvor spesifikasjoner ofte endres, er det sant at risikoen for problemer og konflikter kan være høy. Men på slike steder hvor fleksibilitet er nødvendig, kan det være vanskelig å implementere praktiske tiltak hvis man bare strengt understreker “viktigheten av styring”.

Problemet med hvordan man skal balansere forretningshastighet med beredskap for uforutsette hendelser varierer ofte avhengig av selskapets situasjon og prosjektets innhold. Selv om man tar hensyn til innholdet i denne artikkelen, er det viktig å ha en holdning hvor man søker etter passende metoder for hvert selskap og prosjekt.