Project Management Centers of Excellence (PMCOE) are becoming increasingly popular as a solution for organizations to streamline their processes while increasing efficiency, profit and competitiveness.

Generally, a Center Of Excellence (COE) is a business unit that has organization-wide authority. It coordinates continuous improvement initiatives, ensures that value is achieved in all areas, and fulfils the role of organizational thought-leader or consultant.

COEs are also created to capture an organization's best practices, standards and industry benchmarks. The COE facilitates the approval, transfer and integration of these best practices across the organization. For example, in a global manufacturing company, the COE may identify a best practice used in its European plant, tweak it, and implement the practice in its Saudi plant, too.  

There seems to be confusion between the roles of a Project Management Office (PMO) and a PMCOE. Some argue that the PMO sufficiently leads the organization to project management excellence. So, why would an organization with a well-structured PMO need a PMCOE?

In his book, Advanced Project Management: Best Practices on Implementation, Second Edition, project management expert Dr. Harold Kerzner states:

"The definition of project management excellence must extend well beyond experience and success ... Success is measured by having achieved performance that is in the best interest of the whole company, as well as having completed a specific project."

PMOs and COEs are only successful when they achieve the objectives for which they are created. Leaders in the profession note that the number of projects or years an organization has been delivering projects can't define project management excellence. Neither can the methodology it follows.

Larger, complex organizations may need a PMO and a PMCOE -- but their roles should be clearly defined.

A PMO is an important central hub with a mandate to coordinate and deliver all project activities as determined by the organization's needs.

PMCOE executives would operate as part of the business decision-making process. These individuals would report on the organization's project portfolio as a whole and provide the organization with project consultancy.

The PMCOE also supports the PMO through research, innovation and leadership initiatives and bridges the gap between PMO teams and business units within the organization.

What do you think? Are PMO's and COE's the same? Is a PMCOE just a glorified PMO? Have you come across a PMO and PMCOE in the same organization? Is there clear role differentiation?

The project management office (PMO) is one of the fastest-growing concepts in project management today, but it's not the only answer.

The PMO was born to aid the project manager. Surely then, the PMO (and, as a direct result, you) would benefit if there were a parallel organization for the technical managers, consultants, architects, design specialists, gurus of the world of application configuration and so on.

The PMO is not and should not be an isolated body talking only to the project managers. It should be one of many business units leading the delivery of company strategy.

Align the PMO to a single technical body, no matter what it is, and then align the two through a common process or methodology.

Think about your own in-house project methodology for a moment. Is it just for project managers or does it extend to integrate the technical tasks? Does it recognize the non-project management roles and responsibilities? Does it involve the technical deliveries and control mechanisms? It should.

If you have a common method, have you trained each team in a way that they both respect and understand each other's skills and duties? Have you done so in a way that ensures that the highest level of communication? You should.

When your business assesses the value, benefit and simply whether a new project should go ahead at all, it won't just be the project manager's view that gets the budget approved, will it? So align the technical gurus and the project gurus as one to ensure that the lowest risk and highest ROI projects are commissioned.

Perhaps the future is the perfect pairing of a PMO with a TMO -- a technical management office. It may be that the TMO is formed as a separate entity but closely works alongside the existing PMO -- or even that the PMO embraces and includes the TMO function.

The specifics of how a PMO or TMO relationship would take shape depend on what's best for your own organization, but perhaps it is the future.

What do you think?

<sup>Projects and programs aren't for life. So as the home for project managers, projects and programs, should we not consider the project management office (PMO) in the same light?

A Guide to the Project Management Body of Knowledge (PMBOK® Guide)--Fourth Edition contrasts projects with operational work by stating, "operations are ongoing and repetitive."

Without an end goal, the PMO will become purely a home for operational activity. And if the PMO is only seen as the home of process (methodology) and the body of control (policing) then it will become as exciting as working in -- well, I better not be specific -- but I'm sure you understand what I'm getting at.

I'm not saying PMOs should only be around for a very short time. I'm merely suggesting that because of the nature of what they contain, PMOs must continue to evolve and ensure they're really creating value.

Anyone leading a PMO has a responsibility to consider the end game. We typically know what it is that we are trying to improve, resolve, correct and direct -- but I don't believe that this should be done in a way that creates a permanent need for the PMO.

What we must avoid is the deliberate removal of a subset of project management skills and the replacement of these skills within a permanent overhead community: a PMO. In other words, a PMO should not regularly take on any of the project management tasks. For example, PMO leaders shouldn't say, "We'll look after the risk management and you, project manager, deal with the rest of the project manager's tasks."

It is said that operations end when they stop delivering value, and projects end when they do deliver value. The PMO should aim to end when there is no longer a need for it to exist because it has delivered the value. And that lack of need should be engineered into its strategy.

What do you think? Are PMOs meant to last forever?</sup>

In my last post, I used The Lord of the Rings to help explain the difference between a program and a project. And I also revealed the magical prize of a well-managed program: synergy.

Let's discuss an example in Taiwan: The country has been pursuing a series of e-government initiatives for some time, including an "e-Business" smart card.

Users insert the card into a reader, which then provides access to more than 30 different online government services. The options include business information, marketing and tax databases, tax return calculation, patent applications -- to name a few.

Business people no longer have to go to government offices, spend time telephoning officials or advisers, or print, collect or post physical documents.

The bottom-line savings are substantial. Over one year, a single business might save US$100. Multiply that by 5 million businesses, and the cost savings are around US$500 million. More importantly, it means businesses have access to information and their government whenever they want it.

This is the "synergy" I'm talking about.

But why does such an initiative have to be run as a program, instead of as multiple projects that need coordination?

In this case, more than 30 projects across different application areas are involved and they share a group of IT and telecom resources. With the need to exchange resources, and communicate both vertically and horizontally, a higher level of governance is needed.

Program managers and project managers have different focuses and see things differently. Program managers are primarily concerned with the coordination among projects, while project managers are primarily concerned with the management of their own projects. But working together, they can create that magical synergy.

Program management refers to the process of integrated governance of several related projects to achieve an aggregate result that cannot be delivered by conducting these projects separately.

It may not seem like it, but you can learn a lot about the synergy available through effective program management from The Lord of the Rings.

In the novels and films, the characters of Gandalf, Theoden and Aragorn inspire and command others to be courageous and achieve great feats. Even before a battle starts, these mythical leaders inspire confidence in their men, carefully positioning them in accordance with their skills. Each man has tasks for each stage of the upcoming battle. But they are only effective when coordinated with an understanding of their individual strengths and weaknesses, and knowledge of how they can be used to support and protect each other.

Under a wise leader -- acting as a program manager -- the power of these warriors can be multiplied when coordinated properly. This synergy ensures that every battle they engage in, and every war they fight, victory is at hand. Yet if badly coordinated, the strength and courage of these bands of cavalry, archers, spearmen or swordsmen -- the leader's resources -- is wasted, despite whatever heroic skills they possess individually.

Program management is mainly concerned with managing stakeholders, which in the case of an entire program is a larger, more diverse and more complicated group of than is involved in an individual project. Their interests are different, sometimes contradictory, and their individual impacts -- whether big or small, for good or bad -- may be very significant to the success or failure of the entire program.

The daunting scale of such programs are often not fantasy -- but may appear to demand wizards and heroes to manage them, let alone manage them so that a proper synergy takes place from the different projects involved.

What kind of projects can be managed through a program?
 

• Projects with a common outcome, that can create collective capability and share the same resources
  

• Projects that have the same tasks, that serve the same customer 
  

• Projects where their risks can be reduced when managed together
  

In such cases, "One Ring (Program) To Rule Them All" can bring advantages, not hordes of rampaging orcs and trolls.

Amidst all the talk about the value of project management offices (PMOs), maybe organizations should be looking at size.
 
"PMOs do not have to be big", says Ardi Ghorashy, PMP, PgMP, a partner with 80/20 Consulting Inc., Markham, Ontario, Canada, told me in a recent interview.

"The biggest mistake I think that companies make is that they create a monster organization with a lot of overhead and they also bring all the project managers to report into a PMO. That creates a big lump sum of cost sink that becomes very visible at the executive level every year when you review your finances.

Then the question will always get asked, 'What's the return value on this investment.' And project management has traditionally been very difficult and notorious at quantifying its ROI.

... By its nature, a PMO has such an encompassing impact on the organization that it affects a lot of things. You can't really measure it very easily. .... These days we say PMOs need to be implemented extremely thinly. [Thin] PMOs will demonstrate the value very, very easily."  

What do you think? Are "thin" PMOs the way to go?

Organizations that have a project management office (PMO) show they are moving toward a centralized management of project resources and strategic alignment to business goals.

But I find a certain level of readiness has to exist in an organization for it to create the platform for a worthwhile and cost-effective PMO--the type of PMO that contributes to the business not by simply being an extension that offers extra resources, but that works and evolves with the business.

There are key issues in organizations that usually hinder this:

•    Senior teams do not understand the PMO or its purpose
•    Senior management teams do not understand what project management is all about and how it can help them lower the costs of implementing projects
•    The PMO is viewed as something you install without careful and business-aligned planning

In my mind, PMO implementation must be viewed and managed as a project. A company should know why it's seeking to implement a PMO in their organization, what business issues it's trying to fix and what inefficiencies it's trying to improve.

A company has to consider:

1.    Organizational Readiness
Organizational processes will require changes to ensure the process flows into and out of the PMO are integrated into the organization.
2.    Cultural Readiness
The organization has to assess its readiness based on current resource pools, whether the resources can be migrated to PMO teams, and how other members of community will be able to align with PMO requirements based on their knowledge, experience, skills and mindset.
3.    Strategic Alignment
The goal is not just to have another department, but to have a team of people agile enough to act quickly and in a focused manner. And planning of the PMO has to include reasons that align with direct impacts on strategic goals of the organization.

As director of the enterprise program management office at General Motors (GM), Paul Checkowsky oversees program management offices around the world in different functionary areas like sales, manufacturing and supply chain. He took some time to answer a couple of questions about the state of the project management office (PMO) at the auto giant and throughout the world.

How has the economic downturn affected the PMO at GM?
From an economic standpoint, we've got to be a lot more careful about getting the most value for our money. A couple of examples:
   In the past, we've focused a lot on quality assurance of the process--making sure that people are following all of the steps. That's very time-consuming and can be expensive. Now we've built the quality-assurance process into the steps. We no longer have checkers checking peoples' work. We basically built the quality into the process, so that at the end, we don't need to perform a final quality review.
   We are also doing more backward planning rather than forward planning. We are making timing and content commitments to our business community at the beginning of the year and we are holding the project teams to those commitments. We then plan backward to determine what and when we have to do to achieve the commitments. Many project teams are not comfortable with this approach but it does force teams to get off to a fast start and forces them to resolve issues in a timely and efficient manner.   
   The other thing we've been doing is instead of being a policing organization, [the PMO] is now much more involved with mentoring upfront-- making sure the project teams are aware of the processes and helping them know where they might encounter bumps in the road.

Do you think more organizations are realizing the value of the PMO?
They are.
   Actually, in the last six to 12 months, I've [received] a lot of feedback from individuals saying that this new approach--where the PMOs are actually part of the teams doing the work--is very effective.
   [Organizations] themselves are finding ways to leverage these PMO capabilities and this expertise especially helping to identify and resolve integration issues, mentoring of enabling processes and eliminating deployment roadblocks. So I think it's been very positive, and I think it's here to stay.

   Mr. Checkowsky says it's hard to say what is going to happen with GM's EPMO in light of the economic situation. At the time of this interview, news headlines speculated the organization's possible bankruptcy.
   Overall, however, he says that "people are going to expect more with less. That's not going to change. We're going to have to do a lot more with fewer people, less money and less time."
    Despite the challenges, however, he says there are exciting opportunities out there. "Because of the conditions that we're facing, this is really an opportunity for us to put some changes in place that we've considered in the past.
   "Before, there wasn't a burning platform. Now, there is. So people are much more open to changes and new ideas--where in the past, they'd be, "This has worked for us all of these years. Why change?" Now people are realizing they do need to change. It's actually an opportunity to put some of these new approaches in place. We've just got to make sure that they're effective."


 
 

All successful project management offices (PMOs) have one thing in common, while all failed PMOs lack this same thing. Indeed, if your PMO has this one thing it's next to impossible for it to fail; similarly, if your PMO lacks this, you will not succeed, not matter how much more, time and energy you invest. So, what is this "brass ring" of PMOs?
    Cooperation.
It's funny, too, because of the wildly divergent theories out there about how project management ought to be performed and advanced, and what manifestations of the organization are indicative of success or failure. Some believe that only cost and schedule baselines contained in one software represent a successful PMO, while others hold a rival software combination as the only acceptable setup.
    Many auditors will express outrage at the lack of internal procedures and guides, still others want widespread professional certifications. Many managers who, at some time, had been associated with what they perceived to be a successful PMO will have misidentified the primary casual factor that led to that success. As I discuss in my new book, Things Your PMO Is Doing Wrong, the idea that organizational clout can be leveraged to compel successful project management advancement is a myth, whether that clout-leveraging takes the form of forcing the tool (mandating the use of a certain software), issuing procedures and guides, or any of the other so-called coercive strategies.
    The only way your PMO will succeed is if you adopt a technical approach to advancing project management capabilities that centers on obtaining that brass ring--cooperation--from the other parts of the macro-organization. And that level of cooperation can be elusive, indeed, but consider what you, the PMO director, are asking: You essentially want everybody else to change the way they've been doing business, for decades in some cases. I would submit that asking anybody to change anything they've been doing a certain way for years, even in the face of overwhelming evidence that the new way is better for everyone involved, is difficult in the extreme.
    Difficult, but not impossible.
    How is it done? To find out, you can pose a question on the blog that leads me to tip my hand and disclose the optimal technical approach. But there are two problems with that:
1. You still won't know my take on things that can blow up your implementation, even with the optimal technical approach
2. I'm expecting people to try to get me to reveal this secret, so I'm on to you.

Editor's note: You can purchase Michael Hatfield's new book, Things Your PMO Is Doing Wrong, in the PMI Marketplace.