The "accidental" program management office (PMO)
Program Management Offices (PMOs) have been around for at least 40 years. My first experience within a PMO was in 1980 as a junior member. In the 1980s I took on the role of Program Manager for multiple efforts and was exposed to different styles of PMO in government and commercial contract environments. Much of the literature (papers, books, presentations, and consulting) is either directly taken or modeled after this style of “controlling” PMO; effective model used within government, military, and large contract environments; including construction projects. Information Technology (IT)/Information Services (IS) organizations and some corporate-level support groups, attempt to use similar models but design themselves around either a controlling (budget ownership, project selection and priority, timing, and resource usage) or a supporting (planning support, project manager “loaners,” project coordination, planning tool support, etc.) style of organization.
In 1992 after two years of process improvement consulting across semiconductor, telecom, and other commercial divisions, I helped with the emergence of project management in the improvement of project execution and results. Along with the inevitable growth of basic PM skills and the number of projects, a new challenge emerged. The confusion of cross-project decisions and the differences in project management processes within the same organization became apparent. Some of the difficulties were attributed to not having process owners.
Small groups of people assigned, volunteering, or just wanting to make a difference, were the first examples I saw of these “Accidental” PMOs. Working for various clients since 1997, I find that this “Accidental” PMO approach is more common than one would initially assume.
Looking back over the last 10 years and especially the last five, there are learnings I want to share with the reader and those that attend the presentation. These learnings are based on participating in, leading, facilitating, and/or observing hundreds of actual projects—including several “Accidental” PMOs. This includes observations of portfolio exercises in a variety of industries and disciplines; attempts at various PMO and New Product Development (NPD) Guides, and their associated failures and successes.
Essential PMO Requirements
For a traditional PMO the list of purposes and requirements normally includes:
• Support Project Startup and Wave-Style Planning
• Identify and Correct Trouble Projects (see the Corrective Action Process Below)
• Support the Program (Collection of Projects) Portfolio
• Conduct Project Reviews and Audits
• Develop Project Managers (PMs) and their processes
• Manage the Resource Pool
• Improve the Project Execution Environment
• Provide a Communication “Conduit” between Sponsors, Customers, and Project Teams.
The “Accidental PMO”
Imagine that you are put in the position, or fell into it (or didn't get out of the way fast enough…), of “coordinating” 25 to 200 projects with no clear title, authority, or directions. Some of your boss's ideas include:
• Setup the projects—get them assigned to the RIGHT people
• Help the project manager(s) and team(s) get started with a good plan
• Continue supporting the teams with what you were already providing (technical expertise, reports, etc.).
As an “Accidental” PMO, begin by asking the following two questions:
• What do your projects and project teams need from a PMO—now and in the next six months?
• What do the sponsors and upper managers need now and this year?
Essentially they need, and sometimes want, coordination and communications management, with occasional quick decisions. And they always want a person or group that owns the basic processes and goodness of those processes associated with the concept, selection, execution, monitor and control, and closure of the organization's new product development projects.
The other items listed above (items one through eight) for the traditional PMO all have value. At the right time and stage of organizational development, they are of good use to an organization. However, as with other requirements there are priorities and limited resources. What follows is a sample approach if you find yourself dealing with or within an “Accidental” PMO.
Exhibit 1. PMO Process Guide TOC
A key ingredient of the roles and responsibilities coordination and communications, and basic processes design and ownership, has been a PMO Guide. A sample Table of Contents is listed in Exhibit 1. The “Accidental” PMOs that start with a vague mission (and normally an expediting role) begin to see the benefits of a common agreement on roles and responsibilities, and basic processes. Before an agreement is reached between the PMO, PMs, team members, and sponsors, there will continue to be a constant cases of either items that get neglected, or people feeling that others are over stepping their authority. I have observed that, for the most part, everyone is trying to do what they believe is best for the organization. Common understandings are not common when they are only verbalized, or worse, just assumed.
The development of this style of PMO Guide is not a documentation effort like one associated with becoming ISO 9001 certified. Unlike ISO 9001, there is no requirement that all processes to be documented prior to overall approval. Attempt to rollout sections of the PMO Guide as they are developed and required during the year (the presentation will provide more details and results). The PMO Guide is an instrument for clarifying agreement among various organizations. Most organizations have never documented these processes or have documented parts of the process(es) without regard to the integration with associated processes, and neglected to achieve buy-in from all participants.
Roles and Responsibilities
Roles and responsibilities should start with a high-level concept, and then clarify the individual roles and responsibilities. The PMO is an “intrusive” organization that is most often not welcome by everyone, especially mid-level management. The perception is that a PMO is a controlling organization that takes away power from the current structure, adds bureaucracy, and introduces distant control to a process that already works ok, though not great. The typical roles are listed in Exhibit 2.
Learning: Use the PMO guide as a “scratch pad” to document understandings and agreements among all participants. Take the time to layout a structure that is logical, then mark DRAFT all over it. Sell it as an instrument for discussion rather than something being dictated. Then focus on those processes and organization issues that are causing the most anxiety and distress for the organization and individuals. Issues to consider first are roles and responsibilities, scope management, and project reviews.
PMO Related Processes
Some processes, listed in the PMO Guide (Exhibit 1), are not directly controlled by either the project teams or PMO. Rather, these processes provide inputs or direction to the PMO and project teams (e.g., The Business Plan Development). What is clarified with these sections are the basic process being used (or referenced if written elsewhere) and the deliverables and timing, which affect the ability to plan, execute and close projects successfully. Some of this effort is for the general understanding of participants, but is also useful to promote deliverables “goodness” (e.g., the concept statements, which we use to initiate Project Scope Statement development).
Learning: Without buy-in by all participants, the PMO Guide becomes worth less and less. The less the buy-in, the more the words come together to create a worthless document.
Other suggestions include keeping each process description as simple as possible. A sample format for a PMO Review Process is show in Exhibit 3. The actual write-ups are simple, easy to read formats that have more “white space” than space allows. They are normally two to four pages in length.
Exhibit 2. Roles Clarified in a PMO Guide
For a few of the processes a form may be of benefit to the organization. Exhibit 4 provides a sample. Normally organizations that have “Accidental” PMOs dislike forms, so use them prudently. Sell them as a “coaching tool” to ask the right questions and keep the key pieces of information visible in a format that allows for quicker, better decisions.
PMO Tracked Project Process Metrics
In addition to roles and responsibilities and common processes being defined and managed; any PMO including the “Accidental” PMO, will eventually want to facilitate the measurement of the organization's effectiveness for New Product Development (NPD) or other types of projects. For NPD, one model of metrics has four basic categories:
The business impact of a new product.
The effectiveness of development activities.
NPD progress (approved project list).
Dynamic metrics, which predict or anticipate future results based on recent or aggregate performance.
Exhibit 5 provides typical metrics employed by some maturing “Accidental” PMOs.
Corrective Action Process
Sometimes called an Out-of-Bounds Review, this is one of the key areas where the PMO needs to become competent—quickly! It is listed as #2 in the traditional PMO requirements list and definitely a Sponsor/Customer requirement. There are aspects of a good process that are needed and welcomed by competent Project Managers and teams. Exhibit 6 provides some of the details in a sample process description format.
Exhibit 3. Process Description Format
Focus on becoming effective quickly. Review the list of being effective suggestions below, along with starting a PMO Guide, no matter the state of your “Accidental” PMO. Allow the PMO Guide to develop over time, keeping it updated as suggestions are made and sections are developments. Put together a project plan to convert the “Accidental” PMO into an effective, simple PMO in a time period that allow for continued upper-management support through implementation and initial execution of the initial processes. Focus on the 20% that gives you the 80% you desire. The 20% normally involves the sections highlighted in this paper.
Keep visible the needs of your two “sets” of customers—project managers and teams, and sponsors and upper managers. Neglecting one or both creates a poor environment for the PMO. Meeting both “sets” of needs is what a PMO is all about! And if this can be performed without a PMO—great. Find something else fun to do.
A simple plan for converting an “Accidental” PMO to an Effective PMO is suggested. The results through August/September for current efforts will be updated for the symposium presentation.
Exhibit 4. Sample Form
Agree upon a “common picture”—startup involves more buy-in than you can initially imagine. Have drafts available for people to discuss and make agreements. Be sure to include the suggestions of others.
Start where you are (or the organizations is). This sounds simple, but many individuals and organizations, sometimes on the suggestions of a consultant or self-help book, will attempt to make a big leap of improvement all at once (for engineers—a step function). However, individuals and organizations have inertia to overcome and prefer to follow a “curve.”
Find and focus upon areas where there is emotional buy-in for improvements and PMO usefulness. Then once there is improvement in those areas, the rest of the “good ideas” can begin in bite size chunks.
Focus on team support and accountability.
Have a road map—at least in your pocket. Let the organization know the big picture (as much as they can handle) and then let them focus on specific processes. Then as these processes are implemented, the PMO will be mindful of the interfaces to other processes.
Bite size chunks do not mean going slowly. Quick, simple improvements are better than slow calculated bigger ones. In fact, having success up front with a small effort tends to increase the momentum of acceptance of the remaining improvements and process implementations. Success breeds success.
Fix a simple thing (e.g., Understanding Our Roles).
Exhibit 5. PMO Process Metrics
Exhibit 6. Corrective Action Review Process Description
Proceedings of the Project Management Institute Annual Seminars & Symposium
October 3–10, 2002 · San Antonio, Texas, USA
Developing a Project Management Office in the Department of Energy, Energy Information Administration
This case example, a supplement to the report, PMIAA: Strengthening the Government Delivery Foundation, highlights project and program management capability building within The U.S. Energy…