Project management offices or PMOs are not new, but they have had their ups and downs over the years. Recently, PMOs have been making a resurgence, especially in the United Kingdom. A well-planned, established and supported PMO goes a long way to support the efforts of an organization in streamlining their 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 the IT department of their company. I had had some previous expertise in a number of 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 at present were not meeting expectations and causing concerns.
After some preliminary investigations, including a review of the existing processes and methodologies in IT, we put together the groundwork to establish the new processes needed to support a small, entry-level PMO. Consultative in nature, the PMO was to house all forms, templates as well as provide the project managers with the training, mentoring and overall support on all things related to project management.
The hope was that after the PMO was established and running effectively that we could move over 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 and not at all levels of the organization. In the CTO’s mind, this would streamline the 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, double take, a look of total stupor on my face at the mention of another set of forms. Why had these not been reviewed or considered when we looked at our setup package?
That is the moment when I found out that this organization, I had now been working with for about three months, already had a PMO. A well-established PMO with a few years of projects and experience under their 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 that it was actually a PMO but rather a small group in customer service dedicated to small, customer-centric projects. When digging a tad more though, 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 simply stated that only IT really 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 there should not be more than one PMO in an organization 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, the PMO is now a branch of their organization’s chart and very much an active and contributing group to the everyday work that is accomplished at all levels of the organization.
To think it all started with a simple question about a different set of forms. We saved ourselves a lot of work, and I am certain quite a bit of frustration by rethinking our strategy and ensuring that we did not end up with two dysfunctional PMOs.
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?
