A custom fabrication business measures its sales team on quote turnaround, its engineering team on how quickly drawings are issued, and its workshop on efficiency. All three are hitting their targets. Customers, meanwhile, complain that orders take six weeks when four were promised, and the owner cannot see why the whole is so much worse than its parts.
The answer is rarely hidden. It sits in the gaps. The order waits between sales and engineering because a site measurement is missing. Drawings wait between engineering and purchasing because the material list arrives late. Finished work waits between the workshop and dispatch because nobody booked the delivery. Every team is doing its job. Every handoff is nobody’s job.
This pattern appears in manufacturers, builders, service firms, hospitals and software teams alike. It is a design problem that owners and managers are poorly placed to see, because the tools they use to view the business, such as departments, budgets, reporting lines and targets, are built around the boxes on the organisation chart rather than the spaces between them. This article explains the kinds of interface that cause trouble, why the most expensive ones fail silently, and a practical method for listing, defining, owning and measuring the handoffs in your business.
Three kinds of interface
Practitioner writing on project delivery distinguishes three kinds of interface that a manager must handle:
- Personal interfaces arise wherever two people work on the same thing and conflict is possible. If they report to different managers, the person coordinating them may have no authority to resolve it.
- Organisational interfaces arise between teams or departments with different goals, habits and technical language. These are widely regarded as the hardest, because they involve conflicting objectives as well as people.
- System interfaces involve everything that is not a person: information passed from one task to the next, schedules, physical and technical dependencies.
All three are real. Usually only the third shows up on a schedule or dashboard.
The wrong interface gets the attention
Managers with technical backgrounds tend to focus on system interfaces, because they are visible: they have data, dates and documents, and progress can be shown. Organisational interfaces have none of these. Nobody gets praised for resolving a mismatch between two departments’ definitions of “complete”. So effort flows to where it can be shown, and the more expensive interface goes unmanaged.
The organisational interface is expensive because it fails quietly. A personal interface failure produces visible conflict, and someone escalates. A system interface failure produces a missed date, and a schedule turns red. An organisational interface failure often produces agreement: two teams each believing a matter is settled, until the consequences arrive.
Coordination is not ownership
A common response to handoff problems is more coordination: another meeting, a responsibility chart, a shared spreadsheet. Coordination helps at the margins. But a meeting held across an unowned handoff still leaves the handoff unowned. It creates a forum where two parties can fail to agree more efficiently. The question is not whether a handoff is discussed. It is whether one person is accountable for what happens there.
Same word, different meaning
Each team’s vocabulary reflects its priorities. When engineering says “risk”, it often means a technical failure. When finance says “risk”, it often means a variance from forecast. When sales says “urgent”, it may mean a customer has asked twice. When the workshop says a job is “complete”, it may mean fabrication is finished, while the customer thinks complete means installed and working.
A single business-wide glossary can help with simple terms, but it can also erase distinctions each team genuinely needs. A more workable approach is to define terms at each important boundary: at this handoff, “ready for production” means these specific things are present, and the people on each side accept responsibility for translating into and out of that definition.
A five-step method
1. List the handoffs
For a key process, such as order to delivery, list every point where work, information or a decision passes between two people or teams who do not share a manager, and where external parties such as suppliers or customers hand things to you. Many small businesses find fifteen to thirty handoffs in a single process. The number itself is often a surprise.
2. Classify them
Mark each as personal, organisational or system. The remedies differ. Personal interfaces need a clear escalation route. Organisational interfaces need agreed definitions and reconciled goals. System interfaces need a specified handoff content and timing.
3. Assign one owner
Give every important handoff one accountable person, not two and not a committee. The owner may sit on either side or neither. Often it is the person responsible for the whole process, which is what integration means in practice.
4. Apply two tests
For each handoff, ask:
- What does each side believe the other will provide, and have they said so to each other in the same words?
- If this handoff failed today, how long would it take anyone to notice?
The second test is the more revealing. A handoff whose failure would go unnoticed for weeks is not being managed, whatever the process documents say.
5. Measure the boundary, not just the boxes
Add at least one measure that only gets worse when the handoff fails: elapsed time at the handoff, rework caused by incomplete handoffs, or the volume of clarification messages crossing it.
What a handoff specification contains
For important handoffs, write a short specification:
| Element | Question |
|---|---|
| Content | What exactly is handed over? |
| Form | In what format, system or document? |
| Timing | By when, relative to what event? |
| Quality | What must be true for the handoff to count as complete? |
| Receiver | Who receives it and confirms it is complete? |
| Exception | What happens if it is incomplete: returned, held or escalated, and to whom? |
A one-page checklist at the most troublesome handoffs, such as an order pack checklist between sales and engineering, often removes more delay than any change inside a department.
Measure handoffs
Measures inside departments tell each team how it is doing. Handoff measures tell the business how the process is doing. Useful examples:
- Waiting time at a handoff, from when work is passed on to when the next team starts.
- Rework caused by incomplete handoffs, such as drawings revised because order information was missing.
- Clarification traffic: emails, calls and meetings whose purpose is to find out what the other side meant.
- First-time-complete rate: the share of handoffs accepted without return.
Rising clarification traffic is often the earliest sign of an undefined organisational interface.
The biggest handoffs
Two handoffs deserve special attention in most businesses. The first is from sale to delivery: what the customer was promised must reach the people who will deliver it, completely and accurately. The second is from project to operations: when a temporary team hands new equipment, systems or processes to the permanent team who must run them. Both are large, both are often poorly specified, and both carry consequences long after the handoff.
Handoffs with customers and suppliers
Some of the most troublesome handoffs cross the boundary of the business. Customers hand over requirements, drawings, approvals and site access. Suppliers hand over materials, documents and confirmations. These parties have no obligation to follow your internal definitions, and their delays are not visible on any internal chart.
The same method still helps. Specify what you need from each party, in what form and by when, and tell them early. A customer information checklist sent with the quote, a clear statement of what “approved for manufacture” means, or a supplier delivery checklist covering documentation and labelling can remove days of chasing. Give someone inside the business ownership of each external handoff, so that missing information is chased promptly rather than discovered when work stops.
After change, interfaces multiply
Restructures, new hires, new systems, acquisitions and new product lines all create new handoffs that inherit no definitions. The months after a significant change are when handoff failures are most likely and least watched. List the new handoffs deliberately after any change.
A worked example
This is an illustration. A custom fabrication business with 30 staff has five teams: sales, engineering, purchasing, workshop and dispatch. Each meets its own target. Sales quotes within two days. Engineering issues drawings within five days of receiving complete order information. The workshop runs at 85% efficiency. Yet customers wait about six weeks for orders promised in four.
The operations manager and team leaders list the handoffs in the order-to-delivery process and apply the two tests. They find:
- Sales to engineering: about 40% of order packs are missing site measurements or finish details. Engineering’s five-day clock starts only when information is complete, so its target is met while orders wait an average of four days for missing information.
- Engineering to purchasing: material lists are issued with the final drawings, but long-lead materials need ordering earlier. About six days are lost on many jobs.
- Definitions: engineering’s “complete” means drawings issued. The workshop’s “complete” means drawings approved by the customer. Jobs reach the workshop that it cannot start.
- Workshop to dispatch: deliveries are booked only when jobs finish, adding about two days.
They assign owners and specifications:
- The sales coordinator owns order-pack completeness, using a checklist that must be complete before an order is accepted.
- The engineering lead owns an early long-lead material list, issued within two days of order.
- The operations manager owns a written definition of “ready for production”, agreed by engineering and the workshop.
- Dispatch books delivery when a job enters its final operation.
Two boundary measures are added: days from order to complete order pack, and days from order to long-lead materials ordered. Clarification emails between sales and engineering are tracked for a month before and after.
Three months later, typical lead time has fallen from about six weeks to about four and a half, and clarification emails between sales and engineering have roughly halved. No department changed how it does its own work. The changes were all at the handoffs.
How this applies to a small Australian business
In small businesses, handoffs are often informal: a conversation, a note, an email. That works while the business is small and everyone talks daily. As it grows, the same informality creates gaps. Practical steps:
- Map your main process from enquiry to payment and list the handoffs.
- Ask both sides of each handoff what they expect from the other.
- Write short checklists for the most troublesome handoffs.
- Agree definitions of key words such as complete, ready and urgent at each boundary.
- Give each important handoff one owner.
- Measure waiting and rework at handoffs, not just output within teams.
- Revisit the map after hiring, restructuring or adding new products.
The articles on systems integration and mapping dependencies across your projects cover related ideas.
Signals worth watching
- Rising clarification emails and meetings between teams.
- Rework concentrated at handoffs rather than within tasks.
- Every team on target while the customer’s experience worsens.
- Problems escalated up two levels before anyone talks sideways.
- Handovers from projects to operations with no receiving owner.
- Definitions drifting after a restructure or new system.
Common mistakes
- Measuring only within departments.
- Treating handoff problems as communication problems solvable by more meetings.
- Giving handoffs shared or committee ownership.
- Focusing on system interfaces and ignoring organisational ones.
- Assuming common words mean the same thing to every team.
- Forgetting new handoffs created by change.
Frequently asked questions
Who should own a handoff, the giver or the receiver? Either can work, as long as it is one person with authority to define what crosses and to fix problems. For handoffs that repeatedly fail, the person responsible for the whole process is often the best owner.
How many handoffs should we manage formally? Start with the five to ten that cause the most delay or rework. Informal handoffs that work well can stay informal.
What if teams resist being measured on handoffs? Present handoff measures as measures of the process, not of individuals, and involve both sides in choosing them. Teams usually welcome measures that show where they are waiting on others.
Where should we start if everything feels tangled? Start with the handoff that generates the most chasing or rework. Fix that one properly, with an owner, a checklist and a measure, and use the result to build support for the next.
Does software solve handoff problems? Workflow software can make handoffs visible and enforce required information, which helps. It cannot decide what should be handed over or who owns it. Define the handoff first, then use tools to support it.
Questions to ask
- Can we name the ten most important handoffs in our main process, and the owner of each?
- Which of our measures would get worse if a handoff failed?
- Where do two teams use the same word to mean different things?
- How long would it take us to notice if a key handoff stopped working?
- Do our process owners have authority to define what crosses between teams they do not manage?
- Which handoffs were created by our last major change, and who defined them?
Bringing it together
Businesses are designed as collections of teams and experienced by customers as a sequence of handoffs. Value is often lost in the gaps, quietly, while every team meets its own targets. List the handoffs, classify them, give each important one an owner, specify what crosses it, test what each side expects, and measure waiting and rework at the boundary. The remedy is not a new structure or another layer of coordination. It is deciding that a handoff is something that can have an owner, and then giving it one.
Source: KEVOS notes, drawing on practitioner writing on interface management in project delivery. Examples and figures in this article are illustrations.
