Software lessons learned from a former PMO

As a former PMO lead, Olivia Montgomery learned the art of “endless, endless conversations.”

A PMO, or project management office, creates the standards, documentation, and metrics for achieving company priorities—often IT ones, like the deployment of new software.

Montgomery, now associate principal analyst at Gartner-owned Capterra, sees the PMO position typically as a neutral one that sits in IT, reporting to a CTO, acting as a liaison “between what operations needs, what finance and accounting has, and what IT can provide.”

And that means a lot of conversation.

Let’s say the business wants a new enterprise resource planning (ERP) software. Montgomery walked us through the early conversations and questions.

• The talks may begin with the software requester: What problems are you trying to solve?
• Then, they may head to IT: Can your infrastructure team support a tool? And at what cost?
• Next, to the front-line managers and users: How would this new system impact your and your team’s day-to-day operations? How much training would be involved? “Because sometimes there is a disconnect between the end users and C-suite,” Montgomery told IT Brew.
• And the PMO must communicate the technical requirements, change management challenges, and business goals throughout the organization.

Montgomery spoke with IT Brew about her PMO days and how to ensure a business’s new software plan isn’t just all talk.

The responses below have been edited for length and clarity

With a PMO, how does the software procurement process begin?

So, the business leader would submit an intake form. That would go to the PMO that then reviews it and says, “Okay, do we fully understand what the business problem is and what’s needed?” They’ll work with the business requester to make sure that it’s a fully fleshed out idea. Then they’ll take it, usually, to a steering committee; it’s often the C-suite. Then, that steering committee can look at [the request] and say, “Yes, this is the right time,” or “No, let’s start this project in Q2. These are the resources. This is our budget.” They’re able to understand how that request fits into the larger goals of the business.

What happens once a software tool is approved?

The PMO would assign the team to run it, and then the project manager is that escalation point for when big decisions need to be made. Maybe they’re not getting answers quickly enough from the people that they need answers from. They can go to the PMO and say, “Hey, I need help,” or “Hey, this stakeholder is not being too responsive. They haven’t attended demos. We’re not getting feedback.” That feedback loop is often one of the biggest sources of delays; delays are going to blow your budget, and they often cause a lot of confusion of expectations. So, having that clear chain of command and process for escalating bottlenecks and roadblocks is one of the main strengths, our research shows, for PMOs.

What other practices help to address roadblocks?

Everybody’s using the same terms. They’re using the same formulas to calculate ROI and budget. And all the information that’s being presented tends to be in the same format, probably within the same software tool, so that all reporting so everyone’s talking the same language and understanding the same things. That standardization of processes and language really helps make things run much, much smoother.

What factors lead to organizations not going with a PMO and not having one?

According to our research, cost was the number one reason companies kind of resist a PMO.

And what costs money, exactly?

I think [companies] think they have to hire a brand-new team…The most successful PMOs that I’ve seen? They tend to be a bit more organically grown from the company because company culture is just so specific. A PMO that is too rigid or is trying to bring in outside best practices causes a lot of friction, and people aren’t usually very happy about it. It’s definitely better to grow and develop from within.