Working with clients: contracts, scope and communication

Team Lumen does not own Driftwood's product; Driftwood does. That changes the product manager's job. In a product company the PM negotiates priorities with colleagues; in client work the PM, often called an engagement manager or delivery lead, must also manage a commercial relationship governed by a contract. Money, intellectual property, confidentiality, acceptance and liability all become explicit. This lesson covers the documents and practices that make client delivery work: statements of work, contract types, change control, intellectual property and licensing, confidentiality, communication cadence and the perennial problem of scope creep. For contract law and procurement in depth, see PMP-140 and BUS-220; nothing here is legal advice, and real contracts should be reviewed by a lawyer.

The statement of work

A statement of work (SOW) defines what a vendor will deliver for a client: objectives, scope, deliverables, milestones, acceptance criteria, assumptions, responsibilities on both sides, schedule, pricing and payment terms, and how changes are handled. It typically sits under a master services agreement (MSA), which holds the long-lived legal terms such as liability, confidentiality, intellectual property and dispute resolution, so that each new piece of work needs only a new SOW. A good SOW is specific enough to prevent disputes and flexible enough to allow learning.

Contract types

The pricing model decides who carries the risk of the work taking longer than expected. In a fixed-price contract, the vendor agrees to deliver defined scope for a set price; the client gets cost certainty, and the vendor carries overrun risk, so vendors add a risk premium and resist scope changes. In time and materials (T&M), the client pays for actual hours at agreed rates; the client carries the risk, but gains flexibility to change direction. Capped T&M pays actual hours up to a maximum, sharing risk. Many agile teams use hybrids: fixed price per sprint or per increment, with scope chosen sprint by sprint from a prioritized backlog, and a right for either side to stop after any increment.

# Who carries the risk? Simulate actual effort for a project estimated at 400 hours
# and compare client cost and vendor margin under three contract types (illustrative).
import random
random.seed(401)
rate, est = 110.0, 400            # hourly rate and estimated hours
fixed_price = rate * est * 1.25   # vendor adds a 25% risk premium to a fixed bid
cap = rate * est * 1.15           # capped T&M: client pays actual hours up to a cap
runs = 10000
res = {"fixed": [], "t&m": [], "capped": []}
for _ in range(runs):
    actual = est * random.lognormvariate(0.10, 0.35)   # skewed: overruns are common
    cost = rate * actual
    res["fixed"].append((fixed_price, fixed_price - cost))
    res["t&m"].append((cost, 0.0))
    paid = min(cost, cap)
    res["capped"].append((paid, paid - cost))
for name, rows in res.items():
    client = sorted(r[0] for r in rows)
    vendor = [r[1] for r in rows]
    loss = sum(v < 0 for v in vendor) / runs
    print(f"{name:7s} client median {client[runs // 2]:8.0f}  client p90 {client[int(runs * .9)]:8.0f}"
          f"  vendor loses money in {loss:5.1%} of runs")

fixed   client median    55000  client p90    55000  vendor loses money in 36.1% of runs
t&m     client median    48671  client p90    76438  vendor loses money in  0.0% of runs
capped  client median    48671  client p90    50600  vendor loses money in 45.5% of runs

The simulation shows the trade-off. Under fixed price, the client always pays the same, including the premium, and the vendor sometimes loses money when effort overruns. Under T&M the client's cost varies widely and the vendor never loses. Capped T&M protects the client's budget almost as well as fixed price without paying the premium, so the vendor absorbs every overrun above the cap and loses money more often than under fixed price. None is universally best. Fixed price suits well-understood work with stable requirements; T&M suits discovery-heavy work where scope will change; agile increments suit products where the client wants to steer based on what each increment teaches. Because Driftwood's product depends on discovery and a feasibility pilot, Team Lumen proposed a fixed price for the discovery phase and per-sprint pricing afterwards.

Change control and scope creep

Scope creep is the gradual, uncontrolled growth of a project's scope without matching changes to time, budget or resources. It rarely arrives as one big request; it arrives as many small ones: could the schedule also show fares; the island association asked whether we could add road cameras; the regulator wants every page in a second language. Some changes are valuable and should happen; the problem is changes that happen without anyone deciding to trade something for them. Change control is the process that makes each change a decision.

A simple change control process has four steps. The request is written down, with who asked and why. The team assesses its impact on scope, schedule, cost, risk and quality. The client's decision-maker approves, rejects or defers it, choosing what to trade. And the decision is recorded and the plan updated. In fixed-price work, approved changes usually come with a price; in agile contracts, they usually displace lower-priority backlog items. The code applies this logic to three requests against the capacity forecast from lesson 7.

# Assessing a change request against remaining capacity (invented numbers).
remaining_capacity = 34        # items the team can finish before the summer date (85% forecast)
committed = 30                 # items already in the release
requests = [
    ("Show fares on the schedule page", 3, "Should"),
    ("Integrate with regional road-camera feed", 9, "Could"),
    ("Second-language version of all pages", 6, "Must"),
]
slack = remaining_capacity - committed
print(f"slack before changes: {slack} items")
for title, size, moscow in requests:
    if size <= slack:
        slack -= size
        verdict = "accept within current plan"
    elif moscow == "Must":
        verdict = f"accept only by swapping out {size - slack} items of lower priority, or extend"
    else:
        verdict = "defer to a later release or fund as additional scope"
    print(f"- {title} ({size} items, {moscow}): {verdict}")
print(f"slack after decisions: {slack} item(s)")

slack before changes: 4 items
- Show fares on the schedule page (3 items, Should): accept within current plan
- Integrate with regional road-camera feed (9 items, Could): defer to a later release or fund as additional scope
- Second-language version of all pages (6 items, Must): accept only by swapping out 5 items of lower priority, or extend
slack after decisions: 1 item(s)

The second-language version is a must in this example because of a regulatory expectation, so it goes in only by swapping out lower-priority work or extending the date: the client chooses which. The road-camera feed is deferred. The point is not the arithmetic but that every change is visible and someone with authority made the trade. Burn-up charts that show total scope as a separate line make creep visible too.

# Scope creep made visible: a burn-up chart's numbers, with scope growing each week.
done_per_week = [4, 5, 3, 6, 5, 4, 6, 5]
scope = 40
added = [0, 3, 2, 4, 0, 5, 3, 2]           # items added by change or discovery
done = 0
print("week  done  scope  remaining")
for w, (d, a) in enumerate(zip(done_per_week, added), start=1):
    done += d
    scope += a
    print(f"{w:4d}  {done:4d}  {scope:5d}  {scope - done:9d}")
print(f"scope grew {scope - 40} items ({(scope - 40) / 40:.0%}) while the team finished {done}")

week  done  scope  remaining
   1     4     40         36
   2     9     43         34
   3    12     45         33
   4    18     49         31
   5    23     49         26
   6    27     54         27
   7    33     57         24
   8    38     59         21
scope grew 19 items (48%) while the team finished 38

Intellectual property and licensing

Who owns the code? The answer depends on law and contract, and assumptions are dangerous. A client paying for software usually expects to own it; a vendor may want to reuse its own libraries across clients; and the code almost certainly includes open-source components with their own licences. The contract should say explicitly who owns newly written code, what pre-existing vendor materials are licensed rather than assigned, and what the client may do with them.

In Canada, under the Copyright Act, the employer owns copyright in works made by an employee in the course of employment, unless agreed otherwise. Independent contractors, however, generally own the copyright in what they create unless they assign it in writing. A client that hires a contractor or a student team without a written assignment may end up with only an implied licence to use the code. Canadian law also gives authors moral rights, including the right to be associated with the work and to its integrity; these cannot be assigned but can be waived, and IP clauses in Canadian contracts commonly include a moral rights waiver. University policies may also say who owns student work, so student teams should check their institution's IP policy before signing anything.

Open-source licences matter too. Permissive licences such as MIT, BSD and Apache 2.0 allow use in proprietary products with attribution (Apache 2.0 also includes an express patent licence). Copyleft licences such as the GPL require that distributed derivative works be released under the same licence; the AGPL extends this to software offered over a network, which matters for web services like Driftwood's. The team should keep an inventory of dependencies and their licences, often called a software bill of materials, check compatibility with the client's plans, and hand it over with the code.

Confidentiality and NDAs

A non-disclosure agreement (NDA) or confidentiality clause obliges parties to protect each other's confidential information: business plans, customer data, pricing, source code. NDAs can be one-way or mutual, and define what counts as confidential, permitted uses, exceptions (information already public or independently developed), how long the obligation lasts and what happens to information when the relationship ends. For student teams, NDAs can conflict with the need to present work for grading or in a portfolio, so agree in advance what may be shown publicly, for example a demo with invented data and no client financials. Personal information about travellers is governed by privacy law regardless of what the NDA says (lesson 12).

Communication and governance

Most client relationships fail through communication rather than code. A communication plan sets the cadence and audience for each kind of update. Team Lumen agreed on: a weekly 30-minute check-in with the client owner for decisions and blockers; a sprint review every two weeks with staff representatives; a one-page written status report every Friday covering progress against goals, risks, decisions needed and budget burned; and a steering meeting each month with the owner and Driftwood's finance lead to review the roadmap and contract. Escalation paths say who to contact when something is stuck, and on what timeline.

Good status reports are honest early. Green, amber and red status labels are useful only if amber appears before red: a project that is green every week until it is suddenly red has hidden its problems. When news is bad, deliver it quickly, with what happened, the impact, options and a recommendation. Clients forgive late features far more easily than surprises. Managing expectations also means saying no clearly, using the techniques from lesson 4, and confirming verbal agreements in writing: a short email after each meeting summarizing decisions prevents most later disputes.

Acceptance, handover and the end of an engagement

Acceptance is the client's formal confirmation that a deliverable meets the agreed criteria, often tied to payment. The SOW should define acceptance tests, a time limit for the client to accept or report defects, and what happens if the client neither accepts nor rejects (deemed acceptance). Handover includes the code repository, deployment credentials transferred to the client's accounts, documentation, the dependency and licence inventory, runbooks for operations, and training for whoever will maintain the product. A product nobody can operate after the vendor leaves is a liability, not an asset.

Worked examples