Hvordan man holder mødereferater i systemudvikling fra et juridisk perspektiv

Når en virksomhed uddelegerer systemudvikling til en anden virksomhed, er det ofte tilfældet, at kontrakter underskrevet med virksomhedens segl af de respektive administrerende direktører og kravspecifikationer udarbejdet af projektledere ikke nødvendigvis klart definerer, hvad der skal laves og inden hvilken frist. Dette skyldes, at mange systemudviklingsprojekter involverer daglig kommunikation på medarbejderniveau via e-mail og telefon, møder ledet af projektledere, og løbende justeringer som specifikationer bliver præciseret, ændringer i respons til skiftende omstændigheder, anmodninger om yderligere funktioner, og anmodninger om samarbejde om opståede problemer.

For at sikre en gnidningsfri systemudvikling og forberede sig på eventuelle konflikter, er det vigtigt at håndtere dokumentation og dens styring effektivt i ethvert systemudviklingsprojekt.

I denne artikel vil vi forklare, fra et juridisk perspektiv, hvordan man bedst bevarer mødereferater og mødematerialer, der bruges i fremskridtsmøder for systemudvikling.

Hvorfor er dokumenthåndtering vigtig i systemudvikling?

I systemudviklingsprojekter er det meget vigtigt at holde en registrering af indholdet af bekræftelsesmøder og projektets fremskridt og forløb, også fra et juridisk synspunkt. Der er to hovedårsager til dette:

For at undgå konflikter senere

Systemudvikling er normalt et projekt, der involverer mange parter, både på brugersiden og på leverandørsiden. Derfor, hvis der er uoverensstemmelser mellem brugersiden og leverandørsiden om, hvilken rolle hver part skal spille, og hvad de skal påtage sig som deres ansvar, kan det forstyrre projektets fremdrift.

Desuden, da mange mennesker er involveret i projektet, kan det også betyde, at der er en høj risiko for kommunikationsproblemer, som “Folk siger lidt forskellige ting, og det er uklart, hvem der har ret”.

Det er meningsfuldt at samle indholdet af den dannede aftale i skriftlig form for at bekræfte, at der ikke er nogen uoverensstemmelser mellem parterne, og det er også nyttigt at samle det i et dokument, som alle involverede kan kontrollere (på deres egen tid), for at sikre, at alle er på samme side.

For øvrigt, at bruge juridisk viden som et middel til at forhindre konflikter på forhånd kan også kaldes forebyggende juridisk arbejde.

For at forberede sig på konflikter, der kan opstå senere

Desuden, hvis vi skal forklare vigtigheden af dokumenthåndtering fra et lidt andet synspunkt end det forebyggende juridiske arbejde nævnt ovenfor, kan vi også nævne “krisehåndtering” i tilfælde af faktiske konflikter.

Lad os forestille os en situation, hvor der opstår en form for problem, og projektet bliver afbrudt før det endelige produkt er færdigt, eller det ikke bliver færdigt til den oprindelige deadline, og det ender i retten. Dette gælder for både brugersiden og leverandørsiden, men selvom du vil sige, “Jeg har min egen side af historien om, hvad der skete”, hvis du ikke har dokumenteret det, vil du ikke være i stand til at bevise din sag, og du kan ende med at være i en ugunstig position i retten.

Især i problemer, der opstår på grund af “ikke at nå deadline”, kan årsagen til problemet, såsom “hvornår og hvordan blev problemet opdaget”, “hvornår blev der anmodet om specifikationsændringer”, og “hvordan forsøgte leverandøren at håndtere anmodninger om yderligere funktioner fra brugersiden”, ofte blive vigtige punkter, der kan påvirke udfaldet af retssagen. Hvis der opstår mange “han sagde, hun sagde” problemer i sådanne tilfælde, kan det blive svært at forvente en retfærdig løsning på konflikten.

Hvad er særligt vigtigt i referater fra systemudviklingsmøder?

Typer af møder i systemudvikling

I systemudviklingsprojekter er der ofte mange forskellige møder, der løbende bliver planlagt. Dette er ikke overraskende, da mange mennesker er involveret i sådanne projekter. Programmerere og ingeniører, der implementerer programmet på udviklingsstedet, holder ofte regelmæssige møder for at tjekke fremskridtene i deres arbejde. Der kan også være tilfælde, hvor de gennemgår den implementerede kode for at sikre, at der ikke er nogen problemer med vedligeholdelse eller sikkerhedssvagheder.

Udover disse møder på operatørniveau, kan der også være møder, hvor virksomhedens direktører og ansvarlige personer med autoritet samles. I disse tilfælde vil møderne ofte fokusere på at fastlægge den overordnede retning og politik for udviklingsprojektet. Disse møder på ledelsesniveau, der er designet til at “holde styr” på vigtige spørgsmål, kaldes også styringskomitéer.

Styringskomitéen kræver særlig opmærksomhed

Som nævnt ovenfor, er der mange forskellige møder planlagt i systemudviklingsmiljøet, afhængigt af de involverede personers position og formålet med mødet. Fra et juridisk synspunkt er det dog særligt vigtigt at være opmærksom på styringskomitéen. Sammenlignet med fremskridts- og gennemgangsmøder på operatørniveau, er det særligt vigtigt at anerkende betydningen af dokumentation i styringskomitéen, både for at forebygge forskellige konflikter og for at håndtere dem, når de opstår. Grunden til dette er:

1. På grund af styringskomitéens natur, hvor ledelsesniveauet er vært for mødet, er det ofte et møde, der involverer vigtige beslutninger. Det er derfor let at se det som juridisk vigtigt, da det viser, hvad brugerens og leverandørens forståelse er.
2. For møder på operatørniveau vil indholdet af mødet normalt blive afspejlet i forskellige design- og specifikationsdokumenter senere. Derfor er det svært at forestille sig, at der opstår et problem med “manglende dokumentation”. (Selvfølgelig, hvis dokumentationen for disse også er tynd, vil der være behov for forbedringer.)

Disse er nogle af de punkter, der kan nævnes.

Retskendelser relateret til referater fra styrekomitéer

Nedenfor vil vi introducere et tilfælde, hvor referater fra en styrekomité blev behandlet som vigtige beviser i en faktisk retssag. Den sag, der citeres i dommen nedenfor, handler om et systemudviklingsprojekt, der gik i stå midt i processen, og hvor leverandørens overtrædelse af projektledelsesforpligtelserne blev anerkendt. Indholdet af referatet fra dette møde, som viser begge parters oprindelige forståelse, havde meget stor betydning i retssagen.

Leverandøren har påpeget, at indholdet af referatet fra styrekomitéen, som er grundlaget for anerkendelsen af forløbet i dette systemudviklingsprojekt, er blevet ændret af brugeren og derfor ikke nødvendigvis afspejler den faktiske situation. Men, styrekomitéen blev oprettet med det formål at træffe beslutninger på ledelsesniveau i forbindelse med dette systemudviklingsprojekt, og både leverandøren og brugeren deltog, med projektlederne for systemudviklingen, for at foretage en samlet vurdering, dele status og udfordringer for tidsplanen og arbejdsfremdriften, og træffe beslutninger om vigtige spørgsmål. Og det var aftalt, at leverandøren skulle oprette et referat af de diskuterede punkter inden formiddagen to arbejdsdage efter mødet, registrere det i referatdatabasen, og bruge referatet til at dokumentere de endelige beslutninger fra mødet. Ved godkendelse af referatet, kan det antages, at både leverandøren og brugeren, mens de fuldt ud anerkendte betydningen af at dokumentere arbejdet gennem referatet, overvejede indholdet og formuleringen og bekræftede det som noget, der afspejlede virkeligheden af mødet. Især kan det siges, at leverandøren, som er en professionel systemudvikler, naturligvis var fuldt ud bekendt med betydningen og metoden til at oprette sådanne referater. Derfor kan det siges, at det er passende at behandle det godkendte referat som noget, der afspejler virkeligheden af styrekomitéens arbejde, og medmindre der er særlige omstændigheder, er det passende at anerkende, at indholdet, der er angivet deri, er det, der blev opsummeret i styrekomitéen på den pågældende dato.

Tokyo High Court, 26. september, Heisei 25 (2013)

Retten synes at tage den holdning, at hvis der er et skriftligt referat af et møde, der er oprettet med samtykke fra både leverandøren og brugeren, kan det forventes at have en vis formodende kraft som “bevis”. Set fra et andet perspektiv, bør man være meget forsigtig med dette, da en alt for letfærdig beskrivelse i referatet kan medføre risikoen for, at det bliver brugt som bevis som det er.

Hvad er de specifikke punkter, der skal noteres i mødereferater?

Mødereferater har stor betydning, både som bevis i tilfælde af retssager og for at fremme efterfølgende forhandlinger mellem parterne, selv uden retssager. Men hvad skal man specifikt dokumentere og gemme i mødereferater? Lad os organisere det nedenfor.

Elementer, der skal noteres fra leverandørens synspunkt

Leverandøren har en projektledelsesforpligtelse som en ekspert i systemudvikling over for projektet. Hvad denne forpligtelse præcist indebærer, er detaljeret forklaret i følgende artikel.

https://monolith.law/corporate/project-management-duties[ja]

Med denne forpligtelse i tankerne, er det især vigtigt for leverandøren at notere:

1. Fakta og datoer for afslutningen af hver udviklingsproces
2. Historikken for, hvordan de har svaret på anmodninger om ændringer i specifikationer og tilføjelser af funktioner fra brugersiden
3. De foranstaltninger, de har truffet for at anmode om samarbejde, når udviklingsarbejdet er forsinket på grund af brugerens egen bekvemmelighed, og historikken for dette

Disse er nogle af de ting, der kan nævnes.

For at tilføje til punkt 3 ovenfor, forklarer den følgende artikel, hvad leverandøren skal overveje, hvis brugeren ikke udfører accepttesten. I denne artikel forklarer vi, hvordan domstolens afgørelse kan ændre sig betydeligt afhængigt af, hvor samarbejdsvillig leverandøren har været i at hjælpe brugeren med at udføre accepttesten, ved at citere faktiske domsafgørelser.

https://monolith.law/corporate/estimated-inspection-of-system-development[ja]

Elementer, der skal noteres fra brugerens synspunkt

Naturligvis har brugeren også en vis samarbejdsforpligtelse over for leverandørens udviklingsarbejde, da det er et system, der skal bruges internt i virksomheden. Det samlede indhold af denne forpligtelse er forklaret i følgende artikel.

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

1. Historikken for, hvad brugeren har formidlet til leverandøren, såsom ønskede funktioner og udseendet af skærmsiden
2. Historikken for forskellige problemer, der er opstået i leverandørens proces (for eksempel, pludselig afgang af medlemmer eller forsinkelser i udviklingsprocessen på grund af utilstrækkelig undersøgelse fra leverandørens side, og årsagerne til dette)

Med hensyn til punkt 2 ovenfor, er det især tilbøjeligt til at udvikle sig til uforudsete problemer, når man udvikler et nyt system samtidig med at man fjerner det gamle system. Der er en tendens til, at problemer ofte opstår, når data fra det gamle system overføres til det nye system, men en detaljeret forklaring af juridiske problemer omkring sådanne problemer er givet i følgende artikel.

https://monolith.law/corporate/the-transition-from-the-oldsystem[ja]

Opsummering

Ovenstående er retningslinjer for, hvordan man holder mødereferater på systemudviklingssteder fra et juridisk synspunkt. Ud over praktiske “how-to’s” er det vigtigt at øge forståelsen for forbindelsen mellem temaer som “lov”, “systemudvikling” og “dokumenthåndtering”. Netop fordi systemudvikling involverer mange mennesker og organisationer og let kan udvikle sig til store kommercielle transaktioner, er det vigtigt at forebygge og håndtere konflikter, der opstår i forbindelse med det. Og fra et juridisk synspunkt på bevisbevaring, vil “dokumenter”, der kan bekræftes objektivt af alle, have stor betydning.

Det er sandt, at det kan være en stor byrde og måske ikke realistisk at sprogbehandle alle interaktioner og projektudviklinger fuldstændigt. Men det er vigtigt at identificere, hvad der er juridisk vigtigt, og at fremme dokumentation af vigtige sager efter behov. Dette punkt bør være bredt anerkendt af alle, der er involveret i erhvervslivet, uanset om de er juridiske eksperter eller ej.