Wat is de wetgeving rondom het 'in vlammen opgaan' van systeemontwikkelingsprojecten?

Een project zoals systeemontwikkeling is niet iets dat in een handomdraai kan worden bereikt. Het vereist een aanzienlijke inzet van middelen, waaronder talrijke mensen en organisaties, aanzienlijke financiële investeringen en een langdurige ontwikkelingsperiode. In dit artikel zullen we uitleggen hoe het fenomeen van ‘ontsporing’ in systeemontwikkelingsprojecten kan worden georganiseerd binnen een juridisch kader, en we zullen richtlijnen voor oplossingen samenvatten.

Waarom ‘ontvlammen’ projecten?

Een IT-systeem, zelfs als het geen bijzonder grootschalig project is, functioneert pas correct door de opeenstapeling van talloze programma bestanden en broncodes. Het is vaak zo dat deze systemen een gedetailleerde en nauwkeurige constructie hebben, die ver buiten het bereik van de verbeelding ligt op basis van de gebruikerservaring vanaf het scherm (of eerder, vooral als de gebruikerservaring vanaf het scherm eenvoudig en beknopt is).

• Alleen de deadline is vastgesteld, terwijl de specificaties en vereisten nog steeds vaag zijn en de tijd verstrijkt
• Veel teamleden zijn te veel afgeleid door interne politieke problemen en vallen uit door stress van menselijke relaties
• Er is een gebrek aan onderhandelingsvaardigheden op managementniveau, inclusief de projectmanager, en er wordt niet gevraagd om passende rapportage, communicatie en overleg van de teamleden

De specifieke redenen voor het ‘ontvlammen’ van een project kunnen per project verschillen. Echter, vanuit een juridisch perspectief kunnen de redenen voor het ‘ontvlammen’ van een project relatief eenvoudig worden georganiseerd in verschillende typologieën.

Type 1 van brandgevaar: Wanneer een project halverwege stagneert

Een typische reden waarom een systeemontwikkelingsproject halverwege kan stagneren, is een gebrek aan communicatie tussen de gebruikerskant en de leverancierskant. Een systeemontwikkelingsproject vereist niet alleen de technische en organisatorische vaardigheden van de leverancier, maar ook de medewerking van de uiteindelijke gebruikers van het systeem.

Daarom, als een project doorgaat terwijl de rollen van beide partijen onduidelijk blijven, kan dit leiden tot een soort ‘taakafschuiving’ die de soepele voortgang van het project belemmert. Voor een juridische overweging van de verplichtingen van zowel de gebruikerskant als de leverancierskant, raadpleeg de volgende artikelen.

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

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

De details van de verantwoordelijkheden van beide partijen kunnen worden bekeken in de bovenstaande artikelen, maar het belangrijkste punt hier is dat zowel de gebruiker als de leverancier bepaalde verantwoordelijkheden hebben in een systeemontwikkelingsproject. Over het algemeen erkennen eerdere rechtszaken en jurisprudentie de verplichting van de gebruikerskant om mee te werken aan aspecten die niet kunnen worden voltooid zonder hun medewerking, zoals het definiëren van vereisten, het ontwerpen van het uiterlijk van schermen, en acceptatie.

Aan de andere kant heeft de leverancier, na het ontvangen van de medewerking van de gebruiker op de bovengenoemde punten (en tegelijkertijd het inspannen voor communicatie om dergelijke medewerking te vragen), een alomvattende verplichting om het project soepel te laten verlopen en om obstakels te identificeren en te verwijderen.

Onder deze overwegingen hebben de rechtbanken aangegeven dat de gebruiker een verplichting heeft om intern governance toe te passen, en de leverancier heeft de verplichting om als externe expert zijn expertise en technische vaardigheden te tonen in zijn werk, en dat beide partijen alle geschillen eerlijk zullen behandelen.

Daarnaast is de acceptatiefase een moment waarop ‘stagnatie’ gemakkelijk kan optreden. Voor een gedetailleerde uitleg over acceptatie, zie het volgende artikel.

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

In dergelijke gevallen, als er eenmaal een geschil ontstaat, wordt er vaak veel waarde gehecht aan objectief verifieerbare bewijzen, zoals de voortgang van eerdere projecten en de inhoud van vergaderingen. Daarom hebben vooraf opgenomen documenten vaak een grote betekenis. Om uw positie niet in het nadeel te brengen, is het essentieel om een grondig documentbeheer te hebben. Voor een gedetailleerde uitleg vanuit het oogpunt van het belang van documentbeheer in systeemontwikkeling, zie het volgende artikel.

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

Type 2 van Brandgevaar: Annulering om persoonlijke redenen van de gebruiker

Het kan ook voorkomen dat een project halverwege wordt stopgezet op verzoek van de gebruiker. Stel bijvoorbeeld dat een bedrijf begint met het bouwen van een IT-systeem om alle personeelszaken te beheren, inclusief buitenlandse vestigingen, maar de strategie om uit te breiden naar het buitenland wordt ingetrokken. In dat geval kan de ontwikkeling van het systeem dat net is gestart, overbodig worden voor de gebruiker.

De vraag hoe een IT-systeem dat in een bedrijf wordt gebruikt, moet worden opgebouwd, is onlosmakelijk verbonden met de vraag welke bedrijfsprocessen er in dat bedrijf zijn. Daarom is het denkbaar dat de vereisten voor een systeem dat nodig of overbodig wordt, achteraf veranderen als gevolg van grote veranderingen in de organisatiestructuur, de herstructurering van bedrijfsafdelingen, of een radicale herziening van de strategie.

Als een project om deze redenen halverwege wordt onderbroken, kunnen er verschillende juridische problemen ontstaan. In dat geval worden doorgaans bepaalde wettelijke rechten toegekend aan de leverancier, zoals het recht om een vergoeding te vragen op basis van het voltooiingspercentage, omdat het een persoonlijke reden van de gebruiker is. Afhankelijk van het type contract dat is aangegaan, kunnen de wettelijke grondslagen verschillen, maar de inhoud kan als volgt worden samengevat:

・In het geval van een contract voor werk: Artikel 641 van het Japanse Burgerlijk Wetboek
Artikel 641 van het Japanse Burgerlijk Wetboek
→Zolang de aannemer het werk niet heeft voltooid, kan de opdrachtgever het contract te allen tijde opzeggen door schadevergoeding te betalen.
・In het geval van een quasi-mandaatcontract: Artikel 648, lid 3, van het Japanse Burgerlijk Wetboek (afhankelijk van de omstandigheden kan er ook een schadevergoedingsvordering zijn op basis van artikel 651 van het Japanse Burgerlijk Wetboek)
Artikel 648 van het Japanse Burgerlijk Wetboek
→Als de uitvoering halverwege eindigt door een oorzaak die niet aan de gevolmachtigde kan worden toegeschreven, kan de gevolmachtigde een vergoeding vragen in verhouding tot het deel van de uitvoering dat al is voltooid.
Artikel 651 van het Japanse Burgerlijk Wetboek
→1. Het mandaat kan te allen tijde door elke partij worden opgezegd.
→2. Als een van de partijen het mandaat opzegt op een moment dat nadelig is voor de andere partij, moet die partij de schade van de andere partij vergoeden. Dit geldt echter niet als er een onvermijdelijke reden is.

Samenvatting

Elk systeemontwikkelingsproject zal ongetwijfeld verschillende en diverse uitdagingen doorgaan. Echter, als het gaat om juridische ‘branden’ in projecten, biedt het kader dat in dit artikel wordt gepresenteerd een overzicht. Juridische kwesties met betrekking tot systeemontwikkeling omvatten inderdaad een zeer breed scala aan thema’s.

Maar net zoals systeemontwikkeling constructief denken vereist, kan risicobeheer dat daarmee gepaard gaat ook constructiever worden uitgevoerd door het totaalbeeld van het veld niet uit het oog te verliezen.