What are the Laws Related to the Departure of Members from a System Development Project?

In system development projects, it is typically emphasized to break down each process and task and proceed with as much planning as possible. However, no matter how much we prioritize planning, there are troubles related to ‘people’ that are inevitable, such as sudden troubles. In particular, risks such as sudden illness or resignation of project members may be unavoidable, no matter how much effort is put into follow-up. In this article, we will explain how the law is involved in relation to the departure of project members.

Member Departure as a Specific Issue of Project Management Obligations

Firstly, it is generally understood that in a system development project, the vendor has a comprehensive obligation to ensure smooth progress. This includes estimating the necessary personnel, duration, budget, and man-hours for the project, seeking necessary cooperation from the user as needed, and managing the progress of the project. These obligations are referred to as “project management obligations,” and their existence has been pointed out repeatedly in past court cases.

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

The sudden departure of a member on the vendor side can be considered a type of issue related to the vendor’s project management obligations.

• Physical discomfort due to excessive overtime and working on holidays
• Psychological stress due to interpersonal conflicts

Various factors can cause sudden departures in a project. However, these are fundamentally issues related to the vendor’s labor management. Therefore, even if such circumstances result in delays in delivery, the possibility of exempting the vendor from breach of obligations is low. In other words, the vendor is expected to anticipate such sudden vacancies and manage the progress of the project with a planned approach.

Significant Case Law Regarding Member Withdrawal

Case of Project Delay Due to Member Withdrawal

The case cited below involves a project delay following the sudden withdrawal of a member. In this case, the user’s representative had been taking an intimidating attitude towards the vendor’s representative, which also imposed psychological stress.

The user, who wanted to pursue liability for non-performance due to delay, and the vendor, who wanted to pursue the user for breach of cooperation obligation due to their high-pressure and intimidating attitude, were entangled in a fierce dispute.

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

However, the court ruled that various circumstances did not exempt the vendor from its project management obligations and supported the user’s view (the underlined and bold parts are added by the author).

The vendor claims that the user’s representative verbally abused the vendor’s representative with aggressive and high-pressure behavior, forcing the vendor’s representative to withdraw from the project.

Indeed, it is acknowledged that the user’s representative said in a strong tone at a meeting around November 2003 (Heisei 15), “Are you not motivated?“, “This contract is over. It’s over when I leave this room.” However, this was due to the vendor’s delay in work and its response, as the additional features of the development purpose were not included in the requirement definition document draft, despite the prototype period being set to end by October 2003 (Heisei 15) in the basic agreement. Even when comments were added to the submitted requirement definition document draft, there was no response. It cannot be said to be excessive behavior.

As for C’s withdrawal from the contract work due to illness, the cause is not clear, but even if the stress from the contract work was the cause, it should be considered a labor management issue on the vendor’s side. It cannot be attributed to the user.

Tokyo District Court, December 4, 2007 (Heisei 19)

In the above case, the court did not exempt the vendor from its responsibility, even after considering the fact that the user had pressured the vendor with a “strong tone”. It is believed that there were circumstances such as the lack of fairness in attributing blame to the user who had pressured with various “strong tones”, considering the balance with the poor response of the vendor. It was decided that there was no breach of the cooperation obligation by the user, adopting the scheme that the entire system development project is established by the fulfillment of the project management obligation by the vendor and the fulfillment of the cooperation obligation by the user. This should be seen in the phrase, “it cannot be said to be ‘excessive behavior'”.

What Can Be Learned from the Above Case Law

Furthermore, we can learn important lessons such as the following:

• When considering attributing blame to the user side for the withdrawal of a project member due to illness, the vendor side is required to prove the causal relationship that the withdrawal was due to the user → However, it is generally considered difficult to prove a causal relationship.
• Even if it can be proven that the workload increased due to the user and the member became ill, it is usually considered a labor management issue on the vendor side → If the phrase “excessive behavior” is used in the judgment, it should be considered that the situations that exempt the vendor’s labor management responsibility are quite limited.

Preparing for the Risk of Member Departure

As mentioned above, even if a sudden vacancy occurs in the personnel, it is extremely difficult to attribute this to the user’s side. It is possible that you may be forced to undertake massive additional development or be forced to make drastic specification changes later on. However, it is not easy to prove the causal relationship between physical and mental disorders and various workloads. Given these circumstances, it is important to prepare a personnel system on the assumption that troubles such as sickness absence and poor health of project members may occur.

If this point is disputed in court, it is clear that the vendor side will be at a significant disadvantage. Therefore, it is important to take measures to prevent such disputes. Possible measures include the following:

Establish a system that does not isolate the person in charge

By creating a system where multiple people participate in meetings instead of one person, it is believed that it can prevent the situation where the person in charge feels psychologically isolated.

Ensure a sufficient personnel arrangement

It is also important to have a margin in personnel arrangement. While securing personnel with a margin certainly leads to an increase in costs, if you consider the cost of damages due to delivery delays and the concern of further departures in such trouble handling situations, it is often more rational to secure personnel with a certain margin from the beginning.

Review the arrangement before the health condition worsens

If one person leaves, the workload of other personnel increases, which may lead to a vicious cycle of further departures. To avoid such a vicious cycle, it is important to review the arrangement before the health condition seriously deteriorates.

Thoroughly manage project changes and document management

It is not easy to prove the causal relationship between team member departure and the violation of the user’s cooperation obligation, but it is still important to thoroughly manage specification changes and document management. This is because even if the cause of the team member’s departure cannot be proven, if there is indeed a situation of excessive work that leads to the absence of the person in charge, there is a possibility that it contains elements that support the violation of the user’s cooperation obligation. These circumstances can serve as elements to justify offsetting negligence, even if the vendor is pursued for breach of contract or warranty liability in the event of a project “burnout”.

The following article explains the importance of document management in system development projects.

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

For a more detailed discussion specifically on specification changes, please refer to the following article.

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

Conclusion

We have discussed the legal implications of the phenomenon of “team member departure”. It is undeniable that it is extremely difficult from a legal standpoint for vendors to hold users accountable for the departure of members.

However, even with such circumstances, it is important not to misunderstand that “legal discussions are useless in the case of team member departures”. The thought process of the case examples we presented itself questions how to define the boundary between the “vendor’s project management obligation” and the “user’s cooperation obligation”. Moreover, measures to prevent such disputes are often derived by working backwards from the anticipated dispute situations.

It is important to understand that the point of “being at a disadvantage in a lawsuit” should not be interpreted as “law is useless”, but rather that “the perspective of preventive legal affairs is important”.