Establishing a Program Management Office for IT
Add bookmarkIf 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:
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 AuthorStafford 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 | |
