How Should You Structure a Contract Development or Operations & Maintenance Contract? — Learning the Quasi-Mandate vs. Contract-for-Work Distinction from IPA's 'Model Contract'

“We signed a lump-sum contract-for-work agreement, but development started before the requirements had settled, and we ended up arguing over what counted as ‘done.’”

“We have a monthly maintenance contract, but we and the vendor had different understandings of how far the maintenance scope actually extended.”

“When we asked for a quote, we were told ‘requirements definition will be a quasi-mandate,’ but we don’t understand why the contract type changes from phase to phase.”

In outsourced system development, trouble often stems not from the technology but from the shape of the contract itself.

As it happens, there is an official model to learn from here: the Information System Model Transaction and Contract, published by IPA (the Information-technology Promotion Agency, an independent administrative institution).

This article uses that model contract to lay out, in language accessible to clients as well, how a contract should be structured when outsourcing — or taking on — contract development and operations and maintenance work.

Note that this article is a general explanation based on IPA’s published materials, not legal advice. Please consult a lawyer or other specialist for any specific contract.

1. The Bottom Line First

Here is the thinking that IPA’s model transaction and contract lays out for system development and operations and maintenance contracts, summarized up front.

• Do not bundle the entire development process into a single contract; split it by phase (a multi-stage contract)
• For the planning and requirements-definition phase, where “what to build” has not yet been decided, use a quasi-mandate contract
• For the phases from internal design through development and testing, once “what to build” has been decided, use a contract-for-work agreement as the default (external design can go either way depending on the project)
• For ongoing work such as operations and maintenance, use a quasi-mandate contract as the default
• The client also has cooperation obligations, such as deciding requirements and providing information
• Handle specification changes through a documented change-management procedure, not verbal exchanges

In a nutshell, the principle is: “don’t promise a duty to complete something that hasn’t been decided yet, but do promise a duty to complete something that has” — and the contract type is chosen phase by phase to match.

2. What Is IPA’s “Information System Model Transaction and Contract”?

The Information System Model Transaction and Contract is an official document combining a template for system-development outsourcing contracts with a commentary explaining it.

It was originally published by the Ministry of Economy, Trade and Industry (METI) in 2007 as the first edition, covering contract development (including some planning) and maintenance/operations. The background was a rash of disputes caused by mismatched understandings of contract terms between user companies (clients) and IT vendors (contractors).

Responsibility for revising it later passed to IPA, and a second edition, aligned with the amended Civil Code that took effect in April 2020, was published on December 22, 2020. The second edition clarifies matters such as liability for nonconformity with the contract (discussed below) and the positioning of the outcome-based quasi-mandate contract.

One point of caution concerns scope of applicability. Both the first and second editions were originally built around relatively large-scale custom development (waterfall-style) of things like corporate core systems, assuming transactions between companies that each had an IT department and legal function. For smaller-scale transactions, or cases making use of packaged software or SaaS, a separate supplementary-style model contract covering “package and SaaS/ASP use, and maintenance and operations” is available. The right way to use these is to check which one is closer to your own transaction and treat the text as a foundation for your thinking rather than copying the clauses verbatim. The material this article introduces is likewise the “thinking” part, which is useful regardless of scale.

This model contract has the following characteristics:

• It was drafted through discussion among user companies, IT vendors, industry associations, and legal experts, and is designed neutrally so as not to favor either side
• The contract template is published in Word format and can be revised to fit your own transaction
• It comes with commentary explaining not just the clauses themselves but why they are written that way
• Supporting documents are also published, including guidelines for determining the security specifications of a development contract

In short, it is a resource you can use both as a draft when drawing up a contract of your own, and as a benchmark for comparison when reviewing a contract presented to you by the other party.

3. The Core Idea Is the “Multi-Stage Contract” — Why Split the Contract by Phase?

The core idea in the model transaction and contract is the multi-stage contract.

System development broadly proceeds through phases like these:

Planning and requirements definition (deciding what to build)
        ↓
Design, development, and testing (building what was decided)
        ↓
Acceptance and deployment support (putting what was built into operation)
        ↓
Operations and maintenance (keeping it running)

A multi-stage contract is a scheme in which these phases are not bundled into a single contract, but instead split into separate contracts phase by phase (or by group of phases).

Why split it up? The reason is simple: what you can actually promise differs from phase to phase.

Before requirements definition is finished, neither the content nor the volume of what is being built has been fixed. Fixing the total price and delivery date for the entire development effort at this point leads to one of two outcomes:

• The contractor quotes a larger amount to hedge against the unresolved risk
• A contractor who took the job cheaply later claims “that’s out of scope,” and a dispute with the client follows

By contrast, once requirements definition is finished, what is being built is settled, and the contractor can offer an estimate and a completion commitment with realistic precision.

A multi-stage contract is a scheme premised on “re-estimating the development portion once requirements definition is finished.” From the client’s perspective, this carries the discomfort of not having a fixed total amount up front, but the model contract’s position is that this ultimately produces less trouble and less wasted cost than fixing the whole thing at a baseless price from the start.

4. Quasi-Mandate vs. Contract for Work — The Difference Between the Two Contract Types

A multi-stage contract switches between quasi-mandate and contract-for-work agreements phase by phase. The difference between these two is the single most important point in this article.

Contract for Work — A Contract That Promises Completion

A contract for work is an agreement that promises, “we will complete this deliverable.” The contractor bears the duty to complete it, and in principle cannot claim payment if it is not completed (though if a project ends midway, and the completed portion can be separated out and is of benefit to the client, payment proportional to that portion may sometimes be recognized).

If the delivered item does not conform to the contract, the contractor bears liability for nonconformity with the contract. This concept was restructured from the former “warranty against defects” liability under the Civil Code amendment that took effect in 2020: the client can demand repair, and under certain conditions — for example, if repair was requested within a set period and not carried out — can also demand a reduction in payment. However, if the nonconformity arose from the specifications or instructions the client itself provided, these claims are, in principle, unavailable, except where the contractor noticed the problem and failed to disclose it. The model contract’s second edition reflects this amendment.

Because this contract type carries a strong duty of responsibility in exchange for completion, it is appropriate for phases where “what counts as completion” can be clearly defined.

Quasi-Mandate — A Contract That Promises Professional Work

A quasi-mandate is an agreement that promises, “we will perform the work as professionals.” In exchange for not bearing a duty to complete, the contractor bears a duty of due care — that is, a duty to perform the work with the care ordinarily expected of a professional.

Hearing “there’s no duty to complete” might sound worrying to a client. But this does not mean “it’s fine to cut corners.” Performing the work inadequately as a professional exposes the contractor to liability for violating the duty of due care.

The amended Civil Code also codified an outcome-based way of paying under a quasi-mandate. As opposed to the performance-ratio type (payment proportional to the work performed — a typical example being settlement by hourly rate, and a fixed monthly fee for routine work is also possible), the outcome-based type pays for an agreed-upon outcome. For quasi-mandate work that produces a deliverable, such as a requirements-definition document, using this type lets you structure it as “a quasi-mandate, but one where delivery of the deliverable is tied to payment.”

Choosing the Right Type Phase by Phase

The model transaction and contract broadly assumes the following division:

The important thing here is that this is not simply a case of “contract for work favors the client, quasi-mandate favors the vendor.”

Forcing a contract for work onto work that has not yet been decided ends up promising a duty to complete without a clear standard for completion, leading to endless back-and-forth over whether it’s “done or not.” Choosing the contract type that matches the nature of the phase ultimately protects both sides.

5. What an Operations and Maintenance Contract Needs to Spell Out

Operations and maintenance after development is finished carries its own, different seeds of trouble. The most common one is a mismatch in understanding over “how much is actually included in the monthly maintenance fee.”

“Operations and maintenance” as a single phrase actually bundles together work of very different natures.

• Uptime monitoring, backups, and routine maintenance
• Responding to inquiries about how to use the system
• Initial investigation and recovery when an incident occurs
• Fixing defects
• Keeping up with OS and middleware updates
• Modifications such as feature additions or screen changes

Of these, ongoing work such as monitoring, inquiry response, and initial investigation is best handled under a quasi-mandate structure as a default. Feature additions or modifications whose content can be clearly defined, on the other hand, are safer carved out individually and quoted as separate contract-for-work items rather than folded ambiguously into the maintenance contract.

We recommend documenting at least the following points at contract time:

• The line between what is included in the flat monthly fee and what is not
• The hours during which inquiries and incident response are accepted, and the target time to begin responding
• The severity classification for incidents and the response policy for each classification
• The procedure for quoting and ordering work that falls outside the flat-fee scope
• How liability for nonconformity with the contract during development (covered by free correction) relates to the maintenance contract (paid response)

That last point in particular tends to be overlooked. Whether a defect found right after delivery falls under the development contract’s liability for nonconformity, or is handled under the maintenance contract, is a point that easily leads to disputes unless the period and conditions are clearly spelled out in the contract.

6. The Client Has Obligations Too — Cooperation and Project Management

This is a slight expansion from the topic of contracts, but it is an important idea that the model transaction and contract’s commentary — and case law — have repeatedly emphasized: system development is a joint effort between the client and the vendor, and both sides have obligations to fulfill.

• The vendor bears a duty to manage the project appropriately as a professional and to explain any risks that arise (a project-management obligation)
• The client bears cooperation obligations, such as deciding requirements, providing information about the business operations involved, and making necessary decisions within the required timeframe

In other words, if the client hands everything over to the vendor — a so-called “throw it all over the fence” approach — on the grounds that “we don’t understand the technical side,” requirements never settle, and if the project fails, the client’s own cooperation obligation can end up being questioned as well.

The model transaction and contract builds in a mechanism for documenting the division of roles between both parties and sharing progress and issues through a liaison council (a regular meeting). Read not so much as a contract template but as a rulebook for jointly running a project, it is a document with a great deal to offer the client too.

7. Handle Specification Changes Through a “Change-Management Procedure”

Requests like “actually, we’d like this screen changed like so” cropping up midway through development are unavoidable. The problem isn’t the change itself — it’s letting the change proceed purely through verbal or email exchanges.

• The client thought, “it was meant to be a minor change”
• The contractor thinks, “we handled it, but the effort ballooned, and we want to bill extra”

Verbal or email exchanges can serve as a record of the negotiation, but without a document formally agreed to by both sides covering the scope, cost, and delivery-date impact of the change, once you reach this state it tends to devolve into a “he said, she said” argument.

The model transaction and contract lays out a change-management procedure. Broadly, the flow is:

Change proposed (by either party)
        ↓
Content, scope of impact, cost, and delivery-date impact presented in writing (a change proposal)
        ↓
Both parties confer
        ↓
If agreed, the change is implemented and recorded in writing / if not agreed, things proceed as originally planned

The key point is agreeing on the cost and delivery-date impact together with the content of the change, before work begins. It is one extra step procedurally, but that one extra step is what prevents “he said, she said” disputes.

8. There Is a Dedicated Model Contract for Agile Development

Everything explained so far assumes a waterfall-style contract premised on deciding requirements first and then building.

For agile development, on the other hand — where requirements are revisited as you build — a dedicated model contract, the Information System Model Transaction and Contract (Agile Development Edition), was published on March 31, 2020.

The agile edition has the following characteristics:

• It assumes a quasi-mandate contract as its base type, because agile is a method premised on adding, changing, and reprioritizing features as development proceeds, which does not fit a contract-for-work structure that fixes the deliverable up front
• It adopts Scrum as the development methodology and builds role assignments (such as the product owner) into the contract itself
• It comes with a pre-contract checklist, structured so that the client and contractor confirm the project’s purpose and their mutual understanding of agile development before proceeding to sign

The design is not “it’s agile, so the contract can be vague,” but rather “precisely because this is development that responds to change, the roles and process need to be made explicit in the contract.”

Summary

Here is a summary of the thinking on contract development and operations/maintenance contracts that can be learned from IPA’s Information System Model Transaction and Contract.

• Don’t bundle the whole development effort into a single contract; split it by phase (a multi-stage contract)
• Planning and requirements definition, where “what to build” is decided, uses a quasi-mandate; development from internal design onward, where what is being built is already fixed, uses a contract for work as the default (external design can go either way)
• A contract for work carries the duty to complete plus liability for nonconformity with the contract; a quasi-mandate carries the duty of due care — the nature of the contractor’s responsibility differs between the two
• Operations and maintenance defaults to a quasi-mandate, with the line between the flat-fee scope and individually quoted work documented at contract time
• The client also has cooperation obligations, and handing everything over to the vendor sets a project up to fail
• Route specification changes through a change-management procedure, and agree on the cost and delivery-date impact together with the change itself
• Agile development has its own dedicated model contract premised on a quasi-mandate structure

The model contract template and its commentary can be downloaded for free, in Word format, from IPA’s website. Whether you are about to outsource development or have just been handed a contract to review, it is a document worth reading through at least once.

For Those Considering Outsourcing System Development or Maintenance

Choosing the right contract structure first requires sorting out “what is being built,” “how much is being outsourced,” and “how roles are divided between client and contractor.”

At Komura Software LLC, when we take on consultations about contract development or maintenance of Windows business applications and web systems, we propose following the multi-stage contract thinking described in this article, separating the requirements-organization stage from the development stage. Even if you are still at the point of sorting out the development scope and deliverables, you are welcome to start by simply discussing your current operations with us.

Related Articles

Recent articles sharing the same tags. Deepen your understanding with closely related topics.

Related Topics

These topic pages place the article in a broader service and decision context.

Where This Topic Connects

This article connects naturally to the following service pages.

Frequently Asked Questions

Common questions about the topic of this article.

What is the difference between a contract-for-work agreement and a quasi-mandate agreement?

A contract-for-work agreement (ukeoi) pays for 'completing an agreed-upon deliverable,' and the contractor bears both the duty to complete the work and liability for nonconformity with the contract. A quasi-mandate agreement (jun-inin) pays for 'performing work as a professional' (in the outcome-based variant, payment is tied to an agreed-upon outcome), and the contractor owes a duty of due care as a professional but does not bear a duty to complete the work. Phases where you can clearly define what is being built and the standard for completion are suited to a contract-for-work agreement; phases that support the client's own deliberation or that consist of ongoing work are suited to a quasi-mandate agreement.

Why is a quasi-mandate contract recommended for the requirements-definition phase?

Because requirements definition is the phase where the client, not the vendor, takes the lead in deciding 'what to build,' with the vendor supporting that process. In addition, because the deliverable often cannot be concretely fixed at the outset, promising a duty to complete (a contract-for-work commitment) at this stage leaves the standard for completion ambiguous and becomes a source of disputes. IPA's model contract likewise assumes a quasi-mandate structure for the planning and requirements-definition phase.

For operations and maintenance, is a contract-for-work or a quasi-mandate agreement better?

Continuous work such as uptime monitoring, handling inquiries, and initial investigation of incidents does not fit the concept of 'completion,' so a quasi-mandate structure is the default. On the other hand, feature additions or screen changes whose content and completion criteria can be clearly defined can be carved out individually and contracted for as a contract-for-work item. It is important to document, at the time of contracting, exactly what is included in the monthly maintenance fee and what is quoted separately.

Can IPA's model contract be used as-is?

The model contract is published in Word format on the assumption that you will revise it to fit your own transaction. Because it is drafted from a neutral standpoint that does not favor either the client company or the IT vendor, it is useful as a starting draft for your own contract, or as a benchmark for comparison when reviewing a contract presented to you. That said, for any individual contracting decision, we recommend consulting a lawyer or other specialist.

Author Profile

Profile page for the article author.

Go Komura

Representative of KomuraSoft LLC

Focused on Windows software development, technical consulting, and investigations into failures that are difficult to reproduce.