Learning to Walk Before You Start Running
PMI describes the Project Management Office (PMO) as a strategic driver for organizational excellence. The PMO seeks to enhance the practices of execution management, organizational governance, and strategic change leadership. Because of differences in organizational structures, power and politics, and culture, it would be extremely rare to ever find two PMOs that look the same. For example, if you had three American companies in the same business of manufacturing motorcycle tires and each had 4,000 employees which included 100 IT people, their PMOs would still be different. Company A might not have a PMO, company B could have a PMO where the project managers (PMs) do not report to the PMO, and Company C could have a mature PMO where the PMs report to the PMO. This article is meant to give some guidance for starting a PMO and eventually growing into a Strategic PMO (SPMO). Remember, People + Process = Success.
Assessing Your Current Condition
Before you really start, it’s important to understand your organizational structure because it will affect what type of PMO you will eventually have. Table 1 shows the six types of organizational structures with short descriptions. Whatever your organization type is, you should be looking at the benefits and challenges your organization has, so you can capitalize on the benefits and work on diminishing challenges as you move forward.
The next step is to find your baseline. The questions to ask are: How many projects are underway and what is their current status? Are failing projects or extremely risky projects being cancelled? If not, why? What new project proposals are coming down the pipeline? Do you have any redundant or overlapping projects? How is this competence being realistically tracked and documented? Do any of the projects link back to corporate strategy or goals? Do you use a project management methodology and is it “institutionalized?” If not, do you have any processes in place that could become part of a new project management methodology for your organization to use?
After looking at all of this, you should have a good idea of where you are starting and then be able to compare your current baseline to an existing capability maturity model (CCM or Table 2) to determine where your organization stands in terms of generally accepted process standards. After you find your organization’s maturity level, the next choice is what amount of change your organization is willing to accept.
It’s crucial to keep your eye on the prize. That is, it is better to run projects that have more repeatable processes. From my experience as a PM, I can verify that the lower the level of maturity, the greater the failure rate on projects. Project management must exist as a repeatable, quantifiable process (found on Levels 3 – 5 of the CMM table) for there to be any real chance of consistently bringing projects in on time, within budget, and according to customer expectations.
The major causes of why projects fail are not the specifics of what went wrong, but rather the lack of policies, processes, and procedures. There are many challenges in setting up a PMO, but the biggest ones are underestimating the effort and complexity involved and instilling cultural change throughout the organization. Not an easy thing to do!
You must have senior management backing and on-going support to start up a PMO, and most importantly, you must understand that this will take time. It starts with small steps, short-term successes, and adding value as quickly as possible. I have organizations with a history of project failures decide to start-up a PMO as a quick “silver-bullet” solution hoping to fix an on-going situation. After two years, the PMO most likely dissolves. In most of these cases, senior management was not sincere in the backing of their PMO (OK – it started out as a zombie PMO that lacked strategy, vision, and mission), and/or the organization didn’t understand that the growth and maturity level of a PMO is like a bottle of fine wine (it gets better over time). This common error dooms many PMOs from the beginning because management is disappointed not getting quick results.
Dissolving a PMO may show that senior management doesn’t understand or respect the value a PM brings. They may also promote a highly technical person to the position of PM. I call this the “Halo Effect” because usually the technical person knows very little about project management or seeing the big picture (for example, all the inputs and outputs). They may be a poor communicator who eventually ends up losing their “shine.” One’s technical ability is a meager indicator of their project management ability, yet many organizations still don’t have formal training and/or mentoring processes in place for PMs to have their work evaluated. Some studies (i.e., US National Bureau of Economic Research) suggest companies should promote based on traits of good managers, rather than as a reward for good employment. This is an unfortunate situation and is telling of an organization. If there is a high rate of leadership turnover, it will negatively impact the value and stability of the PMO. The importance of a good PMO and consistent leadership can’t be overstated!
Beginning a PMO
Beginning a PMO is not an overnight event. This process requires a total commitment by the entire organization. It must be recognized that it takes years for a PMO to mature, have repeatable processes, and to fully add value to the overall organization. If management is expecting quick results, they are often disappointed.
For start-up purposes, it would be wise to have a PMO Charter document that describes its’ vision, mission, goals, and objectives. Furthermore, this document would describe the roles and the contributions the PMO is planning on making. In a way, this is a kind of press release that should be distributed to the organization, so everyone is on the same page and there are no surprises.
If you have no formal project management methodology for developing projects, then you need to work on one. A methodology should be viewed as a living organism that constantly needs to be reviewed and updated. Furthermore, the methodology needs to be scalable (or flexible) for different sized projects and/or complexity. For example, if you had a large project plan that has 3,000 tasks and another project that has 300 tasks, then the smaller project would have fewer mandatory tasks, less gate approvals, and less scrutiny. It’s important that the PMs “buy in” to the new methodology and that everyone starts using it, so there is no confusion or miscommunication within the organization.
Maturing a PMO into a SPMO
The SPMO (see Table 2/Levels 3 – 5) is created to assist in making sure organizational projects are done at the right time, with the right tools and templates, and that they contribute to the organization’s strategic plans. Typically, in the early levels (Initial or Repeatable) of the PMO, the PMO manager usually reports to middle management within a large IT department or to the Chief Information Officer (CIO) within a smaller IT organization.
As a PMO starts maturing into a SPMO, its leader (director or VP level manager) should sit with other senior executives within the organization. This position of leadership is responsible for overseeing corporate wide distribution and allocation on all projects. The SPMO leader will have several critical roles to fill. They must ensure that the project management process runs well while always looking to improve it. Some of the most critical responsibilities of the SPMO leader are:
- Resource management: The process of managing the overall project resource pool is one of the most valuable aspects of the SPMO. Resource management is one of the most complex challenges for both the PM and PMO/SPMO. Many would consider failures in this area as the Achilles’ heel of project management. It’s important to successfully link appropriate resources to project needs. Allocating the right resources to projects includes staffing with the right people and contractors (when needed), training, and mentoring.
- Prioritizing projects to align with strategic plans: Historically, most IT departments have spent approximately 75% of their annual budget on running their business, which included supporting their infrastructure and paying their employees. This means the other 25% of their budget was mostly spent on projects that had nothing to do with corporate strategy. This raises the question, why were they working on these projects at all? Most new projects should support the organization’s strategic plans, which require an integrative process for prioritizing projects.
- SPMO Steering committee: Besides the SPMO leader, the governance committee should consist of senior management from each of the businesses and subject matter experts (SMEs) when expertise is needed for selecting and monitoring strategic and nonstrategic projects. The steering committee should define what projects meet short-term and long-term strategic goals. They should also prioritize these projects since each organization has limited resources. One of the harder things the committee must do is kill (or put on hold) a project that is underway that may not be developing as planned. This should not be looked at as a failure, but seen as an opportunity to reallocate resources to more important projects.
Almost 75% of PMOs fall below Level 3 on Table 2, according to Gartner Research, a prestigious consulting firm. Moving from a PMO to a SPMO is a very difficult journey. An organization must invest in their people, as well as in time and money to become a success. That said, according to further Gartner Research, “IT organizations that establish enterprise standards for project management, including a SPMO with suitable governance, will experience half the project cost overruns, delays, and cancellations of those that fail to so.” Ultimately this means that you will be moving your organization from its present position to a future strategic position in order to exploit new products and markets in this fast-changing world. To be successful, SPMOs need to focus on customer value and using the best fit project approach (i.e., Agile, Waterfall and/or a combination of the two methodologies) to succeed.