In this episode, we explore the projects that didn’t just encounter challenges—they went completely off the rails. Joining us is Velociteach instructor Frank Polack, who shares lessons from project failures and examines the warning signs that are often missed, the leadership decisions that backfire, and the moments when teams realize a project may be headed for trouble.
Chapters
00:00 … Intro
00:52 … Meet Frank
02:57 … The Accidental PM
04:38 … Early Career Mistakes and Lessons Learned
08:28 … What Defines a Failed Project?
11:18 … Berlin Brandenburg Airport and Early Warning Signs
13:36 … Silence Is a Red Flag
16:46 … Leadership Blind Spots and the Fyre Festival
18:28 … Staying Out of the Weeds
21:28 … Boeing 737 MAX and Communication Failures
23:43 … Creating a Culture of Honest Communication
25:14 … Velociteach
25:47 … Risk Management Mistakes That Lead to Failure
30:06 … Common Root Causes of Project Failure
36:45 … Recovering Troubled Projects
39:55 … Lessons Learned and Pre-Project Reviews
43:33 … Connect with Frank
44:18 … Closing
Intro
FRANK POLACK: Well, I find that’s a problem in a lot of organizations, that there’s a culture of no bad news. I don’t care how bad the news is, I want to know it now better than later, and we’ll figure it out. The blame can come later, but let’s fix the problem now.
WENDY GROUNDS: Hello, and welcome to Manage This, the podcast by project managers for project managers. We are so thrilled to have you with us today. I’m Wendy Grounds, and in the studio with me is Bill Yates and our audio engineer, Kellen Porter.
If you haven’t yet left a review on Apple Podcasts or Google Play or left your comments on our website, we would love to hear from you. A quick review of Manage This would mean the world to us. Don’t forget, you can earn free Professional Development Units from PMI just by listening to this episode. Stick around till the end of the show, and we’ll tell you how to claim them.
Meet Frank
Our guest today brings a remarkable blend of project management expertise, technology leadership, and real-world experience across a variety of industries. With more than 25 years as a project management consultant, instructor, and PMO implementation specialist, Frank Polack has helped organizations improve the way they deliver projects and manage change. We’re also proud to share that Frank is one of our outstanding instructors here at Velociteach. Many of our listeners may already know him from his highly regarded Pass the PMP classes, where he has helped countless project professionals build their knowledge, confidence, and careers. His career has taken him through telecommunications, aviation, facility management, and healthcare consulting.
But one of the most unique chapters was his time with the Atlanta Committee for the Olympic Games, where he worked on several high-profile Olympic projects, including the torch relay and Olympic Village housing allocation. In fact, one of the highlights of his career was carrying the Olympic torch through his hometown of Gainesville, Florida.
A longtime member of PMI, Frank has served as president of the PMI Atlanta chapter and spent four years on PMI’s Global Ethics Review Committee. And we have a very interesting conversation with Frank today.
BILL YATES: Yeah, Wendy, we’re going to talk about failure. This is going to be the failure episode. This is the episode where we talk about the projects that didn’t just go sideways. They actually full on came off the rails. We’re talking about the warning signs we ignored, the decisions we regret, and the moments where we thought, oh, no, this project is actually going to implode. I can see it. We’re digging into what these failures taught us about leadership, communication, risk, and resilience. You know, every project manager has a failure story. The difference between good leaders and great ones is what they learn from it.
WENDY GROUNDS: Hi, Frank. Welcome to Manage This. Thank you so much for joining us today.
FRANK POLACK: Good morning.
The Accidental PM
WENDY GROUNDS: And first of all, before we start, I want to know a little bit about your story as a project manager. Did you decide project management is the thing for me, or did that grow on you?
FRANK POLACK: What I usually tell my students is I started out as an accidental project manager. I was kind of self-taught in computers, and I started doing some work for a facility management company that a friend of mine worked at. And the premise of that company was kind of unique in that they were helping the owners of buildings move their tenants in. So, it was a service they were providing. So, a little bit unique. And they grew so quickly that they suddenly said, “Hey, we need you to manage a project.”
At that time, I had no idea what the formal structure of project management was, but I kind of understood what the gig was; right? Basically, babysitting movers all night, make sure that everything got put in place. And so, I started learning from that. So I did that for many years, kind of a dual role, doing some projects, but also taking care of all the IT stuff in the office, small office. But so, I’ve always tried to keep a dual career that way.
Over the years, I got to know a little bit more about it. Again, nothing formal, really, until I was able to parlay that into a job with the Olympics, the ‘96 Olympics. And there I went into the technology department and worked on special projects that were pretty interesting. And then after that, I ended up at a true project management consulting company. So, we did a lot of work with IT Telecom, and that was our primary business. So that’s really where I started getting involved with PMI and understanding that there was actually a formal process behind it.
Early Career Mistakes and Lessons Learned
WENDY GROUNDS: Because our topic is the failure episode, and we’re talking about projects that have gone through failure, is there something that you want to share that maybe a mistake that you made as a PM that kind of stings a little bit, and something that you warn your students about?
FRANK POLACK: Well, I think early on it was, I guess, not understanding what all the moving pieces were. And as we learn later in the PMI structure of all the different knowledge areas, you know, aside from, I tell people, aside from your budget and your schedule, there are other things you have to worry about.
So, during one of these facilities moves, I was supposed to also manage part of the contract between the customer and the moving company. Not that I was involved in the actual contract negotiations, but supposedly I was supposed to at least read through it and make sure that it made sense. I was supposed to protect my client. And I missed a few things in there just because of inexperience or whatever. Luckily, the moving company, the guy I worked with, was really good and worked with me to kind of correct it. And he actually ate a little bit of the pain that I caused him. But I learned quickly from that.
So that led me to be very nitpicky from that point forward as to, you know, what’s in the contract. And if we get to it later, there’s another project that that was a key factor of success or not.
BILL YATES: As Frank was sharing, as a reminder, you know, I have so many movies flashing in my head. I’ll just pick one short movie. There was one time I remember we were working a project with a very large retail company. I’m not going to name the company, but you’re all very familiar with this company. And we were migrating their data from their old system to our new system that we’re implementing. And through that migration, we needed their DBA, their technical people to take the interface and create a file for us. You know, pretty straightforward. And they started having problems with it.
And again, this is just getting it out of their own system into a format, a file format that we could read. So, it’s not, you know, it didn’t sound like anything tough. And it’s something that, you know, other companies had done no problem in the past. I assumed things were going well, and they were delayed and delayed and delayed. And I real – here’s the problem. I should have pushed that to my sponsor that, you know, that was the customer. I should have pushed it to her a lot sooner than I did. I knew the DBA that was working for them. You know, I’d gotten to know that DBA. I was trying to protect the DBA and give that person a little more time.
And then it all – I’ll never forget the meeting. It all hit the fan. There were four of us in a meeting, the VP of tax being the sponsor that was in there. And she’s like, why is this taking so long? And when she found out how long I had known it had been delayed, she hit the roof for good reason. And I’d been trying to protect her own team member. And I really should have brought her that bad news. Bring bad news soon; right? It was such a memorable – but I can still play that movie in my head.
FRANK POLACK: Well, I find that that’s a problem in a lot of organizations that there’s a culture of no bad news. I remember working at one company where, when we did our monthly reports for our projects, our boss actually told us you can’t put a red status;right? Green or yellow is fine, but no red. I said, but I’m pointing out red because this is an issue that…
BILL YATES: Because it’s…
FRANK POLACK: …needs attention; right. And he says, no, no, we can’t show that because then it shows that we’re not, you know, doing things right or whatever. It’s like, regardless of why it’s happening, you know? And so that’s something that always, later on when I was running a PMO or something, it’d always be, I don’t care how bad the news is, I want to know it now better than later, and we’ll figure it out. The blame can come later, but let’s fix the problem now.
What Defines a Failed Project?
WENDY GROUNDS: How would you define a failed project? Is it, you know, is it always just about missing the scope, the schedule, the budget, targets or something like that? Or are there other ways that you would say a project can fail?
FRANK POLACK: In my classes, I always tell people project management is not just budget and schedule. That is a small percentage. That’s the easy part because it’s a science. Everything else is the art, and that’s where it starts getting difficult. When you’re managing a project with a lot of people involved, and a lot of personalities, you have to be aware of those, as well.
I have one example of that was we were doing a technical rollout, and, well, it was a call center. And we were in charge of the technical part of it, making sure all the servers were going in, and the phones were programmed, and all that. We did everything exactly the way they wanted it.
And the day that we rolled out, we would set up little help desks internally so that the agents could call and say, hey, my phone doesn’t work, whatever. Well, we started getting a lot of calls, and “This is not working right. It’s not working the way it used to”and all this. And so we’re checking everything. It’s like everything’s programmed exactly the way that management wanted.
Well, what we didn’t realize was that management went from letting the agents deal with their own group of companies, right, so I’m Joe, and I manage these five companies every day, and I know those people, to no, you pick up the phone and grab whatever’s the next call. Right? It’s a pool now. Well, these people weren’t told that. And so that’s one of the things that I realized that, even though all the technical stuff was there, we were on time, we were on budget, the change management part of it was not there. Someone didn’t really explain to these people, this is how things are changing. This is why it’s going to be better for you, and so on. And so, these people were shocked. And of course it was a wake-up call.
But so a lot of times we have to go, again, past that schedule, past that budget, and figure out what are the other elements in the bigger picture that can really cause it to go off rails; you know?
BILL YATES: That’s such a good point. Sometimes the champions for the project, they’ve been in it for so long, and I’ve fallen into that before. It’s like they see the benefits clearly, and they’re excited about it, but they haven’t brought people along with them. They haven’t done that change management communication. They haven’t really said, you know, here’s the vision for the project, and here’s what it’s going to look like in the future. These are the benefits that you’ll see.
They’re just saying, hey, we’ve got a project going on. Here are the things that are assigned to you. You know, then they’re surprised when they don’t realize, how do you not know what the new state of work is going to look like? You know, I’ve had it clear in my head for months and months. Yeah, but you’ve never told me.
Berlin Brandenburg Airport and Early Warning Signs
WENDY GROUNDS: One of the failed projects that we had thought would be a good example to talk about today is the Berlin Brandenburg Airport. So, what happened here was Germany’s new capital airport suffered nearly a decade of delays, billions in cost overruns due to design flaws, construction defects. There were governance problems and poor project coordination. So, failure is not always just one event, something that happens. It’s a process. What are some early warning signs that a project is heading toward trouble? Because I’m sure the Berlin Brandenburg Airport, it was gradually coming, and they just weren’t looking at the signs.
FRANK POLACK: In projects like that, and I’ve managed a project very similar to this, in that there are so many moving pieces and the management team assumes that everyone knows what they’re supposed to be doing; right? So, in a case where you’ve got the construction crews, you’ve got the IT companies, you’ve got other areas, it’s like, well, we hired you to do the job, you’re supposed to be the best, just do it.
And what they failed to look at is, yeah, you can have multiple project managers, but who’s really keeping an eye over all that? And I’m not talking about an executive manager, but someone who’s actually on the ground working with these other project managers. Sometimes people might call that a program manager but really coordinating all those different groups. And the one project that I worked on was very similar to that.
We were strictly the IT hardware side of it, but we had to work in sync with the construction companies as they built out the different gates and stuff. And then we had to come in behind them and put things in. And then another company was doing the cabling, so now we were dependent on them. The meetings that we had every week never really addressed these issues. It was more about finger pointing than actually what are we going to do to fix the problem?
And I think that was someone at a higher level should have taken the reins of that. Again, at that time, my role was to manage my piece, but I could see that no one was really coordinating all those pieces together. And little by little, this guy’s delayed, this one something broke, but no one’s putting all those dominoes together.
Silence Is a Red Flag
BILL YATES: Yeah, Frank, I agree. And, man, there are so many things that jump out at me when I think about some of those signs or warning signs for a project that’s starting to trend towards failure, and we don’t know it. One of the things that scared me with projects is if either the meeting, the status meetings were too quiet, or my sponsor was too quiet. Those were big-time warning signs for me. It’s like if my team was quiet, you know, if nobody had questions, nobody had input, it’s like there’s no energy in the room, I’m like, things cannot be going that well. How do you guys not have any questions for each other; you know? Yeah, we’ve got these reports. That’s fine. But I want to see signs of life.
Anytime it got too quiet in a meeting, I mean, I’d have follow-up with team members later just to make sure there wasn’t something going on that I wasn’t aware of. Maybe there’s a conflict. Maybe there was a side channel communication from the sponsor that I wasn’t aware of. It could be rumors about the company. There’s something going on that’s keeping my team from being healthy because there should be healthy dialogue. Quiet meetings scared me.
Frank, you and I teased before just in the classes that we teach. To me, it’s like the same thing is true with change requests. I like to see healthy change requests. You know, if there are no change requests, either from the team or from the sponsor, I get nervous. You know, I’m like, nobody’s interested in this project anymore. It’s going to be canceled. So that was a thing for me.
And I remember a piece of advice that we got from Robert Israel when he talked about the Palace Theater, the construction they did for that, that renovation project in Manhattan. He talked about the need for face-to-face communication. And what Frank was just talking about reminded me of that.
So, Robert saw value in having a project office really close to the job site so that he could have the right people. He talked about, I don’t know, 30-plus subcontractors. And they had to have a representative in that office at all times when they were working on the site so that, if something happened, they could quickly address it, talk about it, and avoid any costly delays or avoid not having the right voices in the room when they needed to make those decisions to keep things moving along.
FRANK POLACK: It kind of goes back to that, what I was saying, the culture not allowing people to speak up. And especially if you’re a PM that’s coming into an organization, you’re not aware of the atmosphere, right? And you wonder, like you said, why is everyone so quiet? It was because we don’t speak up here. We don’t say these things here. It’s like, but that’s not good. And so, you have to kind of change that culture to, you know, we’ve got to put everything on the table. I remember reading, I want to say it was Malcolm Gladwell, there was one of his books, and they talked about the Korean airliner that had crashed.
BILL YATES: Yes, yeah.
FRANK POLACK: And they were talking about how the, because of the culture, this was a geographic culture, but that, you know, you always defer to the senior person. But long story short, they had a crash and all this. And so, when they came back later, they say we have to instill a culture now that, when you’re in that cockpit, everyone is equal, and everyone has to raise the alarms. You can’t skirt things only because, well, I don’t want to insult my senior manager or whatever.
Leadership Blind Spots and the Fyre Festival
WENDY GROUNDS: Yeah, I think that’s a good opportunity to talk a little bit about leadership blind spots when it comes to failure. One of the failures we have listed here is the Fyre Festival. It was going to be this exclusive luxury music festival in the Bahamas and became a disaster when the organizers failed to deliver basic accommodations, food, transportation, and infrastructure. One of the problems there was leadership delusion. What are some leadership behaviors that contribute to projects going off the rails?
FRANK POLACK: You know, in our classes, we always talk about analyzing our stakeholders and understanding their involvement or their interest in our projects. And there are times when sponsors of a project don’t seem interested in their own project, whether they think it’s just a mundane, everyday thing so, you know, just only let me know if something goes wrong, or they’re just too busy. And I know that Andy speaks to that, that when you have senior-level backing, that projects go much better.
So, I think that’s the first level is that the project manager should make sure that they have that sponsor at the right level of engagement so that they are aware. It doesn’t have to be a daily thing, but they’re not coming in and saying, oh, my gosh, the sky is falling. Right? So, I think that’s where, if there’s not enough linkage to that senior manager – because again, they’re also seeing, like you were saying earlier, what’s going on in the company, what’s going on in the marketplace. We need to have that kind of insight from those sponsors, as well. So, I think it’s our responsibility to engage them, bring them in a little closer to our project.
Staying Out of the Weeds
BILL YATES: Especially early in my career, man, I put on blinders. I was so focused on my project and my clients that I would, you know, blindly, here’s what we’re focused on. Don’t worry about any of the noise from the company or what projects are in the future or which ones are getting the best resources. Let’s just get this done and do it with excellence, and then we’ll be fine. Which there’s some value in that. I mean, you don’t want to be distracted. You want to be able to provide value on the project you’re doing. I realized, okay, I need to get my head out of the sand, look at the forest for the trees;right? Yeah, it’s great to be, you know, focused on your project; but you do need to know what’s going on.
So, engaging your program manager or the portfolio manager or the C-suite to know what big things are coming in the future or the big projects. Why did I just get one of my best resources taken off my project and put on another? You know why? What’s happening with that? Is there anything I could have done about it, or is it a strategic move? And, you know, I will have my eyes open when I find out, you know, while we’re doing this. Okay, all right.
But yeah, I think one of my mistakes early in my career was not listening out and looking for those signs. Asking the questions, why are leaders doing what they’re doing, or not making decisions that I would think they would? What does that mean to me and my team?
FRANK POLACK: The challenge for PMs, especially if you’re in a technical field, or you have a strong technical background, you enjoy being in the weeds; right? That’s dangerous because, you know, we’re supposed to understand that, hey, we’re not doing that anymore; right? I tell people, I might have 30-plus years of IT experience; but if I’m managing an IT project, I am not the expert.
And I have to back off, and I have to see the bigger picture; right? I have to now step into the cockpit and make sure I know where I’m steering this thing as opposed to, hey, let me go help you fix the engine back here; you know? And I see a lot of project managers do that because, again, they’re so – you get involved. You understand what’s going on technically, and so you want to get involved in that. And you just have to learn to step back out of that.
WENDY GROUNDS: And also, I think, not being afraid to take advice from the smart people on your team when they advise you to do something or not, you know. Not to be too proud, not to listen to that advice I think is a sign of a good leader.
BILL YATES: Absolutely, yeah. That’s a definite signal in a blind spot. And I think for a project manager who has a, like a coach or a mentor or maybe just a manager above them, to know that’s a tendency that that project manager has and encourage them to grow in it, you know. And it could be something as simple as, you know, you’re dominating the status meeting or the meeting, the updates with the customer. I want you to give other team members a chance to do that.
Or, you know, you had a few team members that were bringing up some pretty significant updates to the risk register, and you seemed to blow it off like, eh, no big deal. Take a pause on that. Go follow up with them later and see, you know, is there more to the story than what we talked about with the team?
Boeing 737 MAX and Communication Failures
WENDY GROUNDS: So, let’s look at another big disaster of something that went wrong. This is the Boeing 737 MAX. Boeing’s aircraft program was grounded worldwide after there were two fatal crashes. There were flaws in the MCAS flight control system exposing issues. There were issues in the design, the testing, oversight, and basically just organizational culture. A lot of this was linked to just really catastrophic communication gaps. So that’s something that can really cause a big failure in a project. What communication habits distinguish a healthy project from a struggling one?
FRANK POLACK: An important thing when it comes to communication is making sure you have the right people in the room. I’ve seen several projects where decisions were made being a little myopic, thinking, well, you know, this makes sense, it looks good, whatever. And then not realizing that, wait, there are other areas of the organization that actually might be impacted by this.
And so, we should have them sit in, at least yea or nay, you know, everything’s good. So, I think many times I know people get meetinged to death. But to have – you have to have meetings. You have to have that – those statuses. But making sure you have the right people, I think you mentioned earlier, getting the people in there to bring up the different points and having people that can make decisions.
Again, having dead bodies in there doesn’t help. You have to have someone that can, you know, you’re filling in for someone, you have to be able to vote on something in place of that person so that we’re not wasting time, and we can make those decisions. So I think having the right people in the room, having people that have the authority to make decisions, making sure that we’re not meeting out of habit, but out of need.
I think many times it’s just, well, we have it scheduled every Monday, so let’s just meet. Well, are we meeting for a reason? Is there something going on? Can we get away with just having a status report this week and not have to bring everybody together? Or, no, we’re getting down to the final days or weeks of this project. We need to be meeting on a weekly, daily, hourly basis.
Creating a Culture of Honest Communication
BILL YATES: It’s funny, Frank, you mentioned the no red status at one organization. To me, that just speaks to, man, healthy communication needs to be truthful and needs to be transparent, even when the news is not good. And I think that’s one of the big ones that I’ve seen, too, is depending on the culture of the company, just their willingness to see when things are going poorly on a project. Let’s talk about it, and let’s be transparent. Let’s be open about it so that we can actually make a change and get things back on track. From what you’ve seen, Frank, how do project managers encourage honest conversations when the news is not good?
FRANK POLACK: Well, I think, again, working with your immediate project team and letting them understand that your perspective is “I want to see that.” We’re not here to shoot people down. We’re here to put out the fire. And after the fire’s put out, then we can talk about what went wrong, what didn’t. But, you know, if we can always focus that our immediate concern is delivering the project according to the specifications and the requirements for the customer, let’s focus on that first. But again, it depends on the organization.
Again, a lot of them have that culture where you just don’t – you don’t bring that up. You don’t say bad things. But then I’m always curious, how does that end up in the end; right? When those projects fail spectacularly, right, who goes back and says, “Well, you guys never talked about it.” You know, I don’t see how people don’t catch those kinds of things.
Velociteach
JESSICA CLEVENGER: Velociteach has some great learning opportunities for project managers. Prepare for your PMP exam with our Exam Prep Boot Camp, a comprehensive accelerated learning program which includes live instruction and study tools. With the Velociteach no-risk guarantee, get certified or get your money back. Also, our award-winning platform called InSite is for online eLearning, with over 70 self-paced on-demand courses, aligned to the PMI Talent Triangle. You can prepare for the PMP or earn your PDUs.
Risk Management Mistakes That Lead to Failure
WENDY GROUNDS: What are some common mistakes that people make when it comes to risk in a project? Do they underestimate? How do they mishandle their risk? And does complacency play a part in project failures?
FRANK POLACK: This is another area where I feel a lot of project managers do it “because I have to” and don’t really understand why we’re doing it. So, at the beginning of a project, you may have a risk identification meeting. You sit down and start jotting all these risks down. And then it sits on a shelf, and no one ever looks at it again. Well, we went through it. But it’s like, yeah, but risks change every day.
And so, I always tell my students, you know, when you look at the two tools that are the most useful for any PM, it’s going to be your work breakdown structure, you know, what are the elements that you have to deliver; and your risk, your risk register. Because your project is perfect except when you have a risk. Right? And so, we have to be managing those all the time.
Bill, you said that earlier, that sometimes people tend to blow off some risks because, in their experience, oh, it’s not a big deal. But we have to listen even to those quiet voices that say, but it happened to me once, and this is how bad it was. And so, we can’t blow it over. Right? Again, it may never have happened to you. But there’s a reason why we buy fire extinguishers and why we buy insurance; right? So, I think risk is a really important feature of a project. I think it’s something that PMs really should focus more on than just, again, learning how to use a scheduling tool. I think risk and having a good conversation with your sponsor about what are the risks that really concern you.
I know we talk about, for example, when we talk about the triple constraints, which one is the least flexible? I think we have to think about risk in that way, as well. Right? Which of those three constraints – scope, schedule and cost, for example – which of those three is least flexible in terms of risk? And how much should we focus on that? And do we have the luxury of having a risk department that can help us out?
BILL YATES: I think the reality is, too, sometimes we can tend to ignore certain risks, or not give it enough analysis, just because of the person who brought it up. You know, sometimes it’s like, oh, well, Negative Nancy, there she goes again. That never happens. You know, we’ll put it in the list, but I don’t know. And then, you know, you’ve got to remove personalities. You need to look at it like a list and go, okay, here is a risk event. Let’s look at the likelihood. Let’s look at the fallout, if it does happen, the impact, and take the personalities out of it.
FRANK POLACK: And also understanding that we lose sight of people’s experiences; right? We talk about diversity. Well, diversity of thought, diversity of experience is really important because, as people move from one organization to another, from one industry to another, there are things you never have thought about that could happen. One of the simplest stories I always tell people is when I used to travel a lot, I had a friend that also traveled a lot. And I would complain that my bag was always the last one to come up on the carousel. And, you know, I was told, “Well, you’re exaggerating. You’re making a big deal. It’s like, no, that’s my experience.
Well, we ended up going on a trip together. And sure enough, hers was the first bag out. Mine was one of the last ones to come out. I said, so I’m going to always look at this particular item from a bit of skepticism where you just like, oh, no big deal because it always happens right for me. Right?
And so, and this goes back to what I was saying earlier about when you’re very technically minded, or you’re very much in the weeds, you’re not looking at the bigger picture of risk. Right? What is the risk of a vendor being late or what’s going on out in the world that might impact my project that I hadn’t thought about, you know, oh, the price of fuel just went up. Yeah. So, whatever. Well, you’ve got a shipment of cubicles coming into your building that’s going to raise your budget or whatever. So again, I think risk is one of the most important pieces, and it’s the one that seems to be less focused on by most project managers.
Common Root Causes of Project Failure
WENDY GROUNDS: Across major project failures that you’ve studied or you’ve experienced, are there some patterns that you see emerge repeatedly? And what are kind of the root causes, regardless of industry or project size, that cause these failures?
FRANK POLACK: One of the ones I see come up quite a bit, and I know it doesn’t sound like it would actually be a real thing, but lack of planning. And I say that because too many times it’s, “What are you doing?” “Well, we’re planning.” “You don’t have time for that. Start working.” I’ve literally had people tell me that; right? You don’t have time to put all this stuff together. Just start building the thing. And, you know, as we teach in our classes, there’s a structure to this, understanding what is it that we’re building before you start thinking about how long it’s going to take, what it’s going to cost and all that.
And so many times, especially industries where you’re doing similar projects, the tendency is to just start swinging the hammer without really going back and saying, is this project really like the last one we did? Again, bringing back in risk, what are some of the risks on this particular project that are different from the last one, and how do we plan for that? So, I think not giving a lot of emphasis to planning is something that I see quite a bit happening in projects.
BILL YATES: Man, there are so many things that jump out at me; and, yeah, planning is huge. It’s really funny, too. A lot of times the complaint that people think about or a common culprit would be technology. But in my experience, it’s usually something a lot more simple than that. It’s basic stuff. It’s like having a disengaged sponsor who, on the front end of the project, as you’re signing the contract, they’re fully in. They’re going to be, man, I’m available anytime. Here’s my cell phone number. You call me anytime. My door’s always open. There’s that kind of thing.
And then when push comes to shove, he’s not available. You know, he won’t respond in a timely fashion. And then suddenly you’re having to make decisions in the dark, and that’s a terrible place to be. So a disengaged sponsor, maybe sometimes a project manager not fighting for resources when they needed to.
I’ve been in situations before where, you know, maybe I was a bit timid about making sure that we had enough staff on our team to get done what we did and reach our deadline. And I’m kind of looking at it going, ah, we’re going to have to push the overtime button somewhere over on the next six weeks; where I should have been going to the sponsor, to my boss, and say, I’ve got to have more resources. You know, we’re going to burn the team out if we do it, if we stick to the plans that we have right now.
FRANK POLACK: Well, a lot of project managers are intimidated by their sponsors or by upper management, and so they don’t tend to push, or let’s say interact with that person at an equal level. In other words, let’s take away the management level. Let’s just talk about this is a project we’re both interested in making sure it’s successful. Let’s discuss this item.
I had one project where we’re launching a product and our number one red hot item was the approval of the logo and the colors because we had manufacturing that was waiting. We had marketing materials that were waiting, all these things. And every week we would bring up this one thing, and it was always pawned off to, well, that’s the legal department, or that’s this department. And I kept trying to bring this up to my sponsor, and I finally had to almost get in his face and say, you need to make a decision on this now. Right?
You have to do this because I’ve already pushed. I pushed the legal. I pushed these people. It’s time for you to step up and do it because I have no more firepower; right? But it’s hard to do that, you know, because you’re now addressing someone that could basically fire you. Right? And but it’s – I’m trying to protect your project. You have to help me here.
BILL YATES: Frank, it’s so interesting you brought up planning, too, insufficient planning, because I can think of a specific project that I was working on. We had a pretty standard delivery process in play, so we felt good about the project plan that the team had.
But the customer had their piece of it, too, and they missed something in the planning. You know, we had talked about working elbow to elbow, face to face in their offices. They neglected to put travel costs in their project budget. So, we signed the contract, we’re going, making plans for them. You know, we’re going to work on this, and we’re going to interface with your department in this way, and then we’re going to be face to face at this time. They’re like, whoa, whoa, whoa. You’re going to fly; how many people are you going to fly out to our office? And you’ve got to start naming off people.They’re like, let me get back to you.
I’m like, oh, that was weird. And they’d forgot to put it in the budget. And it became a serious issue because we really, back then, the technology was such we really needed to be face to face to get some of that done. And, yeah, so planning, basic planning can really, you know, don’t be afraid to ask stupid questions. That hit me after that project. It’s like, don’t be afraid to ask questions that seem maybe even insulting. But it’s that assumption log; right? I’m assuming we’ll have travel budget that you guys are going to cover per the contract so that we can be face to face, you know, these different dates on the project.
FRANK POLACK: Yeah. It’s the little stuff. And that’s why I was saying earlier about contracts, that I know that on one of our projects, day one, we were already in the hole, I would say $120,000. It was a big, big contract. But people were making a lot of assumptions that this project was like a similar one, and so we’re going to price it the same way, blah, blah, blah. But they failed to really read the details where, as an example, we were installing 1,200 workstations.
Well, the contract, the RFP said every one of them had to have its own power strip and its own cable lot because this was in a public area, that things would walk away. No one bothered looking at those little details. So that’s – that was $120,000 that now we had to come up with from somewhere; right?
And so, the next project, which now we had the chance to actually be involved with the RFP, we started nitpicking every little piece of that contract. And again, I’m not a legal expert, but there were some obvious things that looked like either it was a bad cut-and-paste or, you know, the grammar wasn’t quite right. And so at least at that point you say maybe we should have the lawyers look at this again because that doesn’t sound right to me. But that’s part of your planning; right? Because, you know, once that thing’s signed, you’re stuck with that.
Recovering Troubled Projects
WENDY GROUNDS: Do you have any examples of projects that recovered? Any recovery stories? What turned things around?
FRANK POLACK: In many cases, it’s a replanning. You have to basically rewind and start over again. Many project managers are put in a situation where they have to take over a project. And so, for whatever reason, they come in, and they start looking at what did the previous project manager leave me. And I’ve been in a couple situations where there wasn’t much, or it was not well-defined or understood. And it goes back to their whole thing about, well, we kind of know what we’re doing, so we don’t really have to write it all down.
And so, this is where I said, no, I need – for my sake, I need to go back and replan this based on what I’m seeing, because I don’t understand what the original intent was. And this is, again, where my manager came in and says, “Stop planning, start doing.” I said, “But it’s, you know, you don’t just jump in the car and start driving. You have to have a sense of where you’re going.”
And so I was able to get a couple of weeks to really sit down with the different, I’ll call them department heads, you know, the head of sales, the head of operations, to figure out what is it that you need us to build for you in this big picture, because it wasn’t well-defined. It goes back to what I said earlier that, you know, everyone assumed that the operations guy knew what he had to do, and the sales guy knew what he had to do. But you guys aren’t looking at the fact that all this has to be integrated back into the system that we’re building.
So, sales ended up needing these really intricate reports that no one had planned. They figured it would just come out of the system. Well, how does that happen? Well, it just comes out of the system; right? And so that was kind of redirecting the project based on some new planning that hadn’t been there in the first place.
So, I can’t go back and say, “Well, it definitely went better than it would have.” But you can kind of make that assumption if you don’t have a roadmap to go by. Again, I can’t shoot from the hip all the time; right? What do we say? Projects are unique. And so as much experience as you have, you have to figure out what is unique about this project, what’s going to bite me, and how do I plan for that item? One of the questions that we have in one of the quizzes talks about where you come in, and you find out there’s no work breakdown structure.
BILL YATES: Right.
FRANK POLACK: Right? What do you do? And one of the answers is you stop the project. And it’s amazing the discussion I get from students that you would never do that. And I said, “I’ve done that.” Because, again, it’s like, think about it. If you’re the guy hired by IKEA to design the instruction manual to put this table together, what’s the first thing you have to know? What are the pieces? Without the pieces, how are you going to know how to – this A goes into B goes into C. You’re not going to know that because you don’t know there’s an A, B, or C. And it’s just interesting how many project managers didn’t recognize that. Like, I would never stop the project; but then what are you doing?
BILL YATES: Got to keep the work going, but what are you working on?
Lessons Learned and Pre-Project Reviews
WENDY GROUNDS: And learning from our failures, talk about what a project post-mortem should look like, and the lessons learned from that.
FRANK POLACK: I find that, in a lot of projects, many times we don’t have or don’t make time to really do a post-project review. Right? We’re already gearing up for the next project. It might be a cursory, “Hey, let’s just write down a few things.” But I remember reading about one of the big consulting companies, that they make their project managers go through the lessons-learned database, a similar project that they’re about to take on just so they can start seeing what are some of the things they should be looking out for.
So, when I teach classes, and we get into the discussion about having lessons learned,it’s interesting how many organizations do not have a formal way of really using that to their advantage. Yeah, they might fill out a form. They might put it into some repository. And then what? Right? And, you know, how many project managers actually go and say, “Okay, I’m about to start a project on XYZ. Let me go see what happened on other projects.” So, I think this is another really overlooked tool that is very beneficial, especially if you’re in an industry where you’re doing very similar projects. Again, there comes back that uniqueness. What was that one thing that bit that project that you should really think about?
BILL YATES: Yeah, that’s so true. And I think, you know, personally, if I’m assigned a project, ideally, I’m at a company that’s mature enough with their PM approach that I’ve got files that I can go through and look at. You know, find an old risk register from a similar project, find their schedule, you know, things like that that would just be amazing to help me out. But then also I want to know who was assigned to – who was the team? And are there other things that didn’t get captured that they could tell me that could bring value?
Like it could be, you know, again, many of the projects I worked on were with a set of maybe 50 clients. So, we do repeat work from time to time. We have another project, like, “Oh, I’ve never worked with AT&T before. Let me see, oh, David led that issue or that project with them. Let me go talk to David and see, you know, how do the – what is it like with AT&T? You know, how much access do they give you? Or what kind of roadblocks did you find there that you didn’t find at Verizon when we were working projects there?” So just knowing, some of those things may not get documented; but man, it’s super helpful if you can talk to the developer or the PM or team members who were on it and just see, see how to navigate it.
FRANK POLACK: Well, maybe we should now formally name a new function in project management, the pre-project review; right? Bring in everybody, whether it’s your kickoff meeting or some other thing, and say, “Okay, let’s bring in those people. Let’s have a discussion. Maybe we do that during our risk assessment or maybe a more general discussion.”
BILL YATES: That’s a great point, too, because, you know, practically it’s like, it’s one thing for the leader of the project to do it; but, gosh, it’d be awesome if my developers knew who worked on the previous project that’s going to be similar or with the same client or whatever. You know, “Hey, here’s, you know, the development team. Do you know,” and throw out the names and let them connect if they haven’t already. You know, “These are some resources for you to go to.” You know, it’s all about the team;right? It’s not just up to the PM or the leader of that project to do the homework.
FRANK POLACK: It’s best if everybody does.
BILL YATES: Right. And embrace it.
Connect with Frank
WENDY GROUNDS: If our audience wants to reach out to you, or if they have any questions, where should they go?
FRANK POLACK: Yeah, find me on LinkedIn or the Velociteach website. You should have my bio there to reach out. Or hopefully take a class, and you’ll be able to talk to me directly.
BILL YATES: Awesome. Frank, thanks so much for coming in the studio with us. This has been a long time coming, and it’s just great to be able to talk through and hear some of the stories that you’ve got from your own experiences and the students that you – you’ve encountered thousands of students through your career, and you’ve had a big impact on them. So to be able to have these conversations with me and Wendy in the office here is perfect. Thanks so much.
FRANK POLACK: Thanks.
Closing
WENDY GROUNDS: That’s it for us here on Manage This. Thanks for spending some time with us today. It’s always a pleasure to have you joining us. Don’t forget you can visit us anytime at Velociteach.com to subscribe, catch up on past episodes, or read the full transcript of today’s show.
And now it’s time to reward yourself. You’ve just earned free PDUs for listening. To claim them, head over to Velociteach.com, click on Manage This Podcast at the top of the page, then hit the Claim PDUs button and follow the simple steps.
We’ll be back soon with more insights, stories, and strategies to help you master the art of project management. Until next time, stay curious, stay inspired, and keep tuning in to Manage This.
Leave a Reply