You want to paint a picture: Did you get the “paint by numbers” with a predefined picture and stay within the lines or do you start with a creative stroke of red paint on a white canvas?
All too often we see PMOs that are built without following the same practices we would use to begin a project. Instead, they are built from a prescribed method without consideration for the problem being solved. This is where the trouble begins and the “bad rap” is attached to the PMO. Let’s look at some reasons why PMOs get a bad rap and what you can do to build a successful PMO for your organization.
Depends on What “It” Is
For organizations that have a mired of project investments, governance and controls are a must have. There is an immediate propensity to build “it,” without a consideration for what “it” is, how “it” will perform, the benefits/merits and success tracking of “it”. A PMO should never be built because it is vogue, but rather because it is essential to the success of an organization.
Before you build the PMO, identify the problem and the “appetite for change” (how much change can be introduced and over what period of time).
Gaining clarity on what “it” is will get you to a viable solution, and “it” typically does not come out of a book. An organization’s real needs should always drive the PMO build out.
Using Project Management Processes to Design the PMO
The design and build of a PMO requires the same due diligence that we would use to plan and execute a project. One of the current trends in building a PMO is “build it and they will come”. In reality, the PMO is built and quickly becomes a burden, so why are we not utilizing project management processes to define/design our PMO?
A large Telecom purchased a step-by-step PMO guide at a discounted rate that included templates and online training. After implementation, a PMO Administrator would create a “one-size-fits-all” compilation of reports from data that was collected monthly from the project managers. The Administrator would then email the reports to the leadership team on the requested timeline. The reports rolled up identifying the project portfolio, highlighting “at risk” items in red.
The PMO team began to realize that a long list of PMO-generated reports were not of any use to the leadership – they were outdated and not being read. The PMO was already getting a “bad rap” by the very people who once advocated its importance.
This particular PMO was created as a new box on the organizational chart, provided some “silver bullet” tool, to find that it has become an administrative ball of yarn that quickly began to unravel.
Define the Problem
The PMO should start with a defined Charter that identifies the business problem the PMO is supposed to solve, ties to the strategic vision of the organization and communicates a clear vision that will be embraced across the organization. Success measures should be defined as goals and measured/reported.
If you don’t define what you want then you won’t get what you want!
What are the Requirements?
Requirements are essential building blocks to answer the question, “What do we want the PMO to provide?” In the Telecom situation noted above, the organization jumped in headfirst with a solution. While the requirements themselves are not the solution, they enable us to lay the foundation for the PMO roadmap and subsequent success measurements. In this scenario, a gap analysis to determine the “as is” and “to be” was not completed. The gap analysis is a technique to identify the current situation and the future vision, which helps to uncover the people and process aspects and change impacts. The purported “best practice” methods/tools may not be addressing your organization’s needs.
Why Does Our PMO Not Have Any Clout?
Once you have gathered the requirements, put together a roadmap and start the execution, this is when we often see the PMO begin to lose traction. The PMO team may find itself asking, “Why do we not have any influence?”
The PMO is about people and process within your company’s culture. There is no cookie-cutter approach based on a new organizational chart. The PMO needs to have defined resource capabilities, be clearly accountable to its stakeholders and not create fiefdoms. Here are a few considerations that will help put the punch in your PMO; we call this the “accountability factor” of your PMO.
By establishing what the PMO will or will not provide and the roles and responsibilities of everyone involved, you prevent the creation of false expectations. The importance of the PMO should be documented and communicated (and not by the PMO). Interactions with vendors, contractors and consultants who work with the PMO should also be identified, and clear communications procedures established.
It is essential that the right people are in place to make the PMO successful. This includes transitioning and maintaining continuity so the PMO can increase productivity and measure success.
Is the PMO information relevant to support an escalation path where senior stakeholders can act and disposition it? If not, why? Status, risks, issues and financial information should be a factor in ongoing decision making across the PMO portfolio. The governance process should be established for decision making and handling change control for the PMO. For example, if status reports are provided and no one reads them is it because there is no value to them, they lack credibility, format is too complex or are they outdated? Where is the value to the recipients? Creating and reading reports takes time, and time equals money. The PMO has the accountability to address the lackluster interest in the reporting. It goes back to the basic premise that if no one looks at the report then why was it created?
One major PMO benefit is standardization, which includes reporting, processes and practices. Standardization also includes the execution and documentation associated with Risk Assessments for not just project risk, but also deployment risks. Having a standard risk evaluation ensures stakeholders receive the information the same way and can help with risk mitigation.
The PMO may have lost its punch because no one knows where the information is. To overcome this barrier a process for documentation should exist. This would be the guidelines for the centralized repository with required project information. A project library of key information will become critical for auditing and provide proof of SOX compliance.
To be truly successful, the PMO must continually go back to the definition of what stakeholders need for information and decisioning purposes. A PMO Communication Plan enables the team to understand and address who, what, when and how the stakeholders are engaged.
Understanding stakeholder information needs begins with asking the right questions. For instance, does this group want to distinguish Business as Usual, Regulatory/Compliance, Merger projects? Do they want to monitor success metrics and are they interested in determining deployment approaches? Too often, we forget who the clients are.
Stake in the Game – Selling the Value
Another key reason why PMOs continue to get a bad rap relates to the PMO not “selling itself”. The solution an organization decides to build must clearly state to the customer/stakeholders, “What is in it for me?” Here are some key metrics that senior management will be looking at when assessing the PMO value and engaging it across the organization:
- Controls over the financials – baseline ‘before’ and ‘after’
- Reduction in turnover by supporting project teams
- Greater project output (on schedule, time, budget)
- Flexibility to adapt to changing environment (how we handle change)
- Regulatory/Compliance (i.e. SOX) – controls over project investments
- Increased market share via reducing missed opportunities (decreased time to market)
- Stakeholder satisfaction
- Standardized way of doing things which infers increased productivity
Summary
Organizations continue to pour time, money and effort into building a PMO only for it to end up with a bad rap. Now is a good time to rethink how your PMO was built or how you are going to build one – and approach it using project management processes/practices!
*Contributor – Juliann Knott, Executive Change Consultant
Download PDF