The podcast by project managers for project managers. An episode about detecting imminent failure and dealing with project issues that could lead to failure. The project manager’s approach to supporting the team, addressing issues, and communicating resolutions is crucial for any project facing adversity.
Table of Contents
01:56 … Meet Susan
03:54 … Susan’s Project Story
08:30 … When Nobody Speaks Up
10:59 … Warning Signs
15:55 … When is the Project Manager at Fault
19:38 … Sequestering the Team
22:25 … Maintaining Communication Channels
26:40 … Root Cause Analysis
28:30 … Documenting Lessons Learned
31:06 … The Resolution of Susan’s Project
34:05 … Get in Touch with Susan
35:03 … Closing
SUSAN IRWIN: It’s not about ego. It is about furthering the practice of project management, it is about making everybody great. It is about working together as a unified team. Not just a project team, but a project manager team, to make each one of us great.
WENDY GROUNDS: You’re listening to Manage This, the podcast by project managers for project managers. I’m Wendy Grounds, and with me is Bill Yates. So an interesting thing happened to us the other day. As we were preparing to record this podcast, two days ago, we had some equipment failure.
BILL YATES: Yes, we did.
WENDY GROUNDS: And that amounts to a project failure.
BILL YATES: Yes.
WENDY GROUNDS: Have you ever had a project fail, Bill?
BILL YATES: Yes, I certainly have. I think most who are listening to this can relate. I think it was quite ironic that we would have a project failure, even with our episode as we were going to record this. First time. That’s too funny.
WENDY GROUNDS: Fortunately, Danny got us fixed up, and we’re ready to go today.
BILL YATES: You know, Wendy, it occurs to me this topic is one that is really rich. And we offer an online course by Neal Whitten on this topic of project failure. It’s called “17 Top Reasons Why Projects Fail.” Neal goes through those. He introduces those 17, and then of course talks about how we can avoid them. So another way we can go deeper in this topic.
WENDY GROUNDS: We’re actually talking with someone who has experience in project failure. Our guest is Susan Irwin, and she’s an adjunct professor at the University of Alabama, Collat School of Business.
BILL YATES: Wendy, this is going to be a pertinent conversation for our listeners. And I’m excited to have Susan with us. She has great information about both how to detect when failure is imminent with a project, and then advice. So she gives four areas of advice for those that are dealing with project issues that could lead to failure. So let’s get into it with Susan.
Meet Susan
WENDY GROUNDS: Susan, welcome to Manage This. Thank you so much for being our guest.
SUSAN IRWIN: Yes, thank you. I’m so excited to be able to share my ideas.
WENDY GROUNDS: We’re looking forward to hearing your story. But I want to ask you about your career background. Can you tell me how you got into project management?
SUSAN IRWIN: So I’ve been doing this for about 15 years. And so like most project managers that have been doing it for this long, I actually stumbled into it by happenstance. I was a developer by trade. I was really content on spending my life in the development side of the house. A manager at the time saw something in me, and this was back when project management was first starting to come into industry. You didn’t really see it much outside of the government sector.
He asked me if I wanted to step into this role as a project manager. I really was apprehensive about it because I didn’t really see at that time the value in project management. I felt that project managers were more of the gatekeeper and less of the facilitator of getting work done. And so I begrudgingly did it, and I fell in love with it.
So I went in, I did my PMP certification, and fell in love with it. And where I originally thought it was more of a gatekeeper or wasn’t allowing you to move projects forward. I actually found that, no, project managers do open up that gate and do facilitate and do shield the team and make sure things get accomplished. So I went and did an MBA with an emphasis in project management, and then went on ahead and did my Ph.D. in information technology with an emphasis on project management. So I teach classes and I often tell my students, as you can tell by all my certifications and my degrees, my love of project management now that has grown over the years. And I love the fact that now you can get those degrees in project management that didn’t exist before.
BILL YATES: That’s true.
Susan’s Project Story
WENDY GROUNDS: You had written an article on project failure. And I want to just lead into that with you telling us the story about this project. Could you introduce what happened?
SUSAN IRWIN: Yes. So I was actually the portfolio manager, or the program manager, on this project, and I had 13 lanes. Our project was at a local bank here in town. We were to move our third-party processing from one vendor to another. So we interfaced with our new third-party vendor. And then we had outside components that also interfaced in with our third-party processors. So they obviously had to move, as well. This particular article stemmed out of an issue where, at the time, we had received a go from all parties involved. So from the original organization, from the new third-party processor, and from the third-party vendor that was interfacing in. And so we had received a go that we were ready to move this into production.
Now, this was a two-year project, multimillion-dollar project. So we were about two weeks away from our targeted go-live date. About a week later, we had a meeting with our new third-party processor, and one lone individual threw his hand up and said, “I really don’t think we’re ready,” and explained the reason why. And so really what he was expecting to see from test cases he had not seen come across. So that spurred into a bunch of discussions with different individuals. And so we had, just to kind of give you our leadership perspective, I had a business sponsor, I had an executive business sponsor, I had a technology sponsor and executive technology sponsor.
So as you can tell, frustrations are high, people are concerned. People are going, well, how am I culpable in this situation? How did we get here? And so I had one individual who went and gave the story to the chief technology officer, the CTO at the time, that this was a failure of project management, without any background or anything. I was extremely upset because the narrative of this was we had no facts to base this on. And so this article was my response to that, as opposed to sending the scathing email that I wanted to do.
But as I started looking at this, I started thinking, well, if I’m going through this, maybe other people are going through this, as well. So fast-forwarding into the situation we had, at that point in time we were a week out. We had already done a go here. And we needed to figure out how are we going to get from where we’re at to where we need to be. And figure out how we can get some semblance of a go-live date in very short form because, every single time we move this date out, there’s a cost implication to it.
So pulled the team together, had daily meetings with everybody. Pulled this list of all the things that the third-party processing vendor was expecting to see, and worked with this third-party processor to get those in place. Make sure we have those tested, and then get those signed off.
And then, as we started digging deep into this, I had an opportunity to speak with my portfolio manager about this. And I said, you know, we typically put safety gates in to ensure that we don’t have these project failures. So you have risk and issue management. Well, we actually had a risk associated to this vendor as not being prepared as we originally thought. So we had that safety gate in that we were tracking. Then we had a go/no-go decision point that we were tracking. Then we had a meeting with the bank, the third-party processor, and the outside vendor. And so we had another safety gate where we had between the third-party processor and us. And we had another safety gate between us and the third party.
So as you can tell, we had safety gates in place. But we blew through all of them. Because in reality the root cause of this was no one felt like they had the authority to be able to stand up and say, hey, we’re not ready. Here’s a problem, and this is what’s happening.
When Nobody Speaks Up
BILL YATES: This is so, so interesting. And so relatable, unfortunately, I think, to most of our listeners. We’ve all been in situations where the wheels fall off of a project. I’ve got to ask you, so when you say you blew through the safety gates, by that do you mean the indications were there that, okay, we’re not really passing the quality checkpoints that we had in place, but nobody’s wanting to raise their hand and bring attention to it? So is that what’s going on?
SUSAN IRWIN: Well, yeah, we’re blowing through these, so we’re getting a go. We’re getting through each of these meetings. Nobody’s raising their hand. And it’s not until post-go, when we’re having one of these meetings, we’re up against the go-live date, that a single individual raises his hand and says, “We’re not in a position where we can go, and here’s the reason why.”
BILL YATES: Wow. So nobody was brave enough, if you will, to say, hey, the emperor has no clothes kind of a thing. Looks like nobody wanted to do that.
SUSAN IRWIN: Yeah. That’s 100 percent correct. And again, I had been doing this for 15 years, you know, and several years before that in the technology management side, just without the title. And I’d never seen – and that was my question back to my portfolio manager and other project managers. I’ve seen people blow one gate. I’ve seen them, one safety gate in place, but we had five, and just – everything went through there.
And typically we run through projects, we’ll have these conversations back with the team, is there any questions anybody has? And so we’d pinpoint every single one of them. Do we see any issues? Anything we’re not thinking about? Well, communication is hard. You’ve got to dig this out. People have to have that ability or passion to want to say, “We have a problem.” And sometimes people aren’t willing to do that.
BILL YATES: That’s what’s so intriguing to me is the fact that this is relatable. That we’ve all been in situations like that before. I can think of a project even as you were describing that, where I should have raised my voice earlier and said, okay. In this case it was a key interface that was falling behind, and so we were the performing organization. The customer was to provide that interface, and they had not done it.
As the delays kept mounting, we felt the pressure as the performing organization, the vendor, if you will. We didn’t want to point back to that area of the customer’s department and say, hey, they haven’t finished it yet. They’re way behind, but we needed to, we needed to do that. So, yeah, I think we can all relate to it.
Warning Signs
WENDY GROUNDS: So Susan, looking at project failures, what are some warning signs that are giving an indication that the project is heading towards a failure?
SUSAN IRWIN: You know, when you start seeing slippages. And it’s one-off slippages that start becoming more consistent, consistent, consistent, and so I think those are key pinpoints that you’re getting ready to miss a date. In this particular case, looking back, I struggle with how we could have figured out that this was going to be a failure; we were going to have an issue.
Now, I will tell you, and this is where I kind of take a self-reflective role, where could we have done some things differently? And one of the things I was telling the testing manager when this all happened was we could have pushed to get those test cases, or at least an idea of what they were going to be testing, from our third-party processor and so begin ticking those off on our side. We could not get the full information between the third party and the third-party processor because it was considered proprietary, but I think we could have gotten some level of information there.
Now, do I think this would have helped us, that we could have seen this coming? I think there are some things that, yeah, we could have seen here. I’m not going to tell you that it would have solved our entire problem, but I think those blind spots, if you can’t trace back all your test cases, if you can’t figure out areas where you’re interfacing, and you don’t have some sort of an oversight into that, and it’s really not just a communication oversight, but it’s a metric oversight, then that’s a possibility for a failure.
And so taking what I’ve learned from that project and moving it into my future work is I basically diagram out all my interfaces and throw a context diagram in, and I make sure I understand that I have full coverage, maybe not 100 percent coverage, but at least I know what’s going to have to be assessed in each one of these so I can use data to help me determine am I covered. Now, will that solve your problem? I think you’re always going to have some element of failure. It’s always looming out there. You just have to figure out how you can narrow that down so that it doesn’t happen.
BILL YATES: Susan, it was interesting. I was making some notes on this even before I heard your story of that project failure. And one of the things that I wrote down, a warning sign to me that a project is headed towards failure is when things are too quiet. You kind of get used to a rhythm and a background noise with your project team and your sponsors, your key stakeholders. When things get quiet, when that activity level falls, man, my spidey sense starts tingling, I get nervous. So you know, like you said, blowing through those quality gates, when people were going, “No, everything’s fine. It’s fine.” You know, there’s not a depth to that, they don’t go deeper into it, then that’s a bit of a warning sign to me.
Related to that, I always get nervous when I have a project that doesn’t have any change requests, because, you know, to me, many times that just means the sponsor or the customer has lost interest, or they’re distracted by something else. And then the likelihood that my project’s going to get canceled goes up. So that always made me nervous, too, it’s like, it’s kind of like a sign of life; right? It’s like, okay, I don’t want too many change requests, then I’m overwhelmed, my team is totally frustrated. But I need some so that I know the need’s still there, the customer’s still interested. Those were just some things that jumped out.
And then, I kid you not, one thing I wrote down before your conversation was a supplier or a contractor that doesn’t live up to their obligation, sometimes I’ve over-assumed. I’ve thought, oh, they’ve done this type of thing before, they’ve got this technology down, and then I get surprised in the project. That can sometimes undermine your project, too. Sounds like you experienced some of that. Very interesting.
SUSAN IRWIN: So one thing I’ll add to further your points that you made is we had multiple change requests on this project. So I will tell you that the number of change requests were quite extensive. We were tracking a lot of stuff there. However, you know, you made a very interesting point in the fact that we were in the execution phase on this project for almost a year. So I do think, and it would be an interesting study to understand does the longevity or does a longer execution time begin ramping into more of a higher cost of project failure.
Because you do start seeing the exhausting of the resources, and even though there’s a passion for this, I mean, this was a strategic project that we had a lot of focus on. We’ve got resources that are living and breathing this for a year, and so that doesn’t even incorporate the planning and the initiation piece that happened the year prior. So it was a long time.
When is the Project Manager at Fault?
WENDY GROUNDS: I know something that you have expressed really annoyed you on this project failure was that the project manager got the blame. Why does the project manager always get the blame? And my other question is, when is the project manager at fault?
SUSAN IRWIN: So I wrote in my article that, if a project goes really good, it’s the team, the team did a great job. But if the project goes really bad, it’s the project manager, and my father and I, we were having this conversation because he actually does this through the government. And so I asked him the same question, I said, “Why does the project manager always get the blame?” And he repeated the exact same statement I just made to you. So I said, “But is that correct?” And he said, “It may not be correct, but that’s how it is.”
He said, “You are a CEO of a project. So if you look at a project as an organization or an endeavor you have to get completed, you’re the CEO of that.” And so you’re given a bucket of money, you’re given some scope, and you’re given some resources to get this thing completed, and it’s almost like it’s the easiest person to blame on the team is the project manager when things go wrong.
Now, when is it the project manager’s fault? And I think it comes down to when does the project manager not listen to the team. When are they continuing to blow through and just keep pushing forward when the team has not one person, not two people, but you start seeing a majority of the team members start to raise their hand and say, we’ve got some massive issues going on here, and the project manager just keeps ticking forward. So that’s when it really comes down to the project manager being at fault here is not listening to their team and what’s being said, I just think we’re just easy, I think we’re an easy point.
One thing, when I was having my conversation with the portfolio manager, and I was having the conversation with other individuals in the project management industry, when this happened, one of my biggest frustrations was we were easy cannon fodder. So, it’s the project manager, the project manager didn’t do their job, it was the process, the process didn’t work. While if we had taken a couple of minutes, taken a deeper approach and really kind of taken a deep dive, we would have understood this wasn’t solely a project manager failure. This wasn’t a process failure. There was other attributes at play that we needed to take into account.
So without that deep dive approach, and just taking it along that original assessment of this is the project manager, you run the risk of this happening again. And then you look back on it five years from now, or somebody who’s doing a Six Sigma study will look at it and say, well, why is it you have six failures, and they’re all very similar? And it’s because you’ve not done a root cause analysis to really understand what’s happening.
So that’s why that was a key point that I made, that you’ve got to take that deep dive approach, understand why this happened. Project managers need to put their egos at the door. They need to understand that they may be culpable in this situation. Maybe they hit a blind spot, and they didn’t see this, but they need to be willing to take off the ego, put it on the side, have an open dialogue conversation, figure out how we got to this, and then figure out how do we prevent it from happening in the future. That’s what a lesson learned is supposed to do for project managers.
Sequestering the Team
BILL YATES: Susan, this is great stuff, and so I think this is the perfect segue into the advice that you shared. In the article that Wendy came across, you talked about four areas that a project team should look at when they’re facing a potential failure, and so I’d like to dig into those four areas. The first one you said was sequestering the team, so talk to us about that.
SUSAN IRWIN: So one of the things that – and I’m going to dig back into my dissertation because I actually focused on emotional intelligence when I did my dissertation. But one of the key areas is tensions are high, people know that we’ve got a project failure, they know there’s a cost associated to it. Putting a team on the backside, you know, putting them away and letting them work the problem, how are we going to get from where we’re at today to where we need to be? I don’t want you to focus on how did we get here, but how do we get out of here. And really letting them, in a room, focus on that, while the project manager is going to have to guard that room and say, so you know what, I need my team to get us from here to here.
Now, part of what they’re going to find out, or part of what I’ve seen when we do this, is that they start to dig in. When they start to figure out where we’re at and how do we get to the next level, how do we solve this, little nuggets of how we got here start popping themselves up.
BILL YATES: Yeah, it’s going to naturally happen.
SUSAN IRWIN: Right, it’s naturally there, but you keep the team focused solving the problem because at the end of the day your goal is to still meet that time-cost-scope paradigm that you want to get through. So locking that team away and keeping that team safe from the noise that exists outside because the longer the project is, the more money the company has invested in the project, the more executives that start swirling around and wanting updates. And that causes people to become nervous. So we call them “war rooms.” You can call them whatever you want to, but typically throwing them into a room and saying, “Okay, let’s figure this out, and let’s focus, and let’s get this done in short term.”
BILL YATES: I love that. That’s such a great approach. If I’m a team member, I feel protected. I feel like I’m in a cocoon. I’m in my team huddle. I’m in the locker room, so to speak, where we can speak freely. We don’t have upper level management walking around, looking over our shoulder, saying, “Okay, how’s it coming today? How’s it coming now? So I was here an hour ago, and I don’t see anything has been progressed.” Just so having that project manager, like you said, facilitate that for me and protect me and my team members from all those eyes, so that project manager is really being a good guardian in that respect.
Maintaining Communication Channels
And then you’ve also talked about communication channels and managing the communication. I mean, the reality is, if I’m the sponsor, and I’m paying for this project, and it’s showing up in the red right now, and all the warning signs and lights are going off, man, I’m going to be interested. And I want to have access to the team. So how is a project manager, what are some ways that you can support the team and still maintain the communication levels that those sponsors need?
SUSAN IRWIN: Yeah, so in this particular case, I was extremely fortunate that I had a wonderful executive business sponsor. I mean, if I could bring him with me to all my different companies and just put him in a box, I would. And so he helped facilitate and craft the message up through the chain that kind of helped provide a little bit more clarity about what was happening.
Now, I still had the noise on the back side that was the original assessment that this was a project management failure. And this was the project manager, and I could not get away from that. But what I used this individual for was to help begin crafting the message of this is what we’re looking at as a new date. And this is the impact of this, and this is how we’re moving forward, and so he lock-stepped with me throughout this process.
And then from a technology side I had a wonderful technology sponsor who helped craft and helped me support that message up through the technology chain. So as you can tell, we had a noticeable dual communication path that was taking place. And so I carefully chose both of these two individuals for their passion on the project. But their ability to be able to communicate and support us, and knowing how they were going to move forward.
Now, the hard part is, is that, if a project manager doesn’t have that, then you have to find individuals who can help do that and help be on your side. And sometimes it’s the portfolio manager; sometimes it’s the PMO manager. Just depending upon the company, both of those two individuals carry a lot of influence and obviously have eye interest. And so leveraging them to help craft that message moving forward while you keep the team focused. So you really act as that intermediary. You get the information from the team while protecting and shielding the team. And then you pass that information over through what do you know.
And so the other piece that I want to add is that sometimes we can tend to go off on tangents or say, “Well, we think,” or “We’re trying to figure out.” Craft your message as in what do you know? What do you know today to be a fact? Because if you go into “I think,” then you start going into this hyperbole of, well, this is what they said. And it goes back to that whole 10-second rule. “Well, in the last update, you provided X. Now you’re saying Y.” “Well, at that point in time we thought”. Get out of the “think.” If you have to use the word “I think,” stop, pull yourself back and say what do I know, and have that laid out.
Have the message in a PowerPoint document or a Word document. Something that you can easily shift over to those individuals who are going to be your communication people. And let them review it and then provide you questions back. Because a lot of times they’re going to tell you what questions they foresee happening when they give it.
BILL YATES: Yeah, that’s good, yeah.
SUSAN IRWIN: So come back with that and give them those talking points that they can use. But I will tell you, stay away from the word “I think.”
BILL YATES: Yeah. It’s interesting, the emotional intelligence that I even hear coming up in that. I mean, really, if you think about it, the team and the project manager as the face of that team were having to rebuild trust; right? We’ve broken a relationship. We’ve said, “Hey, we can do this. We can do this scope, using this budget, on this schedule,” and then something happened. Now we’re saying, “Oh, by the way, we’re going to be about a month late. Sorry”. So we’ve got to rebuild the relationship, we’ve got to rebuild trust, stick to the facts, just stick to the brutal facts. Don’t speculate.
Root Cause Analysis
Now, one thing I’ve got to get into is you’re a huge fan of root cause analysis. I think I’m looking to see if you have a fishbone diagram tattoo anywhere, or maybe you’ve named a child Ishikawa. I don’t know, but you’re a big fan of root cause. So tell us why you love root cause so much, and maybe you can give us an example of how it’s helped.
SUSAN IRWIN: So in root cause analysis you’re getting to the pinpointed, why did something happen, as opposed to “I think” or “I feel”. And that’s why I truly like root cause analysis. I really started getting into this a lot more when I did my Six Sigma process, my green belt. Then I actually started looking at things from a root cause. And you have a whole new perception of things when you get into why something happened. So it’s not just about, oh, we’re late because of this. And moving forward, if I have two-party vendors, this is what I’m going to do.
But it really kind of gets you deeper into it and makes the team think. Why did this happen, and what can we do to prevent this? And so maybe you can’t prevent it, maybe there is nothing you can do to prevent it. Maybe there is something that needs to be talked about more, but at least you’ve gotten to why something happened. And then you can come up with mitigation strategies, if there are any, to ensure that this doesn’t happen again in the future. And so don’t just stop at the initial assessment of we were late because somebody did not raise their hand, or the third-party vendor didn’t complete the testing they were supposed to get done. Why didn’t they do this? Why didn’t anybody know about it up to this point in time? And figure that out so that you don’t have this happen again.
Documenting Lessons Learned
BILL YATES: And then, to take it a step further. One of the pieces that I loved that you wrote about was to make sure that’s documented in the lessons learned. So that can be really tough. It can be tough for a team to do that. Because I look at it and think, okay, what I document as lessons learned from this project, other project managers, other team members will probably read it, and they’ll benefit from it. That’s the good side. The bad side is I may look pretty stupid by some of the mistakes I made. Or they may look at it and go, well, of course that was the result of your root cause analysis. So, again, it takes some trust and transparency to do that. But it’s the right thing to do.
SUSAN IRWIN: It does. So you know, one of the things that in my last corporation I made the comment, when a project closes, that project manager has nuggets. They have just facts inside their head of things that they did and things that they didn’t do. So pull that in. You know, the PMO implemented a process where, when you closed a project, you would give a presentation about what went well and what didn’t go well. And you need to have that ability as a project manager. This is not about ego. It’s not. It’s about how am I going to take this project that I have been entrusted. I’ve been given X amount of money, X amount of time, and X amount of scope, and get it from here to here.
And I am a firm believer, along with PMI and any of the other industries that support project management, that it’s about the team. You cannot be the best project manager if all I’m focusing on is what do I know. All three of us know so much more, and so if you had a bad project. And I can take some of those nuggets that you’ve provided to me, and I can use that on my next project, that makes me a better project manager. And so the same goes with you, I can tell you here’s where I failed. Or here’s where I had an issue at. This is what I did to get through that, and so you can take that nugget, that gem, and pull that through to your next project.
So I tell project managers it’s not about ego, it is about furthering the practice of project management. It is about making everybody great. It is about working together as a unified team. Not just a project team, but a project manager team to make each one of us great. That’s why we go to chapter meetings, that’s why we do these podcasts. That’s why we go through symposiums is we all want to learn from each other. Why do we want to stop that when we’re working with project managers from our own company?
The Resolution of Susan’s Project
WENDY GROUNDS: Susan, I want to hear the rest of the story. So how did this project eventually wrap up? How did you overcome that project failure issue? And how did you leverage your lessons learned from that project?
SUSAN IRWIN: So we actually, unbeknownst to the majority of the team, I actually had a fallback date already established in case of a project failure. In case we ended up having to move this date. However, because it trended towards the end of a quarter, we decided that that really wasn’t going to work. So we ended up having to bring it in. And so what happened was we ended up pushing this out two weeks from our original go-live date. So two weeks later we were able to move this project into production. It was a success when it got moved into production. However, you know, obviously the date was missed. So we did have to do a change request to accept the new date.
The cost associated with the project, we did bring that project in actually under budget. So I was a bit of a nitpicky penny pincher in that project. I curtailed a lot of what I considered spending that they didn’t need to have, and so they had the budget. So I was very excited with that project that we did get through the fire, you know, we did have this issue that popped up. We had other change requests that came up, but we were able to get this done on budget, albeit late.
The lessons learned, and how have I pulled that into my other projects? So part of what I did was wrote this article. As I stated, it was kind of more of a response to a very big frustration. But more importantly, it was to let other project managers learn from a failure that had happened to me. And so one of the things when I was writing the article, I kept thinking to myself, this is stupid, everybody knows this. Why am I writing this? No one’s going to like this. And so for people to actually have gravitated towards this article and received the response they have was fantastic. So it tells me that the basics are still valuable in the area of project management.
But as I move forward, it’s given me a better lens to be a better project manager. So it’s given me an opportunity to really dig deep and look at these projects. Take an objective look at where projects can potentially fail. If I start seeing, like you said, spidey sense, Bill. If I start seeing I’ve got interfaces that are happening between multiple external vendors, my little spidey sense starts setting up, and so I figure out how can I objectively track this? What are the data points that I can use that are within my control? And even if they tell me, you know, this is proprietary information, what are those things that I can do that are within my control, within my knowledge area, that I can at least begin tracking this, so things like this don’t happen?
Get in Touch with Susan
WENDY GROUNDS: I’m going to put a link to your article on the transcript. So what is another way that our audience can get hold of you if our listeners have questions?
SUSAN IRWIN: So I am on LinkedIn at Susan Irwin. And also you can reach me via my email at jandsue01@gmail.com.
BILL YATES: We love to talk about those projects that we’re proud of, the great successes, but it’s more important, we actually learn more when we take the time to talk about failures. So thank you so much for talking us through this and being vulnerable and then sharing these great takeaways.
SUSAN IRWIN: Well, thank you. I truly appreciate this opportunity to get out the message. And so hopefully this will help inspire other project managers to take that approach, kind of taking off their vulnerabilities, letting other people kind of grow and learn from them, but then also taking that deeper dive to figure out why something happened, to keep it from happening again.
BILL YATES: Susan, we appreciate your time.
Closing
WENDY GROUNDS: Thank you for listening. You’ve just earned some Professional Development Units by listening to this podcast. To claim your free PDUs, go to Velociteach.com and choose Manage This Podcast from the top of the page. Click the button that says Claim PDUs, and click through the steps. That’s it for us here on Manage This. We hope you’ll tune back in next time for our next episode. Until next time, keep calm and Manage This.
Leave a Reply