Vad är projektledningsskyldigheter inom systemutveckling?

Systemutveckling är något som endast kan gå framåt genom ömsesidigt samarbete mellan användaren som beställer tjänsten och leverantören som tar emot beställningen.

Projekt för att utveckla IT-system som används i företag går sällan helt enligt plan eller förväntningar. Istället är det vanligare att man stöter på en mängd problem och utmaningar, stora som små, och att man fortsätter framåt genom att övervinna dem en efter en. I detta sammanhang är det naturligtvis viktigt att användaren och leverantören anstränger sig för att samordna sina steg, men det är också viktigt att hantera kriser med tanke på potentiella konfliktsituationer.

Från en juridisk synvinkel kan det sägas att det första steget i krishantering är att klargöra vilka skyldigheter varje part har och vilka rättigheter de kan hävda mot varandra. I denna artikel kommer vi att förklara vilka juridiska skyldigheter leverantören har i samband med ett projekt, med fokus på projektledningsskyldigheter.

Vad innebär projektledningsskyldigheter för leverantören?

Låt oss först titta på innehållet i leverantörens projektledningsskyldigheter.

Enligt rättspraxis innebär projektledningsskyldigheter följande:

– Skyldigheten att följa överenskommelsen och driva utvecklingsarbetet framåt, ständigt hantera framsteg och sträva efter att upptäcka faktorer som hindrar utvecklingsarbetet och hantera dem på lämpligt sätt

– Skyldigheten att på lämpligt sätt hantera användarens engagemang i utvecklingen och se till att användare som saknar teknisk kunskap om systemutveckling inte hindrar utvecklingsarbetet

Detta innebär att leverantören ska ange problem och tidsfrister för frågor och bekymmer där användaren behöver fatta beslut, visa de problem som uppstår när användarens beslutsfattande försenas, ge råd till användaren för att påskynda beslutsfattandet, och om det finns önskemål som inte kan accepteras på grund av utvecklingens framsteg, förklara skälen noggrant och avvisa användarens önskemål.

På detta sätt har leverantören en skyldighet att inte bara driva utvecklingsarbetet framåt, utan också uppmuntra användaren att fatta beslut och sträva efter att systemutvecklingen ska lyckas.

Användarens samarbetsplikt

Men i systemutveckling är det inte bara leverantören som ensidigt tar på sig alla skyldigheter. Eftersom det ursprungligen är ett IT-system som ska användas av företaget som beställer det, bör systemutvecklingsprojektet inte vara “någon annans problem” för beställaren.

Även om man utnyttjar externa experter för att utveckla systemet på grund av deras tekniska och organisatoriska förmåga, bör intern styrning vara tillämplig. Utan ansträngningar för att utnyttja de externa experters förmåga, är det omöjligt att leverera det nödvändiga arbetet som om det vore någon annans problem. I detta avseende har även användaren en skyldighet att samarbeta i systemutvecklingen.

Följande är exempel på samarbetsplikter som användaren bör uppfylla:

　① Användaren ska aktivt genomföra riskanalys och efter att ha samordnat interna åsikter på lämpligt sätt och enat synpunkter, förmedla önskemål till leverantören

　② Bekräfta resultatet

　③ Svara på leverantörens begäran om samarbete

Användaren förväntas klart förmedla till leverantören vilka funktioner som krävs av systemet och aktivt samarbeta i utvecklingen.

Projektledning är inte lätt

Det kanske inte är lätt för användare som bara ser skärmen att förstå att ett IT-system består av en kombination av små delar. Men detta är mycket viktigt när man tänker på svårigheterna med att hantera ett systemutvecklingsprojekt. Just för att ett IT-system är sådant, krävs det av leverantören att ha både en noggrann uppmärksamhet och förmågan att organisera den stora bilden på ett koncist sätt.

Det finns svårigheter i arbetet som kanske inte kan föreställas bara genom att titta på skärmen, och det är också en av anledningarna till att projekt “brinner”. Först och främst är det viktigt att förstå dessa punkter och veta att “att hantera ett projekt för att utveckla ett IT-system är inte alls enkelt”. Detta kommer att vara en stor förutsättning när du lär dig om riskhantering i projekt.

Vad som kan hända vid överträdelser av projektledningsplikter

Så vad händer konkret om det finns en överträdelse av projektledningsplikterna?

Det finns ingen tydlig paragraf som säger “Projektledningsplikterna är så här”, och det finns inga fasta regler för detta.

Men från tidigare rättsfall kan vi tolka en viss konsekvent hållning om vad en användare kan göra om en leverantör har brutit mot sina skyldigheter.

Om en leverantör har brutit mot sina skyldigheter kan en användare kräva skadestånd eller upplösning av kontraktet från leverantören. Men om användaren också har problem, kan det bedömas att leverantören inte är ansvarig, eller att det kan bli en fråga om att kompensera för vårdslöshet, vilket kan minska skadeståndsbeloppet.

Å andra sidan, om en användare har brutit mot sina samarbetsplikter, kan det tänkas att leverantören kan kräva en ersättning motsvarande ersättningen från användaren, på grundval av att arbetet inte har slutförts på grund av detta (japansk civil lag 536 paragraf 2), eller på grund av kontraktsbrott.

Rättsfall som visar på projektledningsskyldigheter

Det finns flera framstående rättsfall som förklarar vad projektledningsskyldigheter innebär.

Följande fall handlar om systemutveckling där det uppstod förseningar i leveransen och leverantören begärde en ökning av den ursprungliga uppskattningen, vilket ledde till en rättslig tvist. Detta kan ses som ett typiskt exempel på så kallade “brinnande fall”, där tvisten mellan användaren och leverantören om ansvarsfördelningen eskalerar till rätten.

Defendant, as a specialist in system development, had an obligation to complete the system as described in the contract and proposal for the system development contract based on his advanced professional knowledge and experience, and to deliver it by the agreed deadline for phased operation. Therefore, the defendant should be understood to have an obligation to proceed with the development work according to the development procedures, methods, and work processes presented in the contract and proposal for the system development contract, to always manage the progress, to strive to discover factors that hinder the development work, and to deal with them appropriately. Furthermore, since system development is carried out in consultation with the orderer, taking into account their intentions, the defendant should have had an obligation to properly manage the involvement of the plaintiff, the orderer, in the system development, and to influence the plaintiff, who does not have professional knowledge about system development, so that they do not hinder the development work (hereinafter, these obligations are referred to as “project management duties”).

Tokyo District Court, March 10, 2004 (Heisei 16)

From the summary of the above judgment, it is not important to decipher the detailed wording or the complex course of the case. The point is that the term “project management duties” is used as is. Although there is no explicit provision, it is possible to see the court’s attitude to establish guidelines for dividing legal responsibilities.

Let’s summarize the content of the above judgment in plain language and organize it in bullet points. The “project management duties” mentioned here are:

• Proceeding with the actual work according to the preliminary plan (development procedures, methods, processes, etc.)
• Managing the progress to see if the actual work is going smoothly
• If there are any “hindering factors” that prevent the actual work from going smoothly, discovering them and taking appropriate measures as needed

In addition to the above three points,

• Not just making efforts on the vendor’s side, but also making efforts in communication, such as appropriately asking the user side for necessary cooperation

can be collectively referred to.

System development is usually concluded as a quasi-mandate contract or a contract for work in legal terms. And a quasi-mandate contract is, simply put, a contract to “work with accuracy, etc. according to the remuneration received”, so the concept of project management duties can also be absorbed into the “accuracy, etc.” to be realized.

However, it is a debatable theme, but even in the case of a contract for work, which is a contract to “make what is asked for”, it is considered that project management duties can occur. The reason is, as already mentioned, that regardless of whether it is a quasi-mandate contract or a contract for work, project management is still important in system development, and it is believed that the vendor side should do it.

https://monolith.law/corporate/contract-and-timeandmaterialcontract[ja]

Rättsfall som visar på projektledningsansvar som kan tillämpas även före kontraktsingående

Det anses också att projektledningsansvar kan tillämpas även i de steg som föregår kontraktsingående. Rättsfallet som citeras nedan visar att leverantören har ett projektledningsansvar även i de steg som föregår kontraktsingående, det vill säga när olika förslag och planer läggs fram.

Fallet nedan handlar om ett projekt som avbröts mitt i, och det diskuterades om det var möjligt att erkänna ett projektledningsansvar på grund av brister i planering och förslag, samt i uppskattningar och förklaringar till användaren, före kontraktsingående. Generellt sett, eftersom planering och förslag är uppgifter som utförs före kontraktsingående, var frågan om det juridiskt sett var möjligt att erkänna sådana skyldigheter. Domstolen godkände detta.

Det kommer att bli tydligt att tankesättet om projektledningsansvar i det tidigare nämnda rättsfallet också gäller för steg före kontraktsingående när du läser följande.

Under planerings- och förslagsstadiet fastställs de övergripande ramarna för projektets mål, utvecklingskostnader, utvecklingsomfång och utvecklingstid, samt projektets koncept och genomförbarhet, och riskerna med projektet bestäms också i enlighet med detta. Därför är projektplanering och riskanalys som krävs av leverantören under planerings- och förslagsstadiet oumbärliga för att genomföra systemutveckling. Därför bör leverantören, även under planerings- och förslagsstadiet, överväga och verifiera systemets funktioner, användarens behovstillfredsställelse, systemutvecklingsmetoder, utvecklingsstruktur efter order, och förklara de risker som kan förväntas för användaren. Denna skyldighet för leverantören att verifiera och förklara kan ses som en skyldighet enligt skadeståndslagen baserad på principen om god tro under förhandlingsprocessen för att ingå ett kontrakt, och det kan sägas att appellanten, som leverantör, har en sådan skyldighet (en skyldighet att hantera projektledning på detta stadium).

Tokyo High Court, 26 september 2013 (Heisei 25)

Observera att tanken att det finns vissa juridiska skyldigheter gentemot den andra parten även i de steg som föregår kontraktsingående inte är begränsad till diskussioner om IT-projekt, utan gäller för alla affärstransaktioner och förhandlingar där lagar är inblandade.

Större affärer tenderar att ha en längre process av “samverkan” för att nå målet med ett kontrakt. Även i denna process är det väl förstått, åtminstone moraliskt, att man bör vara ärlig mot den andra parten. För att uttrycka det enkelt, denna typ av diskussion är inte bara en fråga om emotionell moral, utan har också juridisk betydelse. (Se citatet nedan. Understrykningen har lagts till av författaren.)

Civil Code Article 1, Paragraph 2
Utövandet av rättigheter och uppfyllandet av skyldigheter ska utföras med god tro och ärlighet.

Det som tydligt uttrycker innehållet ovan är nyckelordet “principen om god tro” i domstolsutslaget.

Observera att rättsfallet som presenterats i denna artikel också har en aspekt av att vara en “riktlinje för att dra gränsen mellan användarens samarbetsansvar och leverantörens projektledningsansvar”. För mer information om användarens samarbetsansvar i IT-systemutveckling, se följande artikel.

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

Sammanfattning: Vid problem relaterade till brott mot projektledningsplikten, rådfråga en advokat

I denna artikel har vi försökt att generellt organisera begreppet projektledningsplikt inom systemutveckling. Systemutveckling innebär alltid olika utmaningar och problem, men det som verkar vara viktigt när man står inför sådana situationer är “grunden” som genomsyrar alla konfliktsituationer. Det finns säkert oändliga variationer i hur varje oregelbunden situation uppstår.

Men, inför sådana situationer är det viktigt att fråga “Vem hade ursprungligen vilka juridiska skyldigheter?” Denna fråga har en viss universalitet som går utöver individualiteten i varje enskilt fall.

För att sträva efter lösningar genom konstruktiv uppdelning av problem, snarare än att bara fokusera på ad hoc-problemlösning, verkar ledtrådarna återigen finnas inom lagar och tidigare rättsfall.

Om det uppstår problem relaterade till brott mot projektledningsplikten, bör du omedelbart rådfråga en advokat.