In a system development project, user cooperation is not merely based on “please” or “expectations.” It is a legal obligation rooted in a contract, and failure to fulfill the project poses a serious risk that could lead to the project being ruined and lead to liability for damages of several million yen. Despite agreeing to freeze specifications, the company continues to make requests for additional requests one after another. Alternatively, neglecting to provide information about the current system, which is a prerequisite for development, or to prepare master data. Furthermore, the act of continuing to refuse inspections on the completed system without reasonable reason. All of these can violate the “duty of cooperation” that users should fulfill.
This article explores two important court cases that remain in the history of system development: the hospital information system development case that was contested between Asahikawa Medical University and NTT East Japan, and the sales management system development case in which the Tokyo High Court declared that it was default on users’ refusing to inspect them. These decisions provide a very clear picture of what the obligation to cooperate specifically means and what the violation will lead to. We will unravel practical knowledge that development personnel can use in all aspects, from contract negotiations to project management to response to conflicts in the unlikely event, through the facts and logic of cases of precedents.
The Deep in the Project Failure – Timeline and Lessons Learned from the Asahikawa Medical University Incident
Table of Contents
- The Deep in the Project Failure – Timeline and Lessons Learned from the Asahikawa Medical University Incident
- Two aspects of the obligation to cooperate: “Article” and “Operation” recognized by the court
- The default on “Refusal to inspect” – User’s responsibility indicated by the sales management system incident
- Designing contracts to prevent conflicts – A clear culture of cooperation obligations from the JEITA model
- Lessons from precedents to be used in practical work: the boundary between “cooperation” and “violation”
- Summary: To make the obligation to cooperate with the trinity of “clauses, operation, and evidence”
In understanding the importance of the obligation to cooperate in system development, there is no other case that can provide more scathing lessons than the Asahikawa Medical University incident. This incident was a shocking conclusion, in which a complete breach of the user’s obligation to cooperate was ultimately recognized, and damages of approximately 1.5 billion yen were ordered. Following the process leading up to that decision in chronological order highlights why and how the project went into ruin.
The incident began in 2008 when Asahikawa Medical University, a national university corporation, decided to introduce a successor system due to the expiration of maintenance of the existing hospital information system. As a result of the bid in August of the same year, a customization development plan based on the packaging system proposed by NTT East Japan was adopted, and a lease agreement was concluded in December. The contract amount is approximately 33.8 million yen per month, and the period is six years from September 2009 to September 2015. The project was based on a waterfall model that went from requirements definition to design, development and testing.
The original plan was to confirm the specifications that form the basis of development, or the so-called “specification freeze,” to be completed at the end of February 2009. However, starting from this initial milestone, the project begins to deviate from the plan at the request of the user. One after another, requests were received from the university, and the deadline for the specification freeze was repeatedly postponed. Ultimately, in July of the same year, vendor NTT East decided to accept the 625 additional development requests presented by users. In exchange, both parties agreed to postpone the system’s operational start date from the original September 2009 to January 4, 2010 for about four months, and then to freeze the final specifications.
This agreement was supposed to be a turning point that would separate the fate of the project. But the reality is different. Despite the agreement that “the specifications have now been finalized,” the university has continued to receive constant requests from its universities to add 171 new items. Under these circumstances, the project has become more chaotic. The system’s achievement evaluation test conducted between January and February 2010 will result in a failure judgment. However, looking at the truth, it was not that development was in a desperate situation. In fact, as of January 5th, just before the test, only four of the 6,486 agreed items had not yet been completed. As of March 16th of the same year, the remaining unfinished items had decreased to just one item. This suggests that the project was technically close to completion.
Despite this, in April 2010, the university unilaterally notified NTT East that its contract was terminated, causing the situation to turn into a legal battle. The district court in the first instance found the user and vendor’s fault ratio to be 2 to 8, citing the vendor’s defective project management. However, this decision will be dramatically overturned by the Sapporo High Court, an appeal hearing. The Sapporo High Court ruled that the fault ratio was 10-0, citing that the user was responsible for the failure of the project. It has issued a reversal ruling ordering the university to pay approximately 1.497 billion yen to NTT East Japan.
The main reason for this decision was that the High Court made its strict interpretation of the legal implications of the aforementioned “Specification Free Joint Agreement” in July 2009. Taking into account the characteristics of the Waterfall development and the repeated changes in specifications up to that point, the court clearly determined that this agreement was intended to “not issue any further requests for further development,” including requests such as improving screen layout and operability. Therefore, the university’s actions, which continued to make 171 additional requests after the agreement, directly violated the “oscience” obligation of cooperation that users had to bear, to ensure that they did not interfere with the smooth progress of development. The ruling strongly reminded developers that the agreement to freeze specifications is not merely a goal of effort, but a legally binding commitment.
Two aspects of the obligation to cooperate: “Article” and “Operation” recognized by the court
The core of the decision made by the Sapporo High Court in the Asahikawa Medical University case is that it views the user’s obligation to cooperate from two clear aspects: an “obligation for acts” and an “obligation for omission”, and has determined that the user has had negligence in both of these cases. Understanding this two-layer structure is extremely important in defining the role of users in system development.
The first aspect is the “mandatory act.” This refers to the obligation that users must take proactive action to advance their projects. Specifically, this includes providing information on the design documents and specifications of the current system, which are the premise for development, preparing and extracting master data for the transition to the new system, taking initiative in acceptance and operational tests to confirm whether the developed functions meet the requirements, and making necessary decisions at each stage of the project without delay. In the Asahikawa Medical University case, the court found that these mandatory actions were not fully fulfilled. In particular, it has been pointed out that the master data extraction process, which users should normally take responsibility, was significantly delayed, and ultimately, the vendor was forced to act on their behalf. Furthermore, information on the specifications of the current system was insufficient, and there was a situation where vendors had to grope their development, which was also considered a breach of their obligations.
The second aspect is the “obligation of omission.” This means an obligation to ensure that the project does not interfere with progress by “not” any particular act. This obligation of omission was the most important thing in this case. As mentioned above, the July 2009 specification freeze-bonded agreement was interpreted as a legal promise to “not issue any further requests.” Therefore, the act of disrupting and delaying development work by continuing to issue large amounts of additional requests against the agreement and forcing the vendor to respond was rated as an obvious violation of this obligation of omission.
The court has put into practice the fact that in the early stages of system development, some minor bugs and bugs are technically inevitable. And we have organized this as follows: If these problems can be resolved one after another, there is no reason to deny the system’s “completion” itself. Based on this premise, we examined the actions of Asahikawa Medical University and concluded that the users had neglected their obligations to fulfill, both in terms of acts and omissions.
The reason behind this rigorous evaluation is the fact that the vendors worked hard to properly manage their projects. NTT East repeatedly explained that every time a university requests additionally, there is a risk that if it responds, there is a risk that it will not be able to meet the deadline. And in the end, instead of accepting the request for 625 additional items, they made reasonable efforts to manage the project, installing a “specification freeze.” Since the vendors had put in place these management efforts, the High Court has decided that they would not be “an obligation to continue to persuade users even after the freeze-bond intention” or “a legal obligation to firmly reject unfair additional requests.” This confirmed that the reason for the project’s failure was simply a violation of the user’s obligation to cooperate, and there was no reason to be blamed on the vendor.
The default on “Refusal to inspect” – User’s responsibility indicated by the sales management system incident
The user’s obligation to cooperate is not limited to providing information during the development phase and cooperation in determining specifications. Users also have a serious obligation to cooperate in the “inspection” process, in which the developed system is inspected to ensure that it meets the contract contents and notifies them of the results. This point was clearly shown in the Tokyo High Court’s ruling of June 11, 2015, the so-called sales management system case. This ruling showed that the very act of users continuing to refuse to cooperate with inspections without reasonable reason could result in contractual default, which had a major impact on development practices.
In this case, a user company concluded a basic agreement with a vendor regarding the development of a sales management system, and the project was carried out in a way that involves individual contracts for each process, such as requirements definition, design, and construction. As the system approached completion, a briefing was held for users, and several problems were noted. In response to this, the two parties have agreed to customize the items at an additional cost of approximately 5 million yen after discussion. The vendor has completed this additional development and asked users to inspect the system. However, things will stagnate from here. The user refused to accept inspections despite repeated requests from the vendor.
The vendor, who was dying, filed a lawsuit seeking payment of approximately 92 million yen, including the initial contract fee and additional fees. In response, the user argued that “the system is incomplete and the vendor is in default,” and filed a counterclaim seeking damages of approximately 40 million yen.
The court’s decision fully supported the Bender’s claims. First, the Tokyo District Court pointed out that the process of inspection cannot be completed without the cooperation of users. Furthermore, we have presented an important framework for determining that even if inspections are not completed due to user incompatibility, if the vendor completes the work based on the contract and the system meets the final specifications, it is legally deemed to be “completed”. The system in question then accepted the vendor’s request, stating that it met the specifications.
This decision was also maintained by the Tokyo High Court, an appeal trial. The High Court has once again confirmed that, as with the decision in the Asahikawa Medical University case, the existence of minor bugs in the early stages of system development is inevitable, and that if they are of the nature that can be resolved one after another, it will not hinder the certification of completion. Furthermore, the user in this case clearly evaluated the act of continuing to refuse inspections without providing reasonable reasons as a “deficiency of contract.” The message that the ruling states is that “the inspection is not simply a ritual for the vendor to receive the payment.” It is a mandatory contractually established collaborative process for both parties to confirm whether the developed deliverables meet the contractual terms and formal completion of the project.
This precedent contains important lessons, especially in cases where minimal customization is added to the packaging software. Users cannot refuse inspections based on vague “incompatible use” or “not equivalent to current systems” expectations that are outside the scope of agreed specifications. Whether or not the product is completed is determined objectively based on its compatibility with the “specification” agreed in advance. If the user believes that there is a problem with the system, instead of avoiding inspections, the user is responsible for first performing inspections, and then clearly state which features differ from the specifications and the specific reasons for failing within the deadline. This ruling provides an important legal basis to clarify the liability of users in inspections and to prevent unfair payment delays.
Designing contracts to prevent conflicts – A clear culture of cooperation obligations from the JEITA model
Serious disputes such as the Asahikawa Medical University Incident and the Sales Management System Incident are unfortunate consequences that force both users and vendors to be extremely time-consuming and costly. The greatest lesson from these precedents is the importance of clearly positioning the concept of a duty of cooperation as a legally binding “contractual” obligation, rather than simply putting it into the mindset of the field. To prevent conflicts, it is necessary to draw a “blueprint” of the obligation to cooperate at the contract stage before the project begins.
In this regard, information systems, model transactions and contracts published by the Electronics and Information Technology Industry Association (JEITA), a general incorporated association. This model contract is based on years of industry knowledge and an analysis of past disputes, and provides specific and practical terms regarding the obligation to cooperate. For example, the provisions regarding the implementation of development clearly state that user cooperation is an obligation, such as, “The vendor may request the user’s cooperation necessary for the development of the software, and the user shall respond in a timely manner.”
More importantly, the concrete design of the inspection process. The JEITA model contract clearly states that inspections (acceptance inspections) will trigger payments, and also provides detailed information on the inspection period, criteria for passing and failing, the response to cases where they fail, and the concept of “deemed approval” that is considered to be passed if the user fails to notify them of pass or fail within the period. This is an extremely effective mechanism to prevent situations such as intentional delays or rejection of inspections by users, such as those that have become a problem in the sales management system incident.
The advantage of incorporating such a concrete process into a contract is more than just backward conflict prevention. Rather, it acts as a positive progress management tool to help the project go smoothly. For example, by clarifying inspection standards in advance, the development goals will be clear and vendors can work efficiently towards that goal. Additionally, users also understand in advance what to do to make it “complete”, making it difficult to bring up non-special requirements such as subjective “usefulness” The inspection period and deemed approval provision prevents delays in user decision-making and contributes to complying with the entire project’s schedule.
The contract must separate the definitions so as not to confuse inspection standards with operational tests that are evaluated in conjunction with actual operations, and that the user is responsible for clearly determining whether they pass or fail within a defined period. This “process design” is the key to making the abstract concept of cooperation effective. What the case law advocates support the fact that these steady contractual allowances ultimately manage risks across the project and protect both users and vendors.
Lessons from precedents to be used in practical work: the boundary between “cooperation” and “violation”
The two groundbreaking rulings provide a concrete demarcation of what is acceptable for various events that occur daily at the system development site, and what can be a legal “breach of obligation.” Incorporating the lessons learned from these precedents as criteria for daily practice is essential to avoiding problems and leading the project to a successful basis.
The specific facts of the Asahikawa Medical University incident clearly depict the code of conduct that both users and vendors should follow. From the user’s perspective, it must be recognized that disregarding the “freezing of specifications” once agreed, and then making additional requests a regularity afterwards, can no longer be a mere “request” but an illegal act of “breach of obligation to omission” that hinders development. Similarly, delays in providing accurate information about the current system, which is the premise for development, and master data necessary for migration, can also constitute a “violation of the activism obligation” that will cause the project to stagnate. Even though the vendor repeatedly warns them that “if further additional requests are met, we will not be able to meet the deadline,” and even after they have reached a re-agreement to freeze the specifications, they will continue to make requests and ultimately suspend the project through the unilateral lifting method, it should be understood as an act that seriously harms the court’s spirit.
On the other hand, these precedents also require vendors to be strictly self-disciplined. In order to legally assert a user’s obligation to cooperate, the vendor itself must fulfill its project management obligations in good faith. It is necessary to carefully preserve “traces” from every process of the project, including minutes of meetings with users, evaluation results that objectively show the level of the system’s reach, logs that record changes requests and responses from users, requests for master data work and user response history, and agreement documents that lead to specifications being frozen. Only with this evidence can we objectively prove that there was a lack of user cooperation and that this was a direct cause of delays and failure of the project.
The Tokyo High Court ruling on the sales management system will reaffirm both parties’ responsibilities, particularly during the inspection phase. Users are not allowed to make decisions based on their expectations and speculations that “probably won’t be usable” on the completed system and avoid the inspection process itself. The user is responsible for first conducting inspections and, if it deems a failure, to clearly state the specific reasons in writing within the period specified in the contract. The reason for failing must be to specifically point out which parts do not fit in how, in light of the “specifications” agreed in advance. Claims such as abstract “ease of use” or no functionality outside the scope of the contract are implemented legally. This lesson is particularly important in package-based customization cases that tend to be contested over the scope of specifications.
Summary: To make the obligation to cooperate with the trinity of “clauses, operation, and evidence”
The two court cases, the Asahikawa Medical University case and the Sales Management System Case, pose to all people involved in system development, are the extremely simple and important fact that users’ “duty of cooperation” is no longer just a goal of effort or business “ordinary” but a strict “law” based on contracts. If this obligation is not fulfilled, the project will halt and the liability for this will be legally severe. Therefore, we need to incorporate the concept of a duty of cooperation into our projects as a more concrete and effective mechanism.
To do this, it is essential to ensure that the three elements of “contract clauses,” “daily operation,” and “objective evidence” function as a unit. First, we will specifically define the content of the cooperation obligation in the contract, which is the starting point for the project. To prevent the word “freezing” as a mere slogan, rules such as the scope and exceptions of freezing, procedures for accepting requests for changes after freezing, estimates and approval processes for the impact of changes, and whether or not additional contracts are necessary are engraved in the contract in advance. Similarly, to ensure that inspections, which are the exits of the project, do not stagnate, specific requirements for acceptance inspections, the period for determining whether or not to pass or fail, provisions for deemed approval, and a form of notification if a failure occurs.
Next, in daily project operations, we faithfully implement the rules set out in the contract. At each barrier of requirement definition, design, development, testing, and acceptance, the content agreed by users and vendors is recorded in the form of minutes and approval letters and accumulated. In particular, if a vendor determines that a user’s actions pose a risk to the project, it is important to present a written warning or alternative proposal each time, and to clearly log a dialogue about how the user responds to it.
And finally, we preserve all these operational processes as objective evidence. The stacked minutes, change management slips, issue management slips, and email exchanges are powerful defenses to prepare for any eventuality. These evidence serves as an unwavering, objective standard for determining whether the obligation to cooperate has been fulfilled.
Users’ obligation to cooperate is not intended to unilaterally benefit the vendor. It is an essential discipline for users and vendors to build healthy partnerships towards the common goal of a project, reducing risks to both parties, and leading system development to success. Only when this discipline is put into practice as a trinity of “clauses, operation, and evidence” will the obligation of cooperation truly function and become a shield to protect itself in court in times of emergency.
