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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
What is your advice about the best way to choose your PMO Style?
Not subscribed yet? Do it NOW!