Dante Healy [00:00:00]:

Think about the last time your team ignored a lesson. What happened? Another blown budget, a project running late, the same mistake creeping back in. It happens more often than we'd like to admit because the lessons should stick, but they don't. So welcome to today's episode of Business Breaks. I'm Dante Healey. And together with my friend and cohost, John Byrne, we're tackling a frustrating truth that even the most experienced project teams repeat the same mistakes over again and again and again. So why is this? Is it a process problem, A fear of admitting failure? Or are lessons learned just a box ticking exercise that no one actually reads? In this episode, we'll break down why project knowledge keeps slipping through the cracks and what it's really costing organizations. Most importantly, how to make lessons learned stick.

Dante Healy [00:00:59]:

Because trust me, learning the hard way is expensive. So let's get into this. John, what's your experience? Have you seen a PMO or been in an organization where they have well documented lessons learned and you can just access a database somewhere for your type of project in order to see what things you should perhaps avoid or at least address upfront?

John Byrne [00:01:29]:

No. It's the, simple answer to that. Generally, with with the projects that I've worked on, the the lessons learned has been, almost a within the team. You know, as a project manager, you you go in and it's your own personal what you've come up against. Hopefully, you've learned from them, but I've I've I've I've never I've never gone into a project project. I'm being able to, read from the PMO a a simple, you know, examples of, as I said, either in the same type of project or just in the in the organization. You know, there could be something about the organization there. It's it's overly complex for communications or something.

John Byrne [00:02:10]:

But I've I've never actually gotten to and I've I've asked. Yeah. Now I have gone into projects at times where I've asked to see the business case and they haven't had a business case. So, you know, that's that's insane. Just overly surprising, but but I've never once in all the projects I've walked in where I have gone in as an external project manager to to step in and and do it. No one has a and some of these companies are big companies and have PMOs. They have a program management office. So there's not really any excuse for them not having not having the lessons learned available.

John Byrne [00:02:44]:

And some of them do have them, but, like, in in one of the last projects that I worked on, we put a lessons learned list together, and where it got saved was in our project folder in the in the cloud. Mhmm. That's not good to anybody else coming after us. You know, there's there was no central repository for lessons learned across all projects. You'd have to go into every individual project, and not everybody would have access to our project folder because it actually had to be saved in our project folder where, you know, there were limits to who would have access to it. So a future project manager on our project wouldn't know where to find it and wouldn't have access to it even if they did.

Dante Healy [00:03:22]:

That's crazy. Right? Yeah.

John Byrne [00:03:25]:

That's that's that's my experience. How about yourself? I know you kind of you you do them slightly differently to me and that you're kind of working for the same organization more often than than me. So have you found your way around it? Is it easy for somebody to find or or does it

Dante Healy [00:03:40]:

exist? The only organization where projects actually kept their lessons learned was actually in audit, where they had a central database. And it was basically an access database of all the audits going back several years. And it's and in essence, they they included documentation. So they, you know, internal control, internal audit are very regimented on how they document things. And there was a database section where you could query lessons learned on specific audits. So if we were reauditing a plan or even a process, you could actually reflect on those lessons learned, and that was useful. It was actually quite interesting in terms of things that they wish they'd done differently given the learning. A lot of it was really around getting as much information upfront from their databases in order to do sampling early.

Dante Healy [00:04:42]:

So you could sample in parallel whilst trying to understand the processes. So it was things like that. And then even more specific things like what hotels to book, like which ones were close to where you were auditing rather than other side of the city. So you spent you lost about a couple of hours every day travelling, so things like that. So, yeah, it's it's interesting. I I think in terms of PMO, whilst they provide templates, they're not really well regimented. They're also on Word and Excel, so there's no centralized database. Project managers will tend to pull from them, and they may submit things, but they're not easily extractable in terms of the knowledge because they're not on a single database or repository.

Dante Healy [00:05:30]:

Most PMOs don't actually have a strategic approach. All they seem to be is a almost a community of practice where they'll give you some guidance, but they're not they're not enforcing a standard approach to documentation. So, yeah, I find that a lot of like you, a lot of the the learning is on a personal level, whereas an individual project manager, you'll essentially come across a challenge or maybe even make a mistake, and then you'll learn from that. But it's not documented anywhere. So I think this is where the challenge is that organizations probably lose a lot of value because they don't they repeat the same mistakes, and, essentially, that becomes waste. Right? So, yeah, it's interesting. And I guess, to that extent, really, lessons don't stick. And to what extent they don't stick, it's probably because they're not documented.

Dante Healy [00:06:40]:

And whilst they may stick with individuals, they don't actually stick within the organization. Individuals will take that institutional knowledge with them. Now to be fair, there was one project where I I I took over midway through the project, and the project manager gave me his download, his brain dump of things that he he thought would be useful for me. And he had no, should we say, he had no benefit of trying to make me look bad, so I was pretty confident he was doing his best to give me all of the information that he thought was useful. But he was, he was being promoted to program manager, so that was the thing. So in in effect, I was reporting into him. But at the same time, there were things that he didn't he he probably didn't value as much and but he didn't tell me not because he was withholding things. I he was busy getting up to speed with his job.

Dante Healy [00:07:42]:

So running his job was trying to do a handover with me in parallel. And the other thing was it wasn't important. It wasn't things that he considered a challenge personally. But there were things that he took for granted, and you do invariably when you don't reflect or you're rushing on things. You don't have time to think. What could what could trip you up might be something that that person found relatively straightforward. Does that make sense?

John Byrne [00:08:15]:

Yeah. Yeah. And and I have noticed when you bring that up about the the rushing piece, I have noticed that with with projects and project managers and that as well. A lot of the time, the lessons learned is is done at the very end of the project. It's not done as as you go, which means, a, it's remembering on your it's relying on your memory. And, obviously, problems that came up near the end will get more prominence than stuff that happened at the beginning because you've forgotten about them if it's a long project. And, b, it's it's a rush job. It's just get something down quick because this this project is winding down on on another project I have to move on or, you know, the contract is up or or wherever it is.

John Byrne [00:08:55]:

So perhaps the the way it's done is, generally, when it is done, the way it's done is is is not great for capturing all these things because it's a rush job. And then, as you said, there's no central repository to put it all. So often it gets filed in that project specific folder.

Dante Healy [00:09:16]:

If it's not in their head if it's not in their head. Right? If it gets filed at all.

John Byrne [00:09:21]:

If it gets filed at all. Yeah. That's it's in a a place where no other project manager is going to now look.

Dante Healy [00:09:27]:

Yeah.

John Byrne [00:09:28]:

And then you do have, situations where kind of building on what you said that problem a a lesson for one person is not considered by the other person to be a lesson. But the, the other issue there as well is that people cannot sometimes I've I've seen people get too specific. You know? When when the the the one of the biggest problems with projects generally is they run over time and, you know, that that's planning. But I have seen people where, you know, a project ran late because somebody went on maternity leave. You go near the end of it. And their thing is, well, that's not a lesson learned that they have to worry about because what's the odds of that happening again? But then in their next project, they run late because somebody got in a car accident and they were important to the project. And, you know, they they won't put that down as a lesson learned because, well, what's the chances of that happening again? And then the next project is something else and something else and something else. And I think the the the problem there is that people are are being too narrow with what the lesson learned is.

John Byrne [00:10:36]:

The lesson learned is not that somebody could get pregnant or somebody could be in a car crash. The lesson learned is somebody important to your project could end up being off for several months or or whatever.

Dante Healy [00:10:48]:

And it's cover. It's a question of cover. Right? That's the risk.

John Byrne [00:10:52]:

That's the risk. And and that that's the lesson learned. But a lot of them won't recognize they they they as I said, they they're too focused on the specific problem, and therefore, there's no lesson to be learned from that specific problem rather than, well, no. You you take the step back and the overview, and that's your problem. So that your lesson learned is have cover and and, you know, build in a little bit of collateral for time to allow that cover because it's not gonna be a case of somebody disappears, somebody key to your project disappears, and the cover comes in and takes off. Even when that cover comes in, it's gonna take probably a a week or two for that person to be found. And then it's probably gonna take another couple of weeks for them to get up to speed.

Dante Healy [00:11:34]:

Yeah. I mean, that's the thing. You have to detach the individual failings from the systemic failings and try to avoid finger pointing or ignoring a systemic issue because you believe it could reflect badly on an individual.

John Byrne [00:11:53]:

Yeah. Or or but as I said, it's it's more in that particular example. It's more just a case of, you know, not being accepting that the the lessons learned should be kind of in buckets as opposed to in individual things. So, you know, that's not really passing blame on that somebody is gone, but it's just not to be assuming that, oh, well, for that nobody will be gone for that particular reason. You know, might not be it'll be a different reason, but there will be somebody in in any kind of a project that's gonna last six months or more. Chances are there's gonna be somebody key to your project who will end up gone or missing for a large chunk of it because they're sick, because they something has happened in their family, because they've got a better job somewhere else.

Dante Healy [00:12:34]:

Or even they they don't give enough notice when they go on plan leave. Maybe they had a plan in their head, but they didn't tell anyone and they didn't fill in the holiday calendar to say, I'm off for this period. And normally, you should ask, well, please plan ahead because these are the key dates where we want you to be here, such as testing prior to deployment, for example. And and, yeah, your key tester decides they wanna go on holiday. Because, funnily enough, it's summer holidays, and they're taking their family out. But no one thought to ask.

John Byrne [00:13:12]:

I know. And sometimes as well, it's it's it's it's something that, nobody taught to tell you something obvious because it was so obvious in a project that I did before. One of the key people in a particular module went off on maternity leave before we got to the the testing, and she was a very important person to our project. And we were kind of left stunned that this came out of nowhere, you know, that one week she was there, the next week she's gone. She's on maternity leave. Nobody told us, but it was their project was being run fully remote because it was during the lockdown. So it was a fully remote project. And just within the that particular, organization, when people went on Teams meetings or Zoom meetings or whatever, nobody had their cameras on.

John Byrne [00:13:55]:

So everybody everybody knew she was pregnant and would be going on on maternity in her department. But we in the project didn't know because we couldn't see her and nobody it was so obvious to everybody else. Nobody actually said, oh, so and so is gone on maternity leave. It was it was just like the week before when somebody said to her at the end of one of the meetings, best of luck when you go off a maternity leave next week. And that was the first we'd heard of it. But, you know, if we were in the office, if we were in person, it would have been blatantly obvious and we'd have had no one to make plans for it. But because we weren't, nobody's taught to tell us because everybody just assumed everybody knew.

Dante Healy [00:14:31]:

But in that instance, was there a was there a cover arranged, maternity cover, or was it just within the existing team?

John Byrne [00:14:39]:

Within the existing team in that particular case. So it was gonna be tough. Now having said that, our if if if we'd realized on what we ended up just simply doing was that we we just adjusted the timelines because it was it was one subpart of the overall project, so it didn't impact the delivery times of the overall project. We just took longer to deliver that particular piece. And and that's what we would have done in the first place because, we knew from another example, in that particular organization, when people left, they weren't being replaced. So we we would have known when she's gone, that that role is not getting filled again until she comes back. So that would have been how we'd have done that. But, you know, the lesson learned, again, we put into that particular thing was to check with everybody what their what their plans are, their their you know, if they've handed in notice already and it's public, let us know.

John Byrne [00:15:32]:

If there's something coming up, if they've got holidays or if they've got, you know, any kind of parental leave, let us know. And and to actually ask it, not to assume that somebody will tell you because they didn't think to tell us because it was so blatantly obvious to them because they'd seen her in person before.

Dante Healy [00:15:49]:

Mhmm.

John Byrne [00:15:50]:

Everything will promote, whereas we have never in person. So yeah. And I'm not sure if it would have even been obvious on a screen where you're just seeing kind of the shoulders and face. So, you know, it wasn't even just that everybody had their cameras turned off on the meetings. It was just that it's not something that you'll necessarily pick up on on an online thing. So well, again, we we put that in our lessons learned, and eventually when the project closed down, that lesson's learned was just the word documents that got filed in the project folder, never to be seen again.

Dante Healy [00:16:23]:

Yeah. And this is the problem, these, lessons learned. They don't get stored anywhere where they can be easily accessed. And I think that's a big shame because, certainly, on a financial level, there's this silent ROI, so return on investment. Actually, if you think about all of the project delays, all the budget overruns, you can think lessons learned will actually save a company money and time. And so there's a hidden cost to ignoring lessons learned. If your company had an extra, say, £2,000,000, for example, from avoiding repeat mistakes, where could you spend it or reinvest it in your portfolio? So, yeah, I think I think these sort of things, the hidden budget overruns, the the lack of precision, the fact that you have to put in buffer into your projects, maybe I think buffer is always important because estimates are always imprecise anyway, so best to be cautious rather than, you know, find out you run out of money and your project fails because you can't secure the funding. But it's really about avoiding avoiding unnecessary failure and inefficiency.

Dante Healy [00:17:41]:

Right? Because I think if you coming back to your example, if you'd known about that and had mitigated for that earlier, you could have avoided that potentially, that project overrun. And I've seen that where delayed go lives or delayed completions also delay the benefits of the projects that you're actually working on and implementing.

John Byrne [00:18:03]:

That was it. I mean, in in in that particular project, though, it was a very large project with lots of sub modules going live. Mhmm. But each one of those modules, I have worked in other projects where one of those modules would be a project in and of itself. So if that had been the that project, if that module had been the whole project, we would have ended up having to go over because there was, you know no. There was nothing we could do about it. They were down a very important person, but we could have at least that we'd known in advance plan for it and being able to tell the stair code, this is how long the project is. It's not a it's not a three month project.

John Byrne [00:18:37]:

It is a six month project because of the the lack of personnel. You know, but but, while we we didn't the overall project didn't run over because of that because, say, the older modules that we were moving on with, as you said, the the the opportunity cost the cost to that team of not being able to go live when we thought we would. No. We were never going to be able to go live when we thought we would. If we had been told in advance that, you know, the maternity leave was being taken by that person, we just would have haven't we just would have planned for a a project that was going a module that was going to last longer. In that situation, there was no mitigation there. They weren't replacing the person, so there was nothing else that we could do other than use the existing people. And they would take longer to do it because they weren't as skilled at the particular area as she was, and they and, you know, they were trying to pick up for Slack as well as continue their own and do their own testing.

John Byrne [00:19:31]:

So, you know, it is one of those things. But yeah. You know? But the the downside to that is that that lesson learned, it's in my head. And I know when I go to other projects now, you know, check with those things. But in that organization, it's it's gone. You know? That lesson there won't pick up anywhere because nobody will even think of looking in my project folder, my old project folder, unless they're going back to look at something without a project.

Dante Healy [00:19:58]:

And this is the thing. I mean, this is where institutional knowledge leaves with the people that were on the project. And, again, coming back to teams, I mean, even organizations when you make people redundant, people are your asset. Going off topic here slightly, but they take that institutional knowledge and expertise and experience of avoiding failure with them. So and you never get it unless you put it it somewhere where it can be easily accessed. And more importantly, people do access it.

John Byrne [00:20:34]:

And and I think that means, you know, as as part of a PMO or the PMO doesn't exist, even as part of a project, one of the things that should be set up is some kind of knowledge management system specifically for lessons learned on project management things that, you know, even if you're thinking, well, this is only a one off project. We'll never do another project again. Chances are, I know how small your organization is. You will end up doing another project again. And some lessons learned might be specific to particular pieces of software or whatever. But a lot of lessons learned are specific to organizations, organization culture, organization structure. In that old case, one of the things that was they they they moved fully remote because even after the lockdowns and that were lifted, they didn't come back. They're still fully remote now, and they still don't use cameras as a as a standard thing.

John Byrne [00:21:23]:

So, you know, that's that's a cultural thing within the organization that that lesson learned is important to that other people will probably even then, even if you can see them, I mean, that's assuming that it's it's the it's a it's a woman who can go on maternity leave. If it's if it's the father going paternity leave, there's no visible thing there, so you you have to think to ask. When that organization, you know, everybody was of an age where that is probably something that's we wouldn't be the only project that affected that type of thing affected.

Dante Healy [00:21:55]:

Yeah. And I think this is the thing. This is one of the key solutions. I think it's also as much cultural. The lessons learned have to be seen as a valuable process and practice. Otherwise, it just becomes a tick the box exercise, especially if people are putting them on Word documents that can't be reaccessed easily. So that's that's clearly not gonna motivate anyone to care about making sure that the content is easily understood, legible, and very and detailed enough so people will know enough not to repeat the same mistake. I think there's also very, I find that a lot of documents on Word are unnecessarily overcomplicated and onerous.

Dante Healy [00:22:41]:

You can end up with, say, I don't know, 50 to a hundred page document of a lot of minutiae, but not but you only want the highlights. You don't need to go into the detail. It's great to have it there for reference, but give me in one paragraph or a few sentences. What was the issue, why did it happen, and how would you avoid it? That's all you need to know, really. And, also, you find that there's various projects. And there are different types of projects, but they may have the same common themes in terms of what leads to failure. So silo siloed project teams may be within the same portfolio. One of the other things you find is that good project managers will understand the idea of interdependencies and liaise with other project managers.

Dante Healy [00:23:34]:

And as long as they communicate clearly with each other and let each other know if there's any changes to their planning or execution, that they can factor it into their own plans if it has an impact. So I don't know. I guess there's there's the behavioral element, and then there's certainly the systemic setting up, as you say, a database or a knowledge management system. So that, in theory, understanding what the lessons learned are would be as easy as a Google search or even asking an AI chatbot to say, give me this is my project. Give me all the lessons learned. Actually, we could probably try and check GPT.

John Byrne [00:24:18]:

Yeah. We're just a filtering system. You know that Yeah. Yeah. But that but that would be the thing. The first thing, you know, have some kind of knowledge management system or that database there because that would encourage people to do the the lessons learned. If if there if there's a system there, it won't be just left till the very end as a box ticking exercise. It's there.

John Byrne [00:24:36]:

Number two, it'll encourage people to add them as they learn the lessons. So don't wait until the end when you'll have forgotten this lesson because something else will have come up to take your mind off it. And, you know, the the the have as as part of your project kickoff thing that the the the project manager and, you know, if there's a senior team lead or business analyst or whoever else key is on the the thing, A part of that kickoff is going to be to go into that knowledge management system or that database and have a look around, do some searches for the types of projects that you're currently doing and the areas that you're currently doing and see, has that been done before in that area that could impact it? You're not necessarily gonna read through the whole lessons there and think that most of them won't impact you, but there'll be way to filter or search or analyze it with better to chat gbt or whether it's with, you know, search, AI searches, or just filtering, basic filtering. Things will will probably come up with a lot of, stuff. And you'll be through it. I mean, what's it gonna take? It's gonna take a couple of hours, and you might spot something that you haven't thought of that will save you weeks in in pulling your hair off.

Dante Healy [00:25:52]:

Yeah. I mean, I found that also trying to crowd search lessons learned as a project manager is is like pulling teeth. People just don't respond to surveys you send out even if you try and keep it as simple as here's three questions. Just fill out what your personal lessons learned are. And some people, you get one or two, and and this is out of a team of a hundred members on a project. There's one or two who are enthusiastically giving everything that they've noted, which didn't go well on the project. But then the masses, it's like crickets. They don't bother because they see it as admin, and they probably just they they say, oh, this is a great idea.

Dante Healy [00:26:38]:

Lessons learned. Yeah. But then they don't do anything. Those are the ones who actually don't support the process, which is really annoying when it's other PMO members.

John Byrne [00:26:49]:

Yeah. Well, you know, again, if if if it's a system where you can add as you go, it might make that a little bit easier because as project manager, you you don't need to send out the survey to the whole team. When you're in a team meeting with a specific part of the team, you say, okay. That's not going well. What what can we learn from this? And then you add it in straight away when they tell you there. Then you come back to them at the end of the project and ask them what the lessons learned is. You know, chances are they won't remember it. And even if they do remember it, they haven't got time.

John Byrne [00:27:17]:

They're in the middle of another project, and they've got another problem, probably the exact same problem behind you. But,

Dante Healy [00:27:24]:

but repeating the cycle. Right? And it's Exactly. Exactly.

John Byrne [00:27:28]:

But they're but but they're repeating the cycle for a different project manager who didn't know about that particular lesson because they couldn't access it. So, you know, that that that would be the hope that but by having a central repository of an easily searched, some lessons learned, you can avoid that. And by having it in a way that it can be added to easily as you go, not at the end of the project.

Dante Healy [00:27:52]:

Well, then then maybe it's that's the case for remote working, but not necessarily video calls, but audio calls. I'm just thinking about bandwidth. You know, a lot of the time, I don't have my video on because if I did, my computer would freeze because my Oh,

John Byrne [00:28:08]:

no. I I mean, like, just putting together a a a a a a knowledge management system with the the things. It doesn't matter whether

Dante Healy [00:28:16]:

I'm just thinking how to how to load it without having too much of an administrative burden. So if you record the meetings, you transcribe those meetings, and that automatically populates any key points into a lessons learned.

John Byrne [00:28:31]:

I'd say that's that's all complicated. That's considerably of complicated. And it's like you said, you only need a few things on a lessons learned. So, like, it'll take thirty seconds for you know, after our meeting, we have a lessons learned. As the project manager, I just pop into the knowledge management system, and I'll enter the three or four things. You know, what was the problem? How did we overcome it? And then tick a few boxes. What areas was it in? What types of project? You know, what what type of project was it that you had? But I don't think you need to be, analyzing whole transcripts of of meetings and things like that for lessons learned. Well,

Dante Healy [00:29:06]:

not necessarily you, but if you can get AI to do it, that's just what I was thinking in terms of, like, for example, ask it to pull out what were the key lessons learned from this meeting. Thinking about minutes. Because if you document a lesson learned, maybe tag it as a lesson learned during the meeting, at the time when it was identified, then that could be part of some way of automatically populating a database.

John Byrne [00:29:33]:

I'd be I'd be very iffy about doing that, relying on an AI tool to take out your your lessons learned from a a recording of a new I'd I'd it wouldn't be something I would do. I'd I'd I'd rather the project manager just fill in the thing. It'll take them about, you know, after a meeting, taking about ten minutes, assuming there were lessons learned in that particular meeting.

Dante Healy [00:29:54]:

Yeah. Yeah.

John Byrne [00:29:55]:

Because that's that's one of the points. That's what I'm saying. Don't leave it till the end when you've got loads of lessons learned coming out of meetings. It's as you go, you're learning something. You've hit a problem. You've realized, okay. This is a problem. Here's how we fix it.

John Byrne [00:30:08]:

Enter it there and then. Yeah. That's your lesson learned. This and, you know, do it then. It's only one problem then that you're having to ever enter our time. You're not entering dozens of problems, so you don't really need to to where you're getting the titles to pick them out for eight hour meetings. If there's dozens of problems in one meeting that you're having, something's more serious going wrong with your project.

Dante Healy [00:30:30]:

Well, this is the thing. People are complicated. That's why I was thinking maybe a technology solution that captures text could be the answer, but perhaps not. But, I mean, this comes up to my next idea, which was really about people who have this discomfort with admitting failure. So recording it in the lessons learned because, certainly, some newbie project managers will probably not want to admit that they basically miss something. So you have the classic, watermelon metric where our project is green until it's red, and it turns out it had been red for months, but was being misreported. So you find that a lot of cock ups, shall we say, which could arguably be reported as lessons learned, were actually best practice project or even standard practice project management one zero one. The you have someone who's in a project management role, but doesn't actually have the skills yet to be a project manager.

Dante Healy [00:31:35]:

So they're growing and learning and bumbling along and making mistakes. You know, maybe they have this fear of career consequences if a project went wrong until they get up to speed. And then also, there's an element of survivorship bias where even if a project succeeded, but there were still underlying lessons to be had, they may focus only on what worked rather than what went wrong and why. Mhmm. Maybe there were some really severe near misses that just happened to be mitigated towards the end.

John Byrne [00:32:10]:

And and the end of but a good project and and I suppose that will come from the culture of PML. That should be put in as a lesson plan. You know? Like, yes, you mitigated it. We're not saying it went wrong, but but your mitigation, you know, the the the problem that was arising and how you mitigate it goes into the lessons learned so that the next project manager is coming along and spot that because they may not have, you know, they they might not have the same reaction that you had, so they'll learn from your lesson. Mhmm. And then big problems, when big problems go wrong, you know, if you didn't overcome it then of in time and it was spotted, well, then it's too late. That stage people already know that you have that big problem, so you might as well put it in your lessons learned. And if you did spot it and then that nobody ever knew then that became a problem because you mitigated it before it became a true problem, well, then put that in your lessons learned because that's a little bit of a pat on the back for you that you spotted something and you fixed it before it became a problem.

John Byrne [00:33:06]:

And then just give everybody else a you know, that comes after you the heads up that this is something to watch out for and this is how to fix it if if it goes wrong. And one of my pet peeve peeves is, what you mentioned there at the start, it being green until it's red. That is the sign of a weak project manager. It should go orange before it goes red. You know, you should you should be able to see potential for a problem. Now it also depends on what your definitions of green, orange, and red is. But my definitions are green is everything is okay. Orange is everything is kind of okay at the moment, but we we've spotted a problem that if we don't do something to fix it, could cause us issues.

John Byrne [00:33:48]:

And then red is we've actually got an issue now on on the project.

Dante Healy [00:33:51]:

We're gonna miss we're gonna miss either scope, timing, or cost.

John Byrne [00:33:55]:

Yep. Exactly. Which means that if you're if you're a reasonably okay project manager, you should never go from from green to red because you should have at least seen that there was a problem that you're trying to fix before it reaches the stage where you can't fix it. Yeah. And then if you can't fix it, you know, not everything. That that won't avoid things going red. Things can still go red, but at least everybody has a heads up that, well, they knew it was orange for a while. So when it goes red, they weren't completely shocked.

John Byrne [00:34:23]:

But you don't you don't flag up and there's potential problems coming down the line, and then that problem becomes that risk becomes an issue. That looks bad, I think, professional level on it for a project manager.

Dante Healy [00:34:39]:

So thank you, John. That was, really insightful. So last last point to wrap up was thinking about lessons learned that I've encountered on across all the projects that I've been on. Three things, come to mind really. One is having effective stakeholder management. And if you're doing things like scope changes or even adjustments to your project plan, Make sure you've got strong communication across all stakeholder groups that are impacted on on your project because no one likes surprises. Two is resource management. Just make sure your resources are aware what their role is on the project, and then they are actively engaged when they need to be.

Dante Healy [00:35:29]:

Some and also knowing how my how many members on your team are actually purely dedicated for the project versus working across multiple projects or even managing a BAU role or business as usual. So an operational role with a little bit of project allocated to their time. Because if you're not careful, you can burn out people too quickly. And then finally, risk management. So one of the biggest risks I encountered was on working for a bank, which was subject to a number of regulations, if you didn't get legal sign off early enough, it would potentially delay the project by months or even over a year because we couldn't get agreement with the legal team that it was, that certain things were allowable. And on the flip side of that, especially in cross jurisdiction projects where you had to engage local legal counsel, and you had one local stakeholder who, shall we say, had a view of what they wanted done versus what they didn't want done, I would always get a second independent opinion on that. So, yeah, these were the things that kind of tripped me up in my in my previous experience early on in my project management career. Anything from your side, John, that comes to mind?

John Byrne [00:36:58]:

I suppose we we kind of touched on a little bit earlier, making sure that your timelines worked out well. Allow for unexpected things. Mhmm. Because, Janice, unexpected things happen so often, you should be expecting something. You might not know specifically where it is, but you should be expecting something. The other issue I've seen people do, and I may have been guilty of it myself in the past was being again, coming to to doing your project plan, especially with the timelines, being influenced by a strong personality who wants something specific. So, you know, you you do your plan out and you realize this project's gonna take six months and the project sponsor says they want it done in three months. So you rejig your plan to try and fit everything in three months.

John Byrne [00:37:45]:

It will not work. If you if your first thing is that this project is gonna take six months, you're not getting it shorter than that. What you're taking out are things that really shouldn't be taken out. You'll take out contingency. You'll need contingency. You will assume people will be able to dedicate more time to it. They won't be able to dedicate more time to it. Yeah.

John Byrne [00:38:03]:

Don't don't, you're better off well, you know, what's one lesson learned, I think, is it it it comes across a lot. You're better off telling people something they don't necessarily want to hear than you are telling them what they do want to hear and then failing to deliver it.

Dante Healy [00:38:18]:

Yeah. It's not sandbagging. It's actually protecting your credibility because your estimates your original projections were correct. It's just if someone puts in a stretch target to try and meet their stretch objectives, then you need to make them aware of the risk. And the likelihood is, if if if the plan is unrealistic, you're never gonna achieve it.

John Byrne [00:38:42]:

That's it. That, you you know, you explained to them, look, we'll stick with the plan I've got, and we'll try to bring it, you know, as as quickly as possible, but we may not be able to deliver. Or else we're gonna have to to change the scope that you can't, you know, just that. But the the key thing is, though, that, you know, between your usual thing, your scope, your time, and your costs, if if somebody is is pushing you to reduce one or more of them, yeah, don't think that you're going to be able to just reduce one more of them and not have any impact on any of the others. Mhmm. Well, there there are two key things, I suppose, is that because they're where I see projects fail the most. Mhmm. That that were the most.

John Byrne [00:39:20]:

So they're the the two. So I I don't quite have three like you did, but the two hopefully will be will be good ones. Yeah.

Dante Healy [00:39:26]:

Yeah. I mean, three just to keep it focused. So no. Thanks, John. Very valuable. And, yeah, this was a good conversation. Short and sweet, I think, but very important topic. And I guess the key takeaways from the discussion is there's an ROI to actually doing having a good practice of less lessons learned.

Dante Healy [00:39:47]:

It makes sense to have it in a knowledge management system where you can draw out the the lessons themselves somewhere where it's conveniently stored and accessible. Ensure that you have the right practice, but also the right culture in place so that you mitigate the risk of poor documentation and it being treated as a tick box exercise. Yeah. Anything else beyond that, John?

John Byrne [00:40:15]:

Yeah. John, a piece of advice I would give if it's a if you're, you know, a a fresh or relatively new project manager that if you go in somewhere to do a project and these things don't already exist apart from set them up, Have a chat with people who've worked in in the organization on some previous projects. Just just have a chat with them over lunch or over coffee or something and pick their brains and just ask them, how did it go? Did everything go smoothly? Was there anything that went wrong that you'd have changed for it? And at least then, it might give you a heads up as to what to expect even if they get lacking the proper lessons there in that place.

Dante Healy [00:40:48]:

Yeah. Yeah. Very valuable. If you lack the institutional knowledge, then find it from the people that may or may not have it, and and try and engage them as soon as possible. John, thank you very much. It's been a very valuable discussion. Looking forward to the next one.

John Byrne [00:41:07]:

Thank you, Dante.