What are the Project Management Obligations in System Development?

System development is a process that can only progress through mutual cooperation between the user who orders the work and the vendor who receives the order.

Projects to develop IT systems used in companies rarely go exactly as planned or expected. Rather, it is more common to face various troubles and challenges, big or small, and to move forward by overcoming each one. In this process, it is not only important for the user side and the vendor side to synchronize their steps, but also to manage crises with potential disputes in mind.

From a legal perspective, the first step in crisis management is to clarify what obligations each party bears and what rights they can assert against each other. In this article, we will explain the legal obligations that the vendor side bears for a series of projects, focusing primarily on the obligation of project management.

What are the Project Management Obligations of the Vendor?

First, let’s look at the content of the vendor’s project management obligations.

According to court precedents, the content of project management obligations is as follows:

– The obligation to proceed with development work in accordance with the agreement, constantly manage the progress, strive to discover factors that hinder development work, and appropriately deal with them.

– The obligation to properly manage the user’s involvement in development and to work with the user to ensure that no actions that hinder development work are taken by users who do not have specialized knowledge about system development.

This refers to showing the user the issues and deadlines for matters that require the user’s decision-making and concerns to be resolved, indicating the problems that arise when the user’s decision-making is delayed, advising the user to make decisions, and if there are demands that cannot be accepted due to the progress of development, explaining the reasons fully and refusing the user’s demands.

Thus, the vendor has the obligation to promote development work and encourage users to make decisions, and to strive to ensure the success of system development.

User’s Obligation to Cooperate

However, in system development, it is not the case that the vendor unilaterally assumes all obligations. After all, since it is an IT system to be used in the client’s company, the system development project should not be “someone else’s problem” for the client.

Even if you rely on the technical and organizational capabilities of external experts to develop the system, internal governance should be applied. Without efforts to draw out the power of external experts, it is impossible to deliver the necessary work as if it were someone else’s problem. In this sense, the user also has an obligation to cooperate in system development.

The cooperation obligations that the user should fulfill include the following:

　① The user actively conducts risk analysis, properly adjusts internal opinions, unifies views, and communicates demands to the vendor.

　② Confirm the deliverables.

　③ Respond to cooperation requests from the vendor.

The user is required to clearly communicate to the vendor the functions required of the system and actively cooperate in development.

Project Management is Not Easy

The fact that an IT system is made up of a combination of small parts may be difficult to realize from the user’s perspective, who only sees the screen. However, this is very important when considering the difficulty of managing a system development project. Because an IT system is such a thing, the vendor is required to have meticulous attention and at the same time, the ability to organize the overall picture concisely and the ability to overlook.

There are difficulties in the work that cannot be imagined just by looking at the screen, and this is also the very reason why the project “burns”. First, understand these points and know that “managing a project to develop an IT system is not an easy task” will be a major premise when learning about project risk management.

Potential Consequences of Breaching Project Management Obligations

So, what exactly can happen if there is a breach of project management obligations?

There is no clear clause stating, “Project management obligations are such and such,” prepared for this.

However, from past court precedents, we can discern a somewhat consistent stance on what a user can do if a vendor has breached their obligations.

If a vendor has breached their obligations, the user will claim damages or contract termination against the vendor. However, if the user is also at fault, the vendor may be deemed not liable, or a set-off may occur, potentially reducing the amount of damages.

On the other hand, if the user has breached their cooperation obligations, the vendor may claim an amount equivalent to the remuneration from the user, based on the risk burden (Article 536, Paragraph 2 of the Japanese Civil Code) or non-performance of obligations, if the work was not completed due to this.

Court Cases Illustrating Project Management Obligations

There are several representative court cases that explain the concept of project management obligations.

The following case escalated to a lawsuit due to delays in the delivery deadline and the vendor demanding an increase in the initial estimate in system development. This is a prime example of a so-called “flaming case,” where disputes over how to divide responsibilities between the user and the vendor lead to litigation.

The defendant, as a professional in system development, had an obligation to complete the system described in the contract and proposal for this system development contract by the agreed delivery deadline for phased operation, based on their advanced professional knowledge and experience. Therefore, the defendant should be understood to have an obligation to proceed with the development work according to the development procedures, methods, and work processes presented in the contract and proposal for this system development contract, to always manage the progress, to strive to discover factors that hinder the development work, and to deal with them appropriately. Furthermore, since system development is carried out in consultation with the orderer, taking into account their intentions, the defendant should have had an obligation to properly manage the involvement of the plaintiff, the National Health Insurance, in system development, and to influence the plaintiff, who does not have professional knowledge about system development, so that they do not hinder the development work (hereinafter, these obligations are referred to as “project management duties”).

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

From the summary of the above judgment, it is not important to decipher the detailed wording and complex course of the case. Above all, the point is that the term “project management obligations” is used as is. Although there is no explicit provision, it is clear that the court is trying to establish guidelines for dividing legal responsibilities.

Let’s summarize the content of the above judgment in plain language and organize it into bullet points. The “project management obligations” referred to here are:

• Proceeding with actual work according to the preliminary plan (development procedures, methods, processes, etc.)
• Managing the progress to see if the actual work is going smoothly
• If there are any “hindering factors” that prevent the actual work from going smoothly, discovering them and taking appropriate measures as needed

In addition, the above three points include:

• Making efforts in communication, such as appropriately asking the user side for necessary cooperation, rather than just self-help efforts on the vendor side

These can be collectively referred to as project management obligations.

System development is usually concluded as a quasi-mandate contract or a contract for work in legal terms. A quasi-mandate contract is simply a contract to “work with a certain level of accuracy in return for a fee,” so the concept of project management obligations can also be absorbed into the “accuracy” to be achieved.

However, it is a debatable theme, but even in the case of a contract for work, which is a contract to “make what is asked for,” it is believed that project management obligations can arise. The reason, as already mentioned, is that regardless of whether it is a quasi-mandate contract or a contract for work, project management is still important in system development, and it is believed that the vendor side should do it.

Court Case Demonstrating Project Management Obligations Even Before Contract Conclusion

It is believed that project management obligations can be imposed even in the pre-contractual stage. The court case cited below demonstrates that vendors have project management obligations even in the pre-contractual stage, i.e., when various proposals and plans are being put forward.

The following case involves a project that stalled midway. The dispute was whether project management obligations could be recognized due to deficiencies in planning and proposals, as well as estimates and explanations to the user side in the pre-contractual stage. Generally, since planning and proposal tasks are pre-contractual, the issue was whether it is legally possible to recognize such obligations. However, the court recognized this.

The concept of project management obligations in the aforementioned court case also extends to the pre-contractual stage, as you will understand from reading below.

In the planning and proposal stage, the overall framework of matters related to the project concept and feasibility, such as setting project goals, development costs, development scope, and assembling and estimating the development period, is determined. Accordingly, the risks associated with the project are also determined. Therefore, project planning and risk analysis required of vendors at the planning and proposal stage are indispensable for carrying out system development. Therefore, as a vendor, even at the planning and proposal stage, there is an obligation to examine and verify the functions of the system proposed by oneself, the degree of satisfaction with user needs, the system development method, the development structure after receiving an order, etc., and to explain the risks expected from these to the user. This obligation of the vendor to verify and explain, etc., is positioned as a duty under tort law based on the principle of good faith in the negotiation process towards contract conclusion, and it can be said that the appellant has such a duty (the duty related to project management at this stage).

Tokyo High Court, September 26, 2013 (Heisei 25)

Furthermore, the idea that there are certain legal obligations to the other party even in the pre-contractual stage is not limited to IT project discussions, but is originally applicable to all commercial transactions and negotiations involving law in general.

Especially for larger transactions, the process of “compromise” leading to the goal of a contract tends to be long. Even in this process, it is well understood, at least morally, that one should be sincere towards the other party. To put it simply, such discussions are not just emotional moral feelings, but also have legal significance. (The following is a citation of the article. The underlines are added by the author.)

Article 1, Paragraph 2 of the Civil Code
The exercise of rights and the performance of obligations must be carried out in good faith and with sincerity.

The keyword “principle of good faith” in the judgment text succinctly represents the above content.

Also, the court cases presented in this article, in one aspect, serve as guidelines for drawing the boundary between the user’s obligation to cooperate and the vendor’s project management obligations.

Summary: Consult Lawyer for Project Management Obligation Violations in System Development

In this article, we attempted to provide a general overview of the concept of project management obligations in system development. Various challenges and troubles are inherent in system development, and what becomes crucial when faced with such situations seems to be the ‘basics’ that underlie any dispute. Indeed, there may be infinite variations in the nature of each irregular situation.

However, the importance of questioning “Who had assumed what legal obligations in the first place?” when faced with such situations has a certain universality that transcends the individuality of the case itself.

Instead of focusing solely on ad hoc troubleshooting, it seems that the key to aiming for a resolution through constructive problem segmentation lies in the law and past court precedents.

If you encounter issues related to violations of project management obligations, consult a lawyer immediately.