Property Rights Theory in IT Outsourcing
Updated: 3 days ago
An ERP support supplier proposes an automation tool. It needs to learn your processes, build integrations, and invest time before the improvements generate a return. Your company must also contribute by providing access, involving business users, improving data, and changing working practices.
If both parties invest, who should own the resulting assets?
How should the benefits be shared? And does closer cooperation require a joint venture?
These questions belong in the sourcing strategy, before the negotiation becomes an argument over IP clauses.
I developed the IT Service Model Selector to make that discussion more structured. It connects three decisions:
how the service will be delivered,
who should own the essential assets, and
how both parties should benefit from improvements.
Why the service description is not enough
A support contract can specify coverage, response times, responsibilities, and charges. It is harder to prescribe every useful improvement either party should discover over the next three years.
Consider a supplier that identifies a way to eliminate recurring incidents. If the supplier is paid by the hour, successful automation may reduce its billable work. Under a fixed fee, lower delivery effort may instead improve its margin, provided service quality is maintained.
The same improvement can therefore face very different incentives under different commercial arrangements.
Asking for “continuous improvement” does not settle how either party will benefit from investing in it.
The theory: ownership changes the incentive to invest
The Property Rights Theory, or GHM Framework, developed by Sanford Grossman, Oliver Hart, and John Moore, examines investment where important contributions cannot be fully specified and enforced in advance.
Ownership provides residual control rights; those rights affect each party’s position if cooperation breaks down, the returns it expects from cooperation, and therefore its willingness to invest.
Giving one party more control can strengthen its incentive to invest while weakening the other’s. The objective is to improve the combined investment outcome.
This explains why “we pay, therefore we should own everything” can be an incomplete commercial argument. The buyer may need control of a custom integration, while the supplier needs to retain the opportunity to develop and reuse its underlying tools.
The risk also runs in both directions. Once a supplier has invested in learning their customer’s processes, the customer may press for concessions due to increased mutual dependency. Once the customer has built its operations around the supplier’s tools, the supplier may gain negotiating power. Anticipating that exposure can discourage useful investment before the relationship even begins.
Transaction Cost Economics and Property Rights Theory both address the organisation of transactions and firm boundaries. The tool applies the property-rights perspective specifically to the investment consequences of asset control. It does not assume that incomplete contracts arise only because people cannot foresee the future: standard property-rights models can retain rational actors while treating relevant contributions as noncontractible.
First decision: what service model fits the requirement?
The tool begins with selecting the IT service delivery model.
Requirement | Initial service-model candidate |
Extra people whose daily work your team manages | Staff augmentation |
A defined project delivered by a supplier | IT outsourcing |
Ongoing supplier responsibility for a service | Managed services |
A standard subscription service | As-a-Service |
The questions also check who will direct daily work and whether successful results can be described and measured. Conflicting answers produce conditions to resolve.
These are practical sourcing rules. The four service labels are not conclusions derived from Property Rights Theory. A managed service can involve customer-owned assets, supplier-owned assets, or a combination of both.
Second decision: should the essential assets be owned together?
The tool asks whether the relevant assets retain their useful value independently or depend heavily on one another.
There is a theoretical basis for considering unified ownership of strictly complementary assets, under the assumptions of the property-rights model. This does not mean that everything connected to an ERP system should have one owner.
For procurement purposes, define the assets under discussion. A custom interface and the component needed to operate it may warrant examination together. That does not imply acquiring the supplier’s entire development platform or the ERP vendor’s intellectual property.
The tool uses the following screening logic:
Your answers | Ownership starting point |
Assets remain useful separately | Start with separate ownership |
Assets depend on each other; the customer’s additional investment matters most | Evaluate customer unified ownership |
Assets depend on each other; the supplier’s additional investment matters most | Evaluate supplier unified ownership |
Assets depend on each other; both parties’ investments are critical | Compare customer and supplier ownership; assess benefit sharing separately |
These recommendations identify candidates for evaluation. They do not calculate an optimal ownership allocation.
Reusability adds another consideration. A supplier may recover value from a tool across several customers. That opportunity may support its willingness to develop it.
Third decision: how should benefits of improvement be shared?
Ownership and benefit sharing answer different questions. A customer can own a deliverable while rewarding the supplier for improvements. A supplier can retain reusable tools while sharing verified benefits with the customer.
The tool asks whether both parties need an incentive to keep improving the service and what benefits can be measured and attributed.
Situation | Commercial starting point |
Both parties contribute to measurable savings | Contractual gainsharing |
Both parties contribute to attributable additional revenue | Revenue sharing |
Both types of benefit can be measured | Separate arrangements for savings and revenue, avoiding double counting |
Benefits cannot yet be measured and attributed | Establish a measurement basis or consider milestones and performance incentives |
This is the tool’s practical commercial logic. Gainsharing and revenue sharing are not presented as automatic prescriptions of Property Rights Theory.
A proposed share still needs a credible baseline, eligible benefits, a measurement period, verification, and quality safeguards. The tool does not invent the percentage either party should receive.
Where does a JV fit?
Sharing benefits does not require a joint venture.
The first option can be a contractual gainsharing arrangement. A JV becomes a further option when the parties also identify a need for joint control of assets and continuing investment decisions—and contractual governance is insufficient.
The tool therefore asks about joint control separately. Both parties investing is not enough to trigger a JV recommendation. Even where shared control is needed, the result is to consider a JV, including its funding, decision rights, deadlock and exit arrangements.
Example: improving ERP support
Consider a hypothetical ERP support arrangement. The supplier invests in specialist learning and automation. The customer funds a bespoke integration and contributes process knowledge, testing and changes to working practices.
Assume that both parties’ contributions are critical, that verified savings can be attributed to the improvement, and that there is no need for joint asset control.
The tool would keep the overall ownership choice open for comparison and recommend contractual gainsharing, with no JV indicated. The optional asset checks would then help examine a possible negotiating position:
Customer ownership or adequate lasting rights to the bespoke integration.
Supplier ownership of reusable background tools, with the usage and continuity rights the customer needs.
A gainsharing arrangement for verified savings from agreed improvements.
That position still needs to be tested against the actual dependencies.
Could a replacement provider use the integration?
Would it need a license to a supplier component?
Does the supplier have enough reason to keep improving the solution?
An ownership clause alone cannot answer those questions. Nor does an upfront payment establish what rights the customer has acquired.
Using the tool
Start with a defined service scope and answer the questions using facts you can support.
Use “Not sure yet” where ownership, reuse, or measurement has not been established.
The results separate the service-model recommendation from ownership, benefit sharing, and joint-control considerations. Optional asset questions examine current ownership, acquired rights, replacement feasibility, and how development is funded. Changing an answer updates the results; the decision record can also be downloaded as JSON.
The current prototype uses transparent rules. It does not calculate investment responses, prices, sharing percentages, or an economically optimal structure. Its purpose is to make the reasoning visible and to identify the commercial questions to resolve before selecting a supplier and agreeing to the contract.
Comments