After the signature: making a contract work from mobilisation to acceptance

Signing a contract creates obligations; managing it makes them work. How to hand over what was agreed, control who instructs, meet your own obligations and accept work properly.

Contract signature feels like the finish line. The supplier is chosen, the price is agreed, the paperwork is done, and everyone turns to delivery. In practice, a different management problem has just started. The person who negotiated the deal knows why a particular exclusion was accepted, what the price assumed and which promises were made in the last meeting. The people who must run the job often receive only the signed document, or not even that. Work starts before anyone has confirmed insurance, who can give instructions, what the customer must provide and how finished work will be accepted.

Most later disputes trace back to these early weeks: an instruction given by someone without authority, a qualification in the supplier’s proposal that nobody on the customer’s side noticed, a deadline missed because the customer was late providing information, or a senior person who rejects finished work after ignoring every chance to review it along the way. None of these is a legal failure. They are failures of managing the contract after it was signed.

This article covers the practical steps that make a contract work: handing over the commercial memory, checking readiness before work starts, controlling who can instruct, tracking obligations on both sides, keeping one coherent set of documents, and designing acceptance so the people who can reject work also review it as it is built. It applies whether your business is the customer or the supplier. It is general information. The effect of particular clauses depends on the contract and the law; get advice on significant contracts and disputes.

Hand over the commercial memory, not just the file

Whoever negotiated the contract carries context the document does not: why a departure was accepted, what risk the price assumed, which interfaces the customer kept, what technical ambiguity was resolved and how. That context needs to travel to the people who will manage delivery.

A short handover meeting before work begins should produce:

  • an agreed list of the documents that form the contract, including accepted qualifications and exclusions;
  • a list of obligations on both sides, with owners and dates;
  • an authority map: who can instruct, approve, accept and escalate;
  • a commencement checklist;
  • a register of known open issues.

A useful test: could a new manager join on the first day of delivery and understand the commercial arrangement without reconstructing the negotiation history? If not, the handover is incomplete. Early surprises in the first month that were already known during negotiation are a reliable sign of a weak handover.

Check readiness before work starts

There is always pressure to start. A visible start looks like progress. But starting physically before the contract is ready to operate creates hidden exposure: insurance not confirmed, security not provided, access only partial, key information missing, representatives unclear, approval routes informal.

Treat the start as a readiness check rather than a calendar date. Confirm:

  • Commercial: the signed contract, security and insurance evidence, the pricing basis.
  • Authority: named representatives and their delegations on both sides.
  • Site and interfaces: access, other contractors, utilities, customer-supplied facilities.
  • Programme: the schedule, milestones and the dates the customer must provide information or decisions.
  • Quality: inspections, tests, hold points, submissions and how defects will be handled.
  • Safety: arrangements and responsibilities at shared sites.
  • Workflow: how payment claims, variations, notices and records will work.

Scale the check to the job. A small service engagement needs a short list; a significant installation needs a proper meeting. What matters is that open items are recorded, owned and visible, not hidden in minutes.

The first weeks also set habits. If they tolerate undocumented instructions and late approvals, those become normal. If they start with clear authority and quick issue resolution, both parties learn that speed and control can coexist.

Control who can instruct

Most organisations contain more people with influence than people with contractual authority. A designer, a site manager, a department head or a keen staff member may ask a contractor to “just make the change” to keep things moving. The work proceeds, and later someone asks who authorised it.

Make the commercial status of communication clear:

  • Name who can give instructions that change the work, and tell the supplier and your own staff.
  • Let technical people discuss options freely, but route any instruction that changes the contracted work through the named channel.
  • Confirm verbal instructions in writing quickly. Site and project work cannot wait for formal letters, so build a fast confirmation habit: a same-day email or message referencing the instruction.
  • Reconcile contract authority with internal approvals. A contract administrator may have power under the contract to direct a variation, while your internal rules require the owner’s approval above a certain amount.

Where a contract appoints someone to assess claims, certify payment or confirm completion, that person’s decisions carry consequences and should be evidence-based, timely and fair, not simply whatever the customer prefers. The variations article covers handling changes once they are proposed.

Track obligations on both sides

A milestone list is not enough. Contracts contain obligations about reporting, insurance, approvals, data, training, warranties, design responsibility and cooperation with other suppliers. Keep a simple obligations register with an owner for each.

Pay particular attention to the customer’s own obligations. Performance is a two-party system: a contractor needs access, a software supplier needs data and decisions, a designer needs approved requirements, an installer needs isolation and permits. If the customer does not provide these on time, it may prevent the supplier performing, and the consequences can shift accordingly. Before declaring a supplier late, confirm that everything the customer had to provide before that milestone was actually provided. Put customer dependencies in the schedule and give each an owner. The when the job runs late article covers how delay caused by the customer is assessed.

Keep one coherent set of documents

Contracts rarely live in one document. There are conditions, drawings, specifications, schedules of rates, the supplier’s proposal, clarifications, qualification letters and later variations. Together they can preserve certainty or manufacture ambiguity. A drawing may show one detail and a specification another; a qualification in the proposal may exclude something the customer assumed was included; a post-tender clarification may never have been incorporated.

At the start, create a contract document register listing every document, its version and status, and the order of precedence if the contract states one. Then:

  • Capture qualifications that matter. A condition or exclusion that affects the work must be in the governing documents if anyone expects it to affect rights and obligations.
  • Keep working documents controlled. A marked-up drawing or meeting note can drive site work before the formal change catches up. Make sure formal records follow quickly.
  • Raise discrepancies early. The best time to resolve an ambiguity is before it is priced; the next best is before work relies on it.

Acceptance: the right to reject and the duty to look

Acceptance is where the customer takes ownership of what was built. It often goes wrong in a predictable way. A senior person holds the right to reject finished work, does not take part in reviews during the build, then objects at the end to something that would have been cheap to change earlier.

Michael Greer, writing on project management in 1999, put the principle simply: anyone with the power to reject or demand revision of completed work should be required to examine and approve it as it is built. Changes are cheap while work is forming and expensive once it is finished, and the cost of a late rejection falls on everyone except the person who made it.

Treat an approval right as a position with duties: taking part in defining what will be built, reviewing interim deliverables promptly, and helping the supplier get access to the people and information it needs. Decide in advance what happens if an approver does not engage:

  • The right narrows: they can still reject for safety, legal compliance or a defect against the written specification, but not for preferences that interim reviews would have caught.
  • The right transfers to someone who did engage, such as a delegate or a technical lead.
  • The right stands, and the business accepts, knowingly, that late changes may follow.

This works only if the work is delivered in reviewable stages, such as prototypes, demonstrations, samples or partial handovers, so there is something to review.

Also keep payment and acceptance separate. Paying a progress claim does not usually mean the work is accepted, and acceptance should rest on agreed evidence, not on the invoice being paid.

Test the contract before you sign it

Before signing a significant contract, walk through a few realistic scenarios with the people who will manage it: a late deliverable, a failed acceptance test, a change request, a key subcontractor being replaced, an early termination. If nobody can say which clause, person and process applies, the contract may be legally detailed but operationally weak. The matching the contract to the work article covers choosing how much contract structure a job needs.

A worked example

This is an illustration. An accounting firm with 30 staff signs a contract with a software implementer for a new practice management system, including migration of client data.

At the handover meeting, the person who negotiated the deal walks the practice manager and the implementer through the documents. A clause in the implementer’s proposal, accepted during negotiation, excludes migrating archived files more than seven years old. The partners had assumed everything would move. Because it surfaces before work begins, the firm can decide calmly: it pays a modest extra fee to migrate the archive in a later stage.

The readiness check confirms the implementer’s insurance and lists the firm’s own obligations: a clean data extract by a set date, a test environment, and staff availability for two training days. The firm names the practice manager as the only person who can instruct the implementer on changes; staff are asked to send requests through her.

The senior partner holds the right to accept the system but is busy with tax season and attends none of the early demonstrations. Applying the acceptance principle, the partners agree that the right transfers to the practice manager, who attends every review, while the senior partner can still reject for data accuracy or compliance problems.

Midway through, the firm’s data extract arrives three weeks late because of a staff absence. The obligations register makes the cause clear, and the implementer’s revised date is accepted without argument.

At acceptance, the practice manager signs off against agreed tests: a sample of client records reconciled, workflows demonstrated and reports checked. There are no surprises, because every concern was raised during the staged reviews.

How this applies to a small Australian business

  • Hold a short handover from whoever negotiated to whoever will manage delivery.
  • Run a readiness check before work begins, scaled to the job.
  • Name who can instruct, and confirm verbal instructions quickly in writing.
  • Keep an obligations register for both sides, including your own dependencies.
  • Keep a document register and capture qualifications that matter.
  • Ask approvers to review work as it is built, and agree what happens if they do not.
  • Separate payment from acceptance.
  • Walk through scenarios before signing significant contracts.

Signals worth watching

  • Early surprises that were known during negotiation.
  • Instructions coming from many people.
  • Customer obligations missing from the schedule.
  • Qualifications in the supplier’s proposal that nobody on your side has read.
  • Senior approvers absent from every review.
  • Payment treated as acceptance.

Common mistakes

  • Treating signature as the end of commercial work.
  • Starting work before readiness is confirmed.
  • Letting anyone instruct the supplier.
  • Tracking only the supplier’s obligations.
  • Leaving document conflicts to be discovered on site.
  • Allowing late rejection by people who never reviewed the work.

Frequently asked questions

Is all this necessary for small contracts? Scale it. For a small job, a one-page checklist covering documents, authority, obligations and acceptance may be enough.

What if we are the supplier? The same steps protect you: confirm who can instruct you, record the customer’s obligations and dates, and ask for staged reviews so acceptance holds no surprises.

How do we confirm verbal instructions without slowing work? A short same-day message stating what was asked, by whom and when, sent to the named contact, is usually enough.

Can we change who accepts the work after signing? Usually, by agreement and in writing. It is far easier to settle early than at handover.

What should acceptance be based on? Agreed tests or evidence defined before work started, not general satisfaction.

Questions to ask

  • Who negotiated this contract, and have they handed over what they know?
  • Are we ready to start, on both sides?
  • Who can instruct the supplier, and does everyone know?
  • What must we provide, by when, and who owns it?
  • Do all our contract documents agree?
  • Will the people who can reject this work have reviewed it along the way?

Bringing it together

A contract creates obligations; managing it turns them into a working relationship. Hand over the commercial memory as well as the document, check readiness before work starts, and make clear who can instruct. Track obligations on both sides, especially your own dependencies, and keep one coherent, controlled set of documents. Design acceptance so the people who can reject work also review it as it is built, and keep payment separate from acceptance. Most contract disputes start as small lapses in the first weeks; a little structure at the start prevents most of them.


Source: KEVOS notes, drawing on teaching material on contract management, mobilisation, contract administration and document control under standard construction and services contracts, and on M. Greer’s project management principles in the Handbook of Human Performance Technology (1999). Examples in this article are illustrations. This article is general information, not legal advice.

Need practical engineering, manufacturing or process support? KEVOS can help move the work forward.