Hva er lovene som gjelder for avgang av medlemmer i systemutviklingsprosjekter?

I systemutviklingsprosjekter er det vanlig å bryte ned hver prosess og oppgave, og legge vekt på å fremme så planmessig som mulig. Men uansett hvor mye vi vektlegger planmessighet, er det uunngåelige, plutselige problemer som involverer ‘mennesker’. Spesielt er det risikoer som plutselig sykefravær eller avgang av prosjektmedlemmer, som vi ikke kan forhindre helt, uansett hvor mye vi fokuserer på oppfølging. I denne artikkelen vil vi forklare hvordan loven er involvert i forbindelse med avgang av prosjektmedlemmer.

Medlemmers avgang er en del av prosjektledelsesforpliktelsene

Først og fremst, i systemutviklingsprosjekter, antas det at leverandøren har en omfattende forpliktelse til å sikre en jevn fremdrift. Det er en forpliktelse til å estimere nødvendig personell, tidsramme, budsjett og arbeidstid for en jevn fremdrift av prosjektet, og å be om nødvendig samarbeid fra brukerne mens man styrer prosjektets fremdrift. Disse forpliktelsene kalles “prosjektledelsesforpliktelser”, og deres eksistens har blitt påpekt gjentatte ganger i tidligere rettsavgjørelser.

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

En plutselig avgang av en person på leverandørsiden kan sies å være en type problem med leverandørens prosjektledelsesforpliktelser.

• Overarbeid og arbeid i helgene som fører til fysisk utmattelse
• Psykisk stress på grunn av dårlige menneskelige relasjoner

Det er mange mulige årsaker til at noen plutselig forlater et prosjekt. Men disse er i utgangspunktet problemer med leverandørens arbeidsledelse. Derfor, selv om slike forhold resulterer i forsinkelser i levering, er det lite sannsynlig at dette vil frita for brudd på forpliktelser. Med andre ord, leverandøren er forventet å ha en holdning til å håndtere prosjektets fremdrift med planlegging, inkludert forventningen om en plutselig mangel på personell.

Viktige rettsavgjørelser knyttet til medlemsavgang

Sak der medlemmers avgang førte til forsinkelser i leveransen

I rettssaken vi siterer nedenfor, oppstod det forsinkelser i leveransen etter at et medlem plutselig forlot prosjektet, og prosjektets fremdrift gikk ikke som planlagt. I denne saken hadde brukerens representant en truende holdning overfor leverandørens representant, noe som også la psykologisk press på dem.

Saken ble komplisert mellom brukeren, som ønsket å forfølge leverandøren for mislighold av kontrakten på grunn av forsinkelser, og leverandøren, som ønsket å forfølge brukeren for brudd på samarbeidsplikten på grunn av deres truende og høytrykks holdning.

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

Imidlertid konkluderte retten med at de forskjellige omstendighetene ikke fritok leverandøren for deres prosjektledelsesforpliktelser, og støttet brukerens synspunkt (understreket og fet skrift er lagt til av forfatteren).

Leverandøren hevder at brukerens representant, med sin aggressive og høytrykks holdning, fornærmet leverandørens representant, noe som tvang leverandørens representant til å trekke seg fra prosjektet.

Det er sant at brukerens representant, i et møte rundt november 2003 (Heisei 15), sa ting som “Har du ikke lyst til å gjøre dette“, “Dette er slutten på kontrakten. Når jeg forlater dette rommet, er det over.” i en sterk tone. Men dette skyldes leverandørens forsinkelser og manglende respons på kommentarer til det foreslåtte kravdokumentet, til tross for at prototypfasen i grunnleggende avtale var satt til å være ferdig innen utgangen av oktober 2003 (Heisei 15), og at den ekstra funksjonen som var målet for utviklingen, ikke ble inkludert i det hele tatt. Dette kan ikke sies å være overdreven oppførsel.

Det er også uklart hvorfor C måtte trekke seg fra prosjektet på grunn av sykdom, men selv om stress fra prosjektet var årsaken, bør dette i utgangspunktet betraktes som et problem med arbeidsledelse på leverandørens side, og det kan ikke legges på brukerens ansvar.

Tokyo District Court, 4. desember 2007 (Heisei 19)

I den ovennevnte rettssaken, selv etter å ha tatt hensyn til det faktum at brukeren presset leverandøren med en “sterk tone”, ble leverandørens ansvar ikke fritatt. Bakgrunnen for denne avgjørelsen kan være at det ville være urettferdig å legge skylden på brukeren, som presset på med forskjellige “sterke toner”, gitt leverandørens dårlige respons. Det ble konkludert med at det ikke var nødvendig å anerkjenne brudd på samarbeidsplikten fra brukerens side, gitt at hele systemutviklingsprosjektet er basert på leverandørens oppfyllelse av prosjektledelsesforpliktelsene og brukerens oppfyllelse av samarbeidsplikten. Dette er antagelig hva som menes med uttrykket “det kan ikke sies å være overdreven oppførsel”.

Hva vi kan lære fra ovennevnte rettspraksis

I tillegg kan vi trekke følgende viktige lærdommer:

• Når et prosjektmedlem trekker seg på grunn av sykdom, og man vurderer å legge skylden på brukersiden, kreves det at leverandørsiden kan bevise en årsakssammenheng – at avgangen skyldes brukeren. Det er imidlertid vanligvis ikke lett å bevise en slik sammenheng.
• Selv om man kan bevise at arbeidsbelastningen økte på grunn av brukeren, noe som førte til at medlemmet ble syk, vil det vanligvis til slutt bli sett på som et problem med leverandørens arbeidsledelse. Hvis vi legger merke til at sterke uttrykk som “overdreven oppførsel” er brukt i dommen, bør vi anta at situasjonene der leverandørens arbeidsledelsesansvar kan fraskrives er ganske begrensede.

For å forberede seg på risikoen for at medlemmer forlater

Som nevnt ovenfor, selv om det oppstår en plutselig mangel på personell, er det svært vanskelig å legge skylden på brukerens side. Det kan hende at du blir tvunget til å gjennomføre omfattende ekstra utvikling, eller at du blir tvunget til å gjøre drastiske endringer i spesifikasjonene. Imidlertid er det ikke lett å bevise årsakssammenhengen mellom fysisk og mental forstyrrelse og diverse arbeidsbelastninger. Med tanke på disse omstendighetene, er det viktig å forberede personellstrukturen med tanke på at problemer som sykefravær og dårlig helse blant prosjektmedlemmer kan oppstå.

Hvis dette punktet skulle bli bestridt i retten, er det klart at leverandørsiden ville være i en svært ugunstig posisjon. Derfor er det viktigere å iverksette tiltak for å forhindre slike konflikter. Mulige tiltak kan være som følger:

Sett opp et system som forhindrer at ansvarlige blir isolert

Det er viktig å unngå situasjoner der en enkelt person deltar i møter, og ved å opprette et system der flere personer deltar i møter, kan det forhindres at de føler seg isolert psykologisk.

Ha en romslig personellplanlegging

Det er også viktig å ha en romslig personellplanlegging. Å sikre personell med en viss margin vil utvilsomt føre til økte kostnader. Men hvis du tenker på kostnadene ved erstatning for forsinkelser og bekymringen for at flere personer kan forlate under håndteringen av slike problemer, er det ofte mer rasjonelt å sikre personell med en viss margin fra begynnelsen.

Gjennomfør en gjennomgang av plasseringen før helsen forverres

Hvis en person forlater, vil arbeidsbelastningen for de andre medlemmene øke, noe som kan føre til en ond sirkel med flere personer som forlater. For å unngå en slik ond sirkel, er det viktig å gjennomføre en gjennomgang av plasseringen før helsen forverres alvorlig.

Implementer grundig endringsstyring og dokumentstyring av prosjektet

Det er ikke lett å bevise årsakssammenhengen mellom teammedlemmers avgang og brudd på brukerens samarbeidsplikt, men det er fortsatt viktig å implementere grundig endringsstyring og dokumentstyring. Dette er fordi, selv om du ikke kan bevise årsaken til teammedlemmers avgang, hvis det faktisk er en situasjon med overdreven arbeidsbelastning som kan føre til sykefravær, kan det inneholde elementer som støtter brudd på brukerens samarbeidsplikt. Slike omstendigheter kan være elementer som støtter rettferdigheten til offset for uaktsomhet, selv om leverandøren blir holdt ansvarlig for kontraktsbrudd eller mangelfull garanti i tilfelle av en “brann” i prosjektet.

I følgende artikkel forklarer vi viktigheten av dokumentstyring i systemutviklingsprosjekter.

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

For en mer detaljert diskusjon spesifikt om endringer i spesifikasjoner, se følgende artikkel.

https://monolith.law/corporate/howto-manage-change-in-system-development[ja]

Oppsummering

Vi har nå gjennomgått juridiske aspekter knyttet til fenomenet “teammedlemmers avgang”. For leverandører er det utvilsomt svært vanskelig juridisk sett å holde brukerne ansvarlige for medlemmers avgang.

Men selv med slike omstendigheter er det viktig å ikke misforstå og tenke at “i saker om teammedlemmers avgang, er jussen irrelevant”. Tenkeprosessen i de presenterte rettsavgjørelsene i seg selv stiller spørsmål ved hvordan grensene for “leverandørens prosjektledelsesplikt” og “brukerens samarbeidsplikt” skal defineres. Dette er fordi tiltak for å forhindre slike konflikter ofte er avledet ved å resonnere baklengs fra forventede konfliktsituasjoner.

Det er viktig å forstå at det å “være i ulempe i en rettssak” ikke betyr at “jussen er irrelevant”, men heller at “perspektivet på forebyggende juridisk arbeid er viktig”.