There’s an interesting analysis available through the PMO Executive Board on “Project Interdependencies.” In the problem statement, the author correctly observes:
As the volume and size of projects grow, the old problem of managing project and program interdependencies is becoming more acute: three quarters of PMOs consider “managing interdependencies” to be one of their most critical program management challenges.
First statement is cool.
Unfortunately, the next concept is somewhat troubling to me. According to the author, the solution to this problem is one of process
“… the ability to track and communicate project interdependencies boils down to two essential managerial disciplines: good risk management and clarity of communication with senior executives.”
In other words, we can track and communicate interdependencies better if improve our ability to manage risk and communicate interdependencies. Is that argument convincing to you? Seems pretty circular to me.
Digging a little deeper
Let’s take a look at the “project interdependency problem” for a minute. If projects had no interdependencies, there would not be a problem. However, if one project must complete before another one can deliver value, then there is an interdependency.
This is a problem because we may not know which project is the “critical path” project, so we may not do a good job of accounting for delays or cost overruns in the “source” project that can ripple across many other projects. In that aspect, understanding the interdependencies is a CRITICAL problem for the Program Management Office.
But let’s dig a little deeper. What causes projects to be interdependent upon one another? According to the same analysis, the factors to consider are:
- artifacts or deliverables,
- technical functionality,
- infrastructure capabilities,
- milestones, and
- end-user commonality.
Think through the list above. How many are NOT architectural? You could say that end-user commonality is not architectural, if you were to exclude business architecture from the discussion, but once you examine the kinds of models developed in an Enterprise Architecture context, 100% of the types of interdependencies chartered in these different projects are visible in, or predicted by, the architecture of the systems.
Improving the advice
I am not saying that a PMO shouldn’t be concerned with Interdependency management. It is not the job of Enterprise Architecture to track, communicate, and drive the flow of the project portfolio.
What I am saying is that the advice needs to be extended. The second sentence above, and the entire presentation to follow, needs to recognize the clear dependency that the PMO takes, or should take, on the Enterprise Architecture team to identify, review, minimize, and prioritize systemic and project interdependencies.
In other words, the second sentence above would become:
“… the ability to track and communicate project interdependencies boils down to three essential managerial disciplines: timely development and delivery of Enterprise Architecture, good risk management and clarity of communication with senior executives.”