We’ve heard a lot about the role, or lack thereof, of the Project Management Office (PMO) in the Agile world. And, about transforming IT from a ‘project’-driven shop to a ‘product’-driven shop – again threatening the role of the PMO. So what role is there for a PMO? The same one it’s always had. No – not governance. The days of the PMO as methodology police are long gone. The true Strategic PMO is a portfolio shop, facilitating the decisions around which work should be done as opposed to how to do it. Making sure the work aligns with strategy and is balanced across departments, resources, and funding sources. Plus, monitoring the progress of that work to ensure successful delivery.
So why should a PMO switch to a product orientation? Three reasons.
1. Agility
First, most software development is done using some type of Agile methodology; and for good reason. Agile allows for frequent delivery in smaller scopes of work, seriously de-risking a larger initiative. But Agile also works best with long-standing teams oriented around one software “product.” In the PMO world products would equate to applications – ERP, CRM, PSA – pick your acronym. Rather than funding discrete projects, it makes sense to fund teams for each of these application “products” and then bring the desired work to them.
The bugaboo in this has always been infrastructure. You are simply not going to build out a data center in Agile iterations. Or are you? Today, many companies no longer build out their own technology infrastructure. They buy it from Amazon, Microsoft, Google, and others. Spinning up the required servers and infrastructure for a new CRM system is a matter of subscribing to one and configuring it on AWS. So now the infrastructure world has gone the way of “software” and can work in an Agile fashion, too.
2. Capacity
“Well, I still have office build-outs and other non-cloud infrastructure to build. Why would I organize this like products?” you might ask. The simple answer is – capacity. Let’s say we have a 500-person IT shop, and let’s assume everything, including application development, still uses a waterfall approach. The traditional way to deal with resource capacity management would say to plan each proposed project out by either resource type or some sort of resource pool. So now I have, say, 100 resource types to plan capacity across. All I want to know at this stage is, which 20 of these 200 proposals should we even take to the next stage? Trying to do this by detailed resource planning will lead to serious paralysis by analysis.
However, in a large IT shop, some people specialize. You won’t have an all-purpose SQL DBA, you will have at least one each for your ERP system, your CRM system, and your front-end Web presence. Same with programmers, QA, and others. What’s left is your infrastructure team – which is its own shared product. So now we have our product lineup – one for each application and then Application Infrastructure, Networking, Security, and other shared “products.” This alignment allows us to determine the capacity of the virtual teams working in these products so we can separate the requests by product and fit them into the capacity for each team.
Organizing capacity by product “teams” just makes sense when you are trying to match capacity supply with almost always overwhelming demand.
3. Strategic Alignment
What is the role of the PMO in this new product-driven world? The PMO—whether enterprise or technology—can help determine what the product lines are and the resource teams (virtual or real) that work on those products. They can bring corporate strategy to the table to facilitate funding conversations for each product. Plus, given there is more demand than work, they can organize the work by product to fit each product’s investment and resource parameters. The work could take the form of Agile style backlogs or full projects laid out neatly on a roadmap for each product, and they could be rolled-up into one combined enterprise portfolio. Finally, the PMO still needs to monitor and help guide the work for successful delivery and measure if the work has met the targeted business outcomes.
In the product development world, the role of Product Management is to “bring the work to the engineering teams.” The role of the enterprise PMO, and especially the technology PMO, is very much the same.
