Skip to content

Lesson 1 — Procurement and Vendor Considerations

At a glance

Learning objectives

By the end of this lesson you should be able to:

  1. Run a make-or-buy analysis and justify the decision on lifetime grounds.
  2. Compare contract types and explain how each allocates risk.
  3. Write acceptance criteria that a third party could test.
  4. Manage a vendor relationship through visibility, milestones, and exit terms.

Prerequisites

Introduction

Not all software is built by the people who will use it, and much of it is never built at all — it is purchased, adopted, or partnered into existence. Procuring is a legitimate delivery option, and it changes the shape of the project: the work is still yours to manage, but the lever you control is a contract rather than a task list.

This lesson covers the decision to procure, the contract that encodes it, and the management that turns a contract into a working system.

1. Make or buy

There are four options, not two: build, buy, reuse (adopt what the organisation already has), and partner (joint development). The choice is a comparison, not a default.

Consideration Favours building Favours buying
Strategic importance It is a core differentiator It is a commodity capability
Requirements fit Unusual needs, tightly integrated Standard needs met by a product
Time to value Time is available Faster than building
Lifetime cost Cheaper at scale, once Licence or subscription is cheaper at this scale
Control You need to change it freely The vendor's roadmap is acceptable
Capability The team has the skill The skill is scarce or expensive to hold
Exit Not applicable Dependence is acceptable and reversible

Two considerations are routinely skipped. The first is lifetime cost: a purchase price is the cheapest part of a purchased system, and licence renewal, integration, training, and migration arrive after the decision is forgotten. The second is exit: what happens if the vendor raises prices, changes direction, or disappears? If the answer is "we cannot extract our data", that is an architectural property of your system, not a legal footnote.

2. Contract types and where risk sits

Contracts allocate risk between buyer and seller. There is no risk-free option — only different places for it to sit.

Type Buyer's cost risk Seller's cost risk Sensible when
Fixed price Low High Requirements are stable and well understood
Time and materials (T&M) High Low Work is genuinely exploratory
Cost-reimbursable (+ fee) Highest Lowest The buyer must direct the work closely
Fixed price with incentives Moderate Moderate Both benefit from early or better delivery

The consequences are predictable. A fixed price on unclear requirements produces either a large risk premium in the quoted price or a relationship that degenerates into change-request disputes. T&M on unclear requirements produces a bill that grows without a correspondingly clear outcome.

The lesson is uncomfortable but reliable: the clarity of your requirements, not your negotiating strength, determines the right contract type.

3. Running the procurement

Stage Key activities
Define Requirements, acceptance criteria, and who owns each interface
Select Evaluation criteria, weighted scoring, reference checks
Contract Scope, price, schedule, acceptance, change process, IP, confidentiality, exit
Manage Progress visibility, milestone acceptance, issue escalation, relationship
Close Final acceptance, handover of artefacts, support terms, data extraction

Three disciplines carry most of the value.

Write acceptance criteria before the work starts. "Satisfactory integration" is untestable and becomes a negotiation about interpretation. "Submits a test transaction to the sandbox and records the response code" can be checked by anyone.

Require visibility. A vendor's schedule is your schedule, and you cannot monitor what the contract does not require you to receive. Agree in advance what progress information arrives, in what form, and how often.

Specify the exit. Who owns the source code? What is documented, in what form, and by when? For hosted services, can you extract your data in a usable form, and has that been tested before signing? An untested extraction promise is not an exit plan.

4. Managing the relationship

The contract defines what is enforceable, not what is achievable. Most of the value comes from the relationship: regular contact, early surfacing of problems, and milestone review against agreed criteria.

Signal Likely cause Response
Milestones met, acceptance disputes frequent Criteria are ambiguous Rewrite criteria; agree interpretation formally
Progress information late or vague Contract does not require it precisely Specify format and cadence
Requests for schedule relief early Requirements were unclear Re-baseline explicitly rather than absorbing drift
Reluctance to discuss exit Dependence is real and being protected Test extraction now; escalate
Key staff replaced without notice Contract lacks continuity terms Add continuity and knowledge-transfer clauses

Key terms

Term Meaning
Make-or-buy analysis Comparing building, buying, reusing, and partnering
Statement of work (SOW) The description of work a vendor will perform
Fixed price contract Price agreed in advance; seller carries cost risk
Time and materials (T&M) Paid for time and materials used; buyer carries cost risk
Cost-reimbursable contract Costs reimbursed plus a fee
Service level agreement (SLA) Agreed performance and availability commitments
Acceptance criteria Testable conditions for accepting a deliverable
Vendor lock-in Dependence that makes changing supplier costly

Worked example

Task: decide how to obtain the reporting layer for the illustrative analytics dashboard, and set up the procurement. Figures and criteria are invented for teaching.

Step 1 — Apply make-or-buy. Reporting is not the project's differentiator; users need standard charts, filters, and scheduled exports; two products meet the need; the team has no existing expertise. That favours buy over build or partner.

Step 2 — Examine the exit before committing. A hosted product would hold the only copy of the curated data. This is recorded as a risk with a concrete response: automated nightly extraction into a format the university controls, tested before the contract is signed rather than promised in it.

Step 3 — Choose a contract type and justify it. Requirements are standard and settled, so fixed price is defensible, and implementation cost risk sits with the vendor. Note what does not transfer: schedule, quality, and integration risk remain with the buyer.

Step 4 — Rewrite the vague rows as acceptance criteria.

Stated requirement Acceptance criterion
Single sign-on A user authenticates with university credentials and reaches the dashboard without a local account
Data currency Curated data is at most 24 hours old, verified by comparing a dashboard total against the source system
Export Every dashboard view exports to CSV and opens with correct column types in a spreadsheet
Exit A complete extraction is retrievable in a documented format within 24 hours of request, and the procedure has been exercised once

Step 5 — Require visibility. The contract specifies a weekly progress note covering completed items, upcoming milestones, and anything at risk — in a fixed format, because a format agreed in advance is harder to answer vaguely.

Step 6 — Plan to manage, not just to sign. Monthly milestone review against the criteria in step 4; a named contact on each side; an escalation route for disputes. A contract with no management plan drifts until the first dispute.

Step 7 — Note what would change the decision. If the university later requires unusual, deeply integrated analytics, the make-or-buy answer may reverse — and the exit terms established in step 2 are what make reversing it possible.

Common misconceptions

“Fixed price transfers all the risk”

It transfers cost risk. Schedule, quality, integration, and reputation remain with the buyer. And an under-specified fixed-price contract usually converts cost risk back into disputes.

“The cheapest quote is the lowest cost”

Only if licence, integration, training, and exit costs are comparable — which they rarely are. Evaluate lifetime cost against weighted criteria, and check references rather than brochures.

“A vendor relationship is managed by the contract”

The contract is the fallback. Day-to-day value comes from regular contact, early problem surfacing, and milestone review against criteria both sides understand.

Practical activity

Run a procurement decision. For one example project:

  1. Choose one component and compare at least two of build, buy, reuse, and partner, including lifetime cost and exit.
  2. Choose a contract type and justify it from the stability of your requirements.
  3. Write four acceptance criteria that a third party could test without asking you what they mean.
  4. Specify the progress information you require and how often.
  5. State your exit plan and describe how you would test it before committing.

What "good" looks like: a decision that names its exit strategy, acceptance criteria with an observable action and result, a contract choice justified by requirement stability rather than preference, and an exit test that happens before signing rather than after.

Self-assessment

  1. Why does requirement clarity, rather than negotiating skill, determine the right contract type?
  2. Give one advantage and one risk of a hosted vendor product.
  3. What is wrong with "satisfactory integration" as an acceptance criterion?

  4. Why must you test a data-extraction procedure before signing rather than after?

  5. Apply it — public service information system. A public authority has settled requirements for an accessible forms service and a fixed annual budget. Four suppliers bid; the lowest is 30% below the others and lists one comparable reference.

    Hint: A strong answer chooses a contract type and names what must be in place before signature.

Show answers
  1. Because risk has to sit somewhere. Clear requirements let a seller quote a fixed price confidently and accept cost risk. Unclear requirements make a fixed price either expensive or disputable, so time and materials is the more honest arrangement.
  2. Advantage: faster time to value, with capability that does not have to be built and maintained in-house. Risk: dependence on the vendor's pricing, roadmap, availability, and continued operation — which is why exit terms and tested extraction belong in the decision.
  3. It cannot be tested, so acceptance becomes an argument about interpretation. Testable criteria name an action and an observable result.
  4. Because after signing you have no leverage: the ability to leave a supplier is only real if it has been demonstrated. A promise of extraction is a clause; an exercised extraction is an exit.
  5. With requirements settled and unlikely to change, a fixed-price contract is the right shape: it places cost risk on the supplier, which is what you want when you can define the outcome precisely. The low bid is the thing to manage, not a reason to celebrate. Before signature: verify the single reference and inspect the delivered work rather than the reference letter; write acceptance criteria a third party could test, including the accessibility evidence that is mandatory here; require progress visibility (named milestones, working demonstrations, an inspection right) so a struggling supplier is visible before the end; and settle exit and transition terms — source and documentation handover — while you still have leverage. Then re-check the arithmetic: a supplier that cannot deliver costs more in delay than the 30% saved, and the fixed price only fixes the cost if the requirement really was fixed.

Summary

  • Build, buy, reuse, and partner are all legitimate; compare on fit, lifetime cost, control, and exit.
  • Contract types place cost risk differently, and requirement clarity should drive the choice.
  • Write testable acceptance criteria, require progress visibility, and specify exit before committing.
  • Manage the relationship continuously; the contract is the fallback, not the mechanism.

Further learning

Next

Continue to Lesson 2 — Project Documentation, Closure, and Lessons Learned.