We’ve used a Functional Dependency Map for quite some while now to track risks and dependencies across our roadmap.
Once every 4 weeks we get the full project management team together for an hour to run through the dependencies with a view to checking two main things: firstly, is the supporting project still on track to deliver in time for the dependent project; secondly, is the supporting project still delivering the right scope for the dependent project.
It’s generally a useful session but is particularly valued by the higher level project managers. What they say they really appreciate is that all the dependencies across the roadmap are set out on a single page. I’d guess that there is some external interest in this area as well since the top 6 search terms for the blog are all along the lines of “project dependency mapping”.
This is just a note that we’re currently reviewing our functional dependency map to see if it can be improved in two areas.
Explicitness: While our current approach identifies that there is a dependency, it doesn’t explicitly state the nature of that dependency. As a result we sometimes waste time in the session redefining what the dependency is before reviewing it. Apart from the inefficiency, this also suggests that the dependency is not being actively managed outside of the review sessions. We clearly need to improve this.
Parallel as well as sequential: Our current approach supports sequential dependencies. In other words, project A must deliver this capability increment before project B can extend it. However, sometimes there is more of a parallel “dependency”  where two projects are incrementing a capability at the same time. An example would be where two projects need services that retrieve similar data. These two projects should be talking to each other to ensure that the service design is well scoped and efficient. Our current meta-model doesn’t have the semantic elements to support this concept of parallel dependency.
We’re therefore reviewing the model and it’s underlying meta-model to see if we can improve in these areas. We’re also taking the opportunity to see if we can reduce the cost of maintenance by using some tooling like Essential Project. I’ll make another post here when we’ve finished the review but, in the meantime, if you have any tips or pointers I’d be delighted to hear them!1. I’m aware that parallel is technically not a dependency but project managers use the term to refer to links between projects so, because this is a tool for them, I’ll roll with it.