Cross-team dependencies: getting estimates from every impacted team

Most late projects weren't badly estimated by the team that did most of the work. They were late because of the team nobody asked: the integration team that needed three months' notice, the security review queue, the data team whose change was "just a small extract."

Cross-team dependencies are the most common source of delivery surprises in technology portfolios. The fix isn't better estimating by the primary team. It's asking every impacted team before the commitment is made.

Why dependencies are found too late

• Requests describe one team's work. The requester knows which system they use, not everything that system connects to.
• Estimates come from one source. The primary team estimates its own work and assumes others will "just do their part."
• Supporting teams aren't in the decision forum. By the time they hear about the project, the date has been announced.
• Specialists are shared. Security, data, infrastructure and integration teams serve everyone, so their queues are invisible to each individual project.

A simple process for impacted-team estimates

1. Identify impacted teams at intake

Use your product and technology map to see which products a request touches and which teams own them. Ask the requester and the primary team: "What else does this change affect?" Capture the list as part of assessment.

2. Ask each impacted team three questions

Keep the request light, so teams answer quickly:

1. Is there work for your team? (Yes, no, or unsure.)
2. If yes, roughly how big? (Use the same relative scale as everyone else, such as small, medium or large.)
3. When could you realistically do it, given your current commitments?

A relative size and an honest window are far more useful than a detailed hour estimate.

3. Make the estimates a gate before commitment

Don't commit to a date until every impacted team has answered. This is the step most organizations skip, because waiting feels slow. But a week spent gathering estimates is much cheaper than a quarter spent discovering them. See Stage gates without bureaucracy.

4. Use the slowest window, not the average

A project can't finish before its slowest dependency. If the integration team can't start for eight weeks, the plan should say so, even if the primary team could start Monday.

5. Track dependencies during delivery

Record each dependency with an owner and a needed-by date. Review open dependencies at the same rhythm as delivery progress. A dependency that slips is an early warning that the commitment is at risk. See Leading indicators of project trouble.

An example

A request to automate supplier onboarding is assessed:

Without this table, the plan would have been based on the primary team's "next month." With it, the realistic start of integrated delivery is at least ten weeks out, and Finance Systems needs a conversation before anyone commits. That changes how the request compares with others in prioritization.

Reducing dependencies over time

Estimates manage dependencies; architecture and team design reduce them. Look at which dependencies appear again and again. A team that's on the critical path for most projects may need more capacity, self-service tooling, or a change in how work is split between teams.

Common objections

"Asking every team slows us down." It moves discovery earlier. Total time to delivery is usually shorter.

"Supporting teams won't answer." Make it a simple, time-boxed request with a default: no answer in five days means the request waits. Escalate patterns, not individual delays.

"We'll find out during delivery anyway." Yes, at the most expensive point, after the date has been promised.

How Aizu helps

In Aizu, each initiative is placed within your product model, which makes the affected products visible during assessment. Delivery confidence views show dependencies and risks alongside scope and capacity signals, and gate checks before commitment can require that dependencies and estimates are confirmed. Delivery evidence from Jira or Azure DevOps keeps the picture current once work starts. Related: IT capacity planning.