What is a Multi-stage Contract in System Development? An Explanation Including Recommended Reasons

In system development projects, it is often the case that contract practices are carried out using a method called multi-stage contracts. In this article, we will explain about multi-stage contracts in system development, including the reasons why they are recommended.

What is a Multi-stage Contract?

Generally, the practice of entering into a contract is done through a contract document. That is, the party paying the remuneration (the user in the case of system development) undertakes the obligation to pay the remuneration, and the party receiving the work (the vendor in the case of system development) promises in writing to provide the corresponding service. In this way, the essence of a contract is that both parties promise to undertake their own obligations.

Completing Work by Concluding Contracts According to the Nature of Each Process

However, in the case of system development projects, the content of the project itself progresses through several processes, and the content tends to become complex. Considering the nature of such work, it may be appropriate to proceed with the contract in multiple stages. In other words, it is better to compile ideas structurally even for the contract document that manages the entire project. For example, it is very preferable in practice to conclude a contract for each process. This method of contracting is also called a multi-stage contract. The model contract provided by the Ministry of Economy, Trade and Industry (METI) is also based on this multi-stage contract.

Types of Contracts Concluded in Each Project

The contracts often used in system development are two types: contract for work and quasi-mandate contract. Depending on the nature of each process, these two are used alternately to manage the whole. For example, in the entire process of system development, detailed design, program implementation, and unit testing are typically done under a contract for work. The reason why these processes fit well with the contract for work is that the contract for work emphasizes the “completion of work” as a requirement for performance of obligations, and it is easy to concretize the “completion” requirement as the nature of the process. For more details on the “completion of work” in the contract for work, please refer to the following article.

https://monolith.law/corporate/completion-of-work-in-system-development[ja]

On the other hand, the planning stage and the requirement definition stage in the early stages of system development tend to use quasi-mandate contracts. The personalityistics of these processes are that it is often not easy to clarify the requirements for “completion of work”, and the trust relationship between the two parties often forms the basis of the contract. In processes such as basic design and integration testing, either quasi-mandate or contract for work is used depending on the nature of the project. One point to consider when choosing which contract to use in these processes is how much cooperation from the user is required.

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

If the nature of the work requires the vendor to unilaterally complete the work, it is considered convenient to choose a contract for work. However, if it is inevitable that the user and the vendor will have to work together, it is important to understand that it may be more realistic to give legal protection to the relationship based on the trust of both parties. For more details on the difference between a contract for work and a quasi-mandate contract, please refer to the following article.

https://monolith.law/corporate/contract-and-timeandmaterialcontract[ja]

This article explains that contracts for work tend to be used for things like program implementation, where the form of the deliverable is easily identifiable, and the less this tendency, the more likely a quasi-mandate contract is to be used. In this way, the practice of contracting based on multi-stage contracts is to capture a series of projects as a whole of contracts for work and quasi-mandate contracts concluded over multiple stages. Also, a “basic contract” is something that extracts common items so that the same description does not have to be repeated many times. This is very similar to grouping common elements into classes or functions in program implementation.

Common items often written together in a basic contract include, for example,

• Definitions of terms used repeatedly
• How to proceed with individual contracts
• How to change the specifications to be realized afterwards
• How to deliver and accept deliverables for each process
• How to keep secrets

These features are consistent regardless of the process, as they are usually the same content from the perspective of a series of projects, even if the contracts are separated by stages. In this way, the personalityistic of multi-stage contracts is to extract more general and versatile agreements as basic contracts, and to place individual contracts that should be distinguished for each process under the basic contract. Multi-stage contracts are often used not only in system development but also in commercial transactions personalityized by large scale and complexity. The opposite concept of a multi-stage contract with such a complex structure is a lump-sum contract. If the subject is not system development but ordering a custom-made suit, a lump-sum contract is usually sufficient.

What are the Benefits of Multi-stage Contracts?

So, what are the benefits of adopting such a multi-stage contract approach? If we were to organize it a bit more concretely, we could list the following benefits.

Benefit 1 of Multi-stage Contracts: Easier to Handle the Fluidity of Development Projects

One of the benefits of multi-stage contracts is that they make it relatively easy to handle the fluidity of development projects. Normally, a series of system development projects proceed according to pre-defined requirements, moving on to design and program implementation, and are carried out in one go without any backtracking or rework. However, due to the complexity of the product, the construction period usually spans a considerable period, and it is not uncommon for the content of the specifications to be realized to change afterwards. For how to properly manage change requests for these post-specification changes, please refer to the following article.

https://monolith.law/corporate/howto-manage-change-in-system-development[ja]

In other words, at the start of the project, the final goal is not necessarily clear. Especially in projects that include such uncertain elements, it can be difficult to promise all obligations at once at the time of contract conclusion. It is easier to divide the project into stages, which avoids unnecessary risks for both parties and makes it easier to proceed with business transactions smoothly.

Benefit 2 of Multi-stage Contracts: Easier to Make Accurate Estimates

The above-mentioned benefit of being able to avoid committing to unclear things also leads to the ability to make accurate estimate amounts. If the specifications are changed afterwards, it is quite possible that the estimate will also have to be changed afterwards. For how to recalculate estimates in such cases, please refer to the following article.

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

While the approach to changes in estimates due to post-specification changes is as described in the above article, dealing with such changes afterwards is not very desirable for both users and vendors. It is best to avoid making estimates that need to be corrected in the first place and to complete them accurately in one go. With multi-stage contracts, it is expected that it will be easier to make accurate estimates for each stage, and that changes in estimates afterwards will be less likely to occur.

Benefit 3 of Multi-stage Contracts: Easier for the Paying Party to Understand the Reasonableness of the Amount

Furthermore, dividing the project into stages and making estimates for each stage makes it easier for the user, who pays the remuneration, to understand the reasonableness of the amount for the entire project. As mentioned earlier, it is by no means easy to approach a series of projects with perfect planning. Therefore, it is often the case that various changes are made and the initial estimate is changed as the project progresses. In the case of a lump-sum contract, it is assumed that the only opportunity to explain the estimated amount is at the time of the initial contract conclusion. For the user, it is difficult to understand the reason for the difference between the initial estimate and the actual payment amount at the payment stage. Considering these points, it can be said that multi-stage contracts also have certain benefits for users.

Summary

Multi-stage contracts are suitable for forming fair and clear agreements between parties and are effective in preventing future disputes. However, some may wonder if there are any drawbacks to multi-stage contracts and if individual contracts might be better in some cases. On this point, if forced to say, the idea that a lump-sum contract is sufficient if the business is small and it is obvious that the work will be completed quickly can be valid due to the burden of concluding a contract each time. However, rather than being aware of the very limited disadvantages of multi-stage contracts, it is more important to fully understand the benefits of accurate and change-resistant multi-stage contracts. If the project is of a certain scale, it is natural to use such methods.