What is the Legal Significance of Management Objectives and Numerical Targets in System Development Projects?

System development projects often tie closely with significant business improvements within companies and workplaces. In such cases, there may be a demand for a commitment to contribute towards solving the company’s management issues from the user’s side, or achieving numerical targets. However, is committing to these management goals truly a legal obligation? The legal implications of numerical and management goals become a point of contention. This article will explain the legal issues associated with various ‘objectives’ and ‘goals’ in system development.

Why Do the Objectives and Goals of System Development Become a Source of Conflict?

Because it’s a challenge that lies between the user’s obligation to cooperate and the vendor’s discretion

When viewed as a form of commercial transaction, system development projects have several distinctive features. One is that a system development project by a vendor cannot be accomplished solely by the vendor; it requires cooperation from the user side. This obligation is clearly recognized in case law as the “obligation to cooperate”. Mainly, the user is required to cooperate in system development during phases such as ① requirement definition ② basic design ③ acceptance of deliverables.

https://monolith.law/corporate/user-obligatory-cooperation[ja]

Another point is that the vendor side is usually required to exercise a large amount of discretion in their work. There is a legal term that summarizes what the vendor side should do in a series of system development projects, which is the “project management obligation”. This is explained in detail in the following article.

https://monolith.law/corporate/project-management-duties[ja]

Summarizing the above, we can point out two important points here.

• The user is required in practice to provide necessary information to the vendor as appropriate and to cooperate with the vendor’s development work.
• The vendor is required in practice to understand the purpose and goals of the project for the user and to take actions that align with them.

Due to these two points, it becomes an issue as to how far the achievement of management goals and numerical targets, which were explained by the user in advance, can legally become the obligation of the vendor side. In other words, while there is an aspect that it is the user’s obligation to summarize what the vendor should do (not vague things like goals) and present it as specifications, there is also an aspect that the vendor, as a professional, has an obligation to provide what the user essentially wants (not just doing what they were told to do). The collision of these conflicting claims is a personalityistic of disputes over the “goals” and “objectives” of system development. From a legal perspective, presenting guidelines for dispute resolution that benefits both parties is a practical challenge.

Specific Situations Where the User’s Goals Impact the Project

System development projects often tie in with large-scale business improvement and efficiency measures in companies and workplaces, and it is common for hearings on management issues and goals to be conducted even at the planning and proposal stages. There, exchanges about the cost-effectiveness of developing the system and various numerical targets can be considered.

• Labor costs reduced due to labor-saving
• Increase in sales or profits
• Shortening of working hours

For example, if the above items are the final goals of the project, it is conceivable that the vendor side may explain the investment effects of system development from a consultant-like position and conduct sales in advance.

What are the court cases where the management goals set by the user side became an issue?

However, vendors are typically experts in system development. It would be too harsh to say that all responsibility falls on them in relation to the management goals of the user side.

A case where the improvement of business speed was set as a goal

In relation to this matter, the case cited in the following judgment had the purpose and goals of initiating a system development project written in the project proposal created at the time of project launch. However, when the system was actually completed and operation began, it was not able to achieve its purpose and goals, leading to a dispute. The initial project proposal stated that after the system was completed and actually utilized, it aimed to achieve the following conditions:

• Reduce manual input time by humans by 50%
• Ensure that administrative processing using the IT system can be completed within a specified period

The user attempted to pursue the vendor for breach of contract and warranty liability because these could not be realized in the end. However, the court did not accept this argument (the underlined and bold parts are added by the author).

And, (omitted) according to the whole argument, ① the purpose of this case is abstract, such as “improving business efficiency”, “building a CRM foundation”, “conducting visible management”, and the target values are also “increasing customer touchpoints”, “reallocating administrative labor to internal control and sales support”, “making more accurate sales forecasts”, “suppressing excessive sales discounts”, etc., which are abstract, and the target values such as “reducing input time by 50%”, “reducing estimate creation time by 50%”, “being able to disclose legally within the legal period” are dependent on the defendant’s management and business methods after the introduction of SBO, and are not of a nature that the plaintiff, a system development company that supports the introduction of package software, can undertake to achieve, ② there is no mention in the minutes of the meeting after the kickoff of this project that the purpose and target values of this case were specifically discussed, ③ in the project plan of this case, expressions that cannot be said to have the nature of a contract, such as “becoming a listed company”, are used, (omitted) considering these circumstances, it is recognized that the plaintiff created the description of the purpose of this case in the project plan based on the defendant’s explanation in order to prevent the failure of this project and to obtain a common understanding of the purpose and results of this project, and it cannot be recognized that the defendant entrusted the plaintiff with the system development to achieve the purpose of this case. (omitted) Therefore, it cannot be recognized that the plaintiff undertook the system development to achieve the purpose of this case from the defendant, so (omitted) there is no reason for the claim of breach of contract and warranty liability.

Tokyo District Court, December 28, 2010 (Heisei 22)

What is the legal meaning of management goals and numerical goals that can be inferred from court precedents?

As mentioned in this judgment, whether the purpose of system development and the goals quantified in numbers can be achieved usually involves various factors such as the management efforts of the user side that utilizes the system. Therefore, it should be considered that the hurdle to make it the responsibility of the vendor side is very high. After all, if the vendor’s breach of contract and warranty liability are recognized, it means that the achievement of the “purpose” and “goals” was incorporated as part of the contract. However, in this case, the “purpose” and “goals” were legally evaluated as follows:

• For abstract and vague ones, it is difficult to consider them as part of the contract because they do not fit the nature of legal obligations.
• For those that require the self-help efforts of the user side, especially the management side, it is inappropriate to attribute them to the vendor side, and it is difficult to consider them as part of the contractual obligations, as they are beyond the control of the vendor side.

That’s how they were legally evaluated.

What else can be inferred from this judgment

This judgment also contains several other interesting points.

• The court also considers the possibility that sharing the “purpose” and “goals” of a system development project may be nothing more than an effort to communicate to gain a “common understanding” between the user and the vendor.
• In considering how essential these “purposes” and “goals” were in the series of projects, the minutes of meetings are also referred to.

For legal issues associated with system development projects, from the perspective of document management and the importance of minutes, we provide explanations in the following articles.

https://monolith.law/corporate/the-minutes-in-system-development[ja]

Legal Considerations Surrounding Management Objectives and Numerical Targets

However, when dealing with legal issues surrounding these “objectives” and “targets”, it’s important to keep in mind the following additional points.

The Story Changes Depending on Whether Consulting is Paid or Free

If you have not only a system development project but also a paid consulting contract, the situation may change significantly. If, regardless of the user’s management resources, an execution plan with little feasibility was formulated, it is possible that the user could be pursued for breach of contract in the paid consulting contract.

Defects in Deliverables, and Inconsistencies in Function and Specification Requirements are Separate Issues

Also, if there are defects in the “development” project itself, that is, if bugs or malfunctions are confirmed in the deliverables, these issues need to be understood separately. In such cases, the discussion of management “objectives” and “targets” is unnecessary, and the focus is primarily on the consistency between the deliverables and the required functional requirements and specifications. For example, we explain the user’s response measures when a defect is found in the system after the fact in the following article.

https://monolith.law/corporate/system-flaw-measure-after-acceptance[ja]

Another related topic is that there are things that are recognized as having an obligation to implement at the vendor’s discretion, even though they are not included in the requirements. We explain this in detail in the following article.

https://monolith.law/corporate/system-development-specs-function[ja]

In any case, disputes surrounding “objectives” and “targets” should be understood as similar but different issues.

Understanding the Fundamentals of Responsibility and Contracts is Essential

We have discussed legal issues surrounding the “purpose” and “goals” of system development. In disputes over these matters, courts often encourage both users and vendors to make concerted efforts to communicate and share information. It is believed that they fully understand the importance of this. However, even if the validity of the conclusion itself can be fully understood through practical experience, a fundamental understanding of “responsibility” and “contracts” is required in the process leading up to it. We discuss these points in the following article.

https://monolith.law/corporate/responsibility-system-development[ja]

It is important to gain a more essential understanding, considering that legal responsibility differs from vague moral responsibility, and that a clear “consensus” between both parties gives rise to contractual responsibility.