Having project and program managers within any organization, corporation, non-profit or public sector utility is by no means a new concept. They have been a staple fixture within the world for decades.
But how exactly are those project and program manager’s organized with the structure? What ideas and suggestions exist for how any entity, corporate or otherwise, should leverage its existing project and program managers against their own specific product and portfolio offerings.
There are several schools of thought pertaining to how any agency is going to organize its internal structure. To understand this better, we will take a moment to review some of the more common organizational structures that exist today.
Invariably, ‘most’ organizations usually adhere to one of the following organizational styles for their internal structure:
Functional – A very common organizational structure where team members will work in a specific department or group, such as engineering, finance, marketing, etc. But they may also be loaned out from time to time depending on project. In this structure, project managers have very little influence or power and general merely serve to monitor the performance of the project and provide status updates.
Projectized – This type of structure is organized according to projects instead of functional departments. Generally speaking, the project/program manager is both the manager of the project and of the people. This is a highly empowered role for project/program managers and affords them the highest level of control.
Matrix – This is a hybrid organizational structure where individuals have both a functional manager and a clear chain of command while also simultaneously having a project/program manager for projects. This categorization is broken down further into the concepts of a ‘strong matrix’, where the project manager has more influence, a ‘weak matrix’, where the project manager has less influence and a ‘balanced matrix’, where power is shared relatively evenly between functional managers and project/program managers.
So which structure should one use? There is much debate as to which is the ‘best’ structure amongst the choices. And in the end, it honestly comes down to ‘it depends’. Various organizations sometimes prefer a more regimental structure of functional managers. In cases where little cross collaboration exists between teams, this may be a fine choice. Although it will often lead to silos being formed between teams and can also cause inefficiencies if teams are doing similar types of work, thus duplicating effort un-necessarily.
Other organizations prefer a much more projectized environment. You will most often see this structure in consulting and contracting agencies, that loan out talent. Because individuals often work across various project types, the lack of a functional manager is not a problem. Project/program manages will then be tasked with ensuring that resources are being effectively utilized.
And finally, a balanced matrix will often be the choice for organizations that still want some level of breakdown by roles, but also want to ensure that silos don’t form and the organization is running in the most efficient manner possible. As such, they will opt for the hybrid arrangement.
Regardless of style, the question is often invariably asked: how should the project and program managers be aligned within the organization? The answer almost always yields the same result: by being part of a Project Management Office (PMO).
So what exactly is a PMO? To draw the definition from sources like the PMI, it can be classified as follows:
A Project Management Office (PMO) is a group or department within a business, agency or enterprise that defines and maintains standards for project(program) management within the organization. The primary goal of a PMO is to achieve benefits from standardizing and following project management policies, processes, and methods. Over time, a PMO generally will become the source for guidance, documentation, and metrics related to the practices involved in managing and implementing projects within the organization.
In essence, the PMO is an entity that works to govern the standards across the primary lines of business. Often, product life-cycle documentation, process and workflow standards and general best practices will be part of the PMO’s sphere of influence.
The beauty of a PMO is that it can be instituted in any scenario, regardless of overall structure. i.e., a PMO can exist in a functional, projectized or matrix environment. What you will often see in the more projectized structures is that the project and program managers themselves are within a reporting structure that includes the PMO. This further ensures that process normalization and common adherence to best practices is maintained.
Now many may ask: is there truly a benefit and long-term success rate with instituting a PMO? And the answer is a resounding ‘yes’.
The Standish Group Chaos Report, performed in 1995, indicated the following:
- 90% of projects do not meet time/cost/quality targets
- Only 9% of large, 16% of medium and 28% of small company projects were completed on time, within budget
- Inadequate project management implementation constitutes 32% of project failures
- 69% of project failures are due to lack and/or improper implementation of project management methodologies
Just to reiterate that last point, over 2/3rds of project failures can be directly attributed to a lack or improper implementation of project management methodologies. This is a HUGE number when considered in context. The sheer number of lost man hours and wasted money is massive when taken over a broad spectrum.
And it is this fact that really drives the point home for giving credence to the need for a PMO. The main idea behind the PMO is making things more collaborative and standardized across any organization. The more standardized one is, the less likelihood that things occur differently, such as disparate metrics types or inconsistent process. A great analogy for this is to simply think about a company that was non-standard in things we take for granted nowadays. Such as the same calendar style (Gregorian) or usage of the same power utility type in the same region. All these became standard for a reason; greater consistency and less likelihood of problems arising due to mixups. The same can be said for project management. The more you have people on the same page, the better for everyone and the better to monitor consistently across the board.
(I’ll be adding a Part 2 to this post elaborating further on PMOs and how they might be structured within an organization)
