Download Mobile App
A cross-functional team brings people from different departments together to deliver one outcome. The difficult part is often the handoff: design considers a task finished, engineering needs another decision, and marketing has already promised a launch date. Managing that work starts with a shared definition of done and a named owner for each decision.
Start with one outcome and explicit boundaries
Write a short project brief before dividing the work. Describe who benefits, what the team will deliver, how you will check acceptance, and which requests sit outside the project. Ask every function to identify constraints before agreeing to the delivery date. A deadline based only on the build estimate will miss review, training and release work.
Example: a customer onboarding launch might aim to let a new customer complete account setup without a support call. Its deliverables could include the setup flow, help content and support training. A complete billing redesign would remain outside scope. These are illustrative boundaries, not a universal launch checklist.
Give each deliverable an owner and an approver
The owner coordinates completion. The approver accepts the result. Contributors supply expertise, and stakeholders receive updates. One person may hold multiple roles on a small team, but a task assigned to an entire department still needs one named owner. Record a backup when the owner is unavailable.
For the onboarding example, a designer owns the setup flow specification, an engineer owns implementation, and a support lead owns the help article. The project lead resolves tradeoffs that affect several functions. Department managers should agree on available time so project commitments do not silently compete with routine work.
Use this handoff template
- Deliverable: what the receiving person will get, with a link to the current version.
- Owner and receiver: who prepares the work and who confirms receipt.
- Acceptance criteria: the observable conditions that make the handoff complete.
- Needed by: the date and time zone, plus the downstream work it enables.
- Open decisions: the question, decision owner and latest useful decision date.
- Evidence: review notes, test results or the approval record.
Make acceptance concrete. Instead of 'design ready', write 'mobile and desktop screens reviewed, error states included, and implementation questions answered'. The receiver can then accept the work or identify a specific gap without restarting the discussion.
Manage dependencies before adding status meetings
Review the work that is waiting on another person first. Ask what input is missing, who can supply it and when the next action will happen. A blocked task should show that information beside the task itself. If an unresolved decision threatens a milestone, present the decision owner with options and their effects on scope or timing.
Use a short written update for routine progress: completed, next, blocked and decision needed. Reserve a meeting for tradeoffs or problems that benefit from discussion. End it with a decision, owner and follow-up date, then add the result to the project record so absent colleagues can act on it.
Check the operating system after the first milestone
Look for repeated handoff returns, tasks waiting for approval, and conflicting instructions from different managers. Ask whether the cause is unclear criteria, insufficient capacity or missing authority. Change the relevant rule rather than asking everyone to send more updates. Review a small sample of completed tasks with the people who handed them over.
To put this into practice in Edworking, keep the project brief in a shared document, create tasks for the deliverables, and keep handoff discussions with the work. Start with one active project. The useful test is whether a teammate can find the owner, latest decision and next action without asking in a separate chat.
Use the task-assignment guide to turn the brief into owned work.
