Ever since the success of Y2K projects, PMOs have run rampant across the industry. Companies realize they must standardize project management methodologies and centralize the governance, project execution and reporting to achieve higher degrees of success with limited resources. Implementing the right way leads to efficiency and helps deliver projects even better, faster and cheaper. However, few companies have been successful in realizing the full benefits of their PMO, and eventually end up dissolving the PMO.

So what is stalling PMO’s success? It sounds so good on paper. There is no doubt centralizing these functions eliminates redundancy and optimizes the company resources. What we often ignore are two aspects – the human aspect of any change and the organizational context. Understanding these two complex topics greatly enhances the efficacy of the PMO.
  1. The human aspect of change: Change is difficult for anyone, as it requires people to get out of their comfort zone. So there has to be compelling reasons for change and continued efforts to keep the momentum.
In any culture change, middle management plays an important role. They are closest to the working mass and are in trenches with them. It is critical for them to be totally on board with the change else they could also become biggest obstacle. People also need to see what’s in it for them before they can full embrace change.
Very few people like the idea of going to a central body for approving and rejecting projects, reporting status of projects and being told on what they should and should not do.  People see increased bureaucracy. This leads to both active and passive resistance in creating a PMO.  
  1. Organizational context: The PMO is generally setup to solve a business problem.  There is no thumb rule to solve this problem as each environment is different. Some PMOs are set up to define standards, templates and process; some PMOs are setup for governance, while some are set up for consolidating reports from multiple projects. Then there are strong PMOs and weak PMOs. The bottom line is that there isn’t a single way to setup and manage a PMO. Many PMO leaders ignore that aspect and attempt to approach in text book style. There is already a notion of command and control with the name “PMO” and shift of power, so if the purpose and objective of the PMO is not aligned with the business problem, it is doomed to failure.
So how should one approach this problem? Here are 5 steps to address it:
  1. Understand why is the PMO needed? It should not be just because it is the norm or trend. Understand what challenges the organization is facing. Every organization faces challenges but the PMO cannot solve all the problems. A clear list of objectives must be defined when forming a PMO. These objectives must support solving the issues the organization is facing and need to be in the context of how organization is structured.
  2. Get executive Sponsorship: Creating a PMO means introducing a shift in power in certain areas, and with power comes politics. No matter how strong your leadership is, you need support of executive leadership. Your sponsor must be fully onboard with the objectives.
  3. Define the functions PMO is going to sponsor, socialize and get support: Before establishing your charter, you must get support and alignment with your sponsor. Then make sure you get your stakeholders on board with what you are going to sponsor. For example, one SaaS (Software-as-a-Service) organization had multiple product pillars each headed by General Manager. Each GM was accountable for the P&L; of his product line and had a self-contained R&D.; However, all products were to be shipped as single unified suite. The PMO was established to have consistency in process and methodology. There was also a need to provide several services not directly related to application development, such as build engineering, test and process automation, metrics, program management, standards and templates. However, given the autonomy each GM had, setting up a PMO in command and control would have been a recipe for failure. Given this context, following steps were taken to establish central organization.
    1. Standards, templates, and processes: Given that all GMs still had to be on a common release, it was necessary for their R&D; organization to follow the same processes, templates and standards. This became one of the functions supported by the PMO. PMO staff supporting this function helped define common defect management process, a consistent agile methodology and best practices, documentation standards, and style guides. The goal was not only to define them but ensure these were actually adopted and utilized across the organization and revise or retire them as appropriate.
b.      Have semi-formal training program: The PMO must analyze what subjects need structured training and organize it accordingly. It does not help if the PMO is only establishing standards, processes and templates. Proper training must be conducted to assist with adoption. One of the key drivers for having the PMO was to help transition to agile methodology; however little was known in the organization. Training does not always have to be provided by PMO staff. Vendors who specialize in training can be hired, too. Then work with executives and middle management to roll out the training program. Some may need to be mandated, and some may be optional.
    1. Be ready to mentor people in the organization: The PMO should not be process police, whipping people for not following process. They need to work with people in the trenches and provide assistance, understand why certain things are not working, why we should have new process and assist with tools they need to be successful.
    2. Establish a metrics portal: Software releases and the development lifecycle are complex and have many touch points. It is important to have a single source of truth that provides near real time visibility into state of projects, delivery and the value being provided to the business. Metrics drive behavior. What gets measured gets done. Many companies do not know much about defining and capturing a good set of metrics. This is a complex undertaking and has to be treaded carefully. Once stakeholders see the value they are getting from this, they will be much more supportive and metrics will evolve over time.
    3. Demand Management: More work with less resources is a problem every organization faces. Demand management clearly became one of the supported functions since this organization was no different. A governing body to review new initiatives was established and a process was established and socialized. To streamline the review process, a common resource pool with skills inventory of all resources and keeping track of when each person would become available was setup. Simultaneously, a list of all initiatives that were in motion and in the pipeline was created. This ultimately became a steady state process.
    4. Process and QA Automation:  This is an essential function for any software product development organization, but it requires specialized skills. Product groups did not consider them core to their organization. Thus the PMO stepped in to sponsor this function and develop core competencies in that area. These automaters not only automated the test cases but also various manual operations in the software development lifecycle.
    5. Build Engineering:  This is a function that must be kept independent of any GM, thus it naturally became candidate for centralization. While it is primarily operational, the PMO mindset of driving continuous process improvement is extremely beneficial. It helped identify inefficiencies in software build processes that directly helped improve productivity. Requests for automation were submitted to the automation team.
    6. Release Management: This is a typical program management function in R&D;, where people work with product teams on managing day-to-day issue from inception to launch and are responsible for making sure releases happen on time and to provide status updates. 
    7. Communication: While there were several advantages in having a GM structure, one inherent problem that soon surfaced was the silos and lack of information flow across the product pillars. While having release managers working across all product pillars fostered information flow, one additional function that proved very beneficial was a newsletter. This became a powerful vehicle to communicate strategy, upcoming initiatives, process improvements and what not.
  1. Structure your PMO: Once the core functions are determined, the next step is to get the right resources on the team and structure it appropriately. It will be much easier to get support when the organization sees value. In most cases, it will be a slow and incremental journey. People need to see it to be believe it.
  2. Change the name to Engineering Services: Like it or not, the PMO is considered overhead. It must constantly demonstrate value to the organization to remain viable. First, one should demonstrate it is there to provide support and service to the organization. Since the PMO was needed in the R&D; organization to not only establish consistent process and methodology but also to support non-core services, the name change was essential to create the notion we are here to help, not demand.

By having these services in place and following a collaborative style to problem solving, establishing a PMO helped not only gain support across the organization but also bring tangible value to the organization in a very short period. Each organization is different and the model above may not work in every organization. It is not to say a command and control mode for the PMO will no longer going work. It could still be successful where things like SOX compliance or mandatory organization behavior are required. What will surely work is contextual analysis and a step-by-step approach to establish credibility.

In summary, the PMO leader must first determine the services that are important to the organization and then create an overall approach to implementing them. Then he/she must gain agreement from the sponsor/executive management on objectives and functions. Finally, draft and operate on execution plan, carefully evaluating the results and adjusting the course as necessary.

What is your advice about the best way to choose your PMO Style?

Not subscribed yet? Do it NOW! 

Author: Salil Prasad (All Rights Reserved by the author).
Source: Original Text (based upon first hand knowledge).
Image: © Yuri Arcurs – Fotolia.com
Help us to improve it: how-todiscussion.