Monday, October 25, 2010

Defining the Role of the PMO

The PMO (Project Management Office) plays a key role in many organizations, but it's success is not just about the enforcement of the use of templates and methodologies. Many PMOs get caught-up in structure and formality and lose sight of what they should be - a support mechanism for assisting the business to successfully deliver key initiatives.

A PMO should always play a support role for the business, however more often than not when a PMO is deemed unsuccessful, it is a result of the PMO having morphed into a highly formalized, tightly structured department with enforced standards that become a barrier to the business. Over time, the business refuses to support the PMO as they feel the formality is unnecessary and too time consuming - and the result is the disbanding of the department. While the business feels this is the best alternative, it actually is a poor decision.

When a PMO is structured correctly - and the right objectives are in place, the PMO plays an important role in project delivery. The business should be able to rely on the PMO to support business initiatives, while at the same time, feel their needs are being met.

The Template Trap

How many different templates does your PMO have? 10? 20? 50? Has  your PMO developed a template for almost every situation, posted them into a central repository and instructed everyone they must be used under all circumstances - and if a pre-existing template doesn't satisfy a need, a new template is created and posted to the central repository -- never to be used again?

If this sounds like your PMO, they have lost sight of their key responsibility. In the situation described above, your PMO becomes a significant cost center as opposed to a support center for the business. While templates do have there place to ensure consistency amongst project delivery, they are not the end-all to be-all. Templates are simply a tool - and should be used only to assist the business formalize thoughts and ideas so they can be actioned. For example, a Business Case, Feasibility Study or Project Charter are key project documents. But they are key documents because they assist the business to 'think-through' the initiative they want to undertake. These documents are of more value to the person writing them, than to the PMO for having them. And yet, many PMO's look at these documents as simply a deliverable - and leave it at that.

The power of a PMO comes from their ability to understand key deliverables such as a Business Case, Feasibility Study or Project Charter actually serve a purpose. Most of the time, the PMO will shy away from working with the business on the development of these deliverables - the argument always being "it's the business's responsibility to tell us what they want." While this statement holds some merit, it is also a way to skirt the responsibility of actually 'helping' the business through the process. It's this attitude of 'we develop the templates and the business uses them' that over time causes the resentment between the two areas.

That's the Way PMI Says It Should Be Done

You have a number of project managers that are certified in their fields - they hold PMP (Project Management Professional) designations or are certified Scrum Masters or Prince 2 practitioners. Your templates and PMO methodologies are developed based on the methodologies of each of the different practices, and there is little to no deviation from them. Problem is - there is little to no deviation from those methodologies.

Increasingly, PMOs are adopting the PMI methodology. The nine knowledge areas PMI's methodology is built upon are implemented and followed, while at the same time templates are designed to align to each of them. While PMI has a solid approach to project delivery, it is not suited for all projects. If all the rigor PMI suggested was imposed for all projects, it would be virtually impossible to deliver a project within the allotted schedule and budget.  Flexibility to pick and choose the elements of different methodologies that best suit the situation is essential in successful project delivery.

Each one of these methodologies have their strengths, but no one in particular is the best. The PMOs that offer the greatest benefit to the business use a mix of different practices, recognizing some circumstances are better suited to different methodologies. These designations and certifications provide a toolbox of tips and tricks, but it's the maturity of the PMO that determines when each should be used.

Aligning Business Initiatives with IT Solutions

The business has completed the Business Case and Project Charter and the project is initiated. The project team  sets off to deliver the project, never to be heard from again. Sure, the communication plan states the PM will discuss project progress with the Project Steering Committee and Project Sponsor on a regular basis, but do they REALLY discuss the project - or are they just giving status updates? There is a difference.

The PMO should be taking measures to ensure all initiatives undertaken by the PMO on behalf of the business remain aligned with business requirements. The documents created at the beginning of the project might clearly articulate the objectives of the project, but within a relatively short period of time objectives (or the understanding of them) could easily drift apart. How many times have you attended a project status meeting where someone nonchalantly mentions something and you get the 'what?' response. It's at this time you realize the project is in trouble - one party assumed everyone knew what had to be done; the other party assumed they also knew -- neither were the same assumption. Not a situation a template or methodology will fix - only communication with the business could have prevent this situation.

A successful PMO does much more than template governance or enforce project methodology. The successful role of a PMO includes flexibility, understanding, listening, alignment, and assistance. Once a PMO losses their focus of being a support department, they start to become a cost center - adding little value to the organization. It is usually at this point the PMO is deemed worthless and disbanded, resulting in the business losing valuable project delivery insight.

If you feel your PMO has fallen into some of the pitfalls this blog entry discusses and you would like to discuss options for overcoming them, please feel free to contact Innovalign at

No comments: