26.08.15 Eliminating PMO Bloat with Russell Miller (48)
Chris: [00:00:00] In this episode of Great Practices, I'm joined by Russell Miller, a professional scrum trainer, product and program manager. Listen in as Russell discusses some of the reasons why PMOs become bloated and lose sight of the original reason why they are created, and even more importantly, what can be done to bring them back to creating value.
Plus, you'll find out why nothing fails like success. The importance of accountability for A PMO and the lesson A PMO can learn from Sully Sullenberger and the miracle on the Hudson.
[00:01:00] We'd like to welcome you to this episode of great practices, and today we're gonna be digging into something that happens more often than we'd like PMOs that start out helpful and efficient, but slowly become bloated, slow, and frustrating for everyone involved.
You know, it's kind of what happens when you get a new phone at first. It's fast, it's clean, and everything just works. But give it a year or two and it's loaded with old apps, settings you don't remember changing and notifications you don't need. Suddenly it's not helping you anymore. It's actually getting in the way.
PMOs can unfortunately go down the same routes. They start with the best of intentions, streamlining work, improving processes, uh, giving visibility. But over time things pile on. There's extra forms, there's new steps, there's layers of approvals, all in response to problems that may not even exist anymore.[00:02:00]
So our guest today, Russell Miller, knows how to fix that. Russell's been an agile coach, product owner, program manager, IT consultant, scrum.org, trainer, you name it, he's seen where PMOs can go wrong and how to bring them back on track. Russell, welcome to great practices.
Russell: It's my pleasure to be here. Thanks for having me on.
Chris: Yeah, we're absolutely looking forward to this conversation today, Russell. So, first of all, let's just start off. Can you tell us just a little bit about yourself and what you do?
Russell: Sure. My training is mechanical engineering. I spent years in. Aerospace design. Then moved to a career in business analysis and thought I'd make that my, my lifelong career. But I realized I'd had less influence there. Moved on to being a project manager. Got training from Ken Schwaber and Jeff Sole, and the guys who created Scrum.
Uh, since then I've been working as a program manager, as a trainer, and as an IT [00:03:00] consultant. .
Chris: Okay, excellent. So you have seen, a lot of what works and what doesn't work over your career then, is what I'm assuming here. So let's first of all just kind of start with, the hope or the aspiration of A PMO. What is the hope that leaders have for all PMOs when they say, Hey, you know what, we need to get a PMO.
Up and running. What? What is their hope?
Russell: Yeah, I think they have some, Reasonable, but often, focuses that that don't necessarily help the execution of programs. And they want visibility and they want to know if there are risks and they want to know if you're gonna need more money. And, those things meet their needs. Oftentimes, they're not geared toward actually helping.
Program success, Chris.
Chris: Interesting. So their vision or their. Desires for what? That visibility, highlighting the [00:04:00] risks, kind of tracking the budgets, understanding where that, where that falls into the expense or the cost of those programs.
So, Russell, in your experience then, what are some of the, problems or the, the issues or situations that PMOs fall prey to as they get older?
Russell: what they often fall prey to is trying to meet the needs of those they work for without any accountability for the success of programs or projects or system development.
Chris: All right. So that's really kind of almost counterintuitive or almost working against itself, I guess, as far as what they would really want this PMO to be up and running to accomplish. Um, why do you feel this occurs?
Russell: it occurs for a couple of reasons. One of the reasons is the, folks in the PMO aren't aware of the burdens or they feel like the burdens are necessary because those are the things that the leaders want, and there's no accountability for whether the program's, projects, or system developments succeed or fail.
So there's no good [00:05:00] measure for the weight that the inspections or forms are putting on these developers or program managers or Scrum masters, et cetera.
Chris: And you know what, I think I wanna go back to that because you, you've used that word burdens a couple of times here. So what, what are. Some examples of those burdens that kind of surface within A PMO.
Russell: sometimes, in my experience there are, are forms that you're, quote, required to fill out, unquote, without a clear understanding of who the customer is for the form. I mean, the internal customer.
Chris: Yeah.
Russell: And some of these things are born from some past circumstance or from, um, if I can be quite candid, some new person comes along and they wanna make some changes, uh, to show that they're doing something unique.
And whether that's helpful or not, is, up for debate. So there's forms and then [00:06:00] there's some of the check-ins and requirements. That PMOs put on people that not only don't add value, but they actually slow down and put a risk on the successive programs.
Chris: you got any examples of that that would just really put a program at risk?
Russell: definitely I'll try to be succinct. When I learned about, lightweight adaptive development, we wanted to use those programs on a project, a new PMO director, didn't want those activities, didn't have expertise in those activities. And you said, what's the big deal? The big deal is, seven people worked for two years in for a software development effort and didn't release a single line of code. They were using the past practices. We used the new methods, and we released a first line of code in four weeks, maybe six weeks, and then every three weeks after that.
Chris: So it is interesting, you know, how these things will just kind of [00:07:00] stack up or pile up, you know, over time. And like you're saying, it's somebody. Somebody that's wanting to make their mark, you know, we're doing this, we're not doing this, we need this, we don't need this. And it just ends up to be that administrative burden and that weight, you know, that really just that could cripple, cripple A PMO and it's customers basically.
So let's talk about that a little bit. What. What impact does such a heavy administrative burden have on projects or customers or the project managers that are running them? What does that actually look like?
Russell: Well, in short, I've seen managers try to meet all the needs of A PMO and their program has failed. wasn't coincidental. It was the fact that the amount of effort required to satisfy the PMO and the amount of effort required to develop a solution where it was just too much for a program manager to keep up with. So [00:08:00] that's a challenge and I think that it's also true. That, nothing fails like success. So if you checked for something that was a problem in the past and it's not a problem, now you think victory. But once you add, to that, you know, seven other, or eight other or nine other things to check for and reviews for those things, then that's, a challenge for leaders and developers. Product owners, product managers, scrum Masters to keep up with
Chris: so that's interesting. Russell, what did you say? You said there's nothing that fails, like success. What, what did you mean by that?
Russell: So if you have a, um, a, a sports team, I think of football as an example, and you have a couple of plays that work well, but over time people get used to those plays or come up with a defense that stops those plays. Imagine before you were having great success, you know, winning your [00:09:00] conference, maybe winning national championships.
But if you don't have, any other vehicle for your success than what's worked well in the past. not to be trite, but you can look at Kodak selling all the film. if you don't, look at what the future holds, then you can keep doing this. Awesome, great thing. And not get the same results you got in the past because look at the great success we had in the past, but that doesn't guarantee future performance.
Chris: do you have any more examples? You know, I know you talked about Co Kodak as an example, but do you have any other, examples of how bad this could get, you know, within A PMO or within an organization that's heavily burdened by A PMO?
Russell: Well, we can think of some essential, solution that doesn't get delivered. We have customers wait literally three years to get something they could desperately need. that's a significant challenge and it's a different [00:10:00] challenge based on how badly the solution is is needed.
So that's an example. And um, uh, candidly there are some things. That the, leader of a program or project or systems development effort needs to do in that you, you can't do everything. And when I say that, everybody says, yeah, can't do everything, but we need to choose the things that we get help with from our leaders.
Chris: Yeah, and you know, it's like, to your point, there's only so many calories you can expend, and so where do you expend those calories? Do you expend it on actually moving the program forward and the projects forward and, and getting it done so that they can be delivered and deliver value? Or are you expending those calories on, you know, just the paperwork and the administrivia and that's just, that's the wrong place to expend those calories for sure.
Russell: Having led difficult programs, there's a, so your example's great. And another [00:11:00] one is you have a limited amount of emotional energy
Chris: interesting.
Russell: for a very complicated, in my experience, software development effort. And you can't expend that all and still have the relations you need between. People on the team that's required to achieve success.
Chris: Very impactful for sure. Now, fortunately. What you've seen that this is, this is recoverable. Right. You know, we may find ourselves in this situation where it's become bloated and overwhelming and heavy. Um, but you've got a great example that you used to help us identify what actually needs to be done from within A PMO.
And that's the example of, The miracle on the Hudson was Soly Solen Berger. Can you tell us, tell us about that.
Russell: Yeah. folks can probably see some good interviews of, Sully on, um, on the internet, but, both engines were out on his plane, commercial aircraft and the plane was full of people. [00:12:00] And he couldn't get to a runway, a quick summary, and so he ended up landing the plane on the Hudson River and you said, wow, that's amazing.
Well, it is amazing. Consider no one lost their life and the plane landed successfully. But there was a checklist of, I think it was three pages, and you can look and see if I'm right or wrong. They got partway down the first page of things to do if you have to land. Do a waterborne landing, but, there was not sufficient time because of their altitude to go through all those things.
So Sullenberger, did the things that were necessary and other things simply couldn't be done. There was nobody call and say, I can't do these things. It was, I have to do what I need to do to make the plane land. And, those things might have been great based on your altitude. But it would be great candidly to have a checklist based on your altitude, which is, these are the things you need [00:13:00] to check for this altitude.
Now, I'm not saying PMO does this, but not that they should do this, but you can't get through it all, and you have to make choices about what things you can do, what things you can't do.
Chris: Yeah. And so, you know, I think if, if you were just to kind of frame that, then, you know, I mean, I think, I think A PMO could look at a, a reality check and just say like, Hey, if we had to finish this project or this program in the next two minutes, let's just say, you know, or the next week or the next month, right.
Whatever that timeframe is. What is it that you could see that they could shed and that they could get rid of and just say, we just can't do that, and what should they focus on? So what, what would that very tight list look like?
Russell: That, that's a great question. If I may quickly introduce one other thing is that often PMOs aren't accountable for project success. So if somebody fails and doesn't deliver PMO person's not yelled at, and they might not get a lower raise [00:14:00] and they might not get, they, what is it, they might not not get promoted until it's a double negative. So we need some accountability. and without that accountability, I don't know if I'm gonna be blunt. I don't know why you care. Like nobody's gonna hold me accountable. I'll just lay all this stuff on, on Bob and I'll be rewarded for holding them to the standard. So what I would say is, um, what does the program manager or project manager, solution developer, product owner, et cetera, what do they need to succeed? And I've never heard that from the PMOs that I've worked with. In other words, go to the person who actually is trying to get it done and say, what can we do to help you?
Chris: Interesting. So just really kinda ask them what they need
Russell: Because they're very keen on what they think they need. It may not be the right thing, but at least that's better than them. trying to postulate what would be, what would be best.
Chris: So in your experience, what are some of [00:15:00] the, I don't know, maybe the common things that would be really the lowest common denominator that everybody would need in order to be successful?
Russell: I would care about, when we look at program management, surveys or, quarterly or monthly reports, I care that we know in advance the things that might go wrong.
Chris: Okay.
Russell: So I joke with people and say, those scorecards are green, green, green, green, red. 'cause nobody wants to get yelled at for having a yellow item.
Um, and oftentimes we don't have a good reconciliation plan. In other words, great. I go to the PMO and say, this is yellow, and they don't have a good solution for me. They can tell somebody else, but they're not equipped with often with extra budget or. Ability to change schedules or ability to handle risks.
They're more of a, don't wanna even say supervisory, but they're [00:16:00] almost observers as opposed to helping programs succeed.
Chris: Got it. So basically you're saying identifying risk, being forthright and forthcoming even about obviously potential risk, which is the nature of risk. Right. Is there anything else, again, from that lowest common denominator that would be essential for, you know, A PMO to offer or deliver?
Russell: Yeah, I, what I care about is, is, is very, I think of it as so sophisticated because the problem is often. Probably 90% of the time, and I'm making the number up, but is the people. And so I'd care about do we have the right people in the program? Number of people is something the program manager can argue for, but I wanna know, are the people working well together?
And if they're not, that needs to be fixed. But the first thing that needs to be fixed is we gotta have a team that knows how to play. And if you're an NBA fan, you can see how that works.
Chris: Excellent. So risks [00:17:00] people, you know, and I'm assuming there's gonna be some element of, you know, probably timing and schedule and budget. You know, maybe put those couple pieces in there and you've got a nice set right, of what A PMO could deliver, that if you had to deliver a project in three or four weeks, or you just had a very limited time, you could pull it off.
Russell: That's true, and I will emphasize or begin to emphasize that the schedule's. Critical and the budget's critical and the risks are critical. And the quality's, these are critical things.
Chris: Yes.
Russell: But a bigger question is, the phone that we have, was it over budget when it was developed? I don't know. Was it late when it was developed?
I don't know. What quality risks did they have? I don't know. And so your customers care that they get what they, what they need. And if you are having a challenge in one of these other areas. That's where the leaders can decide what to do about those challenges. What are you saying, Russell? I'm saying [00:18:00] that, um, we don't ever wanna be late, but programs get delivered late.
Some of them do, and we don't wanna run over budgets, but some programs run over budget. And so the idea is we can't just take the lash to people when they're over budget. I care about are you going to get the work? Done in a way that satisfies both the customers and your forget budget and schedule and quality and et cetera.
Just for a moment, are we gonna have a solution that people care about?
Chris: I think that comes down to, you know, and I, I'm a huge advocate of this, is that there needs to be some benefit realization tracking, you know, that that would be an amazing piece if A PMO could say, this is the value that has been delivered from this solution. That's a big.
You know, 'cause that's ultimately, it's like, why did we do this? We did this 'cause we were gonna get this XR, you know, this ROI on this, and now we can prove out that that's happened over this period of time. You know, we've made this investment and these are the dollars that's coming back. So, [00:19:00] so to your point, yeah, if it's a little bit late, if it's a little bit behind, if it's a little over budget, all of that could kind of, people will forget about that if this is actually doing what it was intended to do.
Russell: And again, just, you know, I think you would agree, we don't ever wanna be over budget. We don't ever wanna be behind schedule, and I train people on how to not be over budget and not be a behind schedule and not have quality lapses and not, and not not deliver the requirements that are necessary. So that's where I can help people is.
Don't be over budget and don't be late and don't have quality challenges. And then you can talk with leaders about the things you need candidly, to go faster
and to get greater quality. Because you know, if you're late, I'm gonna beat you up for being late until you're not late anymore and often you can't recover from being late, so you just beat up all the time for being late.
Chris: Well, Russell, we definitely appreciate you being on today, sharing your insights with us. If there's, if there's one great practice that you [00:20:00] wanted our listeners to remember, what would it be?
Russell: I, I think one of the great practices would be, make sure that the PMO representatives have some kind of a, a way to get rewarded or maybe challenged or both. If the programs don't succeed,
Chris: You've used the word many times throughout our discussion, and I'm hearing accountability. That's that's really what this is coming to. Right. Have them plugged into the success or the failure of
Russell: and if not, what do you care? Right. Sorry Chris, it failed.
I'm gonna get my raise and I'm gonna get promoted and I'm gonna get the new position that I want. And if, if you're not geared up toward program success. Candidly, if I do nothing, how do I look? PMO great. Everything's green. obviously not the deliverable, but the schedule's, schedule's green but we need to hold them [00:21:00] accountable.
And if not, then I don't see a, if you're not accountable, why would I reduce the number of things I'm asking of somebody
Chris: Yeah, yeah. I checked off all these, I checked off all these boxes, I ran it through all these processes. I did all of these forms, you know, but that had nothing to do with the success of the project
Russell: If I'm a leader, God, I don't beat you up, you're in the PMO 'cause I'm late. I beat up the program manager or if I'm over budget. So you have to hold, have some kind of accountability. And I think this is the mark of, if I can say so good leadership and good training of leaders. Not that they do this automatically, but oftentimes we leave it to the PMO.
They don't have the right, I guess maybe reward system or so that they know that they care whether things succeed or not. They care. Don't get me wrong. But if you can get your raise, get promoted, and get credit with the leaders for, for beating on a program manager, then you're just gonna beat on 'em as much as you can.
Chris: Well, we appreciate your, , your [00:22:00] insights and giving us plenty to think about as far as how, how PMOs are structured then. So Rosa, what's the best way, uh, for people to reach out to you or to contact you if they wanna discuss this further or have any other questions or continue on this conversation?
Russell: Sure. I have made a living for a while helping people understand lightweight adaptive development. but my handle [email protected]. Uh, I say handle, I mean my email address, and so you can reach me there. you don't have to do Scrum.
I really want leaders to understand how they can get things delivered on time, how they can get, uh, risks reduced, how they can get the quality they need, and that's not. Necessarily about Scrum scrums. Just help people, uh, iteratively and incrementally examine their, their progress over time. So don't be cast away by this phrase, scrum.
Simple.
Chris: Got it. Or they could even reach out to you on LinkedIn. Right. I mean, you're all over [00:23:00] LinkedIn too, so just Russell Miller. And that'll do the, that'll do the trick.
Russell: Yes.
Chris: All right. Excellent. Well thanks for being on today, Russell, and, uh, we'll look forward to talking to you soon.
Russell: I look forward to that. Thank you, Chris, for having me on.
Chris: That was another great episode of great practices, and we certainly do appreciate Russell joining us today. What were some of the great practices and insights that came from today's episode? Well, I like the fact that Russell started out with the hope that most leaders have when they start up a PMO.
Is to have visibility into what is going on in the organization, being able to identify and get ahead of risks. Really having that overarching view of everything that is going on in the enterprise. But what can happen over time he brought out is the fact that these PMOs can turn into a lot of administrative.
Burden and weight that ultimately [00:24:00] slows things down. Some of the examples he gave, maybe forms that need to be filled out without a clear understanding of who the form is, even for, you know, maybe it was something that was done or was born out of past circumstances or past problems, but it's not even needed anymore.
And yet here we are. We're still requiring it. Or I like the fact he brought out, you know, a new person comes in and they're looking to make a change and show the value that they're bringing and how unique that they are. So they bring in additional requirements with them to do something and it may not even be important or matter Or he said there may be check-ins or requirements that just don't add value at all, and even. Put a program at risk so much at risk. He gave that example of, of seven people that were working on a project for two years and they didn't even release a single line of code just checking off all of these boxes and [00:25:00] crossing all these T's and dotting the i's and all these forms.
It just really has a tendency to put that administrative burden on A PMO and really defeat the purpose of what was originally set up for. Which took us into that concept that he said that nothing fails like success. You know, he gave the sports example of football. Uh, you know, you've got a couple of plays that work very well, so you just keep doing those plays over and over and over and over again.
Well, after a while, people are gonna get used to them. Defense is going to stop them. And before these things, were helping you win. Now. You're gonna find yourself losing because you haven't changed or kept up with the times and what's important and what needs to be done and what really the PMO was set up for.
Originally, I thought the point of the miracle on the Hudson really drove it home. here is an emergency dire situation. This [00:26:00] plane is going down now, if you went by the book. Soly Sullenberger had a checklist of three pages or something like that, that he would need to go down. Now he made it partway down that first page to see what you have to do to land in water.
And you know what? He threw that paperwork out because there wasn't sufficient time. He did the things that were necessary. He realized other things couldn't be done in that very short period of time, but he did what exactly was necessary and exactly what was needed in order to land. Plane, so couldn't get through.
It all had to make choices, and that's the same thing, to be honest with you, is gonna happen in A PMO. What if you found yourself in a position where somebody said, you know this project that was gonna take three or four months, we gotta get it done in one month now, or one and a half months? If you were to look into that.
Plan and look into all of the steps and the processes. Now, you can't get rid of everything. There are certain checkpoints [00:27:00] and, checks and balances that are in place for a legitimate reason. Like you can't just blow past security and that kind of stuff. But there could be some things in there.
That could absolutely be removed because it's no longer necessary. Remove the bloat. Focus on what is important, which is delivering that program so that people could start using it and getting value out of it. Which is really what he brought us to. The fact that I like that phone example. You know? Do we know if that phone's schedule was right on track?
Do we know if the phone's budget was right on track or risk or quality or all those things were right on online? No, probably not. When we look at that phone in our hand, but what we are. Aware of is the fact that this phone does exactly what we needed to do and we're all willing to pay big dollars to have this device.
These things are important, but there's going to be times when the budget is going to be blown [00:28:00] or the schedule is going to be a little bit late, but the ultimate deliverable is going to delight customers, and that's really what we want to keep in mind when we go through that. So additionally, I love the fact that, you know, really kind of ask him about, well, what, what are the things that A PMO really should be focusing on?
These are the two things that he brought up. First of all, know in advance the things that might go wrong. we'll have a tendency as A PMO. It's like, oh, it's green, it's green, it's green, it's green, and then all of a sudden it's red and everything's on fire. There was no yellow, there was no couple weeks of yellow as far as status updates and reports.
All of a sudden it goes from green to red. And that's not a good way to escalate something because at that point it's too late. so you wanna make sure that you're knowing in advance of things that might go wrong. And this was the other point that I was really kind of surprised a little bit to hear, [00:29:00] but focus on people.
Do we have the right people on the project? I thought that was a great question. Do they have the right skill sets and are they working well together? So it wasn't like, oh, well you're gonna need to have 10 resources. But the question he's asking that he thinks A PMO brings value on is, do we have the right people on the project?
Do they have the right skillset, and are they working well together? Because at the end of the day. It's people that get the work done. And that's a great, uh, way that A PMO could then bring value by focusing on, on those couple of metrics.
What was the one great practice that he wrapped it up with? Make sure that PMO employees, representatives, people that are working with the PMO, have a way to get rewarded if the project goes well and challenged if programs don't succeed.
He was really zeroing in on the fact that [00:30:00] accountability is a big deal that needs to be in PMOs because. There's no skin in the game there. It's like, okay, yeah, you got all these forms complete and you got the questionnaires filled out. You went through all of these checkpoints. Um, but what is the saying?
It's like the, the operation was a success, but the patient died. So that's not the way we want our projects to be, and that's not the way we want our PMO to operate. So again, we'd like to thank Russell for being on great practices today. And do you have a great practice that you'd like to share? We'll go to the PMO leader.com, click on Resources, great Practices Podcast, and fill out the form at the bottom of the screen.
Someone will get in touch with you shortly. Also, be sure not to miss out on a single episode by subscribing to great practices on your favorite podcast platform. If you like what you hear, we've had some great guests on, we've got many more coming. Be sure to share this with your manager, colleagues and any others [00:31:00] you think would benefit.
So thanks again for listening to this episode of great practices and keep putting great practices into practice.
