Learning from Mistakes: How Project Professionals Grow from Failure

Mistakes happen. It’s how you respond that really matters. Three project professionals discuss mistakes from their project careers and how they turned those failures into lessons learned. Plus, how can project leaders create a culture that accepts mistakes—and spins them into opportunities for greater efficiency and innovation? Our guests are Alexandra Schutz, PMI-ACP, PMP, director of program management at Appfire, and she is based in the Washington, D.C., metro area; Brian Dlamini, PMI-RMP, PMP, a project manager at Anglo American Platinum in Johannesburg; and Valentina Barou, PMP, a senior project manager at Ubisoft in Paris.

STEVE HENDERSHOT 
Mistakes happen. To everyone—and every project team. What really matters in those moments is how you respond.

Do you immediately alert sponsors and key stakeholders? Do you turn them into lessons learned? Do you help team members view them as opportunities to improve? And can you really celebrate them?

Today, project professionals will discuss the art of learning from failure. 

In today’s fast-paced and complex business landscape, project professionals lead the way, delivering value while tackling critical challenges and embracing innovative ways of working. On Projectified^®, we bring you insights from the project management community to help you thrive in this evolving world of work through real-world stories and strategies, inspiring you to advance your career and make a positive impact.

This is Projectified. I’m Steve Hendershot.

Mistakes are inevitable in the project world—but in the right culture, they can open doors to growth and innovation. The capacity to accept occasional failure is both a personal virtue and a hallmark of resilient organizations. 

Of course, learning from failure requires commitment and reflection. Today, three project professionals talk about how mistakes—when handled the right way—can hasten maturity.

Before we head to our group discussion, though, a quick favor: If you enjoy Projectified, please leave us a rating or review on Apple Podcasts, Spotify or wherever you listen. Your feedback matters and helps us keep making this show. 

Okay, now let’s hear from our guests. Alexandra Schutz is director of program management at software company Appfire, and she’s based in the Washington, D.C., metro area; Brian Dlamini is a project manager at mining company Anglo American Platinum in Johannesburg; and Valentina Barou is a senior project manager at gaming giant Ubisoft in Paris.

MUSICAL TRANSITION

STEVE HENDERSHOT
Everyone, thanks for joining us. Let’s start with how you think about failure as a project leader. What does failure mean to you? And how has that view of failure—what it means, what it portends, what opportunities it creates—changed over the course of your career? Alexandra, let’s start with you. 

ALEXANDRA SCHUTZ 
Yeah, I’m happy to start. Honestly, failure isn’t, to me, something that’s very black or white. It isn’t necessarily a matter of success or defeat. It’s just something that is a learning opportunity. And I think as project professionals, we have a lot of opportunities to kind of adjust and course-correct along the way. And failure oftentimes is an indicator to tell whether we’re actually on the right track or not. 

I also think that failure often occurs because there’s a lack of something. There’s a lack of knowledge, a lack of resources. There might be a lack of tools or even a lack of support that’s causing some sort of expectation to not be met or an outcome not to be achieved. And I know for me, early on in my career, failure meant that I was making a mistake. I was doing something wrong or I didn’t know something. Or even that I was receiving some sort of critical feedback, and it weighed upon me, and I took it very personally. I saw it as a sign of incompetence. Now that I’m a much more seasoned professional, I see failure as a learning opportunity. It’s an opportunity to grow. It’s an opportunity to improve yourself and expand your career. And I think it’s important that people view it that way rather than some sort of a setback that you potentially can’t get past in your career.

STEVE HENDERSHOT
You just mentioned how that evolves in one sense, but you also brought up a really interesting idea, which is that the sort of difference between failure in the sense of “We tried something and it didn’t work” versus “I messed up on something professionally”—the sort of project that didn’t land as intended versus some work product imperfection, et cetera.

ALEXANDRA SCHUTZ
I think it has to do with perception, too. You could have a project that goes down a super bumpy road, it ends up delayed, past schedule, over budget, but you’re potentially still providing value to either your company or a client that you serve. That could be considered a failure because you were past schedule and over budget, but maybe not. On the flip side, a project could be delivered on time within budget. You meet all of the scope, but maybe your client isn’t happy with the end product. That could also be a failure. So I think it’s really important that we kind of identify what the expectations around failure are and what it means, because I think it can mean different things to different people. And often there’s different expectations within different companies. So that’s important to consider as well.

STEVE HENDERSHOT
Brian, how about you? How do you think about what constitutes failure, and how has that changed?

BRIAN DLAMINI
I did believe it is a reflection of your competence, or at least your inadequate competence, for that matter. To say the least, I used to actually fear failure. Over time, like Alexandra, it’s a way of actually finding out how not to do things. If it’s a failure at that particular point, it’s pretty much a reflection of actually finding a different alternative. That has led to a lot of creativity, to a lot of innovation, finding new ways of doing things and just building up on that. I have found it to be more rather giving than necessarily taking away.

STEVE HENDERSHOT
Great. Thanks. And then Valentina, I’ll kick that to you, but maybe also with a little bit of an industry spin, just because it strikes me that the consequences of failure also look really different if you are in say, game development and you can fix it with the next release versus, say, mining, as Brian speaks of.

VALENTINA BAROU
I used to think that anything short of perfect was a failure—so if a project is not ready a week before the actual deadline, if the documentation is not updated the second the new information is received, if you don’t send a report to your stakeholders on that specific Thursday afternoon so they have it Friday morning. So I think early on in the career, there was a lot more about hitting the perfect pitch on all the notes, but now, with time, I learned that a project is not about just me completing every point on the checklist perfectly and on time because in most cases, nobody cares exactly what time you send that report, as long as they get it, right?

For me now, a success is to make sure that my project sponsors or clients, they’re happy, but the team is also happy with the way it’s advancing. Because again, with IT development, you can a lot of times either push the go-live date or, as you said, yes, we can fix it with a follow-up release. So now, instead of blindly executing the to-do list, I try to just build relationships with the team, with the stakeholders, whoever is working on the project, and have them co-own it with me because it makes sure that they can surface all the possible issues much earlier. And like this, if anything is going wrong, we can have a plan B that would be a lot easier to accept. And for me, failure today as compared to before would come from not building enough relationships and not getting enough buy-in, because in the end, the final result can deviate from the initial blueprint. But as long as it’s educated and accepted, it’s now fine.

Project professionals share their mistakes—and the biggest lessons learned from them

STEVE HENDERSHOT
I’m going to stick with you, Valentina, for our next question. Can you tell me about a time when you messed up? How did you respond? What did you do to fix or mitigate the mistake, and how did you learn from it?

VALENTINA BAROU
My mistake was in not setting enough boundaries and not protecting my team enough. It resulted in one team member absorbing the delays caused by other groups. At Ubisoft, there are two main groups: There’s publishing and production. Publishing takes care of business development, marketing, sales, product strategy. On the production side, we’re taking care of development, maintaining IT product, security, these kind of things. So I’m on the production side and in charge of a subscription for video games called Ubisoft+. I had been in this role for about two months. I was getting up to speed with my development team, and I was in the early stages of building the relationship with my partner team in publishing. They come in with a big partnership contract to make sure that Ubisoft+—that up until now is only on PC and cloud—is now available on Xbox consoles. It’s a really cool opportunity. Everybody’s very excited. But we also understand that this is a very XL-size project for us to collaborate on. And we’re still not really mature in our relationship to start working on it.

I’m completely dependent on the other team to handle the conversations with the partner and receive any feedback and signoffs that they may have. So while the other team was sharing sound visibility on their exchanges with the client, for me it was still pretty much a black box. It resulted in a design discussion taking a really long time, something about seven months, and leaving only two months for the implementation on the front end and quality testing. It resulted, as I said, in the front-end engineer absorbing all the delay caused by the lengthy design discussions and me not setting enough time boundaries ahead of time. 

As a result, knowing that we couldn’t deliver everything on the release date, I had to raise points saying that either we move the launch date or we don’t deliver everything on the day of. And that’s what we did. Looking at the most user-valuable features, we delivered the account linking that allowed users to start playing on consoles and the ability to claim rewards for their loyalty. But everything else was delivered in the follow-up two releases, which meant that there was a possible impact on revenue generation from the launch date because that’s when you get the most people, but at least the user was put on a pedestal in the top corner to make sure that at least users could get everything they needed on the day of.

STEVE HENDERSHOT 
What have you learned from that that has [been] applied to future, either when you’re thinking about how to structure and what to promise initially, but what did you learn?

VALENTINA BAROU
So my learnings were to make sure that I don’t rely on my assumptions. I address risk earlier, and I insist on getting the answers because up until a certain point, everything seemed okay. But also, mostly, setting boundaries and getting buy-in from people that, okay, if you know that whatever decision you’re not taking by a specific date, then know that it will have consequences. And that’s something that I keep applying more and more, saying that if you cannot give us an answer by a specific date, then you know that we’ll not be able to deliver.

STEVE HENDERSHOT
Before I call the next person to share their own story, any reactions, Alexandra or Brian, to what Valentina just shared? Does that ring a bell in any way?

BRIAN DLAMINI 
Yeah, absolutely. When I share, you’ll see that there’s quite a lot of similarities, particularly around the issue of timelines, not being able to meet the deadlines, and perhaps just fueled in my case by, probably, call it intimidation from sponsors or senior management.

STEVE HENDERSHOT
All right. Brian, you just sort of set us up. So I’ll come back to you now. What’s this parallel story?

BRIAN DLAMINI
I think project management is typically the same across the board. We are in completely different industries, but you tend to pick up similarities. For me, someone once said you have to get your bad news out first. Just to give context, as a project manager in my organization, we take a project through from the initiation stage through to execution. And in execution, that’s where you want to detail design it, and then take it through to construction. So it’s pretty much mostly in the construction space within the mining environment. Now, between feasibility and the execution stage, that’s really where you request for funding from the investor to execute this project. 

So I inherited a project which was nearing a funding approval request. When I joined that project, within about a month’s time, we had to go and request for funding. Now, the mistake was me not really diving into the schedule that was developed, not really diving enough into the defined scope to ensure that everything has been captured. If your scope is not better defined, you’ll certainly not have the correct timelines, and ultimately the funding you are requesting for will probably be short. And that’s the trap that I then landed into. 

So we went ahead because there was pressure to execute this project. When that funding request was being done, the commitment was that the project would be completed in eight months, whereas in retrospect, it was actually an 18-month project. So you can see that 10 months of that was not yet captured. Coming back to the point of “Get your bad news out first,” we did request for funding, and when we now detailed the project and we want to get this thing up and going, construct this thing, we then realize that “Hang on, it’s actually going to take much longer than what has been communicated.” Now, not wanting to be the bearer of bad news, you try with your project team to work within what has been approved as far as funding is concerned, and to work within the timelines that have been committed [to]. You would want to crash your schedule, do some activities in parallel, and where you had budgeted to do this work within a, call it an eight-hour day, you see if you can actually do it in 16 hours, which means shifts, but you actually don’t have the money to support the second shift because that funding was not requested.

So those were the mistakes in it. We realized this cannot be done. We need to go back, we need to communicate it, we need to request for an extension of time and we need to request for additional funding. That is ultimately what ended up being done. Because now you’re doing it much later, the impact is much bigger than when you would’ve done it as soon as you realized that this is actually what you need and quantify why that additional time is required and why that additional funding is required. We did, better late than never, so we did eventually do it and get it out.

STEVE HENDERSHOT
That’s good. I mean, that “Get your bad news out early” line, not only [do] I think that’s probably wise just from a sort of PR communication standpoint. But to your last idea there, it also just means that you are getting it out when there’s still more time to respond and change course.

BRIAN DLAMINI
Absolutely, and it becomes a trap to actually want to deal with decisions beyond your control. It’s unnecessary. One of the learnings is to escalate things as soon as you have to. There are some calls that you don’t have to be responsible for, so teams and people are there to actually assist you to get it through.

STEVE HENDERSHOT
And Alexandra, how about you?

ALEXANDRA SCHUTZ
I’ve made a lot of mistakes in my career, so it’s honestly hard to pinpoint just one. But if I were to identify core patterns around some of the mistakes that I’ve made, I think there are two really key areas, and one would be lack of clear communication, which Brian just mentioned. And the other is around making assumptions, which Valentina mentioned. So very relatable. But the times when I haven’t understood what a key stakeholder was telling me and I didn’t ask for clarification, or when I assumed something to be true without questioning it, those are honestly the times when my projects have gone off track or had issues and risks that needed to be mitigated. And at that point in time, I’ve had to backtrack, start over and reset. At those points in times, when I’ve run into these things, I’ve had to check myself and go back to the project team and the stakeholders and say, “Here’s what I’m understanding. Here’s where I’m seeing gaps.” And then get feedback.

It’s imperative to know “Am I understanding the same thing you all are understanding?” because if you’re driving a project in one direction but you’re missing the mark on areas, you have to gather that feedback and kind of reset, and it’s so much better to just pause and gain that needed clarification so that you can move ahead in the right direction rather than continue down an unknown path or an unclear path. So I think a lot of the things that I’ve learned are that when things are not clear to me, it probably isn’t clear to others. And it doesn’t matter how ignorant I may feel asking a question, it’s imperative to ask it. And it’s also imperative to keep digging until the picture is transparent, because as a project professional, it’s our jobs to understand what the project contains because we’re the ones driving it to the outcome. So we have to be able to bring visibility and clarity to not only ourselves but also to everybody else that’s contributing.

How failure can fuel innovation and efficiency

STEVE HENDERSHOT 
Yeah, that’s great. Next question: How does failure sometimes lead to something greater, or fuel innovation? One response to all three of your stories is “I’m never going to do that again. I’m going to change my process to avoid the thing that I did.” But there’s also an upside potential whenever you mess up—that maybe you can innovate your processes or create something new to address that gap, or things like that. So do you have examples of moments when a shortcoming led to a creative solution that you were able to employ going forward instead of just never doing that again?

BRIAN DLAMINI
So the one thing for me, you tend to take failure as bringing out a weakness. That’s certainly what it does. It prompts you to actually relook at your execution plan, relook at what then you need to do to try and circumvent it. And in so doing, it almost propels you to go into creativity. 

One of the projects that I did required training of people to actually run the new product, which we were installing. This was around weighbridges, where you weigh trucks and big vehicles that come to deliver and collect stuff within the operations that we’re in. So it was being rolled out across different operations of the organization. And at almost the last minute, when this thing had to be commissioned, the organization at the time was going through a restructuring, and what that meant was that those people are actually not available to be trained. We quickly had to turn around to say “How do we then bring it to fruition?” And that’s how automation was then brought into the picture to say [that] perhaps this product needs to be automated, which means you remove the person, and in removing the person, actually we realized that you mitigate the human intervention, which has got bias in measuring. Automation was actually eventually the best way of implementing it.

STEVE HENDERSHOT
Yeah, it’s a really strong example. Valentina, Alexandra, how about you guys?

VALENTINA BAROU
Well, for me, it’s more of a general observation that sometimes a failure to deliver something can result in just having less time for implementation. Normally when you have all the time in the world, you also have less motivation to study or improve or find new solutions. But under the pressure of a specific deadline, you may start just thinking differently. You come up with different solutions of how the job can be done. You can start thinking more outside of the box, looking for replacements, being a lot more critical of what you have and streamlining your processes, whether everything you are trying to build, all the features you’re trying to build, are actually needed or not. Basically, it’s just about the focus under the pressure of the time to really concentrate on what needs to be done or prioritized. 

ALEXANDRA SCHUTZ
Yeah, I think to Valentina’s point, it’s not only failure but the threat of failure that can spark this innovative thinking. So when you’re up against that tough deadline or struggling to meet a project goal, you all of a sudden start looking at every possible solution. And I think this encourages collaboration and team bonding because there’s kind of this sense of desperation and everyone goes, “Oh my gosh, how are we going to hit this deadline? How are we going to deliver this product?” So all the options now have to be put on the table, even the ones that you scrapped before. And to Valentina’s point, having that pressure and the need to overcome those challenges I think is what sometimes leads teams to find those more fresh or innovative approaches that they may not have thought about at the get-go.

VALENTINA BAROU
Also, look at this. To get to Alexandra’s point, imagine that you couldn’t get funding for a specific tool or a specific consultant, something from the outside, but now that you don’t have enough time and the use of this resource is justified, this can also be finally allowing you to get there. I’m not saying you need to lead your project into the wall so that you finally get the extra funding unlocked, but it’s more about just maybe this is finally something that gets you over that edge to finally be able to use a tool that was previously rejected.

ALEXANDRA SCHUTZ
That’s a great point. Opportunities may even just present themselves naturally.

BRIAN DLAMINI
It all reflects that as a human being, we’re actually capable [of] more than what we limit ourselves to. Because in times of high-pressurized environments, that’s when you realize we’re actually creative. And I think when you have the luxury of time, that cannot come out. 

Ways to create a team culture that accepts mistakes with accountability

STEVE HENDERSHOT
That’s great. Now I want to talk about another scenario. Say someone on the project team makes a mistake. How do you bring that up and handle it? To me, this goes hand in hand with the larger question of how do you create an environment that accepts mistakes without forgoing a sense of accountability? Alexandra, let’s start with you. What do you do when a team member makes a mistake? 

ALEXANDRA SCHUTZ
I think when there is a mistake that’s made by a team member, it’s extremely important to just have that conversation. First of all, just tackle it head-on. Even though it’s difficult, it’s necessary to talk about it. If there are clear expectations in place already, it’ll be easier to point back to where those expectations were not met. So it’s clear to the person where that mistake was made and why it was a miss. But I think it’s important to hear the team member out and understand how they felt about the mistake. Did they even recognize that it was made, or did they see it and not feel safe enough to admit that there was a mistake and that they needed to raise awareness? Maybe they thought they could fix it on their own. I think all of their input will provide clues as to where that breakdown occurred and where they may have had a gap or needed some support or help. And I think that’s really important to take into consideration.

STEVE HENDERSHOT
When that sort of thing happens, how do you diagnose when you’ve maybe got a culture issue versus an immature act on behalf of the person involved? When is it on them versus something that you should be thinking about [in] practice and policy?

ALEXANDRA SCHUTZ
I think it’s important as managers and leaders to understand the people that work for you and to know at least what their abilities and skills are at a baseline so that you kind of know where they’re going to be challenged and where mistakes are much more capable of being made. 

BRIAN DLAMINI
As a leader, firstly, it should be self-reflection, and how I look at it is, you want to have what is called positive accountability. But positive accountability, you can only achieve it if expectations are clearly defined and the team members know exactly what they’re expected to do. So in the area of a team member making a mistake, the question first is, in terms of what you expect them to do, do they have all the required resources? Have they been furnished with the resources to actually be able to meet their performance indicators? And if they’ve got everything to deliver what is expected of them, then the shift moves to did they then make a mistake? And then how do you deal with that mistake? The idea here to be able to hold them accountable is really to push toward constructive criticism. I mean, if you’re a leader of a team, you want to leave that team member still empowered, although you’ve highlighted the issues and the challenges, or rather the end result of the mistake. 

But you also want to be able not to leave them disheartened. You want to leave them empowered to actually rectify that mistake. And it comes back to the culture topic. It’s a cultural issue if it’s happened more than once and more than one person does a similar mistake, or there’s just a notion of making mistakes within that team. Then you can conclude that it’s a cultural thing. But if it’s just one team member, it’s probably not cultural yet. But you do want to create a culture where people are accountable, a culture where people are honest, a culture of high integrity. The way to do that is, again, coming back to yourself as the leader to say, do you walk the talk? So you reflect that by being accountable yourself as a leader. So show others that they can count on you. That’s really what you want to achieve. And you build that culture then of accountability, that culture of being honest. That culture of saying “Mistakes are not the end of the world. It’s things that we can learn from, it’s things that we can build from.” And if you open that environment, then people are happy to actually support and buy into the vision.

VALENTINA BAROU
When I discover a mistake or if somebody points my mistake out to me, my go-to strategy would be to talk about it to someone and try to get a big picture. Take a step away, and sometimes maybe even sleep on it. Because discovering a mistake, especially your own, triggers a very strong emotional response.

In terms of somebody else who has made a mistake and how we can talk to that person about this—this would be definitely in a one-to-one conversation. This is a moment of vulnerability. So I would start with a one-to-one conversation, and as a project manager, it would be important for me to actually address it and then stop talking.

I would need them to explain their vision, because I come with my own bias. I come with my own vision. I come with my own feedback I received from somebody else and whatever else somebody else told me about it. First I want to hear from the person and see what led to it because, Brian has brought it up before, that you want to see also how the other person sees it. This surfaces what are the gaps that they may be having. I would never blame the person. I’ll try to blame the situation or address the situation itself because, again, everybody’s uncomfortable. You want to find how to act so that it doesn’t happen again. Many times, I think it’s also an issue of feeling the responsibility or being alone and not asking for help because different cultures—within the company but maybe even culturally—can put this pressure of having to deal with something alone. There is a term “servant leader.” And one of the facets of this is to clear the obstacles of your team members before they get to them so that they continue working peacefully. It’s important to actually empower people and make sure that they’re not alone.

I don’t know if on your side, Alexandra and Brian, if you do retrospectives with your teams. In my team, we have three-week sprints, and at the end of each sprint, we have a retrospective where we look back and discuss what happened in the last three weeks. This is a great time to actually bring up what’s going well, what is not going well. When somebody makes a mistake, it’s also a good opportunity for that person to speak about it on their own because it would allow them to clear the air with their team members and address it because you don’t just hide it under the carpet. And I’m also aware about another really cool one, actually, as a practice. It’s where a team gets together once a month to have a competition of who dropped the ball hardest. Basically, they all disclose their worst fail in the last month, and then they take a vote of who had the worst one.

BRIAN DLAMINI
I’m going to take that, Valentina. 

ALEXANDRA SCHUTZ
I love that.

VALENTINA BAROU
Yeah?

ALEXANDRA SCHUTZ
Very cool.

VALENTINA BAROU 
That person, the winner, they win chocolate, [and] they share with the team. So, again, it’s not so bad. But basically what happens is they try to find examples where their mistake had an actual impact around them, and they can learn and apply it. It helps the team actually identify similar issues that contribute to updating the processes within the team and fix recurring mistakes. Because if you made a mistake, somebody else probably did the same. And within the team it really helps to build this comradery, establish security that you can fail, it’s human, and to have this kind of team-building exercise in a way where you don’t necessarily have to go do something outside, but you can just exchange stories, allow yourselves to be vulnerable and to be accepted in this vulnerability. So I think that this is a really cool exercise that more teams can try adopting.

ALEXANDRA SCHUTZ
Valentina, I love this because what a way to set up and create an environment that truly accepts mistakes. You are just creating that sense of being able to be vulnerable, which is really hard. You’re building comradery with people, you’re showcasing the humanity of making mistakes, and you’re wrapping that all around how you can create these lessons learned and grow as a team. And I love it because unintentionally it’s already creating an amazing culture that shows what’s acceptable within your company and within your team. 

We need to be clear with people that failure is not an excuse to be sloppy or lazy or not do your job correctly. It is an opportunity for saying what you did wrong, bringing that awareness and being honest, and having that integrity to do so. And then figuring out a best way to move forward. How can we learn from this, and how can we make sure that we sidestep something like this in the future?

STEVE HENDERSHOT
So we’re down to our last couple of minutes. But Valentina just brilliantly transitioned us into the last thing that I really wanted to make sure we hit, which is a tip from each of you on how you go about making sure that failure has that appropriate place in your teams where it’s fueling growth.

VALENTINA BAROU
I’ll just tell you to sleep on it. Take a step away, calm down and see that it’s possible to fix it. Don’t let it define you as a failure because you just learn and move on.

ALEXANDRA SCHUTZ
That’s exactly what I would’ve said. Learn from it and move on. And I think what’s really important is mistakes do not define who you are as a person.

STEVE HENDERSHOT
What do you do to make sure that everyone on the team understands that that’s where you’re coming from as a leader?

BRIAN DLAMINI
You need to appreciate that there [are] quite a lot of different mindsets. There’s a lot of different people within the project team, and most often than not, these are specialists in their own separate fields. So you want to create an environment where rather than being a dictator, create that environment where you can trust people to go and do what they’ve got expertise to do. If you create that type of an environment, then people understand that they’ve got the leeway to do what they can do best. And if they make a mistake, then you can always talk about that.

STEVE HENDERSHOT
Great. Thank you, everybody, so much. 

STEVE HENDERSHOT

And thank you for listening to Projectified. Like what you heard? Subscribe to the show on your favorite podcast platform and leave us a rating or review. Your feedback matters a lot—it helps us get the support we need to continue making this show. And be sure to visit us online at PMI.org/podcast, where you’ll find the full transcripts for episodes as well as links to related content like useful tools and templates, the latest research reports, and more. Catch you next time!