Wat zijn de projectmanagementverplichtingen bij systeemontwikkeling?

Systeemontwikkeling is iets dat pas vooruitgaat wanneer de gebruiker die de opdracht geeft en de leverancier die de opdracht aanneemt, samenwerken.

Projecten voor de ontwikkeling van IT-systemen die in bedrijven worden gebruikt, verlopen zelden volledig volgens plan of zoals verwacht. Integendeel, het is vaker zo dat er, ondanks de vele grote en kleine problemen en uitdagingen, stap voor stap vooruitgang wordt geboekt. In dit proces is het natuurlijk belangrijk dat de gebruiker en de leverancier hun stappen op elkaar afstemmen, maar ook crisisbeheer in het licht van mogelijke conflicten is van groot belang.

Vanuit een juridisch oogpunt is de eerste stap in crisisbeheer het verduidelijken welke verplichtingen beide partijen hebben en wat ze als rechten kunnen claimen tegenover de ander. In dit artikel zullen we uitleggen welke wettelijke verplichtingen de leverancier heeft in een reeks projecten, met de nadruk op projectmanagementverplichtingen.

Wat zijn de projectmanagementverplichtingen van de leverancier?

Laten we eerst eens kijken naar de inhoud van de projectmanagementverplichtingen van de leverancier.

Volgens jurisprudentie omvatten de projectmanagementverplichtingen het volgende:

– De verplichting om de ontwikkelingswerkzaamheden volgens de overeenkomst voort te zetten, de voortgang voortdurend te beheren, te streven naar het ontdekken van factoren die de ontwikkelingswerkzaamheden belemmeren en hier adequaat op te reageren

– De verplichting om de betrokkenheid van de gebruiker bij de ontwikkeling adequaat te beheren en ervoor te zorgen dat de gebruiker, die geen gespecialiseerde kennis van systeemontwikkeling heeft, geen acties onderneemt die de ontwikkelingswerkzaamheden belemmeren

Dit betekent dat de leverancier de gebruiker moet adviseren over zaken waarover de gebruiker een beslissing moet nemen en zorgen die moeten worden opgelost, de problemen en deadlines moet aangeven, de gevolgen moet aangeven als de besluitvorming van de gebruiker wordt vertraagd, en als er verzoeken zijn die niet kunnen worden geaccepteerd vanwege de voortgang van de ontwikkeling, moet de leverancier de redenen volledig uitleggen en het verzoek van de gebruiker weigeren.

Op deze manier heeft de leverancier de plicht om niet alleen de ontwikkelingswerkzaamheden voort te zetten, maar ook om de gebruiker aan te moedigen beslissingen te nemen en ervoor te zorgen dat de systeemontwikkeling succesvol is.

De medewerkingsplicht van de gebruiker

Echter, in systeemontwikkeling is het niet zo dat de leverancier eenzijdig alle verplichtingen op zich neemt. Aangezien het IT-systeem in de eerste plaats bedoeld is voor gebruik binnen het bedrijf dat de bestelling plaatst, mag het systeemontwikkelingsproject niet als een “andermans probleem” worden beschouwd.

Zelfs als externe experts worden ingeschakeld vanwege hun technische en organisatorische capaciteiten om systemen te ontwikkelen, zou er intern toezicht moeten zijn. Zonder inspanningen om de kracht van externe experts te benutten, is het onmogelijk om een noodzakelijk product te leveren alsof het iemand anders’ probleem is. In deze zin heeft ook de gebruiker een plicht om mee te werken aan de systeemontwikkeling.

De medewerkingsplicht van de gebruiker omvat het volgende:

　① De gebruiker voert proactief een risicoanalyse uit, coördineert interne meningen op een passende manier, komt tot een uniforme mening en communiceert deze aan de leverancier

　② Het controleren van de resultaten

　③ Reageren op verzoeken om medewerking van de leverancier

Van de gebruiker wordt verwacht dat hij de functies die hij van het systeem verlangt duidelijk aan de leverancier communiceert en actief meewerkt aan de ontwikkeling.

Projectmanagement is niet eenvoudig

Het feit dat een IT-systeem bestaat uit een combinatie van kleine onderdelen kan moeilijk te realiseren zijn voor gebruikers die alleen naar het scherm kijken. Echter, dit is zeer belangrijk bij het nadenken over de moeilijkheid van het managen van een systeemontwikkelingsproject. Precies omdat een IT-systeem zo is, wordt van de leverancier zowel een gedetailleerde aandacht als een vermogen om het grote geheel beknopt te organiseren en te overzien gevraagd.

Er zijn moeilijkheden in het werk die je niet kunt voorstellen door alleen naar het scherm te kijken, en dit is ook de reden waarom projecten “in brand vliegen”. Het is belangrijk om deze punten te begrijpen en te weten dat “het managen van een project om een IT-systeem te ontwikkelen is niet eenvoudig”, als een basisvoorwaarde voor het leren over projectrisicobeheer.

Wat kan er gebeuren bij overtreding van projectmanagementverplichtingen?

Wat gebeurt er specifiek als er een overtreding van de projectmanagementverplichtingen is?

Hierover is er geen duidelijk artikel dat zegt: “Dit is wat projectmanagementverplichtingen zijn”.

Echter, uit eerdere rechtszaken kunnen we een soort consistente houding afleiden over wat een gebruiker kan doen als er een overtreding is door de leverancier.

Als de leverancier een overtreding heeft begaan, zal de gebruiker schadevergoeding of contractbeëindiging van de leverancier eisen. Echter, als er ook problemen zijn aan de kant van de gebruiker, kan het zijn dat de leverancier niet aansprakelijk wordt geacht, of dat er een compensatie voor nalatigheid plaatsvindt, waardoor het bedrag van de schadevergoeding wordt verlaagd.

Aan de andere kant, als de gebruiker een overtreding van de samenwerkingsverplichting heeft begaan, kan de leverancier een bedrag gelijk aan de vergoeding van de gebruiker eisen op basis van het risico van niet-voltooiing van het werk (Artikel 536, lid 2, van het Japanse Burgerlijk Wetboek) of niet-nakoming van de verplichting.

Voorbeelden van rechtszaken die de verplichting tot projectmanagement aantonen

Er zijn enkele representatieve rechtszaken die de verplichting tot projectmanagement uitleggen, zoals hieronder:

De volgende zaak escaleerde tot een rechtszaak vanwege vertragingen in de leveringstermijn en verzoeken van de leverancier om de oorspronkelijke schatting te verhogen bij systeemontwikkeling. Het kan een typisch voorbeeld zijn van een zogenaamde “brandende zaak”, waarbij geschillen over hoe de verantwoordelijkheid tussen de gebruiker en de leverancier moet worden verdeeld, zelfs tot een rechtszaak leiden.

De gedaagde, als specialist in systeemontwikkeling, had de verplichting om het systeem te voltooien tegen de leveringsdeadline volgens de overeenkomst en het voorstel voor het computersysteem, gebaseerd op zijn geavanceerde professionele kennis en ervaring, en om het systeem te bouwen zoals beschreven. Daarom moet worden begrepen dat de gedaagde de verplichting had om de ontwikkelingswerkzaamheden voort te zetten volgens de ontwikkelingsprocedures, methoden en werkprocessen die in het contract en het voorstel voor het computersysteem werden gepresenteerd, om de voortgang voortdurend te beheren, om factoren die de ontwikkelingswerkzaamheden belemmeren te ontdekken en om hier op gepaste wijze mee om te gaan. Bovendien, omdat systeemontwikkeling wordt uitgevoerd in overleg met de besteller, had de gedaagde de verplichting om de betrokkenheid van de eiser, de nationale gezondheidsverzekering, bij de systeemontwikkeling op gepaste wijze te beheren en om ervoor te zorgen dat de eiser, die geen professionele kennis van systeemontwikkeling heeft, geen acties onderneemt die de ontwikkelingswerkzaamheden belemmeren (hierna worden deze verplichtingen “projectmanagementtaken” genoemd).

Tokyo District Court, 10 maart 2004 (Heisei 16)

Vanuit de essentie van het bovenstaande vonnis is het niet belangrijk om de gedetailleerde bewoordingen en de complexe loop van de zaak te interpreteren. Het punt is dat de term “projectmanagementverplichting” letterlijk wordt gebruikt. Hoewel er geen expliciete bepalingen zijn, is het duidelijk dat de rechtbank probeert richtlijnen te vestigen voor het verdelen van wettelijke verantwoordelijkheden.

Laten we de inhoud van het bovenstaande vonnis eenvoudig samenvatten en organiseren in bullet points. De “projectmanagementverplichting” hier betekent:

• Werkzaamheden uitvoeren volgens voorafgaande planning (ontwikkelingsprocedures, methoden, processen, enz.)
• Voortgangsbeheer uitvoeren om te zien of het werk soepel verloopt
• Als er “belemmerende factoren” zijn die het werk niet soepel laten verlopen, deze ontdekken en passende maatregelen nemen

Bovendien, met betrekking tot de bovenstaande drie punten,

• Niet alleen inspanningen van de leverancier, maar ook inspanningen om communicatie te bevorderen, zoals het vragen om passende medewerking van de gebruiker indien nodig

We kunnen organiseren dat dit een algemene term is.

Overigens worden systeemontwikkelingscontracten meestal gesloten in de vorm van quasi-mandaatcontracten of aannemingscontracten vanuit juridisch oogpunt. En een quasi-mandaatcontract is eenvoudig gezegd een contract om “werk te doen met een nauwkeurigheid die overeenkomt met de ontvangen vergoeding”, dus de projectmanagementverplichting kan ook worden georganiseerd als een concept dat wordt geabsorbeerd in de “nauwkeurigheid, enz.” die moet worden gerealiseerd.

Hoewel het een onderwerp van discussie is, wordt ook gedacht dat de projectmanagementverplichting kan ontstaan in het geval van een aannemingscontract, dat een contract is om “iets te maken zoals gevraagd”. De reden is zoals eerder vermeld, of het nu een quasi-mandaatcontract of een aannemingscontract is, het feit dat projectmanagement belangrijk is in systeemontwikkeling verandert niet, en het wordt gedacht dat de leverancier dat zou moeten doen.

Rechtszaak die aantoont dat projectmanagementverplichtingen ook vóór het sluiten van een contract kunnen worden opgelegd

Er wordt ook aangenomen dat projectmanagementverplichtingen kunnen worden opgelegd in de fase vóór het sluiten van een contract. Het volgende geciteerde rechtszaak toont aan dat er projectmanagementverplichtingen zijn voor de leverancier, zelfs in de fase vóór het contract, dat wil zeggen, wanneer verschillende voorstellen en plannen worden gemaakt.

De volgende zaak betreft een project dat halverwege is gestopt, en er werd gedebatteerd of projectmanagementverplichtingen konden worden erkend op basis van tekortkomingen in de planning en voorstellen, en in de schattingen en uitleg aan de gebruikerszijde in de fase vóór het sluiten van het contract. Over het algemeen was het een probleem of dergelijke verplichtingen wettelijk mogelijk waren, aangezien taken zoals planning en voorstellen voorafgaan aan het sluiten van een contract, maar de rechtbank erkende dit.

Het concept van projectmanagementverplichtingen in de bovengenoemde rechtszaak strekt zich ook uit tot de fase vóór het sluiten van een contract, zoals duidelijk zal worden bij het lezen van het volgende.

In de plannings- en voorstelfase worden de algemene kaders van zaken die verband houden met het projectconcept en de haalbaarheid, zoals het instellen van projectdoelen, ontwikkelingskosten, ontwikkelingsomvang en het opstellen en vooruitzien van de ontwikkelingsperiode, vastgesteld, en dienovereenkomstig worden de risico’s die gepaard gaan met het project ook bepaald. Daarom is de projectplanning en risicoanalyse die van de leverancier wordt gevraagd in de plannings- en voorstelfase essentieel voor het uitvoeren van systeemontwikkeling. Daarom moet de leverancier, zelfs in de plannings- en voorstelfase, de functies van het systeem dat hij voorstelt, de mate waarin het voldoet aan de behoeften van de gebruiker, de methoden voor systeemontwikkeling, de ontwikkelingsstructuur na de bestelling, enz. onderzoeken en verifiëren, en de risico’s die daaruit voortvloeien aan de gebruiker uitleggen. Deze verplichtingen van de leverancier met betrekking tot verificatie en uitleg kunnen worden gepositioneerd als verplichtingen onder het onrechtmatige daadrecht op basis van de goede trouw in het onderhandelingsproces naar het sluiten van een contract, en het kan worden gezegd dat de appellant als leverancier dergelijke verplichtingen (verplichtingen met betrekking tot projectmanagement in deze fase) heeft.

Tokyo High Court, 26 september 2013 (Heisei 25)

Overigens, het idee dat er bepaalde wettelijke verplichtingen zijn jegens de andere partij, zelfs in de fase vóór het sluiten van een contract, is niet beperkt tot IT-projecten, maar is van toepassing op alle commerciële transacties en onderhandelingen waarbij de wet betrokken is.

Hoe groter de transactie, hoe langer het proces van ‘toenadering’ naar het doel van het contract vaak is. Zelfs in dat proces is het goed te begrijpen dat men eerlijk moet zijn tegenover de andere partij, tenminste vanuit een moreel oogpunt. Simpel gezegd, dit soort verhalen zijn niet alleen gebaseerd op emotionele morele gevoelens, maar hebben ook juridische betekenis. (De volgende tekst is geciteerd. De onderstreping is toegevoegd door de auteur.)

Artikel 1, lid 2, van het Burgerlijk Wetboek
De uitoefening van rechten en de nakoming van verplichtingen moeten te goeder trouw en eerlijk worden uitgevoerd.

Het sleutelwoord ‘goede trouw’ in het vonnis geeft de bovenstaande inhoud beknopt weer.

Overigens, de rechtszaak die in dit artikel wordt gepresenteerd, heeft ook een aspect van het bieden van een richtlijn voor het trekken van de grens tussen de verplichting van de gebruikerszijde om mee te werken en de projectmanagementverplichting van de leverancierszijde. Voor de verplichting van de gebruikerszijde om mee te werken bij de ontwikkeling van IT-systemen, zie het volgende artikel.

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

Samenvatting: Raadpleeg een advocaat bij problemen met betrekking tot schending van projectmanagementverplichtingen

In dit artikel hebben we geprobeerd een algemene ordening te maken van wat bekend staat als projectmanagementverplichtingen in systeemontwikkeling. Systeemontwikkeling gaat gepaard met verschillende uitdagingen en problemen, maar wat belangrijk lijkt te zijn wanneer men met dergelijke situaties wordt geconfronteerd, is de ‘basis’ die ten grondslag ligt aan elk conflictscenario. Er zijn ongetwijfeld oneindige variaties in de manier waarop individuele onregelmatige situaties zich voordoen.

Echter, het belang van het stellen van de vraag “Wie had in de eerste plaats welke wettelijke verplichtingen?” in het licht van dergelijke situaties, heeft een zekere universaliteit die de individualiteit van de zaak zelf overstijgt.

In plaats van zich te beperken tot ad hoc probleemoplossing, lijkt het erop dat de sleutel tot het nastreven van oplossingen door constructieve probleemsegmentatie ook te vinden is in de wet en eerdere jurisprudentie.

Als er problemen ontstaan met betrekking tot schending van projectmanagementverplichtingen, raadpleeg dan onmiddellijk een advocaat.