What are the Cooperative Duties Borne by the User Side as the Orderer of System Development?

The task of system development, especially for large-scale systems, requires a significant amount of manpower and time. Therefore, not only the vendor who undertakes the development, but also the user who orders the system development, is obliged to cooperate to a certain extent.

This is different from the usual order and acceptance relationship. For example, when ordering a tailor-made suit from a suit shop, the customer (user) who places the order does not particularly bear any “obligations”. The “obligation” is primarily on the suit shop (vendor) who accepts the order. It is precisely because IT systems require a lot of manpower and time that users also need to “cooperate” with vendors.

In this article, we will explain the legal obligations of the ordering party in system development, which cannot be left entirely to the vendor.

When it Comes to Your Own System, You Can’t Just Leave it ‘All to Others’

Even in a single system development project, there are often many people and organizations involved. Not only engineers and programmers who are proficient in coding technology, but also project managers play a crucial role in consolidating the output of these personnel into a single achievement.

However, no matter how high the technical and organizational capabilities of the vendor side are, system development cannot be accomplished solely by the vendor’s efforts. For example, there is no way for the vendor side to know about company-specific jargon used only within the company or business knowledge unique to the company through one-way efforts. The larger the system development, the more likely it is that the company utilizing the system is a large corporation with many people and tasks. In order to lead the success of the system development project, it is often the case that organizing such business logic actually weighs heavily, even before computer work.

Therefore, instead of the user side becoming passive for the reason that “I am not an IT expert”, it is often the case that the project progresses smoothly by actively providing information. In this sense, the role that the user side is playing in the system development project is actually not small at all.

What is the User’s Obligation to Cooperate Based on Precedents?

So, what exactly are the obligations of cooperation that users bear in system development projects? There are many hints left in past precedents on this point.

In court, the issue was whether the user (plaintiff) had an obligation to cooperate in development, as there were delays in the vendor’s (defendant) delivery and delays in the user’s decision-making. In this case, the court recognized the user’s breach of the obligation to cooperate and denied the vendor’s liability for non-performance of obligations. (Although the cancellation of the contract was recognized, 60% of the fault offset was also recognized.)

In this case, the computer system development contract is a so-called custom-made system development contract, and in such a custom-made system development contract, the contractor (vendor) alone cannot complete the system, and the client (user) must accurately coordinate internal opinions during the development process, clearly communicate to the contractor what functions they want, discuss the desired functions with the contractor, finally decide on the functions, and further, decide on the screens and forms, and accept the deliverables, etc. It is necessary to share roles.

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

This judgment not only indicates that system development itself is a joint work with the user side, but also provides very suggestive points by stating “what points should be cooperated specifically”.

Let’s try translating the wording of the above judgment into IT terms for system development.

These can be organized in this way. All of these are things that cannot be done alone without the cooperation of the user, no matter how advanced the expertise in the IT system is. The functions and layout of the screen that are required are basically things that the user should clarify, and whether or not what is requested has been realized can only be confirmed by the user.

Moreover, just as the vendor is obligated to project management, the user is also obligated to cooperate. Therefore, if the user breaches the obligation to cooperate in the above process, it is conceivable that the vendor may claim damages from the user for non-performance of obligations or tort.

How are Requests for Post-hoc Specification Changes Interpreted?

Furthermore, assuming that system development projects are a collaborative effort between users and vendors, the discussion will evolve into more advanced issues. One such issue is, “If a user requests additional features or modifications after the fact, and this makes it difficult to meet the delivery deadline, whose responsibility is it?”

System development generally aims to proceed in a sequence starting with requirement definition, basic design, detailed design, manufacturing (program implementation), and testing, with the aim of minimizing any rework (commonly referred to as the waterfall model). However, in reality, rework often occurs in the process due to some circumstances, such as when it is revealed that there are deficiencies in the previous process.

In such cases, how should we think if we cannot meet the delivery deadline? Reading past precedents, it seems that the conclusion may vary depending on when the additional work occurred.

When Additional Work Occurred Before the Clarification of Specifications Such As External Design

The aforementioned precedent indicates that there is nothing wrong with raising such requests during the basic design phase (before the program implementation stage).

It is natural for users to make various requests to vendors about the system to be built during the basic design work in a system development process like this case, and moreover, it is difficult for the plaintiff user, who lacks specialized knowledge, to accurately judge whether such requests require additional fees or extensions of delivery deadlines, or whether they cause problems in the work process. Therefore, it cannot be said that the plaintiff user should have refrained from making requests that would result in additional fees or extensions of delivery deadlines. Rather, if the plaintiff user made requests that required additional fees or extensions of delivery deadlines, the defendant, who has a project management obligation, should have informed the plaintiff user of this and sought discussions on the withdrawal of requests or extensions of delivery deadlines, etc., so as not to cause problems in the development work.

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

In this judgment, it was indicated that while affirming that there is a certain obligation of cooperation on the user side, the user is not a specialist in system development and should be considered. In other words, it is not strange for users who are not experts in system development to make orders in bits and pieces until the content of the system to be developed becomes clear (and in some cases, they may not even be used to placing orders), and it is harsh to say that they should “notice on their own” when the content of their orders requires a review of the delivery deadline, etc.

However, the obligation imposed on the vendor here is essentially to make efforts to communicate, such as requesting an extension of the delivery deadline (or, if the deadline cannot be moved, suggesting that the additional request itself be withdrawn). Therefore, it is not meant to include the obligation to accept all user requests and deliver by the original deadline, so caution is needed on this point.

When Additional Work Occurred After the Specification Confirmation of the Manufacturing or Testing Process

If you reverse the content of the above judgment, you can predict to some extent what conclusion would have been reached if it was additional development after the specifications had already been confirmed. In that case, such requests would be difficult to pass. Indeed, the gap in understanding of the development work between the user side and the vendor side does not change whether it is before or after the specification confirmation.

However, changing or adding order content after the specifications have been confirmed is likely to force a redo of the work. In many cases, it is difficult to defend the delay in delivery that occurred even in such cases by saying, “It is natural for customers to make various requests.” Furthermore, a situation where many specification changes and additional functions occur after the fact raises the question of whether there was a breach of the cooperation obligation on the user side in the upstream process such as basic design that should have already been completed in advance.

From these points, it is realistic to think that it is not the vendor’s responsibility to delay the delivery due to specification changes made after the specifications have been confirmed once. It is reasonable to read the above-mentioned judgment text in such a way that it also has such implications.

Also, such judgments tend to be made based on evidence such as minutes adjusted to the progress of system development, not just contracts. Details about the minutes are explained in the following article.

Summary: It’s Crucial to Remember that Requirement Definition is a Process on the User’s Side

While requirement definition is a showcase of the vendor’s skills, it’s important to remember that it is fundamentally a task on the user’s side. Even if the system is built with the help of external experts, it is legally considered to be under the governance of the company that uses it, and should be within its rightful jurisdiction.

If the user side is not cooperative in the development process, there is a high possibility that the court will take a strict view against the user side, even if the project goes up in flames. This point should be recognized first and foremost.