A project can have capable people, executive support, and a well-funded plan—and still stall between departments. Sales promises a launch date before operations confirms capacity. Security discovers a new vendor after the contract is signed. Finance approves a budget without knowing who will own the ongoing costs.
These are not necessarily failures of effort. They are failures of coordination: different definitions of success, unclear ownership, hidden dependencies, and decisions that nobody realizes they are responsible for making.
Effective cross-functional collaboration makes those conditions explicit before they become expensive. The checklist below gives business leaders, department heads, and project owners a practical starting point. Adapt it to the size and risk of the work; it does not require Scrum, a new software platform, or another standing committee.
Before the Work Begins: Establish the Rules
☐ 1. Define one shared outcome
Start with the business problem, not a list of departmental activities. “Deploy an AI assistant” describes an implementation. “Help support staff resolve eligible customer questions faster without exposing sensitive information” describes an outcome that operations, technology, security, and customer service can evaluate together.
Write down:
- The problem and beneficiary: What needs to improve, and for whom?
- The success measure: What evidence will show improvement, and who will collect it?
- The target date: When must the outcome be achieved or evaluated?
- The boundaries: What is explicitly outside scope?
- The completion standard: What must be true before the work is accepted?
For the AI example, evaluation could include resolution time, answer accuracy, and compliance with approved data-handling requirements. Record the baseline and agree on acceptable results before launch.
Ask each function to confirm that its priorities support this outcome. The Scrum Guide offers useful references for shared goals and explicit completion standards, although its formal requirements apply to Scrum teams—not every cross-functional project.
☐ 2. Bring the necessary functions in early
The right participants are not simply the people attending the kickoff. Identify whose expertise, resources, approval, or downstream work the project requires. Ask who will operate the result after the project team moves on.
For a customer-facing technology launch, that might include support, operations, finance, procurement, security, and legal alongside the delivery team. Not everyone needs to attend every meeting. Everyone whose work or obligations could materially affect the outcome needs an appropriate opportunity to contribute.
Atlassian’s Network of Teams practice provides a useful way to examine cross-team relationships early. The practical test is simple: Who could reasonably say, “You should have involved us before making that commitment”?
☐ 3. Assign ownership—and resolve the gaps
Give each deliverable a primary owner. Identify contributors and backup support where needed, then ask the owner to confirm the assignment, capacity, and dependencies. An assignment that someone cannot realistically fulfill is not a reliable commitment.
Look specifically for overlapping responsibilities and work with no owner. Atlassian’s roles and responsibilities practice addresses both problems.
For example, “technology and operations own launch readiness” leaves room for confusion. A clearer arrangement names an owner for technical validation, another for operational readiness, and a project owner who assembles the launch recommendation. Shared contribution should not obscure individual accountability.
☐ 4. Separate participation from decision authority
Being consulted is not the same as having the final call. For consequential decisions, specify who coordinates the process, who decides, whose expertise is required, and who must receive the outcome.
The DACI framework labels these roles Driver, Approver, Contributors, and Informed. Its Approver is one decision-maker, not a consensus committee. You can use those labels or plain language; the important point is clarity.
Decision authority must also respect mandatory controls. A project sponsor’s launch authority does not remove applicable legal obligations or required security approvals. Identify those constraints upfront, along with the route for resolving questions about them.
While Work Is Underway: Make Coordination Visible
☐ 5. Agree on communication rules
Teams do not need more communication everywhere. They need reliable communication in agreed places. Document where the current plan lives, where decisions are recorded, and which channel handles urgent issues.
Set response expectations that account for working hours and time zones. Define “urgent” by business impact rather than the sender’s preference. Also decide when a meeting is warranted—for example, when a trade-off needs discussion or an unresolved dependency threatens a commitment.
Atlassian’s working-agreements guidance supports making these expectations explicit. Keep the resulting agreement short enough to use.
Maintain a brief decision log: record the decision, decision-maker, rationale, and affected work. This helps colleagues understand what changed without reconstructing a conversation from messages and meeting notes.
☐ 6. Make every important handoff explicit
A task can be complete for one department and unusable for the next. Prevent that mismatch by documenting the sending owner, receiving owner, required input, due date, and acceptance criteria for each material dependency.
Suppose procurement hands a proposed vendor arrangement to security. “Vendor information submitted” is not a sufficient completion standard if the submission lacks the intended use, data types, access requirements, or relevant documentation.
The receiving team should confirm what makes the handoff usable before work begins—and acknowledge acceptance when it arrives. If required information is missing, record the gap and its effect on the schedule.
“Sent” describes an action. “Accepted” confirms that the next team can proceed.
This approach extends explicit ownership and completion standards across departmental boundaries. It also makes delays easier to diagnose without turning every missed dependency into a debate about effort.
☐ 7. Establish a route for disagreement
Different functions are responsible for different risks and priorities. Disagreement is therefore something to manage, not something to eliminate.
Agree on who resolves an impasse, what information they need, and when escalation should occur. A useful escalation includes the decision required, available options, business impact, relevant constraints, and the latest responsible decision point.
For example, if a launch depends on an unresolved data-access concern, present viable options: narrow the pilot, change the access design, or move the launch. Make the consequences visible rather than asking leadership to choose between vague demands for speed and safety.
Invite concerns before the decision deadline. Silence is not reliable evidence of agreement. Once the decision is made, communicate it to affected teams and update the plan.
At Milestones and Completion: Improve How the Work Gets Done
☐ 8. Review the collaboration, not just the deliverable
A project review should examine how the result was achieved, not merely whether it shipped. Ask what worked, where coordination broke down, and what should change before the next phase.
Use specific examples: an approval discovered late, conflicting instructions, or a handoff that repeatedly needed rework. Avoid broad judgments about a department’s attitude.
Atlassian’s retrospective practice offers a structured approach. Choose a small set of improvements, assign owners, and check progress at the next review. A retrospective without follow-through documents frustration rather than improving collaboration.
A One-Page Worksheet for Your Next Project
Capture the essentials in a shared document. Use an existing tool and link to supporting material rather than duplicating everything.
- Shared outcome: Problem, beneficiary, and target date.
- Success measure: Baseline, evaluation method, and acceptance standard.
- Scope: Included work and explicit exclusions.
- Deliverable owners: Primary owners, contributors, and confirmed capacity.
- Decision-maker: Authority for key decisions and required approvals.
- Dependencies: Sending and receiving owners, inputs, deadlines, and acceptance criteria.
- Communication rules: Information location, response expectations, and urgent channel.
- Escalation route: Resolver, required information, and escalation trigger.
- Next review: Milestone and owner for checking progress and improvements.
Start With Clarity, Not Another Tool
Cross-functional collaboration does not become dependable because everyone is copied on the same message. It becomes dependable when people understand the outcome, accept ownership, know how decisions happen, and can rely on one another’s handoffs.
Choose one active project and work through this checklist with the people responsible for delivering it. Resolve unclear ownership, confirm the next handoff, and document the decision that is currently blocking progress. Better collaboration starts with making the work—and the commitments behind it—clear.