Dependencies Log: Fields, Example and Review Rhythm

A dependencies log is a single list of everything your project needs from someone or something else: an input, a decision, an approval, a delivery. Each entry names who owes it, when it is due, and what breaks if it arrives late. It works when every line has a named owner and a review date. It fails when it becomes a spreadsheet someone filled in once during kickoff.

This guide covers the fields worth keeping, a worked example from an architecture project, the four dependency types, how a submittal register relates to all this, and a review rhythm that keeps the log honest.

TL;DR

• A dependencies log records inputs your project needs from others: one entry per dependency, each with an owner, a due date and a stated consequence.
• The fields that matter most are a unique ID, a cause-and-effect description, a named owner, a due date, and the impact if it is not delivered.
• A submittal register is a specialized dependency log for shop drawings, product data and samples. Its most useful column is “ball in court.”
• An entry with no owner is an open defect. Review high-stakes entries often and low-risk ones less often.
• Record where each dependency came from, so anyone can trace it back to the conversation that created it.

Table of Contents

• What a dependencies log is, and what it is not
• The fields to include
• A worked example from a design project
• The four dependency types, in plain terms
• Where a submittal register fits
• Keep it alive: ownership and review cadence
• Common mistakes
• Our perspective: dependencies begin as sentences
• Turning conversations into log entries
• If you want the log built from your meetings
• FAQ
• Sources

What a dependencies log is, and what it is not

A task list says what you will do. A dependencies log says what you are waiting on. The distinction matters because waiting is where schedules die: nobody is working on the item, so nobody notices it is stuck.

The log is often one tab of a larger RAID log (risks, assumptions, issues, dependencies). A dependency log records the source, deliverables and timeline of each dependency, and projects may have both internal dependencies (another team in your own firm) and external ones (a client, a consultant, a city agency).

It is also different from a schedule diagram. Visual dependency graphs are useful for sequencing, but a dependency registry is better understood as a searchable system of record that holds accountability through named ownership and scheduled reviews. A diagram shows shape. A log shows who has to do what by when.

The fields to include

Start small. Every extra column is a column someone has to maintain. These are the fields that earn their place.

The commonly cited attributes include a unique reference, a clear description, an accountable owner, delivery dates, the probability of delay, and the projected impact if the dependency is not met, as summarized by Brightwork. Add a probability or confidence column if your team likes to rank by risk. Skip it if nobody will fill it in honestly.

The field people skip: impact if not delivered

Experienced project managers treat dependencies as a form of hidden project risk. The point of writing down the impact is practical: if you cannot state the negative consequence of a late input, you will struggle to get anyone to prioritize it when schedules slip.

“Waiting on client to confirm finishes” is a note. “Millwork shop drawings cannot start until finishes are confirmed; 8-week lead time pushes install past the tenant move-in date” is a dependency with a consequence. The second one gets answered.

The other skipped field: owner

A dependency with no owner is not a loose end. Treat it as an open defect: if nobody is explicitly responsible for delivering an input, it is operationally invisible, however well it is documented. Make a blank owner cell a red flag that must be cleared at the next meeting.

A worked example from a design project

Imagine a small studio designing a 4,000 square foot dental clinic fit-out. Here is what a trimmed log might look like after the second client meeting.

Notice three things. Each title follows a cause-and-effect pattern. Each has one owner, not a team. And each points to the conversation it came from, which is the part most logs lose.

That last field is what separates a log people trust from one they ignore. Three months later, when the client says they never agreed to the chair vendor deadline, the source column tells you where to look.

The four dependency types, in plain terms

If you schedule in software, you will meet the four logical relationships. They describe how a successor activity relates to its predecessor, and the PMI’s Guide to the Project Management Body of Knowledge errata lists them as follows:

• Finish-to-Start (FS): the successor cannot start until the predecessor finishes. This is the most common. Example: construction documents cannot be issued until the client signs off on design development.
• Finish-to-Finish (FF): the successor cannot finish until the predecessor finishes. Example: the specification cannot be completed until the drawing set is completed.
• Start-to-Start (SS): the successor cannot start until the predecessor starts. Example: finish selections can begin once the lighting design begins.
• Start-to-Finish (SF): the successor cannot finish until the predecessor starts. This one is rare. Most teams never need it in a log.

For a log, you rarely need to label every entry with FS or SS. A note in the description, such as “must be done before”, is enough. Use the codes when you are feeding a scheduling tool and need the links to be exact.

Where a submittal register fits

If you work in architecture or construction, you have probably seen a submittal log or register. It is a dependencies log with a narrow job: tracking shop drawings, product data and material samples through review before fabrication or installation.

A good register links every submittal to a contract specification section, keeps a status showing who holds the action, and records submission and return dates, according to Mastt’s submittal register guidance. The typical columns look like this:

Ball in court

This is the column worth copying into every other log you keep. It names the party currently holding the action, whether subcontractor, consultant or client. Mastt describes it as one of the most overlooked fields, and it removes the “whose desk is it on?” argument that stalls coordination meetings.

On naming discipline, one construction document platform’s guidance recommends numbering and naming all submittals consistently so subcontractors and contractors do not each invent their own system, and using the log to export lists of incomplete and complete submittals.

If you are choosing between one combined log and two separate ones, a practical rule: keep the submittal register separate when your project is large enough that submittals number in the dozens, and add a single line in the dependencies log for each critical-path submittal. That way the main log stays readable.

Keep it alive: ownership and review cadence

Most dependencies logs do not fail at creation. They fail at month two.

The common failure is treating dependencies as set-and-forget. A better model is stewardship. The Encyclopedia of Abstractions argues for a governance model with review cadences, where high-stakes items are re-validated often and lower-risk items less often. Here is a simple way to apply that to a small team.

1. Rate each entry high, medium or low by the cost of delay.
2. Set the review rhythm: high weekly, medium every two weeks, low monthly.
3. Write the next review date in the entry itself, so the log tells you what to look at.
4. Clear blank owners first at every review.
5. Close entries with a note, not a deletion: who delivered, on what date, in what form.
6. Archive, never erase. The closed entries are your record of how the project moved.

Ten minutes at the start of the weekly team meeting is usually enough for a small studio. If the review takes longer, the log has too many low-value entries.

Common mistakes

• Logging tasks instead of dependencies. If it is something your own team does, it belongs on the task list.
• Group owners. “Design team” is not an owner.
• Vague due dates. “ASAP” and “soon” cannot be reviewed.
• No consequence. Without an impact, the entry has no priority.
• No source. When a client disputes a commitment, you want the conversation, not your recollection.
• Mismatch between the plan and the facts. Research on tracking software dependencies found that the core difficulty is often a gap between a high-level managerial model and the fine-grained actual state of dependencies. The lesson carries over to design: if your log is more abstract than what is actually happening on the drawings, people stop using it.

Our perspective: dependencies begin as sentences

We build project memory software for design teams, and what we see is that almost every dependency starts life as a casual sentence in a meeting. “We’ll need the engineer’s input before we lock that.” “Can you send the landlord’s criteria by next week?” Nobody writes a log entry in the moment. The sentence goes into someone’s notes, or nowhere.

By the time the delay shows up, the team has the log entry but not the reason. They remember that something was needed, not why it mattered or who agreed to provide it. That is the gap we care about: the why behind the work.

So our view is that a dependencies log should be tied to its origin. Every entry should point to the conversation, comment or critique where it was created. That is the idea behind The Intent Ledger: we turn conversations, notes and transcripts into structured, source-backed records of decisions, risks, actions, commitments and unresolved questions. A dependency often sits across several of these, a commitment from one person that a decision hangs on. Seeing them side by side with their sources makes the log far harder to dismiss.

If you are building the habit by hand first, that is a good way to start. Our guides on a decision log template, commitment tracking, and a constraints log with owners and weekly review cover neighboring records that feed your dependencies.

, Rajas

Turning conversations into log entries

The laborious part of a dependencies log is not the table. It is catching dependencies as they are spoken. A few habits help whether you use software or a spreadsheet.

• Listen for conditional phrases: “once we have,” “as long as,” “pending,” “we’re waiting on.” Each usually hides a dependency.
• Capture them within a day. Memory of who said what fades fast.
• Read the entry back at the end of the meeting: owner, date, consequence. Fix it while everyone is present.
• Separate client comments from team asks. Client feedback often creates dependencies that nobody labels as such; our guide to client comment tracking shows one way to structure it.
• Link to the action. Each dependency usually spawns an action item; see action items tracking for a working system.

If you want the log built from your meetings

If you would rather not transcribe by hand, The Intent Ledger creates ILM Records from meeting notes, transcripts, audio and client comments, with each record traceable to the conversation it came from. Pricing is published: one-off packs run from $12 for Working Set to $119 for Studio Ledger, and monthly plans from $29 per month for Working Memory to $149 per month for Shared Ledger. See the pricing page to compare, or start at theintentledger.com.

FAQ

What is the difference between a dependencies log and a dependency register?

In practice, they are the same thing: a structured list of dependencies with owners, dates and impacts. “Register” tends to suggest a more formal, governed record, while “log” is the everyday term. Pick one name and use it consistently across the team.

How do you track dependencies on a small project?

Use a spreadsheet with the fields in the table above, and review it weekly. Give every entry one owner, a needed-by date and a written consequence. Record the meeting or message where it arose so you can check the details later.

What are examples of dependencies in design work?

A client choosing finishes before millwork drawings begin, a structural engineer confirming openings before a room layout is locked, a landlord approving equipment locations before mechanical design is final, and a supplier returning a sample before a specification is issued. All are inputs that someone else controls.

Is a submittal log the same as a dependencies log?

Not quite. A submittal log is a specialized dependency record for shop drawings, product data and samples, with columns such as spec section and review status. A dependencies log is broader and covers any input your project needs. Many teams keep both and cross-reference the critical submittals.

Sources

• How To Handle Dependencies In Your Projects, Brightwork
• Dependency Registry, The Encyclopedia of Abstractions
• Dependences Log, RAIDLog.com
• PMBOK Guide Eighth Edition errata, PMI
• Submittal Register Template, Mastt
• Create and Import a Submittal Register, Newforma ConstructEx Help
• Challenges of Tracking and Documenting Open Source Dependencies in Products, PMC

Recommended

• Constraints Log for Small Studios: Assign Owners, Review Weekly
• Record of Decision: 8 Fields Design Teams Must Capture
• Link Drawings to Decisions With 10 Fields Mapped to ISO 19650
• Commitment Tracking: 7 Fields That Let Design Teams Verify Promises