EP78 Fireside Chat on the hidden risks of Cross-Project Dependencies and how to solve them

Dante Healy [00:00:00]:

Hello everyone. Welcome back to Business Breaks your project management Edge. I'm Dante Healy and This is episode 78. Today's Hot Topic hits right at the heart of what often goes wrong in delivery and that is project dependencies. We're not talking about task links inside a Gantt chart, we're talking about the messier stuff. So shared resources, misaligned timelines and overlapping scopes and dependencies between projects can quietly derail delivery if no one's keeping an eye on them. So to help make sense of it all, I'm joined by John Byrne and he's been in the trenches regarding managing programs where multiple projects need to stay in sync and where one misstep in one area can cause a pile up somewhere else. So John, it's great to have you here for this session and to just get things kick started.

Dante Healy [00:00:59]:

From your perspective, what are project dependencies?

John Byrne [00:01:03]:

Well, I suppose there are lots of different dependencies within the projects that you can do. So key ones I suppose can be, you know, within the single project you've task dependencies you can't do. You can't start milestone two until you hit milestone one, that type of thing. Some, sometimes they can run concurrently, but sometimes one builds on the other. But throughout the for a full project point of view, I suppose key dependencies can be resource dependencies that you know. So many of these projects that we do, we don't have the full time use of some of the key resources. We're sharing them with other, with business as usual, especially with business as usual projects I kind of work on but also with other projects and we have dependencies there. Will they come free when we need them? Because we're usually as a project, especially when it's business as usual resources, we aren't the important piece.

John Byrne [00:02:01]:

Their day job is the important piece. Then there can be, you know, other projects. You have a dependency on other projects. If you need feed in from other projects, whether it's information, whether it's people that they're working on them, wherever it is you, you may be left waiting on it. I mean that was a big problem that I had with a project. One, we, we delivered most of the project and then there was one, one last piece to be delivered where we had to create a system to bring in information. Data migration effectively. But was, that wasn't part of the project.

John Byrne [00:02:35]:

It was the project the data migration from into, into a new system. But we designed it and it was all done with a big dependency on another project which was actually going to create the information that we needed to then take and implement that other project ended up being about six months late. And so our project then was, was, was useless effectively we, we, we delivered and we were ready and waiting to go. We tested with, you know, with dummy data, but we weren't able to actually use the great system that we designed and implemented for a good six months. It's actually just a little bit more than six months. When the other project finally delivered where it was supposed to deliver, then everything worked freely. But for that six months our project was, may as well have not happened. So you know, stakeholder dependencies as well that you need approvals, you need things like that and key people will tend to be not available when you need them.

John Byrne [00:03:37]:

At times you're again, you're a project and no matter how big or important your project is, there'll be something else pulling their time and distracting them. Budgets as well. Money. You've got a dependency on the money even if it's been promised to you. Again, you're a project. There's business as usual going on. And if the business as usual needs the money or a bigger project comes along and needs the money, you may find yourself being tolls to cut costs somewhere along the lines. They're the main ones that pop off into my head.

John Byrne [00:04:04]:

How about yourself, Dante? Have you, what major dependencies have you come across in your projects?

Dante Healy [00:04:10]:

Well, you've hit on all the major ones. The only thing I'd add to yours, your list is budget dependency, especially if you're dealing with vendors. Sometimes you may find that there's a scope item that emerges but we haven't got funding for it for the work. And it could be like one developer for two months if you don't have the, if you can't pay them, you're not going to get the work done. So and, and that will. We'll get to buffer and contingency later on in the episode, I'm sure. And then just to expand upon task dependence, you also have this. When you're doing a waterfall project plan with all the detailed tasks sequencing and connections within the project itself is scheduled dependency.

Dante Healy [00:04:58]:

And this can also impact cross projects. If you've got all your projects on one project plan, you, you may get fancy with connecting the tasks themselves. When you're scheduling do you remember fs, ff, sf, those sort of relationships where for example FS is finished start where the preceding project has to finish before the following project a task has to start and then maybe you have even finish finish for example, where one project, one project task can't finish until another one has finished as well. So maybe there are components that need to be grouped together before the whole task can be considered done. So, so yeah, that's. Those are the two types of additional dependencies that I, I would bring out and a lot of it is really around. Yeah, as you see cross project, it's more tricky, right, because the inter project links are the biggest challenge for project managers, especially if they don't have direct line of sight of those dependencies. They're not accountable for them, but they need to track them.

Dante Healy [00:06:14]:

And for most project managers, they need to collaborate with hopefully other project managers who have the same level of scrutiny and discipline because the hidden nature of those dependencies are not obvious at first sight because as you mentioned, shared resources, you also have external vendors. You also may come across technical constraints and also regulatory requirements, especially if you're doing any project with any sort of legal tails to it, where the legalities of your specific circumstances still need to be thrashed out before you can identify what the appropriate approach is. And I think just in general, as you progress with your project, the project itself is subject to constant change. And that obviously puts challenge on your, you know, your constraints which involve scope, schedule, priorities and as well as funding. So how about yourself John? Do you find that's a challenge and probably you can elaborate on how do you overcome those communication gaps?

John Byrne [00:07:30]:

Yeah, it can be like that example I gave. You know, the project manager was, wasn't my project that we were waiting on. So that was, would have been ff that was finish, finish. We, we could start and we could do and we had our projects pretty much ready to go, but we couldn't, it wasn't, we couldn't roll it out until the other project finished. And yeah, it's that, that can be a challenge, especially because in that particular situation it wasn't just, just across projects actually across programs. They, they weren't part of the same program as us, which meant I wasn't even getting the program notes. You know, often like batches of projects that will have dependencies with each other, they usually be part of the same program of work. And so when you go to the program management office, they're getting the updates from everybody and they can make sure that everybody is aware of what's happening.

Dante Healy [00:08:24]:

And you know, the escalation line isn't so obvious.

John Byrne [00:08:28]:

Exactly. Wendell. When we were across programs it just, it was the way it worked out. We had already delivered our main project and this was like a little side project. Then they realized they needed but it started late and it was kind of in the wrong program. It was. Yeah, it was an awkward, difficult one for them to organize. I suppose the other procedure, actually, our project was in the right program.

John Byrne [00:08:52]:

The other project was in the wrong program. They just, at the time they started it, they were doing it for different reasons. And it was only late on they realized, oh, actually we also need that project to deliver for the program that I was working on. And. But yeah, it was difficult then to even get meetings with their project manager because they were trying to put out an awful lot of fires. So we were completely, you know, irrelevant to them. What we. At the fall was not what they were brought in to deliver.

John Byrne [00:09:20]:

They were focused on what they were brought in to deliver. We just happened to be also able to use that data for hours. And that was how it came across.

Dante Healy [00:09:27]:

You had no influence really whatsoever.

John Byrne [00:09:30]:

No influence whatsoever. And, and we were completely, you know, we, we were irrelevant to that project. That project was running into problems and they had their own things. We. So we were, we were kind of stealing a report. Not, not stealing. We. Our project was basically starting from a report that their project would create at the end.

John Byrne [00:09:52]:

But that wasn't their, Their main worries. Yeah, that report was just a. And they happened to have the data that could create that report when their project was done. So they weren't worried about giving us that report. They were worried about delivering the main project that they were trying to do. So, yeah, it was very difficult to get communications there and to get out. And in the end, there was nothing we could do. We just had to sit and wait and we had everything ready to go.

John Byrne [00:10:20]:

We, we tested as much as we could, and as it turned out, it was actually ready to go when we got live data into it. Eventually everything worked perfectly, but that was just, you know, good luck, really, because testing with dumb data, you can't ever really replicate live data. But yeah, sometimes you just have to be patient. There's. There's nothing you can do. There's no escalation, and I can't even help them because, you know, it was a completely different project doing completely different stuff.

Dante Healy [00:10:51]:

And that's the problem. I mean, you. You've documented it, you know what's happening. But if you can't influence any prioritization, there's no way you can bump it up or speed up the process. You just have to helplessly wait for the dependency and just make sure that when it's. As soon as it's ready, you're able to act on it.

John Byrne [00:11:10]:

Yeah. And there's nothing more frustrating as a. Well, I suppose there are a few things we could come up with. You know, a lot of examples of really frustrating things are being a project manager, but that is a very frustrating one and it's a relatively frequent one as well. Although I think that example that I have was an extreme example because normally a project that you're dependent on will probably will be part of the same program of work that you're doing. So there will be some way of escalating it or, you know, even if there's no way of escalating it, you at least know what's going to happen before it happens. You know, you know there's a delay. You know that this is not the priority, so you're just going to have to remember it.

John Byrne [00:11:55]:

Whereas we didn't even get that information. We were, you know, we got told that there was a delay the day after we were waiting to go live. You know, we didn't get the information. We had to go chase them and then be told, well, now we're about two months behind, so we have another two months to go. And then two months later they were still behind. And it was. But we weren't even getting notified. And we were in aftershock, actually, we weren't in aftershot.

Dante Healy [00:12:22]:

You weren't even in their line of sight, which is really painful. And I guess, you know, it's moving on because, yes, we've shared what dependencies are and why they're so challenging. But I guess recognizing the dependency is only half the battle. If we can go into more of the people side and communication roles as well as the team dynamics can make or break how dependencies play out across projects. Have you got any good stories about how that's happened or what are your thoughts around that, that element of it?

John Byrne [00:13:02]:

Well, suppose, you know, one of the problems with that particular, with that particular example, I'll just, I'll go back to is there was a lot. One of the reasons why the decision was made higher up to do, do it the way we did it, that we take a report from them and from their project was because there they had been overly optimistic when they were going to be able to deliver their project. This. So their communications weren't exactly. Well, they weren't communicating with us at all, but they're even their communications within their own program up to the, you know, sponsors. I don't know if they just completely underestimated the walk they were taken on or if they just didn't feel comfortable giving bad news to Very senior people and, but they, they didn't communicate it well. They, they were overly optimistic and they were overly optimistic at every step of the way and not just at the beginning giving, you know, the thing. But even as I said, we, when we finally got that forced notification that it was going to be delayed by two months, it was delayed by six months in the end, you know what I mean? So even they, they, even when they realized they weren't able to hit targets, they still underestimated what those targets would be.

John Byrne [00:14:23]:

So now I don't think, I think that the project manager in charge was actually a very experienced project manager and probably one of their worst projects. If you were ever interviewing them, they'd probably be given the same example as their biggest. You know, it wasn't a failure of a project. They eventually delivered what was needed, but it was a bit of a mess and I think they inherited it from a previous, you know, project manager. So they were effectively relying on a lot of documentation that was given to them. But yeah, so that, that can be a big problem with communications and you trust the timelines you're being given. And then also you, you've, you've got every problem that can run into on your project. If you're dependent on another project, you've doubled it because all the problems that can happen on your project and also happen on that other project, somebody, a key state, the, you know, subject matter expert lives, you know, they leave your project, you're in trouble but if they leave that other project, you're in trouble, even though it's nothing to do with you.

John Byrne [00:15:23]:

But, and I think that happened as well. There seemed to be a lot of turnover on that example of the people, not necessarily the project team. There was a bit of turnover on the project team. As I said, even the project manager was a replacement of a previous project manager within the business as usual area as well. There was a lot of going over at the time causing them problems. Didn't cause us any problems at all other than we did, you know. So it kind of, yeah, those dependencies, you're, you're, you're also. Every risk involved in your project is doubled because that same risk probably exists on the other project.

John Byrne [00:16:01]:

And, and you've, you've very rarely. You'll have the view of them unless they are part of your program. It's not like I could just pop in and look at their risk reg.

Dante Healy [00:16:09]:

And that.

John Byrne [00:16:11]:

It wasn't centrally sword, there was no access to it. So I actually had no clue what the hold looks where what potential hold up there could be. So I was completely in the dark on that part. Now, luckily enough, I wasn't being held accountable. Everybody knew on our project, everybody in our thing, they were also, you know, getting the news that I was getting at the same time I was getting it. So they were as frustrated as I was. But, but sometimes you're not that lucky. Sometimes you are the one being held accountable for something not completely outside your control.

Dante Healy [00:16:41]:

Yeah, and that's the problem with communication, or should I say poor communication, that you're at the mercy of inconsistent messaging, mismessaging last minute surprises. And you also brought up a good point about documentation here. You know, communication isn't just what you verbally say or write in an email. It's actually how you document all of the key elements of the project. Because if that's not there and it's not easily accessible or understandable to the people taking over, especially if you got handoffs, then you're in trouble. And I guess flipping it from poor communication to good communication, I mean we've all had great projects that seem to be seamless. Right. You're given the updates, people think about you and they let you know what they're doing that's relevant to you and they give you clear, clear status and you know, just regular touch points I find really works well.

Dante Healy [00:17:42]:

It's, it's really about transparency and also consistency in providing an update where we are with a dependency until it's needed.

John Byrne [00:17:52]:

Yeah, yeah, and I've had a few examples of that as well where you know, we, we were on a program work together and really early on in the process we had got a dependency on another project and I had a, you know, a request for a themes meeting with the project manager from the other project and she reached out to me to tell me that they had run into an issue. Um, by the time, then the following week it was all up on the program meeting thing. But when it popped up there, I was well aware of it. She'd briefly be on everything that was, you know, what her latest plans were, how she's going to walk around. So when they seen that that was delayed and she gave her report and they turned around on the meeting and they asked me what knock on effects does that have for my project? I was able to answer. I wasn't thrown. It wasn't the first time. So that was actually brilliant communication on her part.

John Byrne [00:18:43]:

Didn't just wait for the program meeting when she knew I would get the information there and that's what it was. Designed for. She reached out to me in advance, which meant I then had.

Dante Healy [00:18:54]:

You had, you had an appropriate plan.

John Byrne [00:18:57]:

I had an appropriate plan and I had it. I had it all. So when they asked me, I was able to tell them it'll actually have no major impact on our overall timelines because it just meant we would now focus on a different strand of our project. We had a multi strand project and one of those rounds were relying on horrors and we were going to deliver that internally within the project earlier. So we just juggled things around and as we said, so we'll delay on delivering that to that particular business as usual team but now we're going to prioritize these other things. So the overall project will still finish.

Dante Healy [00:19:28]:

On time, on budget and then just shuffle priorities around.

John Byrne [00:19:32]:

Exactly. We just had to shuffle. That was all it was. But had I not been made aware of what she was doing, I, you know, might have been caught on the hop and so, you know, you know, have to tell them, I don't know, I'm going to have to look at this book. He reached out and she communicated well and she communicated accurately as well. And she kept me up to date throughout the whole process that every time she made a change she, she notified me. And I'm sure she was notifying. There was a few other projects I think that were, you know, Ken and Don Har.

John Byrne [00:19:58]:

So she notified everybody. But she was an example of a very good project manager who made sure she knew who was dependent on her and she communicated to everybody when there was a problem. This is, this is what the repercussions are. And you walk around was able to, I don't think anybody else's project was delayed because of her delay because it's so early with them and they were able to do exactly like I did. They, they just juggle.

Dante Healy [00:20:21]:

Brilliant. And, and that's, that's, that's a great example of why it's important to have that constant communication and, and being clear about what's going on so that the stakeholders and you communicate early enough that they can do something about it. It's always really important. I guess the other thing, the other people element about dependencies which you listed was resources. And I guess the other piece to that is shared resources where it's one person's allocated to two projects and then you get the friction. There's this tug of war, the pool guide as two project managers, they have to deliver for. And if, if they're, if they're being, shall we say, chased on two priorities where they can't prioritize. They just have to try and figure out a way to deliver both on time.

Dante Healy [00:21:14]:

You risk I guess conflict and burnout on the poor resources that are done that are assigned to multiple projects. Have you seen that and have you seen any effective ways of dealing with it apart from the open communication and getting alignment on what's the pro. What's the real priority for that person?

John Byrne [00:21:35]:

Trying to think now has. Has it ever happened to me? I've worked with people who have been, you know obviously across different projects. Biggest. The biggest challenge I've always kind of had with. With that is more business as usual people rather than project people in on different projects that. But yeah I have come across. Have you had people allocated to my project who are also working on two or three other projects. They just happen to be very good at a specific task and you know we.

John Byrne [00:22:09]:

And when. When you have that. I think the project managers do need to talk to each other. The one example I'm kind of thinking of that they were allocated three different projects but they themselves were actually terrible at time management. They could not do it. Luckily enough we knew in advance that when we. When we got them because there. There had been issues on previous projects that luckily I wasn't part of.

John Byrne [00:22:36]:

Actually of the three project managers, one of them was part of previous projects and they reached out to the other two of us and said it right. One of them and not organize their own time. So if we need them for their three projects and as time's being divided between our three projects, we need to agree between ourselves how to allocate his time and tell them this is how it allocated. We cannot just rely on him to be. To be able to allocate his own time. And the three of us did have our own little mini subcommittee type of thing that we didn't do it through the program board. That was just getting too complicated. And you know the thing.

John Byrne [00:23:13]:

So just the three of us sat down, had our meetings, walked out when which of us would need them first, when we need them second, who would need them third? Would there be any overlap? Would there be actual concurrent needs? Various things like that. We worked all that out and we allocated this time. We told them right, this is how your time has been split between the three projects. And then we just had. We had continuous meetings once a week just to make sure that nobody was. Timelines weren't being swayed that related to him to that particular resource. He was a very important resource. He was the only one who knew we needed a bit of development work done in all our projects.

John Byrne [00:23:53]:

And I think it was specific. It was a piece of software and it was a specific. It was an old language that not everybody knew. It wasn't Java or something simple. It was, don't think it was Cobol, but it was something not everybody had a word. He was the only person who had that language that we all needed. And so that was what we'd done. Now, thankfully enough, none of us ran into any major issues on our projects.

John Byrne [00:24:16]:

So when we had these weekly meetings it was more just say, yeah, everything is still on schedule from my point of view. And the other two would say the same and we got away with it. But that would have been, that could have led to some. That was a situation that had potential, a lot of potential risk and it would have been a problem had that one other project manager not walked with this person in the past that we were suddenly discovering this person.

Dante Healy [00:24:38]:

Things weren't getting done that needed to be. Yeah, yeah. And that's always a challenge. You know, just highlights really that dependencies aren't necessarily technical. It's about people who are able to communicate and also resource wise work well. And so I guess it's being able to be proactive to avoid unnecessary headaches.

John Byrne [00:25:04]:

Yeah, I, but I do think though that the key thing is to realize that even with great communications and great foresight and all that doesn't necessarily mean that you will avoid the pitfalls of the dependency. You know, we worked together and we got it. But it would have been still possible if any of our projects had gone off so that we'd end up with issues with that tent that we both started, all three projects would need them at the exact same time or something. So and, and you know, even in the, the previous example I gave or the, the their project running six months late, even if that project manager had it been better at communicating, the only thing would have been that I'd have known very early on they're going to be six months late. It wouldn't have changed the fact that they were going to be six months late. But it just would have meant the, you know, the stress of the situation type of thing that am I getting it today? Am I not getting it today? And then two days later finding out no, we're running, you know, two months late and then it turning out to be six months later rather than two months that that would have all been avoided with better communication.

Dante Healy [00:26:06]:

Thanks John. I agree completely. So now that the human angle where is generally where most things go wrong, but also where we can resolve them quite quickly. However, soft skills and influencing only go so far. In terms of the mechanics like tools, timelines, techniques, what are the sort of simple things or shall we say the fundamental things that we need to do to keep them moving in terms of those, those systems and processes. What do you find works well for you in terms of tools and techniques? Specific tools like for example RAID logs, you know, risk.

John Byrne [00:26:52]:

Having them, having a session, having them visible to everybody is good. You know, a good program office or PMO will be able to, you know, have regular meetings with cross project teams that keep everything together. The tools, I suppose, you know, whether it's Excel, whether it's PowerPoint presentations, whether it's actually something product, project software, but that's being used to manage a series of projects together that you can see they all work. I think the main thing is visibility, to have some kind of a visual representation of where the different projects and where the dependencies are so that everybody is clear and whoever it is that's managing it. So you know, usually it'd be a PMO or somebody like that would be managing across them and in the case of the, that individual resource that we needed there was the three of us got together and did it ourselves.

Dante Healy [00:27:53]:

Or if it's a task that needs to be like a task which has an artifact or deliverable that you need in order to proceed, that's it.

John Byrne [00:28:02]:

But have some way of linking them visually. So you know, like Gantt Chart or something basic like that.

Dante Healy [00:28:08]:

Even like work streams where it shows like a critical path that says from this work stream you've got this and then you draw a line that connects the work stream to the task that you need.

John Byrne [00:28:20]:

Yeah, exactly. Something so that. And it's not even just from the point of view of so you can see what you need and is there a delay. But it's also, you know, if there are people who have dependencies on parts of my project, you know, if they have a dependency on my whole project, then that's, that's. I just have to look at the, make sure they have access to the timelines of my whole project. But if they've got dependencies on certain aspects of my project, it's not just so that they can see where those aspects are, but I need to see that they have dependencies on those aspects of my project that if I have to make decisions, I can't deliver everything that I wanted by such and such a date. What do I prioritize? Well, if I can clearly see, well a B And C, there's other projects that are dependent on me delivering them. Whereas D and F is just purely internal.

John Byrne [00:29:11]:

Okay, I can't deliver all six at the same time. But what I can do is I can get A, B and C prioritized so that I'm not holding the other projects. And so I think a lot of people, when they, when they are doing things like that, planning dependencies, it's the, the dependent project is, tends to be the one that has to look out for the other what's happening with the other projects and have no control over them. They just, you know, dependent and that's it. But it's not only them. I think the project managers of the project that's being depended on should also have clear visibility as to what parts of their project is going to feed into the other projects.

Dante Healy [00:29:47]:

Yeah, yeah. If they don't deliver their piece on time, what's the knock on effect? Because it can be a domino effect, you know, where a whole program is late because one work stream isn't able to deliver on time.

John Byrne [00:30:01]:

That's it. And it could even be a completely unnecessary. Like you know that, that was a hypothetical example. But in that hypothetical example we, our project delivers six things. A, B, C, D, E, F, A, B and C. Other projects are waiting on D and F. It's just purely internal. I've got resource constraints wherever a reason there is.

John Byrne [00:30:19]:

I can't deliver all six of them by the original timelines or quickly. Well, prioritize A, B and C of other projects are waiting on them because even if I do ED and F, my project is still not going to be delivered any quicker. We'll have the other three to do. But I've just delayed all those other projects and to know that sometimes the program, the PMO and the program don't cop that as as well, you know, or as clear to them because they've got so much to do. You're just one project and those other projects that are waiting are just one as well. It's done. So you're better off being aware of that yourself, you know, making sure. And the tools that do it are just nice clear visual tools, I think.

Dante Healy [00:30:59]:

Yeah, yeah. And it should be easy to check in and get a quick understanding of where you are and where with the risks of those dependencies. Because it's one key one thing. Keeping a live dependency register is another thing being able to review and quickly assess what does it mean, where is your project in terms of those dependencies? Because without the regular oversight it can easily slip And I think to address slippages as if you know it's going to happen, there are things you can do like inject a bit of buffer or even have a plan B where you may decide, well, if they don't deliver, maybe we have a workaround that plugs the gap until they do deliver, if it's at all possible. I don't know if you've had that. I've had it on a few projects where we just insert a manual process until the full integra. A full integration can happen.

John Byrne [00:32:02]:

Yeah, I've done that a few times. All right, you know, you're not getting the full integration, but you don't want to be waiting until that's possible. You just kind of give me a manual extract from your system and I'll create an ETL and just input this into Air Assist. It's not great, but it'll get the job done until we can do a better one. But just like with your dependency register, dependency log or wherever terminology you want to use, one of the problems I've often found with that is everybody does it from their own project's point of view. So I'm doing it, I'm saying, what my project is dependent on. People who I'm dependent on don't see my dependencies, so they don't know that I'm dependent on them and I'm waiting for it. That's, that's why I think an overall view of the, you know, at PMO level, clear view, nobody's going to read through that.

John Byrne [00:32:54]:

Even if you made those dependency registers available to everybody else, then they could see them all. Nobody's going into somebody else's project to read through. Then to see my project, are they dependent on me in any way? They need to be told out, right? And even being told, if it's just you're sending an email to them saying, look, let me know about and delays your project because I'm dependent on it. They'll forget when, when push comes to show if it's not going to be top. You know, they're in a panic situation as the problem's gone with their project. They've forgotten all about you. And so I think clear diagram, clear something that's clearly, visually easily done, that can be just put up at every PMO meeting once a week or whatever. Just reinforces to the, the people who's dependent on you, not just who are you dependent on.

John Byrne [00:33:42]:

A lot of project managers tend to just focus on who they're dependent on. They, they, they forget about People upstream that are dependent on them, which is.

Dante Healy [00:33:49]:

A bit sloppy for a project manager because project other projects can be stakeholders as well.

John Byrne [00:33:56]:

Yeah.

Dante Healy [00:33:56]:

And you've just missed a big stakeholder, especially if it's at the program level, is going to have an impact.

John Byrne [00:34:02]:

Yeah, it's a common thing that I, you know, you kind of say it is a. A big flaw in the project, but it's a very common big flaw that they. Unless somebody has specifically told them that they have a dependency, they won't think of it. And even if they have specifically told them, if they told them way back, you know, six months ago when everything was going well, no problem and now something has gone wrong. Now they've forgotten all about what they were told then. So it just needs to be a constant reminder that, you know, this is coming up, this is coming up, this is coming up. It is one of those things that's a very individualistic thing. There's very few ways to automate the thing I think does come down to even when you have a system that could potentially do it, nobody puts the effort in.

John Byrne [00:34:46]:

It's just one of those things that can slip by an awful lot.

Dante Healy [00:34:50]:

I think it highlights really just to wrap up. This section is really about making sure you got the fundamentals covered correctly. Good processes, simple tools and awareness of who all your stakeholders are. Just to cut through that complexity, create routines that keep discipline and also make sure that you get the alignment from everyone who needs to be aligned. And then also the other element is the risk management and being able to proactively address potential issues rather than just reacting after the event. Which makes the whole process of project dependency management a lot more smoother and less stressful. You can avoid a lot of sleepless nights just by being a little bit thoughtful up front. Thanks.

John Byrne [00:35:49]:

I think that's. And that's a key one as well. You've kind of. You've said it a couple of times now with examples I gave. It's the early communication is the big thing. I think we've discussed it before on another episode about, you know, your things like your. Your for your risks and your issues and that the rag thing that things going from green to red that they've skipped the yellow piece.

Dante Healy [00:36:13]:

Yeah, yeah.

John Byrne [00:36:14]:

It'll or am or wherever you want to do it. That's bad because if it's gone straight to red, it means the problem is there now nobody's had a chance to plan around, you know, if you, if they had a dependency on you, at least if you gave plenty of notice and you allowed it to go to amber or yellow or whatever color you want to. Orange, whatever color you want to use. It's giving them a heads up. And so like that example where the other project manager reached out to me and she gave you the heads up plenty of time. It meant I was able to plan around and reschedule and reprioritize. So had no impact whatsoever on the overall timelines of my project. And that's only possible when people are willing to admit there is a risk.

John Byrne [00:36:57]:

And the risk is more likely.

Dante Healy [00:37:00]:

Yeah, yeah. And start having that those discussions about slip timings. Because slip timings doesn't necessarily mean the project is red or even amber. You know, if you can reorganize, you have flexibility. You're just flipping the how and exactly when in sequence things are getting delivered. So that's. And you're accommodating to reality, which is good.

John Byrne [00:37:26]:

But you do need to like luckily enough in that situation she was looking, you know, when type of thing to. To my project and to a couple of other projects that were reliant on her. Luckily enough in my project there was only one other project that was dependent on mine and that was another one of my projects. My actually when I was able to reschedule all the internals were out acting anybody else. But you do need to think about that as well that when you've got this bad news and you need to reschedule, reprioritize your internals. Is there somebody else who's dependent on you that needs that communication stuff forward to them as well that you know, don't let it just die with you and, and look after your own thing. Do tell the rest of the, you know who else might be impacted further on in our project. As I said, in that situation the only other project that was dependent was mine as well.

John Byrne [00:38:19]:

So do both projects handily off. And as it turned out that other project didn't need, you know, just my prioritization that it actually meant I could deliver that other project a little earlier because one of the prioritizations brought its dependency forward and going so that, you know, they're bringing for me all around.

Dante Healy [00:38:41]:

Yeah. And even when you have the fundamentals covered, you still need that vigilance. Right. Because projects change, priorities shift and dependencies themselves don't stand still. So then that question becomes how do we stay ahead of the change and how do we know we're doing a good job in terms of managing those connections? I mean what's, what's your thoughts on that, John?

John Byrne [00:39:08]:

That can be, that can be a tough one as well. Thankfully it didn't happen to me. We're in that same program of work. There was, there were a couple of other projects and one of them got cancelled for whatever reason, deemed not unnecessary. We don't need this anymore. But there was another project that had a huge dependency on one of the deliverables from that canceled project. They were then left in a real panic how you know, we needed this and it's no longer going to be delivered. How are we doing it? No matter how well planned you are, something will, will, will.

John Byrne [00:39:44]:

But now in the end they ended up having to do a scope change for their project and they had to create the deliverable from the cancel project for themselves. That was the only way around it that sometimes, you know, all the great communication, all the knowledge in the world will still not help you because you're.

Dante Healy [00:40:03]:

Not working in isolation and things will always change, you know. Recently we had an issue where due to a policy change by our digital security team, it meant that we had to quadruple our overhead in terms of not just doing attestations but renewing our security credentials. And this went from once every year to now every month. So you imagine how much additional overhead that involves just because of security. And also from their side, if people don't renew, then they have infrastructure that they don't really need because they're not using it if they don't need to renew it. So it puts pressure on everyone else who does need their infrastructure. So it's those sort of things on top of the additional pressures of constant delivery. So I think even through no fault of your own, rules change, the game changes all the time.

Dante Healy [00:41:08]:

And so that, that in itself is a dependency that you might not necessarily be tracking. And the stakeholder isn't. You're not a direct stakeholder. You're just, what would you call it, almost collateral damage. Because everyone else is feeling the pain.

John Byrne [00:41:24]:

Like that, you know, canceled project and you've got a dependency on another project. You're, you're very rarely put down. If this project is canceled, you're assuming the project delivered. It just might be late and you might have all the contingency built in around it being late. But whereas that other project manager, when the project manager previous project got canceled on him, he now suddenly there was no contingency he could have. He was not getting something that he needed for his project. And the only way around it was then a scope change for his project to develop the, the thing he that did the previous Project. The canceled project was going to deliver.

John Byrne [00:41:57]:

Now, it was obviously going to deliver a lot more than just that one thing. So it was still a canceled project, but it just meant that one thing had to be brought in. But it was a big thing. It was, you know, a bit similar to, to the example I gave earlier with my project. That was panic on one that was running six months late. If they decided to cancel that project, well, I still need that report from it, so I need to develop that report myself as part of my project. Now, suddenly it's a big scope change. It's no longer just a delay.

John Byrne [00:42:27]:

And like in your case, there the.

Dante Healy [00:42:29]:

You suddenly have so an internal policy. It's not even a regulation change. But regulatory changes also impact projects as well, you know, and they're completely outside of the organization. But yeah, you can. Sometimes you just have to suck it up or absorb it, should I say? But yeah, I don't know if there's anything easy you can do apart from identify your stakeholders who are impacted and communicate to them as soon as possible. I was going to say communicate early, but in some cases it's not early because you haven't been given much notice yourself.

John Byrne [00:43:08]:

Yeah, ultimately, I think that that's one of the problems with dependencies. Generally speaking, the dependency is something that you have no control over. That's why you're dependent on it. If it's, if it's in your control, it's part of your project, it's, you know, just a normal risk thing. But when it's a dependency, it means usually you're gonna have to just suck her up when it goes wrong because you have no control. You are just a victim of circumstance.

Dante Healy [00:43:33]:

Yeah, you just have to hope you have enough resilience built into your project team to absorb the impact and also respond, you know, have enough sense to actually identify it soon enough that you can react quickly to it as needed. The last thing your team wants is the. You know, in an ideal world, everything's under your control and you can plan accordingly. If it succeeds or if it fails, it's on you. But when you have, as you mentioned, outside dependencies, outside forces that you have no control over, then you just really have to see that as a challenge it is and find solutions to address them. And I guess, you know, one thing is also, what do you learn from those dependencies to make yourself more resilient? Retrospectives or lessons learned? Do you document misdependencies as part of your, as part of your reflections? Or is it more just throughout the process, you have regular reviews and if it was that bad, you just, you just note it as this was a reason why we might have been late or might have delivered on time, but not as comfortably as we'd like.

John Byrne [00:44:52]:

Yeah, I think you do it. I think personally on a personal level you do need to, to record and recognize when you miss dependencies. You know, presumably if you missed it, it's going to be because you, you didn't, you didn't really put enough care and attention into your. Or else you just didn't realize how big of a dependency it was. But it tripped you up, it tripped, you weren't expecting. And then the other thing can be sometimes scale. I mean, you know, when you're listing out your, your, your risks and your dependencies and stuff like that, you tend not to, not to record things that would be considered huge. You know, you, you know, you, you know, clear risk for every project is that the company that you're, you're doing their project for goes bus.

John Byrne [00:45:43]:

But you're never going to put that down in the risk register. You know that that's, it's just not, it's too big of a thing. And that can be the problem with dependencies as well. Like, I can pretty much guarantee you that the, the, the, in that, that previous example where there was a cancel project, the dependency register, the risk Regency register had that. Yeah. Were reliant on this thing being delivered. This risk register did not have that. Well, that would.

John Byrne [00:46:05]:

A project to be cancelled. That was not something that was even, you know, it's. That other project will be late. Yes. But not canceled. And I think that can be a problem. Yeah. With the dependencies that you can miss them and you can overlook.

John Byrne [00:46:18]:

You can, you can underestimate how big of a dependency some things are or a lot of the time as well, a dependency. You spotted it, you knew it was there, the risk of it was there, but you just didn't consider it realistic.

Dante Healy [00:46:30]:

Yeah, I mean, at the end of the day, as you say, dependencies by their nature are dynamic and they do require constant attention and adjustment as the projects evolve. So, you know, ignore them at your peril. But to be fair to most project managers, they're not always top of mind because you have your own immediate team to focus on.

John Byrne [00:46:54]:

And I think though that's, that's the other thing with your dependency register, you know, that should also be a living document.

Dante Healy [00:47:02]:

Yeah.

John Byrne [00:47:03]:

Something you do at the beginning and then forget about. UA should be always keeping you never.

Dante Healy [00:47:07]:

Park anything you've listed there you need to continuously update it, add to it, take off it.

John Byrne [00:47:13]:

Yeah, exactly. And what I do see though, a lot of project managers, the only thing they'll do to update a dependency list is closed down a dependency, this has been delivered, we're no longer dependent on it, end of story. You rarely see them add a new dependency that they have to score. And it does happen. It happens. You know that, you know your dependency was basically a staff member, but you didn't really consider that a thing because at the start of your project you have full time use of that staff member. But now suddenly there's a new project started up and they're going to be getting some of their time taken onto that. Well, now suddenly you need to put down as your dependency because you don't have full time use of that staff member anymore.

John Byrne [00:47:54]:

They're not part of your project team anymore, they've been hijacked. So you know there's a change, clear change, and sometimes it could be just something that you missed, you didn't realize at the beginning, and it's just part way through your project you realize, oh, that can be nerve wracking for some project managers, especially early on in their career. They're afraid to add it because they feel it makes them look bad for missing it in the first place. No, it doesn't. Chances are none of your superiors read through it fully, so you can add it without them even copping that it's being added. But you know then, and you're keeping a record of it, and even if they did copy, they realized, oh, you've added that you found the new dependency fair play. At least you've already documented them.

Dante Healy [00:48:32]:

Hmm. And in fairness to those project managers that miss it, usually what happens is before you can even add it to a dependency list, it's already made the issues list, so forget it. By then it's already super visible and you don't have to worry about prioritization. I think that was everything. It's been a great discussion. So I guess to wrap up what we're saying is project dependencies, even though they're often deprioritized, they're not really a side issue and are actually central to whether, especially in large scale delivery, the work unravels or succeeds. So whether you're leading a program or juggling two connected projects, you still need that visibility, structure and solid relationships. So, John, big thanks to you for sharing your expertise and insights today.

Dante Healy [00:49:29]:

Anything else you'd like to add before we wrap up?

John Byrne [00:49:34]:

No, I think we covered everything. I mean, you know where you can. You have your resilience built in. You may just be able to juggle things around, but a lot of the time when it comes to dependencies, you are just in acceptance mode. It's communicating to other people that your dependency hasn't come true and you wanted it. But you know, by its nature, you usually don't have any control over a mercy. So be willing to accept that. Be a bit stoic about it when it happens.

John Byrne [00:50:02]:

Don't panic, don't get upset. Just do the best you can with the carries you're dealt at that time.

Dante Healy [00:50:08]:

Absolutely. And again, thank you very much, John. This was business breaks your project management edge. I'm Dante Healy and together with John Byrne. We will see you next time. Thank you again, John.

John Byrne [00:50:21]:

Thanks, Dante.