Please login or join to subscribe to this thread
A PMO needs to be the right answer to a specific business problem. In your case, it sounds like a PMO is a solution looking for a problem.
I'd start by confirming the rationale in establishing a PMO and then chartering it so that there is a common understanding of its mandate and scope of services across all senior stakeholders.
PMOs come in all shapes and sizes - some are supportive whereas others are directive, some focus on a specific portfolio such as technology projects whereas others cover the whole enterprise's portfolio, some are staffed and some are virtual...
In general I don't like PM's to report to departments (i.e. "Project manager mostly belongs to the engineering department"). In the scenarios where I have worked the PM's have been independent and report to senior staff directly. Most projects I've worked on require cross-departmental collaboration and cooperation, and by having the PM be in a specific department they are viewed by other departments to have a bias and therefore are much less effective coordinating projects within the entire business.
Is the intention to have all PM's report to the PMO instead of to other departments? Or is the PMO just to "support" various PM's across the organization? If the former then I think it makes sense for all projects to be reported equally (whether they are within engineering or not). If PM's will only be within various other departments, and only report "dotted line" to the PMO, then I'd have to understand more about the management structure and why PM's aren't centralized before being able to give any useful thoughts.
I'm not saying you can't have PM's spread around within different departments - I'm just saying that I'd have to understand more about the reasoning for that before being able to give any opinions.
Thank you both for your comments.
Bob, I fully agree with you. In a perfect world we would have all PMs centralized and not located in various departments. The issue is that we do not have full time PMs. All of our PMs are also actively working on the development for a specific product or running the daily business. Since they are not focused on project management only and are not necessarily PM specialist, we decided to build a PMO to better support these PMs. But that’s only one reason why we decided to build a PMO.
I’m a team leader within the engineering and also set the rules for project management and support our PMs. It works quite well, but non-engineering projects are not really considered within our standards. Now, we would like to transfer our PM rules and standards to our sister companies. That’s one of the main reasons to establish a PMO. While describing the PMO responsibilities the question came up, if we should include all the non-engineering project now and I’m really not sure if this makes sense.
I've worked in a company where there were several PMOs across the business, where the PMO I was part of focused on IT projects, and I've worked in a company where all strategic projects went through the PMO, even if they weren't run by a PM from the PMO.
In the first, we handled SAP upgrades and rollouts, but there were major transformation efforts led by another group (we were involved, but not directly leading the efforts).
In the second, we led most major transformational efforts, including choosing a new ERP. There were some larger projects that impacted IT that other groups were put in charge of, but they floundered and came back under our control.
The PMO model is important, but not as urgent as the skills of those leading the projects and their ability to collaborate cross-functionally. Rather than try and mandate all projects being led by our PMO PMs, we worked on improving the capabilities of the PMs outside of the PMO. The PMO director maintained a report of all approved projects, regardless of who ran them.
In that sense, it sounds like you have a bunch of what I call "project leaders" who aren't just managing projects but probably also executing them (i.e. the chief cook and bottlewasher). I had a past job where our product development engineers served this function and although they had responsibility to bring a new product to market they weren't qualified PM's and only performed (lowercase) project management as a necessary side function.
In your case, it sounds like PM methodologies and whatnot in the PMO were developed for a specific type of project, and I would think that the framework you've established might not work outside of the specific context. So if I do understand that correctly, I would not try to incorporate your processes which were intended for a specific type of audience/project to be applied to somewhere which might cause issues.
Further, if your PMO needs to establish organization-wide rules/processes/guidelines, I might take what you've set up for engineers and make it more generic. Or just start from scratch with a broader scope in mind. Or if it's just a single project that doesn't fit the mold (i.e. ERP implementation), oversee (coach) that project distinctly and separately to help guide them to a successful conclusion without trying to impose rules which don't make sense for them.
One of the things I wanted to implement in my particular past role was to have "PM coaching sessions" (i.e. lunch & learns) to help non-PM's execute their projects successfully. I did it one-on-one a lot which worked great, but I didn't get to open that up to a wider audience and I think that would have helped greatly.
Best I can offer without knowing more!
I have been in this situation and in my experience it is organizationally dependent.
My primary function is engineering, however I have often been involved in types of projects like ERP implementation which affect engineering but where the Engineering (big E) org is not prime.
In these situations, there are multiple PMOs as Aaron described. The Engineering PMO is primarily focused on the products, and is represented by the various engineering functions where the majority of the work is performed, and supported by other non-Engineering functions who may be affected by changes. Likewise, whatever part of the organization is prime on the ERP effort has its own PMO primarily responsible for their own work, but represented by impacted orgs such as Engineering.
There has to be some cross-pollination between the activities otherwise the solutions don't fit the higher organizational needs. The division of responsibility is important though because there are not enough hours in the day for a single PMO to manage every product, process, and other type of change in the same forums. For this reason, they are split organizationally and aligned to the primary skillsets/functions. This gets very messy during high level reorganizations, because now projects get re-aligned to different places in the org chart.
Please login or join to reply