PMO Architecture: Does your organization have one?

I like the idea of a PMO architecture and I agree that every PMO has one, the vast majority of them through accidental evolution. Whether by design or accident, the PMO architecture is a useful tool for understanding the key components you describe.

The one aspect of you PMO Architecture that troubles me is your describing governance and portfolio management processes as PMO Content Components. This may be a matter of semantics because I have found significant disparity in the use of these terms.

I define governance as the process and relationships that lead to reasoned decision-making. Another way of putting it is the identification of what decisions need to be made, assignment of decision accountability and the process for making those decisions. I define Portfolio Management as the process for ensuring an organization’s overall portfolio of IT-enabled investments is aligned with, and contributing optimal value to, the organization’s strategic objectives. I believe a PMO Architecture serves governance and functionally enables portfolio management, as opposed to governance and portfolio management simply being content assets of a PMO architecture.

As I stated earlier, we might just be using the terms differently.

Steve Romero, IT Governance Evangelist http://community.ca.com/blogs/theitgovernanceevangelist/

Posted: Feb 7, 2008 2:17 PM

Hi Steve, we are on the same page and I agree with you in terms of how you have "defined" governance and portfolio management. And, with respect to PMO Content Assets, the key point (and some may disagree with me on this) is that the "definition" of the process (where ever it exists) is very much a content asset of the organization. And there are many, many other content assets beyond just defined processes and policies. To not manage these assets (make them accessible, useful, usable, and improve upon them) or to have them randomly peppered about the organization in various PPM tools, collaboration platforms, network file shares, PC hard drives, emails as atachments, hard copy notebooks, and in people's minds, etc, etc, etc, is a tremendous missed opportunity. Just a little bit of organization, from a PMO Architecture point of view, can drive consistency, a high level of performance, and excellence in execution.

Posted: Feb 7, 2008 3:08 PM

Mark - your article is excellent and I wish I had seen this a year ago when I took over an existing PMO and organization that thought they had a tool problem when in reality they had a process and management problem. In order to rescue a troubled PPM tool implementation, make sense of how best to use SharePoint, and get things back on track, we stepped back and developed a number of core PMO processes, policies, and supporting information. We called this our PMO Playbook, but I like your term, PMO Content Assets, much better. I did not think to present the end result of our work as a PMO Architecture, but what we put in place and how we conveyed it is identical to the PMO Layer of your PMO Architecture graphic. I think Steve might be missing the point. The issue isn't semantics, rather that organizational project management processes (of which governance and portfolio management are part of) need to be defined as opposed to being open for interpretation or applied loosely or in an ad hoc manner by those using the PPM and collaboration tools of the PMO. And, if such processes are not defined, it's virtually impossible to manage, measure, and continually improve upon them. Put simply, if a defined process is not a content asset, then what is it..?

Posted: Feb 7, 2008 11:25 PM

As I noted in my initial comment, it was simply a matter of semantics. Mark cleared it up for me when he identified the "definition" of the process as the content asset. I will assume he is referring to the process design documented in a cross-functional process map. I will also assume the content assets will include all of the other process management artifacts required to design, implement, manage, an ultimately institutionalize a process. Being a Certified Process Master, I am delighted by Ann's comments as well. Even a defined process can leave too much to interpretation making it impossible to measure and optimize. It is great to encounter folks advocating good process management. We are all in viloent agreement.

Posted: Feb 8, 2008 12:01 PM

Mark, I''m with you on the architecture model but would like to make few observations which I feel would be the key to becoming successful and are therefore current drivers of the business world.
1. The market dynamics today demand Program office to be more involved and focussed with the business community and so a "need" has arisen to change the current PMO setting to be one of a "value provider" based and not the mediator alone. e.g. fast-paced business executives and team members has less time to explain their businesses as they need to get out and sell more but on the converse side we have seen a significant increase in the consulting numbers (by way of off-shoring, outsourcing etc) and they need more time to gain knowledge about the business. How would you see your architecture address this need?
2. Almost every business (specifically large and medium) today touches global economy in some shape or form. Most of them have PMO setup but primarily addresses the US need well but fails/lacks to understand the driving needs created through this global model. e.g. issue exist on multiple fronts such as getting time with business executives and members, clarity on supply and demand (resources), re-alignment of business teams to now work with not only offshore models but captive models as well. Where and how do you see your model providing these support OR changing the model to accept newer demands created by global economy?


Posted: Aug 11, 2008 1:48 PM

Hi Sunny, you are spot on. Just like you mentioned, today's PMOs, more than even before, need to gain knowledge about the business and business units that the PMO exists to serve and to be in tune with the demands of a global economy and the needs of the various business units that in turn serve their global economy. As a model, the PMO Architecture enables the PMO to do just that. In particular, the PMO Content Asset component of the PMO Architecture is the component that provides and enables such things as:

• PMO Processes
  
  
  
  • Project Management (PMBOK)
  
  
  • Traditional SDLC models
  
  
  • Agile Methods
  
  
  • Unique and custom purpose approaches (outsourcing)
  
  
  
  


• PMO Policies
  
  
  
  • Strategic Planning
  
  
  • Governance
  
  
  • Portfolio Management
  
  
  • Project Type Policies
    
    
    
    • Size and type
    
    
    • Domestic (PMBOK), International (Prince2), etc.
    
    
    
    
  
  
  • Policies for Collaboration and Document Management
    
    
    
    • Teamsites and Workspaces
    
    
    • Project Documents Folders
    
    
    
    
  
  
  • Project Archives Policies
  
  
  • Continuous Improvement Policies
  
  
  • Process Owners and Process Caretakers
  
  
  
  


• PMO Guidance
  
  
  
  • "Learn-As-You-Do" Resources
    
    
    
    • Tips, Tools, and Techniques
    
    
    
    
  
  
  • Training materials
    
    
    
    • Presentations, self-learning, audiocasts
    
    
    
    
  
  
  
  

Far more than a singular or unified PM methodology, the PMO Content Asset component of the PMO Architecture is where all of these things come together and work in conjunction with (as opposed to offline to) the tools, applications, and platforms of the PMO. It enables PMOs of all shapes and sizes, domestic and international, to truly have, institutionalize, and improve upon their best practices as opposed to managing projects and the PMO in non-optimized or ad hoc approaches. Simply implementing a PPM tool and stuffing it with data is not enough. Processes do matter, that is, effective processes, not those overly detailed, out of date, "one-shoe-fits-all-sizes" methodologies that give the illusion of project management organizational capability, but in actuality fail to serve the team and organization (and often frustrate all involved).

Posted: Aug 11, 2008 4:33 PM