다음을 통해 공유

How the Program Management Office Views Enterprise Architecture…

  • 아티클

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:

  1. data,
  2. artifacts or deliverables,
  3. technical functionality,
  4. infrastructure capabilities,
  5. milestones, and
  6. 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.”

Comments

  • Anonymous
    March 10, 2010
    The comment has been removed

  • Anonymous
    March 10, 2010
    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.

  • Anonymous
    March 12, 2010
    @Nirav, 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.   --- Nick

  • Anonymous
    March 14, 2010
    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.

  • Anonymous
    March 22, 2010
    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.