What Does a Project Management Office Look Like?

Someone recently asked me about a one day seminar on building a Project Management Office (PMO).  I told them that there could be no greater waste of time than to get an individual to stand in front of them for one day to tell them how to build the PMO.  And if they did, I guarantee that that office would be closed within a few years.


PMOWhen talking about the PMO I love to say that at last count, there are 2456 variations on the theme.  My point is that no project office will be the same in any organization and nor should it.  And no one individual or training organization has the answer.


About 10-12 years ago the PMO became the ‘FAD’ across many industries but especially within IT and many organizations launched their first Project Management Office.  I was running ProjectWorld Canada at the time and we ran many sessions hearing from organizations about how they developed their PMO. It was all good news.  But then a funny thing happened: 4-5 years later those same organizations were quietly admitting that those original PMO’s had closed.


Why?  Because they were built for the wrong reasons, for the wrong people and by the wrong people.


I talk about leadership most of the time. Is this discussion about leadership? I certainly think it is.  You see, leadership does not have to come from just people but it can come from vehicles or organizations that we create. In this case the PMO is a perfect leadership tool. In my mind, its role is to lead the project management community in any way that it is asked to do. These last words are the key to the successful PMO: ”that it is asked to do”.


I’ve seen the virtual PMO whose job it is to set standards, create guidelines and advise when necessary. This version is run by contributions from multiple parts of a department or organization.


I’ve seen the PMO that directly employs 20 to 30 people with a Director-level lead, a budget and a performance requirement. This group is typically opening and closing large projects and often directly managing the largest, most mission-critical projects. Much more hands-on and a lot more responsibility.


And in the middle as I have said, there are 2000+ variations of these models.


So what’s the right answer? I don’t have it and no one should profess to have the answer for you either.  The key to success lies in the same method you would use to create a new custom software program or build a new product: you need to ask the customer.


If you know me, you might know that I have been in very involved in the creation and the history of the International Institute for Business Analysis.  Now don’t leave me.  This is not a pitch for the IIBA.  But it is a pitch for the role of the business analyst.  Whether professionally trained and certified or ‘winging it’, someone needs to play the role of the business analyst.  Before anyone talks about the virtual PMO, hiring employees or creating roles and responsibilities we need to step back and do a full needs analysis with the customer and all stakeholders.  We need to model any potential solutions back to the customer to be sure we are heading in the right direction. We need to make everyone aware of the costs, risks and rewards to a potential solution to their needs. In the end we need to make sure that every stakeholder is aware of what is to be built and what is involved in doing so.  And we need to get everyone’s buy-in not only in supporting the build but supporting the new product going into the future.


If you ever wondered what the business analyst does this is the perfect description. I like to tell BAs and project management communities that the role of the BA is to be sure that when it is built, it is built right the first time. I like to say that the BA’s role is to make sure that there aren’t eight revisions because the audience wasn’t properly involved.


What does a Project Management Office look like?   I can show you examples and models. But like the final look of your new kitchen, I can’t give you the answer quite yet. I need time to figure out what you really want, what you can afford and what you can support. Then I can tell you what your Project Management Office might look like.


Images courtesy of www.freedigitalphotos.net


More Posts

Do You Have a Plan B?

If I suggested to you that your current plan was going to fail somewhere down the road, would you be ready? The optimist would say ‘I don’t need a Plan

Scalability and Common Sense

Have you ever watched someone use a canon to kill a fly?  Use a software program to solve a problem that really just needed a pen and piece of paper? 

Subscribe to my blog

4 thoughts on “What Does a Project Management Office Look Like?”

  1. Thanks for the provocative post David! Your first paragraph roped me in. Start with why, correct? Why does a client believe they need a PMO? Then build it to suite their purpose and the needs of the customer, after you validate the needs. I wasn’t expecting a single and clear answer, and you delivered. 🙂

  2. Hello David, a very useful article…i read somewhere that 75% of companies that set up a PMO closed it down after three years because it did not provide any value. One question i have is whether the idea of creating a PMO at all is flawed or whether we have to be very careful to create one that is aligned to the customer – which i believe is your closing point. So for those companies that closed down their original PMOs, did they totally shut them down or did they relaunch them in a better form.

  3. Thanks David … truly enjoying the posts.

    @Martin –I agree with your point on alignment but there should
    be some degree of rigor and consistency. Unfortunately, too many of the failed PMOs wasted tremendous effort on defining standards and then insisting on strict adherence to them. As a result, the PMO would struggle with the business units to define “what is a project” because of the fear of the mandate of compliance.

    Following David’s outline to provide value we should perform
    the basic actions of initiation and planning to ensure our outcomes:
    * Step back and do a full needs analysis with the customer and all stakeholders (s/h analysis.)
    * We need to model any potential solutions back to the customer to be sure we are heading in the right direction (charter, scope definition.)
    * We need to make everyone aware of the costs, risks and rewards to a potential solution to their needs (cost-benefit and risk analyses.)
    * In the end we need to make sure that every stakeholder is aware of what is to be built and what is involved in doing so (scope definition, RACI matrix and schedule.)

    The formality and completeness of the identified deliverables is up to the individual organization (or unit) … which is David’s 2000+ variations on the theme.

  4. Well Dave,

    You managed to reveal your answer without giving an answer.

    The true nature of a project is as a temporary endeavour – so we do not expect to have a permanent project anywhere. However, I have worked in several, equally temporary, project management offices to deal with the overarching planning and coordination of numerous collaborative projects depending on a fairly large number of project managers each focused on specific deliverables.

    The nature of communications as numbers of participants increase simply demand that to expedite big initiatives you have to provide coordination that, for better or worse, becomes a program office or project management office (I prefer program office because it is more descriptive of coordinating projects). How else would I have been able to participate and coordinate in major initiatives like:

    * The overhaul of two nuclear reactors at Pickering NGS that involved many specialized participants from different partsof the organization and external service providers, each with their own team of project managers ($500Million in 1990’s);

    * The construction of a new datacenter building, infrastructure, migration (with 24/7 non-stop) and endless software upgrades to accommodate new configurations and hardware upgrades;

    * The consolidation of companies and the creation of a new company that required different teams to deal with different parts and somehow made them emerge as a unified whole;

    * We could go on, but this is the scenario that leads to a PMO.

    The life-span of the PMO would simply be the overarching lifespan across the temporary projects that it coordinates. It does not detract from what people have proposed in the past: you need standards so that contributing projects can be reflected in a consolidated status view, or the definition of RAG status uses the same criteria across the board, and so on.

    What you have noticed (and what was predictable) is that some organizations grew tired of PMOs that tried to carve out a long-term existence that grew counter to the temporary nature of projects. When we focus on long-term initiatives, like building a nuclear generating station, that may be 20+ years and there will be “longevity” in the sense that people get promoted, they retire, and they get replaced. Once done and over with, the PMO team may move on to another PMO just like a PM moves on to the next project, simply based on prior experience, but even if the physical space remains constant the PMO should then be focused on a different overarching objective – the pre-condition for justifying the PMO existence.

    Although this opinion may stir up a hornets’ nest, it might be a useful line of thinking about the WHY and WHAT and WHO and WHEN and WHERE
    of the PMO instead of only pondering the HOW.

Leave a Reply

Scroll to Top