Earlier in this book I discussed why I prefer to use Actions and Decisions over Assumptions and Dependencies as the “A” and “D” in my RAID log. But as I will share in a case study at the end of this book, tracking dependencies in a RAID log can be one of the best ways to turn a troubled project around. And as mentioned earlier, tracking inter-workstream dependencies is a critical part of program management.
Dependency tracking can also be useful when managing a difficult customer or partner organization. For example, if you are delivering for a customer that seems to have a hard time meeting their obligations, it can be very useful to have a Dependency log to track those obligations and hold the customer accountable. This is particularly powerful if those dependencies are contracted obligations on the part of the customer or partner.
If you are tracking dependencies, they should always be deliverable focused. This means that these are possibly (maybe even likely) redundant to your project plan. But it is sometimes worth it to be able to quickly pull up all the dependencies for an organization and hold them accountable.
