What are the Remedies When System Development Work is Interrupted Due to User Circumstances?

System development tasks often take the form of long-term projects. What can be done from the vendor’s perspective if a user unilaterally declares, “We no longer need that system, so you don’t have to build it,” after the system development has already begun?

In this article, we will organize the unique personalityistics of system development contracts and explain the measures to be taken in such cases.

The Significance of Considering Interruptions Due to User Circumstances

There are several distinctive features when looking at system development contracts. One of these is that the project period is usually long, and the vendor side has a significant amount of discretion and responsibility in managing the project. The overall content of the project management obligations borne by the vendor side is explained in detail in the following article.

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

Another point is that the user, even though they are the client, has a broad obligation to cooperate with the vendor’s operations. Since it is a system used internally, it cannot be completely left to the vendor. There is an obligation to cooperate appropriately from within the company so that the vendor can demonstrate their expertise and work on the project. This is explained in detail in the following article.

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

To summarize the above, there is a relationship between the vendor and the user that involves both a “contractor” developing the system and a “client” paying for it, but at the same time, there is also an aspect of being “partners” who should collaborate towards the common goal of project completion. This complexity of relationships is not usually found in simple custom-made suit tailors, and is a major personalityistic of contracts related to system development. Disputes related to system development tend to become complicated due to this complex relationship, and once entangled, it can be tricky to legally sort out the relationship between the two parties.

Considering the issue of how to understand the rights and obligations of both parties when the user side suddenly changes their mind and says, “We no longer need that system, so you don’t need to proceed with the project anymore,” has the implication of presenting a practical example of legal thinking in the face of such complex contractual relationships. Below, we will organize the matters to be considered afterwards, assuming such a case.

First, Clarify the Reasons for the Termination Request

From the vendor’s perspective, there may be cases where the user unilaterally wants to suspend the project. However, such understanding may not necessarily be shared with the user. For instance, consider a scenario where a project was initiated to develop a system to manage the personnel of expatriates working at overseas bases, but later the plan for overseas expansion itself was withdrawn, making the development of such a system unnecessary. Indeed, based on this explanation alone, it could be interpreted as a unilateral change of mind on the user’s side.

However, what if there were circumstances leading to such a decision, such as the vendor’s breach of project management obligations, including delays in each process, and the difficulty in progressing the development itself, which also contributed to the company’s policy change?

As mentioned earlier, system development involves both the vendor and the user bearing significant responsibilities and progressing in close collaboration. Therefore, even if the user initiated the desire to suspend and the vendor considered it a termination due to the user’s convenience, it should be recognized that there is a possibility of being countered with claims such as it being a cancellation based on non-performance of obligations or a mutual termination due to the vendor’s attributable cause.

Whether it is a termination due to personal convenience, a cancellation based on non-performance of obligations, or a mutual termination, the distinction tends to be judged individually for each case, depending on the progress of the project and the history of negotiations. Therefore, if the vendor proceeds with post-processing under the understanding that it is a termination due to the user’s convenience, it is important to clearly record this in meeting minutes and other documents to prevent disputes over this point later on.

Next, Confirm the Basis for Claims for Remuneration and Damages

With the above points in mind, if the discussion can proceed as a user-initiated cancellation, the next step is to consider whether the vendor can claim remuneration according to the completion rate or claim damages from the user.

The articles to be referred to in such cases vary depending on the type of contract. This is because contracts related to system development can be broadly divided into contract work and quasi-mandate contracts.

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

And in the case of quasi-mandate contracts and contract work, the Civil Code (Japanese Civil Code) provides the following provisions:

a.) In the case of a quasi-mandate contract
Claim for remuneration: Civil Code Article 648, Paragraph 3
When the mandate ends midway through performance due to a cause that cannot be attributed to the acceptor, the acceptor can claim remuneration according to the proportion of performance already made.
Claim for damages: Civil Code Article 651
1. The mandate can be cancelled by either party at any time.
2. If one party cancels the mandate at a disadvantageous time for the other party, that party must compensate the other party for the damage. However, this does not apply if there is an unavoidable reason.

b.) In the case of a contract work
Claim for damages: Civil Code Article 641
As long as the contractor does not complete the work, the client can cancel the contract at any time by compensating for the damage.

Furthermore, the scope of damages based on Article 641 of the Civil Code is considered to include not only the costs already incurred but also the “profits that would have been obtained if the contract had not been cancelled”. This reflects the idea that it is more rational to guarantee the profit of the contractor by paying the same amount of consideration, as it is meaningless for the law to force the completion of work that has become unnecessary from the client’s point of view.

However, it is not uncommon for damages based on Article 641 of the Civil Code to be excluded from the individual contracts between the vendor and the user. In such cases, the individual promises made between the parties (= contracts) take precedence, and it is possible that these provisions of the Civil Code will not apply, so caution is required.

Further Advancing the Proof of Work Completed and Damages

In cases where the user cancels the contract due to their own circumstances, it is common for the contract to stipulate that they can claim for the commission of the work completed (i.e., the completed portion) and for damages. Therefore, it is usually necessary for the vendor to provide evidence of the work completed and the damages in order to make a claim for damages.

However, proving the work completed, or the percentage of completion, can be a daunting task. This is because, especially when there are multiple subcontractors, it is expected that a considerable amount of work will be required to conduct hearings for progress checks and to determine the extent to which each work item has been completed. Furthermore, creating documents to support the results of these hearings and documenting the content of the hearings themselves can be a massive undertaking. There are also many challenges, such as the risk of being told that the evidence is insufficient even after all this effort, which could render all the work put into preparing the evidence fruitless.

Considering these points, measures such as specifying from the outset at the contract stage that if the contract is cancelled midway, the calculation will be prorated based on the number of days up to the point of cancellation, can be considered. This would simplify the calculation process. Also, considering the effort required to prove the work completed, another approach could be to abandon claims for the work completed itself and instead consider claiming for the ‘costs incurred for the development of the parts already completed’. This is often easily calculated using a simple formula of ‘man-hours x unit price’ if the development costs are internal. Especially for projects with low profit margins, prioritizing claims based on cost rather than work completed can make debt recovery easier and provide a more realistic remedy by compensating for losses.

What Should Users Consider?

On the other hand, there are points that users should consider in advance when they initiate a termination due to their own circumstances. One of these is to check an approximate amount of damages that they are likely to pay to the vendor. The reason for using the term “approximate” here is to set a rough guideline for the flow of subsequent negotiations (since delaying the expression of intent to terminate would be putting the cart before the horse, an exact amount is not necessary).

If the confirmed approximate amount is deemed excessively high, you should ask for an explanation. However, if you try to negotiate unreasonably to reduce the payment amount, there is a risk that unnecessary lawsuits and further complications may arise. If negotiations between the two parties seem difficult, consulting with a lawyer may be an option.

While this article has been explained on the premise that a contract for system development is in place, in the actual scene of system development, there are not a few cases where it is disputed whether the contract has been effectively established in the first place. Details on this are explained in the following article.

https://monolith.law/corporate/system-development-contract[ja]

Summary

In this article, we have explained the process of dealing with cases where a project is interrupted due to user circumstances. However, the main point of this article is that it is necessary to consider whether it can truly be said that the interruption was due to the user’s own circumstances, and whether the vendor was really at fault.

Both the vendor and the user bear significant responsibilities in a system development project. Given this, it is crucial to carefully consider in advance whether it is truly possible to unilaterally attribute blame to the other party. If not, it could potentially add fuel to the fire, a situation that should be kept in mind.