The Relationship Between Delays in System Development Delivery and Legal Breach of Contract

In a sense, system development projects are always a battle against deadlines. From a legal perspective, we can consider the risks that become apparent in the event that a deadline is not met in system development.

In this article, we will explain when such ‘delays in delivery’ are treated as performance delays, and when they result in legal liabilities such as non-performance of obligations.

What is the Delivery Date in System Development?

Delivery Date in General Terms

The term “delivery date” generally refers to the deadline for delivering a product requested by a customer. Even in the development field, where unexpected troubles can occur, it is often required to strictly adhere to the delivery date. In situations where there is a power imbalance between the orderer and the contractor, the tendency to strictly adhere to the delivery date is often more pronounced. Alternatively, if the delivery is delayed, there may be cases where discounts are applied according to the excess, or the excess work is not charged and made free of charge. In any case, the delivery date is generally considered important for maintaining trust with business partners.

We also explain the legal concept of “completion of work” and delivery dates in another article.

https://monolith.law/corporate/completion-of-work-in-system-development [ja]

Delivery Date from a Legal Perspective

From a legal perspective, as soon as a contract is made between the vendor and the user, the vendor has an obligation (debt) to deliver the system. The delivery date can be said to be a restriction on when this obligation should be fulfilled. In other words, a delay in the delivery date can be considered a type of breach of obligation, or a delay in performance. Therefore, if the delivery date is delayed due to the vendor’s intentional or negligent actions, they will be liable for breach of obligation due to delay in performance (Japanese Civil Code Article 412).

1. When there is a definite deadline for the performance of an obligation, the obligor shall be liable for delay from the time the deadline arrives.
2. When there is an indefinite deadline for the performance of an obligation, the obligor shall be liable for delay from the time he/she becomes aware that the deadline has arrived.
3. When no deadline has been set for the performance of an obligation, the obligor shall be liable for delay from the time he/she receives a demand for performance.

Japanese Civil Code Article 412

The “liability” mentioned in this article simply refers to liability for damages.

If the obligor does not perform in accordance with the main purpose of the obligation, the obligee may claim compensation for the damage caused thereby. The same shall apply when the obligor becomes unable to perform due to a cause attributable to him/her.

Japanese Civil Code Article 415

Furthermore, if the user sets a “reasonable period” and demands delivery by that date, but the vendor does not deliver, the contract can be cancelled.

In the case where one party does not perform its obligation, if the other party sets a reasonable period and demands performance, and there is no performance within that period, the other party may cancel the contract.

Japanese Civil Code Article 541

For a general explanation of the option of “cancellation” in such cases, please refer to the following article.

https://monolith.law/corporate/cancellation-of-contracts-in-system-development [ja]

Not All Delivery Delays Constitute Legal Breach of Contract

However, the superficial fact of “not meeting the deadline” does not necessarily mean a delay in performance as a breach of contract. For a mere delivery delay to become a legal delay in performance, it must meet several conditions as shown below.

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

Given that system development is typically a project where both the user and the vendor have obligations, there may be cases where both the vendor and the user are found to have breached their obligations, and damages are offset, leading to a resolution.

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

Adding to this topic, what usually happens close to the delivery date is the “acceptance” of the deliverables. We cover the topic of acceptance in detail in the following article. Here, we explain cases where delivery is not completed because the user does not comply with the acceptance.

https://monolith.law/corporate/estimated-inspection-of-system-development [ja]

The key point of the discussion is that the issue is not as simple as “not meeting the deadline equals breach of contract”. Even when we talk about a delay in delivery, the reasons can vary, from being the vendor’s fault to being the user’s fault. There is a significant gap between the formal fact of “delay in deadline” and the substantial breach of obligation that constitutes “delay in performance”.

Court Cases Regarding Delay in Performance

Let’s look at court cases where it was disputed whether it was possible to pursue liability for non-performance of obligations based on a delay in delivery. Although these are disputes over delivery dates, the essence of the matter, whether it is the “user’s obligation to cooperate” or the “project management obligation”, does not change from other disputes, and it is important to organize the case based on the basics of system development.

Case where delay in performance was offset by violation of user’s obligation to cooperate and negligence

In the case of the judgment quoted below, the user initiated a lawsuit because the vendor’s delivery was delayed. This claim was partially accepted in court, but at the same time, it was indicated that the lack of appropriate cooperation on the part of the user was also a factor, and 40% of the damages due to the delay in delivery were the responsibility of the user.

As a result of the above considerations, it can be said that the plaintiff user did not make timely and appropriate decisions, such as not resolving the issues raised by the defendant by the target deadline, and thus did not provide appropriate cooperation. However, the defendant’s claim of violation of the obligation to cooperate in relation to the plaintiff user’s request for additional or changed functions cannot be accepted, even though it is recognized that the plaintiff user made a request that resulted in additional or changed development content as anticipated in the basic design document of this case. It cannot be said that this constitutes a violation of the plaintiff user’s obligation to cooperate, and the defendant’s claim is without reason. Also, the defendant’s claim of violation of the obligation to cooperate in relation to the plaintiff user’s excessive demands cannot be accepted, as it cannot be recognized that the plaintiff user made excessive demands in light of the commission fee for the computer system development contract and other contracts. Rather, it can be said that there were inappropriate points in the defendant’s project management, such as the fact that the defendant became aware of the number of processes (the number of “processes” as of July or August of the same year) after January of Heisei 11 (1999), and that the defendant made a request for additional commission fees with inappropriate content or a reduction in processes after May 31 of the same year.

Tokyo District Court, March 10, Heisei 16 (2004)

The above judgment recognized the delay in performance due to the vendor’s delay in delivery, but also recognized that part of the cause was the user’s failure to resolve concerns raised by the vendor, and accepted the user’s claim by “cutting” 60% of the damages claimed by the user. This is a process of “offsetting negligence”, similar to a traffic accident where the victim is also at fault.

In this judgment, the term “obligation to cooperate” appears more than 40 times in the entire text, including the table of contents. From a legal point of view, the essence of the matter could be said to be the distinction between the vendor’s project management obligation and the user’s obligation to cooperate.

Case where delay in performance was fully recognized

The following is a judgment of a case where the vendor’s responsibility for the delay in delivery was fully proven, and the liability for non-performance of obligations due to delay in performance was recognized. In this case, the user terminated the contract just before the completion of the system, and the vendor initiated a lawsuit, but the user argued that the delay in delivery was the cause.

It cannot be denied that the defendant made various changes to the design system, and as a result, the completion was delayed to some extent. In particular, the defendant made a final change instruction on June 23, Heisei 17 (2005), so it is recognized that the function of “automatic calculation for the detailed items of the curbstone” based on that instruction is not completed, and it cannot be attributed to the plaintiff. However, other changes instructed by the defendant were made by early April of the same year, and it is recognized that there were no circumstances that should be interpreted as changing the schedule to complete the design system (excluding the part due to the defendant’s change instruction on June 23 of the same year). It is recognized that the plaintiff had not completed the design system to the extent that it could actually be operated as of the end of June of the same year, excluding the part due to the change instruction on June 23 of the same year, and that important parts of the system, such as the inability to display images or the search function not working, were incomplete. (Omitted) It can be inferred that the plaintiff did not adequately manage the work procedures associated with system development. Therefore, it cannot be recognized that the main reason why the plaintiff could not meet the delivery date was due to the defendant’s instructions, and it cannot be recognized that there are no reasons attributable to the plaintiff.

Tokyo District Court, February 16, Heisei 19 (2007)

In this judgment, it was indicated that the part of the function that was not completed due to the specification change instruction given about a week before the delivery date cannot be attributed to the vendor. However, considering the following points,

• The vendor has not yet responded to the change instructions issued several months ago
• After the above instructions were issued, the vendor sent an email stating the expected completion date
• The unfinished parts are important parts of the system, such as the implementation of image display and search functions, and the fact that they have not been responded to is an element that supports the violation of the project management obligation

it was recognized that there was a breach of obligation due to delay in performance.

What can be learned from the contents of both judgments

Considering both judgments, the issue of “delivery date” in system development can ultimately be said to be a matter of how to draw the boundary between the user’s obligation to cooperate and the vendor’s project management obligation. In other words, since the legal delay in performance is a type of liability for non-performance of obligations, whether or not there has been a breach of obligation on the part of the vendor naturally becomes a point of contention. And in order to examine whether the damage fact that has become apparent as a result (i.e., the loss on the user side that occurs with the delay in delivery) can be attributed to the vendor, it is necessary to consider how to interpret the user’s obligation to cooperate at the same time.

Summary

At first glance, the term “performance delay” may seem like a mere rephrasing of the formal fact of “delivery delay” due to its connotation. However, performance delay is a type of breach of obligation. Therefore, it is more appropriate to understand it as a “violation of project management obligations”.

When it comes to the issue of “delivery date” in system development projects, it is important not to be caught up in the superficial timing of delivery, but to reframe it as an issue of the vendor’s project management obligations and the user’s duty to cooperate.