Here's a one-question pop quiz: What should a PMO do in your company? Not does, but should—and not in general, but in your company.
If you can't come up with a quick answer, don't worry—it isn't meant to have a quick, easy answer. If you can answer it quickly and without trouble, then you just might be ahead of the digital product management game—or very, very far behind the curve.
Silicon, Not Salami
Twenty-first century technology companies don't (and can't afford to) operate like mid-twentieth-century consumer-oriented companies. If you're in the business of making and selling traditional products based on well-established formulas and manufacturing techniques, then your PMO (if your company even needs one) may be able to focus on convincing everyone to adopt widely used processes, tools, and methodologies, because the job of the PMO will largely be to keep existing systems running smoothly and efficiently.
But contemporary technology companies don't work like that. They don't sell established and unchanging (or slowly changing) products; in fact, more than anything, they sell continual innovation and adaptability as much as (or even more than) they sell any specific product or service. The core of the modern technology company isn't the assembly line, it's the development project; and you can't handle digital product management in a development-oriented company the same way that you would in one that makes screwdrivers, sandpaper, or sausages.
How to Not Get There
Unfortunately, too many companies (and the PMOs that they bring onboard) simply aren't aware that there is a difference between the tech sector and the sausage-making sector when it comes to project management. They're all too likely to get caught up in a fundamentally dysfunctional cycle that looks like this:
The company hires a PMO to manage its rapidly growing set of projects.
The PMO brings in a comprehensive set of practices, puts them in place, and gets them up and running.
The PMO works hard to sell upper management on the new system.
Lower management and development teams go along because they don't have much choice.
Nothing much changes, upper management isn't happy with the (lack of) outcome, and a year or so later, there's a new PMO.
Repeat until the nth new PMO finally understands what key managers wanted all along.
If that looks a lot like a very inefficient and costly process of hit-and-miss, it's because that's what it is. But it doesn't need to be that way—not for the company, and not for the PMO.
What's Wrong With This Picture?
So, where did the PMO and/or management go wrong? Take a look at steps 1, 2, and 3 in the cycle we outlined above: the PMO basically gets hired, comes in with a system, sets it up, and convinces management to buy in. But there's something missing. What is it?
Well, there's nothing in there about the PMO asking anybody—high or low—what business outcomes they want from either the projects or the process of managing them. That's not an accidental omission in our outline of the cycle; all too often, it just doesn't happen.
But how can you give people what they want if you don't ask them what that is? If you assume that you already know, there's a good chance that you'll be wrong, and if you convince them to follow a program based on your assumptions, they probably aren't going to like the result. Practices mean nothing unless you understand what outcomes you're aiming for—and you won't know what business outcomes the key stakeholders want unless you ask them.
PMO for the Modern Era
What, then, should a PMO be doing in a contemporary, development-based company? If you are a newly hired PMO, the first thing that you need to do is understand your mandate for digital product management within the company. Notice that word: mandate. It implies both the authority and the responsibility to take whatever actions are necessary to achieve the specified set of outcomes. Unless you come in at the head of a conquering army (which isn't the case for most PMOs), a mandate is typically not something that you bring with you into a new job. You don't present your mandate to your employers; you receive it from them. And no matter what your position is, that mandate will vary significantly from company to company.
For a PMO, this means that you must find out what your mandate is from the top-level stakeholders with whom you will be dealing. Note that this doesn't mean going over the heads of everyone from the VP level on down and getting your authority directly from the CEO. That kind of mandate is typically generic ("just get the job done"), and it’s likely to run out rather quickly in the absence of tangible results. The mandate that you need requires a consensus of the top stakeholders.
How do you get this kind of consensus? You can start by asking individual stakeholders. You can ask them what their role is in relation to the company's projects, what business outcomes they want from those projects (revenue, for example, or even an accurate itemization of expenses), what kinds of problems they encounter in relation to various projects (such as marketing plans being impacted by schedule delays in developing new products), and what areas of digital product management need the most attention. Ask the project managers themselves what practices, resources, and policies would make the job of managing individual projects easier. More than anything, find what business outcomes each stakeholder would most like to see from your work as a PMO.
Be the Facilitator
But don't stop at asking each stakeholder what they want on an individual basis. If possible, bring them (or their designated representatives) together as a team and give them the task of forming a general consensus regarding your mandate as PMO. Your place on such a team will not be to lead them to a conclusion based on your own ideas about what's best for the company (or conversely, to stand back and let them talk and argue endlessly), but to facilitate the discussion and guide it toward some kind of overall agreement, drawing on your understanding of what each stakeholder wants.
The Customer as Stakeholder
But wait. There's another stakeholder who needs to be part of the process—one who it is all too easy to leave out, or forget entirely. We're talking about the customer. Even the best digital product management practices may not amount to much in terms of business outcomes if you fail to connect with the customer. You need to have a clear picture of what your customers want, and what they don't want; the customer is, after all, your most important stakeholder.
How can you bring the customer in as a stakeholder? Sometimes you can do it directly, through surveys, one-on-one interviews, or focus groups. Very often, though, you will need to rely on in-house sources of information—the people who know from direct contact and experience what customers want. Typically, this will include sales (and to a lesser degree, marketing) staff, but it should also include front-line customer service representatives.
Let them know that along with their roles as in-house stakeholders representing sales, marketing, and support, you need them to take on an additional role representing the customer as a stakeholder. Your goal should be to give the customer a place at the table at all times—even when there are no customers physically present.
From Mandate to Plan
The goal of this process should be a mandate that addresses the points that are important to each stakeholder, and that at least suggests pathways for resolving potential conflicts without ignoring or glossing over key issues. When you have such a mandate, you can put together a business plan.
The plan should identify a small number of top-priority issues (typically around three) based on the most important outcomes identified by stakeholders. It should set specific goals in relation to those issues and describe the value of each main goal to the company. Issues that don't make it into your initial plan can form the basis of subsequent plans; if you try to take on everything at once, there's a good chance that nothing will get done.
Serve, Don't Command
It is at this point that the PMO can look at which processes, tools, and practices would be most suitable for the tasks at hand. Without a clear mandate, tools and practices are all too likely to drive the process and determine its outcome. With a mandate, those same tools and practices can support the outcome.
This, in fact, is the key to the role of the modern PMO. The traditional PMO was likely to manage by command, bringing in a set of rules and practices with enforcement of compliance as the most immediate (and often the only) goal. The job of the modern PMO, however, is to serve the company by helping stakeholders define the basic digital product management mandate and to serve that mandate by formulating and carrying out a plan to support it. For project-driven, technology-based companies, this kind of service is an extraordinary—and in many ways irreplaceable—asset.
Michael Churchman started as a scriptwriter, editor, and producer of the game industry, working on the prototype for the laser-disc game Dragon's Lair. He spent much of the 90s in the software industry. During that time he developed a semi-automated system for managing localization in over fifteen languages. For the past ten years, he has been involved in the analysis of software development processes and related engineering management issues.