Hvad er projektledelsesforpligtelser i systemudvikling?

Systemudvikling er en proces, der kun kan skride fremad gennem gensidigt samarbejde mellem brugeren, der bestiller tjenesten, og leverandøren, der modtager ordren.

IT-systemudviklingsprojekter, der anvendes i virksomheder, forløber sjældent helt efter planen eller som forventet. Tværtimod er det oftere sådan, at man står over for mange forskellige problemer og udfordringer, store som små, og man må overvinde dem én efter én for at komme videre. I denne proces er det selvfølgelig vigtigt, at brugeren og leverandøren gør en indsats for at synkronisere deres skridt, men det er også vigtigt at have en krisehåndtering, der tager højde for potentielle konfliktsituationer.

Fra et juridisk perspektiv kan det siges, at det første skridt i krisehåndtering er at klargøre, hvilke forpligtelser hver part har, og hvad de kan kræve som rettigheder fra den anden part. I denne artikel vil vi fokusere på at forklare, hvilke juridiske forpligtelser leverandøren har i forbindelse med et sådant projekt, med særlig fokus på projektledelsesforpligtelser.

Hvad indebærer projektledelsesforpligtelsen for leverandøren?

Lad os først se på, hvad projektledelsesforpligtelsen for leverandøren indebærer.

Ifølge retspraksis omfatter projektledelsesforpligtelsen følgende:

– Forpligtelsen til at fremme udviklingsarbejdet i overensstemmelse med aftalen, konstant at styre fremskridtene, at stræbe efter at opdage faktorer, der hindrer udviklingsarbejdet, og at håndtere disse på passende vis.

– Forpligtelsen til at styre brugerens involvering i udviklingen på passende vis, og at sikre, at brugere uden specialviden om systemudvikling ikke hindrer udviklingsarbejdet.

Dette indebærer at angive opgaver og deadlines for spørgsmål, hvor brugeren skal træffe beslutninger eller løse bekymringer, at påpege de problemer, der opstår, hvis brugerens beslutningstagning forsinkes, at leverandøren giver råd for at fremme brugerens beslutningstagning, og hvis der er krav, der ikke kan accepteres på grund af udviklingsforløbet, at forklare årsagen fuldt ud og afvise brugerens krav.

På denne måde har leverandøren en forpligtelse til at fremme udviklingsarbejdet, mens de opfordrer brugeren til at træffe beslutninger og stræber efter at sikre, at systemudviklingen lykkes.

Brugerens samarbejdsforpligtelse

Men i systemudvikling er det ikke kun leverandøren, der ensidigt påtager sig alle forpligtelser. Da det er et IT-system, der skal bruges i virksomheden, der bestiller det, bør systemudviklingsprojektet ikke være “nogen andens problem” for bestilleren.

Selv når man bruger eksterne eksperter på grund af deres tekniske og organisatoriske evner til at udvikle systemet, bør intern governance være på plads. Uden indsats for at udnytte ekspertisen hos eksterne eksperter, er det umuligt at levere det nødvendige arbejde, som om det var nogen andens problem. I denne forstand har brugeren også en forpligtelse til at samarbejde om systemudviklingen.

Brugerens samarbejdsforpligtelser omfatter følgende:

　① Brugeren skal aktivt foretage risikoanalyse, koordinere interne meninger på passende vis, konsolidere synspunkter og formidle krav til leverandøren.

　② Bekræftelse af resultaterne.

　③ At reagere på leverandørens anmodning om samarbejde.

Det forventes, at brugeren klart formidler til leverandøren, hvilke funktioner de kræver af systemet, og aktivt samarbejder om udviklingen.

Projektledelse er ikke let

Det kan være svært for brugere, der kun ser på skærmen, at være bevidste om, at et IT-system består af en kombination af små dele. Men dette er meget vigtigt, når man overvejer vanskelighederne ved at styre et systemudviklingsprojekt. Netop fordi et IT-system er sådan, kræves der af leverandøren både en omhyggelig opmærksomhed og evnen til samtidig at organisere det overordnede billede på en klar og koncis måde.

Der er vanskeligheder i arbejdet, som man måske ikke kan forestille sig ved blot at se på skærmen, og dette er også grunden til, at projekter “brænder”. Først og fremmest er det vigtigt at forstå disse punkter og erkende, at “at styre et projekt til at udvikle et IT-system er bestemt ikke en nem opgave”. Dette vil være en stor forudsætning for at lære om risikostyring af projekter.

Hvad der kan ske i tilfælde af overtrædelse af projektledelsesforpligtelser

Så hvad sker der konkret, hvis der er en overtrædelse af projektledelsesforpligtelserne?

Der er ingen specifikke artikler, der siger, “Dette er hvad projektledelsesforpligtelserne er”.

Men fra tidligere retssager kan vi få en vis forståelse af, hvad en bruger kan gøre, hvis en leverandør har overtrådt sine forpligtelser.

Hvis en leverandør har overtrådt sine forpligtelser, vil brugeren gøre krav på erstatning for skader eller ophævelse af kontrakten over for leverandøren. Men hvis brugeren også har et problem, kan det blive besluttet, at leverandøren ikke er ansvarlig, eller der kan blive foretaget en fejludligning, hvilket kan reducere erstatningsbeløbet.

På den anden side, hvis en bruger har overtrådt sin samarbejdsforpligtelse, kan det være muligt for leverandøren at kræve et beløb svarende til betalingen fra brugeren på grundlag af risikobæring (Japanese Civil Code artikel 536, afsnit 2) eller manglende opfyldelse af forpligtelser, hvis arbejdet ikke er blevet fuldført som følge heraf.

Retssager, der demonstrerer projektledelsesforpligtelser

Der er flere repræsentative retssager, der forklarer begrebet projektledelsesforpligtelser.

Den følgende sag udviklede sig til en retssag på grund af forsinkelser i leveringstiden og krav om prisstigninger fra leverandøren i forbindelse med systemudvikling. Dette kan være et eksempel på en såkaldt “brand” sag, hvor striden mellem brugeren og leverandøren om ansvarsfordelingen ender i retten.

Den sagsøgte, som er en specialist i systemudvikling, havde en forpligtelse til at fuldføre det pågældende computersystem inden den aftalte leveringsfrist i henhold til kontrakten og forslaget til det pågældende computersystem, baseret på sin høje grad af specialiseret viden og erfaring. Derfor skulle den sagsøgte forstå, at den havde en forpligtelse til at fremme udviklingsarbejdet i overensstemmelse med udviklingsprocedurerne, metoderne og arbejdsprocesserne, der blev præsenteret i kontrakten og forslaget til det pågældende computersystem, og til konstant at administrere fremskridtene, stræbe efter at opdage faktorer, der hindrer udviklingsarbejdet, og håndtere dem passende. Da systemudvikling udføres i samråd med ordregiveren og tager hensyn til dennes intentioner, skulle den sagsøgte også have haft en forpligtelse til at administrere ordregiverens, i dette tilfælde den sagsøgende National Health Insurance’s, involvering i systemudviklingen på passende vis og til at påvirke National Health Insurance, som ikke har specialiseret viden om systemudvikling, således at der ikke foretages handlinger, der hindrer udviklingsarbejdet (disse forpligtelser kaldes her “projektledelsesopgaver”).

Tokyo District Court, 10. marts 2004 (Heisei 16)

Det er ikke vigtigt at dechifrere de detaljerede formuleringer og den komplekse forløb af sagen fra ovenstående doms resume. Det vigtige er, at udtrykket “projektledelsesforpligtelser” bruges direkte. Selvom der ikke er nogen kodificeret artikel, kan man se en holdning, hvor retten tager initiativ til at etablere retningslinjer for ansvarsfordeling.

Lad os opsummere indholdet af ovenstående domsafgørelse på en letforståelig måde og organisere det i punktform. De “projektledelsesforpligtelser”, der nævnes her, er:

• At fremme det faktiske arbejde i overensstemmelse med den forudgående plan (udviklingsprocedurer, metoder, processer osv.)
• At udføre fremskridtsstyring for at se, om det faktiske arbejde går glat
• Hvis der er “hindrende faktorer”, der gør, at det faktiske arbejde ikke går glat, skal man opdage og træffe passende foranstaltninger efter behov

Desuden, med hensyn til ovenstående tre punkter,

• Ikke kun skal leverandøren gøre en ensidig indsats, men også gøre en indsats for kommunikation, såsom at anmode om nødvendig samarbejde fra brugersiden efter behov

Det kan organiseres som en generel betegnelse for sådanne ting.

Systemudvikling er for det meste kontraheret i form af en quasi-mandatkontrakt eller en kontrakt. En quasi-mandatkontrakt er simpelthen en kontrakt, der siger, “Udfør arbejdet med en nøjagtighed, der svarer til den betaling, du modtager”, så projektledelsesforpligtelserne kan også organiseres som et koncept, der absorberes i den “nøjagtighed osv.”, der skal realiseres.

Det er et emne for debat, men selv i tilfælde af en kontrakt, der siger “lav det, som du er blevet bedt om”, er det tænkeligt, at projektledelsesforpligtelser kan opstå. Årsagen er, som allerede nævnt, at uanset om det er en quasi-mandatkontrakt eller en kontrakt, er projektledelse stadig vigtig i systemudvikling, og det antages, at leverandørsiden skal udføre det.

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

Retssag, der viser projektledelsesforpligtelser, der kan pålægges før kontraktindgåelse

Desuden antages det, at projektledelsesforpligtelser kan pålægges selv i de indledende faser før en kontrakt indgås. Den retssag, der citeres nedenfor, viser, at leverandøren har projektledelsesforpligtelser, selv i de indledende faser før kontraktindgåelse, dvs. når forskellige forslag og planer fremsættes.

Den følgende sag handler om et projekt, der gik i stå midtvejs, og om det var muligt at anerkende projektledelsesforpligtelser på grund af mangler i planlægning og forslag før kontraktindgåelse, samt mangelfulde estimater og forklaringer til brugeren i forslagsfasen. Generelt blev det et problem, om det juridisk set var muligt at anerkende sådanne forpligtelser, da planlægning og forslag er opgaver, der udføres i de indledende faser før en kontrakt indgås, men retten anerkendte dette.

Den måde, projektledelsesforpligtelserne tænkes på i den ovenfor nævnte retssag, kan også gælde for de indledende faser før en kontrakt indgåes, som det vil være klart, når man læser nedenstående.

I planlægnings- og forslagsfasen fastlægges de overordnede rammer for projektets mål, udviklingsomkostninger, udviklingsomfang og udviklingstid, samt risiciene forbundet med projektet. Derfor er projektplanlægning og risikoanalyse, som leverandøren kræves at udføre i denne fase, uundværlige for at gennemføre systemudvikling. Derfor bør leverandøren, selv i planlægnings- og forslagsfasen, undersøge og verificere systemets funktioner, brugerens behov, systemudviklingsmetoder, udviklingsstruktur efter ordre osv., og forklare de risici, der kan forventes herfra, til brugeren. Disse forpligtelser for leverandøren til at undersøge og forklare kan betragtes som juridiske forpligtelser baseret på god tro i forhandlingsprocessen mod kontraktindgåelse, og det kan siges, at appellanten som leverandør har sådanne forpligtelser (forpligtelser i forbindelse med projektledelse på dette tidspunkt).

Tokyo High Court, 26. september 2013 (Heisei 25)

Desuden er det oprindeligt antaget, at der er visse juridiske forpligtelser over for den anden part, selv i de indledende faser før en kontrakt indgås, ikke kun i forbindelse med IT-projekter, men også i alle kommercielle transaktioner og forhandlinger, der involverer loven.

Jo større handelen er, jo længere er processen med “at mødes på midten” inden kontrakten, det endelige mål, nås. Selv i denne proces er det velkendt, at man i det mindste moralsk set bør være ærlig over for den anden part. For at sige det enkelt, er dette ikke kun en følelse af moral baseret på følelser, men også juridisk meningsfuldt. (Citatet nedenfor er forfatterens tilføjelse.)

Civil Code Article 1, Paragraph 2
Udøvelsen af rettigheder og opfyldelsen af forpligtelser skal udføres i god tro og ærligt.

Det, der klart udtrykker ovenstående indhold, er nøgleordet “god tro” i dommen.

Desuden har de retssager, der er blevet præsenteret i denne artikel, også en betydning som en “retningslinje for at trække grænsen mellem brugerens samarbejdsforpligtelser og leverandørens projektledelsesforpligtelser”. For mere information om brugerens samarbejdsforpligtelser i forbindelse med udvikling af IT-systemer, se følgende artikel.

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

Opsummering: Konsulter en advokat ved problemer relateret til overtrædelse af projektledelsesforpligtelser

I denne artikel har vi forsøgt at give en generel oversigt over projektledelsesforpligtelser i systemudvikling. Systemudvikling indebærer mange udfordringer og problemer, men det, der synes at være vigtigt, når man står over for sådanne situationer, er ‘grundlaget’, der gennemsyrer enhver konfliktsituation. Der er utvivlsomt uendelige variationer i den måde, individuelle uregelmæssige situationer opstår på.

Men vigtigheden af at spørge “Hvem havde oprindeligt hvilke juridiske forpligtelser?” i mødet med sådanne situationer har en vis universalitet, der går ud over individualiteten af selve sagen.

Snarere end at begrænse sig til ad hoc problemløsning, synes det, at løsningen gennem konstruktiv opdeling af udfordringer også ligger i loven og tidligere retspraksis, når man sigter mod dette.

Hvis der opstår problemer relateret til overtrædelse af projektledelsesforpligtelser, bør du straks konsultere en advokat.