The First Implementation Brief: What to Include and Leave Out

A ranked opportunity is not yet a build brief. “Improve RFQ intake” could mean a form change, a routing rule, a CRM integration or a technical qualification process. Unless someone chooses the boundary, the first sprint can quietly become all four.

This guide starts after the team has selected a problem. For choosing between problems, use the prioritisation guide. Here the task is to specify work that can be accepted or rejected without another debate about what it was meant to achieve.

Write the excluded work while the scope is still small

Exclusions protect the first test. If the change is meant to preserve enquiry context and assign an owner, say that equipment selection, pricing and automatic external responses are outside scope.

A request to add them may be reasonable, but it changes the evidence, permissions and review needed. Treat it as a scope decision rather than a minor enhancement that slips into a meeting note.

A brief the receiving team can challenge

Problem

Clarified enquiries can wait because regional sales and application engineering do not share an explicit review state.

Change

Preserve the original enquiry context, assign the approved owner and expose whether technical review is pending or complete.

Decision owner

The sales-operations role approves routing; the engineering lead approves the meaning of technical-review states.

Excluded

Automatic quotation, product substitution, historical CRM migration and outbound marketing.

Dependencies

Agreed territory rules, permitted test records, CRM access and an available reviewer.

Acceptance

Known routes reach the intended owner; ambiguous cases remain visible; retries do not duplicate records; attachments remain accessible to authorised users.

Stop condition

Pause if permissions cannot be restricted or original technical context is lost.

The example describes a proposed process, not measured customer results. Replace its assumptions with an observed baseline before using it to authorise work.

Agree how acceptance will be tested

Compare "routing works" with "an enquiry from an existing distributor reaches the approved account owner; its attachment remains accessible; an uncertain match stays in review; replaying the same request creates no duplicate". The second version gives the receiving team something to reject. It does not claim faster sales until operating evidence exists.

Use the editable one-page brief to record the problem, excluded work, owner, prerequisites and test cases. The example is filled; a blank section follows. A handover is incomplete if only the developer can explain how acceptance was decided.

Choose representative cases with the team who receives the result. Include a normal enquiry, an existing-account exception, missing information and a failed delivery or retry. Record the expected outcome before implementation.

Separate functional acceptance from commercial evaluation. A routing rule can work correctly on the test set without yet proving faster response across the business. The latter needs operating evidence after release, with other changes recorded.

Likewise, distinguish a defect from a newly discovered requirement. If nobody agreed how distributor enquiries should be handled, that gap must be resolved before the developer can meaningfully pass or fail the route.

A planning horizon is not a delivery guarantee

A 30-day plan can help a team coordinate investigation, implementation and review. It should not promise completion of a migration or integration before access and dependencies are known.

Use the first part of the period to confirm the baseline and test conditions. Release a bounded change only when prerequisites are met. Preserve time for review and correction rather than treating the final day as the first opportunity for sales to see the result.

If a dependency slips, name what can proceed and what must wait. Do not fill the gap with unrelated work just to report activity.

Include operation and exit in the handover

The owner needs configuration notes, failure handling, access ownership and a way to reverse the change. Agree who receives an alert and who can act on it. A demonstration recording does not substitute for those details.

Keep the deliverable usable by the internal team or another implementation partner. An audit or strategy engagement should not make the next supplier choice inevitable.

Close with a decision

At review, show the accepted and failed cases, operating observations and remaining assumptions. Expand only if the next scope has a defensible purpose. Revise if the problem is worth solving but the current intervention is weak. Stop if the evidence no longer supports the work.

A small completed intervention with an intelligible acceptance record is a better foundation for the next investment than an ambitious roadmap whose first item is still open to interpretation.