Wat is de juiste manier om notulen bij te houden tijdens systeemontwikkeling vanuit een juridisch perspectief?

Wanneer een bedrijf systeemontwikkeling uitbesteedt aan een ander bedrijf, is het vaak het geval dat de contracten, ondertekend met de bedrijfszegels van de CEO’s, en de specificatiedocumenten gemaakt door de projectleiders, niet altijd duidelijk maken wat er precies gemaakt moet worden en tegen welke deadline. Dit komt omdat er in veel systeemontwikkelingsprojecten dagelijks interacties plaatsvinden op operationeel niveau, zoals e-mails en telefoongesprekken, en vergaderingen georganiseerd door projectleiders, waarin zaken als specificatiebevestiging van aanvankelijk vage onderdelen, specificatiewijzigingen in overeenstemming met veranderende omstandigheden, verzoeken om extra functies en verzoeken om samenwerking bij problemen worden besproken.

Vanuit het oogpunt van het soepel laten verlopen van systeemontwikkeling en het voorbereiden op eventuele geschillen, is het belangrijk om documentatie te creëren en te beheren om een systeemontwikkelingsproject soepel te coördineren.

In dit artikel zullen we uitleggen hoe je notulen en vergaderdocumenten voor voortgangsvergaderingen van systeemontwikkeling kunt bewaren, vanuit een juridisch perspectief.

Waarom documentbeheer belangrijk is bij systeemontwikkeling

In systeemontwikkelingsprojecten is het zeer belangrijk om verslagen bij te houden van de inhoud van bevestigingsvergaderingen en de voortgang en achtergrond van het project, ook vanuit een juridisch perspectief. De redenen hiervoor kunnen als volgt worden samengevat:

Om latere geschillen te voorkomen

Systeemontwikkeling is meestal een project dat vordert met de betrokkenheid van vele partijen, zowel aan de gebruikers- als aan de leverancierskant. Daarom kan het voorkomen dat er een discrepantie is in het begrip tussen de gebruikers- en de leverancierskant over wie welke rol op zich neemt en welke verplichtingen zij aangaan, wat problemen kan veroorzaken in de voortgang van het project.

Daarnaast betekent het feit dat veel mensen betrokken zijn bij het project dat er gemakkelijk communicatieproblemen kunnen ontstaan, zoals “mensen zeggen iets anders en het is niet duidelijk wie gelijk heeft”.

Het is zinvol om de inhoud van de overeenkomst op schrift te stellen om te controleren of er geen discrepanties zijn in het begrip van beide partijen, en het samenstellen van documenten die door alle betrokkenen op hun eigen tijd kunnen worden gecontroleerd, draagt bij aan het op één lijn brengen van iedereen.

Overigens wordt het gebruik van juridische kennis als middel om geschillen te voorkomen soms preventief juridisch werk genoemd.

Als maatregel voor het geval er later een geschil ontstaat

Daarnaast, hoewel het vergelijkbaar is met het preventieve juridische perspectief dat hierboven is genoemd, kan het belang van documentbeheer worden uitgelegd vanuit een iets ander perspectief, namelijk “crisismanagement” in het geval van een daadwerkelijk geschil.

Stel je voor dat er een probleem ontstaat, het project wordt onderbroken voordat het eindproduct is voltooid, of de oorspronkelijke deadline wordt niet gehaald en het wordt een rechtszaak. Dit geldt voor zowel de gebruikers- als de leverancierskant, maar als je wilt zeggen “er is een reden voor wat er is gebeurd”, en er zijn geen schriftelijke verslagen, dan kun je je eigen argument niet bewijzen en kun je in de rechtbank in het nadeel zijn.

Vooral in geschillen die ontstaan door “het niet halen van de deadline”, zijn zaken als “wanneer en hoe werd het probleem ontdekt”, “wanneer werd er een verzoek om specificatiewijziging gedaan”, “hoe heeft de leverancier gereageerd op het verzoek om extra functies van de gebruikerskant” vaak cruciale punten die de uitkomst van de rechtszaak kunnen beïnvloeden. Als er veel problemen ontstaan over “wie wat heeft gezegd”, wordt het moeilijk om een eerlijke geschillenbeslechting te verwachten.

Wat is vooral belangrijk in de notulen van systeemontwikkelingsvergaderingen?

Soorten vergaderingen in systeemontwikkeling

In systeemontwikkelingsprojecten worden vaak verschillende vergaderingen gepland en uitgevoerd. Dit is niet verrassend, gezien het feit dat veel mensen betrokken zijn bij het project. Programmeurs en ingenieurs die de implementatie van het programma op de ontwikkelingslocatie uitvoeren, houden vaak regelmatige vergaderingen om de voortgang van het werk te controleren. Er kunnen ook gevallen zijn waarin een review wordt uitgevoerd terwijl de daadwerkelijke code wordt bekeken om te controleren of er problemen zijn met de onderhoudbaarheid en beveiligingsaspecten van de geïmplementeerde code.

Bovendien zijn er niet alleen vergaderingen op het niveau van de verantwoordelijke personen op de ontwikkelingslocatie, maar ook vergaderingen waarbij de directeuren van het bedrijf en verantwoordelijke personen met autoriteit betrokken zijn. In dergelijke gevallen zal de vergadering vaak gericht zijn op het bepalen van de algemene richting en het beleid van het ontwikkelingsproject. Dergelijke vergaderingen op het niveau van de verantwoordelijken, bedoeld om belangrijke zaken “in handen” te houden, worden ook wel stuurcomités genoemd.

Speciale aandacht voor het stuurcomité

Zoals eerder vermeld, worden er in de context van systeemontwikkeling verschillende vergaderingen gepland, afhankelijk van de positie van de betrokken personen en het doel. Vanuit een juridisch oogpunt is de vergadering die bijzonder belangrijk is, het stuurcomité. In vergelijking met voortgangscontrolevergaderingen en reviewvergaderingen op het niveau van de verantwoordelijken, is het vooral belangrijk om het belang van documentatie goed te begrijpen vanuit het oogpunt van het voorkomen van verschillende conflicten en maatregelen bij het uitbreken van conflicten. De redenen hiervoor zijn:

1. Vanwege de aard van het stuurcomité, dat wordt georganiseerd door personen op het niveau van de verantwoordelijken, is het vaak een vergadering die betrokken is bij belangrijke beslissingen, en wordt het gezien als iets dat de perceptie van zowel de gebruiker als de leverancier laat zien, en wordt het vaak belangrijk geacht vanuit een juridisch oogpunt.
2. Als het een vergadering op het niveau van de verantwoordelijken is, wordt de inhoud van de vergadering meestal weerspiegeld in verschillende ontwerpen en specificaties, en is het onrealistisch om te verwachten dat er een probleem zal zijn met “geen documentatie”. (Hoewel, als de documentatie zelfs voor deze dun is, zou er waarschijnlijk verbetering nodig zijn.)

Dit zijn enkele van de punten die kunnen worden genoemd.

Rechtszaken met betrekking tot de notulen van de Stuurgroep

Hieronder introduceren we een geval waarin de notulen van de Stuurgroep werden behandeld als belangrijk bewijsmateriaal in een daadwerkelijke rechtszaak. De zaak die in het onderstaande vonnis wordt geciteerd, betreft een systeemontwikkelingsproject dat halverwege is gestagneerd, en waarbij een schending van de projectmanagementverplichtingen door de leverancier is erkend. De inhoud van de notulen in deze zaak, die de oorspronkelijke perceptie van zowel de leverancier als de gebruiker aantoont, had een zeer grote betekenis in de rechtszaak.

De leverancier heeft aangegeven dat de inhoud van de notulen van de Stuurgroep, die zijn gebruikt om de voortgang van de systeemontwikkeling te bevestigen, niet noodzakelijkerwijs de werkelijke situatie weerspiegelt, omdat deze is gewijzigd door de gebruiker. Echter, de Stuurgroep is opgezet met het doel om beslissingen te nemen op het hogere managementniveau van de systeemontwikkeling, en de verantwoordelijken voor de uitvoering van de systeemontwikkeling van zowel de leverancier als de gebruiker namen deel, om een algehele evaluatie, het delen van de werkelijke voortgang en problemen van het schema, en het nemen van beslissingen over belangrijke kwesties te realiseren. De belangrijkste punten die daar werden besproken, werden vastgelegd in de notulen die door de leverancier werden opgesteld en geregistreerd in de notulen-database tegen de ochtend van de tweede werkdag na de vergadering. Bij het vaststellen van de notulen, kunnen we aannemen dat zowel de leverancier als de gebruiker de inhoud en uitdrukking hebben overwogen, terwijl ze het belang van het vastleggen van het werk door middel van de notulen volledig erkenden, en de inhoud hebben vastgesteld als een weerspiegeling van de werkelijke situatie van de vergadering. In het bijzonder kan worden gezegd dat de leverancier, die zich bezighoudt met systeemontwikkeling, vanzelfsprekend bekend was met het belang en de methode van het opstellen van dergelijke notulen. Daarom kan worden gezegd dat het passend is om de vastgestelde notulen te behandelen als een weerspiegeling van de werkelijke situatie van de werkzaamheden van de Stuurgroep, en tenzij er bijzondere omstandigheden zijn, is het passend om de inhoud van de voortgang van het werk, enz., zoals vermeld in de notulen, te erkennen als een samenvatting van de Stuurgroep op de betreffende datum.

Tokyo High Court, 26 september 2013 (Heisei 25)

Het standpunt van de rechtbank lijkt te zijn dat als de notulen van een vergadering, die zijn opgesteld met instemming van zowel de leverancier als de gebruiker, kunnen worden beschouwd als ‘bewijs’ met een bepaalde veronderstelde kracht. Vanuit een ander perspectief, als je te gemakkelijk notities maakt in de notulen, is er een risico dat dit direct als bewijs wordt gebruikt, dus je moet hier zeker voorzichtig mee zijn.

Wat zijn de specifieke items die in de notulen van een vergadering moeten worden opgenomen?

De notulen van een vergadering hebben een belangrijke betekenis, niet alleen als bewijs in het geval van een rechtszaak, maar ook om de onderhandelingen tussen de partijen soepel te laten verlopen. Maar wat moet er precies worden gedocumenteerd en vastgelegd in de notulen van een vergadering? Hieronder zullen we dit verder uitwerken.

Wat moet er vanuit het standpunt van de leverancier worden vastgelegd?

Vanuit het standpunt van de leverancier, die de verantwoordelijkheid draagt voor projectmanagement als expert in systeemontwikkeling, zijn er bepaalde zaken die specifiek moeten worden vastgelegd. Deze verantwoordelijkheden worden in detail uitgelegd in het volgende artikel.

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

Met deze verantwoordelijkheden in gedachten, zijn de zaken die de leverancier specifiek moet vastleggen:

1. Het feit dat elk ontwikkelingsproces is voltooid en de datum daarvan
2. De geschiedenis van hoe ze hebben gereageerd op verzoeken van de gebruikerskant voor specificatiewijzigingen en functietoevoegingen
3. De maatregelen die ze hebben genomen om samenwerking te vragen wanneer de voortgang van de ontwikkelingswerkzaamheden wordt belemmerd door de gebruikerskant, en de achtergrond daarvan

Dit zijn enkele voorbeelden.

Ter aanvulling op punt 3 hierboven, wordt in het volgende artikel uitgelegd wat de leverancier moet overwegen als de gebruiker geen acceptatietest uitvoert. In dit artikel wordt uitgelegd hoe de beslissing van de rechtbank sterk kan variëren afhankelijk van hoe coöperatief de leverancier is geweest in het helpen van de gebruiker om de acceptatietest uit te voeren, met behulp van daadwerkelijke vonnissen.

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

Wat moet er vanuit het standpunt van de gebruiker worden vastgelegd?

Natuurlijk heeft de gebruiker ook een bepaalde verplichting om samen te werken met de ontwikkelingswerkzaamheden van de leverancier, aangezien het een systeem is dat intern wordt gebruikt. De algemene inhoud van deze verplichting wordt uitgelegd in het volgende artikel.

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

1. De geschiedenis van wat de gebruiker aan de leverancier heeft gecommuniceerd, zoals gewenste functies en het uiterlijk van het scherm
2. De geschiedenis van verschillende problemen die zich hebben voorgedaan tijdens de processen van de leverancier (bijvoorbeeld, plotseling vertrek van teamleden of vertragingen in de ontwikkelingsschema’s veroorzaakt door onvoldoende onderzoek door de leverancier, en de oorzaken daarvan)

Met betrekking tot punt 2 hierboven, is het bijzonder waarschijnlijk dat er onvoorziene problemen ontstaan wanneer de ontwikkeling van een nieuw systeem gelijktijdig plaatsvindt met de afschaffing van een oud systeem. Problemen komen vaak voor bij het overzetten van gegevens van het oude systeem naar het nieuwe systeem, maar de juridische problemen rond dergelijke problemen worden in detail uitgelegd in het volgende artikel.

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

Samenvatting

Het bovenstaande vormt de richtlijnen voor het bijhouden van vergadernotulen vanuit een juridisch perspectief op de locatie van systeemontwikkeling. Naast praktische knowhow is het ook belangrijk om een dieper begrip te krijgen van de verbinding tussen thema’s zoals ‘wetgeving’, ‘systeemontwikkeling’ en ‘documentbeheer’. Juist omdat systeemontwikkeling gemakkelijk kan uitgroeien tot grootschalige commerciële transacties die veel mensen en organisaties betrekken, is het belangrijk om conflictpreventie en -beheersing te hebben. Vanuit een juridisch perspectief op het behoud van bewijsmateriaal, wordt het bestaan van ‘documenten’ die objectief kunnen worden bevestigd door iedereen, van groot belang.

Het is zeker waar dat het volledig verwoorden van alle interacties en de voortgang van projecten een grote last kan zijn en misschien niet realistisch. Echter, het is belangrijk om te bepalen wat juridisch belangrijke zaken zijn en om deze belangrijke zaken naar behoren te documenteren. Dit punt zou breed erkend moeten worden door iedereen die betrokken is bij het bedrijfsleven, ongeacht of ze juridische experts zijn of niet.