Our project overlaps with another team's system. Where should the boundary be?
Unclear scope interfaceDefine responsibilities at the interface, including data ownership, handoffs, integration behavior, and acceptance. Avoid using organizational boundaries as a substitute for an end-to-end service definition.
What to do now
- Map the shared user journey
- Identify ownership on each side
- Agree interface deliverables and tests
- Document responsibility for failures and changes
When to escalate
Escalate when
Neither team accepts ownership of an essential interface.
Who decides
The scope owner and authorized sponsor
Example
The application team owns transaction creation while the finance team owns posting validation, with a shared reconciliation test.
Mistake to avoid
Assuming integration belongs entirely to the other project.
Prevent a repeat
Review ambiguous requirements and unresolved acceptance conditions before the affected work begins.
Suggested ApprovedFlow setup
- Projects
- Tasks
- Documents
- Approvals
Keep the agreed scope and acceptance evidence with the project; record any proposed change and its decision separately. See the platform
Related cases
- We are replacing a system. Must we reproduce every old feature?Uncritical legacy scope
- The requirements say the system must be user friendly. How can we test that?Untestable requirement
- When should I escalate a project issue?Unclear escalation boundary
- How do we delegate without losing control?Unclear delegation boundaries