What is the Law Surrounding the 'Flameout' of System Development Projects?
A project such as system development is not something that can be accomplished overnight. It requires a significant investment of resources, including numerous people and organizations, substantial funds, and a lengthy development period. In this article, we will explain how the phenomenon of ‘flaming’ in system development projects can be organized under a legal framework, and we will compile guidelines for solutions.
Why do Projects “Go Up in Flames”?
Even if an IT system is not an exceptionally large-scale project, it can only function correctly due to the accumulation of a vast number of program files and source codes. The level of detail and precision involved is often far beyond what one could imagine from the user interface (or rather, the simpler and more concise the user interface of the IT system, the more intricate its construction tends to be).
- The deadline is set in advance, but the specifications and requirements remain vague as time passes
- Members are too distracted by internal politics, and many drop out midway due to interpersonal stress
- There is a lack of negotiation skills among the management layer, including the Project Manager (PM), and members are not being asked for appropriate reporting, communication, and consultation
These are some of the specific reasons why a project might “go up in flames”. However, from a legal perspective, the reasons for a project’s failure can be relatively simply organized into several types.
Flame Type 1: When a Project Stalls Midway
In the course of system development, a typical reason for a project to stall midway is a lack of communication between the user side and the vendor side. A system development project requires not only the technical and organizational skills of the vendor, but also the cooperation of the user side who will ultimately use the system.
Therefore, if a project proceeds with unclear roles for each party, a sort of “pushing of responsibilities” can occur, hindering the smooth progress of the project. For legal considerations regarding the obligations of the user side and the vendor side, please refer to the following articles.
https://monolith.law/corporate/project-management-duties[ja]
https://monolith.law/corporate/user-obligatory-cooporation[ja]
While the detailed content of each party’s responsibilities can be found in the above articles, the key point here is that both the user and the vendor have certain responsibilities in a system development project. Broadly speaking, past precedents and court cases recognize the user’s obligation to cooperate in areas such as requirement definition, design of appearance such as screens (i.e., basic design), and acceptance, which cannot be completed without the user’s cooperation.
On the other hand, the vendor side also has a comprehensive obligation to ensure the smooth progress of the project and to identify and eliminate obstacles, after receiving the user’s cooperation in the above points (and at the same time, making efforts to communicate and request such cooperation).
Under this concept, the court shows an attitude of treating all disputes fairly, by demonstrating the obligation of the user to govern from within as an internal system, and the obligation of the vendor to demonstrate expertise and technical skills as an external expert.
Furthermore, a situation where such a “stall” is likely to occur is during the acceptance phase. For more details on acceptance, please refer to the following article.
https://monolith.law/corporate/estimated-inspection-of-system-development[ja]
In such cases, once a dispute arises, objective evidence such as the progress of past projects and the content of meetings is often emphasized. Therefore, documents that have been recorded in advance often carry significant weight. Thorough document management is important to avoid disadvantaging your position. For a detailed explanation from the perspective of the importance of document management in system development, please refer to the following article.
https://monolith.law/corporate/the-minutes-in-system-development[ja]
Flame Type 2: When the User Cancels for Personal Reasons
There may also be cases where a project is halted midway due to the user’s wishes. For example, let’s say a company started building an IT system to manage human resources, including overseas bases, but then the company’s strategy of expanding sales channels through overseas expansion was withdrawn. In such cases, the development of the system that was just getting started may no longer be necessary for the user.
First of all, the question of how an IT system should be built in a company is inseparable from the question of “what kind of operations exist in the company” as a premise. Therefore, it is conceivable that the requirements of the system that becomes necessary (or unnecessary) may change after the fact due to the impact of major changes in organizational structure, business division reorganization, and radical review of strategies.
Various legal issues may arise when a project is interrupted midway due to such circumstances. In such cases, since it is usually due to the user’s personal circumstances, the vendor side is also granted certain legal rights, such as claiming remuneration according to the completion rate. Depending on the type of contract that was adopted, there may be differences in the basis of the provisions, but the content is organized as follows:
・In the case of a contract: Japanese Civil Code Article 641
Japanese Civil Code Article 641
→The orderer can cancel the contract at any time by compensating for the damage while the contractor does not complete the work.
・In the case of a quasi-mandate contract: Japanese Civil Code Article 648, Paragraph 3 (depending on the situation, a claim for damages based on Japanese Civil Code Article 651 may also be made)
Japanese Civil Code Article 648
→If the mandate ends midway through performance due to a reason that cannot be attributed to the acceptor, the acceptor can claim remuneration in proportion to the performance already made.
Japanese Civil Code Article 651
→1. The mandate can be cancelled by either party at any time.
→2. If one party cancels the mandate at a disadvantageous time for the other party, the one party must compensate the other party for the damage. However, this does not apply if there is an unavoidable reason.
Flame Type 3: When Deficiencies in the Delivered System are Discovered Later
Users often assess the quality of a system based on the user interface, but from the perspective of those who accept the job, the more challenging aspects are often the design of the database and the identification of test items, assuming all possible operations.
In other words, even a system that seemed to work without problems at the beginning may:
- Slow down in processing speed as the amount of data registered increases
- Although the system seemed to work without problems in daily basic operations, it was found that bugs can occur in special operations that occur once every few months or years
- Even if it appears that the results are being output correctly on the surface, the actual logic may not be correct. (For example, even if “2” is correctly output in response to the user’s input of “1+1”, it does not necessarily mean that the calculation process is being performed correctly. There are many cases where a “logic error”, such as returning the output “2” no matter what calculation formula is input, cannot be discovered by simply operating the screen. In this sense, a certain level of “technical skill” is required in the testing process.)
Such things can actually happen. If we dare to analyze these cases from a legal perspective, it could be considered a breach of the vendor’s project management obligations, or in other words, a problem of incomplete performance under the Civil Code.
In this case, if there is no special agreement in the contract, the provisions related to the general contract will apply.
The points to consider in this case are organized as follows:
| ・If the job is not completed in the first place →If the job is not completed, the principle is that no remuneration, which is the consideration for it, will arise. However, if the cause is a breach of the user’s obligation to cooperate, the vendor can also take legal measures such as a claim for damages. |
https://monolith.law/corporate/defect-warranty-liability[ja]
| ・If the job is completed and the contracted purpose can be achieved, but there are still some minor defects that should be compensated for or repaired →The vendor can claim remuneration, but the user can also claim damages. Therefore, the usual practice is to offset the two amounts. |
| ・If the job is completed and there are no defects in the content →This is not a “flame” case in this article, and the project is completed with a normal claim for remuneration. |
These are the ways to organize it.
Summary
Each system development project will undoubtedly progress through various twists and turns. However, when it comes to the “flaming” of legal projects, the framework presented in this article serves as a blueprint. Legal issues related to system development indeed encompass a wide range of themes.
Just as system development requires constructive thinking, the associated risk management can also be carried out more constructively by not losing sight of the overall picture of the field. Wouldn’t you agree?
Category: IT
Tag: ITSystem Development
