Recovery and prevention strategies to rescue a struggling project. If you’re dealing with an overdue project or looking to prevent delays before they happen, listen to Mark Woeppel as he shares real-world examples, hard-earned lessons, and practical frameworks to help organizations get struggling initiatives back on track—and what leaders can do to prevent delays from happening in the first place. Hear how poor schedule and risk reserve management can lead to delays and learn early warning signs to identify minor versus systemic issues.
Chapters
00:00 … Intro
01:35 … Rescuing a Late Project
05:38 … Common Root Causes for Delays
09:07 … Schedule Transparency
12:15 … Minor Delay vs. Systemic Problems
14:35 … Priority Switching
15:40 … Early Warning Signs
17:46 … Kevin and Kyle
18:47 … Visual Project Board
23:19 … Maintain Team Morale
25:51 … Rebuilding Trust
30:39 … Preventing Delays
32:38 … Contact Mark
34:09 … Closing
Intro
WENDY GROUNDS: Hello, and welcome to Manage This, the podcast by project managers for project managers. We’re thrilled to have you joining us today. I’m Wendy Grounds, and with me is Bill Yates. If you haven’t yet left a review on Apple Podcasts or Google Play, or even left your comments on our website, we would love to hear from you. And we’re so grateful to anyone who’s already taken the time to do so. Thank you for being part of our community. You can also earn free professional development units, your PDUs from PMI, just by listening to this episode.
Our guest today is Mark J. Woeppel, the founder and president of Pinnacle Strategies International, a management consulting firm that specializes in improving productivity in production, project management, and knowledge work. He’s the author of a few books, and taught and lectured at several universities including Northwestern Kellogg School, California Institute of Technology, and the University of Kansas. He’s a true expert in project recovery, with over 20 years of experience in helping organizations rescue struggling initiatives. So, if you’re struggling with an overdue project, or you’re a leader looking to prevent delays in the future, take a listen to Mark’s real‑world examples, his hard-earned lessons and easy-to-follow frameworks.
BILL YATES: Some would say that every project schedule is either behind schedule, or it’s about to be behind schedule. So, let’s talk to an expert about this.
WENDY GROUNDS: Hi, Mark. Welcome to Manage This.
MARK WOEPPEL: Hi. I’m glad to be here.
Rescuing a Late Project
WENDY GROUNDS: We are thrilled to have you, and it’s been lovely meeting you. So, thank you so much for being our guest. We’re talking about “Rescue Your Late Project.” Can you share a time that you’ve successfully rescued a late project, and some of the steps that you took to rescue it?
MARK WOEPPEL: Well, I wrote a book based on probably the biggest project that I’ve worked on, and it was a construction project for oil field equipment in Asia. The first problem was they didn’t know where they were. You know, they’ve got a $100 million, $200 million project. And the project owner told me, “I don’t know where we are, except we’re late.” That’s what she did. She knew they were late, but she didn’t know where they were. And so that was really the first step was to break out the project, build a process. And we looked at the project plan to kind of re-baseline the project, but it was so complicated we didn’t have time. We needed to do something right now.
So, what we did is we kind of condensed that down and simplified it into a stage gate process, and then put a visual board, and then here’s all the jobs, here’s all the tasks, and here’s all the people so we could actually visualize the project. And then we got all the stakeholders, the engineering manager, the construction manager, the manufacturing manager, all the people that were responsible. You know, we stood them up in front of the board and said, “Well, here’s where you are. And this one has stopped; this one has stopped; this one has stopped. Who’s going to fix it?” And so that’s the very first thing that we did was just kind of say, “Well, here’s where we are. Where are we stuck?” Right? And that’s really where we went to first.
Just a little side note on that. So, this is a big multinational, so they’ve got factories all over the world. And so, they’re kind of coordinating it from Singapore; but, you know, they’ve got components in Malaysia and Houston and Norway. And they’re kind of coordinating all these people, and they’ve got engineers spread all over the world. So, we had all these tasks that were stopped, waiting. And we’re like, “Well, who is it? Who owns that?” And they’re like, “We don’t know.” You know, because what would happen, I’d go to a project meeting and say, “Well, I sent the email. I haven’t – it’s in Houston someplace. I don’t know where it is.” So, you know, one of the things that we really focused on was, I use the word “accountability,” focused on accountability. Who owns that task?
BILL YATES: Yeah.
MARK WOEPPEL: Then, in the escalation process, how do we get that to the right person to get those things unstuck? So that was the very first thing. And that took, I don’t know, in that project it probably took about 90 days. And then once we got execution running, then we started looking at the project plan. We started doing more risk management. So, we focused on risk management. And so, we had an analyst that was focused on the schedule. Look at the schedule. What’s coming up? What are the risks? We started to push the schedule to try and get that risk resolution done before it was presented to the execution team.
So, and that risk was either technical risk or supply chain risk or wasn’t assigned or something like that. And from there, we sent teams to suppliers. We sent teams to other parts of the organization because they were stuck.
Another part of the organization had a bottleneck. So, we would send a couple of guys, say “Go break that bottleneck.” And they would go live in the factory or on the jobsite for some period of time until, you know, they got rolling. And I don’t want to say we saved the project, but from the customer’s perspective and from their customer – so their customer was one of the majors. Think, you know, Big Oil, Exxon, Chevron, you know, one of those guys, and they were happy. So, from our perspective, the customer was happy. The customer’s customer was happy.
BILL YATES: Yeah.
MARK WOEPPEL: Because it was a big project. I mean, you know, several hundred million dollars. And it took us, eight months or so to kind of get processes and get things rolling, and we could hand it off to those guys. That’s one example.
Common Root Causes for Delays
BILL YATES: Yeah. So, from my own experience, it’s like experiences like that, projects like that are the best for me to learn from. And there are so many great takeaways that we’re going to get into, the stage gate, the, you know, where are we stuck, who’s going to own it, the focus for 90 days, the risk management that followed that. These are all excellent. Let me step back and ask another question here, kind of a broader question. When you look at project delays, what are some of the most common root causes for those delays, and why do they tend to go unnoticed?
MARK WOEPPEL: Well, projects get delayed a day at a time; right?
BILL YATES: Yeah, mm-hmm.
MARK WOEPPEL: So, what happens? You think the project’s going along, it’s going along; and then, you know, you’re coming to the due date of a critical deliverable. And it’s like, crap, we are not going to, then everybody runs around and tries to do that. So, what happens is that people are trying to manage tasks.
What I see is that project managers are focusing too much on the task level. And if we hit these dates, then everything else is going to fall into line. And of course, what happens in projects is things happen; right? I mean, you know, we ran a test procedure, and it failed, and we had to rework it; or the design didn’t work; or the innumerable things that happens in projects. So, the big thing is that what project managers don’t do is manage that little reserve of time that they have, the scheduled reserve…
BILL YATES: Yeah.
MARK WOEPPEL: …to the risk reserve. They don’t manage that really well. So, what happens is that, as project moves forward, that reserve gets chipped away and chipped away and chipped away, and then finally it’s gone. And then you’re going to be late, and then you have to explain. So, there are some behaviors that I’d look at to see are they going to be on time. Those things are more systemic in nature. The big thing is we’re not managing that buffer.
BILL YATES: Yeah, yeah. I get that. It’s like you have, you know, if you look at the details of a project schedule, you have slack. You have flow that’s there. It’s a tendency when you’re busy as a project team doing these tasks, you could kind of lose sight of, okay, it’s death by a thousand cuts; right? It’s like, yeah, I just – I lost half a day here. I lost a few hours here. This task took a quarter more than it was supposed to. But it’s not a big deal. It’s just one task. But those small cuts keep adding up, and then suddenly somebody looks and goes, oh, man, we’re like two weeks behind now.
MARK WOEPPEL: Yeah, exactly. And it’s usually not because something blows up. We’ve all been on projects where, you know, some weird event, you know, blew up the entire project. I’ve got a lot of experience in software in the oil business; right? So, you know, somebody’s going to write a big piece of code, and it just doesn’t work.
BILL YATES: Yeah.
MARK WOEPPEL: It just – it just doesn’t work. And it’s like 70% of the project. So, I mean, those things happen; but that’s not the reason why most projects are late.
BILL YATES: Yeah.
MARK WOEPPEL: You read Goldratt’s “Critical Chain.”
BILL YATES: Yeah.
MARK WOEPPEL: He talks a lot about task estimations gone wrong, that everybody buffers their task because they don’t want to be late because we beat people up when they’re late. So, they’re like, okay, they’re going to build that buffer. And what happens is that each task gets a buffer. And if he finishes early, he never reports that. That time never comes back to the project; right? So, the only thing that goes to the project is late. That’s the only thing that goes to the project, and it just accumulates. And then you get near the end, right, the last 20% of the project; and you realize, oh.
Schedule Transparency
BILL YATES: I’m with you. So, with “Critical Chain” and Goldratt it’s like, okay, sometimes the only news that we’re hearing as a project leader is the bad news of, okay, you know, I’m late, or my subteam is late on this piece of deliverable. It’s rare that we hear the, “Hey, good news, we finished this up in half the time that we estimated.”
And, you know, there are a number of reasons for that. Sometimes I feel like, I don’t want to share that information because then my managers will think I’m a rotten estimator, or they’ll think I’m gold plating or buffering stuff. But within the team, what are some techniques that the team leader can use to make sure that, when people do finish things up early, they share that with their leaders so that they can be reassigned or have things moved up on the schedule?
MARK WOEPPEL: I think the number one thing is to stop beating people up when they miss.
BILL YATES: Good point.
MARK WOEPPEL: Right? You know, a project is a project. Every task in a project is just an estimate. People generally don’t have good estimation skills. So, if somebody misses their estimate, the question is not, why did you miss your estimate? You know, that’s not the question. The question that a project manager should be asking is, how can we help?
BILL YATES: There you go.
MARK WOEPPEL: Do you need resources? Can I run interference for you? Is there something that’s blocking you that’s causing this? What can I do? And I think if the project manager fosters a problem-centric approach to the project, but at the same time, if we create the environment, we all agree as a team these numbers are made up. What really matters is that we do them as quickly as possible and meet the technical spec. And when we aren’t able to, you know, then the question is, how do we help? You know, I was working with a team, a semiconductor manufacturer, and they were building the chip, or they were designing the chip for one of the PlayStations. I don’t remember. But they were going from USB-A to USB-B. So, all of your hardware people will know what I mean.
You know, everybody’s, like, sitting around the table. We’re pulling the plan together. And the engineers are like, “I don’t know what’s going to happen because nobody’s ever done it this way before. And how do we deal with all the heat?” And what we ended up doing was we ended up creating a branch off of that. But the point was nobody was beating up the engineer because he couldn’t give a good estimate. The question was really, okay, what don’t we know, and how can we know it? And that turned the conversation around to, okay, well, here’s what we don’t know. And that identification process found its way into the project plan. So, we got a branch. If A, then we go this way; if B, they go this way.
BILL YATES: Yeah, sure.
MARK WOEPPEL: But, you know, Sony was pretty picky. They wanted that latest version. So…
BILL YATES: I think for some that are listening, that’s a different approach there. You have to go against the culture that may be at your organization where, you know, people are quick to point fingers and say, “Well, it was this department,” or “This group gave me a bad estimate.” You have to just get beyond that, look for the overall good of the project and create that environment of, okay, what is the obstacle, and how can we tackle it?
MARK WOEPPEL: Yeah, finger-pointing is toxic.
Minor Delay vs. Systemic Problems
BILL YATES: Yeah. I’ve got one other question I want to ask. You brought up this differentiation. How can project managers distinguish between what turns out to be a minor delay and something that is a systemic issue that could really derail the project?
MARK WOEPPEL: Oh, what I look at is I look at the project team and what are the behaviors they’re doing to manage this project. So, a lot of times what I see is project managers have meetings, and in these meetings, they do status updates. Because they’re doing status updates, what happens is the process, for the lack of a better term, the process is go to a meeting, tell why you’re behind, and give your reasons for why you’re behind. And then the project team goes off and does what they want. You know, I think of that as, you know, you’re trying to manage the past.
And really what project managers should be doing is look at what’s coming at them. And in my projects, we eliminate status meetings. We don’t have status meetings. We have action meetings. You come to the meeting; you’ve already reported your status. So, when you come to the meeting, everybody knows what the status is so you don’t waste your time. And the visual boards help a lot with that, as well; right? So, you know, a lot of times you walk by the board, get a quick view, and then go into your action meeting process. So that’s one thing.
The other thing that I’m looking at is internal conflict, functional conflict. And I see this a lot in construction projects where you’ve got the supply chain organization. They’re the people that are buying all the stuff. They’re hiring the suppliers and that sort of thing. And then you have the project team, and the project team is working on a timeline. The supply chain team, their goal is to get it as cheap as possible within certain parameters.
BILL YATES: Sure.
MARK WOEPPEL: But their goal is not to finish the project. Their measurements are completely different in engineering. You know, their goal is not to finish this project because this is one of many. So, we see this a lot in matrix organizations where they have kind of these conflicts where really the only one who’s on the project is the project manager. Everybody else is kind of like doing their own thing, and then they come together. So, this is one thing that I’m looking at as sort of a systemic problem; right?
BILL YATES: Mm-hmm.
MARK WOEPPEL: Because when that happens, what you get is delay. You have a hard time getting resources. You know, you have to do a lot of negotiating. So, the project manager becomes more like a beggar. These are just a couple of the things. Oh, priority switching.
BILL YATES: Yeah.
Priority Switching
MARK WOEPPEL: This is huge. All right. So, one of the things that we see is, if your project is in good control, then you’re going to be able to set consistent priorities for the resources assigned to that. If your project is out of control, you’re going to be changing priorities daily or weekly. Oh, I know I told you to do this one yesterday, but I got a phone call or whatever it is. And now this thing is done. So, the engineer or the supplier who’s already halfway through the thing that you thought was hot has to stop, set it aside, and then start on another one.
And that stopping/starting business adds time to the project. That time is not in the project plan. You know, people make project plans with the assumption that I’m going to get a resource, they’re going to be full-time on that task, and it’s going to take this long. But when you start interrupting people with your switching priorities, then everything takes long. It’s not obvious. It creates additional work for the resources. And as a result, the task duration increases, as well. Those are a handful.
BILL YATES: Mm-hmm, those are good. Those are really helpful.
Early Warning Signs
WENDY GROUNDS: Mark, I have a question for you. What are some of the early warning signs that a project is heading off track, and how can a leader respond to that proactively?
MARK WOEPPEL: Ooh, okay. Early warning signs. Are you changing priorities every day, every week? Are you spending all of your time negotiating for resources? Or are you having conflicts with resources? Right? So, I need a senior developer to do this part of the code, but he’s busy doing another thing, and I can’t get him. It’s on the schedule for this certain slot or whatever. It’s actually the project has stopped because we can’t move the project forward. So, this is something that we look at. When you know that the people on the project team are not on the project, that’s the biggest thing that you look for, where they’re not committed to the objective of completing the project within the parameters that are established from the spending specification, et cetera, et cetera. So, yeah.
I guess one other thing, too. Wandering bottlenecks. This resource was the bottleneck last week, and now this resource over here is the bottleneck now. And now we’ve got this problem over at the supplier. So, we kind of have this wandering effect. You know, if you’ve got a real bottleneck in the project, all right, that supplier or that resource is going to come up almost every day in the meetings. It’s like, this is where our problem is. But if you don’t, if you’ve got multiple people over time, that’s telling you that you are not in control of their project, and it’s going to go off the rails because you’ve got people that are not in your project.
So, from a project management standpoint, I think, you know, the cure is really getting service level agreements from your resource managers, all right, saying I need this resource approximately in this timeframe, and I need them all the time, and the resource manager agrees. And that way, if something happens, you know, then the resource manager has to come back to the project team and say, hey, I told you I was going to have this person or this resource. I don’t have it. And then, well, okay, how can I help?
Kevin and Kyle
KYLE CROWE: Agile is a popular approach to project management. It places a strong emphasis on swiftly delivering value to both organizations and customers, regularly adjusting project scope and priorities, and allowing for the breakdown of large projects into more manageable tasks. You’ll also find that typically Agile teams are highly collaborative and constantly work to improve team performance. Agile is typically associated with software development and product development, but it can be much more. Its simplicity in implementation makes it accessible to a wide range of organizations, all of which stand to benefit from its adoption.
KEVIN RONEY: Alan Zucker offers an excellent course via Velociteach where you’ll learn the key concepts and practices associated with Agile, while gaining confidence in your ability to work effectively in an Agile environment. The FUNDAMENTALS OF AGILE course will introduce you to the principles of collaborative and value driven development. In addition, you’ll learn about the most popular Agile methodologies: Scrum, Lean, Kanban, and eXtreme Programming (XP). So, whether you are new to Agile or need a refresher on the foundations, this course is for you!
Visual Project Board
BILL YATES: Yeah. Mark, I have a question. And when you gave us the first example, I think you touched on this. The question is when a project is already delayed, what’s the first step in turning things around? When you were talking through that example of that project, you mentioned a visual board. And I remember referring to that in the book, the visual project board. You know, okay, some of the first steps that you take in a project that is delayed, talk about using this visual project board. I think it might be a new concept for some of our listeners.
MARK WOEPPEL: The visual project management board, really, people are familiar with kind of the whiteboarding or Kanban boards. And usually what we’re doing, and we do this on every project, is we will take that project plan and kind of distill it down into lanes and columns. And I put the process in the back of the book. I think it’s in the Appendix, I think. But the idea is that what I don’t want to do is take the entire team down into every detail of the project; right?
BILL YATES: Yeah.
MARK WOEPPEL: You know, for some projects there are thousands of line items in your schedule; right? Or even hundreds. And even hundreds is too hard for somebody to manage. So, we’ll kind of chunk that down. So, one project that we did, we actually had 450 projects that they were running at the same time. What we ended up doing was we built a board, not at the project level, but at the portfolio level.
BILL YATES: Okay.
MARK WOEPPEL: And so, we would take – each project had a card, at least one card, say, okay, this is like the electrical element of this project, or this is the mechanical element, or this is the design element. And we would build the rough process of, okay, well, how do we manage the mechanical? We get the supplier, they build the product, we test it and so forth. So, we kind of defined those management points for the project. Part of that making it visual is just cards and lines and columns and setting up decision points. I called it earlier, I called it “stage gated.”
BILL YATES: Yeah.
MARK WOEPPEL: It’s more of a, you know, not everybody manages by stage gates. But if you want to manage a complex project, you should have decision points built in. And those decision points are typically handoffs from one function to another function; right? So, it’s going from design into test, or it’s going from production to assembly or something like that. So, we build kind of these decision points. And so, I don’t concern myself with the details because the details are managed by the resource. Somebody’s accountable for that piece. So, we don’t need to bring every detail on how do I build a house to my project meeting.
I don’t need to know, okay, I need to bring my framing guy and my roofing guy; and, you know, they can manage all the details of what two-by-fours go where and for that kind of stuff. That becomes the tool that we can manage execution because then that allows us to visualize the progress of the work; and we can see, okay, this one stopped. And once we’ve got that process, then we can start to do more risk management on the work that’s in process. So, we get our guys to say, okay, here’s the task that’s coming up. If you think there’s an unresolved issue, I want you to flag that and start thinking about risk management from a day-to-day standpoint. Because you know what happens with risk management, you know, we make a spreadsheet at the beginning of the project and…
BILL YATES: Then we’re done.
MARK WOEPPEL: No one ever looks at it again; you know.
BILL YATES: Yeah. Right.
MARK WOEPPEL: So, you know, the visual project management process is really, you know, making the board. But the board is really the, I want to call it the “leverage point” that allows you to do certain behaviors.
BILL YATES: That’s a good word, yeah, yeah, yeah. Because you talked about ownership, and then you talk about raising awareness, and even using colors on that board that’s very much like a Kanban board.
MARK WOEPPEL: Yeah.
BILL YATES: So, then you can see where are things stuck, and who owns it. You know, and it is visual, you know, to your point. It’s right there where everybody can see it.
MARK WOEPPEL: Yeah. And it’s a shortcut. It’s a shortcut for the project manager and the team; right? Because you are no longer spending time figuring out where is stuff. And for stakeholders, too, we did a project for – there’s a big engineering firm, and I cannot remember the name of the firm. But what would happen is like the top guy would walk into where this board was. And he would see where all the work was in his system. And he could bring his customers in there, and they could say, okay, here’s where we are in the system. So, it becomes a communication tool.
BILL YATES: Yeah.
MARK WOEPPEL: Right? I can’t say enough good stuff about visual project management.
BILL YATES: That’s good.
Maintain Team Morale
WENDY GROUNDS: Let’s talk a little bit about the psychology behind this. It’s a challenging time for everybody if you’re recovering a late project. How do you maintain the morale of your team?
MARK WOEPPEL: Yeah. What a great question; you know? Because when your project is late, everybody has this feeling of defeat.
BILL YATES: Yeah.
MARK WOEPPEL: They’re being micromanaged. Because they’re behind, they’re getting all of this unwanted attention. They don’t want all this attention. So, the thing that we do about building the board changes the team dynamic. So, there’s a couple of things. One, like I touched on earlier, we don’t beat people up when they’re late, when it takes longer.
BILL YATES: Yeah.
MARK WOEPPEL: Two, we get people away from reporting what’s wrong, preparing a plan to do something tomorrow. The worst time to do a project study is during the life of the project, do a postmortem. The best time to do a postmortem is when it’s done, not in the middle of the project.
BILL YATES: Mm-hmm.
MARK WOEPPEL: And so, you know, we stopped doing postmortems. We stopped giving reasons. The reasons are there to drive action; right? So, if you say, hey, I’m late because so and so is on pregnancy leave, you know, this supplier got overbooked, or some foundry blew up in India, now they can’t get these parts. Okay. So, the psychology of the project has to shift from the “I made a mistake, and here’s why I made that mistake,” to “Okay, here’s our problem. How can we best address that problem?” And then start getting people to talk to each other.
So, one of the things that we do, when we’ve got that board, we get people to stand up in front of that board, and we say, “Hey, this one here is stuck. What kind of help do you need?” And that person in purchasing might say, “Hey, I need this.” And some other team member will say, “Hey, I think I can fix that,” or “I’ve got extra resources. If you want extra resources, I can give you somebody for a week.”
BILL YATES: That’s good.
MARK WOEPPEL: And we start to foster that collaboration. And you know, in my book I call it “basic collaborations.” Projects are collaborations. Recovering from that sense of defeat, once they start seeing that things are moving forward, you know, when the projects are moving forward, the team starts to get a sense of, okay, we’re back on track. Even though the data is still out there, and we’re not sure of when we’re going to deliver, at least we’re moving. Projects that are behind are stuck.
BILL YATES: Mm-hmm.
MARK WOEPPEL: And so, we’ve got to get people to get that sense of we’re moving ahead; we’re getting things done; we’re getting the right things done; we’re helping each other.
Rebuilding Trust
BILL YATES: Yeah, it’s collaboration. Mark, one of the points I wanted to have you hit on, it’s related to this idea of, okay, if my project falls behind, I’m the project leader. So, I feel like I’m losing a little bit of trust with key stakeholders. What are some effective strategies to rebuild that trust? And I think part of that comes in terms of how I share that news about the delay with those key people. So, what advice do you have for me as a project leader in terms of how I share that news with my customer or key stakeholder?
MARK WOEPPEL: Yeah. Well, first of all, you’re not late until you’re late.
BILL YATES: Okay.
MARK WOEPPEL: Meaning the date for the project completion has passed; right? Until then, there’s only a risk of being late.
BILL YATES: That’s a good point.
MARK WOEPPEL: All right. So, what you as the project manager should be doing from day one is reporting what you think is the risk of delivering late, and what you are doing to mitigate that risk. If you need help, then you should be raising your hand. Hey, I need help with, you know, this manager or this supplier; or we’re under-resourced here.
We’ve got a priority conflict between my project and the other project. And that kind of communication is not a failure on the part of the project manager. You’re being proactive. You’re just saying, okay, we think the risk for late delivery is high. And if we keep going as we’re going, if something doesn’t change, we’d probably be two weeks, three weeks, four weeks late, whatever that is. But you’re not late until you’re late. So, the question of when is this project going to be done, there’s never a firm date.
So, what you as a project manager need to shift your mindset a little bit because remember what I said earlier, every task is an estimate. The entire project plan is an estimate. So, we estimate that we’re going to be done here, and we’ve got 90% confidence in achieving that date. So, you as a project manager, if you’re managing that risk, that delivery risk every week, and in your reporting, you can say, well, our risk is up; our risk is down. Here’s where the risk is; here’s what I’m doing to mitigate that risk. That tells your sponsor and your customer that you’ve got a handle on the project, and you’re setting the right expectation; right? So, you’re not saying I’m going to be delivered here.
For example, let’s say that in the oil business, if you’re drilling a well, the most important date is first oil; right? So, there’s a whole bunch of activity that goes into drilling a well. Once oil is out, then a whole bunch of other things have to happen. You’ve got to cap a well. If the oil’s coming out of the ground, you can’t stop it. So, you’re drilling a hole in the ground. And when the oil starts coming out, you know, you’ve got to be able to hit that. So that date is a really important date for the “post” or what we’ll call the “completion” activities; right? Completing the well.
So, a lot of times there’s a big price for that completion, particularly in subsea. Millions of dollars are at stake for that date. So, if your confidence is low, you know, one of the things that can happen is, when you report to your sponsor, hey, you know, my confidence is low, here’s where the risk is, and it’s going to cost me X to mitigate that risk, then you can have a rational conversation about what do we need to do? Is it worth spending money?
BILL YATES: Yeah.
MARK WOEPPEL: Do I need to move that date? So, the idea for the project manager is not to say, you know, you’re not a slave to the project due date. Typically, what you are a slave to is the performance of that project, if it’s a feature or software or, you know, a machine or a building that has to function a certain way. But that date and the budget are both kind of guesses.
So, you know, you want to be rational about that and think, okay, well, you know, I know it’s an estimate. I have a 90% confidence that we’re going to hit that. If we want to get to 50% or 100% confidence, then these are the things that we need to do to fix that. And that tells your customer, your sponsor, that you really understand the project, and you are sensitive to their requirements; right?
BILL YATES: Yeah.
MARK WOEPPEL: Yeah. And the same thing works on technical uncertainty as well; right?
BILL YATES: Mm-hmm.
MARK WOEPPEL: So, you know, I talked about that chip, you know, there’s a lot of technical uncertainty if you’re making something new; right? So part of the management is how certain are we, and what can we do to drive that uncertainty out? And it’s a completely different way of thinking about your project, you know, deadlines and tasks, more of a probabilistic rather than deterministic mindset.
BILL YATES: Yeah. And it sets up a very valuable conversation; right? Then you’re just talking through options with that customer or key sponsor. I like that.
Preventing Delays
WENDY GROUNDS: Another thing to consider is let’s make sure these delays don’t happen. Do you have any advice on how to create some process to prevent these delays from happening in the first place?
MARK WOEPPEL: I would say, first of all, that you have an agreement on how the project is going to operate.
BILL YATES: Mm-hmm.
MARK WOEPPEL: In particular, a well-articulated escalation process.
BILL YATES: Yes.
MARK WOEPPEL: Let’s say that you guys are on my project team, and one of you is in software, and one of you is in hardware; all right? And you have certain resources. And I’m the project manager. Your people are on my team. So, my agreement is with you because I want my team to behave in a certain way. You know, the thing I want my team to do is, when you have work, work as quickly as possible. If there’s a problem, raise your hand. And really those are the two things that I want.
But for the resource manager, for you, I want to have an agreement. Hey, if I’ve got a problem, I need to have a way to escalate. If we disagree, like let’s say that I’m a project manager, and you’ve given me three people. And you’ve got another project that’s running through your organization, and you’ve got six people. Well, all of a sudden you don’t have the three people that I have. My project has a high priority, but I can’t get the resources, so my project is stopped.
Okay. What happens? You and I have a conversation, say, well, this project A is a higher priority so I can’t give you those resources. So, then what happens? Do I just go back to my cubicle and cry? No. What you and I have is an agreement then to say, okay, if we disagree on the priorities, then let’s take it up to the next level of management and let them, you know, make that decision for us. That takes out the blaming of, you know, you’re a bad guy because you’re not giving me my people.
BILL YATES: Yeah, sure.
MARK WOEPPEL: And I’m a bad guy because you keep pushing me around and telling me how to do my job; you know. You’re not running my department. Having that escalation process removes that conversation.
BILL YATES: Yeah, it’s good for all parties. I’m with him, yeah.
Contact Mark
WENDY GROUNDS: If our audience wants to get in touch with you or find out more about what you do, where should they go?
MARK WOEPPEL: I have a website. It’s called ProjectsInLessTime.com. There’s a contact form on there, or you can send me an email. It’s just mark@projectsinlesstime.com. And if you want to dive deep in the methodology, you know, obviously the book that we were talking about, “Rescue Your Late Project.” My other book, “Visual Project Management,” really dives into detail on the, you know, the principles of visual project management. And that’s the book about principles. The “Rescue Your Late Project” is more tactical, to pull the project out of the ditch. And I’m always available for email discussions. And you can find me on LinkedIn, you know, and on X. I’m on X, too.
BILL YATES: Well, Mark, this is content that’s relevant to every project leader. You know, we can kid around and say, all of our projects are either late or about to be late. It’s one of those things that we all have to deal with. It was funny. We were talking offline. We even tend to be, you and I, we tend to be suspicious if a project’s going to end early. We’re like, oh, okay, what happened?
MARK WOEPPEL: Yeah. Yeah.
BILL YATES: You know, something got cut. So, this is a reality that project leaders deal with. And I appreciate you sharing the takeaways, the lessons learned that you had through your experience. So, thank you so much for codifying it and sharing it with our group.
MARK WOEPPEL: Hey, you’re welcome. Like I said earlier, I’m happy to share my experience. And that’s why I wrote the book was really – it isn’t a sales brochure. It’s more of a, this is what I learned, and I hope somebody else can learn from it, too.
Closing
WENDY GROUNDS: That’s it for us here on Manage This. Thank you for hanging out with us today. It’s always a pleasure to have you along for the ride. 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 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, keep your projects and coffee cups filled to the brim. Stay curious, stay inspired, and keep tuning in to Manage This.
Leave a Reply