A practical acceptance test before a project team starts work

Why a mobilisation check matters

Projects rarely fail because a team does not work hard enough. They lose time when work starts before the team shares the same answer to a few basic questions: what is included, what information is reliable, who can decide, and what makes a change legitimate.

That problem occurs across engineering, recruitment, technology and business projects. A short mobilisation acceptance check cannot remove uncertainty, but it makes uncertainty visible before it becomes rework, a missed handover or a promise that the delivery team cannot safely meet.

This is a vendor-neutral working checklist for project owners, delivery leads and specialist suppliers. It is not a contract, risk assessment or substitute for discipline-specific design review. Use it at the point where a commercial commitment becomes a delivery assignment.

The 10-point readiness test

Mark each item ready, conditional or not ready. “Conditional” is acceptable only if the owner, due date and impact are recorded.

1. Define the outcome before assigning tasks

Start with the result the customer needs, not a list of activities. A useful outcome statement has three parts:

1. the deliverable or service;
2. the acceptance condition; and
3. the boundary of responsibility.

For example, “provide a reviewed draft design package for client comment” is clearer than “support the design.” It tells the team what they are producing, what happens next and what it does not promise.

Where outcome wording is still uncertain, record that as a conditional item. Do not hide it inside task notes.

2. Surface assumptions and exclusions

Assumptions are not a problem; invisible assumptions are. During mobilisation, ask each discipline or workstream to state the conditions it is relying on. Examples include the availability of data, access to a site, timely client decisions, existing system compatibility or the need for a third-party review.

Pair every important assumption with one of three responses:

• confirm it before work begins;
• assign an owner to validate it by a set date; or
• plan the work so that the assumption can be changed without losing the entire schedule.

Likewise, make exclusions explicit. An exclusion does not reduce service; it prevents a later misunderstanding about whether a task was included.

3. Confirm the minimum inputs

Teams should not be asked to “start and see what is missing.” Set up a minimum-input list for the first milestone. It may contain technical data, existing documents, access permissions, a recruitment brief, a software account, a nominated client representative or a decision on priorities.

For each input, record:

• description and format;
• source and owner;
• due date;
• how delivery is checked; and
• what work is affected if it is late or incomplete.

This turns missing information into a managed dependency rather than an after-the-fact explanation.

4. Match the people to the actual work

Capability is not the same as availability. Confirm the person who will lead the work, the specialist support required, an alternate where needed and the time actually available within the first milestone.

The delivery lead should be able to say: “These are the named people, this is the work each owns, and this is what happens if one becomes unavailable.”

This applies equally to a short advisory task and a multi-month delivery programme. A brief resourcing check at mobilisation is cheaper than a mid-project handover.

5. Map interfaces, not just organisations

An interface exists whenever one person’s output is another person’s input. Make the important ones visible in a simple table.

The table is useful because it shows a gap immediately: if an input has no owner or acceptance check, it is not yet controlled.

6. Make constraints part of the start decision

Do not treat safety, quality, privacy, site access, regulatory obligations and customer timing as separate administrative issues. They determine whether the work can start and what “ready” means.

Record relevant constraints early and identify any specialist review that is mandatory before progressing. If the project has significant safety or technical risk, use the organisation’s formal risk and assurance processes; this general checklist should never be used to bypass them.

7. Establish decision rights and change control

A project does not need a complicated governance model to be controlled. It does need an answer to two questions:

• Who can make a decision about scope, priority or acceptance?
• How is a requested change recorded, assessed and agreed?

Use a short change record with the request, reason, impact on scope/time/cost/risk, decision owner and date. If a change is too small to record, agree the threshold at mobilisation. This gives the team permission to raise changes early rather than absorb them silently.

8. Hold a short readiness review

Before the first work package starts, bring the delivery lead, relevant specialists and customer representative together for a 20–30 minute review. Work through the ten checks and agree one of three outcomes:

• Ready: work starts as planned.
• Ready with conditions: work starts only on the items not affected by outstanding conditions; assign each condition.
• Not ready: delay the affected work and resolve the blockers first.

Capture the result in one page. The value is not the meeting itself; it is the shared record of what the team was entitled to rely on.

Mobilisation record

Use it again at every major handover

The same check is useful when a phase closes, a new supplier joins, a key person changes, or a project moves from definition into execution. Repeating it at those points gives the next team a better start than relying on informal knowledge transfer.