How Far Should We Legally Implement Functions Not Specified in the System Development Specification?

In principle, IT system development projects used in companies are created in accordance with predefined specifications. However, considering the role of vendors as experts in system development, it may not be enough to simply mechanically implement what is written in the specifications. The expectations from the user side may not be that low. In this article, we will discuss to what extent developers should bear the responsibility for implementing programs that are not mentioned in the specifications, but are necessary in light of the purpose of development.

Legal Issues Associated with Implementing Unspecified Features

Discretion is Required in Vendor Operations

One of the major personalityistics of legal issues surrounding system development projects and associated contracts is that the vendor who takes on the work has significant discretion.

Related article: What are the project management duties in system development?[ja]

However, the ‘discretion’ mentioned here does not necessarily apply to all stages of system development. After identifying each process and breaking it down into detailed tasks, there may be many tasks that are close to simple work. However, generally, the more upstream the task, the more difficult it is to carry out the work without significant discretion. This is also why contracts often fit well with quasi-delegation in the upstream process.

Related article: The distinction and difference between contract and quasi-delegation contracts in system development[ja]

Discretion Should Also Be Exercised Within Strict Development Processes

However, even if the system development vendor has significant discretion, accepting client requests in an ad hoc manner can cause significant damage to later processes. An IT system is made up of a collection of small components, and even a minor change in appearance can require a significant change in man-hours from the developer’s perspective. Regarding the change of system development specifications, there are articles that explain how to manage the change situation from a legal perspective. The following article discusses how changes in specifications from the engineer’s perspective can have a significant impact on the work, as well as how to manage changes.

Related article: How to manage changes in system development from a legal perspective[ja]

What Should Be Done as a Specialist, Not Bound by Specifications?

For a smooth system development project, it is important to define the requirements of development in advance and proceed with the project in a planned manner. On the other hand, there are situations where you cannot fully fulfill your role as a system development specialist by just doing what you are told according to the pre-defined requirements. In such a dilemma, the question of “What should be implemented, even if it is not specified in the specifications?” becomes apparent.

Legal obligations are determined in accordance with the ‘purpose’ of specifications and contracts

The content of what should be implemented is determined from the ‘purpose’ of the items described in the contract or specifications, that is, ‘what meaning or intention was there when such an agreement was made’, even if it was not described in the contract or specifications. Let’s take a look at some case examples below.

Court Case Where Implementation Obligation Was Denied Due to Lack of Specification

In the court case cited below, a dispute arose when a vendor developed a system and progressed to the point of trial operation, but the user claimed that the necessary functions were lacking and sought to terminate the contract. The user claimed that the “automatic data update function” was lacking, and argued that this was a major selling point of the system in question, but the court did not recognize this implementation obligation.

As acknowledged above, there is no mention in the contract, basic design document, or detailed design document that the ③ function is a development target of the system in question.

The plaintiff argues that the ③ function was a major selling point of the defendant’s system to the plaintiff, and emphasizes the necessity of this function, but if this were the case, it should have been clearly stated in the contract, etc., and it is hard to believe that the development of this function was agreed upon without such a statement.

Tokyo District Court, February 18, 2009 (Heisei 21)

Indeed, if we simply extract the conclusion from this judgment, it could be said that “if it is not specified in the design document, you don’t have to create it.” However, to be more precise, it is not a matter of formal facts such as whether it is specified in the design document or not, but a judgment made in light of the “purpose” of the specifications in the design document and contract. In other words, “considering the reason why it was not specified in the design document or contract, it is reasonable to think that there was no agreement corresponding to that specification.”

Court Cases Affirming Implementation Obligations Even Without Explicit Documentation

On the other hand, there are court cases that have affirmed the obligation to implement, even if it was not explicitly stated in the contract or specifications. The following quoted case involves the development of a system for managing medication history. The user was unable to migrate data from the existing system to the new system, rendering the new system unusable, and thus terminated the contract. However, the vendor argued that data migration was outside the scope of their responsibilities, leading to a dispute.

Developing a new system often involves the removal of an existing system and the migration of data. The importance of these tasks and the legal issues associated with them are detailed in the following article.

Related Article: Legal Issues Associated with Transitioning from an Old System in System Development[ja]

More than 50,000 patient data were already stored in the existing system, and the plaintiff was using this data to streamline operations. It is clear that if the patient data cannot be migrated from the existing system to the new system, it will cause problems in the dispensing operations at the pharmacy. It can be assumed that the plaintiff’s representative was naturally aware of this. Before the contract was concluded, the plaintiff’s representative asked the defendant’s representative about the possibility of data migration, which the defendant’s representative also acknowledged. It is hard to believe that the plaintiff’s representative decided to introduce the new system, knowing that there was a high possibility that they would have to manually input data for more than 50,000 patients. Furthermore, as stated in (1) above, the defendant could not migrate the medication history data from the existing system to the new system, and had to print the data on paper and import it into a PDF file. It is hard to believe that the defendant would have undertaken such a laborious task as a service, even though data migration was not assumed in the contract.

Tokyo District Court, November 18, 2010 (Heisei 22)

What is important here is the “purpose” of the contract and the “intent” of the items documented in the contract. If both parties had entered into the contract with the understanding that data migration was outside the scope of the work, the court pointed out that it would imply that both the user and the vendor had entered into the contract with unnatural intentions. In other words, it would mean that the user had agreed to undertake a massive amount of manual work, and the vendor had embarked on the project knowing that it would cause problems for the user’s operations in the future, which is highly irrational.

What can be learned from both judgments

Even if there is no mention of data migration in the contract or specification documents, the obligation to implement it was affirmed. One of the reasons for this is that the issue was about “data”, which does not appear on the screen. The “lack of essential functions” mentioned earlier is something that directly appears on the system screen. Therefore, even if you are a novice in system development, it is not so difficult to find omissions in the specification documents. On the other hand, the issue of data migration has the personalityistic that it is difficult for novices in system development to recognize the importance of the process, the difficulty of the work, and the man-hours. Therefore, it is believed that there was also a situation where it was easily treated as a matter that the vendor side should manage smoothly with its expertise.

Considering this, the omission of specifications and contract documents can also be said to be a problem closely related to the user’s “obligation to cooperate”. In other words, it is a question of whether the user has really fulfilled the “obligation to cooperate” towards the conclusion of the contract and the creation of the specification documents. A comprehensive explanation of the legal obligations that users should fulfill in system development projects is detailed in the following article.

Related article: What is the obligation to cooperate borne b[ja]y the user side who is the orderer of system development[ja]

If you also check the above article, you will naturally understand that the story is quite different in the area where the user’s cooperation is required, such as the identification of screens and essential functions, and the omission of consideration for data migration.

How Should We Consider Compensation for Development Not Included in the Specifications?

Another point of interest related to the topic of this article is whether it is legally permissible to charge extra for creating something not included in the specifications. We have detailed explanations about the possibility of increasing compensation and how to calculate the estimated amount if possible in the following article.

Related article: Is it possible to increase the estimated amount of system development after the fact?[ja]

In the above article, we explain that it is important whether there were tasks beyond the scope of work related to the compensation and consideration. In other words, in relation to this article, if the vendor responds to the development of something not included in the original specifications (in this article, the negative example), it is possible to allow additional compensation claims.

Summary

In system development, the role of the vendor is determined, on one hand, by the contents of the contract and specification documents. However, considering that they are entrusted with tasks based on a high degree of trust as professionals, it is clear that their actual role is not solely determined by formalities. Nevertheless, it is important to understand that the law plays a significant role in understanding the true nature of their responsibilities.