Developing your Project
Management Office (PMO)
http://advice.cio.com/jim_vaughan/de
veloping_your_project_management
_office_pmo?page=0%2C1
What should your PMO be doing for
you?
Posted by: Jim Vaughan in Best
Practices
Topic: Enterprise Management
Blog: The IT Project Management
Blog
Current Rating: Comments: 3
I have developed many different
PMOs over the past two decades.
These PMOs have supported
various different types of
organizations at various levels of
maturity responsible for various
different aspects of technical
development. Each of these PMOs
provided different services based on
the organization that was being
supported.
The first PMO that I developed was
designed to support a software
deployment group. The overall
organization was immature (SEI
level 1) and I was one of the few
people that thought in terms of
project management. I too was
immature, especially in the area of
project management. I was a mere
novice having recently discovered
PMI and the Project Management
Body of Knowledge (PMBOK). Using
the PMBOK like a hammer I hit my
thumbs many times. This
organization had two primary areas
that it supported: software delivery
(deployment) and problem support
for the same software. In my role as
project manager I was also the
technical face to the customer. You
might be wondering how I could call
this a PMO. The first key element
that made this a PMO was that we
were the organization responsible for
reporting to the customer on a
regular basis. This was for all
software releases long before they
were in the hands of my
organization. We also managed
delivery and roll out plans for the
software. The last piece that we
supported was the tracking and
scheduling of problem fixes. The
customer interface, release
management and problem tracking
were the three areas that the larger
organization required of us as a
PMO and we performed those
functions.
A few years later of was assigned to
perform project management for a
large software development project.
This project utilized the services of
about 180 people. At this point in
time we were at a much higher
maturity level (SEI level 3) and we
were actually using the words
“project management.” I became
involved in this project shortly before
contract signing. We had been asked
to provide a schedule to out general
manager. Imagine that, us giving the
date to him! Our date was three
months later than he wanted and as
hard as we tried we could not see a
way to shorten the schedule. He
signed the contract with a deliver
date three months earlier than we
thought we could deliver. Sound
familiar? The difference with this one
is that the GM committed to take
ownership of the difference in dates
and he did. With this very large and
diverse group of development
engineers my primary tasks where
managing deliverables and
communications. We were
constantly looking for a way to pull in
the schedule. Each month the GM
would ask if we found a way.
Ultimately we met our committed
date much to the surprise of our
customer who expected us to deliver
much later. I attribute our success to
our high level of process maturity
and our application of sound project
management practices. For this
particular PMO our primary
responsibility was tracking deliveries,
connecting the dots and keeping all
the stakeholders informed along the
way.
These were the primary services that
we in this very unique PMO.
What I have found is that there is no
set formula for what is to be included
in a PMO. Each PMO must be
designed to serve the need of the
organization. The ultimate objective
of the PMO is to ensure that the
organization meets the requirements
of scope, time and cost. The savvy
PMO leader will be able to determine
what services the PMO needs to
provide and can optimize the
organization around those services.
PMI and PMBOK are registered
trademarks of the Project
Management Institute (www.pmi.org)

The last PMO I will discuss was for

an architecture team. The hardest
part here was trying to determine the
product deliverable. We determined
that the deliverable was a technical
description of this new product. We
had pulled senior level technical
people from all over the corporation
to come together to design the “Next
Generation Wireless
Telecommunications System.” We
intentionally avoided the word
“cellular” as we did not want to limit
our thinking. By the way, ne’er did
we consider satellites ;-) With this
diverse group of thinkers we quickly
came to realize that the primary
services that we needed to provide
was to manage and organize design
information. This had to be
accomplished without stifling
creativity. The next thing we had to
provide was a forum for everyone to
share these designs and thoughts.