If you sit six project managers around a table and ask them what the most important part of project management is, you will probably get seven different answers and one equivocation. Oddly enough, that's not a joke. Two or more project managers working on the same activity do not necessarily make it easier, less complex, or run smoother. In fact, conflicts between individual styles of communication and organization quickly lead to serious, sometimes even resume generating, blunders.
Now, I'm attached to making money on a deep, personal level. So, figuring out how best to negotiate my way though these situations where two or more project managers ostensibly share responsibility for project completion is a project near and dear to my heart. Everyone cannot, no matter what the organization chart says, actually hold ultimate responsibility (and therefore authority) over the entire project. That way lies madness by committee meeting. At the same time, if we cut responsibility into narrowly focused silos then each project manager cares only about his own little piece, leading to the development/deployment of products which meet no detectable need or simply do not work.
Somewhere in the middle ground lies the real work of a project management office. Most PMOs are out there selling themselves and their services. They talk about standardization, about the need to appease auditors, and their responsibility for the "overall project process." That's all lovely and important in the same metaphysical sense that your mother invoked when she told you to eat your vegetables. The heavy lifting comes in getting development, infrastructure, and support project managers to sit down at the same table without trying to kill each other.
Doesn't sound so hard, does it? Everyone has the customer's best interest in mind, right? Well...not really. Everyone has their vision of what the customer wants, certainly. However each project manager has the unspoken responsibility of making sure his group does not get the blame for anything which goes wrong. Just as importantly, he has a very different focus on what it means to "serve the customer's best interest" in both the short and the long term.
A development project manager focuses on his software release. His job is to get the code out of the developers heads into a form that mostly works, and out the door as something that passed some kind of formal approval process. Note that the software doesn't actually have to work, be scalable, or survive deployment outside of a specific environment to meet any or all of the above criteria. As long as compiled code does what the requirements say its supposed to, all is well in the development project manager's world.
An infrastructure project manager focuses on putting whatever software someone hands him into the existing environment in a reasonably stable way. He doesn't much care if the software meets the business' operational needs or if it even works as advertised. He is concerned with issues of access, stability, and that the software deploys in a repeatable, automated fashion. As long as the deployment doesn't break anything he will likely keep his job.
A support project manager is tasked with making sure that, at the end of the day, the number of calls his organization receives does not increase to the point where he needs to ask for extra bodies. Temporary upsurges are expected with new deployments, but long term growth (even in the face of increasing complexity) can generate serious problems. This focus ensures he will worry more about documentation and the development of support procedures than actual customer communication or service.
In some companies the business analyst takes on the role of product champion. In others, this work falls to business sponsors and executives. That's lovely, but these people are fundamentally still business people. Most IT project managers grew out of the technical sides of the organization. We speak a different language and see a different world than our cousins who deal with phantom numbers all day.
A skilled PMO manager could step in and bring it all together. A talented PMO director could sell that service to his organization by simply providing value, rather than trying to convince people he provides value. A good PMO project manager could get out there and make things come together with just his voice and a smile, if he were so inclined.
I've seen it happen. I've also seen what happens when no one steps up to meet the challenge. Of the two situations, my personal feelings about PMOs aside, I'd rather deal with the former.