Manage External Dependencies or face the Risk of a "dropped baton" in the relay race

External Dependencies need to be carefully managed to ensure they don't trip up your Project and cause you to cross the finish line late. In this post I suggest how to manage with tips and templates.

Definition

First a definition! What I don't mean is task dependencies (i.e. you can't complete task a until task b is complete). What I do mean is things you need to deliver your project which aren't part of your project scope and need to be provided by others, often a different project. This is very common in Programmes but can be seen in other scenarios.

Identifying External Dependencies

When you are working through your Project Planning you should identify anything which you need to deliver your scope which isn't part of your scope, who you believe is providing these items and when you need them. You have now found your External Dependencies which should be clearly marked within your schedule (typically I have these as clearly marked milestones "EXT DEP:<description>").

The first thing to note is that just because you would like an external dependency to be satisfied by date "x" doesn't mean that the provider can or will be able to achieve this.

Managing External Dependencies

The process I adopt for External Dependencies (especially within a Programme setting) is as follows:

1. Establish a common Dependency Log / Register and every Project Manager should log Dependencies as soon as possible, then firm up on details and dates
2. Until the "dependency provider" actually agrees to your dependency request, you have a big risk that it won't be provided when you need it. So this is stage 2, get agreements that these dependencies have been built into plans from the providing project (or BAU activity)
3. Then you move into "Monitoring Stage". Within a Programme I like to have a regular (weekly) RAIDs review meeting. At this I will review the Dependencies for whether we have "non agreed" dependencies and for the agreed dependencies, how does the supplying Project Manager rate being on track to provide each one at the agreed date with some form of RAG status 
4. When the dependency has been met, mark the dependency appropriately in the log. Eventually, every one in the Log should be either cancelled or marked as "Met"

Dependency Log

A good Dependency Log / Register is important in the management processes described above. Below is my standard dependency log held in Excel.

The fields are:

• Raid Nr - Unique ID
• Description - As specific as you can make it. It is OK to start vague but you need to firm up before it is marked as "Agreed"
• Date Raised
• Date Dependency (as per description) is to be met
• Who requested (project and contact)
• Who is satisfying dependency (project and contact)
• Dependency status - Request / Agreed / Met / Cancel
• RAGB status where Red = not on track to meet the agreed date, Amber = at some risk of meeting the agreed date but still expect to achieve, Green = on track, Blue = have met the dependency request
• Position - allows for comment updates preceded by date stamp

Conclusion

External Dependency management is really important within a Programme of Projects but often in other scenarios too. A 4 step management process is suggested built upon a good Dependency Log but of course, it all relies on good planning first.

If you don't plan, agree and manage external dependencies, the baton may be dropped in your Project race resulting in a delay as your external contacts quote you the old saying "Your inability to plan does not become my emergency"!!