Project dependencies: the dates your client owes you.
Most dependency lists are notes an agency keeps for itself, which is how a client input that lands two weeks late quietly turns into two weeks of your margin rather than two weeks of their schedule.
Every project has a few things somebody else has to do before your part can move, and on client work most of them belong to the client. The login for their order system, the product data, the answer from their one approver and the vendor they hired before they hired you are all things you'll end up waiting on. Agencies usually record those as reminders in a project plan, which is where they stop being worth anything, because a reminder to yourself doesn't move a delivery date and doesn't bill for a week nobody could work.
What are project dependencies?
A dependency is anything that has to happen before a piece of your work can start or finish, and the ones worth putting in a scope are the ones you can't do yourself. The standard teaching treats this as a relationship between two tasks on a schedule, which is accurate and stops one step short of useful on paid work. The relationship that costs money runs between your delivery date and something a person outside your team owes you, and that's a different animal from two of your own tasks sitting in sequence.
So the same word quietly does two jobs. Inside your own plan a dependency is sequencing, you own it, and nobody needs to sign anything for it to work. Pointed outward at the client or at one of their vendors, the same dependency is an obligation with a date attached, and whether that date exists in writing decides who carries the cost when it's missed.
What are the four types of dependencies in project management?
The four types named in every project management course are finish to start, start to start, finish to finish and start to finish, and all four describe how two pieces of work are tied together rather than who owes what. Finish to start is the common one, where the first thing has to be done before the second can begin. Start to start means the second can't open until the first has, and finish to finish means the two have to land together, which is what happens when content entry has to complete at the same moment as the page it sits on. Start to finish turns up so rarely that most projects never meet one.
A second grouping sits alongside those and is the more useful of the two on client work: logical dependencies, where the order is a fact about the work itself; resource dependencies, where two things need the same person; preferential dependencies, where you'd simply rather do it in that order; and external dependencies, where the thing you're waiting on sits outside the project entirely.
External is where nearly all of an agency's money sits, and it's the group that tends to get the least written about it, because the usual answer is contingency and contingency is a buffer you pay for yourself. On a fixed fee, padding the schedule to absorb somebody else's lateness is a discount you gave before anybody asked for one.
A dependency you can only chase by email is one you agreed to carry for free.
What does a project dependency look like on a client project?
It looks like a short numbered section with dates in it, a name beside each date, and one clause underneath saying what happens when a date is missed. Wexford Door Works builds windows and doors and sells them through 34 independent dealers, and the eight-week job below replaces the order form those dealers currently fax with a portal that prices an order against Wexford's own system.
6. DEPENDENCIES
6.1 Wexford supplies test credentials for its order system, plus one test dealer account, by October 12, 2026. We can't issue these ourselves.
6.2 Wexford supplies product data for 640 items as a spreadsheet in the format shown in appendix A, by October 19, 2026.
6.3 Wexford names one approver for the page templates in section 3, who replies within three business days of each delivery. A template with no reply after three business days is treated as approved.
6.4 Wexford's payment processor completes dealer merchant onboarding by November 2, 2026. Wexford carries this date, because the processor is Wexford's supplier and not ours.
6.5 If a date in 6.1 to 6.4 is missed, the delivery dates in section 5 move by the same number of working days. The first five working days of cumulative delay are absorbed at no charge. Held time beyond that is billed at $1,250 per week, pro-rated at $250 per working day. A hold running longer than ten working days is also billed one fee of $1,600 to return the team to the project. Anything not named in section 3 or section 6 is quoted before it starts, or billed at $135 per hour where Wexford prefers.
Clause 6.3 is the one agencies leave out most often, and it's the cheapest of the four to write. An approver who takes eleven days to look at a template isn't refusing anything, and the eleven days come out of your build whether or not anybody names them.
How do you find a project's dependencies before you sign?
Walk the schedule backwards from the delivery date and stop at every point where your team would be sitting still, then ask who they'd be sitting still for. Three questions cover almost all of it, and they're who has to give us something, who has to say yes, and whose supplier are we waiting on. Anything that answers one of those three belongs in the scope with a date beside it.
The one people miss is the second question, because approval doesn't feel like an input. It arrives as an opinion rather than a file, so nobody thinks to put a date on it, and then a template sits in an inbox for two weeks while the person who owns it is traveling. Naming a single approver and a reply window fixes that, and the sentence treating silence as approval after three business days is what makes the window real. An approval that holds up later is one that had a deadline attached to it from the start.
The third question is the one that needs a different kind of wording. You can ask a client to hand you a file by a Monday, and you can't ask their payment processor to hurry, so a dependency on somebody else's supplier gets a window rather than a promise, and the clause says who carries it. Writing a scope of work that stays honest about that is easier than explaining in week six why a date you never controlled was still your problem.
What does a dependency clause say, word for word?
It names the thing, the person who owes it, the date it's owed by, and what moves when it doesn't arrive, and that last part is what most versions leave off. A dependency list without a consequence is a list of things to chase, and chasing is unpaid work that also fails to protect the deadline you're chasing for.
The wording that does the work in clause 6.5 is the automatic movement. The delivery dates move by the same number of working days the input was late, day for day, without anybody having to request it or approve it. That's deliberately different from asking for an extension, because an extension is a favor the client can decline and a day-for-day shift is arithmetic both sides agreed to in week one. The five absorbed days matter as much, since they keep the clause from firing over an afternoon and make it obvious that the rest of it is about real holds rather than pedantry.
Money comes second, and on purpose. A held week costs an agency real capacity, because the people booked on Wexford can't be handed to another client for four days and handed back, so $1,250 a week is closer to a description of the loss than a penalty. The $1,600 for a hold past ten working days covers the genuine cost of putting a paused project back together, which is the part clients least expect and most readily accept once it's written down.
Who pays when a client misses a dependency?
Whoever the document says pays, and at Wexford that turned out to be the client, in week five, for $6,280. The order system credentials in clause 6.1 arrived 14 working days after the date in the scope, because the request sat with an internal systems team nobody had told about the project. The product data in 6.2 arrived on time and arrived as a PDF price list rather than the spreadsheet format in appendix A.
Every part of that was arithmetic the scope had already set out. The hold ran 14 working days, the first five were absorbed under 6.5, and the remaining nine came to $2,250 at the $250 per working day the same clause sets out. The hold also passed ten working days, which added the single $1,600 return fee. Re-keying 640 items out of a PDF into the appendix A format was work named nowhere in section 3 or section 6, so it went through at the $135 hourly rate in 6.5 and came to $2,430 across 18 hours. The change went back at $6,280, approved in writing before any of the re-keying started, taking the engagement to $28,360 and moving launch 14 working days.
Run the same five weeks with dependencies living in a project plan instead. The credentials are still late by the same fortnight, the data still arrives in the wrong shape, and the agency still does the re-keying, except now the launch date hasn't moved, nobody owes anybody $6,280, and the team works two weekends to protect a deadline that was never theirs to miss. A good share of what scope creep costs an agency over a year is made of weeks like that, where nothing was added to the scope and the fee quietly bought more of your time than it was meant to.
How are dependencies different from assumptions, constraints and exclusions?
All four are conditions on the same fee, and they fail in four different directions, which is why filing them under one heading costs money. A project assumption is a belief about the work that keeps it the size you priced, and it's tested when something arrives in a different shape than the one you costed. A project constraint is a limit that was already true when you quoted, usually a date, and it's tested when the client moves a limit they set themselves.
A project exclusion names work the fee doesn't buy, and it's tested in the most ordinary way there is, when somebody asks for the excluded thing and you hand them a rate. A dependency is the only one of the four that creates an obligation running the other way, from the client to you, on a date. The other three describe what you will and won't do for the money, while a dependency describes what has to reach you before you can do any of it.
That difference decides where each one goes. An exclusion belongs beside the line it narrows, an assumption belongs in the paragraph whose price it protects, and dependencies work better gathered into one numbered section, because the client needs to read their own homework in one place rather than hunting for it across nine pages. A project scope template with that section already in it saves the twenty minutes you'd otherwise spend rebuilding it per project.
The dependency that moves the schedule by itself is the one that holds
One sentence did most of the work at Wexford, and it's the one in clause 6.5 saying the delivery dates move by the same number of working days the input was late. Nobody had to request that, grant it, or feel awkward about it, and by the time the credentials showed up 14 working days behind, the new launch date had already been true for two weeks. The $2,250 and the $1,600 were the smaller half of what that sentence protected.
The rest is keeping the record of it. Docket puts the request, the days, the $6,280 and the written approval on one entry against the project, so the dependency that slipped and the change it produced stay attached to each other instead of scattering across a month of email. A change request form is where that starts, and a dated dependency section is what gives it something to point at.
Frequently asked questions
What are project dependencies?
Project dependencies are the things that have to happen before a piece of the work can start or finish, and the ones worth writing into a scope are the ones you do not control. Inside your own plan a dependency is just sequencing, and you own the consequence of getting it wrong. Pointed at the client or at one of their vendors, the same dependency is an obligation with a date attached, and whether that date is written down decides who absorbs the delay when it is missed.
What are the four types of dependencies in project management?
Finish to start, where the first thing has to finish before the second can begin. Start to start, where the second thing cannot begin until the first has begun. Finish to finish, where the two have to land together. And start to finish, which is rare enough that most projects never meet one. All four describe how two pieces of work are tied together in a schedule, and none of them says who owes what to whom, which is the part a client signs against.
Can you give an example of a project dependency?
A dealer ordering portal cannot be connected to an existing order system the client controls until the client supplies a test login for it, so the connection work depends on a login the agency cannot issue itself. That is the shape most agency dependencies take: the client, or a vendor the client hired, owes you an input, an access credential or a decision, and your own schedule cannot move until it arrives. The useful version of that example names the date it is owed and what happens to the delivery date if it is late.
What is an external dependency in project management?
An external dependency is one where the thing you are waiting on sits outside the project team altogether, such as a payment processor approving a merchant account, a platform review, or a vendor the client contracted before you arrived. The usual advice is to plan contingency around it, which on a fixed fee means you are buying the buffer yourself. The alternative is to write the date into the scope, name who carries it, and say what moves if it slips.
Who is responsible when a project dependency is late?
Whoever the signed document says is responsible, which is why the consequence matters more than the list. A scope that names the input, the owner and the date, and then states that the delivery dates move by the same number of working days the input was late, hands the cost of the delay to the party who caused it without anybody having to argue. A scope that lists the same dependencies with no consequence attached leaves the agency holding both the idle week and the original deadline.
Do project dependencies belong in the scope of work?
The ones you are waiting on somebody else for belong in it, in a numbered section of their own with dates and a named owner. Your internal sequencing does not, because it is your plan rather than an obligation the client took on, and putting it in front of a client invites a conversation about how you work instead of about what they owe. The test is simple: if you would send an email chasing it, it belongs in the scope.