Czym jest obowiązek zarządzania projektem w rozwoju systemów?

Rozwój systemu jest możliwy tylko dzięki wzajemnej współpracy między użytkownikiem zamawiającym usługę a dostawcą, który ją realizuje.

Projekty związane z tworzeniem systemów IT wykorzystywanych w firmach rzadko kiedy przebiegają zgodnie z planem i oczekiwaniami. Częściej spotykamy się z sytuacją, gdzie mimo wielu problemów i wyzwań, projekt jest kontynuowany i stopniowo pokonuje napotkane trudności. W takim kontekście, równie ważne jak synchronizacja działań między użytkownikiem a dostawcą, jest zarządzanie kryzysowe, które uwzględnia potencjalne konflikty.

Z prawnego punktu widzenia, pierwszym krokiem w zarządzaniu kryzysowym jest jasne określenie, jakie obowiązki spoczywają na każdej ze stron, a także jakie prawa mogą one rościć. W tym artykule skupimy się na wyjaśnieniu, jakie prawne obowiązki spoczywają na dostawcy w kontekście całego projektu, ze szczególnym uwzględnieniem obowiązków związanych z zarządzaniem projektem.

Obowiązki zarządzania projektem po stronie dostawcy

Na początek przyjrzyjmy się obowiązkom zarządzania projektem po stronie dostawcy.

Według orzecznictwa, obowiązki zarządzania projektem obejmują:

– Obowiązek prowadzenia prac rozwojowych zgodnie z umową, ciągłego monitorowania postępów i dążenia do wykrywania czynników, które mogą utrudniać prace rozwojowe, oraz odpowiedniego reagowania na nie

– Obowiązek odpowiedniego zarządzania zaangażowaniem użytkownika w rozwój i dążenie do zapewnienia, że użytkownik, który nie posiada specjalistycznej wiedzy na temat rozwoju systemów, nie podejmuje działań, które mogą utrudniać prace rozwojowe

Dotyczy to pokazywania użytkownikowi problemów i terminów dotyczących kwestii, które wymagają podjęcia decyzji lub rozwiązania problemów, wskazywania problemów, które mogą wystąpić, gdy decyzje użytkownika są opóźnione, udzielania przez dostawcę porad w celu przyspieszenia decyzji użytkownika, a w przypadku, gdy istnieją żądania, które nie mogą być zaakceptowane ze względu na postęp prac rozwojowych, dostatecznego wyjaśnienia powodów i odrzucenia żądań użytkownika.

W ten sposób, dostawca ma obowiązek nie tylko prowadzić prace rozwojowe, ale także zachęcać użytkownika do podejmowania decyzji i dążyć do sukcesu rozwoju systemu.

Obowiązek współpracy po stronie użytkownika

Jednakże, w przypadku rozwoju systemów, nie jest tak, że dostawca jednostronnie podejmuje wszystkie obowiązki. Przecież, skoro jest to system IT, który ma być używany w firmie zamawiającej, projekt rozwoju systemu nie powinien być “sprawą innych” dla strony zamawiającej.

Nawet jeśli korzysta się z pomocy zewnętrznych ekspertów, polegając na ich umiejętnościach technicznych i organizacyjnych w rozwoju systemów, należy zapewnić nadzór z wewnątrz. Bez wysiłku na rzecz wykorzystania umiejętności zewnętrznych ekspertów, nie jest możliwe dostarczenie wymaganego produktu, traktując wszystko jako sprawę innych. W tym sensie, po stronie użytkownika również istnieje obowiązek współpracy w rozwoju systemów.

Obowiązki współpracy, które powinna spełnić strona użytkownika, obejmują:

　① Użytkownik powinien aktywnie przeprowadzać analizę ryzyka, odpowiednio koordynować opinie wewnętrzne i zjednoczyć swoje stanowisko, a następnie przekazać swoje żądania dostawcy

　② Sprawdzenie produktów końcowych

　③ Reagowanie na prośby o współpracę ze strony dostawcy

Od strony użytkownika wymaga się, aby jasno przekazała dostawcy funkcje, które system powinien spełniać, i aktywnie współpracowała w rozwoju.

Zarządzanie projektem nie jest łatwe

Może być trudne dla użytkownika, który patrzy tylko na ekran, aby zdać sobie sprawę, że system IT składa się z drobnych części. Jednak jest to bardzo ważne przy rozważaniu trudności zarządzania projektem rozwoju systemu. Ze względu na to, że system IT jest taki, od dostawcy wymaga się jednocześnie drobiazgowej uwagi i zdolności do uporządkowania ogólnego obrazu w sposób zwięzły.

Trudności pracy leżą w miejscach, które są trudne do wyobrażenia, patrząc tylko na ekran, a z innej perspektywy, są to również powody, dla których projekt “płonie”. Najpierw zrozumieć te punkty i wiedzieć, że “zarządzanie projektem rozwoju systemu IT nie jest łatwe”, będzie podstawą do nauki zarządzania ryzykiem projektu.

Co może się zdarzyć w przypadku naruszenia obowiązków zarządzania projektem

Więc, co konkretnie może się zdarzyć, gdy dochodzi do naruszenia obowiązków zarządzania projektem?

Nie ma tutaj żadnego konkretnego artykułu, który mówiłby, że “obowiązki zarządzania projektem to takie i takie”.

Jednakże, na podstawie wcześniejszych wyroków sądowych, można dostrzec pewną konsekwencję w tym, co użytkownik może zrobić, gdy dostawca narusza swoje obowiązki.

Jeśli dostawca naruszy swoje obowiązki, użytkownik może domagać się od dostawcy odszkodowania lub rozwiązania umowy. Jednakże, jeśli użytkownik również ma problem, dostawca może nie być uznany za odpowiedzialnego, lub może nastąpić kompensata za błąd, co może skutkować zmniejszeniem kwoty odszkodowania.

Z drugiej strony, jeśli użytkownik naruszył obowiązek współpracy, a praca nie została ukończona z tego powodu, dostawca może domagać się od użytkownika zapłaty równowartości wynagrodzenia na podstawie ryzyka (japoński Kodeks Cywilny, artykuł 536, ustęp 2) lub niewykonania zobowiązania.

Przypadek sądowy pokazujący obowiązki zarządzania projektem

Typowym przykładem wyroku, który wyjaśnia, czym są obowiązki zarządzania projektem, jest poniższy:

W poniższym przypadku, spór dotarł do sądu z powodu opóźnień w terminie dostawy i żądań podwyżki od dostawcy w projekcie rozwoju systemu. Może to być najbardziej typowy przykład tzw. “płonącego projektu”, gdzie spór o to, jak podzielić odpowiedzialność między użytkownikiem a dostawcą, prowadzi do sądu.

Pozwany, jako specjalista w dziedzinie rozwoju systemów, miał obowiązek zbudować system opisany w umowie o rozwój systemu komputerowego i propozycji systemu komputerowego, opierając się na swojej zaawansowanej wiedzy i doświadczeniu, i zakończyć rozwój systemu komputerowego do uzgodnionego terminu dostawy. Dlatego pozwany miał obowiązek postępować zgodnie z procedurami rozwoju, metodami i procesami pracy przedstawionymi w umowie o rozwój systemu komputerowego i propozycji systemu komputerowego, zarządzać postępem prac, starać się odkryć czynniki, które mogą utrudniać prace rozwojowe, i odpowiednio na nie reagować. Ponadto, rozwój systemu odbywa się poprzez konsultacje z zamawiającym, dlatego pozwany miał obowiązek odpowiednio zarządzać udziałem powoda, Narodowego Ubezpieczenia Zdrowotnego, w rozwoju systemu i wpływać na powoda, który nie posiada specjalistycznej wiedzy na temat rozwoju systemów, aby nie utrudniał prac rozwojowych (nazywane dalej “obowiązkami zarządzania projektem”).

Sąd Okręgowy w Tokio, 10 marca 2004 roku (Heisei 16)

Podsumowując powyższy wyrok, nie jest ważne, aby rozumieć szczegółowe sformułowania czy skomplikowane tło sprawy. Kluczowe jest to, że termin “obowiązki zarządzania projektem” jest używany dosłownie. Mimo braku sformalizowanych przepisów, widoczne jest dążenie sądu do ustanowienia wytycznych dla podziału odpowiedzialności prawnej.

Podsumujmy treść powyższego wyroku w prosty sposób i uporządkujmy go w formie punktów. “Obowiązki zarządzania projektem” oznaczają:

• Przeprowadzanie rzeczywistych prac zgodnie z wcześniejszym planem (procedury rozwoju, metody, procesy pracy itp.)
• Zarządzanie postępem prac, aby sprawdzić, czy przebiegają one płynnie
• Jeśli istnieją “czynniki utrudniające” uniemożliwiające płynne prowadzenie prac, odkrywanie ich i podejmowanie odpowiednich środków

Dodatkowo, w odniesieniu do powyższych trzech punktów,

• Nie tylko samodzielne wysiłki dostawcy, ale także odpowiednie wysiłki w zakresie komunikacji, takie jak regularne żądanie współpracy od użytkownika, są równocześnie realizowane

Możemy to podsumować jako ogólne określenie powyższych punktów.

Warto zauważyć, że rozwój systemu jest zazwyczaj zawierany w formie umowy quasi-mandatu lub umowy o dzieło. Umowa quasi-mandatu to, mówiąc prosto, umowa, która mówi: “Wykonaj pracę z odpowiednią precyzją w zamian za wynagrodzenie”, więc obowiązki zarządzania projektem mogą być postrzegane jako koncepcja, która jest wchłaniana w “precyzję itp.”, która powinna być osiągnięta.

Jednak, mimo że jest to temat dyskusji, uważa się, że obowiązki zarządzania projektem mogą wystąpić nawet w przypadku umowy o dzieło, która jest umową “wykonania rzeczy zgodnie z zamówieniem”. Powodem jest to, co już zostało powiedziane: niezależnie od tego, czy jest to umowa quasi-mandatu, czy umowa o dzieło, zarządzanie projektem jest ważne w rozwoju systemu, a dostawca powinien to robić.

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

Przypadek sądowy pokazujący obowiązki zarządzania projektem, które mogą być nałożone przed zawarciem umowy

Uważa się również, że obowiązki zarządzania projektem mogą być nałożone nawet na etapie przed zawarciem umowy. Poniżej cytowany przypadek sądowy pokazuje, że nawet na etapie przed zawarciem umowy, czyli podczas składania różnych propozycji i planów, strona dostawcy ma obowiązki zarządzania projektem.

W poniższym przypadku, projekt został przerwany w trakcie realizacji, a spór dotyczył tego, czy można uznać obowiązki zarządzania projektem na podstawie braków w planowaniu i propozycjach przed zawarciem umowy, a także wycenach i wyjaśnieniach dla użytkowników na etapie propozycji. Ogólnie rzecz biorąc, kwestia, czy takie obowiązki mogą być prawnie uznane, stała się problemem, ponieważ prace związane z planowaniem i propozycjami są na etapie przed zawarciem umowy, ale sąd uznał to.

Zasada obowiązków zarządzania projektem w cytowanym wyżej przypadku sądowym, która dotyczy również etapu przed zawarciem umowy, powinna być dobrze zrozumiała po przeczytaniu poniższego tekstu.

Na etapie planowania i składania propozycji, określane są ogólne ramy takie jak cele projektu, koszty rozwoju, zakres rozwoju i harmonogram, a także ryzyko związane z projektem jest ustalane zgodnie z tymi ramami. Analiza ryzyka i planowanie projektu, które są wymagane od dostawcy na tym etapie, są niezbędne do realizacji rozwoju systemu. W związku z tym, dostawca powinien na tym etapie badać i weryfikować funkcje proponowanego systemu, stopień zaspokojenia potrzeb użytkownika, metody rozwoju systemu, strukturę rozwoju po otrzymaniu zamówienia, itp., a także powinien wyjaśnić użytkownikowi ryzyko wynikające z tych kwestii. Takie obowiązki dostawcy dotyczące badania i wyjaśniania są uważane za obowiązki prawne wynikające z zasady dobrej wiary w procesie negocjacji przed zawarciem umowy, a apelant jako dostawca powinien ponosić takie obowiązki (obowiązki dotyczące zarządzania projektem na tym etapie).

Sąd Apelacyjny w Tokio, 26 września 2013 roku (rok 25 Heisei)

Należy zauważyć, że zasada, że istnieją pewne obowiązki prawne wobec drugiej strony nawet na etapie przed zawarciem umowy, jest zasadą, która istnieje od dawna, nie tylko w kontekście projektów IT, ale we wszystkich transakcjach handlowych i negocjacjach związanych z prawem.

Zwykle, im większa jest transakcja, tym dłuższy jest proces “zbliżania się” do celu, którym jest umowa. Nawet w tym procesie, powinno być oczywiste, że powinniśmy być uczciwi wobec drugiej strony, przynajmniej z moralnego punktu widzenia. Mówiąc prosto, takie rozmowy nie są tylko emocjonalnymi uczuciami moralnymi, ale mają również znaczenie prawnie. (Poniżej cytuję artykuł. Podkreślenie zostało dodane przez autora.)

Artykuł 1 ustęp 2 Kodeksu Cywilnego
Wykonywanie praw i spełnianie obowiązków musi odbywać się zgodnie z zasadą dobrej wiary i uczciwości.

Wydaje się, że kluczowe słowo “zasada dobrej wiary” w wyroku sądowym dobrze oddaje powyższe treści.

Należy zauważyć, że przypadek sądowy, który został opublikowany w tym artykule, ma pewne znaczenie jako “wytyczne do wyznaczania granic między obowiązkami współpracy użytkownika a obowiązkami zarządzania projektem ze strony dostawcy”. W sprawie obowiązków współpracy użytkownika w rozwoju systemów IT, proszę zobaczyć poniższy artykuł.

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

Podsumowanie: W przypadku problemów związanych z naruszeniem obowiązków zarządzania projektem, skonsultuj się z adwokatem

W tym artykule próbowaliśmy ogólnie uporządkować kwestię obowiązków zarządzania projektem w rozwoju systemów. Rozwój systemów wiąże się z różnymi wyzwaniami i problemami, ale kiedy napotykamy na takie sytuacje, wydaje się, że to, co staje się ważne, to “podstawy”, które są wspólne dla każdej sceny konfliktu. Bez wątpienia, istnieje nieskończona liczba wariantów dla każdej nieprzewidzianej sytuacji.

Jednakże, stawiając czoła takim sytuacjom, ważne jest zapytanie “Kto i w jakim stopniu początkowo przyjął prawną odpowiedzialność?”. Ta kwestia ma pewien rodzaj uniwersalności, która przekracza indywidualność każdego przypadku.

Zamiast skupiać się na doraźnym rozwiązywaniu problemów, wydaje się, że kluczem do dążenia do rozwiązania poprzez konstruktywne podział zadania jest prawo i precedensy sądowe.

W przypadku wystąpienia problemów związanych z naruszeniem obowiązków zarządzania projektem, skonsultuj się natychmiast z adwokatem.