Bob Jewell reveals his no-nonsense guide to Pursuing Project Excellence in project management. He advises how to steer clear of common pitfalls, and why he avoids the term “scope.” He discusses underrated tools, challenges the practice of building schedules backwards, and shares fresh perspectives on the work breakdown structure, the critical path, and the crucial handoffs that can determine a project’s success.
Chapters
00:00 … Intro
01:21 … Meet Bob
04:40 … Global Experience
06:08 … Pursuing Project Excellence
08:56 … Execution Pitfalls
10:00 … When to Let Go
11:09 … Scope Creep
15:42 … Undervalued Tools and Processes
18:06 … The People Side
19:05 … Overrated PM Tools
21:19 … Multiple Critical Paths
22:41 … Transitional Periods
24:54 … Transitional Deliverables
28:15 … Never Build a Schedule Backwards
31:27 … Get in Touch
33:12 … Closing
Intro
BOB JEWELL: …you came in on budget, you came in on schedule, and the customer was thrilled. Now, all of us know that the odds of those three things happening are rare. But when they do, I think you’ve seen excellence.
WENDY GROUNDS: Welcome to Manage This, the podcast by project managers for project managers, and we’re thrilled to have you joining us today. I’m Wendy Grounds, and in the studio with me is Bill Yates.
If you would like to reach out to us, please leave a comment on our website or on social media. Your feedback helps us pursue project excellence, which is what we’re talking about today.
BILL YATES: Well-played, Wendy. Yeah. We have the privilege of talking with Bob Jewell, and he wrote a book called “Pursuing Project Excellence.” Now, he’ll tell you this is just a small book. It’s less than a hundred pages. It’s “Six Ideas to Improve Your Projects.” And this comes from a guy who’s had, I don’t know, 40-plus years’ experience in project management?
WENDY GROUNDS: He has, yes. He has spent four decades navigating the highs and lows of managing projects. He’s worked with industry giants like GE, Toyota, Sherwin-Williams, as well as FedEx. He’s the founder of the Omega Leadership Group, and he’s helped many professionals sharpen their skills. And he’s here to share his hard-earned wisdom.
Hi Bob. Welcome to Manage This. We’re so excited to talk with you today.
BOB JEWELL: Thank you.
Meet Bob
WENDY GROUNDS: Can you tell us about your journey into the world of projects? How did you begin in project management?
BOB JEWELL: Well, I wish I could tell you I’d laid out a solid schedule, but I fell into it.
WENDY GROUNDS: So many say it was by accident.
BOB JEWELL: Yeah. I only meet a few people that actually plan this. And it’s – I think it’s just ironic; isn’t it. But I graduated from Ohio State University with a degree in engineering in 1980. And first of all, embarrassment to tell you that I went through an engineering program and never got a class on project management. I can tell you that I fixed that because later when I got to serve with the ABET organization, ABET Accredit – it stands for Accreditation Board for Engineering Technology – that writes the standards for accreditation for engineering schools, I made sure that that changed.
You know, believe it or not, there were civil engineering programs in the United States that didn’t have requirements for project management. And you think of what a civil engineer does. I came out with a very – a very unique engineering degree. Ohio State has a welding engineering degree. One of the only schools that has an ABET accredited degree in that field.
So anyways, I went to work for a company that was a projectized company, meaning that’s all they did was project work. They happened to build hydroelectric turbines all around the country and all around the world. They were one of really only two companies in the world that took on the big hydro projects. So of course, immediately I’m thrust into the project world in the workplace and was responsible for a few projects. Eventually, some of those projects took me around the world.
But luckily, I was around a couple people that had managed the projects for years. And they were really my first exposure to project management. And they said, if you ever, ever get a chance, take a project management class. And I think it was, wow, so 1986 or ‘7 that I sat down and actually took a first class in it. And I remember just, again, saying, I wish I would have had this as part of my engineering degree. So that’s kind of how I got exposed to it.
At the time we had just won a contract, it was in the millions, to build the hydroelectric turbines that went in the Aswan Dam in Egypt. So, you know, those were kind of cool projects. Another project was down on the Alicura River that comes off the Andes Mountains in South Argentina. We got the hydroelectric turbine project for that. So of course I joke about this, but I’m one of the few people that actually can claim I’ve had dam projects.
BILL YATES: Bob, it’s interesting. You know, for years I had the privilege of working with Louis Alderman, and he was a gosh darn engineer from Georgia Tech.
BOB JEWELL: Okay.
BILL YATES: An electrical engineer. You know, what you said just sounded just like Louis. He was an engineer by training. And then with HP, they basically put him deeper into engineering. And he was working on hardware mostly, and he said there was a beauty to project management. It just opened his eyes as he got exposed to more and more project management. You know, the engineering part of his brain, similar to yours, things just click into place. There’s a systematic approach to what you’re doing that just really clicks into place. So, I get what you’re saying, you know, and how you started.
Global Experience
One thing that’s unique with you, too, is the global experience that you’ve had and the opportunity to be in different countries…
BOB JEWELL: Yeah.
BILL YATES: …and work in different areas, that’s – I’m sure that certainly added some depth to your experience, especially at an early age in your career.
BOB JEWELL: Well, I remember asking one time how I got lucky enough to get one of the overseas assignments. And my boss told me that I met the one most important criteria. And I kept thinking, wow, that’s like communication skills, leadership skills.
BILL YATES: It was you got a [crosstalk].
BOB JEWELL: I know how to build great Gantt charts. And after I said all that, he looked at me, he says, you’re single.
BILL YATES: You’re single. Okay, yeah.
BOB JEWELL: You know, I ended up leaving that company because I thought I probably will never be other than single. It’s funny, the Alicura project in South Argentina had started right before the Falkland Wars. The British were involved in that. But we were down there wondering if the Americans would get involved or not. And if they did, how would that affect our project? Because eventually the Argentineans quit sending us supply trains because they were routing all the trains to the coast.
So, one thing about being involved in world projects is many other things affect a world project other than maybe lack of resources. You know, who would think wars and politics would affect the projects you’re involved in?
BILL YATES: They certainly do, yeah.
BOB JEWELL: Yeah. And I don’t know how you build those into Gantt charts.
Pursuing Project Excellence
BILL YATES: Yeah. Okay, I’m holding a copy of “Pursuing Project Excellence: Six Ideas to Improve Your Projects.” I really enjoyed going through this. And one of the things that you do early on in there is you define excellence in project management. Just for our listeners, how do you define that?
BOB JEWELL: Well, first, let me make a comment about the book. My original title was going to be “The Project Heretic.”
BILL YATES: Yeah.
BOB JEWELL: But the problem that people told me is not everybody understands what a heretic is. And some people have a really bad thought about what it is.
BILL YATES: Right.
BOB JEWELL: And I gave an example in the book of Galileo being considered a heretic because he claimed everything revolved around the Sun. And that wasn’t the thought at that time. The thought at the time was everything revolved around the Earth. So, to me, a heretic was just somebody who espouses something a little bit different that maybe not everybody agrees with, but eventually proves to be true. But she talked me out of the title, but I still had to put it in the story, in the intro.
BILL YATES: I like that.
BOB JEWELL: Because even a good friend of mine said, “Aren’t heretics people that are burned at the stake?” Probably not the lasting impression you want to give a future project manager; right?
BILL YATES: That’s true. That’s true.
BOB JEWELL: Is that they’ll get burned at the stake for what they say. To go back to your question about excellence, I think, first of all, I think excellence is hard to define. It’s almost something you don’t realize until you see it.
You know, in project management, it’s just like a lot of things coming together that you didn’t think would come together with some hard work behind it. But if I had to really put a definition on excellence, it would be built around you came in on budget, you came in on schedule, and the customer was thrilled. Now, all of us know that the odds of those three things happening are rare. But when they do, I think you’ve seen excellence.
BILL YATES: Yeah.
BOB JEWELL: On budget; on schedule; and, most importantly, the customer walks away, you know, thrilled with what you did. Sometimes they can be thrilled, and you don’t necessarily hit budget or schedule. But I think when you hit all three of those – and I’ve had one or two chances in my career to hit all three of those at the same time – at that point you’re kind of thinking, maybe I should retire.
BILL YATES: Right. Go out ahead.
BOB JEWELL: But then, like all project managers, we turn around and try to do it again.
BILL YATES: Yeah.
BOB JEWELL: But, you know, early in my career, mediocrity just wasn’t a word or an environment I wanted to be around. So, I would just push and try to do things the best way I knew how to do them, and try to get people around me to want to do that, too. And I’ve learned later that not everybody pushes for that. You know, some people are just going to try to get through it. And maybe because their busy schedule, other things going on. But, you know, I was around some projects that weren’t excellent, and those were hard to be around. They’re the old fingers on the chalkboard projects.
BILL YATES: Yes, yes.
Execution Pitfalls
WENDY GROUNDS: Another thing to look at is also pitfalls. What are some common execution pitfalls that you’ve seen, and how can a project manager get around those?
BOB JEWELL: You know, let me maybe answer that question a little bit differently than maybe you expect. To me, the pitfalls in execution start with what happens before execution. You know, there’s always going to be surprises during execution. There’s going to be risk events that you don’t anticipate. There’s going to be people that make changes. You know, those two things right there to me are the biggest pitfalls.
There’s always people that yank resources away when a project’s underway because another project’s taken priority. To me, the biggest pitfalls I see in execution are, frankly, really poor planning. And then you pay the price for that when you get into execution.
The planning will pay off. And as a consultant where I saw pitfalls the most in execution was because of lack of or poor planning that was done prior. Other than the occasional changes in risk that are going to happen, unknown things that you really can’t think or plan too much about.
When to Let Go
You know, I remember a project where one thing that happened during execution nobody anticipated was a technology change occurred. And so literally almost everything we had done up to that point was obsolete. And I remember thinking, well, the company surely is just going to stop this project because it really doesn’t pay off to go forward, if this new technology is basically obsolete. But they wouldn’t let go of it for some reason.
BILL YATES: Huh. Wow.
BOB JEWELL: And I thought, why are you not letting go of this project?
BILL YATES: Yeah.
BOB JEWELL: So maybe that’s another pitfall is latching onto a project and not being willing to let go when things tell you to let go.
BILL YATES: Yeah.
BOB JEWELL: And then there’s times to let go of a project.
BILL YATES: Yeah, for sure.
BOB JEWELL: It may not be just technology change. It could be differing priorities, availability of resources, pandemics. I mean, but I still can’t figure out why people find it hard to let go sometimes. Like we started this thing, the fuse is lit, so we’ve got to let it go to where it goes. No.
BILL YATES: We don’t.
BOB JEWELL: No. Oh, we spent all this money. You know, if we stop now, we’re going to have to account for all of this. I said, well, pretty easy to account for. It’s not worth spending any more.
Scope Creep
BILL YATES: Bob, one of the contrarian stances that you take in the book…
BOB JEWELL: Oh, no.
BILL YATES: …is not liking the word “scope.” And I like what you had to say about that. So, I want you to explain yourself. Why do you not like the word “scope”?
BOB JEWELL: So, first of all, usually the first person that mentions scope in my room gets a little bottle of Scope mouthwash?
BILL YATES: Yeah, that was good. That was good.
BOB JEWELL: Well, I found it’s a word that many people have different definitions of. And even the Project Management Institute, I’m not sure about the current PMBOK, but I know the previous one had about six different definitions of scope. They had project scope, they had product scope, they had just scope, and then maybe two or three others. So, what caused my concern about it is, when I was in a meeting, and people were using it, I could tell that not everybody in the room had the same definition. So, I think that means we’re miscommunicating.
BILL YATES: That’s right.
BOB JEWELL: So, for instance, a technical person, say an engineer, might really attach the word “scope” to requirements, where more of a senior manager may attach scope more to the goal of the project, what we’re trying to achieve; right? So, I would listen to these conversations, and I realized, you know, we’re all throwing around this word, but we’re not all on the same page with it. So why use it at all, if it’s a word that creates that kind of confusion?
What I found is when people reference scope, they reference one of three things, maybe even a combination of these three: goal, deliverables/requirements, and activities. They’re either referencing one of those, or maybe a combination of them.
So, like I said, a lot of technical people will attach the word “scope” to the requirements associated with deliverables. Senior level people will typically associate scope with the goal objectives of the project. PMI actually, in one of their definitions, attaches scope to the activities of the project; right? Because they actually call the work breakdown structure the “scope-defining document.” Their definition of it in the PMBOK says it defines the total scope of work.
Well, you know, then I’ll meet people that say, no, the charter document defines total scope of work. So that’s the kind of confusion that I saw in the field. So, I just decided not to use it. Why replace the word “requirement” with scope? Just say requirement. Why replace the word “goal” with scope? Just say goal. Why replace the word “activities” with scope? Just say activities.
BILL YATES: Right.
BOB JEWELL: Let’s say I’ve got activity creep, or I’ve got goal creep, or I’ve got requirement creep. Right? You say “scope creep,” and I have no idea…
BILL YATES: You don’t know which one you’re referring to.
BOB JEWELL: …what’s creeping unless I know more about how you define the word “scope.” Would you agree with that, kind of that confusion?
BILL YATES: Yeah, I do. It certainly makes sense to me. And I like your takeaway in the book on it. Your bottom line is let’s make sure the team is on the same page in terms…
BOB JEWELL: Right.
BILL YATES: …of definitions. That’s one of the beauties of, you know, having teams get together and go through training together or have kickoff meetings is, you know, you set those expectations, and you clarify what…
BOB JEWELL: Right.
BILL YATES: …things are going to mean.
BOB JEWELL: Yeah. And again, PMI really calls the work breakdown structure the “scope-defining document.” I would disagree with that. I would say the charter is more in line with Webster’s dictionary definition of scope. And the main purpose of the kickoff meeting is to really wrap your arms around the scope of the project. Right? It’s we’re going to the moon and coming back. Three astronauts are going to be involved in that. That’s truly Webster’s dictionary.
We’re having a picnic. Okay. Is this a company-wide picnic for 700 people, or is this a barbecue for four of your friends in the backyard? We need to understand that upfront because that description has a big impact on the project. So, yeah, I guess I’m not anti-scope. You just won’t hear me use it. And if I hear it used, I’ll usually call a timeout and say, “Could you give me your definition?” And I think I could have wrote a chapter in the book with all the different definitions of scope that I’ve heard.
BILL YATES: Yup.
Velociteach is a community of hard-working team members, here to support your growth and success. InSite is our project management mobile learning platform where you can prepare for your PMP certification or get better at your job by choosing from over 70 high quality and engaging courses. These courses cover a variety of topics such as communication, leadership, status reporting, the work breakdown structure. Each course aligns with a PMI Talent Triangle, making earning and reporting PDUs easier than ever. Visit us at velociteach.com today to get started.
Undervalued Tools and Processes
WENDY GROUNDS: Bob, won’t you tell us what, in your opinion, are some of the undervalued tools or processes in project management?
BOB JEWELL: I always separate projects into two things, and I give these two things equal weight: the process side and the people side. So, when we address that question, we have to look in both of those buckets, in my opinion. On the people side, I mean, there’s a four-hour conversation. So, let’s go to the process side for a minute. On the process side, my experience tells me work breakdown structure is the most underappreciated tool in project management. And my experience in actual projects tells me it’s the most important tool.
Now, I put a lot of emphasis on project charters upfront, but that’s because the charter – which in my opinion answers two questions: Why are we doing the project? What specifically has to get created? So, the goal and objectives and the deliverables and the requirements are addressed in the charter. Charter’s important because if I’m going to accurately identify activities, I need to accurately know what the goal and deliverables and the requirements are. So, the charter is important, but it’s only important to me because the document that I create from that document, the work breakdown structure, is the most important document.
And the case for that is very simple. If you don’t know the activities in your project, you’re going to have a hard time coming up with an accurate budget. You’re going to have a hard time coming up with an accurate schedule. You’re going to have a hard time coming up with an accurate understanding of the people and resources you need to get your project done. And I would say those are three major things you don’t want to fall short on. Now, it may not be your fault that the work breakdown structure is not accurate.
BILL YATES: Yeah.
BOB JEWELL: It could be you’re on a project where you don’t understand 70% of the project. You don’t even know you don’t understand it. So, I think you’ve got to be really clear to people. And this is one of the things I’ve stressed a lot. Just because we’re using project management doesn’t mean we’re hitting home runs.
You can put great charters together, and great work breakdown structures together, and beautifully laid-out schedules. But you could be very well in a project where you don’t know 70% of what you don’t know. And you’re not going to discover that until the project’s over with. I’ve had to give clients over the years that assessment and say, you know what? Even our best efforts, most of us, we’re only identifying about 50% of the work. We don’t even know what the other 50% is. Guess what? The good news is at the end of the project, we’ll know 100%.
BILL YATES: That’s so true.
The People Side
BOB JEWELL: I mentioned the people’s side of the project. And one of the things I like about the work breakdown structure is I can tie really well the people side of the project into that by having my team build it, and that really creates buy-in to the project. My favorite way to build it, I get my team in the room. There’s flipcharts hanging on the wall that has each deliverable. I’ve got somebody in the room already assigned to that deliverable. Hopefully that’s one of my team members, and hopefully they’re a subject matter expert.
And we just get out the Post-it notes, and we just start thinking of activities that we need to do to get that deliverable done. We write them on Post-it notes, and we put them up on the flipchart. And we may spend two days doing that and walk around the room and look at each other’s deliverables to make sure we’re not duplicating activities. But the way that I like to build the work breakdown structure also factors in the people side. And since I think it’s the most important tool for the process side, I’ve tried to make it the most important tool from a people side.
Overrated PM Tools
BILL YATES: Okay. Yeah. I certainly agree with what you have to say in regards to the work breakdown structure. I think it is one of the keys to success, and I really like that. Let me flip it. What do you think is an overrated tool in project management, or one that’s used that’s not understood?
BOB JEWELL: You know what my answer is going to be to this. It’s this critical path stuff; right? Give me a break. I get people to show up for maybe a two-day class, and at the first morning break of the first day, they come up to me in a very anxious way. “When are we getting the critical path? When are you going to talk about that?” I said, “Actually, after lunch tomorrow.” “Whoa, you wait that late to talk about critical path?” I said, “Well, can’t really talk about it till we get a kind of a schedule built, you know, plan put together, charter written, a work breakdown structure created.” “Oh, no, no. No, we don’t do any of that stuff. We just like critical path.”
I’m saying it’s overrated. My basis for that is the only time it’s going to be accurate is if you’re looking at 100% accurate work breakdown structure and you’ve 100% accurately sequenced everything. And you’ve 100% accurately put durations and start/finish dates on everything. So, what’s the odds all that precursor is going to be accurate is probably slim to none. So, I’m not saying it’s not useful. It’s definitely useful. But, boy, I’m convinced there’s people that have places in their house where they burn candles and worship critical path.
BILL YATES: Way too much value placed on that. I got you. Yeah, yeah.
BOB JEWELL: Yeah. And what’s funny is, for many people, it’s like the only thing they’ve ever heard about project management.
BILL YATES: Yeah.
BOB JEWELL: I mean, they haven’t heard of a Gantt chart, but they’ve heard of critical path.
BILL YATES: And I think for some people, they don’t think about all those important things that you have to do first to get to a schedule to even plug in the attributes of all these tasks and activities to figure out what a critical path is.
BOB JEWELL: Right.
BILL YATES: And, you know, to your point, if you’re not even agreeing on scope, if you don’t have a work breakdown structure, you know, how in the world can you think you’re going to have some kind of estimate on these tasks that’s even close to accurate?
BOB JEWELL: Right.
BILL YATES: So, yeah.
Multiple Critical Paths
BOB JEWELL: Yeah, I’m not saying it’s not useful, even in a project where you don’t believe you’ve identified all the activities. You know, clearly you can calculate a critical path, or the software will. I’m not saying it wouldn’t be helpful in some decision-making. But I think before you start getting too crazy with it, you have to confess it’s not accurate because all of our inputs that are necessary to calculate it are seldom accurate. But I think people knew that upfront. I wouldn’t say it’s not useful, but I meet people that, man, that seems to be their only focus.
I remember having a fellow once who told me – my definition on my slide said “critical path.” And I put, after path, I put an (s) in parentheses. And he says, “Why is that (s) there?” And I said, “Because you could have multiple critical paths in a project.” He says. “No, you can’t. There’s only one.” I said, “Really. There can only be one.” He says: “Yeah, there can only be one.” So we did an exercise later in the class where the exercise ended up with three different critical paths.
BILL YATES: Yeah.
BOB JEWELL: I remember saying to him, I said, “You got all three of these. So, you know, do you see what I mean by there can be more than one?” He says, “Oh, no, I’ll fix it so two of those go away.”
BILL YATES: Oh.
BOB JEWELL: Okay. All right. So, we start with three, but you can fix it so there’s only one.
BILL YATES: Go fix it.
BOB JEWELL: Okay, I’ll give you that. I’ll give you the ability to do that.
BILL YATES: Oh, that’s hilarious. Yeah, yeah, yeah.
BOB JEWELL: But you have to confess that we had three upfront.
BILL YATES: That’s right. Yeah, it’s math.
BOB JEWELL: Yeah.
Transitional Periods
BILL YATES: Bob, one of the things that I want to make sure we hear from you on, is about transitional periods and the transition that takes place. It’s just a natural flow of a project. I started laughing when I read this in the book because I’m like, this was, let’s just say, an area of growth for me early in my career.
I thought, heck, you know, we’re in here working with this client, and there’s three things that are going to happen. Either they cancel the project; we run out of money and just kind of finish and go, okay, we’re done; or number three, we run out of money at the perfect time, when we’re actually finished, you know, delivered, and have had a smooth transition. But man, that transition, sometimes it would suffer because, you know, we’d either get pulled in different directions or we’d run out of money on the budget or whatever.
So, talk to us about the transition, you know, both from a planning standpoint and then just some practical advice for project managers who maybe are not emphasizing that enough in their upfront planning.
BOB JEWELL: So, it takes me back to a project I was in. After I left hydroelectric turbine world, I went into the aircraft engine world. I argue it’s another turbine, just smaller and hotter and faster.
BILL YATES: Okay.
BOB JEWELL: But one project I was involved there was we had an outside company setting up a plant. And when they were done, basically finished with the plant, as I like to call it, they threw the keys at us as they were running away. Right? Their work was done. They’re tossing the keys so we could get in the plant.
But boy, we went into the plant, and hardly anything was working correctly, or we didn’t know how to work some of the stuff, because their contract was over. It was to build the plant, install the electricity, hydraulics and all that stuff, hand us the keys so we could get into the building, and then run away. And we ended up having to hire, under a new contract, them to come back. And they stayed with us for about three months when they came back because it took us about three months to get our feet on the ground with that new plant.
BILL YATES: Yeah.
BOB JEWELL: With their help, by the way. And I thought, I don’t want to ever do that. Any project I need to think upfront, are there some things that, even though I’m finished with them, when I give them to Wendy, she’s not going to be able to really assess them until she’s used them for a while.
BILL YATES: Yeah, mm-hmm.
Transitional Deliverables
BOB JEWELL: And so maybe another good example of that would be a training program. You hire me to put together a training program. I develop the PowerPoint. I put the workbooks together. I put the handouts together. I lay that all on your desk, and it looks beautiful. But until you really use it in a training class, will either of us really know? So, to me, that’s a transitional deliverable. I need to follow up with you. The project needs to remain open. Maybe it’s not open for the entire team, but it needs to remain open until a period of time goes past, and we can assess, does that deliverable really meet your needs?
Or let’s get together three months after you’ve used the training program and see if everything’s working the way you wanted it to work. Or, hey, I built you a plant, but I’m going to stick around for three months to make sure that everything’s working right, and you know where things are at and things like that.
Now, many projects don’t have transitional deliverables. I mean, I make what you want. You get it. The moment you see it, you fall in love with it. And I don’t have to ask you three months later, are you still in love with it? But I think there’s many that, until it’s used, and used for a while, you really can’t truly assess were all the requirements met.
And that’s what it really comes down to. When can you assess that all the requirements have been met? And I think if there’s any chance that there’s a time period to assess that, then that time period, in my opinion, needs to be built into the project. Maybe the final phase of the project is what that is, but it needs to be there. And I just have seen too many projects where people have run away too quick.
BILL YATES: Yeah, that’s good. We in the software world, we used to call it “throwing it over the wall.”
BOB JEWELL: Yeah. And a help desk would be a great example of a transitional deliverable. So, when I’m around projects and looking at charters, one of the things I always look for on a charter is how’s this going to transition? Like I’ll look at a charter where they’re installing a new piece of equipment in a plant. And I’ll say, “You know what? I don’t see anything in your charter about training the employees on this new piece of equipment.”
BILL YATES: Yeah.
BOB JEWELL: Go, oh, yeah, I guess we’d better do that. Yeah. I mean, just to install it and not train anybody on it, or think that that’s somebody else’s responsibility, if somebody says it is somebody else’s, then fine. We don’t have to address it. But I think that’s another example of where people kind of leave hanging over a cliff. Like, I installed the equipment. Oh, yeah, we probably should have trained some people on how to use it. That would have been a good idea. And then maybe stick around for a couple of weeks or months to see if everything’s working well.
And, you know, and I think we’re seeing maybe more of those types of projects where it’s not just as soon as you have it in your hands, I can walk away, and you’re thrilled, and we never have to talk again. So transitional deliverables, don’t drop the ball. It’s amazing how you can work so hard and then drop the ball right at the end when you hand off a deliverable that needs to be transitioned, but you don’t effectively transition it. That leaves a taste in a customer’s mouth that’s not always the taste you want left. I would argue, even if it wasn’t required under the contract, pick up the phone two months later, call the customer up and say, “How’s it working for you?” At best, that could be the start of a new sales opportunity.
BILL YATES: Yup.
Never Build a Schedule Backwards
WENDY GROUNDS: So, Bob, you challenged this common practice in project planning by stating that we should never build a schedule backwards. Why is that so problematic? Won’t you tell us why you build a schedule the other way?
BOB JEWELL: I think one of the most controversial things I say in the classroom is that I never build schedules backward. And, I mean, I’ve actually had clients come up to me and say they would prefer me not to say that in a classroom.
You know, that was one of the things I learned from a mentor very, very early in my career. And I didn’t understand why he was so adamant about it. He used to tell me that the only legitimate date in a project is the date you can start it. And that everything flows from that date based on natural sequences, durations, availability of resource and things like that. He told me never build a schedule backward from a date somebody’s given you that they want the project done. Build it forward from the date you can start it. See where that takes you, and then deal with it.
If it happens to go past when somebody expects it to be done, then we’ll have to deal with that. But you’re always going to make your best decisions from a schedule that’s built properly. It may not be what people want; but you know, this is where I love to do my Jack Nicholson, “You can’t handle the truth.” But learn to handle it because you’ll make better decisions in a project.
And I get asked all the time, is there any exception to that? Like, say you signed a contract with a $4 million penalty if you don’t hit a date to get the project done. No, I’d still build the schedule left to right. And maybe that schedule tells us we need to start sooner, but often that start sooner option’s not even available. It is what it is. So now you’ve got to figure out how to compress the schedule. And when you start compressing schedules, you put an impact on time, on money, and on quality.
So, yeah, we probably could have done a whole podcast on building schedules and not building backwards. But I wanted to let you know that’s probably the biggest thing I get pushback from in my classes, to the point where, like I said, I’ve had companies say to me, please don’t mention that in class. We build schedules backward around here. And I said, “So how’s that working for you? Why would I be here if it’s working well?” You know?
BILL YATES: Yeah.
BOB JEWELL: I helped a large automotive company put a plant together, and they so wanted to build that schedule backward. And I said, no, we’re not – you’re not going to do it with me. We ended up building it forward, and that schedule went about four months past when they wanted that plant online. And there’s no way we could accelerate this project four months from where we’re at. I said, “Listen, we’ll just have to find ways. I’m not saying it’s not impossible, but four months is a lot to shave off of a three-year project. So maybe we’ll find an opportunity.” Well, we were able to shave about a month off of it. It just got done when it got done.
So, I believe that you don’t build schedules backward. You build them forward. You live with the consequence of that schedule. If you have to compress it, there’s techniques you can use to compress schedules. But there’s always ramifications when you use those techniques. And I think people want to ignore the ramifications.
BILL YATES: Yeah. Yeah.
Get in Touch
WENDY GROUNDS: We’re almost out of time, Bob. And it’s been so good talking with you. If our audience wants to reach out to you, where’s the best place they should go to find out more?
BOB JEWELL: Well, I’ll give you an email that you can put up in your notes. rjewell@zoomtown.com
I retired two years ago. My wife doesn’t believe that yet, but – because there’s still a few things I’m hanging around and doing.
BILL YATES: Yeah.
BOB JEWELL: But I’ll leave you with my email, and people are welcome to get a hold of me via email. I’ve always donated the money from this book. There’s a great group up in Middletown, Ohio. Everybody knows Middletown now because J.D. Vance came from Middletown, Ohio. There’s a great place up there called Hope House, which is a ministry for down-and-out people. It does a wonderful job of getting those people off the street, getting them in an apartment there at the building. They have to have a job to be in one of those apartments. And so, I just – I’ve always donated the proceeds from the book to Hope House. I’m not going to retire off a $9 book that Amazon only splits half of it with me.
BILL YATES: That’s fantastic that you’re doing that. And again…
BOB JEWELL: Yeah.
BILL YATES: …thank you for putting it out there. Just putting on paper experiences that you’ve had and things that you’ve seen. Some of them are, you know, you could say they’re a little controversial, whatever. I like it.
BOB JEWELL: Yeah.
BILL YATES: It really forces people to think. It’s like when I read what you had to say about critical path. And I think our abuse of scheduling tools, it just totally made sense to me. I’ve seen people that they want to just chase after a schedule by just jamming information into it as quickly as possible, and then saying, well, this is what the computer says. Yeah, yeah, yeah. What does your brain say? Let’s step back a little bit. So I appreciate your approach with this, Bob, and your sharing it. Thank you so much.
BOB JEWELL: Thanks so much. It was great.
Closing
WENDY GROUNDS: That’s it for us here on Manage This. Thank you for joining us. You can visit us at Velociteach.com, where you can subscribe to this podcast and see a complete transcript of the show. You’ve also earned your free PDUs by listening to this podcast. To claim them, go to Velociteach.com. Choose Manage This Podcast from the top of the page. Click the button that says Claim PDUs and click through the steps.
Until next time, stay curious, stay inspired, and keep tuning in to Manage This.
Leave a Reply