Sourcing Readiness Checklist: Why Procurement Needs Economic Theory Before the RFP
Procurement professionals make decisions about outsourcing, competition, supplier dependence, and contract design almost every day.
Transaction Cost Economics, Incomplete Contracts, and Property Rights Theory should be part of their basic working knowledge.
Some procurement training curricula do not cover these core economic theories at all; others mention them but stop just as the practical questions begin. Meanwhile, these questions persist:
Make or Buy?
What should I ask the business?
What would change my sourcing approach?
Which risks should I deal with in the contract?
This article and the Sourcing Readiness Checklist are meant to bring these theories into everyday procurement work and show their practical value. They don't provide a universal answer or a magical justification. They help us identify the characteristics of a purchase that should shape how we organize the work, approach the market, and decide who controls it when the original plan changes.
Consider a company preparing to tender a custom application connected to its internal systems. The business has a target date and a budget, but it is still discovering the integrations, future demand is uncertain, and the delivery team expects to refine features after work starts.
Launching an RFP may create the illusion of progress. It may also lock unresolved decisions into supplier assumptions, different bid prices, and a long series of change requests. This is the sort of case the checklist is designed to examine before the tender begins.
Transaction Cost Economics: what are we really buying?
The make-or-buy question is often reduced to comparing an internal cost estimate with a supplier quotation.
Coase pointed to the costs of using the market; Williamson developed the analysis of transactions and the governance arrangements used to manage them. Finding a supplier, defining requirements, monitoring performance, renegotiating changes, and resolving disputes all require resources. Their importance varies with the nature of the transaction.
That is why the first part of the tool asks about
asset specificity,
frequency,
volume uncertainty,
technological uncertainty,
behavioral uncertainty.
If a supplier must acquire knowledge or build interfaces that have little use elsewhere, switching may become difficult after implementation.
If the work repeats, maintaining internal capability or building a durable relationship may make more sense than returning to the spot market. If performance is hard to observe, an apparently attractive external price may conceal a substantial governance burden.
None of this means that a specialized transaction must always be brought in-house. In our application example, the company may have no credible internal development capability.
The checklist therefore checks market availability, internal capability, and urgency alongside the transaction characteristics. It can show a provisional preference for internal control while also pointing out that the organization cannot currently deliver that option. That conflict is more useful than a confident recommendation the organization cannot implement.
The make-or-buy calculation in the checklist is an explicit teaching heuristic, not a formula estimated by Coase or Williamson. Its job is to display the assumptions and make them challengeable.
A buyer may still decide to procure externally, retain architecture and data governance internally, and contract for development. Whether that hybrid split works requires a real examination of interfaces, accountability, and capability; the label alone solves nothing.
Readiness is more than choosing Make or Buy
Once the organization decides to go to market, it still needs requirements suppliers can meet on comparable terms.
The second part of the checklist tests business and technical requirements, objective specifications, whole-life cost assumptions, stakeholder agreement and approvals. It distinguishes market consultation, which can clarify requirements, from an expression of interest, which can help determine whether capable suppliers are willing to compete. When requirements remain unclear, a tender document does not replace discovery.
The third part asks a different question: does an eligible sourcing process fit the need-by date? Users enter their own lead times and indicate whether a Public RFP, Limited RFP, negotiation, single source, or contract extension is actually available. Include a proof of concept where needed. The tool works backward from the date required and identifies options that fit the stated assumptions. An urgent date does not, by itself, make single sourcing permissible or a contract extension appropriate. Sometimes the honest conclusion is that the plan must change.
These two gates are procurement discipline, not economic models. I would not claim that a requirements checklist or a calendar calculation was derived from TCE. Their role is to stop an interesting theoretical recommendation from being mistaken for a sourcing process that is ready to launch.
Incomplete Contracts: what happens when the plan changes?
No one can write down every event that might occur during a complex implementation. Oliver Hart's work on incomplete contracts asks a crucial question: who decides on matters the contract leaves open?
A requirement can be agreed at award and still need to change when a new interface, operational constraint, or technical possibility becomes visible. Pretending otherwise generally makes the first change request the start of the real negotiation.
This is where the fourth part of the checklist reuses the first part's answers.
High asset specificity directs attention to data and interface access, work products, knowledge transfer, and exit.
Uncertain volumes require measurable ordering units, rates, and limits rather than an unexplained promise of flexibility.
Technological uncertainty increases the importance of an initial acceptance baseline, decision rights, and a process for approving changes in scope, price, and time.
When supplier performance is difficult to verify, the buyer needs evidence, reporting, review rights and escalation arrangements.
Some future choices should be made jointly as the work develops: demand forecasts, the order of later features, or a technical solution that could not sensibly be selected at award.
Baker, Gibbons and Murphy explain how relational arrangements can be sustained by the value of future cooperation. That possibility is strongest when the parties expect to keep working together and can observe whether commitments are being honored. It offers weak protection if the deal is one-off or performance is hard to observe.
Bajari and Tadelis also show why designing a complex project exhaustively in advance can be costly, while later renegotiation carries its own costs.
Joint adaptation does not mean leaving the commercial foundations to goodwill. The baseline, authority to change it, price mechanism, acceptance, evidence, and exit need to be sufficiently clear. The parties can then decide the genuinely unknown details through the process they agreed in advance.
The tool highlights priorities for that discussion; it does not generate contract clauses or calculate an optimal level of incompleteness.
Property Rights: who retains control when the contract is silent?
Property Rights Theory makes the control question more precise. Grossman and Hart distinguish rights specifically allocated in a contract from residual rights of control over an asset—decisions about uses the contract does not specify.
Ownership matters because the party holding those residual rights is better positioned when circumstances change.
But allocating every asset to the customer is not automatically efficient: taking control from a supplier can also weaken its incentives to invest and improve.
For our application example, the practical questions are immediate:
Who controls the data and production environment?
Can the customer use the interfaces, documentation, and work products with another provider?
Who may decide how a new integration is built if the contract did not foresee it?
Which assets should the supplier control to remain accountable for delivery, and which would create an unacceptable dependency if the customer could not access them?
These questions belong in sourcing and contract planning, while there is still room to negotiate.
The current checklist doesn't calculate an optimal ownership structure from Grossman and Hart's model, but our IT Service Model Selector does. It flags transactions where those control and exit questions deserve attention. That is a modest application of the theory, but a useful one: it directs the buyer toward decisions that a price comparison will never reveal.
What the final report is for
The report stitches together the make-or-buy assessment, missing requirements and market evidence, feasible sourcing options and contract priorities. If it says “Ready for governance review,” it means the checklist conditions pass on the facts entered.
The most useful moment is often when the report says the opposite.
The business wants an external supplier, but no credible market exists.
The requested date doesn't allow for an eligible process.
A specialized asset will make switching difficult, but no one has planned for transition.
We can address each of these decisions before the RFP rather than explain them away after contract award.
Economic theory earns its place in procurement when it changes the questions we ask BEFORE sourcing.
The Sourcing Readiness Checklist puts Coase, Williamson, Hart, and relational contracting into an ordinary sourcing conversation—where we can test their practical value.
Comments