Keep Cross-Team Project Timelines Moving Despite Dependencies

Treating the client's homework as a real task on our board, with their name on it and a due date, was the fix. Soft dependencies are where timelines quietly die. Send it whenever you can becomes never, and your team's stuck twiddling thumbs.
On one launch we needed the client's photos and copy. Instead of asking nicely over email, we added it to ClickUp as a tracked deliverable, owner and deadline set a full week before go-live, with a reminder to keep it on track. We also built the entire site on realistic placeholder content so dev never paused.
When their material landed late, we'd already designed around it and just dropped it in. Assume the dependency will slip, because it nearly always does, and give your own team a way to keep moving without it.

When our timeline depends on another team, we avoid planning as if everything will happen on time. We create a working backlog for the waiting period. It includes research, content refinement, QA criteria, stakeholder alignment, and draft reviews that are often delayed. Naming this backlog helps us use the waiting time in a better way for the team.

We make sure each task is connected to the final goal and not just busy work. We assign one dependency owner who tracks updates and shares changes with the team. This keeps everyone aligned and avoids mixed signals. It helps us keep the schedule steady, smoothly, even when outside work is delayed.

A unique agreement that I have witnessed and implemented while working for a price comparison client is how to visualize and handle wait for third-party within the same work flow using staggered Kanban columns. The team was tasked to build and update live integrations across a hundred insurance providers. There will be times where progress is halted until certain external requirements go live. In this case, it's external to the current team. Sure they can already put a blocked tag on the task cards, but that will just clutter the current development columns and make WIP limit meaningless. This is also misleading in terms of flow and work prioritization.

The modified staggered board column approach was added. We agreed to create "third-party wait" lanes under the dev columns. The catch is that when the task card for a feature that requires the attention, input, or activation from an outside member is blocked, the card will move physically downward to a waiting for provider area. When the issue or requirement goes live, the task won't immediately move back into the dev area; it will first re-stage in the ready for analysis column located at the bottom of the entire board to ensure that when there is capacity in the dev team, work items that are ready can be pulled and not overwhelm the dev team at once. What the team didn't expect was that this practice will help them keep WIP from becoming meaningless and in avoiding unsafe assumptions that may cause multitasking or working ahead.

With 200+ simultaneous integrations on the same board, the approach made it very clear visually how many are waiting on a third party and nicely helped advocate priority with providers and within the company.

Takeaway: If you are plagued with multiple wait for external dependencies, rather than just flagging your blocked work, physically place them on one lateral line outside your typical work flow. This will help keep your schedule and WIP honest, help you quantitatively escalate priorities to leadership, reduce dependency wait from becoming sunk cost, and help you catch up on work in queue as soon as the wait is over. In this case, simply by exposing work blocked by third-parties to promote escalations, the critical path blockage caused by external teams was reduced by approximately 30%.

When a delivery depends on another team, we split the plan into work that needs the dependency and work that can move without it. Waiting becomes a separate track, not a reason for the whole project to stop.

We used this approach on a mobile neobank project in the UAE. The client's legal team was still negotiating with Banking-as-a-Service providers, and the final provider choice would affect parts of the product logic. If we had waited for that decision before starting, the schedule would have lost weeks. Instead, we moved forward with analytics, impact mapping, first-version scope, roadmap, and UI/UX design. We also helped the client define BaaS selection criteria from the development side, so the legal and business team weren't choosing a vendor in isolation from technical constraints.

The agreement that protected the timeline was a clear dependency contract: what the external team had to deliver, by when, and what decisions we could safely make before that delivery. In this case, the client needed to provide the selected BaaS provider, access requirements, and confirmed integration constraints before development estimation became precise. Until then, we treated development estimates as preliminary and used the waiting period for design, scope validation, and architecture assumptions.

This kind of agreement works because it separates uncertainty from progress. The team knows which tasks are blocked, which tasks are independent, and which tasks can proceed with assumptions that will be checked later. It also prevents false certainty. If a vendor decision isn't final, don't pretend the backend estimate is final.

My advice is to make every external dependency visible in the schedule as a named milestone with an owner, a date, and a fallback plan. Then build the sprint around parallel progress: discovery, design, documentation, test planning, architecture options, and backlog preparation. You can't remove every dependency, but you can stop one delayed decision from freezing the whole project.

The agreement that made the biggest difference was building an explicit check-in point into the timeline before the dependency became critical. Instead of waiting to find out a supplier was behind when we needed the material in hand, we started confirming status at a set point earlier in the process when there was still time to adjust. That one habit moved a lot of late surprises into early warnings.
On our side, the way we kept progress moving during a wait was identifying which parts of the order could advance in parallel. Proofing, packaging prep, and customer communication do not always require the dependent piece to be complete. Mapping out what could run simultaneously meant the wait did not stop everything, just the parts that genuinely needed to wait.
The broader principle is that dependencies are least damaging when both sides have agreed on what a status update looks like and when it happens. A vague commitment to deliver by a certain date is much harder to manage than an agreement that includes a midpoint check and a clear escalation path if things start slipping.

This is something that we try to time as best as possible during the planning stages. We aim to time out the various tasks that have to be done and then coordinate those so that there is as little frozen time as possible for any of our teams. But, of course sometimes things don't go exactly to plan. One thing that we do try to deal with that is stay in good communication with one another. That way, if one team is a little behind, the other teams they are working with know about that and can adjust their own tasks accordingly for better efficiency.

When teams perceive dependencies as active contracts instead of passive queues, they interrupt project momentum. The key to being able to avoid the waiting game is establishing Dependency Service Level Agreements (DSLAs) upfront for any integrated workstreams that I have delivered for my clients by providing complex ERP and enterprise systems. The DSLAs serve as formal written agreements between team leads that clarify the "what" and "when" to the level of detail necessary to describe the specific data schemas, response times, and fallback procedures if the date that the data arrives slips.

I can think of one instance where I had responsibility for leading the ERP migration for a multi-phase project and was blocked at our procurement module due to delays from a third-party legacy system that was to be integrated. Instead of waiting for the third-party team to catch up, we built a fake interface that was based on the DSLAs we established. We were able then to continue with configuration of the downstream warehouse management and financial modules using the fake data until the production system was available to us. At that time, we simply replaced the fake with the actual data feed. As we did not wait for the third-party team, our ability to carry out our work was not impacted as a result of the delay due to the DSLAs.

The critical aspect of the DSLAs was defining "ready" the first time with respect to the incoming data request. If the two teams establish the exact structure, format, and frequency of the handoff before the first line of code is written, this eliminates the friction caused by having to redo work that is caused by the dependency surprise of trying to integrate the two teams' systems/modules. A dependency will only be a roadblock if you allow it to be; if you treat it as you would an interface with clear specifications and contingencies, the dependency will simply be one more task on your critical path to completing the project.

The agreement that saved us is what I call "show me the half-done thing." When my timeline depends on another team or vendor, we agree up front on a midpoint date where they show the actual deliverable in whatever rough state it's in. Not a status update. Not a percentage. The thing itself, on a screen.
I learned this running a healthcare company's migration to a new records platform while depending on data exports from the old vendor. Status reports said green for weeks. The half-done viewing told a different story in about four minutes, and because we caught it at the midpoint instead of the deadline, I still had room to re-sequence.
That's the other half of the practice: I plan my own schedule in two stacks. Stack one needs their delivery. Stack two doesn't, and it's real work, not busywork, things like building templates against sample data so the day their piece lands, ours snaps onto it. The wait stops being dead time.
Percent-complete is a feeling. A half-done thing is a fact. Every dependency that has derailed me happened because I accepted the feeling, and every one that didn't is because I insisted on the fact.

We use an approach we call escalation without emotion. When a dependency moves past its buffer, it triggers a decision meeting with the owner. The goal is to choose to reduce scope, change sequence, or add support. This keeps the schedule tied to clear decisions and not to hope.

We see drift when teams try to be helpful for too long and extend courtesy. We prefer agreements that force early clarity and turn delays into a new plan. Most delays do not fail a project by themselves, but the lack of a new plan does. With a steady decision rhythm, progress continues even when the original sequence changes.

When progress depends on another team, we start by finding decisions that create stability for the work that follows. We handle them first, even if the other team has not finished. We plan around clear readiness points: what must be true to begin, what can move with assumptions, and what should wait to avoid rework. This keeps momentum and reduces waste.

One agreement that keeps timelines on track is a no silent slippage rule. If a date is at risk, we share it early so we can adjust the plan. We switch to an alternate sequence instead of discovering delays after they spread through the schedule. This habit keeps ownership clear and helps us protect delivery without last minute stress.

For critical projects with external dependencies, I use a hybrid delivery model: a Waterfall/CPM schedule for milestones and critical path tracking, executed through Agile sprints and Kanban boards.

1. An example: developing a timesheet and workforce planning application. Core functionality (security, database, standard layouts) could be built independently, but specific fields and approval workflows depended on the client's HR requirements, still being finalized internally.

My schedule calculated Early/Late Start and Finish dates, establishing Total Float for every activity as a defensible baseline.

When the HR input was delayed, I re-forecast the milestone, generating new Early Start/Finish dates downstream and recalculating Total Float.

To translate this into Agile delivery:
I embedded the recalculated Late Start, Late Finish, and remaining Total Float onto each Kanban card.

In Sprint Planning, I sequenced the backlog by float and late finish, pulling forward those with the earliest date and lowest float that weren't dependent on the delayed input.

Where required, partially dependent tasks were decomposed (e.g., splitting Development from Testing), so the independent portion moved into the sprint while only the gated sub-task remained delayed.

Stand-ups referenced the Kanban board with float visible, so the team naturally gravitated toward the resequenced priorities.

2. Left unresolved, the HR requirements gap represented a 6 to 8 week delay, since it affected what fields and work flows users needed beyond basic project code and hours.

Twice monthly check-ins, aligned with our sprint cadence, were built into the original project agreement. This gave us early visibility once the client's internal sign-off began slipping. Rather than wait for the final signed document, the client agreed to share a draft of their procedure. It wasn't yet approved internally, but gave the team enough structure to design around. We agreed to a two week delay, formally approved through change management on both sides, with the option to revisit if the final document differed substantially from the draft.

The result: a potential 6 to 8 week delay was contained to four days. Early visibility through regular check-ins, combined with accepting partial, unsigned information once a slip was confirmed, let us reforecast proactively and keep the team productive while we waited.