Establishing a Program Management Office for IT

The Coca-Cola Company's Stafford Green on how a Program Management

Office can ensure solid results from your project teams

By: Stafford Green

(Issue Details: Volume 6, Issue 1, March 2004).

If your company doesn’t have a well-tuned Program Management Office (PMO),

you’re missing out on one of the best opportunities to ensure solid results from
your project teams.

What can you get from this PMO? Your teams first work on things that matter the
most… you know what your project staff is actually working on… you reuse your
assets versus buying new… and everyone speaks the same project language,
including the definition of success. There are fewer surprises and, importantly, the
project cost is reduced.

Throwing a PMO together without the right ingredients and framework can create
a titanic bureaucracy that will sink in the warmest of seas. With this in mind,
allow me to share with you an approach we’ve learned on our path to success
here at The Coca-Cola Company.

About two years ago our company CIO, Jean-Michel Arés, asked me to start a
new group for the Information Technology function: the global PMO. The Coca-
Cola Company had dabbled in PMOs in various departments for years, but never
one which was overarching to all global IT employees. It was a direct report
position, and my CIO boss offered my team the headcount of two: that is, me and
one other person.

I was hoping more like a dozen people – after all, we’d be managing governance
of 200+ programs worldwide worth millions of dollars in spend and much more in
benefits, developing a new global standard methodology, creating templates and
scorecards, establishing training, etc. Our team would ensure that real business
value would actually happen, with risks and costs reduced.

I managed to negotiate one additional person into the team – this seemed far too
few at the time, but in retrospect, my boss was right.

Lesson Number One: your PMO team should be painfully small: it forces
the team to focus only on the right things that matter the most.

Large PMO teams will start meddling in projects, building PowerPoints that sell
versus tell, inventing obscure training and templates that aren’t really needed,
talking excessively about "process" and "tools," and laboriously extending the
time of company efforts into horrific Shakespearean tragedies. Read this: make
your PMO nimble. And if you have a large PMO today, cut it.
Our first step was to develop a project methodology. And we ignored offers by
consultant firms to sell us their proprietary methodology printed with those
dazzling colors; we wanted to own it ourselves and not ever ask permission to
make copies for our friends. At the high level of program and project
management, there are only tiny twists and syllables from one approach to
another.

The key to "good methodology building" is in the simplicity and the buy-in of the
leadership team. In the end, after a few days work, we created a diagram of six
steps. For each of the steps, we required only a few key deliverable documents –
those basic things like charters, checklists, workplans, performance specifications,
and risk assessment documents.

All PMO’s, no matter how great, will be accused of being bureaucratic. A simple
methodology, with easy-to-use deliverables, is the best defense.

Lesson Number Two: the project methodology must be simple – able to be

explained successfully to an average sixth grader.

Creating something that sounds brilliant, playfully using connotations and

derivations back to Latin and Greek, could gain points among your intellectual
peers, but it creates unnecessary complexity, and sets you up for a harsh, ugly
sell. Bypass your need to impress for your need to get things done.

At this point in our development – about 3 months after I accepted the task for
PMO creation – I had grand plans for templates, balanced scorecards, portfolio
management and advanced tools. But rushing our hundreds of developers and
managers into things when they haven’t absorbed basic concepts would have
been hazardous.

Lesson Number Three: one step at a time.

Don’t implement faster than the organization’s learning curve and your ability to
get senior management support. We upgrade our methodology every 6-10
months, adding a few more simple deliverables and logical requirements each
time. PMO success is delicious, but only in carefully eaten morsels.

Next in our development was a clear governance structure using "tollgates". At

each project stage – six times per team – the project leadership attends a 30-
minute tollgate meeting that I oversee. Attending the meetings are the
development lead, technology lead, finance director, and typically someone from
information infrastructure, information security, and architecture. The CIO attends
the "Top 25" key efforts. For small efforts, my team has "minitollgates" with
reduced attendees, and we poke at these projects with a short stick, hunting for
missed benefits, unmitigated risk, lost sponsorship and cost overruns.

Project leads from other programs often join to see what’s going on around their
effort. And occasionally there’s a business tourist; anyone on the payroll is
welcome; there are no secrets.
I believe that in all companies, a tremendous urge exists to PowerPoint
everything. Happily, this aspiration has yet to move into our personal lives. For
the PMO, I’ve created a simple rule:

Lesson Number Four: no PowerPoints.

PowerPoints get teams working on PowerPoints (versus, of course, the project).

The teams can spend hours making the green lines parallel and ensuring that all
green lines are the same shade of green. Freestyle PowerPoints cheer everyone
into conversational tangents that spin only the Mars rovers.

Our tollgate meetings use one word template called "Project Six." In it, we guide
the conversation for only six things elected from the charter. These six things are:

1. Scope: framed as the 30-second "what are you doing?" elevator conversation
to your CEO – e.g., "this specific problem W will be solved: X people will
receive Y benefit by Z time"
2. Hard benefit and success measures in a standard template
3. High level "before" and "after" business and technology diagram
4. Project finances in standard template
5. Related projects along the critical path
6. Risks – only significant, high risks

People have learned that in these now-notorious tollgates, the best way to answer
a question is, simply put, to answer the question. It is funny to me how this is a
learning. And if a marker is needed to help explain, I offer you a white board. By
having explanations this way, you get to learn if your team has the right
capabilities – if they know their stuff.

Business participation from the sponsor is a requirement. In order for the team to
come to the table, all the required documents for that tollgate and all the key
parties must be present, otherwise the tollgate doesn’t happen, and approval for
spending at the next stage doesn’t happen.

Lesson Number Five: business sponsors’ attendance at the tollgate

meetings is a requirement – no exceptions.

If they don’t show, you know the effort isn’t a priority for them and you can
happily kill the project, saving everyone’s time. Or, if they attend, but don’t agree
to "stepping up" to the estimated benefits directly in their P&L, then you can have
a friendly conversation about why the effort shouldn’t continue.

Training your project teams to create and properly use these project documents is
important. We would like to think that people hired "off-the- shelf" already have
the basics, but this just isn’t true – different companies have different priorities.
We’ve put together our own training materials, connected to a local university,
and are starting a series of classes to take project teams through not only the
"what" of effective project management, but also the "why".
Lesson Number Six: Train them!

Include the whys with the whats. If you don’t achieve everyone’s understanding
of the "why," the worst thing possible can happen: teams take the time without
the care – motions without the motivation - and the completed documents sit on
the shelf with a dying yukka. For example, if that charter isn’t updated with a
sizable scope change and re-signed by all, your training has failed. These
deliverables are part of the day-to-day management of a project; they must be
used.

Included in our training has been a series of lunch-and-learn sessions called

"Career Sketchbook". It is designed to answer some basics for employees around
the "what am I doing with my life?" question by completing a spiral workbook and
attending the sessions: "About the World", "About Me", "About the Company",
and a final seminar which puts it all together. Do not overkill: it took only two
days by three of us to build the material. Defining the "why" for your teams
includes: why am I here? What is my future?

When I take the moment to step back in my working life – really step back – and
think of the things which generate the most personal value, I think (1) new
friends: the diverse relationships that I have cultivated along the way and (2)
achievements: the successes that have lasting value. The funny thing is that
these are key values to business too – that is, a global set of employees and
vendors that trust each other, working on things that grow system profitably and
capability for years. With this, I can easily link work priorities to personal
priorities. That means self-generated inspiration.

Lesson Number Seven: true success marries making a living with making
a life.

Take the time make it real; make it personal. Create an environment which
engages the teams, encouraging project managers to do the same.

In Stockholm, I ran a project with fifty people from twelve different countries and
four different companies; our task was the equivalent of a company getting major
heart surgery – new processes, technology, and people. We seemed destined to
hate each other because of this high stress: we all came from such different
places (Moscow, Charleston, Cape Town, Reykjavik, etc.).

We took one weekend, put everyone in the Nordic forest with only a tiny bit of
equipment, and had the Swedish military teach us to build tents out of broken
branches, behead slimy fish to cook over a rub-sticks-together fire, and make
beds of fresh pine needles. That night, it rained.

Magically, it all came together. The team had to work together to eat and be
warm. Those initial fights eased, and collaboration occurred. We became a family
with a mission, and the basic mission that night extended along to the project
mission over the next six successful months.
Building a PMO requires a commitment from everyone. All facts must be friendly.
No high risk can be ignored. Everyone has a chance to speak up. Certainly, we
have not reached project utopia at The Coca-Cola Company, but to me, the
journey has been downright wonderful. Because of that – and please do pardon
the pun – things go better with Coke™. They can for you too.

--------------------------------------------------------------------------------

About the Author

Stafford Green’s 16 years in the Coca-Cola system includes work in operational

marketing in Russia, human resource in the US, and software development in
Austria. He lives in Atlanta, Georgia with his Norwegian wife, Kristin.
sgreen@na.ko.com

Copyright © 2008 SSON. All Rights Reserved.

More Articles: Want to receive more articles like this? Have a tip, learning
or case study you want to share?
Join our growing community of shared services and Outsourcing professionals.
Sign up to our eNewsletters and ensure you receive the latest news, articles and
features from our growing global community. For more information email
enquire@ssonetwork.com