EP83 Scope creep and what to do when it isn't optional!

Dante Healy [00:00:01]:

Hello, everyone. Welcome to Business Breaks. I'm Dante Healy and as always, I'm joined by John Byrne. So, John, today we're tackling something every PM has battle scars from, which is scope creep. And I wanted to start with this idea. I think personally we've been lied to about scope creep. We're told it's a failure of discipline, that if we just had better requirements or tighter governance, we could lock it down. But I don't think that's always true.

Dante Healy [00:00:28]:

And I'll be interested to get your thoughts because I think you may have a different opinion. But for me, the truth is, scope creep, I think, is pretty much inevitable in the fact that you're going to experience it. And it's not necessarily because you're bad at your job, but because sometimes we build things in a world of imperfect knowledge, hidden agendas, and sometimes constantly shifting realities. So the question is, how do you prevent scope creep? Or should we be asking what kind of scope creep are you managing? And which battles are worth fighting? Often you're not the one who's able to defend them. So today we're going to break down why scope creep tends to happen, who benefits from it and how to manage it strategically rather than just absorbing blow after blow until you burn out. So let's get into it. So I guess, John, to frame it up, when you set out your original project timeline, how much of it is based on actual technical understanding versus, I guess, political pressure to commit to a date by which you have a certain list of deliverables completed depends on the.

John Byrne [00:01:47]:

Project and who it is that's doing it. But, you know, initially for the plan, you need to get your, you know, figure out what your scope is and get that signed off by everybody, all the stakeholders who are involved in it. So basically the customers and also the supplier piece, you know, they need to be able to say that the scope is manageable. And once that's all agreed, then it kind of should be going into the business case, and that's owned by the sponsor, not by the project manager. So the business case then is where that's managed from afterwards. The scope creep then is when things change with what's going to be delivered. That can happen. And it can happen for various reasons.

John Byrne [00:02:37]:

It's how you, you as a project manager deals with it. Because there'd be two buckets of scope reading. I think, you know, there's lots of different types of scope creep, but they'll all fit into two buckets. There's the big, big changes to scope and they're not so bad actually because when it's a big enough change for scope, you're going to have to go back to the, to the business case. It's going to all have to be scoped out. It's going to have to be what's the extra cost? So it's, it's, it's rejigging the, the project plan and that's not so bad because it is making you think things through and justify it and it's making the sponsor make a decision because the sponsor owns the business case. So the sponsor then has to make a decision. Is it worth changing your business case for this or not? And if they, if the decision is made, yes, it is, then that's grand.

John Byrne [00:03:28]:

You've just done it. Little things. I'd say there is, you know, evaluating and see is it really worth expanding the scope of your current project or is what's being proposed, would that be better off being run as a separate project perhaps at the end to not over complicate things, you know, make it too complex. Because one of the biggest risks to any project is if it's way too complex, chances are more Gamora opportunities for the failure. So that's the thing. But the worst scope creep, I think, which is kind of where the project manager can be a little bit more guilty, is when it's small things just constantly being added. You're doing it as a favor to somebody a little big to get a little bit of political traction. They didn't get this bit.

John Byrne [00:04:11]:

So we give them that bit and it's done. We're out thinking things through. It's done. We're out actually changing the plan or the business case because it's always something that, that's only something small, only add a few hours on and it never does. And I think they're the, the killer pieces of, for a project is those smaller pieces of scope creep that just keep adding on, adding on and are always bigger than, than anybody guess. Because the people who are guessing are usually not the people who would know. They're people who want it, but not the people who know how much work is involved in doing it.

Dante Healy [00:04:44]:

Yeah, you commit the resources to something that you don't fully understand and you don't know how much effort it takes. And then when you think it's a smallish, a small thing, you bring it to the developer as a, oh, can you just add that piece? And they say actually that'll take you a month to two months. And you're thinking, oh no, I thought it was only a little bit of a five minute job or worse.

John Byrne [00:05:09]:

Again, the developer will, you know, especially if they're not a fixed price contract, if it's, if it's a time of materials, they'll oh yeah, yeah, yeah, that, that's a small job, that's a small job. And then suddenly much later you're still waiting for it to be done and it's holding up other aspects of the project. So you actually now can no longer deliver the scope that had been agreed because you're waiting for this to be done and it's holding up something. And, and that's usually what's on the project manager because oftentimes there the sponsor, you know is going by what the project manager said. It's usually small enough that it's kind of within the area of the project manager for decision making that initially it's estimated to be small enough but then it turns out to be much bigger. And I think that's where project manager need to not allow that to happen because that's on you. How do you stop that from happening? There's a thing between bureaucracy and good governance. And bureaucracy is not good governance, it's actually bad governance.

John Byrne [00:06:10]:

But in certain aspects I think a certain amount of bureaucracy is a good thing. And for change, I think going through the change management plan for scope is the only way to do it. To make there be hoops that have to be jumped through so that you can't just agree to something small. You actually have to do some work and make sure it is small before you agree to it.

Dante Healy [00:06:32]:

Yeah, I think there has to certainly be some level of discipline in the covenant and also communication. You have to manage expectations up and down. And also your responsibility as a project manager is to protect your team. They're your resources. If we go back to the basics, you've got triple constraint theory. You've got your time, you've got your cost and you've got your scope. And so if you want to defend your scope, you may end up playing around with time and cost. And that's the implication.

Dante Healy [00:07:05]:

Right. The more scope you add, either you're going to need to spend more to deliver that additional item on top of everything else, or you're going to have to stretch your time.

John Byrne [00:07:18]:

And that happens no matter what. I think where project managers with scope creep fall down is they think that's small enough that won't impact the other two, we can make it fit and that rarely ever.

Dante Healy [00:07:31]:

Even worse yet, you're arguing to say that actually the scope hasn't changed. This item was defined in some vague, vague sentence on your charter and you've just said, well this is what it meant. And then the developers, because they may be a third party vendor, they'll say, well actually that's not the specification work we signed off the requisition order for, so it's going to cost you extra.

John Byrne [00:08:00]:

And that's, you know, and that's oftentimes because the customer, so you're the project manager, you're dealing with a customer who's probably internal. Well, is internal to your organization, pure project management organization. So that's the functional people, whatever system it is that normally we're talking about system implementation. So whoever the functional users of that system is, they're the customer. Oftentimes it's them at the beginning that they just were being deliberately vague because they didn't know what they wanted. And that makes it very tough then to, to, you know, have their arguments. Like even when people are being vague at the beginning, I think you kind of need to get some kind of limitation, you know, even though it can't be specific about the detail that there needs to be an overall, a limitation on it. Okay, we can, we can get into the nitty gritty at the time when we've got a little bit more information, but here are the, the limitations of it.

John Byrne [00:08:59]:

We're not going above X. And then if they want to go above X, well at least you had that down as your, as your thing. So the developers say yeah, yeah, no problem up to X is, is part of the project but beyond that we have to charge more and the customer can't argue against that because they've agreed to it, they've signed off that, yeah, up to a certain point we can have what we want, we're in it. Or if we go above that. And now what X is, I suppose that depends on the project. You know, maybe it's, you can have what you want, but up to a limit of two weeks work, maybe you're not even going to define the scope, you're just going to tell them how long they can do for that particular piece and that can be tough. But you know, again though, even when that's happening, if I think you can't take the shortcut, you have to run through the whole change process for scope no matter how smart think it is.

Dante Healy [00:09:48]:

Yeah, everything needs to be signed off by someone who's qualified to estimate the effort and then you do a cost benefit analysis because at the end of the day your project will have a list of deliverables. And in my mind you split them between two groups, two buckets of priorities. One are the non negotiables and the other is the nice to haves. So you make sure you defend the non negotiables. And on the nice to haves there's some degree of discretion in terms of judgment on which order they're delivered in and what makes sense. But even then, if you're not a project manager will manage a project. If they're not technical in the area that they're or the domain in the project that they're managing, then they need to defer to someone who is the lead. Now it could be a business lead or a technical lead, depending on the nature of the project.

Dante Healy [00:10:43]:

But they need to defer. If they can't make the call, they need to defer to someone else who can make that judgment call. But then that comes back to communication.

John Byrne [00:10:53]:

Yeah, and again, you know that the project manager as well, those need to accept the fact that. And it's not just the project manager, project managers will tend to, some of them will think that they are the ultimate decision maker. Orders will realize that no, actually they don't own the business case. Sponsor owns the business case. That is one of the key elements of it. But the sponsor themselves just simply won't take ownership of it and it's left to the project manager. They have no choice but to, to manage it and that. But, but ultimately, yeah, the, the sponsor, even when it's small now if it's just a very small thing, you know, like it's, we went in and we knew we could either go X or Y and we just have to make the decision at time because they're both the same.

John Byrne [00:11:42]:

That, that's fine then. That's, that's, you know, when you get to that decision point, you just, you go with whichever one it is and they take the same amount of effort, the same amount of work. It's just a, you know, small configuration piece or whatever, that's fine. And those decisions, they're not really change management. There's just a decision point that you make your decision. But if somebody then decided actually we want Z instead and that's going to take, you know, it'll only take a day or two more work. And you know, as a project manager, you should not be tempted to just accept that you should know a day or two more work. I need to do a bit of research.

John Byrne [00:12:17]:

I need to make sure it's only going to take a day or two as well. And I Need to make sure that we have the capacity, we're in the project, that, that day or two extra here, even if that's what it turns out to be, doesn't have a knock on effect somewhere else in the project that I'm not seeing or for someone else's project. Because if you're running your project as part of a program, you know, your little changes might have a big impact on somebody else's project. So you do need to, you know, make sure all stakeholders are aware of small changes that haven't been already documented.

Dante Healy [00:12:49]:

And sometimes you do. In this regard, I do believe in defending a project because sometimes you do get these cases where another project is trying to survive, descoping their, their own original deliverables by passing them onto your project. You may be upstream or downstream and they may say, well, it makes more sense to give this work to you when really it should be with them. Usually the further upstream, it's probably that organization who should be dealing with it. But sometimes they run out of cash or they run out of expertise and they decide, well, let's just throw it down the, down the overall process or value chain. We say at that point you have to say, well yeah, we can take it on, but we need to get, we need to get that called out and, and we need sign off, we need alignment.

John Byrne [00:13:47]:

Yeah, I mean those types of things though, I wouldn't see them as a big problem because whenever that happens, you do have to completely reevaluate your business case and they have to make justification work. That's not something that ever really happens quietly that, that you've just been given a chunk more work to do from somebody else's project and nobody knows about it. It's a quiet decision between you and their project manager. I've never come across that happening. That would be incredibly unprofessional if it did because I've had it. You've had it, okay, where they force.

Dante Healy [00:14:19]:

It and the developer push back. The consultants, I won't say companies, but they were big boards and the consultants felt threatened because they were basically challenged with questions. It wasn't anything, should we say aggressive, but the guy who was pushing back was the development lead. He was very technical and he asked them, look, this is the reason why I don't think it sits with us going to create a huge amount of technical debt and it really sits with your area. And I know for a fact you should be able to do it quite easily. So please can you explain to me why you can't do it? And he made very. A senior manager who was clearly not technical appear very, should we say, incompetent. And that guy, threatened, took it to HR or the program manager and it became a HR issue because he said he felt threatened when really he was made to look stupid by being challenged with pushback.

John Byrne [00:15:23]:

But at least that went through the Program management office, you know, that nobody was taking that extra walk onto their project without a change.

Dante Healy [00:15:31]:

No, what went through the program management office was the fact that this senior consultant felt threatened.

John Byrne [00:15:37]:

That's a very unusual situation. I've never.

Dante Healy [00:15:41]:

I mean, yeah, yeah, these, these horror stories happen.

John Byrne [00:15:44]:

Any, any changes where something is getting switched from one project to another has all always that, that I've come across has always gone through the, the program management office and has always then led to the, the, the project getting the extra work, redoing its business case and, and redoing it to, to make sure that it makes sense. Some cases, yeah, it does make sense that, you know, but other cases it didn't. And we simply didn't take it on. The work didn't get done. It was as simple as that, that if the, if the project that was supposed to do it was no longer able to deliver, it was kind of just themed. Well, you know, it wasn't actually that important in any way in the grand scheme of things. So it just didn't get delivered. But we didn't take it on because we weren't relying on it.

John Byrne [00:16:28]:

Once, I suppose there was an issue where we were relying on something that another project was to do and it descoped it. So we took her on, but it wasn't forced on us. It was, it was simply a case of, well, they've descoped it, which means we can't just. We were taking a shortcut. They were doing something very similar to what we needed as our starting point. So instead of. So we started from that deliverable kind of area. And when they scoped that deliverable area, well, it meant we no longer had that as our starting point.

John Byrne [00:17:00]:

So in order to deliver our project, we had to move back. But that was, you know, again, as I said, that was one of the big changes. And the big ones aren't usually the problem because the big ones, you go back and you redo your business case.

Dante Healy [00:17:12]:

And you big ones usually go through the proper governance.

John Byrne [00:17:16]:

Yeah.

Dante Healy [00:17:16]:

And as you say, it's the small workarounds that build up and create hidden problems later on when you try and transform. And the biggest risk is it becomes status quo. And then when you have another transformation program and you're re platforming again. Oftentimes what happens is you end up lifting and shifting as per usual, you just change systems. But the dysfunctional business processes stay the same. And what's not realized is that some things exist purely because they were workarounds. Because one team ran out of funding before another and then they pushed the development out to a place where it should never have existed.

John Byrne [00:18:04]:

Yeah, sometimes I suppose that can happen. That if it's not documented, then in the right place at the right time, somebody in the future can't rely on it because they can't, can't find where, you know that's in the wrong project that they're looking at the thing. But in the more immediate term though, that always adds up to your project being becoming over budget or taking longer that you know, no matter how small there is, it's, it's going to add something. If it was, it has to add something. Either that or you're taking away something from your existing scope.

Dante Healy [00:18:33]:

You know, I think, yeah, I think different projects, even if they're in an interconnected program, run on different timelines and you might be seeing the end of one project in the program in one area and then the beginning of a new project in another area. The project that's ending has run out of funding and what they've ended up doing is try to pass over any undelivered items onto other areas to find homes for the requirements. Because at the end of the day, the cheapest time to affect changes in your project is at the start when it's all new. And then the most expensive time is when you've already built about 80% of it. And then you're trying. Any changes you effect may have serious implications on what you've already laid as foundations. That's the risk. Especially if it's big changes like, I don't know, on data projects you could be changing data tables, adding a new field on a table.

Dante Healy [00:19:37]:

That means that all your, all your existing, shall we say data pipelines need to be reconfigured to pass that new data set through as an example. And I mean can be more complicated depending on how much impact the tables involved are. But you know, it could just be, if it's well designed, it could just be minor config or it could be a whole major rewrite and impact analysis going end to end to make sure nothing breaks when you make the change.

John Byrne [00:20:16]:

Again, I think that's the thing that impact analysis needs to be done regardless because everybody will say it's only a small thing. Sometimes it does end up only being a small thing, but you don't know until you do the impact analysis. And if you don't do the impact analysis initially and just start that small thing and it becomes a big thing, then your project is doomed. You've just gone over budget or over time and you had no warning. So you have to do the impact analysis no matter how small you think the thing might be, make sure it's going to be that small. And if it turns out then from the impact analysis, it's going to be a bigger problem, well, then you can go and you do the change request and all the rest of it and you do your cost benefit analysis and make a decision. Will we do it or won't we do it? Yeah, we have to do. Or somebody will say, well, okay, we have to do it.

John Byrne [00:21:05]:

Then we need to get more budget.

Dante Healy [00:21:06]:

We need to be allocated or we drop something else.

John Byrne [00:21:09]:

Exactly. And if nobody's willing to do that, then, well. Well, then we don't have to do it because it's obviously not.

Dante Healy [00:21:15]:

We don't have a plan, we have a problem because we don't have enough funding to deliver the project as is.

John Byrne [00:21:22]:

But what I've often found when situations like that arise is that when push comes to shove, turns out, no, it doesn't have to be. It's just that that person who's requesting it. Really? Really. But when the person in charge is being told they can have this or they can have the original, they want the original, and that's not important, no matter. And that's something that, you know, basically, unless the project sponsor is telling you they absolutely have to have something, nothing has to be had because the project sponsor is the person who is the ultimate authority.

Dante Healy [00:21:54]:

And then that's. You just escalate to them and you let the grownups figure it out. Especially if it's, if it's a senior person in another area. But isn't the, isn't formally owning the project, then they need to go through the project sponsor and it's up to the project manager to communicate that that's it.

John Byrne [00:22:14]:

I mean, the project manager, then at that stage isn't the one who should be making the decision. The project manager is the one who.

Dante Healy [00:22:20]:

Needs communicate and doesn't sit on it.

John Byrne [00:22:23]:

Exactly. Communicate doesn't sit and is able to tell the project sponsor, okay, here are the repercussions of doing that. Here are your options. You can pay this much extra to do it, you can take this much longer to do it, most likely taking longer and paying extra is going to be compliant. Or we can drop this other stuff here, that's it. And then the project sponsor is going to know, well, don't want to drop that other stuff. I need it, don't want to pay more and I don't want to take too much longer. Well, then you can't have this extra bit.

Dante Healy [00:22:56]:

Well, the requester then has to fund it themselves. Ultimately, if they want it, they need to pay for it.

John Byrne [00:23:03]:

Yeah, which just happened, you know, like in, in a recent project. Somebody's decided that they, they, they wanted one of the, an outside consultants to sit in on the project board. You know, I'm not sure why exactly, but. Well, you know, I won't tell.

Dante Healy [00:23:21]:

Doesn't sound like a conflict of interest at all, does it?

John Byrne [00:23:25]:

Exactly.

Dante Healy [00:23:25]:

Yeah.

John Byrne [00:23:27]:

But my response to that as project manager was I didn't even, haven't even raised it with, well, I have raised it with the project. I, I did raise it with the project sponsor, but my response was simply, look, there's no budget in our project for that. So if you want to have it, that's no problem. Somebody else is going to have to pay for it, have some other budget.

Dante Healy [00:23:47]:

Yeah. Imagine paying someone to be able to listen to the portfolio plan and then know where they can, which areas they should be strategically bidding for, effectively being paid to listen in on insider knowledge.

John Byrne [00:24:02]:

Now once, once they realized that they had to come up with the money for it, then suddenly things changed.

Dante Healy [00:24:08]:

Yeah.

John Byrne [00:24:10]:

But again, you know, as project manager, that's not a decision that you need to make. It's just something that you need to be able to communicate what the repercussions are.

Dante Healy [00:24:17]:

Yeah. And for me, that sort of scope creep isn't the type of scope creep that comes from uncertainty at the start is actually from people who have different agendas that aren't aligned with that of the sponsor. Oh.

John Byrne [00:24:32]:

And to be honest, my experience with not, not just my own projects, but with other people's projects, when you see them, you know, when you're on project boards and program boards and stuff like that, you can see other projects and what's happening. My example, my experience with that is scope is almost always, I tell you, 80% of scope pre events that happen is exactly that. It's not that they didn't plan things out right at the beginning. They did. They had everything planned out right at the beginning. It's that somebody then decides after the fact that, oh, let's just do something different than what we agreed originally.

Dante Healy [00:25:04]:

Yeah, we've only got X million dollars to spend this year. Let's assume that these two projects can combine when they can't. Or let's just defer another project out not realizing by doing that they've deferred something critical and it was a project on a critical program path. Let's move it out to next year. And we're good. Very simple decisions.

John Byrne [00:25:27]:

Yeah, yeah. Although that's at the program level. But I mean we're in projects and any scope that I see are generally just, it's usually just people wanting to add. It's, it's, you know, it's little bits.

Dante Healy [00:25:39]:

Little wish list items.

John Byrne [00:25:41]:

Exactly. That they didn't mention at the beginning that and aren't really needed but they just kind of figure, well, since you're here, let's, let's do this, let's do that, let's do the other. And project managers just agreeing to it and thinking that taking their word for taking the developer's word for it that it's going to be just. That's only small thing. But you know, if the developer won't give you that in right then it's not going to be a small thing. You know, the developer won't commit to. Oh well, it's only going to be that small. Then you can give me a commitment in right.

John Byrne [00:26:07]:

And that you can do it and it won't cost any extra and you can have it done by such and such a date. And I guarantee you no developer will do that because they all know, oh no, this could turn into something really, really big and we're not really scoping it out properly at the moment.

Dante Healy [00:26:19]:

Yeah, we got to defend our margins as well. If I commit to doing unpaid overtime, that's, that's our business down the pan.

John Byrne [00:26:28]:

Exactly. And since they, and if, but if that's a realistic worry for them, well then that should be telling the project manager this is not such a small job. This is not guaranteed to be just a small, you know, an extra hours worth of work. This, this could turn into something big because if there was no chance it could turn into something big, they'd have no problem just doing it.

Dante Healy [00:26:47]:

And that's a problem. You know what? Even that isn't as bad as something I've experienced in the past where you get requests and all you need is them to the request to do the analysis. Forget about funding, just give us the analysis. What exactly are you asking for? And they give a vague statement of what they want, but not how they want it. What are the specific details and you're waiting for that information and then like a week later they say, have you delivered it yet? Yeah, they're saying, what exactly do you want us to deliver?

John Byrne [00:27:23]:

I did have a, it's a good while ago now and a previous project that I was doing, I started off to do another project for the, the same organization and then I left because they changed what the project was. But the, the initial project that I was going to do was to do some research to do some analysis to find out what the. They, they needed to achieve something they, they basically just needed to achieve to, to lower their debtor days down. So people who don't know accounting better days is just, you know, from the time you do your work to the time you get paid for your debtor days, and they needed to lower that down. And so we were to go in and do a bit of research to find out, well, what was the, what's the critical path there? What, what, you know, what can we do to lower down. And when we went in and we got certain on the project, then suddenly they'd gotten a budget for that, doing that, then suddenly they wanted to spend the budget on making changes, upgrading the system and all that. Their, their response was, yeah, but if we, if we do that, it'll save us time and that will, then we can spend more time collecting. So that will lord, you know, shorten.

John Byrne [00:28:27]:

Yeah, and they kind of looking, thinking, but we don't know if any of the things that you're looking to change are actually on the critical path. It doesn't matter because they'd have more time than to do the stuff on the critical path if it's not on. And you know, so they were just making Europe as they went along. They just had funding and they had a developer and they just wanted the developer to make their. Now most of what they were asking to be done would have been done as part of that bigger project, you know, because what we were effectively doing was creating a business case to do a bigger project. And they spent the money on the business case making small tweaks to their system. So they actually did themselves out of a chance to make some major changes with a bigger project. Because you can't, then you have no business case to go looking for the bigger project.

John Byrne [00:29:10]:

Your business case now is gone. That was what they did, but that was scope creep in a big way that they were doing.

Dante Healy [00:29:15]:

But that was a lack of a strategy as well, focusing on tactical changes rather than the strategic changes that are exactly big hitters.

John Byrne [00:29:25]:

Yeah, and, and as project manager, there was absolutely nothing I could do because the person who was driving it was the sponsor.

Dante Healy [00:29:32]:

If they decide they want to take a change of direction, well, there's not a lot you can do except for point it out to them and then hope that they see sense clearly. Not in this case.

John Byrne [00:29:44]:

No, in this case they didn't. So I pointed her out, they didn't see sense. And then I just pointed out, well then in that case there's a better off savings saving the money you're paying a project manager because there isn't really a project here. You have a technical team leads. All you're doing is telling that technical team lead what you want done. So you don't need a project manager in between.

Dante Healy [00:30:02]:

So there's, you just need an IT analyst or data analyst or whatever developer to do the tactical things you want and plug fix, you know, patch holes rather than replace pipelines.

John Byrne [00:30:16]:

Yeah, so, and that was, I mean, okay, they completely changed what the project was, but they completely changed it in a way it was kind of scope creep because the way it was originally set up, we were to do the business case, but we had got a development team there. And the reason we had the development team there was twofold. Number one, so that we know what's viable, what, you know, making the business case, what can we do? But the second thing was if there were any quick fixes, they just do the quick fix. You know, we did three months, would.

Dante Healy [00:30:45]:

Have made it easier if you implemented the system change or whatever, the upgrade, that's it.

John Byrne [00:30:51]:

So, you know, but what they torn it down in, so what they end up doing was the scope creep was, well, they kept adding more and more quick fixes. You know, not everything was quick fixed. Then suddenly there were things that were going to take like a month or development. You're thinking, well, a month or development is.

Dante Healy [00:31:05]:

This is technical debt in action, right?

John Byrne [00:31:07]:

Yeah, exactly. Exactly.

Dante Healy [00:31:09]:

How do you expect your pipes to work properly when all you're doing is instead of replacing the pipes, you're, you're just patching holes with duct tape.

John Byrne [00:31:17]:

Yeah. And you're spending your whole budget, you're increasing the amount of duct tape you're doing and spending your whole budget on the duct tape, which meant that you were never going to get a business plan, business case to be able to go and do a proper project to replace the pipes. And yes, as far as I know, they have. That organization still has the same better days because it's a, you know, an organization that needs to report them to the SEC and, you know, for every quarter for the thing. So. And I haven't, when I've, when I have looked on it, I haven't noticed any major change. So they're stuck with the same thing because they went and they, you know, but that was, that was a scope read that actually completely changed what the project was supposed to do now. So that's an extreme example.

John Byrne [00:32:02]:

Now, it was only a small project. It was a small, supposedly a business case project that would last three months and instead became a small patching project. But the patching was part of it. But only a tiny part of it suddenly became the whole project.

Dante Healy [00:32:16]:

Yeah. And in sympathy to that, that team, then, I guess the pressure they felt meant that they succumbed to thinking short term rather than longer term. Yeah.

John Byrne [00:32:28]:

And to the extent that they just completely ignored all the advice that we're.

Dante Healy [00:32:32]:

Being given, well, that's unforgivable.

John Byrne [00:32:35]:

And, you know, but again, that was. The project sponsor was actually the driving force of that. And when that happens, there's nothing the project manager can do. But if the sponsor is the one who's doing, all you can do is project manager is make sure they're aware of what the repercussions are. They probably won't believe it. They'll think you're exaggerating or you're just.

Dante Healy [00:32:53]:

They'll live the pain, won't they? So you either learn through others or you learn through experience, Right?

John Byrne [00:33:00]:

Exactly. And if they're refusing to learn through orders, then you have to let them learn through experience. But you make sure that you had tried to give them the opportunity to learn through others by advising them and doing the research. To say, well, this is what the repercussions are if you do that.

Dante Healy [00:33:12]:

Well, that's the important thing, is to make sure your conscience is clean and.

John Byrne [00:33:16]:

Your professionalism, you know, they can know that you're covered, basically. They can't turn around and say that you failed the project. Now, I didn't know this was going to be the repercussions because you never told me. It's like, well, no, I did. I, I did the research. I found out that, no, this is, this is not, you know, going to achieve what you hope it will achieve. It's going to either cost us more, take longer, or it's going to take away from the scope. That was agreed at the beginning and you made the decision to go ahead and do that.

John Byrne [00:33:48]:

So there was nothing I could do.

Dante Healy [00:33:51]:

Yeah. At least, as you say, your conscious is clean. Sometimes, though, some project managers, a lot of them are on contracts anyway. So to actually go against your sponsor, who will not only ensure you. You stay for the whole duration of the project, but will also write you a job reference, going against your sponsor can be an occupational hazard, could potentially risk your career, and you have to make that judgment call. If that's really the hill you want to die on, clearly you can only advise them. You can't, you can't, you can't pull rank and.

John Byrne [00:34:29]:

Oh, no, no. I mean, yeah, I mean, it's not project manager, but that's what I mean. The, the ownership. Sometimes project managers tend to take ownership of the business case and they don't. The ownership of the business case lies with the sponsor.

Dante Healy [00:34:41]:

You just have to manage expectations.

John Byrne [00:34:43]:

Exactly.

Dante Healy [00:34:44]:

Communicate.

John Byrne [00:34:45]:

Yeah, exactly. So you just have to make sure that that sponsor. You're not arguing with the sponsor, you're not telling the sponsor the sponsor is wrong for wanting to prioritize something, but you're just making sure the sponsor has.

Dante Healy [00:34:54]:

You advised them.

John Byrne [00:34:56]:

Yeah, these are the facts. I'm not. You know, you don't even necessarily have to advise them if you don't want to. You know, maybe you don't know what's best. You might not, because, you know, you're a project manager, you don't know what's best for the, the thing. But what you do have to do is say, right, this is what happens if we do it this way. This is what happens if you do it that way. Choose the way you want and then, you know, you go for it.

John Byrne [00:35:15]:

But. So you're not advising them which way to go. You're just telling. This is. These are. This is what happens or what's most likely to happen.

Dante Healy [00:35:23]:

Yeah. Which is your opinion, right?

John Byrne [00:35:27]:

Well, yeah. You usually think it's a. It's an informed way. It's not, it's not advice that you're not telling them which way you think they should go. You're just saying, this is what I think based on my experience. This is what happened.

Dante Healy [00:35:37]:

This is what you believe is the correct course of action, Right.

John Byrne [00:35:40]:

Well, no, I mean, that's what I'm saying, that you don't necessarily have to tell them the course of action. These are the two options that you have. Pick one. That's it. You're not advising them which one to pick. You're just telling them this is what, from my experience, this is what will happen if you go this way, and this is what will happen if you go that way. And I'm not making.

Dante Healy [00:35:58]:

That's got to be Framed by your viewpoint as to which one you think will yield the most benefits.

John Byrne [00:36:06]:

If you tell them which one you think, then you're giving them advice for. I'm saying don't tell. You know, sometimes you might not tell them that unless you just. Because Matt, you might not know. You might not know what's the best thing.

Dante Healy [00:36:17]:

But then, yeah, but, and, and you're right, maybe it is about framing rather than consultation but, and diagnosis. But at the end of the day, if you thought things through, the answer should be apparent. Right?

John Byrne [00:36:35]:

I mean sometimes you, you, you know, you, you have option A, you have option B. Both options will improve what you're doing.

Dante Healy [00:36:40]:

Yeah.

John Byrne [00:36:41]:

And then it's just a matter of. But which way do you want. What, what do you want to improve? You've got, you know like you've got X amount of money and you can, you can improve the technical system or you can improve the process that people currently do. What, what, what you prefer doing what the people currently do. Improving that is short term gain. You will eventually need to, to replace the system, but it'll fix all. It'll, it'll paper over the cracks. For now doing the other way is a longer term solution but it'll be a more long lasting solution.

John Byrne [00:37:14]:

But you know, you may not know what the team did. Maybe they'll decide. Actually the short term solution will do me for now because right now everybody is under so much pressure that I'm going to lose them all to. They'll quit or they'll be out sick or whatever. So do that now. Yes, the other one would have been a better long term solution but the decision is that short term is what I need. Now you may not as a project manager actually know that. You won't get to see that.

Dante Healy [00:37:42]:

You won't know what the options are.

John Byrne [00:37:45]:

Well, you know what, you know what the options are but you won't know what the best option is because you know as a project manager what you're going to say the best option is. The best option is the long term fix because then it lasts longer. Yeah, but that's no good to the people in the day to day if they're all going to be out on stress related live because they need the current system to be just improved a bit, not a new system being brought in. So you know, you might not be able to make a recommendation. What you're going to be able to do though is say well here are your options.

Dante Healy [00:38:13]:

Well, I mean there was one case in my career when I was on a transformation program and the, the solution was because we had a very complex process and the, this location wanted to automate everything in it would have cost a fortune. Thankfully someone came up with the option of outsource it, consolidate and outsource it because it was, it was debt collection. But the debt collection was fragmented across the country with, with small like collectors who were tasked with repossessing the assets that were being loaned out on higher purchase contracts. And so what it was, what was determined was rather than have a whole central office department managing these regional debt collectors, we outsourced the whole thing to a national vendor and therefore it saved us a fortune in having to having to invest in infrastructure to do it all in house and coordinate all those regional elections. Plus the risk was, I mean it was a potential risk of not having a collection service. But long story short in that, in that sense changing the business process had a direct financial impact with very little, with very little effort if that makes sense. But I wasn't aware when I was going into it and I was doing the analysis of automating an inefficient process. But just someone from the business who knew that that part of the business was able to that perspective because we thought even though they had a different process compared to all the other locations, there was someone who knew actually you can do it this way.

John Byrne [00:40:08]:

That's where I mean that's what I'm saying that as a project manager you don't always have to make a recommendation as you may not know, but you have to come up with the options, try and find out what the options are and then let the people who know decide which is the best option for me. And you can't always, as a project manager you don't necessarily always have to know what the best option is. You just have to kind of figure out what the options are.

Dante Healy [00:40:31]:

But when you have the options you need to be able to present a recommendation. And for me that was a no brainer when I was.

John Byrne [00:40:39]:

Again, it depends on what the project is. I mean you don't always have to make a recommendation. You document the options. If you don't have the internal knowledge, you might not know what recommendations make because you don't know what the, what the needs are. So like in that situation or the.

Dante Healy [00:40:55]:

Sponsors decision making criteria, it might not even be cost saving exactly.

John Byrne [00:41:00]:

It could be something else completely. So you, you, but you need to have the options and then you present the options and let them make the decision where you know, usually you make a recommendation especially if you're in an area where you actually know. So, like my area would be, you know, finance, financial systems, making, you know, give people options on the financial systems, how to do. I'll make a recommendation because it's an area of expertise for me. So I, I, you know, I'm also a consultant, not just a project manager. But if I got myself involved in a project doing, I don't know, HR stuff, say I know nothing about hdr, I couldn't tell you what the best I can tell you what the options are for your HR systems and procedures and all that, but I couldn't tell you what the best one is for your organization. And chances are I'm not going to be there long enough to figure that out because I was brought in as a project manager, I wasn't brought in as a consultant. So I'll give you the options, but somebody there as an expert can make the decision which is the best option for you.

John Byrne [00:41:56]:

And ultimately that's all they do. Even when you make a recommendation, they're still, they don't always go with your recommendation. There might be other things that they're considering that you weren't aware of.

Dante Healy [00:42:06]:

So I guess in terms of managing scope creep, I think we covered a lot of ground.

John Byrne [00:42:12]:

I guess I think the key thing is, no matter how small you think that scope is, extra scope is going to be follow through on a process of evaluating it and getting written estimations from the people who will be actually carrying around and see will it impact the, how big of an impact it will have on the business case. And you know, if it genuinely is something that's tiny after doing all that, then you can go ahead and do it. But if it's, if it risks having a bigger impact on the business case than everybody initially estimated, which it almost certainly will, then it's up to the project sponsors to decide, is this worth changing our business case, or is it a benefit, or is it something that's just going to be a cost and not derive enough benefit to justify it?

Dante Healy [00:43:00]:

I think in terms of scope creep, maybe we can revisit this in another episode, but I think we've covered a lot of ground in terms of how scope creep should be managed. And really what are the, what is scope creep? Because it sounds like creep really denotes small items trying to go under the radar of governance. It's not really a big item because that doesn't creep up on you. It's all the accumulation of little items.

John Byrne [00:43:33]:

As we mentioned at the beginning, the big ones, you're always going to do the Reevaluation anyway, so you'll know exactly what you're getting yourself into. So it's fine. But it's. Yeah, it's the little things where people just try to pop them in without doing it. They're never as small as everybody tells you.

Dante Healy [00:43:50]:

And ironically, I mean, project management is 80% communication. Do you find it's better to keep quiet and deliver things on discreetly, or do you give people a forum to actually submit requests but manage their expectations openly and say, unless this is formally accepted, don't assume we're going to deliver it just because you've asked for it?

John Byrne [00:44:15]:

Oh, yeah, and I think that's the only way you do it. That's how you manage scope. Read. Because if you don't do the forum, if you don't give them a forum to do it officially and go through the things, then they'll come to you unofficially and try to get you to do it.

Dante Healy [00:44:27]:

And they might still do that, even.

John Byrne [00:44:29]:

With a forum, they might still do it, but at least you have something. There's a forum there and that's it. And say that's the only way it happens is through that forum, that it never will be done without that forum. But that's where, you know, you always.

Dante Healy [00:44:44]:

Have someone who shouts all the time, regardless of the process you've got that they think that if they can just be loud that they can bypass the process. Do you find that?

John Byrne [00:44:54]:

Sometimes I don't worry about that too much because if they're being that loud, it means somebody else will cop on, they're trying to bypass the process and we'll tell them, no, that's not happening. It's the quiet ones who do it, you know, I mean, sometimes, sometimes they genuinely think it's just going, that's only a small change. I'm only asking you to, you know, to add in an error box. Yeah, but there's a heck of a lot of development work that will go into that. Maybe there's not. Maybe all they're asking you to do is change the wording in the existing error box. And that is small, you know, but you need to let them go through a process so that you can evaluate how small genuinely is and how big is it. If it is genuinely small, then you do it.

Dante Healy [00:45:34]:

Or they may give a vague request and then three months later say, oh, I requested this three months ago. Why haven't you delivered it yet? I asked for this three months ago. You're very unresponsive.

John Byrne [00:45:46]:

Or worse still, they make the change because I'VE seen it happen with somebody. They did it put a lot of work in and put their team under a lot of stress to get the change made. Did it managed to stay on time and stay on budget and all the rest of it. And then when it came to getting sign off, the person who'd made the request didn't actually like the end result and wouldn't sign off and said no, but that's, it was a different thing that was in the original scope that I signed off and you haven't delivered that. And the person said but you asked to send the changes to this, but there was no written because they'd done it quietly and the project manager who was on the project did it to help them and thought he was doing a good job and you know, helping them actually got thrown under a bus then because didn't like the outcome and then basically said but you've, there was no, we didn't formally ask you to change that. It was the original sign off and the project manager had no. That was involved in that project. He, he had nothing.

John Byrne [00:46:49]:

It was all done. It wasn't even done on email. It was done in person. It was back before lockdown. So they, they, you know, it was done in person, personal requests and, and all the stuff was done in person. And so he had nothing. And then having delivered the project. Yeah, yeah, he was pushed under a bus because the, the person who made the request didn't like how it turned out.

John Byrne [00:47:12]:

He got exactly what he'd asked for but didn't like how it turned out and said oh no, I PR it the other way that I originally asked for and then completely stabbed the guy in the back that had done all the work to help him. They didn't even admit that. Yeah, I had asked for that and now I'm changing my mind. Kind of made. No, what I signed off on was the original. I never signed off on this. I was just picking your brains. Could it be done? I didn't ask you to do it.

John Byrne [00:47:35]:

And so, you know, that was a very extreme example. I've never seen that like that happen before or since.

Dante Healy [00:47:42]:

And that's, that's another key thing is you have to keep the discipline. You have to document decisions and requests because then that becomes, in that sort of environment, and I don't want to say this, you have to do it anyway as a professional project manager, but it's also like managing Scope Creep then is becomes really a glorified cover my ass exercise. Because when things, if things do go wrong, heaven forbid at least you've got that documentation to hold on to, to say, no, I didn't go maverick, I didn't, I didn't, I didn't suddenly make these massive changes without, without approval. Here's the documentation, here's who requested it, when, and this is when it was discussed. And make sure you have things minuted.

John Byrne [00:48:31]:

Yeah, yeah, exactly. And, and that, yeah, you know, but that is good government. So it does mean then later on, if something goes wrong, people can see where, you know, who asked for it and why and what was going. How did we, how did it go wrong? Did we not do any, you know. Oh, we did do an analysis. Oh, look, we just, we got the analysis wrong. We said it would be this and it turned out to be that.

Dante Healy [00:48:53]:

But then that also was a failure. When the request was submitted, you, you need to cover yourself and say, let me run it past all the stakeholders, the development team, the business stakeholders who will be impacted. And then I'll come back to you, A, with an estimate of when it can be delivered and B, what are the implications downstream?

John Byrne [00:49:14]:

Exactly. And then if they still want to go ahead with it, then you do the full, the change request, go to the project board, get them to review it, sign off on it and all the rest of it. And then it means everybody is aware as to what's happening, why it's happening and if it does go wrong. Well, everybody was aware of what the risks were by agreeing to it.

Dante Healy [00:49:34]:

And to that person, who, your colleague you mentioned, who was negatively impacted, they lived to fight another day. They protected themselves.

John Byrne [00:49:46]:

They would have. Yeah, yeah. I mean, in that case, in that particular, I don't think he was too bothered about it because he was a project manager, but he wasn't a full time professional project manager. He was just the one who drew the shorts around, had to manage that project. So he just went back to doing what he would normally do and lesson learned.

Dante Healy [00:50:07]:

And so he was taken off managing projects. But he still had a job at the end of it.

John Byrne [00:50:11]:

Yeah, yeah, but that was the end. He finished this project even though he couldn't get it signed off. He just, and I think it actually backfired on the, as he walked in that company, he was just, you know, it was an internal thing that was put on as a project manager and then went back to his day job, but very shortly afterwards got promoted and ended up being the, the guy who slapped on the back's boss. So I don't know what happens there. I have that, you know, that'd be some Awkward meetings there, knowing two of them.

Dante Healy [00:50:38]:

Well, they wouldn't last long. I'm sure. The other guy is probably no longer at the company.

John Byrne [00:50:43]:

Probably. Probably not. It wasn't the company that I actually worked for. I just was aware of what had happened because the project in that company was impacting a project in another company and I was the project manager in that other project, so I knew what had happened. But thankfully it didn't affect us. We were just taking, taking and just.

Dante Healy [00:51:01]:

It's a very, very cautionary tale on all sides because the person who was doing the political backstabbing probably didn't realize that it would come back to bite him later.

John Byrne [00:51:16]:

Exactly. Exactly. But it was a lesson. Like it was early on in my career as a project manager and I, you know, starting to manage projects. So when I seen it happen, I kind of. It was a nice little reminder to me that the documentation exists for a reason. Document everything and get the process. Go through the, you know, Prince, who is good with that, with the governance.

John Byrne [00:51:38]:

Go through the governance process. No matter how small you think that change is.

Dante Healy [00:51:41]:

Yeah.

John Byrne [00:51:42]:

And how helpful you think you're being by, by, by, by trying to help the, the person do it because, you know, it goes wrong. And he. And that situation. I think what made it even worse was it didn't go wrong. It actually did exactly what the guy had asked for. But when he seen the end result.

Dante Healy [00:51:56]:

Then decided he didn't like it.

John Byrne [00:51:58]:

Yeah. So, you know, that was the worst case scenario. There's no winning there. You know, it's not like the project failed and it went wrong because he tried, he tried to change it. He made the change, delivered exactly what he was asked to do and then got pushed under a bus or, you know, attempted to be pushed under a bus, but, you know, was. Was obviously more astute within the organization than the other guy.

Dante Healy [00:52:20]:

Realized a lot more goodwill, put it that way.

John Byrne [00:52:23]:

That's it. Yeah. The project didn't. Because I think, I think a lot of them, even though it wasn't documented, knew what happened, even though they couldn't prove it. So it was. He had a lot of sympathy and a lot of backing from people. So. But again, though, you know, not every project manager will have that, especially if you're.

Dante Healy [00:52:41]:

You're an outsider on a contract.

John Byrne [00:52:43]:

That's it. It'll just look like you went rogue. Yeah.

Dante Healy [00:52:46]:

If you don't protect yourself with documentation, minutes, et cetera, that you can always refer to.

John Byrne [00:52:51]:

Exactly.

Dante Healy [00:52:52]:

And that's what usually happens. People, if they do anything that looks remotely suspicious, they ask for a request in writing and that's one thing you need to do regardless of whether a process is followed or not or even has been defined. If you don't have a process, at least ask for the request in writing. Get and then relay that request to the people who matter and get their feedback and then make a trade off decision based on, well, what does it mean? Do we increase cost? Do we drop something else? And then once you've got that alignment, you're protected. And it's not the most glorious thing, documentation in this case, but it means you live to, you survive to fight another day. Right. And actually when you survive, you know, eventually we're calling out the worst parts of project management. But on projects where you actually get to do good work and it's relatively smooth sailing where the leadership actually has your back and isn't working against you.

Dante Healy [00:53:56]:

And SCOPE is managed collaboratively so you can deliver as a team something of value that those moments make all of the previous pains worthwhile. So it's all about picking your battles, protecting what matters, and making sure that you don't die on a hill that was never yours to defend.

John Byrne [00:54:18]:

And I suppose when we're giving those examples, we're giving examples to hear of.

Dante Healy [00:54:23]:

People, really extreme cases of pressure. Yeah.

John Byrne [00:54:27]:

Like in a normal thing, it's not really that you're going to be pushed under a bus or anything like that, but it is though that the project will add stress on that if, if the change wasn't taught out. So at least by following the process, part of that is going to be cost benefits analysis. It's making you think about the project plan and what you're going to change and what the impact is going to be. And that might just save you an awful lot of stress because even if everybody pulls together and tries to save it and there's no blame apportionment and nothing like that, ultimately you're.

Dante Healy [00:54:59]:

Yeah. Delayed and it could have been avoided. And that, that, that sense of not, not having delivered in the best way will, will eat at you.

John Byrne [00:55:10]:

Yeah, exactly. So it's best, I think, as tempting as it be as a project manager, to try to, to just do something really smoothly and to bypass, you know, what can seem like bureaucracy. There's a certain amount of governance that is good and following a change process, a change request process is good no matter how small the change is. Because every change, everybody says every change at the beginning, that's only a small change, but you need to put the thought into it to make sure is it really? Or is it a big change you know that it's doing? And the only way to do that is to follow a process. Follow the change request process.

Dante Healy [00:55:48]:

Define it as soon as possible so people know what to follow.

John Byrne [00:55:52]:

Exactly. That should be set up at the very beginning when you're putting together your project. Your project initiation documents have the change request thing in there. Even if you think, gosh, we have it set down now, the plan, we speak scope throughout, we know exactly what's being delivered. There will be no changes. That's fine, but still just put a process in. Just use the standard template. Especially if you're in an organization that has a lot of projects, there will be a standard process.

Dante Healy [00:56:16]:

You go to your pmo, they'll give you all the templates and if you don't have it, if you have, if you're with a project management organization, they'll have standard template and if you don't.

John Byrne [00:56:28]:

Have them, you'll find them online. Prince, two templates, something like that. Just. But just have something in. Put it in the initial project initiation documents and then if anybody asks for the change, just say this is the way it's there. It was documented, I can't bypass it.

Dante Healy [00:56:43]:

Worst case scenario, ask AI.

John Byrne [00:56:46]:

That's it.

Dante Healy [00:56:48]:

Thanks, John. That was an interesting discussion. Any final thoughts?

John Byrne [00:56:52]:

Yeah, Project managers just. You do your best to manage the change, but just make sure you know what you're getting yourself into. There'll be an eyes open any changes that you're making.

Dante Healy [00:57:01]:

I think sometimes you have to manage up, you try and manage down and there will always be people who try and move you sideways. So protect yourself, make sure any changes, even little ones, are fully documented and communicated with the people who matter. Log them as risks if need be, if you're not sure, and then just make sure that they're covered in this. The relevant governance meetings.

John Byrne [00:57:29]:

Yeah, so that's actually a good point. Just those of the risk register. I haven't thought of that. As I said early on, sometimes the change things happen because people are a bit too vague in the scoping part and sometimes they can't be more. That vagueness is there for a reason.

Dante Healy [00:57:45]:

It's uncertainty and risk is just uncertainty.

John Byrne [00:57:48]:

Exactly.

Dante Healy [00:57:48]:

So.

John Byrne [00:57:49]:

So if you get that situation at the beginning and that something scope wasn't fully defined, just stick that in the risk register and you're covered.

Dante Healy [00:57:58]:

Yeah, exactly. You can't say it was, it wasn't available, but yeah. And that goes back to the, the documentation. It's not bureaucracy, it's actually your defense. Against any changes or any misalignments within your organization and and the projects as.

John Byrne [00:58:17]:

Well you know that as I said even if everybody pulls together and there's no blame games or nothing like that no politics it still just helps the project to be its best chance of success. You know you have to give Prince to this much. It's it is one of the best methodologies for a reason and one of those reasons is it makes you have solid governance throughout the project and and.

Dante Healy [00:58:38]:

Same for PMP as well and it you know you could argue waterfall does deliver a lot in terms of documentation and sometimes that's needed. Okay well John another fascinating conversation thank you very much for your time and for our listeners Please don't forget if you enjoyed it like and subscribe and feel free to send us feedback in the feedback form links will be in the show notes so thanks for listening and now go manage some scope John thank you very much as always.