Vad är sättet att behålla mötesprotokoll i systemutveckling från ett juridiskt perspektiv?

När ett företag anlitar ett annat företag för systemutveckling, är det ofta fallet att kontraktet, som undertecknas med företagsstämplar av VD:arna, och kravspecifikationen som skapats av projektledaren, inte alltid tydligt definierar vad som ska skapas och när det ska vara klart. Detta beror på att mycket av systemutvecklingen sker genom e-post och telefonsamtal på operativ nivå, möten ledda av projektledaren, och dagliga justeringar av specifikationer som ursprungligen var oklara, ändringar av specifikationer för att anpassa sig till förändrade omständigheter, förfrågningar om tillägg av funktioner, och begäran om samarbete kring uppkomna problem.

För att smidigt driva ett systemutvecklingsprojekt och förbereda sig för eventuella tvister, är det viktigt att skapa och hantera dokument.

I denna artikel kommer vi att förklara hur man bäst bevarar mötesprotokoll och mötesmaterial som används i framstegsmöten för systemutveckling, ur ett juridiskt perspektiv.

Varför är dokumenthantering viktig i systemutveckling?

I systemutvecklingsprojekt är det mycket viktigt att dokumentera innehållet i bekräftelsemöten, projektets framsteg och historik, även ur ett juridiskt perspektiv. Detta kan förklaras med följande två punkter:

För att undvika konflikter senare

Systemutveckling är vanligtvis ett projekt som involverar många parter, både på användar- och leverantörssidan. Därför, om det finns en diskrepans i förståelsen mellan användar- och leverantörssidan om vem som har vilket ansvar och vilka skyldigheter de tar på sig, kan det störa projektets framsteg.

Att många människor är involverade i projektet innebär också att det ofta kan uppstå kommunikationsproblem, som “alla säger något lite annorlunda och det är svårt att veta vem som har rätt”.

Det är meningsfullt att sammanställa innehållet i den överenskommelse som har nåtts i skriftlig form för att bekräfta att det inte finns några missförstånd mellan parterna, och att sammanställa det i ett dokument som alla inblandade kan kontrollera (vid olika tidpunkter) bidrar till att hålla alla på samma sida.

För övrigt, att använda juridisk kunskap för att förebygga uppkomsten av tvister i förväg kallas ibland för förebyggande juridiskt arbete.

För att förbereda sig för en tvist om den uppstår senare

Om vi ska förklara vikten av dokumenthantering från en något annorlunda synvinkel än den förebyggande juridiska aspekten som nämndes tidigare, kan vi också nämna “krishantering” i händelse av en faktisk tvist.

Låt oss anta att någon form av problem uppstår, projektet avbryts innan resultatet är klart, eller att det inte kommer att vara klart i tid för den ursprungliga deadline. Detta gäller både användar- och leverantörssidan, men om du vill säga “jag har min egen syn på vad som hände”, men om du inte har dokumenterat det, kommer du inte att kunna bevisa din ståndpunkt och kan bli missgynnad i en rättegång.

I synnerhet i problem som uppstår på grund av att “deadline inte uppnåddes”, kan frågor som “när och hur upptäcktes problemet?”, “när kom det en begäran om specifikationsändring?”, “hur försökte leverantören svara på användarens begäran om att lägga till funktioner?” ofta bli viktiga punkter som kan påverka utfallet av rättegången. Om det uppstår många “sade, sade inte” problem i det här skedet, blir det svårt att förvänta sig en rättvis lösning på tvisten.

Vad är särskilt viktigt att notera i protokollet från ett systemutvecklingsmöte?

Typer av möten inom systemutveckling

I systemutvecklingsprojekt är det vanligt att olika typer av möten planeras och genomförs löpande. Detta är inte förvånande med tanke på att många människor är involverade i projektet. Programmerare och ingenjörer som implementerar programmet på utvecklingsplatsen håller ofta regelbundna möten för att kontrollera framsteg i arbetet. Dessutom kan det finnas tillfällen då man granskar den implementerade koden för att säkerställa att det inte finns några problem med underhållbarhet eller säkerhetsbrister.

Utöver dessa möten på operativ nivå kan det också finnas möten där företagets styrelse eller ansvariga med befogenheter samlas. I dessa fall är mötena ofta inriktade på att fastställa den övergripande riktningen och policyn för utvecklingsprojektet. Sådana möten på ledningsnivå, som syftar till att “greppa” viktiga frågor, kallas ofta styrkommittéer.

Styrkommittén kräver särskild uppmärksamhet

Det är sant att olika möten planeras inom systemutveckling beroende på deltagarnas position och syftet med mötet, men från en juridisk synvinkel är det särskilt viktigt att uppmärksamma styrkommittén. Jämfört med framstegskontrollmöten och granskningsmöten på operativ nivå, bör vikten av dokumentation i styrkommittén erkännas särskilt ur perspektivet av att förebygga olika konflikter och vidta åtgärder vid konflikter. Anledningarna till detta är:

1. Styrkommittén är ett möte som leds av personer på ledningsnivå, och det är ofta ett möte som involverar viktiga beslut. Det är därför det är viktigt att visa hur både användare och leverantörer uppfattar situationen, även ur ett juridiskt perspektiv.
2. Om det är ett möte på operativ nivå, kommer innehållet i mötet oftast att återspeglas i olika design- och specifikationsdokument senare. Det är därför svårt att föreställa sig att det skulle uppstå problem med brist på dokumentation. (Även om det är nödvändigt att förbättra situationen om dokumentationen är otillräcklig även för dessa.)

Dessa är några av de punkter som kan lyftas fram.

Rättsfall relaterade till styrkommitténs protokoll

Nedan introducerar vi ett fall där protokollet från en styrkommitté behandlades som viktig bevisning i en faktisk rättegång. Fallet som citeras i domen nedan handlar om ett systemutvecklingsprojekt som avbröts mitt i, och där leverantörens brott mot projektledningsplikten erkändes. Innehållet i protokollet från detta möte, som visar leverantörens och användarens ursprungliga uppfattning, hade mycket stor betydelse i rättegången.

Leverantören har påpekat att innehållet i protokollet från styrkommittén, som ligger till grund för att fastställa förloppet i detta systemutvecklingsprojekt, har ändrats av användaren och därför inte nödvändigtvis återspeglar den faktiska arbetssituationen. Men, styrkommittén inrättades för att fatta beslut på högsta ledningsnivå i detta systemutvecklingsprojekt, och både leverantören och användaren deltog, med projektledare ansvariga för genomförandet av systemutvecklingen, för att göra en övergripande bedömning, dela upp faktiska framsteg och problem med schemat och arbetet, och fatta beslut om viktiga frågor. Och, de viktigaste punkterna som diskuterades skulle dokumenteras av leverantören i ett protokoll som skulle registreras i protokolldatabasen senast på morgonen två arbetsdagar efter mötet, och de slutliga besluten från mötet skulle dokumenteras genom detta protokoll. När protokollet fastställdes, kan det antas att både leverantören och användaren, med full förståelse för betydelsen av att dokumentera arbetet genom protokollet, granskade dess innehåll och uttryck och fastställde innehållet som återspeglar verkligheten i mötet. Särskilt leverantören, som är en professionell systemutvecklare, kan förväntas ha fullständig kunskap om betydelsen och metoden för att skapa sådana protokoll. Därför kan det sägas att det är lämpligt att behandla det fastställda protokollet som något som återspeglar den faktiska arbetssituationen i styrkommittén, och såvida inga särskilda omständigheter kan erkännas, är det lämpligt att erkänna att innehållet som dokumenterats där är det som sammanfattades i styrkommittén på det relevanta datumet.

Tokyo High Court, 26 september 2013 (Heisei 25)

Domstolens ståndpunkt verkar vara att om det är ett protokoll från ett möte som både leverantören och användaren har skapat gemensamt, kan det förväntas ha viss presumtiv kraft som “bevis”. Från en annan synvinkel bör man vara mycket försiktig med att inte skriva ner saker för lättvindigt i protokollet, eftersom det kan bli bevis som det är, och det finns en risk för detta.

Vad bör specifikt noteras i mötesprotokoll?

Mötesprotokoll har en viktig betydelse, inte bara som bevis i händelse av en rättegång, men också för att underlätta smidiga förhandlingar mellan parterna även om det inte blir någon rättegång. Så, vad bör specifikt dokumenteras och bevaras i mötesprotokoll? Låt oss organisera detta nedan.

Vad bör noteras ur leverantörens perspektiv

Som systemutvecklingsexperter har leverantörer en skyldighet att hantera projekt. Vi förklarar mer detaljerat om innehållet i denna skyldighet i följande artikel.

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

Med tanke på dessa skyldigheter, bör leverantörer särskilt notera följande:

1. Faktumet att varje utvecklingsfas har slutförts och dess datum
2. Historiken över hur de har svarat på förfrågningar om specifikationsändringar och tillägg av funktioner från användarsidan
3. Åtgärder och omständigheter som har vidtagits för att begära samarbete när utvecklingsarbetet har stagnerat på grund av användarens egen bekvämlighet

Detta är några exempel.

För att tillägga om punkt 3 ovan, i följande artikel förklarar vi vad leverantören bör överväga om användaren inte utför acceptanstest. I denna artikel förklarar vi hur domstolens bedömning kan ändras kraftigt beroende på hur samarbetsvillig leverantören har varit för att uppnå användarens acceptanstest, med hänvisning till faktiska domar.

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

Vad bör noteras ur användarens perspektiv

Naturligtvis har användare också en viss skyldighet att samarbeta med leverantörens utvecklingsarbete, eftersom det är ett system som de kommer att använda internt i sitt företag. Vi förklarar det övergripande innehållet i denna skyldighet i följande artikel.

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

1. Historiken över vad användaren har meddelat leverantören, såsom önskade funktioner och utseendet på skärmsidan
2. Historiken över olika problem som uppstått under leverantörens process (till exempel, förseningar i utvecklingsprocessen och dess orsaker på grund av plötslig avgång av medlemmar eller bristande undersökning från leverantörens sida)

I samband med punkt 2 ovan, är det särskilt benäget för oväntade problem att uppstå när utvecklingen av ett nytt system pågår samtidigt som det gamla systemet avvecklas. Det är särskilt vanligt med problem när data från det gamla systemet överförs till det nya systemet, men vi förklarar mer detaljerat om juridiska problem relaterade till sådana problem i följande artikel.

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

Sammanfattning

Ovanstående utgör riktlinjer för hur man ska bevara mötesprotokoll på systemutvecklingsplatsen ur ett juridiskt perspektiv. Det är viktigt att inte bara förstå praktiska “how-tos”, men också att fördjupa förståelsen för sambandet mellan teman som “lag”, “systemutveckling” och “dokumenthantering”. Just eftersom systemutveckling involverar många människor och organisationer och lätt kan utvecklas till stora affärstransaktioner, blir förebyggande och åtgärder för konflikter som uppstår i samband med detta viktiga. Och ur ett juridiskt perspektiv på bevarande av bevis, kommer existensen av “dokument” som kan objektivt bekräftas av alla att ha stor betydelse.

Visst, att helt och hållet verbalisera alla interaktioner och projektets utveckling kan vara en stor börda och kanske inte realistiskt. Men det är viktigt att identifiera vad som är juridiskt viktiga frågor och att fortsätta att dokumentera viktiga frågor när det behövs. Denna punkt bör vara allmänt erkänd av alla som är involverade i affärer, oavsett om de är juridiska experter eller inte.