Discover how to streamline PMO processes. Project management offices, or PMOs, are not new, but they have had their ups and downs over the years. Recently, they have been making a resurgence, especially in the United Kingdom. A well-planned, established, and supported PMO goes a long way to support an organization’s efforts in streamlining its project and program processes. There is a lot to learn from implementing, growing, and taking down a PMO.
Some years ago, I was asked to provide some consulting expertise to an organization looking to establish a PMO linked to its IT department. I had previous knowledge of several organizations with that type of assignment, and I was looking forward to this work. The ultimate goal for this change in structure was to help the IT group deliver more consistently on their projects, which were not meeting expectations and causing concerns.
Existing PMO Processes and Methodologies
After some preliminary investigations, including a review of the existing PMO processes and methodologies in IT, we put together the groundwork to establish the new PMO processes needed to support a small, entry-level PMO. Consultative in nature, the PMO was to house all forms and templates and provide the project managers with training, mentoring, and overall support on all things related to project management.
The hope was that after the PMO was established and running effectively, we could change its mandate to be more controlling or directive. The Chief Technology Officer (CTO) was looking at fully integrating the new PMO structure into its department and having project managers reside there rather than at all levels of the organization. In the CTO’s mind, this would streamline PMO processes and provide better control of the projects.
Everything seemed as if it was well underway until, one day when attending a stakeholder meeting for a project which was about to start, a stakeholder mentioned that having the new PMO was going to be great except for the need to use all different forms than what is currently being used through the client service department.
Okay, so I did a double-take and looked in total stupor when I mentioned another set of forms. Why had these not been considered when we looked at our setup package?
That is when I found out that this organization, with whom I had been working for about three months, already had a PMO—a well-established PMO with a few years of projects and experience under its belt.
How had I missed something that big?
Well, the truth is I had not.
In all of our work, this second PMO had never been mentioned. Not once. How? Well, that is easy when most of the organization did not believe it was a PMO but rather a small group in customer service dedicated to small, customer-centric projects. When digging a tad more, it was way more than that. It was a PMO with forms, templates, methodology, training, and associated PMs going on client engagements.
When questioned further, the CTO stated that only IT is involved in the size or complexity of projects that warrant the establishment of a true PMO.
So, where did we go from there?
We started with the premise that an organization should not have more than one PMO to be effective, avoid redundancies, and achieve the proper objectives. We highlighted the benefits of having a full view of all projects in the organization at a given time. We then began with a meeting of all concerned and started establishing a PMO structure suited to all levels of projects that the organization could undertake at whatever level or department these could be located. This meant a larger change and redefinition of the organization’s structure than previously understood or anticipated, but this was the time for this organization to make this move. Anything else would have been ineffective and probably dismantled within a year or so.
When I last checked with the organization, I found that the PMO is now a branch of their chart and an active and contributing group to the everyday work accomplished at all levels of the organization.
It all started with a simple question about a different set of forms. By rethinking our strategy and ensuring that we did not end up with two dysfunctional PMOs, we saved ourselves a lot of work and, I am certain, quite a bit of frustration.
Similar Content:
-
How to transition from a PMO to an EPMO
-
Taking a portfolio view: Why strategy drives projects
-
PMBOK finally expands on lessons learned, but is it enough?
