Hvordan man håndterer ændringsstyring i systemudvikling fra et juridisk perspektiv

I systemudviklingsprojekter sker det ofte, at brugeren ændrer det indhold, de har forklaret på forhånd, i løbet af arbejdsprocessen. Derfor kan det som leverandør, der modtager arbejdet, være nødvendigt at imødekomme ændringer i kontraktindholdet, selv efter at kontrakten er indgået.

I denne artikel forklarer vi, fra et juridisk perspektiv, hvordan man skal håndtere fænomenet “ændringer”, der foretages efterfølgende, i forhold til systemudviklingsprojekter, der ikke altid forløber som forventet.

Hvorfor bliver systemudviklingsprojekter ‘ændret’ efterfølgende?

Systemudvikling er et samarbejde mellem leverandør og bruger

Generelt går systemudvikling gennem en planlægnings- og forslagsfase, hvor udviklingskravene defineres, og en kontrakt indgås. Efter kontrakten er indgået, følger en proces med forskellige designfaser, implementering i henhold til designet, og til sidst testning. I hele denne proces har leverandøren, som er ekspert i systemudvikling, naturligvis en bred vifte af forpligtelser, men brugeren har også en vis forpligtelse til at samarbejde. I processer som identifikation af de funktioner, systemet skal have (dvs. kravdefinition), udseendet og brugeroplevelsen af skærmen (dvs. grundlæggende design), og bekræftelse af, om kravene er opfyldt (dvs. test eller accept), er brugerens samarbejde særligt vigtigt. For en generel forklaring på de forpligtelser, brugeren har i systemudvikling, se følgende artikel.

https://monolith.law/corporate/user-obligatory-cooporation[ja]

Brugere har en forpligtelse til at samarbejde, men de har en tendens til at anmode om ændringer

Men det er ikke altid, at brugere, der ikke er eksperter i systemudvikling, kan formidle alle de nødvendige oplysninger til leverandøren på en omfattende og fuldstændig måde. I virkeligheden er det ofte svært for brugerne at forudsige, hvilke fakta der kan have afgørende betydning i senere faser, netop fordi det er en detaljeret og præcis opgave. Ironisk nok kan det betyde, at de vigtigste fakta ofte kommer frem i små bidder senere. På grund af disse omstændigheder er det i virkelige projekter vigtigt at overveje, hvordan man håndterer ‘ændringsstyring’, selvom det ideelle ville være en ‘gennemgående proces fra opstrøms til nedstrøms faser’, under antagelse af, at forskellige ændringer kan forekomme efterfølgende.

Hvad er en ændringsstyringsdokument?

Hvornår bruges ændringsstyringsdokumenter?

Et ændringsstyringsdokument er et dokument, der bruges, når en bruger anmoder en leverandør om at ændre specifikationer eller tilføje funktioner, der afviger fra det, der oprindeligt blev forklaret. Som nævnt tidligere, har brugeren en forpligtelse til at samarbejde med leverandørens arbejde i faser som kravdefinition og grundlæggende design, men det er muligt, at forskellige ønsker kan opstå i senere faser.

Eksempler på situationer, hvor et ændringsstyringsdokument kan være nødvendigt, inkluderer:

• Når der er overset noget i kravdefinitionen eller det grundlæggende design, og der anmodes om at tilføje en funktion efterfølgende.
• Når der er behov for specifikationsændringer på grund af en revision af virksomhedens politik midt i udviklingen.

Disse er blot nogle eksempler.

Med hensyn til emner som tilføjelse af funktioner og ændring af specifikationer, er det, der mest bekymrer dem, der modtager arbejdet, om det er juridisk tilladt at ændre det estimerede beløb. Vi har en separat artikel, der forklarer dette i detaljer.

https://monolith.law/corporate/increase-of-estimate[ja]

Ændringsstyringsdokumentet er grundlaget for at vurdere rimeligheden af indholdet, når du øger estimatet efterfølgende. For at undgå konflikter med den anden part, når du fakturerer baseret på det øgede estimat (og for at give din argumentation overbevisende kraft, hvis der opstår en konflikt), er det vigtigt at oprette et ændringsstyringsdokument.

Hvad skal inkluderes i et ændringsstyringsdokument?

Så hvad skal juridisk set inkluderes i et ændringsstyringsdokument? Kontraktsmekanismen, der bruger ændringsstyringsdokumenter til at imødekomme ændringer i specifikationer og tilføjelse af funktioner, er allerede almindeligt anerkendt. Derfor kan du generelt forstå, hvad der skal registreres ved at kontrollere skabeloner for kontraktbestemmelser, som regeringsagenturer som det japanske ministerium for økonomi, handel og industri viser.

(Ændringsstyringsprocedure)
Artikel 37 Hvis A eller B modtager et ændringsforslag baseret på artikel 34 (ændring af systemspecifikationsdokumenter osv.), artikel 35 (godkendelse af midlertidige dokumenter af brugeren), artikel 36 (håndtering af ubestemte sager), skal de inden for ○ dage fra modtagelsesdatoen give den anden part et skriftligt dokument (herefter kaldet “ændringsstyringsdokument”.) med følgende oplysninger noteret, og A og B skal diskutere godkendelsen af den pågældende ændring i kommunikationsrådet defineret i artikel 12.
① Navnet på ændringen
② Den person, der er ansvarlig for forslaget
③ Dato
④ Grunden til ændringen
⑤ Detaljer om ændringen, inklusive specifikationer relateret til ændringen
⑥ Hvis der er omkostninger forbundet med ændringen, beløbet
⑦ Tidsplanen for ændringsarbejdet, inklusive overvejelsesperioden
⑧ Andre effekter, som ændringen har på vilkårene for denne kontrakt og individuelle kontrakter (arbejdsperiode eller leveringsdato, kontraktgebyr, kontraktbestemmelser osv.)

Hvis du læser teksten direkte og bekræfter de anbefalede poster, er yderligere forklaring unødvendig. For at undgå “sagde-ikke-sagde” problemer senere, skal du registrere detaljerne og den specifikke proces for ændringen.

Ved at angive disse oplysninger og kombinere dem med underskrifter eller segl fra ansvarlige og beslutningstagere fra både leverandøren og brugeren, vil det have samme betydning som en kontrakt som bevis, selvom der skulle opstå en retssag.

Det er godt at vide om ændringsstyring

Ændringsstyring bør generelt udføres sammen med opgaveadministration

Formålet med at oprette en ændringsstyringsdokument er at styre ændringshistorikken for at lede projektet til fuldførelse (eller for at undgå uretfærdig ansvarspådragelse, hvis det ikke lykkes). I praksis er oprettelsen af en ændringsstyringsdokument ofte udført sammen med oprettelse og opdatering af opgaveadministrationslisten. Det vil sige, når ændringshistorikken er styret i ændringsstyringstabellen, bliver de aftalte ændringspunkter indarbejdet i opgaveadministrationslisten som opgaver, der skal håndteres fremover.

Det er bedre også at fastsætte regler for, hvordan ændringsforhandlinger skal udføres

Ikke kun hvordan man håndterer ændringsstyring, men også hvordan man forhandler om ændringer, kan det forventes, at ændringshåndteringen vil gå glat, hvis man også fastsætter regler for det. Dette er især vigtigt, når man anvender udviklingsmetoder som agile udvikling, hvor forskellige ændringer forventes at blive foretaget efterfølgende. I praksis er der mange eksempler på, at regler er fastsat for, hvornår den anden part skal reagere på en anmodning om forhandling om ændringsstyring.

Ændringsforhandlinger og pligten til at handle i god tro

Når begge parter ændrer en kontrakt, de engang har indgået, er det i princippet det samme som at indgå en ny kontrakt. Da kontrakten er baseret på parternes fri vilje, er der i princippet ingen pligt for leverandøren til at acceptere ændringskontrakten. Men hvis denne rettighed overdrives, kan det være bekymrende, at systemudviklingsprojektet ikke vil gå glat i praksis.

Derfor er det ofte angivet i kontrakter, at der er en “pligt til at handle i god tro i forhandlinger om ændringer”, og der er eksempler på, at det er angivet, at det er muligt at anmode om erstatning for skader, hvis leverandøren ikke reagerer i god tro på ændringer.

Et eksempel på en sådan formulering er som følger (her er et eksempel på en klausul, citeret fra “ff Basic/Individual Contract Model Basic Contract Draft” officielt oprettet af den uafhængige administrative institution Information Processing Promotion Agency).

Artikel 4, afsnit 3 Ved forhandlinger om ændringer skal begge parter i god tro drøfte emnet for ændringen, om ændringen kan foretages, og virkningen af ændringen på prisen og leveringstiden.

Bestemmelser om ændringsmetoden

Som nævnt tidligere er det juridisk “sikkert” at afholde forhandlinger om hver ændring. Men i mindre projekter kan det være, at man ikke behøver at fastsætte regler for, hvordan man forhandler om ændringer. I sådanne tilfælde kan man overveje at lade ændringer ske først, når brugerens og leverandørens ansvarlige har underskrevet og stemplet ændringsstyringsdokumentet, i stedet for at fastsætte regler for forhandlinger. Hvis man tillader ændringer at ske let ved mundtlig aftale alene, kan det blive uklart, om ændringer er blevet foretaget, hvilket kan føre til store problemer senere. I denne forstand bør dokumentstyring være grundig.

Men det kan også være, at det er en byrde at skulle forberede separate dokumenter for hver ændringsstyring, og at man ønsker at prioritere en fleksibel respons. I sådanne tilfælde kan det være en mulighed at dokumentere ændringsrelaterede emner i mødereferater. Hvordan man holder mødereferater i systemudvikling er detaljeret forklaret i følgende artikel.

https://monolith.law/corporate/the-minutes-in-system-development[ja]

Opsummering

I miljøer, hvor specifikationsændringer forekommer hyppigt, er der bestemt en tendens til at være i tæt kontakt med risikoen for problemer og konflikter. Men selv i sådanne situationer, hvor fleksibilitet er nødvendig, kan det ofte være svært at implementere realistiske foranstaltninger ved blot at understrege “vigtigheden af styring” på en stiv måde.

Spørgsmålet om, hvordan man skal balancere den hastighed, der kræves i erhvervslivet, og forberedelsen på en eventuel situation, synes ofte at have forskellige optimale løsninger afhængigt af virksomhedens situation og projektets indhold. Selv med hensyntagen til indholdet af denne artikel, mener vi, at det er vigtigt at have en holdning til at søge den passende metode for hver virksomhed og hvert projekt.