Dante Healy [00:00:02]:

One. Hello, everyone. Welcome to business breaks, your project management edge. Today's episode is for senior project managers who've seen the glossy Gantt charts, the template decks, the slide heavy status reports, and still found themselves cleaning up the mess when things go sideways. So we're aiming to cut through the noise to talk about project planning that actually holds up under pressure. We're aiming for no fluff, no theory, and sharing practical insights across the project planning domain. So we'll organize it into three themes. And if you've ever juggled shifting scope, resource roulette, or strategic fog, then this one's for you.

Dante Healy [00:00:48]:

So let's get into it. So John, let's start from the basics except for they're never really basic. You've got your iron triangle. You've got your scope. You've got your time. You've got your cost or resources. And for senior project managers, the game isn't setting them. It's holding the line when pressure builds.

Dante Healy [00:01:11]:

And so in your experiences as a as a project manager, how do you find how do you find keeping the plan and ensuring it doesn't collapse once the rubber hits the road and reality kicks in.

John Byrne [00:01:30]:

Impossible. And Yeah. It will be no matter how well, how much thought you put into it. I have never once even plans that I've created, I've never once it never goes fully according to Planning. There's always something. Scope creep is is a big one, but you can control that. You can actually control that with a bit of forethought. Time is one that's tough to control because it it's it's, you're being pulled too many ways.

John Byrne [00:02:04]:

Your way to control that is to add in plenty of contingency. Yeah. Then people start trying to pull you back on the contingency and and, you know, you're having to do that. A big one is the resources. Cost is one, but, actually, in in the projects that I tend to work on, it's, it's people.

Dante Healy [00:02:24]:

Yeah. They're very scarce. The real resources is not about having bodies. It's about having the right people who can actually do the job, who have the skills, and a lot of those skills tend to be complex. They're built up over years. It's a combination of technical domain expertise, but also within a business, you've got the institutional knowledge, the tacit understanding of how to move your systems forward, your processes, your business, and that's very rare.

John Byrne [00:02:56]:

And the fact is that when you have the people who know how to do that, usually they're internal. Mhmm. They're they're and usually, they still have business as usual work to do. Yeah. And usually, you're not the only person where Project there there's other Project, and they're getting pulled up to those projects as well.

Dante Healy [00:03:13]:

And you're not the decision maker. You're not their boss. No. But you don't have direct influence over what their priorities are.

John Byrne [00:03:21]:

No. Exactly. And then it also comes down to which which project is the pet Project the most important person because that's the one they will be pulled onto most. No matter how important your project might be, no matter how well advanced you got with the scheduling and you made it clear you need them for this amount of time at this particular time, and it was all signed off and all approved, Somebody's gonna come along and pull those people away from you. Something there'd be an emergency. There'd be a big, oh, it didn't work out. The the month end close didn't work this month. We need them back for it.

John Byrne [00:03:55]:

And one of the the biggest, you know, I felt like banging not my head against the wall, somebody else's head against the wall was, we were in the middle of it. We needed them Project, and they were pulled away because the top management team wanted, to do basically year end reports at the February. Mhmm. They'd already done the year end reports. We'd lost them for the whole of the year end process, and they'd finished them. They came back to us just about to start and then got pulled away again because whoever the management was wanted they they've done it for the year end December. They wanted them for the year end February, even though there's no such thing as a year end February, but they wanted the same reports again. They never asked these are reports that were done once a year for audit purposes.

John Byrne [00:04:40]:

They've never been asked to do it before. They had been given no heads up that they were going to be asked to do it this time, and they got pulled away from us again. So we lost them then until and then March was a quarter end, so we couldn't use them. So it was April before we got them. Sorry, the April heading into May, before we got them again. And this was the, you know, this was a strategic project we were doing. So the top management team, the top the board of directors, and I was aware we were doing this. We're aware we needed them for this and still pulled them away because they wanted reports that they'd never wanted before.

John Byrne [00:05:13]:

And what purpose they served, I don't know, because there was no audit going on. It wasn't like they were doing anything to, you know, emerge or at and I got that, oh, we need that at this date as well as the the original one. So, you know, there was absolutely no way I could have planned for it. And that's the type of thing that happens frequently. You know, I'm not that exact example, but there will be something that there'll be another project will pull the rug out from under you and take the people away from you despite you having them booked.

Dante Healy [00:05:40]:

Yeah. And usually, I found it's usually a person who understands the business and the system. So they they draw that parallel. They sit in between it. Mhmm. They have deep knowledge. They know what trade off decisions to make. But, yeah.

Dante Healy [00:05:58]:

As you mentioned, they're in scarce demand, and they can be pulled in different directions. And ultimately, it's the most senior person who gets the call on where they're deployed. The one time I've seen it work is when it's, it's containable within their Management. And the person who who might not be the most technical or most business is it may be someone who's who's up there and good enough, but is then made the project lead. So they own and they're taken off their day to day job. Someone's backfilled them, and they're used as a project lead to deploy replacement to the system they already mani have managed. And it's seen as a development opportunity.

John Byrne [00:06:48]:

And that's that's the ideal. Like, you can get a situation like that where the person has basically become a full time worker on the project.

Dante Healy [00:06:56]:

Yeah.

John Byrne [00:06:56]:

That's that. And that is the only way to, to alleviate, I think, the the personnel problems are. But it happens so rarely that, you know, they'll

Dante Healy [00:07:05]:

do that. It it takes a lot of discipline from leadership to lock in critical resources in the right way. And also, I think even beyond that, you still need additional resources on top of that. They can't do everything themselves unless you've got infinite time, which, generally speaking, in projects with critical milestones milestones that doesn't happen. But, you know, I I guess there's an element of, wisdom, priority, and patience. And, you know, sometimes these projects, they don't need a lot of time. Can be two to three weeks to plan depending on the complexity, depending on whether it's an absolute completely new technology to use, or it's just reevaluating the whole process end to end. The the other two items you mentioned was really about clarity of the goal.

Dante Healy [00:08:02]:

And in that regard, Planning a clearly defined scope and what are the boundaries of the project to stop scope creep because people, if they're unclear really where where are the where do you draw the line, then they'll just accept every random ask as if it's part of the Project. And then the Project, but by default just naturally grows because there's no control over it. And if you have strong governance, you've defined your scope, and any any material changes are captured, and then decided whether it's either containable or if it needs additional Planning, or it can be deferred or parked. But either way, you get a a pushback because, you know, there's only limited time and resource, because you're controlling the scope by saying this is what we've budgeted for. This is what we're focused on. Anything you're asking above and beyond, there's no free ride. You're gonna either fund it, or you're gonna you're gonna have to accept that there's a high risk that it won't happen. I.

Dante Healy [00:09:11]:

E. We're not guaranteeing it, and in fact, we are rejecting it.

John Byrne [00:09:17]:

Kind of find, one of the best things to do to try and to to help stop scope creep is when you're writing down what's in scope, also have a section that explicitly calls out what is not in scope. Because, you know, when you write down what is in scope, people will be very broad with their interpretations at times of, well, this area here could be interpreted to include what we're asking for now. So it wasn't scope. So, you know, whereas if you've explicitly complained, they say, no. But look, we've listed it there as not in scope for this Project, and there it is. There's you know, it helps. It it it doesn't 100% guarantee, scope creep won't happen, but it can help that if you've come across a few things that people might be likely to ask for, but you're not planning to do in the, project, explicitly put it down as not in scope so that there's no pushback from them saying that, but you didn't say it wasn't, and we couldn't interpret this area here. Yeah.

Dante Healy [00:10:20]:

Yeah. There's always that temptation if it's a good good enough initiative, other people will want to piggyback off it. But there's there shouldn't be such a thing as a free ride. Either they contribute or they don't. Yeah. And if they benefit because there's not much additional effort or any additional effort to include them, then great. But generally speaking, that doesn't happen often. And usually, a new, ad, say, for example, an extra department included in the discussions, They'll come in with their own specific set of configuration and customization that will just delay the project even further.

Dante Healy [00:11:00]:

And speaking of delays, making sure the last point on this, holding up under pressure is making sure you've got a realistic timeline for delivery. If usually you find that you need contingency because the original goal wasn't realistic And it's always usually a challenge, a stretch target. So they probably, give you estimate they might estimate what it would take, and then they knock off a few extra months just to see if it can be delivered earlier.

John Byrne [00:11:34]:

And and there will always be something. I think we've discussed this previously in a in a in a attempt. There's always gonna be something that's gonna go wrong. Yeah. Somebody will be out sick. Somebody will will be will get a new job. Somebody will be replaced. You know, there there'll be a new person, which everybody thinks is great because we're getting a new person into the Management, and that will free up time.

John Byrne [00:11:59]:

And that but that new person needs to be trained in. And all these things that, you know, it will be a different thing for every project, but there will always be something that you weren't expecting that will come up. So put contingency in for it. But the problem with that is when you put in contingency of yeah. We we've put in a we a we've put in an extra month because we're expecting something to go wrong. We just can't name what it is. Yeah. Mhmm.

John Byrne [00:12:18]:

And then the first thing that the the the the steering committee or that will will say is, well, then take that out. Yeah. So so sometimes you're better off just increasing the length of time of individual items by, 20% or whatever it is to get in your contingency that way, and you'll get ahead up until the point where that that Project, whatever it's gonna be for this particular Project, it's

Dante Healy [00:12:42]:

And that's it. When when you put in the realistic estimates, you have to factor in things. Sometimes people don't overlook things like holidays, overlook things like critical points in the business, where if you're using resources that aren't purely project related, they will have their peak periods where they're just off limits. They won't be doing anything else. And you have to plan around it. Great. So I guess moving on. So making sure that, at the start of that Planning on from the start of the plan to actually steering it midway.

Dante Healy [00:13:25]:

Once the Planning kicked off and it's in motion, it's not just about delivery as such, but it's making sure you're working through complexity without losing the focus, And you're not deviating off track to the North Master or you're or delivering on the vision. So it's a question of continuous communication, quality, focus, risk, and making sure that you manage all of these variables that are competing for your attention. So unpacking that, John, how do you find how do you find steering through the noise once the project is in flight? What do you think works well, and what do you what challenges do you normally face?

John Byrne [00:14:14]:

Challenges I think you kind of hear on it there. The big challenge is communication. Trying to get that balance right because each stakeholder grouping needs different level of detailed communication and different style of communication. And that can be difficult if you if you give, somebody who who doesn't need the detail, too much detail, you can cause problems. If you don't and, obviously, then the the most common one that people could probably pull out, you know, is when you don't give enough details of the people who need detail, you know, that's that's an obvious one. But the other side of that is giving too much detail to people who shouldn't really be wasting their time with the detail. That can become problematic because then suddenly they start trying to interfere in detail that they don't really know enough about. That can pull you away then that you're having to explain things that you probably they don't need explained at this point in time, which then makes you take your eye off the ball on other areas such as the the risks, keeping an eye on them.

John Byrne [00:15:20]:

Are they, you know, are they still just risks or are they becoming issues? Yeah. And catching that early enough. How about yourself? What what, would be your key things there? Is that

Dante Healy [00:15:33]:

I think, you've hit the nail on the head. I just wanna just add to your communication because I think that's a valid point, because we're project managers. The majority of the job is communication. And as you quite rightly say, the majority of it should be about what you observe on the project. You're keeping an eye on the project. You're ensuring that people know what they're doing, and the tasks are being delivered. As much as it is making sure stakeholders are feeling comfortable that things are being well Management, because then if you end up if if they start having concerns and they start asking too many questions because you weren't clear or you weren't giving them the right answers or delivered in the right way, then you're going to waste a lot of overhead purely on just Planning out fires. And those fires could be people suddenly escalating because they aren't seeing what they're expecting.

Dante Healy [00:16:40]:

So I think, for me, a lot of it is around risk Management. Because I think the risks Planning with the unknowns are, are the biggest challenge. Anticipating them as much as anything, and then having contingency planning for that if things go wrong. And also, making sure that someone's owning a risk, and and prioritizing correctly. You have to evaluate the risk on likelihood and impact. No point worrying about issues that won't don't need immediate attention, but at the same time, you know, if they're big enough, at some point, they may become due. And if you don't have a plan for them, then you could find your Project, spinning way off course. So you need to and I think also the biggest risk is when you're not clear on what's needed.

Dante Healy [00:17:41]:

So if your requirements aren't clear, you need to or if you're running the whole project based on assumptions that haven't been validated, then you need to eliminate that risk either through analysis or, or more stakeholder communication to get clarity. Usually, it's the end customer. If you're if you're facing a trade off decision, then you need to make sure that that is agreed upfront. And then you can, you know, the team can proceed with confidence. Anything else from your side, John?

John Byrne [00:18:15]:

The only thing I'd suggest is that people are doing, you know, sometimes we can get a little bit too into the theory of it. And so with the stakeholders, with the communications, we do our stakeholder mapping piece and and, you know, the razors and all the the razors and all the rest of it. But don't just rely on that. Actually, talk to the stakeholders and tell them where you put them and make sure that they're happy to be there. Because if you if if you put them somewhere they're not expecting to be, that they don't want to be, and you start communicating them in that way, and they then are are having to come back because they wanted more, that causes problems because they kind of then don't trust you quite enough from the beginning. So while you're in your planning stage and you're putting together your stakeholder mapping of that, talk to the stakeholders, tell them where you've put them, and make sure they're happy to be there. Mhmm. That way then you've started off on the right foot, which means they trust what you're communicating because they've agreed in advance rather than them realizing, oh, I thought I was going to get different information to what you're giving me here.

John Byrne [00:19:20]:

I don't now trust you anymore, and I'm going to be much more hands on with this project and tell you every day. Yeah. You know, that's one thing. So that that's the kind of bit of advice I would give to people for that area there. It is, don't just rely on the theory of sitting down and doing it, you know, on your computer real conversing, tell them the stakeholders where you put them, why you put them there, and make sure they're happy to be there, and and what level of information you're planning and giving them.

Dante Healy [00:19:48]:

Yeah. And a lot of the time, a lot of communication with stakeholders is about managing requests. So and also, managing expectations is the most is the largest thing, because a lot of the time you need to have good change control. And so if someone adds or or proposes an ad to your project, you you may they may be so senior that you can't outright say no, but you have to kind of manage it. And, one of the things I say is, I'll put it to the team and see what what's possible. And then, you know, we can discuss it and say, well, what would we have to either drop? Or do we need to ask for extra resource? And how much would that cost in order to deliver that additional Master? Then you go back and say, you can either fund it, or you can do with lesser something else. So so again, change control is really around, making sure there's no surprises. The worst thing you can do is be vague.

Dante Healy [00:21:01]:

So it's it's if you can't answer then and there, just take it away. Say we need to make an assessment to see if it's possible.

John Byrne [00:21:09]:

Yep. And that that that regard there, I would say even if you think you can answer that and then, you still say, I'll take it away and see what's possible because you might not be missing you might be missing something that you didn't realize. And then when you go through your team, somebody on the team says, oh, yeah. But at that stage, then you've already promised the person that, oh, yeah. This is no problem. And never never agree in the sport at the moment. Make them go through the change request. You know what? How small the change is.

John Byrne [00:21:38]:

Have a have a clear process and make it go through it because that will just force you then to check and double check that what they're asking for is actually as small as you think there is and that there isn't some on notice on top of, problem.

Dante Healy [00:21:51]:

Yeah. Because you lose credibility if you promise Scheduling, and then say, actually, we can't give it to you. And, actually, adding to that, the other thing is when you're overloaded, the project, what happens is it becomes a vicious cycle because the project team will be tempted to cut corners. And then quality becomes an issue, which if it's the wrong corner you've cut, it will compound an issue, because the team will have to go back and fix it when they should be doing something else in the project. And coming back to that buffer, if you have no buffer, then you're in trouble, because you're already behind. And you'll end up either crashing the team and burning them out to deliver. In which case, they'll need some time to recover from that from that, that massive boost of effort. Or you're going to you're gonna run out of runway and find that you've you've you've finished the Project, and it's only partially complete against all of the things you promised to deliver.

John Byrne [00:22:58]:

Yeah. And then, and the yeah. Your other issue as well is that if you constantly are if you're constantly promising things and, without checking with your team, then you're adding to that porno with your team. Yeah. And they lose trust in you. And if they lose if your team lose trust in you, that's gonna exasperate everything else that that, you've just mentioned there about quality and cutting corners and that. If they don't trust you, if they don't kind of think that you you have their best interest in that, of course, they're gonna cook corners, and they're not gonna tell you what corners they got there. Just cut them bigger when you won't notice.

John Byrne [00:23:31]:

And you won't, until you realize at the end of the project that, oh, this is not working the way it was supposed to. How come?

Dante Healy [00:23:37]:

Oh, well, you'll see it immediately Master if you're if you've got any sense of, awareness because the morale will drop and you'll feel it. It'll be quite and harder. It'll become progressively harder to ask for additional things.

John Byrne [00:23:52]:

Yeah. Yeah. Yeah. We kinda get in push back for every little thing that you ask. And and the reason for that generally is they've lost Project. They've lost trust in you because you're you're you you haven't been

Dante Healy [00:24:03]:

They'll manage you. They'll end up managing you by saying no to you.

John Byrne [00:24:07]:

That's it. And and that's fair enough, you know, if you've been making if you haven't got a clear change request, a change process, it means they're not getting a say in it. You're agreeing to things that you shouldn't be and and yeah. That's, and that's where, again, your plan falls down. And I remember how good your plan was at the Planning. You've just destroyed your own plan by doing this. So, you know, and and and there are times that we we, you know, we've all faced that where even it's not a request. It's an instruction.

Dante Healy [00:24:36]:

Yeah. You don't have a say. Yeah. They're so senior. It's like you do this or you we'll find someone who will do it for you.

John Byrne [00:24:44]:

That's it. But but then even in a situation like that, you say, okay. But we still have to go through the the change process because we need to reevaluate what we've cushions are. Talk to your team. They'll understand that you tell them, look, this is happening whether we like it or not. But we need to know what the risks are, what, you know, what's going on.

Dante Healy [00:25:00]:

What what do we drop in place of that? And that's the risk is you're gonna you're gonna accept that you can't do everything at the same time. If if someone's that senior, but they can't prioritize, you're gonna have to prioritize for them. And if the risk comes, you can always say, well, we did warn them.

John Byrne [00:25:19]:

Yeah. Exactly. That that's all you can do. And and at least then as well, you you by by putting that in the risk and communicating that back up the line, you maintain a bit of, of the respect and the trust of your team because they can see, well, you are powerless to go out and to stop it, but you did at least try to fight their corner for them and and, you know, may Project them.

Dante Healy [00:25:43]:

And you at least, you communicated back what the risk was. So and and that's ultimately what a professional should be doing. They should be able to say, well, this is what's gonna happen if you're gonna do these things. They should be able to anticipate reasonably, accurately what's gonna happen.

John Byrne [00:26:03]:

Yeah. And and that is a key thing to project management. Project management does not necessarily overcoming issues and problems. It's it's a lot of it is just making sure people were aware that these things can happen and have noticed that, oh, it's it's going to happen. You know, what what the likelihood is. Sometimes there is no way around it. You know? It's it's just the project is not going to deliver the full scope or it's going to be late or it's going to be over budget. There was nothing you could have done about it.

John Byrne [00:26:31]:

No amount of management was going to do it. But you communicated what was going to happen well in advance so that it wasn't a shock to anybody, and they could make the decision to scale back them. You know? Okay. We're not going to reach the scope that we wanted. So at least then let's pick what are we going to reach, and let's leave out the bits you know, let's do it in a planned way, not just relying on chance.

Dante Healy [00:26:55]:

Yeah. You're managing. I mean, the leadership piece is going back to your team when they're progressing well. You say great job. But when you're managing, you're having to say to people outside of the project, this is what where we are. This is what could go wrong. And if they're asking for over and above, you have to say, well, these are the implications. What you introduce when you're when you're adding scope without adding necessarily resource or time is your increasing risk that things won't go to plan.

Dante Healy [00:27:29]:

Yeah. So great. And I guess in terms of the final topic, it's, you know, you you develop you start out with a plan. You develop it. You put some analysis. But, what happens if the plan is looking like it's not going to deliver any strategic value? And so you're thinking, well, the assumptions were this, but we now look like, we're it's not gonna happen. So how do you how do you align delivery to business impact, outside of the normal project of project management responsibilities of controlling the budget, ensuring you have the right methodology and right governance. What what other things, should a project manager be responsible for to make sure that the purpose is met?

John Byrne [00:28:27]:

Well, again, I think we may have mentioned this before on, I think the the business case. That should be constantly getting reviewed. Does it still make sense? Does it still have changes, you know, happens that make your your Project?

Dante Healy [00:28:44]:

The benefit assumptions mainly because you know your costs. Your costs are kind of predictable, but the benefits are assumptions, aren't they?

John Byrne [00:28:53]:

That's it. And and things change, especially on big projects.

Dante Healy [00:28:57]:

Yeah.

John Byrne [00:28:57]:

Things change. You know, you're putting in this great system that can do all this stuff or and you've got 50% of it in or or you've got 80% of it in. I know you've got one more module to do and you'll be complete. But when you do your your, you know, reassess the business case, you realize, actually, that new module that you're gonna have to spend an awful lot of time, money, and effort putting in is now covered by this other system because they upgraded another system on a separate Project, and it actually has an overlap and does what you you need. Okay. Well, then our business case no longer makes sense because we've got the benefits already of what we were going to do. So all we'd be really doing for this is duplicating some another system and the cost that goes through. So you cancel it.

John Byrne [00:29:40]:

You know, that's not a failed project. That is a very successful project. It means you've got the maximum benefits per cost that you could possibly get by cutting out something that was no longer going to to be of benefit. And now, admittedly, that that's rare. But I have seen that happen. I've, I I I've seen, I I've worked on a project where we weren't the ones who canceled. We were the ones who put something in that made another project part, obsolete. It it was that they were working on an ERP.

John Byrne [00:30:12]:

We were working on an EPM, and we put in the full on the the full on, reporting module in the EPM because it was part of our Project it was on. And the project manager and ERP, they had, it was different types of reports, but they had reports on theirs. When they were doing the the business, case review before they got to Planning in their reports, They came over to have a look at our system and see what reports we were doing. They said, well, actually, we we haven't put in the same reports they put in, but the reports they were putting in that they were gonna create on their system were actually just standard out of the box reports on our system. So there's no point in them putting all that effort into designing reports that they could because the two systems were linked. So it's just, hey, if you want

Dante Healy [00:30:56]:

That was a great catch though because you avoided cost, unnecessary duplication.

John Byrne [00:31:01]:

Exactly, Anna. It was very, like, now it was the other project Management did that because I didn't know what his project was was doing. We we but we we did know we did see on part of it, they were doing reports. And that was why I reached out to him and said, listen. We've got a reporting tech stack here that we've put in. It was part of our thing. I know you're not doing those reports, but before you start on on yours, just make sure that, you know, there wasn't and he came and he had a look. He went into the system and he canceled his reporting thing as as a result of that, his reporting module.

John Byrne [00:31:34]:

I I, you know, I I just flagged up. All I flagged up to him was the fact that we had a reporting module and put it in. He did the walk down to realize and that his business case no longer made sense. And he was a very good project manager because he called that out. You know, a lot of project managers would be afraid. They they they'd say, no. No. That you know, it makes my project smaller, and and the big project makes me more important.

John Byrne [00:31:54]:

But he says, no. That's it. You know, this is a complete waste of our time to do this because they have it out of the box on their system. They there was no duplication of work. Our project our reports were completely different to theirs. What we were designing was completely different to what he was going to design. But our out of the box, that that module just had out of the box reports that, weren't good enough for what we were doing, but we're actually exactly why he was about to strike the design for the ERP. And so, you know, doing that is is a big thing.

Dante Healy [00:32:24]:

And I think that hits on a a an excellent point is avoiding planning in isolation. Be aware that a business is larger than your immediate domain. I've seen I've seen sorry. Hold on.

John Byrne [00:32:37]:

Just wanna say, keep an eye on what's going on because one of the the problems was his project started before ours. So when he designed that and had the, module with the reports in place, it was fine because he needed it. There was no other system. We started their project then afterwards. I had seen that they had a project team, but we've done the the thing and the the the the reports were completely different. They serve different, audiences. They were for different purposes. So there even at that stage, there wasn't any overlap.

John Byrne [00:33:08]:

And it was just as I got walking with, with the module that did the reports, I realized, oh, but there's a whole load of, out of the box reports here, and they sound very similar to what the others were doing. And that's why I just flagged up, said, and just make sure or pay attention to this. Sorry. It's it. But he was perfectly right with his planning even because at the time he did the planning, our project didn't exist. Mhmm. So, you know, it's it's not even a matter of when you're planning to be doing it. He constantly keeping an eye on what's going on around you throughout the project because another project starts up has just made part of your project obsolete.

Dante Healy [00:33:43]:

Yeah. Exactly. It's vigilance, and don't don't feel like because your project didn't reflect the end state and reality, because reality is in flux all the time. Similar to me, I, I started a project early on, to automate some finance processes. Operations made some changes when we were mid midway through Management, and so we had to cancel those changes because they were irrelevant. Shutting down, products and service offerings that we didn't need to automate the, the back end accounting for. And even even, things like this is where you get to, see what happens when you do a pan European Project, is you see the efficiencies, that are dressed up. Because what you'll find is that with transformation, there's an element of accepting some minor inefficiencies in components to get the whole over the whole much more efficient.

Dante Healy [00:34:52]:

And there were some locations that deviated from the the business operating model, but the pieces that they had in their finance department were were highly automated, because they had internal systems experts that could just write a piece of code, and then suddenly it was all all singing and all dancing. But then when you when you transfer from their local system to the corporate system to automate that same Project, it was it was gonna cost $10,000, and the saving was about €400 a year. And we we said, well, let's just take the 400 per year and work on, removing that that product or service that was costing us that to administer. Yeah. Yeah. And in that case, that was a payables process where they were they were scrambling to pay early to get early payment discounts. And they were claiming those back as savings.

John Byrne [00:36:01]:

Yeah. I suppose it's a it is. It's savings. It's savings. That's a it's a benefit.

Dante Healy [00:36:05]:

Yeah. Yeah. But yeah. But if you're gonna if you're gonna introduce that functionality into a system that pays only when it's due, It's crazy. But yeah. Yeah. So I guess that's that's, that's that's a great point. And, it is about coming back to a vigilance.

Dante Healy [00:36:29]:

But, do you find anything else that would capture that besides communication, besides being alert? Usually, Project governance wouldn't capture it. If it's project governance in isolation, you need either a program governance or a strong, strong person who's got the overview of the business, and all of the change initiatives, and can connect the dots to see what what could be impacted. Right? Because you find, especially Project managers who are brought brought in externally, they'll struggle to maybe make the connections.

John Byrne [00:37:08]:

Yeah. And especially project managers who who don't know you know, there there can be a habit of project managers being just project managers, and they don't necessarily know the systems that they're putting in. They just know how to put in a system.

Dante Healy [00:37:26]:

I think They just Management schedule. They're experts in Microsoft Project. They can give you a perfect list of tasks, connect them, schedule, like, put in the dependencies. If you find a a task is delayed, it will automatically update the Gantt chart and push out that timeline.

John Byrne [00:37:47]:

Exactly. That they, you know, they're they're not subject matter experts, and they're and that's right. I mean, Project Management not supposed to be a subject matter expert, but it does help to have, an overview of the Project. Even if you're not the the detailed expert that at least have their

Dante Healy [00:38:04]:

You mean domain expert? Because as a schedule a schedule manage schedule professional or whatever project manager, they are experts in that or whatever project management tool they Yeah.

John Byrne [00:38:15]:

But they they they they're

Dante Healy [00:38:16]:

not domain experts. But they're not in specifically to business or logistics or whatever project they're on.

John Byrne [00:38:22]:

But I do think it helps to for for a project manager to have a good set a good knowledge. I mean, it's like the two of us, you know, what projects do we work on? We work on finance transformation projects because we come from a finance background. Yeah. You know, and we have a we we've grown we've we've developed a fair bit of, IT stuff. I would not fancy being a project manager on a, you know, a big construction project. I wouldn't even attempt it because I simply don't know anything about construction. In theory

Dante Healy [00:38:53]:

I do. Builders are bloody hard to convince. You know, you need a really strong, it's a different culture because they come from that working background. It's very manual labor. They have a different mindset that, say, a white collar professional wouldn't.

John Byrne [00:39:13]:

It has a different

Dante Healy [00:39:13]:

sense of humor. It's kind of not.

John Byrne [00:39:16]:

Even though it's it's the technical pieces, you know, you you you you kind of it it's good to have an idea. Now I'm not saying that, you know, so an IT professional can't ever be involved in a finance transformation. They can, but I think if that's where your background comes from as a project manager, you will get better to I think you're you're almost better to try and focus on a particular aspect of type of project that you work on to it it just yeah. You have knowledge of of what to expect, what can go wrong. You know? I don't know what can go wrong in a construction project. I don't know what can go wrong in a, you know, in IT programming for brand new piece of software Project. But in finance transformation project, I know what can go wrong because I worked in finance. I developed that, and I've got plenty of experience in in project Management them.

John Byrne [00:40:08]:

So, you know, be aware of that as a project Management if you are stepping into the a domain that you have no background in, you you basically you have to do an awful lot of research and get yourself a background in in order to be effective project manager. Otherwise, things will blind size you to you you know, thought of, you know, so so that would be the the other thing I I would say is just have a good knowledge of the domain you're in in even though technically Planning, a project manager is not Project matter expert in that domain. I I I not anymore, you know, finance transformation, but I would probably be a bit behind on latest standards, IFRS standards and stuff like that. Mhmm. But that's okay because I'm not doing accounting, but I have a good broad knowledge of that accounting, the finance If

Dante Healy [00:40:57]:

you studied them ten years ago, I dare say they haven't moved much since then.

John Byrne [00:41:01]:

Probably not.

Dante Healy [00:41:02]:

Let's face it. You know?

John Byrne [00:41:03]:

I can't remember what I studied about ten years ago.

Dante Healy [00:41:08]:

Oh, dear. Which one was the, the revenue recognition one? IFRS 15?

John Byrne [00:41:14]:

70 n, I think. Is it?

Dante Healy [00:41:15]:

Or 17?

John Byrne [00:41:16]:

Uh-huh. 16 is the Planning, the the the long term leasing. So I can't remember if the the revenue recognition come before or after. Yeah. But, I mean, the the the last big study thing I did was, the The U the Ireland and UK gap, which is a FRS one zero two. And since then, it's been updated, and there's an FRS one zero two a and an FRS one zero five as well. So even even I I'm out of date on them. Even though they don't update them often, they update them enough.

John Byrne [00:41:45]:

Yeah. But, again, I'm not subject matter expert in now. I don't need to to be the the other subject matter experts. But from a finance transformation piece, at least I know what would be involved in putting in a system to Management.

Dante Healy [00:42:00]:

Yeah. Yeah. Yeah. And you can look it up. I mean, Google it. And just for the reference record, IFRS 15 is revenue recognition.

John Byrne [00:42:08]:

Yeah. That's right. I think. What's seven there?

Dante Healy [00:42:11]:

17. It's insurance contract accounting.

John Byrne [00:42:14]:

Insurance. Yeah. Yeah.

Dante Healy [00:42:15]:

And and I I know about 15 because I implemented it, over ten years ago, which yeah. Anyway, yeah. And, coming back to the builders, it's it's completely different. And, again, I only happen to know because, working in a global organization who actually own their buildings rather than lease them, they were subject to a number of things. And I used to go out for coffee with this guy, and it was just coincidental. We'd both worked on some similar Project, and a lot of what he was talking around were, building permits, environmental permits, as much as blueprints, site layouts, dealing with contractors who were plumbers, builders, electricians, that sort of thing. And these are people who you have to be very you have to know pretty much what they're doing and and be able to assess whether it's, what they're quoting for is actually appropriate for the job at hand. So and as you say, if you've never built your own house, you're gonna struggle to understand what they've done.

John Byrne [00:43:30]:

Exactly. And and, you know, I just mean that as a general you do need to have as your subject matter expert in project management, not in the domain that you're doing, but you have to have an overview of the domain.

Dante Healy [00:43:41]:

You'd have to be able to assess, are you on track? Yeah. And also, if costs tend to spiral, which they can do, if they're not controlled, then, you have to be able to course correct.

John Byrne [00:43:55]:

Yeah. And different domains, different areas, you know, whether it's an IT, software, developments, whether it's finance transformation, whether it's a construction project, whether it's, any other type of Project, the research Project, you know, a a pharmaceuticals, you know, new medicine Project or whatever. They'll all have their own areas that you need to keep to be a little bit more aware of, you know, the the for for the for the the risks, for the, for the methodology even, you know, like, your you know, match your cadence to the risk. You don't you don't want to over engineer for small things, but you want to make sure you have enough controls in place for the big things, but you need to have a a a decent domain knowledge to know what what are the big things in this area and what are the small things that I can kind of, you know, Vonway. You don't need to be the subject matter expert as I've said, but you do need to to make sure you have a good knowledge of the domain if you're going to be a project manager in the in a project in that area.

Dante Healy [00:45:01]:

Yeah. Agreed. Common sense and being able to learn and pick up things quickly on the fly is a transferable skill, but context matters a lot. And for certain complex projects, having a background really helps.

John Byrne [00:45:18]:

Yeah. And ideal certainly, if you are planning to come into project management, come in in something that's that's your current background and spread out from there. But then when you are going into a project that's in a domain that you are not familiar with, get familiar with. Yeah. That's part of the Planning. The initial, you know, while you're putting together I mean, yeah, you actually do need to do it when you're putting together the project initiation documents and stuff like that.

Dante Healy [00:45:45]:

You need to

John Byrne [00:45:45]:

be aware of the domain then.

Dante Healy [00:45:47]:

And if you're if you're if you're going across to something completely different, be prepared to fail a lot until you get up to speed.

John Byrne [00:45:55]:

And put that down as one of the risks. Yeah. Now there's Because

Dante Healy [00:46:00]:

why, you know, obviously there's a growth opportunity. Say for example, I decide I wanna go into sustainability or logistics. I'm gonna have problems because I haven't been deep involved in operational logistics. I have, as an internal control manager, audited logistics. So I have a some idea, of, you know, things like, managing trucks, understanding, being able to understand that you need buffer stock, understanding supply routes, understanding alternative supplies, that sort of thing. Customs duties, you know, having goods in in in freight containers, that sort of thing, whilst they're getting clearances. But and that all takes time. Right? And you need to plan for that.

Dante Healy [00:46:50]:

But, where was I going with this? But, yeah. It's it's something that, again, if you're doing a logistics project, I'm not expecting to be the expert. And ideally, you need someone to you need to partner with someone who who can fill in those knowledge gaps and cover for you. And if you don't have that, you're gonna struggle. You're gonna be completely reliant on the team, and you won't be able to provide much more than just reporting.

John Byrne [00:47:22]:

And and that's but, you know, again, when you're doing your your initiation documents, your initial Planning, and and risks things, you're doing your project brief documents and that call that out. I mean, I I've done that. I've, I'm I'm I'm working on a project, that that you know, I was working on a project that required, public service, public sector, tendering. I'd never been involved in a public sector tendering process before, so I called that out as a risk. I have absolutely no idea how to put a tender together for that type of thing. So I don't know how long it's going to take us, but that will will take time before we can even start the project. So I called her out. It was a risk.

John Byrne [00:48:04]:

You know, it it it's not a weakness. It it well, I suppose it is weakness. I you know, there were people who probably have experience in that area who, could have done a better thing. They weren't going to get rid of me as a project manager because, like, I didn't know that. They knew that. I didn't know that from the beginning. But I called her out. It was a risk so that people are aware of that.

John Byrne [00:48:23]:

And actually then what they did when they seen that as a risk was they got somebody in a subject matter expert in that end to help us put together this hand.

Dante Healy [00:48:33]:

Brilliant. So thanks, John. That was a interesting discussion as always. So what are your top takeaways, reflecting on what we just got?

John Byrne [00:48:48]:

Well, I suppose that that Planning planning stage, if you if you you you do need to make sure that that plan is robust because it will go wrong. But if it's robust, you will be able to recover, to make changes to to, you know, call out risks from the beginning even if you are the risk. Don't be afraid to to call out, and keep it yeah. Just keep an eye on things that that you know, be aware when things are starting to knock up the plan. Be aware of it as quickly as possible because then even if you can't recover it, you can at least communicate to the right people that, okay. Here we go. This is this is going wrong. Here are the options.

John Byrne [00:49:36]:

And in reality, that's all you can do. You make your plan at the beginning, and then you just make sure that when the plan starts deviating, that you know what your options are, can it be recovered? Can it not be recovered? And if it can't be recovered, what are options that we can go to the the Project board and, say, well, what do you want to do?

Dante Healy [00:49:57]:

And, I guess, from my side, for me, it's really about there's no such thing as a perfect Planning, so allow for flexibility. And if you don't have the people, you don't have a plan at all, because you'll never deliver. And, if I'm going in for a top three, my final one would be never sacrifice quality, even if you're being pushed to adjust your scope or your timing. And, you know, adding either adding more scope because someone's asked you to squeeze something in, or you're being asked to deliver early. Because any technical debt, any corners you cut will eventually come back to bite you, I believe. In my experience, the biggest hack for efficiency is making sure you have the quality right, so you do a job only once and that's it.

John Byrne [00:50:54]:

Yeah. I agree with that. Thanks.

Dante Healy [00:50:58]:

Thanks, John. So great discussion as always. Thanks. Thank you very much, John. And, looking forward to our next discussion. Thanks, Dante.

John Byrne [00:51:08]:

Talk to you soon.

Dante Healy [00:51:10]:

Cheers.