Vad är lagarna som gäller för 'brand' i systemutvecklingsprojekt?

Projekt inom systemutveckling är inte något som kan uppnås över en natt. Det kräver en stor mängd resurser, inklusive många människor och organisationer, betydande finansiering och en lång utvecklingsperiod. I denna artikel kommer vi att förklara hur fenomenet “brinnande” i systemutvecklingsprojekt kan organiseras inom ramen för juridiska strukturer, och vi kommer att sammanställa riktlinjer för lösningar.

Varför “brinner” projekt upp?

Ett IT-system, även om det inte är ett särskilt stort projekt, fungerar korrekt endast tack vare en stor mängd programfiler och källkod som har byggts upp. Det är ofta mycket mer detaljerat och noggrant konstruerat än man kan föreställa sig utifrån användarupplevelsen på skärmen (eller snarare, ju enklare och mer koncis användarupplevelsen på skärmen är, desto mer sannolikt är det).

• Endast leveranstiden är fastställd, medan specifikationer och krav fortfarande är oklara när tiden går
• Medlemmarna är alltför upptagna med interna politiska problem, och många medlemmar tappar ut på grund av stress från mänskliga relationer
• Det finns en brist på förhandlingsförmåga även på ledningsnivå, inklusive projektledaren, och medlemmarna uppmanas inte att rapportera, kommunicera och konsultera på lämpligt sätt

De specifika orsakerna till att ett projekt “brinner upp” varierar från projekt till projekt. Men ur ett juridiskt perspektiv kan orsakerna till att ett projekt “brinner upp” organiseras relativt enkelt i flera olika typer.

Brandtyp 1: När ett projekt stannar upp halvvägs

En typisk orsak till att systemutvecklingsprojekt stannar upp halvvägs är bristande kommunikation mellan användarsidan och leverantörssidan. Ett systemutvecklingsprojekt kräver inte bara den tekniska och organisatoriska expertisen som leverantören besitter, utan också samarbete från användarna som slutligen kommer att använda systemet.

Om det är oklart vilken roll varje part ska spela i ett projekt, och projektet fortsätter med denna oklarhet, kan det uppstå en sorts “arbetspassning” som hindrar projektets smidiga framsteg. För en juridisk granskning av användarens och leverantörens skyldigheter, se följande artiklar.

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

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

Detaljerna om vilket ansvar varje part har kan hittas i ovanstående artiklar, men huvudpunkten här är att både användare och leverantörer har vissa ansvar i ett systemutvecklingsprojekt. Generellt sett, kräver saker som kravspecifikation, design av gränssnitt och acceptanstestning, samarbete från användarsidan för att slutföras, vilket tidigare rättsfall har erkänt som en skyldighet för användarsidan.

Å andra sidan har leverantören, efter att ha fått samarbete från användarsidan (och samtidigt gjort ansträngningar för att begära sådant samarbete), en övergripande skyldighet att säkerställa projektets smidiga framsteg och att identifiera och eliminera hinder.

Med denna tankegång har domstolarna visat en inställning att både användare och leverantörer har en skyldighet att visa intern styrning och att leverantören, som en extern expert, ska utöva sin expertis och tekniska färdigheter i sitt arbete, och att alla tvister ska hanteras rättvist.

En situation där “stopp” ofta uppstår är vid acceptanstestning. För mer information om acceptanstestning, se följande artikel.

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

I sådana fall, om en tvist uppstår, kommer objektivt verifierbara bevis, såsom projektets tidigare utveckling och innehållet i mötesdiskussioner, att prioriteras. Därför spelar dokument som har registrerats i förväg ofta en stor roll. För att inte missgynna din egen position är det viktigt att noggrant hantera dokument. För mer information om vikten av dokumenthantering i systemutveckling, se följande artikel.

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

Typ av brand: När användaren avbryter av egen vilja

Det kan också hända att ett projekt avbryts på grund av användarens önskemål. Till exempel, låt oss anta att ett företag har börjat utveckla ett IT-system för att hantera personalfrågor, inklusive utlandsbaserade kontor, men företagets strategi för att expandera utomlands har dragits tillbaka. I sådana fall kan utvecklingen av det påbörjade systemet bli onödigt även för användaren.

Frågan om hur ett IT-system som används i ett företag bör byggas upp kan inte skiljas från frågan om vilken typ av verksamhet som finns i företaget. Därför är det tänkbart att kraven på ett system som blir nödvändigt (eller onödigt) kan ändras efteråt på grund av stora förändringar i organisationsstrukturen, omorganisationen av affärsavdelningar, en grundlig översyn av strategin, och så vidare.

Om ett projekt avbryts på grund av sådana omständigheter kan det uppstå olika juridiska problem. I sådana fall, eftersom det är användarens egen vilja, erkänns leverantören vissa juridiska rättigheter, såsom att begära betalning i proportion till graden av färdigställande. Beroende på vilken typ av kontrakt som har antagits, kan det finnas skillnader i de bestämmelser som ligger till grund, men innehållet kan sammanfattas som följer:

・I fallet med ett kontrakt: Japansk civil lag 641 §
Japansk civil lag 641 §
→Beställaren kan när som helst avbryta kontraktet genom att ersätta skadan, så länge arbetet inte är slutfört.
・I fallet med ett quasi-kontrakt: Japansk civil lag 648 § 3 (beroende på omständigheterna, kan skadestånd enligt Japansk civil lag 651 § också begäras)
Japansk civil lag 648 §
→Om uppdraget avslutas mitt i utförandet på grund av en orsak som inte kan tillskrivas uppdragstagaren, kan uppdragstagaren begära betalning i proportion till det arbete som redan har utförts.
Japansk civil lag 651 §
→1. Uppdraget kan avbrytas av båda parter när som helst.
→2. Om en part avbryter uppdraget vid en tidpunkt som är ogynnsam för den andra parten, måste den parten ersätta den andra partens skada. Detta gäller dock inte om det finns en oundviklig orsak.

Sammanfattning

Varje systemutvecklingsprojekt kommer att gå igenom olika och mångfaldiga komplikationer. Men när det kommer till juridiska problem som kan leda till att ett projekt “brinner upp”, kan ramverket som presenteras i denna artikel fungera som en översikt. Juridiska frågor relaterade till systemutveckling innefattar verkligen en mängd olika teman.

Precis som systemutvecklingsarbete kräver konstruktivt tänkande, kan riskhanteringen som följer med det också utföras mer konstruktivt genom att inte förlora sikte på den större bilden av området. Är det inte så?