Post-development Support Obligations of a Software Company for a System Development Project

In the field of system development, it is well known that software companies, who are specialists in system development, bear a “Project Management Obligation”. However, a similar but distinct concept in law is the “Support Obligation”. In this article, we will explain this “Support Obligation”, taking into account past court cases and other factors.

What is the Support Obligation?

Overview of the Support Obligation

In the context of obligations that a vendor owes to a user, the obligation of project management is a typical example. This obligation has been established through repeated references in past court precedents and encapsulates the responsibilities that the vendor, as a system development expert, bears for a series of projects.

The obligation of project management is a very well-known legal term in the field of system development, and there is no doubt that it is a primary obligation that the vendor undertakes. However, some court precedents recognize the existence of an obligation called the “support obligation,” which is different from the obligation of project management.

The Support Obligation Becomes an Issue in Operational Support for Users

So, what is the support obligation? And why is it called by a different name than the obligation of project management? The support obligation usually becomes an issue after the development of the system is completed. A system development project, being a “development” project, essentially ends when the system to be created is completed. That is, a system development project begins with clarifying what the system to be created is (i.e., defining requirements) and ends with confirming whether it has actually been completed (i.e., testing or acceptance).

Even if we consider a system development project to focus solely on creating a new system, it’s implicitly understood that the developed system will be put to use in subsequent business operations. Ignoring how the system will be utilized after its development and claiming that “as long as it’s built, that’s enough” can potentially lead to significant inefficiencies. Bearing this in mind, past legal precedents in Japan have raised the question of whether vendors responsible for system development should also have some obligations related to operational support after the system’s completion. In other words, the issue is whether the obligations that vendors bear under a system development contract should also include duties related to post-development operational support. It’s important to note that because operational support is not part of the development process itself, the term “support obligation” has been used to distinguish it from project management responsibilities.

What are the Court Cases Where the Support Obligation was an Issue?

Case Where the User’s Business Operation was Hindered at the System Test Stage

In the court decision quoted below, the user was unable to utilize the system as initially anticipated during the system test conducted before the system went live, resulting in the user ultimately giving up on the operation of the system. This case involved trouble at the time of the user’s operation start, and the issue was how to justify the vendor’s responsibility based on the contract for system development that had been previously agreed upon. The conclusion was that the user’s claim for damages was recognized, and the basis for this was identified as a “violation of the obligation to provide support”.

I Violation of the obligation to provide support
(A) The plaintiff’s representative requested the defendant on July 14, 1997 (Heisei 9), “Not only to create the system, but also to take care of it until it runs properly.“, “We are amateurs, so we are paying a lot of money, so we want you to make it usable until the end.“. In response, the defendant explained that it was possible to build a system that could achieve the plaintiff’s introduction objectives and promised to support until it could be used properly. As a result, an agreement was established between the plaintiff and the defendant that the defendant would support until the plaintiff could use the system properly.
It is clear that the defendant has an support obligation the plaintiff, as it has charged a cost of 1,726,000 yen for “package introduction support” as the price of this contract, and the estimate states that the monthly maintenance fee is “free maintenance for six months after introduction”, and the document titled “About future SE support (internal meeting materials)” confirms that SE support can be received for “creation of introduction procedure (plan)” and “data/operation verification work” for fresh order.
(B) The support obligation that the defendant owes to the plaintiff specifically refers to at least until the plaintiff reaches the full operation of this system, the defendant provides the plaintiff with ①appropriate advice on the operation method of this system, ②attendance at the operation test and response to system problems that occurred in the operation test, ③improvement of the system according to the results of the operation test, ④introduction education for operators.
However, the defendant, despite the frequent troubles in the operation test, did not respond sincerely, claiming only the cost of introduction education for operators, and did not provide any appropriate support to the plaintiff for full operation.

Tokyo District Court Hachioji Branch, November 5, 2003 (Heisei 15) decision

In this court decision, the word “support” appears about 30 times throughout the text, including the table of contents. The user’s voice demanding appropriate support is directly recorded in the court decision, and it can be inferred that the conclusion was reached after carefully considering the course of the case and aiming for a fair resolution. Particularly noteworthy points in understanding this case are:

• The violation of the obligation to provide support is treated as “non-performance of obligations”, and as a result, damages resulting from it were ordered.
• The term “project management obligation” is not used even once throughout the court decision.

While it is a concept separate from project management, there is an attitude to treat it as a contractual obligation included in the contract for system development.

How Should We Understand the Nature of Support Obligations?

The Concept of Support Obligations is Not Yet Clear

The aforementioned court case essentially indicates that vendors who develop systems should also provide the necessary support for users to start operating. However, the concept of support obligations is not as well-established as project management obligations, and there are not many clues to understand its actual state. In particular, the term “support” itself includes the problem of not clearly understanding what specifically should be done.

Support Obligations are Not Unlimited

Furthermore, the judgment that recognized the vendor’s breach of support obligations also pointed out a very important point.

The defendant is understood to have an obligation to provide a certain level of support necessary for the plaintiff to operate the system built and delivered to the plaintiff based on this contract. However, it is not understood that the content was such that, as the plaintiff claims, it provides all support for free until the plaintiff can actually operate this system, without limiting the period.

Tokyo District Court Hachioji Branch, November 5, 2003 (Heisei 15)

If the main task undertaken is system “development”, it can be considered that there are naturally restrictions on what should be done as support for subsequent “operation”. In this judgment, there are several personalityistic points, such as quoting the voices of users seeking support in the judgment text, mentioning the contents of the previous estimate, and touching on the presence or absence of special contracts to provide support. In other words, considering that the concept of support obligations would impose a heavy burden on the vendor side if it expands indefinitely, it is believed that the recognition of breach of obligations itself was intended to be somewhat cautious.

The Reality of Support Obligations Should be Considered Along with the User’s Obligation to Cooperate

In short, the discussion so far can be said to be about “how users and vendors share the workload in the initial stage of operation in system development”. Certainly, there are somewhat difficult problems included, such as how much legal obligation the vendor bears at the start of operation from the contract related to “development”. At the same time, it is undeniable that there is a strong tendency to require judgment based on individual circumstances.

However, it is believed that understanding what the reality of the support obligations that the vendor bears will become more certain by understanding the cooperation obligations that the user bears.

After all, the effort to improve operations with a new system has an aspect of being a joint work of the vendor, who is a technical expert, and the user, who has knowledge of in-house operations. Therefore, it is often the case that the range of what is called support obligations is naturally determined by clarifying the matters that the user should solve with self-help efforts as part of the “performance of cooperation obligations”.

Summary: Support Obligation in Post-Development of a System Development Project

In this article, we have discussed the concept of ‘support obligations’, which can be considered a derivative of project management after development, based on the fundamentals of project management. Although there are still many ambiguities in the concept of support obligations, it is believed that the understanding of basic matters such as ‘project management obligations’ and ‘duty to cooperate’ is still important.