Ep 65: What Is a Construction PMO, and Why Would a Contractor Hire One?

A PMO is the owner’s rep for your software project. They sit above the software company, the implementer, and your own team, hold each of them to what they promised, and keep the project moving toward the future state you signed up for. Mid-size contractors hire one for the same reason enterprise firms do: the people who would otherwise run the implementation already have full-time jobs.

Adam Cooper, Greg Gorman, and Jeff Robertson all have PMO engagements underway, and in this episode they explain the role through the analogies they use with clients: the quarterback between the software company, the implementer, and the business; the shepherd who can see the cliff before the flock does; and a long drive, where a PMO can tell you where you are and how long you have to go.

What’s in this episode

• What a construction PMO does, and why it sits above the software company, the implementer, and your team
• Why a PMO works like an owner’s rep, including how holding a vendor to its contract saved one client upwards of $60,000
• What a PMO isn’t: not the implementer, decision maker, or a yes man
• How PMO engagements are usually paid, with a monthly fee plus milestone payments like a schedule of values
• Listener questions: joining mid-implementation, fixing processes before new software, and how many hours your team will need
• Why small contractors and enterprise firms both hire PMOs, and how a PMO differs from a project manager

Timestamps

00:00 Is hiring a PMO a luxury?
00:22 What a construction PMO does
03:40 The road trip analogy: where are we now?
05:11 The PMO as shepherd
07:11 Why busy contractors need outside software expertise
08:30 Does your company need a PMO?
09:27 The PMO as owner’s rep
13:39 Artifacts that show real progress
15:50 Holding software vendors accountable
17:19 What a PMO isn’t
20:00 Recommendations, not decisions
22:51 How PMO engagements are paid
23:55 Why a PMO can’t be a yes man
25:56 Is it too late to bring in a PMO?
28:42 Fix your processes first or after the new software?
31:02 How many hours your people need for an implementation
33:57 Who makes the final call?
34:25 Getting acquired companies onto one system
36:35 How to prove a PMO is working
38:23 Value creator or bureaucratic overhead?
39:26 Are we too small for a PMO?
40:27 PMO vs. project manager
42:02 Other names for PMO work

Transcript

[00:05] Jeff Robertson: Yeah, I think it’s worth saying, I would argue that hiring a PMO is not a luxury, which was kind of, I think, the baseline of that question: Is this something I really absolutely need or not? A good PMO is actually, of course, there’s some bureaucracy involved with it. We’ve talked about some things: we have risk registers and logs and schedules.

[00:22] Adam Cooper: Welcome to today’s episode of Construction Hot Takes. Gentlemen, today we’re going to talk about PMO, project management office. This is a term that’s come out more so in the construction industry in the last few years. It’s been around for a long time. It’s typically associated with some type of software project. We’re going to talk about it today. We’ve been getting a lot of PMO inquiries. We’re doing some PMO projects. We’ve been doing this work for a couple of years now, at least referring to it as PMO. We’ve been talking about it as software advisory or implementation advisory. It’s really come into fashion to call it a PMO, a project management office type project. So let’s kick off the conversation by explaining to people: What is a PMO? What is a project management office engagement? What do people hire us for, or what do people in the construction industry look to a PMO to accomplish? Maybe we’ll start with Jeff.

[01:23] Jeff Robertson: Okay. Well, I’ll describe it this way, in the way that we approach it. How about that? We act as, like, the quarterback. We’ll think about it that way. It’s football season, right?

[01:39] Adam Cooper: Sure.

[01:40] Jeff Robertson: We’re the quarterback for, and let’s just use an ERP as an example, although it could apply to lots of other different types of software, between the software company, the stakeholders at the business, at the company, and maybe there’s a third-party implementer or another third piece of software, like project management software, for example. We sit in the middle of that, or kind of above it, actually, to manage all of those groups and make sure that the stakeholders, all of the stakeholders in the team, are meeting their commitments, their schedule, the outcomes they’re supposed to be hitting, work product, et cetera. That’s the most basic way I could say it.

[02:24] Adam Cooper: Sure. Greg, how would you embellish that?

[02:27] Greg Gorman: Yeah, I was going to add one thing to that especially. I think there’s also a level of, I like the quarterback thing, but we have to keep everyone informed. That’s another piece of it. So we can talk to one side, we can talk to the other, but there does need to be a piece where we, as the PMO, are sort of making sure that everyone understands what’s happening, where we are, whether that’s a weekly meeting, whether that’s a monthly meeting, whatever it is, just to keep people all on the same page. Because if you think about what a PMO is, Jeff just explained: we’re in the middle, which means there’s things on either side of the middle. And sometimes those two pieces don’t have a chance to communicate, or they just get really busy doing other things. So we’re sort of the magnet that pulls the two sides.

[03:19] Jeff Robertson: That’s why I think about it kind of like a three-dimensional,

[03:19] Greg Gorman: yeah,

[03:22] Jeff Robertson: we’re not really in the middle; we’re kind of like, there’s this solar system of things happening around the business. That’s the center. We’re kind of above that. We can see everything from where we sit and make sure everything is working the way it’s supposed to be working.

[03:40] Jeff Robertson: We’re helping the client look ahead. A lot of people probably haven’t been through these types of things. A major ERP upgrade is not something you do every day. So we’re helping the client look ahead and understand the big picture of the schedule. I was actually explaining this to a client the other day: We’re going to drive from New York to Los Angeles. Are we in New Jersey still? Are we in Ohio yet? Where are we? And how much farther do we have? It feels like we’ve been going forever. We’ve just crossed the bridge. It’s like we’re still in New Jersey.

[04:12] Adam Cooper: I want to add to that analogy. It’s a good analogy. I’ve used that as well recently since I heard you say that a few weeks ago. I want to add to that, which is that typically there are multiple softwares involved. There might be an accounting system, a project management system, a payroll system, maybe some other systems, a service module. The end user, the company, typically wants to buy these softwares for functionality, and they want them to talk. The softwares themselves know their software, but they don’t know the other software. And the PMO, as you said, kind of sits over it and explains and guides so that, at the end, all the softwares are talking to each other. The integrations are working the way they’re supposed to. And we’ve guided that as a project management office. We typically have the big picture of how it’s supposed to look at the end, and then we’re making sure that the vendors are doing what we need them to do individually to make those functionalities happen.

[05:11] Jeff Robertson: I’ll give you another analogy. I thought of this the other day. I think of us as a PMO, we’re like a shepherd, and we’ve got sheep in front of us: all the different vendors, the software providers, the stakeholders in the company. We can see up above everything. We see the rocks, the briars, maybe a cliff coming, and we’re guiding the team where it’s supposed to go. Every now and then somebody gets bogged down; they’re in a briar. You have to get down, hit your knife out, cut the sheep out, help them out, get them ahead, then pop back up and look around to make sure any strays haven’t gone off and we’re still all going the right direction.

[05:51] Adam Cooper: That’s a great analogy.

[05:53] Greg Gorman: Yes, I like that one. If we’re going to stick with analogies, I’m going to go back to the car one, only because I just thought of something. The car analogy where we’re driving from New York to California: Are we in New Jersey or are we in Ohio? I like that analogy for this reason. In that case, we’re not just asking, ‘Where are we?’ We’re not just the map. We’re also the scheduler: When are we supposed to get to California? What day? We’re also kind of not in the driver’s seat, right? Someone else is driving the car usually.

[06:31] Adam Cooper: Well, we’re probably keeping track of who’s driving.

[06:32] Jeff Robertson: Multiple drivers.

[06:34] Greg Gorman: We’re tracking the drivers, but we’re not doing the driving. Someone could be in the backseat working on their laptop, and we’re not doing that either. We’re making sure that the schedule, the plan, the agenda, the map:

[06:48] Jeff Robertson: ‘Look, kids, Big Ben, Parliament.’

[06:50] Greg Gorman: Right. Doing that, don’t miss it. When are we going to stop for bathroom breaks? What time is lunch? You have to do a lot of things to keep that car on the road, but it doesn’t mean you’re driving the car, and it doesn’t mean you’re just a standby kind of sightseer. There’s a lot going on, but it’s still moving forward. You’re trying to move something forward.

[07:11] Adam Cooper: The other piece of this is that the end user, in this case the construction company, is busy. They are running projects, they are running their business, and they are not software experts. They are not integration experts, and they don’t necessarily have the talent or the bandwidth to manage multiple vendors like this. They’re used to managing vendors on a project, not on an internal software program. They need somebody with this type of expertise, who understands what these softwares can and can’t do and is there to help think about how the end users are going to use this whole ecosystem when it’s done. If there’s legacy software they’re not getting rid of, how is that going to play with the new software they’re putting in place? If you have Procore and you’re changing your accounting system, or you have an accounting system and you’re going from one project management software to another, or you’re changing payroll, from in-house payroll to outsourced payroll, bringing it back in-house, or changing payroll platforms, anything that has some type of technology aspect to it. Especially if they’re not enterprise level and don’t have an in-house IT department or those types of resources, they need experts to help them through the process. Just like we help with redesigning business processes and workflows, this is helping to redesign software processes and workflows.

[08:30] Jeff Robertson: Right.

[08:30] Greg Gorman: I think what I like about that is that it kind of segues into a good question: Does somebody need a PMO? I think if you ask yourself that question, which everybody should, and you answered yes to any of the things you just said: Are we very busy? Are we experts in all these softwares? Do we understand how these two things are going to connect, or do we need someone else? If the answer is no, then that’s one of the reasons why you’d hire a PMO.

[08:58] Adam Cooper: Correct.

[08:58] Greg Gorman: Because you’ve identified the reasons you might not succeed in this project or undertaking, in this adventure, to be very nice about it, because it’s not always fun. Do you need a PMO? Yes, if you don’t think that you can be experts in all the things you need to be experts in, in order to find success,

[09:22] Adam Cooper: and have the time.

[09:23] Greg Gorman: I would say the time is probably right up there.

[09:27] Adam Cooper: Most often, the reason we hear that we got called, or anybody gets hired as a PMO or hires a PMO company, is because they say, ‘I don’t have the time to manage this, or my people don’t have the time to do everything.’ They need some help. We need some guidance. We need an expert on our side. We need somebody advocating for us with all these software companies. I’ve made the analogy before: In construction, we’re kind of like the owner’s rep. We’re not the owner of the building, we’re not the general contractor, we’re not the trade contractors. We’re the owner’s rep, watching out for our construction company client’s best interests and holding all the vendors to account. We’re also making sure our client isn’t holding up the vendors by not giving them information they need. They may need to redesign their cost code system, update their general ledger accounts, or true things up, and they need advice about that. They need somebody to be a third-party auditor of these systems when they’re going through testing and configuration. There’s lots of different reasons to have a PMO involved.

[10:30] Adam Cooper: Yeah, I think we’re hitting on a lot of the same points.

[10:37] Greg Gorman: I like that, too, because sometimes people think, ‘If a client hires us, we’re going to work directly for them and put them first and only do what they want.’ That’s not necessarily the way to think about it. We are representing them and wanting their success. But if they’re falling down on their part of the job, if they’re holding up the software company or the implementation company, then it’s our job to step in and say, ‘Look, we need more from you,’ or, ‘You guys are risking running afoul of the schedule.’ I think it’s important to remember that we’re truly in the middle, and above and below, trying to conduct the orchestra.

[11:24] Jeff Robertson: I was describing this to a client the other day: It’s not unlike a construction schedule. You have a full-length construction schedule, from breaking ground to move-in, but you’re doing two-, four-, or six-week look-aheads along the way. There’s a lot more detail in those two- to four-week look-aheads; you’re looking at daily, sometimes maybe hourly, details. It’s the same shepherd thing: you pop up and go, ‘Okay, big picture, we’ve been really focused here for these next two weeks. Let’s make sure we’re going to land in a month from now where we’re supposed to be.’ That’s our job. We live in the detail and the big picture to make sure everybody and all the parts are moving the way they’re supposed to be moving.

[12:15] Adam Cooper: Another thing we’re dealing with on a few of our projects as PMO is overseeing the build of something custom, custom middleware. A lot of times we may be redesigning business processes to fit how the new software is going to work. The client doesn’t have time to do that because they’re currently doing the work the way they’ve always done it with legacy systems that are going to be replaced. They’ve got to figure out how they’re going to use the new system. What’s going to change with people’s roles and responsibilities? How do their day-to-day tasks change when they go from software A to software B? If you’ve been outsourcing payroll and now you’re going to bring it in-house, or vice versa, how does that change? Who’s validating data? Who’s validating time cards? Who’s making sure data gets back to the job and hits job costs correctly? The way they process things is potentially going to change with the new software. As a PMO, we’re also thinking about how the workflows will change for end users down the road and helping them prepare. We can see the future state;

[13:17] Jeff Robertson: we understand the current state. And how big a bridge are we having to build to get to the future state?

[13:23] Adam Cooper: Correct. What’s that change management process? We’re overseeing the shepherding of the sheep: the sheep are here, we need to get them over there, and we’re going to hit some struggles along the way. But we need to make sure that when we get there, all the sheep are there and ready.

[13:39] Greg Gorman: I think another thing we just touched on is that a PMO is not theoretical. This isn’t, ‘Well, we’re here, we’re in the middle, we’re on top,’ and really nothing happens. It’s not a lot of moving around and pointing. There is tangible output. There are documents to be created, a new process to be built, risk registers, a RACI matrix to build out. There are tools, artifacts that have to be created as part of the project in order to get from step A to step B and move through it. We’re not just standing back looking at the thing. We’re doing the work, too. We’re with the people doing the work.

[14:26] Adam Cooper: That’s what clients are expecting: tangible evidence that progress is being made. The artifacts we’re creating are how we’re tracking progress on the job. So, to Jeff’s opening analogy, we know where we are between New York and LA because we’ve got artifacts we’re creating. We can see how many open items are still on the risk register versus closed. That’s an indicator of progress in the transition through this migration to whatever the new platform looks like. Oftentimes a PMO isn’t just for a single software. It can be, but even if you’re changing a single software, it’s going to impact other softwares you’re already using. Very few softwares live in a silo completely these days.

[15:09] Jeff Robertson: Right.

[15:10] Greg Gorman: Yeah, there’s a lot of dependencies across a PMO, even if it’s just one software, which it might not be. There are dependencies, say, between the accounting team and operations, or between what the executives of the company need and what the implementation company needs. There’s a lot of facets of being a PMO you have to think about, so you’re not just standing back and thinking, ‘Well, it’ll probably get done.’

[15:38] Adam Cooper: Yeah, that’s not the right answer. That’s what the end user should be saying: ‘I assume it’s going to get done. I have a PMO. The PMO is responsible for that.’

[15:47] Greg Gorman: Responsible, and, yeah, they’re doing it.

[15:50] Adam Cooper: Something else that occurred to me is holding people accountable, holding these vendors accountable. We’ve heard, and have anecdotal evidence of, customers getting invoices for extra work that was actually part of the base contract. Just like an owner’s rep, we’re there to look at all the potential extras and validate or invalidate them.

[16:16] Jeff Robertson: I have an actual project use case: We saved a client upwards of $60,000 that they would theoretically have spent had we not pointed out, ‘That isn’t a change. The vendor owed that to us.’

[16:31] Greg Gorman: Here’s a real-world example. Adam will know this; Jeff won’t. We’re doing a big PMO project right now. It’s going to be about a year, actually a little longer than a year as of filming this podcast. Last night we got a big proposal, a big scope of work from one of the software companies, one of the vendors. We have to go through it. There are things in there that have high risk for our client. As a PMO, we have to look at that, take all of that risk on board, and explain it to our client. That’s something that happens throughout the project. Trying to mitigate risk is another really important part of why you bring in a PMO, so that you, as the client, are not the only person looking at this.

[17:19] Adam Cooper: All right, let’s take a little different tack: What isn’t a PMO? What isn’t handled by a project management office? What isn’t typically included in our scope? I would say the first thing is we’re not sitting on our client’s team as an end user. We’re not there to be part of their team full-time. We’re not an extension of their IT department or operations department. We’re an independent advisory.

[17:51] Adam Cooper: So what else isn’t a project management office?

[17:52] Greg Gorman: I think the most famous thing we’ve talked about here is we’re not the software implementation company. We do not own the software in almost every single case. We don’t build the software, and we don’t control the back end. We’re not coders, we’re not developers. We work with a vendor who’s selling that software or with the software company themselves, but we cannot control the software itself.

[18:02] Jeff Robertson: Right.

[18:29] Adam Cooper: Yeah, the VAR, right, yeah. We’re not a VAR.

[18:29] Jeff Robertson: What we do end up doing sometimes is acting as a translator.

[18:36] Greg Gorman: Sure.

[18:37] Jeff Robertson: Between the developer,

[18:38] Adam Cooper: or the Rosetta Stone.

[18:40] Jeff Robertson: Right. They’re speaking a certain language and the client’s speaking a certain language, and our job is to sit in the middle and translate sometimes. We’re also not tied to any specific software. This doesn’t just apply to accounting software or ERPs. It doesn’t just apply to Procore, ADP payroll, or any of those. It could mean all three of those things; it could mean more. It’s not tied to any one specific software.

[19:15] Greg Gorman: We could have been involved as Ascent Consulting, we usually are, but if we’re not, we can still be the PMO. It’s just, ‘This is what they chose, and now we have to figure out how to make sure that the end game occurs with whatever software.’ The other thing, unless you guys feel differently, is I don’t think we’re there to make decisions for our client based on how they want to use a system. If they need a new cost code system or need to change their payroll system, I don’t think that’s our decision to make. It’s our job to help them think about that decision.

[20:00] Adam Cooper: It’s definitely the role of the PMO to raise recommendations and help them work through these things. I’m doing one right now where part of our recommendations as the PMO were that we had an opportunity to redo their cost code system. Their cost code system was non-traditional. They’d been given bad advice a few years ago and made changes that weren’t going to support their needs long-term. We were going through this big transition, so we raised the opportunity to redesign their cost code system as part of the engagement. We advised them and helped them workshop through it. But ultimately, you’re right: it’s their decision. It’s their software. It’s their business.

[20:40] Adam Cooper: We make recommendations about which way data should flow. Should projects be originated in the ERP or in the project management software? Because you have the opportunity for bi-directionality. We help them evaluate: If you started here, who’s doing it, and what does that push into the other system versus the other way? Who’s doing it if you go the other direction? Then they can make educated choices.

[21:04] Greg Gorman: Our job is often to help them think through different options and make educated choices, and think through the outcome of those decisions. We can think ahead. They make a decision, it’s their company, but we’re there to help and guide. We’re also there to think ahead: ‘Look, that is going to change this, so we want to make you aware of that.’

[21:27] Jeff Robertson: Yeah, what are the second- and third-order effects?

[21:30] Adam Cooper: Doing this with a client right now: typically the project manager does three functions. They issue subcontracts, issue purchase orders, and validate timesheets. Our client said, ‘We don’t really want our project managers doing that. We want our contracts division, who’s part of accounting, to create all the commitments in the system. The PMs can send all the information to them, but we don’t want PMs wasting, or spending, their time doing that data entry. We’ll trust that to our contracts department.’ That was a choice. We evaluated: Well, then this changes the permissions for that role.

[22:14] Jeff Robertson: The data flow may change.

[22:15] Adam Cooper: Are project managers going to review that before it gets sent to the vendor or subcontractor? Or is it going to be, ‘I send it to you, you key it in and send it out the door’? So we’re thinking about how that workflow gets redesigned and whether there’s a system of checks and balances. That’s a real-world example of a PMO helping the client think through those second- and third-level downstream effects. Yeah. So what else is a project manager? A project manager is not a full-time employee. We are a contractor. We are hired to oversee a specific change management process.

[22:51] Adam Cooper: I’ll add that a lot of times PMOs are paid on both a time and performance model. Often there’s some type of retainer or monthly recurring fee, and then there are milestones for achieving certain goals through the project. Sometimes we call them stage gates; sometimes we call them phases. You’ll hit certain stages like, ‘Okay, we’ve connected this software to that software,’ or, ‘We’ve had a successful shadow payroll run,’ or, ‘We’ve successfully processed AP invoices with an automation tool.’ Some type of milestone achievement. That usually ties to it as well. It’s similar to how you hire a subcontractor to perform work on your project. There’s a mobilization fee, maybe some stored materials fees, and there’s general work they’re getting done. But then you have big milestones like temporary power, running water, or TCO being achieved, all milestones that could be billing lines on a schedule of values. Similar for a PMO.

[23:54] Jeff Robertson: Good point.

[23:55] Greg Gorman: I was going to add one more. I don’t know how to phrase this, but what else a PMO is not, bad phrasing, is we’re not a yes man or yes woman. We’re hired by our client and working with other vendors, but I think we have the responsibility of making sure there’s logic and reality to this project. It’s not just, ‘Sure, say yes to everything and make it easy for everybody,’ because things have to get done. I don’t think we can just say, ‘Oh, sure, whatever you want, we’ll do it.’ I don’t necessarily think that’s what’s best for the project.

[24:37] Jeff Robertson: Yeah, I’ll yes-and that, or maybe give an example. It’s not uncommon in these types of projects: You start with some ideas or end goals in mind, and you’re smarter tomorrow than you were today. You rethink things or get new information. It’s not uncommon for things to start getting bolted on: ‘Let’s add some automation, let’s add Power BI, let’s add these things.’ Quite commonly, we have to be the person who says, ‘That’s too much, too soon. That’s a day-two thing.’

[25:21] Greg Gorman: Or this happens, it’s happening right now one of my projects, someone says, ‘Why don’t we go ahead and add that new payroll system? It’s not that big a deal; it’s just another software.’

[25:33] Jeff Robertson: Right. Yeah.

[25:35] Greg Gorman: Let me raise my hand and say, ‘You know what? Let’s talk about how detrimental that would be to the overall schedule.’

[25:42] Jeff Robertson: Yeah, exactly.

[25:44] Greg Gorman: We bring reality back to the thing. That’s why I say we’re not a yes man, because there are times when we have to say, ‘That’s not the best thing for the project.’

[25:53] Jeff Robertson: It happens a lot.

[25:54] Greg Gorman: I think it happens a lot.

[25:56] Adam Cooper: All right. I’ve got a list of questions we’ve collected over the last, call it six months, from calls we’ve taken. I thought I’d throw a few of these out and throw you some softballs. The first one we get is: ‘Our implementation has already started. Is it too late to get a PMO involved?’ My typical answer is no, because I just want to sell work. But also, no, it’s not.

[26:21] Jeff Robertson: Yeah, my instinct is probably not.

[26:25] Adam Cooper: There’s a question: How far are we to LA?

[26:26] Jeff Robertson: There’s a ‘depends’ in there. How far along are you? Yeah, how far are we?

[26:30] Greg Gorman: If you’re in Las Vegas, it’s maybe,

[26:32] Jeff Robertson: yeah, it’s already started and we’re pulling into LA now. We’re in Chula Vista.

[26:39] Greg Gorman: Very specific. Wow. I went with Vegas because I thought it was an easier landmark. You know what I would say is I think we’re maybe treating a PMO like it’s this hard-and-fast thing. I don’t think there are rules. If you feel like you need a PMO because you’ve gotten halfway through your implementation and it’s not going well, then we, or anybody who’s a PMO, could offer assistance. So I think that’s how I would think about it.

[27:17] Adam Cooper: I would say if you’re bringing somebody in midstream, typically you’re going to have to pause the project. You’re going to have to pause everything to let them get up to speed, understand where you’re at in the process, and figure out why it’s not going well. Hopefully you’re calling us before major damage has been done, like you’ve spent a million dollars and gotten zero.

[27:36] Jeff Robertson: Commonly referred to as, ‘We fucked this up. Can you unfuck it?’

[27:38] Adam Cooper: Yes.

[27:39] Greg Gorman: Well, that’s what I was going to say. If you call a PMO after a project has started, you’d only consider a PMO if things aren’t going well, or that’s the assumption. So then I think it would be a good idea, because maybe that PMO can help you stop, pause, get assessed, understand what’s happening, and put the project back on track, as opposed to letting it continue badly for the second half of the trip.

[28:09] Adam Cooper: This is why it’s such a natural extension of our consulting services. We’re often brought in when things are not going well and people recognize they need an outside perspective to help fix something, whether it’s software, process, workflow, personnel, or something in the business that’s gone sideways. The PMO became a natural extension for us because they were saying, ‘Why don’t we just get you involved up front, and you can ride with us through this whole change process and make sure it goes smoothly?’ And that’s how we got into doing PMO work.

[28:41] Jeff Robertson: Yeah.

[28:42] Adam Cooper: So the next one, I love this one: Should we fix our processes first, or will the new software fix them? Or, said another way, should we wait till we have the new software and then change our processes?

[28:54] Greg Gorman: Note to self: we should probably make that a completely separate podcast.

[28:57] Jeff Robertson: I would agree.

[28:58] Greg Gorman: That’s such a great topic. Should we fix our process now, or should we go into new software and fix them later? That’s kind of the title.

[29:07] Adam Cooper: Isn’t that great? We could do a half hour on that.

[29:10] Greg Gorman: Yeah, I think we can, because I just had a conversation with someone about that. Our scope was not process, but obviously they need new processes. It’s a software project. We told them that. They asked us, ‘Well, it’s going to fundamentally change the way you do things. How do we write that down?’ Well, let me tell you how. I think that’s a whole topic people really care about.

[29:33] Adam Cooper: The short answer is: it depends. How badly broken are your processes now? Can you live with them while you go through a software migration and then redesign them on the other side? Or is there value in getting things cleaned up now before you go through a big change process? It kind of depends.

[29:48] Jeff Robertson: Yeah, I think that’s a very good point. We have a client with a major software project across multiple companies. We identified a common thing: let’s get project management and job costing tuned up while we get the ERP installed. That solved that problem, so it was a little bit of both. Let’s fix some processes, not all of them, but some very specific things, so it can work.

[30:18] Adam Cooper: I’ve got one right now where we’re building custom middleware to reconnect Procore and multiple other systems. There’s a Procore process that needs to be changed, but Procore is functional for them. They opted to say, ‘Let’s not change how we use Procore now, just to change it again in four months when the middleware is done. We’ll do it all at once after we have new middleware that’s making it function differently.’

[30:42] Jeff Robertson: I would like to add that we do this enough that, if there are some processes we could update today to get things tuned up, we don’t have to wait. We can do that because we know what the end looks like. We can set those processes up today to work with what’s going to happen in the future. We can predict the future in that regard.

[31:02] Adam Cooper: How many of our people’s hours do we need for an implementation?

[31:07] Jeff Robertson: More than you think.

[31:09] Greg Gorman: That’s the best short answer yet.

[31:11] Jeff Robertson: Yeah, more than you think.

[31:13] Adam Cooper: The PMO can take a lot of the lift off those hours if they’re a good PMO, so your people are doing focused work and not all of the work.

[31:23] Greg Gorman: Well, let’s not make every answer ‘it depends,’ but in this one, what depends is: What software is it?

[31:31] Adam Cooper: What are you changing?

[31:34] Greg Gorman: Going from one project management software to another is a lot more straightforward than bringing in a big ERP when you have no ERP, or bringing payroll in at the same time as a new ERP. I think it depends on the complexity of the project. And the answer is more than you think.

[31:55] Adam Cooper: Yeah. I mean, I would say the most successful projects I’ve done helping clients change ERP systems take a lot more hours than they think. Usually it’s more in the beginning, light in the middle, and then there’s a ton of hours at the end. It’s like a part-time job.

[32:15] Jeff Robertson: Well, yeah.

[32:16] Adam Cooper: That’s when they’re actually learning how to use it. There are different flavors of hours I’ve found. One is straight-up learning, the learning curve. People are so used to how they’ve been doing it; they don’t know how Spectrum or Acumatica works. It doesn’t matter which. They don’t understand the logic of it. They’re still learning the,

[32:34] Adam Cooper: They came from QuickBooks?

[32:36] Jeff Robertson: Acumatica-speak. That’s what I mean. Or Spectrum-speak. Spectrum calls them phase codes instead of cost codes, that type of thing. It doesn’t sound like a big deal on the surface, but it’s deeper than that. There’s a learning curve that just takes time, and you can’t slow the project down for that. Then when you get to, ‘Okay, now it’s time to bring all the legacy data in and test it and check it,’ you’re doing conference room pilots or whatnot. That’s busy, busy, busy user acceptance testing. Yeah, yeah.

[33:11] Greg Gorman: I will say there is a bright side to that question. We’d like to be positive when we can. There’s a silver lining: If the client is concerned about how much time it takes, by working with a PMO, you can talk it through before you start. You can get some really good ideas. With an experienced PMO, we can make sure it’s more than you think, so you’re prepared for it and can plan for it.

[33:40] Jeff Robertson: Manage expectations,

[33:41] Greg Gorman: maybe bring on some temporary help. That’s what one of our clients is doing. We advise that just about every time. But if you don’t ask the question and think about it, and you’re surprised halfway through, that’s chaotic.

[33:57] Adam Cooper: So, a couple other ones. These are some easy ones. Somebody asked, ‘Who makes the final call, the PMO or you?’

[34:02] Jeff Robertson: We kind of already answered that one. We’re here to advise and recommend. A PMO is, but ultimately it is the end user’s choice when they have choices to make. They own the decisions. It’s their business, right?

[34:14] Greg Gorman: Yeah. I say the person signing the contract for that software is the person who ultimately has to decide how and when and what they’re going to do with it.

[34:25] Adam Cooper: Another one: ‘We just acquired a company. How do we get everyone on one system?’ We do a lot of this.

[34:34] Jeff Robertson: What I would say first is, how do you even know which system is the right system?

[34:39] Greg Gorman: Yeah. I was just going to say you have to establish a baseline, and there’s usually some type of an evaluation process. We help clients go through it to determine: Do they have a good software stack right now? If they have different stacks in different companies, which one, if any of them, should be kept? What do we standardize on?

[34:54] Jeff Robertson: What are we going to make the source of truth?

[34:57] Greg Gorman: Correct. There’s just so much complexity to that. I think that’s a whole other podcast episode.

[35:02] Greg Gorman: It is. And that’s a point-of-view question, because that’s a point of view from someone who looks to be doing that work. It’s probably different if you’re the company being put onto that software versus the person who wants you to go onto a new software, right?

[35:17] Jeff Robertson: But in that case, from our perspective, that’s exactly why it’s valuable to hire us as the PMO, because we come with an outside perspective. We understand best practices. We look across those one, two, three, four, five companies they’re going to acquire and compare them all to our understanding of best practice. We determine, well, these guys operate better in these categories; those guys operate better in different categories. We can merge those together and say best practice, best practice, best practice, best practice. And if there’s a whole other third thing that nobody’s doing, we can bring all those together and build a cohesive system.

[35:53] Greg Gorman: And you just reminded me of something. Sometimes a PMO project can be very complex, and it can be something new that maybe has never been done before in that way. But what a PMO can do is bring experience from previous projects. Sometimes the client has never done this at all. Not just from that software to this software, but they’ve never done a big engagement like this. They’ve never done a big change.

[36:23] Jeff Robertson: Change, right.

[36:24] Greg Gorman: But an experienced PMO has. So there’s a level of experience that comes with that, which will hopefully avoid what you just said.

[36:34] Jeff Robertson: Right.

[36:35] Adam Cooper: All right. Another one: ‘How do you prove a PMO is working when you can’t see any progress?’ I think we talked about this earlier with artifacts.

[36:44] Greg Gorman: Yeah, we set up artifacts and milestones. We should pause every now and then and check the road signs.

[36:51] Jeff Robertson: Are we where we thought we were going to be against the schedule that we built?

[36:54] Adam Cooper: The schedule: are we on time? Are we where we thought we were going to be? Are we in St. Louis? Are we actually in St. Louis?

[37:01] Adam Cooper: The other thing that we do with our PMO engagements is we require the client to set up some type of an executive committee or a steering committee, and then we’re meeting with them on a regular cadence, typically every other week, and we’re giving a progress report. We’re addressing open issues. We’re getting things resolved. We’re holding everybody accountable. The software companies are involved in those meetings, as well as the steering committee from the end users. And we’re making progress because we’re tracking it. We’re talking about the progress that’s being made. So I think if you’re not measuring what the PMO is doing, either they’re not a very good PMO, because they’re not communicating with you, or you’ve taken your hands off the steering wheel and you’re trusting somebody else to run this project for you instead of with you.

[37:47] Greg Gorman: We’re doing that right now on my PMO project. We built an entire document. It’s a schedule, but it’s a lot more than that. It’s the steps by phase. It’s an estimated start date. It’s an estimated end date. And then we created a validated column: Has what’s been done been validated? You could literally look at this document and say yes, yes, yes, yes, no. Okay, here’s where we are. That’s where we are. So it’s a tangible document that people can follow, and they are following it, and it probably does make them feel better knowing that things are happening.

[38:23] Adam Cooper: I’m not sure who wrote this one: ‘PMO: value creator or bureaucratic overhead?’

[38:28] Greg Gorman: We could guess who wrote that.

[38:30] Adam Cooper: I would say that depends on the PMO you’ve hired, but if they’re doing any of the things that we’ve talked about today, they’re a value creator.

[38:37] Jeff Robertson: Yeah, I think it’s worth saying they’re absolutely a value. I would argue that hiring a PMO is not a luxury, which was kind of, I think, the baseline of that question: Is this something I really absolutely need or not? A good PMO is actually, of course, there’s some bureaucracy involved with it. We’ve talked about some things: we have risk registers and logs and schedules. That’s bureaucratic, but they’re good tools.

[39:01] Adam Cooper: They’re not that different than what you would use to build a construction project.

[39:04] Jeff Robertson: Oh, no, they’re not at all. My point being, the supposition in that is that bureaucratic means it’s not necessary.

[39:14] Adam Cooper: Frivolous.

[39:15] Jeff Robertson: Frivolous, right? And I would argue no. I think it’s not a luxury. It’s something that you probably really ought to consider seriously.

[39:23] Greg Gorman: Unless you have the in-house capability to do it.

[39:26] Adam Cooper: But the other thing is, that question doesn’t define value. You know what’s really interesting to me is that we get this question: Are we too small to have a PMO? Can we afford a PMO? Do we need a PMO if it’s just one software that we’re changing? And what occurs to me is, if you’re a small company, you probably need a PMO because you don’t have the bandwidth to manage this on your own, and you don’t have the expertise to manage this on your own. But enterprise-level companies hire PMOs all the time for the same reasons. Their business is so big and so complex. They need one person watching it all, shepherding it all. They want to have a steering committee that can answer questions and make good decisions, but they want to outsource the day-to-day running of this project because they are also busy. Even though they have the resources, they don’t want to dedicate them to this effort. They see the value in hiring a PMO so their people can stay focused on revenue-generating activities.

[40:27] Adam Cooper: So, one that we get sometimes, where people maybe need a little clarity: What’s the difference between a PMO and a project manager? I like to say a project manager is somebody you hire to do a job at your company, typically to run projects. Whereas a PMO is an outside party that you hire to oversee an internal change management project. Typically, as I said, software is where we’d see a PMO most often.

[40:52] Greg Gorman: I’ve actually heard this question before, and one of the ways that I defined it is a project manager is a person. It’s a role. It’s a job. A PMO has more infrastructure around it. It’s more of a system, with maybe more than one person. It doesn’t have to be three to five on a PMO project, right? It’s a team, and there are management skills away from just the job. I think a PMO can have a PM inside of it.

[41:19] Adam Cooper: Sure. Absolutely.

[41:21] Greg Gorman: But that’s kind of the definition. One is kind of small, and one’s a little broader.

[41:26] Jeff Robertson: Yeah, I think the change management piece is important, because a project manager is somebody who works with the superintendent, and they build the building or whatever it is you’re building. Whereas the PMO is explicitly designed, with systems and infrastructure, and it could be multiple people, to elicit change throughout an organization. So it’s not just, ‘Hey, let’s install some software.’ It’s installing, implementing, and standing up a piece of software, maybe two or three, and making the changes to the processes as you’re flying the plane in many cases. In all cases, actually.

[42:02] Adam Cooper: I think it’s helpful to also say that PMO is one way to describe this type of engagement. It’s also sometimes called software implementation advisory.

[42:14] Greg Gorman: Sure.

[42:14] Adam Cooper: Or change management advisory, something like that, or technology change advisory, or oversight of technology change management. There are some interchangeable words there. PMO is just the current terminology that’s becoming widespread, so that’s why we use it in the title of this one.

[42:33] Jeff Robertson: Right.

[42:34] Adam Cooper: All right. Hopefully that was very informative and educational for our listeners and viewers.

[42:39] Greg Gorman: That’s a lot of fun talking about that today. I know we’re all doing some PMO projects.

[42:44] Adam Cooper: So we’ll continue to report back with findings from the field, and we’ll keep you updated on any new developments in the world of PMO as they show up.