Project Dependencies Examples: 25 Real Ones by Type

A project dependency is any relationship where one piece of work cannot start or finish until something else does. The four standard types are mandatory (physics or law requires the order), discretionary (the team chose the order), internal (both sides sit inside the project), and external (one side does not). Most real dependencies carry two labels at once, because the internal and external axis is independent of the mandatory and discretionary one.

Definitions get you nowhere on their own. The reason dependencies are missed is that people do not recognize one when it is sitting in front of them, phrased as "we are just waiting on legal" or "the platform team said March." Below are 25 examples, grouped by type, each with the shape it takes in a real plan and the action it deserves. If you want the framework behind them, read project dependency management first. If you want to go find yours, dependency mapping is the process.

The four types of dependencies, in one table

Mandatory and discretionary describe whether the order is negotiable. Internal and external describe who controls it. Every dependency has one label from each pair, which is why "mandatory external" (a permit you must have and cannot hurry) is the category that quietly wrecks schedules, and "discretionary internal" is where all your recovery options live.

What is an example of a mandatory dependency?

A mandatory dependency is one where the sequence is forced by the nature of the work or by a rule you cannot waive. Pouring a building foundation must finish before framing starts. You cannot compress it, overlap it, or negotiate it. Mandatory dependencies define the true floor of your schedule, so they are the first thing to identify when a sponsor asks whether the date can move.

Five mandatory examples:

• Foundation cured before framing begins. Physics. No amount of sponsor pressure changes concrete.
• Requirements signed off before the fixed-price statement of work is agreed. Commercially mandatory. Sign a fixed price against unstable requirements and you have bought a change order pipeline.
• Security review passed before production deployment. Policy makes this mandatory. It is also the one most often treated as discretionary right up until it stops a release.
• Environmental permit issued before ground is broken. Legally mandatory and externally controlled, the worst combination, which is why permits belong on the critical path from day one.
• Data migration completed before user acceptance testing. You cannot test business processes against an empty database, though teams try, and the resulting UAT sign off is worthless.

What is an example of a discretionary dependency?

A discretionary dependency is a sequence the team chose because it is safer, cheaper, or conventional, not because it is required. Finishing design before starting construction is the classic case: you can overlap them, and fast-tracking is exactly that decision. Discretionary dependencies are your compression levers, and the only reason to label them is so you know which ones you are allowed to pull when the date is at risk.

Four discretionary examples:

• Complete the full design before starting build. Overlapping the two is called fast-tracking. It works, it costs rework, and it should be a decision rather than an accident.
• Finish the script before casting the actors. Standard practice in film, routinely broken when a star becomes available.
• Train all users before go live rather than in waves after it. A preference. Wave training trades support cost for schedule.
• Migrate the pilot region before the remaining regions. Risk reduction, not a requirement. Parallel migration is faster and less forgiving.

What is an example of an internal dependency?

An internal dependency links two pieces of work that both sit inside the project team, under one project manager's authority. Writing test cases before executing them is internal. So is having the architect approve a design before developers build against it. Internal dependencies are the easiest to fix because a single person can arbitrate, and the easiest to ignore for the same reason.

Five internal examples:

• Test cases written before test execution begins. Skipping the link produces testing that finds no defects, which is not the same as software with no defects.
• Architecture decision record approved before the build sprint starts. Otherwise two developers make the decision twice, differently.
• Chart of accounts confirmed before the finance system is configured. Configuring against a draft is the single most common source of rework in a finance implementation.
• Training materials finished before the trainer runs a dry run. Discretionary in theory, mandatory the moment you have booked the room.
• Cutover runbook complete before the go live rehearsal. Rehearsing without a runbook rehearses improvisation.

What are examples of external dependencies in project management?

An external dependency is one where the work you are waiting on sits outside the project team's control: a vendor, a regulator, a customer, or another department. Waiting on a supplier to deliver hardware is the standard example. External dependencies need an earlier warning threshold, a named human contact on the other side, and a documented fallback, because escalation through your own management chain has no authority over the person who is late.

Six external examples:

• A vendor delivers the servers before the environment can be built. Track the purchase order date, not the promise date. Committed spend and delivery dates usually live in the PO system rather than the plan.
• Legal countersigns the statement of work before the integration build starts. Nearly always underestimated. A document in a review queue has no owner unless you give it one.
• A regulator issues a license before the product can launch. Mandatory and external. There is no fallback, only earlier submission.
• The client provides sample data before the migration scripts can be tested. The client is external even when they are paying you, and especially then.
• The vendor's insurance certificate clears before they are allowed on site. A compliance gate that stops work at the gate. Expired certificates of insurance block more site starts than weather does.
• A partner bank completes its own upgrade before your integration can be certified. Their roadmap, your critical path, and no leverage whatsoever.

What are examples of cross-project dependencies?

A cross-project dependency exists when one project's output or resource is required by another project in the same portfolio. Quality assurance can only test the device once engineering has finished it. Cross-project dependencies are the most damaging class in a portfolio, because neither project manager has authority over the other and both plans assume the link will hold.

Five cross-project examples:

• The CRM project cannot integrate until the identity platform project ships single sign on. Two roadmaps, one assumption, and usually two different target dates.
• Four projects each assume the same database administrator is available in March. This is a capacity dependency, not a deliverable one, and it belongs in capacity planning.
• The warehouse automation project needs the network upgrade project to finish the site first. Sequenced by geography, owned by nobody in common below the sponsor.
• Two projects both need the same two-week change freeze window at year end. A calendar collision, discoverable months in advance and typically found three weeks out.
• A benefits case depends on a second project delivering the reporting layer. The first project can be fully delivered and still realize nothing. See benefits realization management.

Dependency examples by logical relationship

The four types answer who and whether. The four logical relationships answer what "late" means. They matter because a start-to-start dependency that slips by a week and a finish-to-start dependency that slips by a week do very different things to a plan.

Finish to start covers the overwhelming majority of real dependencies. Start to finish is rare enough that if you think you have found one, check whether you have actually described a finish to start relationship backwards. The honest use for SF is handover and cutover: the legacy service keeps running until the replacement is live.

What to do with each example once you find it

Finding a dependency is not managing it. Every one of the 25 above becomes actionable through the same four moves, in order.

• Name both sides. A provider and a consumer, both people, not teams. Teams do not reply to emails.
• Agree a date out loud. Not a date the consumer wrote down. A date the provider said, in a meeting, with the consumer present.
• Write the impact sentence. "If this is late by two weeks, go live moves to April and we miss the quarter." Sponsors act on sentences like that and ignore red status colors.
• Decide the fallback now. Especially for the external ones. The time to decide what you do if the permit is late is before you know that it is.

Then put the whole set somewhere it will be looked at. A dependency matrix works when the count passes about forty and you need to see clusters and loops. A simple log works below that. Either way it needs a standing slot in the portfolio review, showing only what is breached or at risk, because a dependency register nobody reads is an audit trail for a failure rather than a tool to prevent one.

Frequently asked questions

What is an example of a dependency in project management?

The simplest example: user acceptance testing cannot begin until data migration is complete. One task must finish before another can start, so the second is dependent on the first. That is a mandatory internal finish-to-start dependency. Every dependency, however complex, reduces to that same shape: something must happen before something else can.

What is the difference between an internal and an external dependency?

An internal dependency links work that sits inside the project team, so the project manager can arbitrate and resequence it. An external dependency involves a party outside that authority: a vendor, a regulator, a client, or another department. The practical difference is leverage. You manage internal dependencies by deciding, and external ones by agreeing early, warning sooner, and holding a fallback.

Is a resource a dependency?

Yes, and it is the type most often missed. When four projects assume the same specialist is free in March, the dependency is on capacity rather than on any deliverable. Resource dependencies do not appear in task-linked schedules, which is why portfolios discover them through capacity planning rather than through the plan.

What is a dependency versus a risk versus an assumption?

A dependency is a known relationship with a named owner on each side. An assumption is a dependency you have not confirmed, which is why unvalidated assumptions turn into dependencies the moment somebody checks. A risk is what a dependency becomes when the date is in doubt. The register moves items in one direction: assumption, dependency, risk, issue.

How many dependencies should a project have?

There is no correct number, but the distribution tells you something. If a project of any size has logged fewer than about ten, it has not mapped, it has guessed. If almost none are external, the map stops at the team boundary and the real risk is outside it. Count the cross-boundary links, not the total.