Well, it’s not really “liveblogging.”  More like “asynchronously blogging,” but if you follow my Twitter feed, you’ll know that I am currently attending the PMO Special Interest Group conference here in beautiful Dallas, TX.  There’s a lot of information that I am sure will make its way into this blog in the next couple of weeks, but in the meantime, I figured I’d release a first cut based off of my stream of consciousness Tweets from the first day of the conference.

So here we go, my first posting as I leisurely and asynchronously blog the PMOSIG confab…

Trends, Themes and/or My Own Cognitive Bias

I picked up on three or so threads throughout the discussions and presentations of the first day:

1) The Portfolio Management Office should be treated as an entity – the same issues that a project manager has, a PMO has writ large.  A PMO must seek authority and deal with conflict on the macro level, much like any PM has to do on the project level.  It seems self-evident, but I confess that I have never looked at it quite in that light.

2) The PMO should be an enterprise PMO and not “just” an IT PMO – this was the question most asked by the presenters as they kicked off their presentation and gauged audience demographics: “How many audience members manage enterprise PMOs?  And how many manage IT PMOs?.”  I chatted with a couple of folks who had IT PMOs which IT couldn’t handle, and which were then absorbed or taken over by Finance or other departments.  In fact, this was the topic of Terry Doerscher’s workshop on Sunday, where he maintained that all enterprise changes should be managed by a PMO structure.  The basic concept is that the PMO needs to gain a total picture of enterprise work across operational and project areas, and only after doing so, can demand and capacity properly be compared.

3) The Portfolio Management Office as a Change Management Office – based on these discussions and presentations, I still have issues picturing one ginormous PMO controlling all changes within the organization.  The way I see it is that the PMO can often be decentralized, so that I have organizations within each business unit and even department that establish change management structures: baseline expectations/strategy, variance/problem sensing mechanisms, demand/capacity matching, and deployment oversight.  (See my previous post on organizational fractals).  The decentralized structure would allow the various PMO offices to manage complexity within the organization, better leverage unique skill sets, develop relationships with the end users, and better address change management scheduling issues.

Once you have that kind of structure within the organization, it seems inevitable to me that you would have to create some sort of uber-PMO to provide a standard change management process and the tools required to support the decentralized PMO structure – kind of like a central Change Management Office and the change management framework that such an office entails.


So the Change Management Office provides the underpinning structure for the decentralized, geographically dispersed PMO entities.  That, I think will make some great presentation fodder at a later date.

Specific Nuggets

So that being said, let me explain some of the thinking behind some of yesterday’s tweets and a couple of other random thoughts…

Tweets 1 & 2: “The theme so far: expanding the PMO out of projects to include operational process improvement…but doesn’t that require a change management framework to underpin a decentralized, complexity managing PMO structure?”

See point #3 above.

Tweets 3 & 4: “Good q’s in the k-note: what are some of the benchmarks of a good PMO? Which end of the candle can be burned first: PM or PPM? My take: you may not need stellar project management to implement PPM, but you do need solid project estimating to start.”

This is a question that often comes up in tool deployment: “we just want to implement portfolio management and project selection.  We don’t have time to develop project management maturity.  Our executives want a portfolio level view now.”  Personally, I think that’s more or less doable, with the caveat that unless you have decent project estimates to work from, you can’t do cost-benefit analyses or demand/capacity management.

Of course, that assumes that all of PPM boils down to a project selection mechanism – which it is not, but that’s often the most visible aspect of PPM as commonly implemented.  With good estimates, you can also do better benefits realization, and lessons learned at the end of the project.  Without estimates, I am not sure what you could accomplish by trying to implement PPM.

Tweet 5: “I like Oscar’s model of PPM as the balance of business priorities, organizational constraints, and enterprise work portfolio.”

In the keynote, Oscar de Lucia presented an elegant model of PPM as the management of three constraints – as follows:


Tweet #6: “PPM – it’s all in the teleology, perhaps followed by an exercise in motivation.”

The essence of PPM lies in identifying the underlying goals of the organization, and in mapping those goals to the actions of the organization.  Once those are defined, it’s a question of ensuring that folks remain dedicated to the vision of the strategy and its tactical implementation.  Continuing with the keynote, Oscar presented his four steps to PPM:

  1. Define an actionable strategy.
  2. Generate the right work.
  3. Select optimal work.
  4. Monitor against objectives.


As I see it, that maps to my rough stages of PPM development:

  1. Define organizational goals.
  2. Establish a problem sensing mechanism around those goals.
  3. Perform demand/capacity management and strategic validation.
  4. Rinse and repeat after incorporating the principles of continual quality improvement.


…which segues nicely into the next topic, prompted by a question in the keynote…

Tweet #7: “Is strategy done unto the PMO, or does the PMO facilitate the progressive emergence of strategy? Yes.”

The questioner was asking if strategy should be developed independent from the PMO, and then used as an input to project selection – or if the PMO should be part of the strategy development process.

Personally, I subscribe to the philosophy that organizational strategy must be validated against real world project portfolios.  If we say that we use one prioritization structure to govern project selection, but use another, then the PMO performs the role of strategic validation.  Similarly, many organizations may not have identified their own drivers until they analyze an existing inventory of project work, and begin to assess that against the costs for those projects.  Hence, a PMO facilitates the progressive emergence of strategy.

In the absence of cost constraints, strategies are optional…

Tweet #8: “Attending an SAS case study on the PMO as a power hungry entity – not quite in those terms – maybe just power seeking.”

Evans Travis gave a great presentation on developing expert authority as a PMO in a professional services organization.  Really made me aware of the fact that a PMO struggles for authority much as a PM does in a functionally structured organization.  Good stuff.

    Panel Observations

    …a couple notes from the panel discussion that closed out the day….

    1. IBM, typically the trendsetter in the global PM space, is apparently moving away from the PM as a job description, but more as a capability that an individual possesses.  (And really, they have 27,000 project managers supported by a PMO of 6 FTE?)
    2. Portfolio reporting is the driver for standardized processes.  Once an organization decides it wants standard reports, standard processes are never far behind.  Individual project managers with nonstandard processes does not a Portfolio Management Office make.
    3. One of the key roles of a PMO is to maximize resource utilization and ensuring that resources are used across silos.
    4. The PMO value is in sharing the skills to enable the capabilities to create desireable outcomes.   Do you have information that could be shared that would benefit the organization?  If so, there is value within a PMO.  Once you have such a process and you want to share, you need a PMO – which then may be further charged with ensuring compliance with this new process.  Arguably though, it all comes back to risk mitigation and management.
    5. Agile and PMO starting to meet in the middle.  Interesting to see that there is an Agile presence at the conference, and that PMOs are working with Agile practitioners.
    6. When asked what is the optimal skill set for a PMO manager, the response was that based on surveys, your best bet is to be a woman over 50.  (There goes one more career option for me.)


    ….and last but not least, I’ll leave you with my favorite quote of the day, from Sarma’s discussion of implementing EPM in a Midwest insurance company:  "So we implemented the PMO, and we solved the question the executives asked, but that may not have been the question they needed answered."

    Stay tuned for more thrilling observations from Day Two….