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.”
5 thoughts on “How the Program Management Office Views Enterprise Architecture…”
Now I see why we have some of our problems which seem to be quite obvious. I’ve seen lately a program of four projects (and before other cases as well) where the following occured:
– interdependencies were not known (apart from the fact that projects are dependent)
– key resources were not managed across the projects resulting in resource steeling
– the bigger the environment is the more bits and pieces remain outside all projects until very late phases (this is very tricky and dangerous)
– the common steering committee didn’t help either as it was basically just a cover-up for problems (they eventually became obvious only at the very end when operations said that the emperor is wearing no clothes). Any attempts to point out those problems where unsuccessful.
And the result? Well, four "SOA"s (not kidding), four different applications instead of initially intended one common application (different in all aspects you can imagine).
I do not believe that just managing risks and communicating to senior executives helps with managing project dependencies (or perhaps in a company with very strong transparency culture).
Excellent points. There are some areas in "Program"MO though which need to be distinguished from the list in your "digging deeper" section. What has not been called out is program costs, "actual" timelines, resource constraints etc. which do not fall under the architecture domain. To me, architects are guard dogs of traceability of artifacts more than dealing with management of the actual implementation. There lies the difference and complications with the interdependencies that PMO plays a role in. EA inputs are a subset of factors that go into making PMO decisions.
I agree. EPMO activities include interdependencies that are not directly architectural. That said, in a well functioning EA program, the interdependency of timelines is revealed to be an interdependency on one of the listed aspects, and an EA model can not only illustrate that interdependency, but can provide insight into mitigating the risks involved.
We are in complete agreement with this statement: "EA inputs are a subset of the factors that go into making PMO decisions." I hope you would also agree with a corollary statement: When those artifacts are structured correctly as to be directly consumable by EPMO staff, EA artifacts are a *necessary* input into EPMO decisions.
good analysis. Though you kept ‘timely dev and del of EA’ as a separate discipline, it could also be perceived as a part of Risk Management. Essentially, if ‘good risk management’ dont consider EA inputs, its practically no more good.
Another obvious example to me is that a project can’t begin development until the legal pre-checks have been completed, or that code can’t be deployed until legal gives the ok etc.
I think that all PMO decisions should be made in a collaborative fashion and all relevant inputs from Architecture should be considered.