Project Execution in a Small PMO

Screenshot of Cora Assistant PPM Software

In this episode of the Project Management Paradise Podcast Johnny speaks to Matthew Snyder, from CRB, about project execution in a small PMO.

Matthew has over 25 years experience as a project engineer and project manager and is a passionate sustainability advocate and creative problem solver.

Subscribe to Project Management Paradise via one of the links above or on the right and you’ll automatically receive new episodes directly to your device.


By training, I am a chemical engineer. I started my training post-college in an engineering design company focused primarily on the biopharmaceutical manufacturing industry. Twenty years later, I find myself back in a similar role where we do projects focused on manufacturing system modifications, facility renovations, and some greenfield construction projects. Between those two roles, I was a project engineer and manager for a variety of different major pharmaceutical companies in the states. I currently work with CRB, focusing on the pharmaceutical industry. I work within a core team that is especially focused on biopharmaceutical products.

Define “Small PMO.”

I would start by talking about projects. The small PMO is focused on control and management of small projects. The way that my organisation defines small projects was regarding actual work effort was 40-180 hours of real combined effort across the cross-functional team that was charged with delivering the projects. Typically these small projects are going to be less than a year in duration—around 3-6 months—and the overall costs are relatively low—several thousand dollars—based on the goals being defined.

In the pharmaceutical industry, there could be some relatively high technology and thereby high costs, equipment items, instrumentation, and focused or deliverables that would be required as a result of these projects. The small project PMO that we put together, while it’s not necessarily the opposite of a larger organizational PMO; it was more focused on bare-bones support of the projects.

To just try and identify the minimum governance that you need to deliver a project. While a larger PMO is more focused on covering the entire basis, putting together all of the governance and tool you need to deal with any particular instance. In a small PMO, we were more focused on trying to solve the challenges we had within our business unit.

What’s the main reason for existence?

It primarily exists because there are specific challenges within an organisation that you’re trying to address. For the projects that I implemented the small PMO, we had a lot of small capital projects that were run by many different project managers.

As you might expect there, they had varying degrees of experience, and maybe not the best background or overall guidance to be delivering these types of projects. There’s a lack of consistency in the way that the projects were being executed; the reporting is done, the controls being operated on the projects. We didn’t have a good grasp of how the projects within our business unit and how they were interacting with each other and the resources that were needed to be able to support and deliver these. For us, it was more about the scheduling issues and resources availability issues that we created this.

Depending on your organisation and what your issues are, you could be more focused on the quality or cost aspect of project delivery.

Why is it important to make the distinction between project types and PMOs?

PMOs with more of an enterprise focus are ideal for strategic project management and helping to select and guide projects that are of a significant size. They’re more focused on the delivery of the larger organisation’s business purposes. Sometimes the inclination there is to treat all projects the same regarding how they should be managed. That doesn’t tend to apply very well to projects that are of a smaller scope.

It’s not necessarily any less important to delivering on the goals of the organization; it’s just that there not of long enough duration, there are not sufficient resources to focus on all of the aspects that you normally would when you have a larger multimillion-dollar, international, highly resourced project.

What are the minimum project governance features that must be included in a small PMO?

Even though there’s less formality in the way that smaller projects are run, it thinks it’s still essential to have certain formal aspects of the projects. These features include terms of initiation, definition of some of the basics of what you need for the project, a reasonable scope definition, stakeholders identified, and overall duration and costs. For us, a good description of the resources required for the delivery of the project.

The formality of closing a project is also important. There is that tendency to have projects linger on and tack on additional items to deliver and other goals to accomplish. There’s still need to control the scope and have regular updates both regarding the status and the resource utilization.

Using my particular case, we needed to put together specific project schedules and the interrelationship between the multiple projects to track the combined resource use. This way our end goal—understanding the resources that we needed to deliver the various projects that we were trying to provide.

Are there other standards project management tools needed?

Many of the other tools that were supported within the small project PMO would need to be developed based on the needs of the business. For that, we would go back and look at why the PMO was created in the first place. What was the priority? Was, was it that we were trying to deal with and resolve? That will be different for various types of organisations.

For us—we’re very focused on the schedule—so we spent a lot of time doing some voice of customer interview and collecting as much previously executed project data as we could. We set some good guidelines and definitions around basic types of projects that were typical for our organization. They encompassed four different types of scope and resource needs. We used those as a basis to categorize our projects that were emerging that enabled us to get a good look ahead as to the schedule ahead and being able to plan for these multiple projects that we were trying to deliver.

Building those tools around schedule and resource focus is what was required for us. Some of the other necessary projects tools are a status list, meeting minutes; communication type tools to keep your stakeholders informed, and basic cross tracking measures. You also need a means to do some change control and tracking of changes both to the cost and schedule, and resource requirements within the project.

Is there a challenge to maintain a reinforced compliance with the governance? How were you able to overcome it?

It’s not always easy. With the size of the project there that inclination to try and do it quickly and as simply as possible. There was resistance to putting some of these governance type measures in place. The initial intention we had when beginning to develop this small PMO was to keep it simple. Try not to deviate too much from the current practices and expectations.

I refer back to the customer’s voice. We did a lot of discussions, held many meetings and conversations with the project’s managers. We were able to extract from them processes that they were currently using and tried to draw some commonalities between them and find some areas where we could centralize what they were doing. Also, we didn’t try to drive too much change at any one time. We did a slow roll out of this program and regularly asked for feedback/input, while also responding to raised issues and people who were not following the procedures we had in place. We tried to identify why and make some slight changes so that we could accommodate them.

I think that’s another differentiation point between small and larger PMOs. Were able to provide those types of development type activities in response to the needs of the project management group that we’re trying to serve.

What are the other benefits of having a small PMO?

Some of the points I already touched on allow you to address the more localised issues of your particular business unit or operating group. It enables you to customise the practices, procedures, and bring less experienced managers into the fold. There’s not the whole cadre of governance and compliance evaluative activities that would be required by a larger PMO in support of larger projects.

Maybe some in the project management realm—changing the way you do things to accommodate your project managers as opposed to changing your project mangers, would frown that upon. The ultimate goal was not to create expert project managers, but assuring that we were delivering projects that were of value to our organization in the most efficient and timely manner.

What are some of the issues with have multiple small PMOs?

The whole idea of a PMO, in general, is to centralise that control and standardise the practices. That potentially doesn’t fit all of the cases. That’s a one-size-fits all approach that may not allow for enough deviation to make delivery of projects as efficient as possible when they’re small projects of this type.

Small PMOs aren’t going to work for the delivery of large projects. They’re for small projects only. I think hat the focused customization that could occur within small project PMOs between groups within an organization, could raise some additional challenges. Bringing conflicts between the ways projects are delivered among them as well as conflicts with the more typical enterprise or organizational PMO.

Other guidance?

It’s important to identify what the needs of your group are. You need to start with an understanding of the sound project management principles. You have to know what your business unit or group needs to get the best results out of the project management office you’re trying to put together. You have to understand if it’s tracking of cost or identification of particular risks within your organisation.

In our case, the scheduling and resources. If you can identify the needs, and then focus the tools that you want to employ, the governance measures, and procedures, that should deliver your goal. Make sure you are talking to your project managers and keeping it simple.

Lastly, providing frequent opportunities for training and addressing those who may be less skilled in project management process and asking for feedback to make your continuous improvement on the PMO.

Show Notes

Connect with Matthew on LinkedIn.

Find out more about CRB here

Related Insights

Want to See Cora in Action?

Cora PPM Software Laptop and Mobile Image