What is the Proper Way to Manage Changes in System Development from a Legal Perspective?

In system development projects, it is often the case that the content explained by the user in advance changes as the work progresses. Therefore, even as a vendor accepting the work, there may be a need to accommodate changes to the contract that was once concluded.

This article explains how to handle the phenomenon of “changes” that occur post-facto in system development projects, which often do not proceed as expected, from a legal perspective.

Why are System Development Projects Often ‘Changed’ Post-Completion?

System Development is a Collaborative Effort Between Vendors and Users

Typically, system development goes through a planning and proposal stage, after which the requirements for development are defined and a contract is concluded. Once the contract is signed, the process generally follows a path of various design stages, implementation as per the design, and finally testing before completion. Throughout this entire process, while the vendor who takes on the job bears a wide range of responsibilities as a system development expert, there is also a certain level of cooperation required from the user side. In particular, user cooperation is crucial in stages such as identifying the functions that the system should have (i.e., requirement definition), the appearance and operability of the screen (i.e., basic design), and confirming whether the requirements have been met (i.e., testing or acceptance). For a general explanation of the obligations that users bear in system development, please refer to the following article.

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

Despite the Obligation to Cooperate, Users Often Request Changes

However, users, who are not system development experts, may not always be able to comprehensively and accurately convey all the necessary information for system development to the vendor. In reality, due to the detailed and meticulous nature of the work, there are many things that users cannot predict, such as what facts may have a decisive meaning in later stages. Ironically, this can lead to situations where the more important the fact, the more likely it is to be revealed in bits and pieces later on. Given these circumstances, in real-world projects, while the ideal is to have a ‘through and through’ approach from upstream to downstream processes, it is important to consider how to manage ‘changes’ that may occur post-completion.

What is a Change Control Document?

When is a Change Control Document Used?

A Change Control Document is a document used by the user to request changes in specifications or additional features from the vendor, differing from the content explained beforehand. As mentioned earlier, during phases such as requirement definition and basic design, the user also has an obligation to cooperate with the vendor’s operations. However, it is possible that different requests may arise in subsequent processes.

Examples of situations where a Change Control Document is necessary include:

• When there are oversights in the requirement definition or basic design, and additional features are requested afterwards
• When a review of business policies or similar occurs during development, necessitating a change in specifications

These are some possible scenarios.

Regarding topics such as adding features or changing specifications, what concerns those receiving the work most is whether changes in the estimated amount are legally permissible. We provide a detailed explanation on this point in a separate article.

https://monolith.law/corporate/increase-of-estimate[ja]

The Change Control Document serves as the basis for assessing the validity of the content of the estimate when increasing the estimate afterwards. The creation of a Change Control Document is important to avoid disputes when making claims based on the increased estimate later, and to lend credibility to your argument in case of a dispute.

Items to be Included in the Change Control Document

So, what should be included in the Change Control Document from a legal perspective? The contract mechanism to accommodate specification changes and additional features using a Change Control Document is already widely recognized in general. Therefore, by checking templates of contract clauses provided by government agencies, such as the Ministry of Economy, Trade and Industry (METI) model contract, you can generally understand what items should be recorded.

(Change Control Procedure)
Article 37: When Party A or Party B receives a change proposal based on Article 34 (Changes to System Specifications, etc.), Article 35 (Approval of Intermediate Materials by User), or Article 36 (Handling of Undetermined Matters), they shall, within ○ days from the date of receipt, deliver to the other party a document (hereinafter referred to as the “Change Control Document”) that includes the following items, and Party A and Party B shall discuss the acceptability of the change at the communication consultation meeting specified in Article 12.
① Name of the change
② Person in charge of the proposal
③ Date
④ Reason for the change
⑤ Detailed matters of the change, including the specifications related to the change
⑥ If the change requires costs, the amount
⑦ Schedule of the change work, including the consideration period
⑧ Other impacts of the change on the terms of this contract and individual contracts (work period or delivery date, contract fee, contract clauses, etc.)

Reading the text directly and confirming the recommended items for inclusion should make further explanation unnecessary. To avoid “he said, she said” issues later, it is important to record the details and specifics of the change.

By clearly stating these items and pairing them with the signatures or seals of the responsible parties or decision-makers from both the vendor and user, the document will hold the same significance as a contract as evidence, even in the event of a lawsuit.

Things to Know About Change Management

Change management is usually done in conjunction with issue management

The reason for creating a change management document is to manage the change history, which can guide the project to completion (or, if the project is not completed, to avoid unjust responsibility). In practice, the creation of a change management document is often done in conjunction with the creation and updating of an issue management list. In other words, once the change history is managed in the change management table, the agreed-upon changes are incorporated into the issue management list as issues to be addressed in the future.

It’s better to also establish rules for how to conduct change discussions

Not only the method of change management, but also the way of discussing changes should be regulated to ensure smooth handling of changes. This is especially important when adopting development methods such as agile development, where various changes are assumed to be made afterwards. In practice, there are many examples of regulations specifying when the other party should respond to a request for a discussion on change management.

Change Discussions and Duty of Good Faith

When changing a contract that both parties have once agreed upon, it is essentially like entering into a new contract. From the principle that a contract is based on the free will of the parties, there is no obligation for the vendor to agree to the change contract. However, if the rights aspect is overemphasized, there may be concerns that the system development project will not proceed smoothly.

Therefore, in practice, it is often stipulated in the contract that there is a “duty to respond in good faith to discussions on changes”, and there are cases where the vendor can claim damages if they do not respond in good faith to changes.

For example, the following is an example of a clause (quoted from the “Basic/Individual Contract Model Basic Contract Draft” officially created by the Independent Administrative Institution Information Processing Promotion Agency).

Article 4, Paragraph 3: In discussions on changes, both parties shall sincerely discuss whether to make changes, considering the subject of the change, the feasibility of the change, and the impact of the change on the price and delivery date.

Regulations on How to Change

As mentioned earlier, it is legally “safe” to hold discussions on changes each time a change is made. However, in small projects, there may be cases where it is not necessary to establish how to conduct discussions on changes. In such cases, instead of establishing regulations on discussions, it may be considered to make changes only after the user and vendor’s managers have signed and sealed the change management document, even without discussions. If changes can be made easily with only verbal agreement, it tends to be ambiguous whether changes have been made, which can lead to major trouble later. Therefore, document management should be thoroughly implemented.

However, it may be burdensome to prepare separate documents for change management each time, and you may want to prioritize flexible responses. In such cases, one option is to document changes in the minutes of meetings. The way to keep minutes of meetings in system development is explained in detail in the following article.

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

Summary

In environments where specifications are frequently changed, it is indeed often the case that one is prone to various troubles and disputes. However, in such flexible situations, it may be difficult to implement practical measures by merely emphasizing the importance of ‘management’ in a rigid manner.

The issue of how to balance the speed required in business and the preparation for unforeseen circumstances often varies depending on the company’s situation and the content of the project. While considering the content of this article, it is also important to have an attitude of exploring appropriate methods for each company and project.