Industrial Insights with Paul Lukehart

Paul Lukehart 00:38

yeah, absolutely a pleasure, Justin. Thanks for having me on. I was looking through your previous shows, quite a depth and breadth of subjects, so was really looking forward to it.

Paul Lukehart 01:07

All right, well, try not to disappoint today.

Paul Lukehart 01:43

Sure. Yeah, so why don't I start off with a little bit of history. The entry into project management was incidental. I started, as you mentioned, in logistics and supply chain. I got out of the Army, went to work with Target in a distribution center. I think it was TO593 out in California. And so I started as a supervisor with Target. Great experience, retail distribution. And then after that worked with Amazon as an ops manager out of the Fernley, I think now closed R &O one facility. And then after that, I took a job with a company called RailX, which was a three PL. And what they did was they did refrigerated produce transportation by rail out of California and Washington to the East coast. I started, I came on as a. yeah, everything. So like apples.

Paul Lukehart 02:38

carrots, onions, almonds, pistachios, grapes. They did wine, they did the occasional pallets of frozen squid, which you had to be really careful about so they didn't thaw, like really not great to have in the warehouse. And so it was like mostly West Coast, East Coast, a little bit of a backhaul back to West Coast with some select commodities. So there was mostly unloading of rail cars and then cross-docking or a few days storage of your produce. where you got it into trucks and then out to major like the East Coast, CNS, Hannaford, Stop and Shop, those types of and a lot of the Ahold brands up on the East Coast. I came on as a site manager for the opening of a Florida facility and so I come on with RailX and they have this 42,000 foot space down in Jacksonville, Florida and they say, guess what, you're the manager of the site, get this thing up and running. We have a lease, we think we have rack ordered, like get it going. Like you're coming on in February, needs to be operational in March, ready go. So it was get down, figure out, get some material handling equipment, hire the team, get the systems in place, do some preliminary testing and start receiving rail cars. And that was really kind of the first site startup project that I did.

Paul Lukehart 04:01

Right. So yeah, you had a rail siding. pulled up, I think that first building had four doors on a rail siding. So you open the door, the rail car is pulled up, you throw down a dock plate and you go in and you start pulling out pallets, which are stuffed into the rail cars. Really interesting and probably a unique real estate situation, like directly rail served warehousing is not extremely common. And so that was the first.

Paul Lukehart 04:29

real-site startup after Rayalex I went up and managed their other facility in near Albany, New York. It's connectedy and then after that went out to Colorado and ended up with through a Rayalex connection ended up at XP logistics and they said guess what you're gonna be a project manager and I said okay I don't know anything about formal project management but you know we've we've gotten things done before let's

Paul Lukehart 04:56

We can learn about status reports, we can learn about the formal program setup. And so at XPO, as a project manager, I started out as a PM on a large project getting a Nike returns facility up in Lebanon, Indiana started. So it was the key point of contact. I was kind of learning on the fly a little bit about the formal procedures in project management, like what is a PMB? What does monitoring and controlling a project mean? How do you execute things? are the nuts and bolts of maybe more formal program management that our client needed? And so I did that for a couple of years, went back to the operations side with XPO, left XPO and then as an independent signed up, said I was looking for independent consulting gigs at the time. This was 2020, COVID had started. Awesome, yeah.

Paul Lukehart 05:54

Fantastic. And I was fortunate enough to get a gig as an independent consultant doing exactly what I had done at XPO for a beverage company that was insourcing its first North American distribution center. So that's where I struck out on my own and started the more formal program management, know, PL programs. so structuring programs, pulling the teams together, making sure all the parts. were identified, all the work was identified and integrated and then delivered, procured, delivered, tested. That's what we've been doing for a couple of years. I've added, the first project went well, client retained me for some additional work. I began working with one of their partners. I hired a couple people, a senior consultant and then a coordinator, and we've continued to sustain those relationships and a few other projects.

Paul Lukehart 07:06

Mm-hmm. I was going say it is a big leap of trust. You bring someone from an outside organization into yours and you're like, do I like this person? Do they smell good? Do they work well with us? All those important questions on is this going to help us accomplish what we want or is it increasing the risk? it going to blow up? We try to be sensitive to that for sure.

Paul Lukehart 07:43

The books, so I think the book you're talking about, Practical Floor Supervision, was a book I wrote after being a director of operations. And I said there's really not a great resource for being a warehouse supervisor. So I wrote it on the nuts and bolts of being a warehouse supervisor. How do you set up standard work? What are some fundamentals of understanding your operation and the processes in it? How do you do your job effectively? So it's not really directly related to project management.

Paul Lukehart 08:10

Yeah, this is running it, this is operating it. I find one of the important things during your programs when you're setting them up is keeping an eye towards how are they going to have to operate, who's going to operate them, how are they going to run, and keeping those things in mind from the beginning so you can plan. You don't end up doing a lot of rework on the solution or the team or your ramp plan, which can be really

Paul Lukehart 08:39

really damaging to the overall payback and prospects for the project.

Paul Lukehart 08:51

Right, right. On a professional level, I read a little bit about the art and science of project and program management. So there's like operations, which is super interesting in itself. And then we apply that perspective to the projects, but then also project management. You have to look and you say, what is the point? Is it just a bunch of glorified status givers and task trackers? Like, okay, maybe. but the real...

Paul Lukehart 09:25

I love Gantt charts, but that's not all of it, right? The end state of the Gantt chart is saying helping you identify and avoid risk. From a schedule point of view, have to say, man, there's a lease that needs to get signed. They're saying it's going to be done in three weeks. Is it going to be done in three weeks? I don't know. Maybe it'll be more like two months. How's this going to impact the overall program? What's the risk I need to bring up to the stakeholders so that we can plan around it?

Paul Lukehart 09:52

Or likewise, like hey, there's a data, know, set of data analysis that needs to be done. Maybe we should call Ralph Asher instead of having, you know, Bob the inventory analyst do our sales forecast and everything that the site is going to be based off of. You know, so the foundational, being able to spot and identify the sources of risk and then work to mitigate. To me, that's really like the higher level value of hey, do I have a good PMO supporting me?

Paul Lukehart 10:38

That's a good, I ask myself that sometimes too. Right, and it's a, I'd say it's taking a good look at your current organization and what you're trying to do and you have to do an honest appraisal. Do I have the resources? Do I have the right people in house to run this? If you are, if you do new sites all the time or you do complex implementations all the time or big capital projects, you probably have a team, you know, the real estate guys know what they're doing. The analytics,

Paul Lukehart 11:08

team and knows where to get the right forecast and can size the facility appropriately with a provider. Your operations organizations knows who they have to hire and when they have to hire and may have internal talent they can transfer over. But if you don't have that team in-house and you need some outside expertise for somebody to fill those roles, that's when you would go to a project consultant and say, hey, can you come on and support us? Can you help us define and shape the project? before we get started? Can you help us plan it? Can you, you know, on whatever specific work streams, can you help us execute this work? You know, provide input in maybe major procurement, for example, or hey, how's your testing cycle going to look? Maybe we can help you define that. that's going back to your original question, when should you go outside when you don't have the capabilities inside? And that's something that only a, you know, the company is going to know.

Paul Lukehart 12:28

No, it's a good point and this is what often happens. People are challenged on resources and there are barriers to hiring. As you're going through the shaping of the definition phase, one of the tasks should be to say something like, who's going to be the team? Maybe a first reflex is Bobby and Johnny and Sarah over there can take care of this project and they're also doing their day job. It's really worth asking, that, do you want to assume that risk? Like what if the project flips, who's going to do their day job? Something's got to give for some of these very involved effort.

Paul Lukehart 14:12

Okay, yeah, and that's, think you're right on, like there's, in these programs, there's some amount of tailoring, what the client needs, where they see the most. You know, if they're very sophisticated and they have processes for almost everything, you might just need to do a specialized kind of task or manage a certain process or control. Otherwise, it's like everything. In this program you're talking about, like some of these automation projects, know, most recently there was a, an automated truck loading project and then before some other robotics project. A lot of the immediate value in that is taping a, well I'm not going to say immediate value, know we did jobs ranging from you know task coordination, planning and managing some of regular communication cadences. I'd say some of the Most of the, a lot of the value came from let's define the project, let's define the scope and what's going to happen, let's build a business case and let's define the structure for it. You know, once you get those things done at the beginning of a project, you say, here's the business case, let's get the stakeholders aligned around that and make sure we have the resourcing plan and kind of like the initial setup done. A lot of the rest of the activities go very smoothly. But if you, if you neglect that, if you don't define the scope properly,

Paul Lukehart 15:38

If the business case is not solid and you don't get your approvals, then it doesn't. So I think a lot of our value is being able to help set these up correctly at the beginning and make sure that they're all aligned and then the rest of the program is execution and control.

Paul Lukehart 16:11

And they, you know, different companies do it different ways. But I have seen it where somebody takes an initiative and tries to run with that without being fully aligned through an investment, you know, up through an investment committee level. And they run into blocks or, you know, the sponsors are not aligned with the people trying to execute the project or there's disagreement about scope later on. From 3PL world, I've seen this, you know, secondhand with some implementations where the projects were just not operable. went live and they couldn't function. You you see that and those are big problems, right? Like the client can't operate, the 3PL is on the hook, they're pointing at each other saying, you told us that this is what it was going to have to do and it's not doing that. And it turns into lawsuits and a big problem. So I think having that initial like definition of the project, hey, this is what it's going to do. Here are the starting assumptions. You know, we've thought about contingencies and everybody's on the same page. That's super important.

Paul Lukehart 17:18

Yeah, the starting state was conventionally loaded 53 foot trucks, full pallet, you know, unit loads or family load. And the, they're probably seven day a week operations. So you've got running across probably 50 doors or so loading, loading trucks. And then at the end of it, there are, there are robots loading the trucks. Or I think primarily like drop trailers right now, the live loads pose a couple different scheduling challenges, it's making robotics and then, you know, the pallets are staged by another robotic system and then the truck loading robots pick up the pallets and put them in the truck. And so there were a few challenges with that, on the tech side, overcoming some layout constraint. And then how do you integrate the robotics with your docs? doctors, for example, and then it into basically a brownfield operation. that was a...

Paul Lukehart 18:37

That's right. the validation starts kind of at the supplier evaluation during procurement and saying, hey, what are your references? Can we see it? Do you have a prototype we can evaluate and look at and say, is this going to work or not? And then you can have the supplier come on site and prototype it at your facility and check for problems. And then like you said, once the tech is getting implemented on the system side and the hardware side, you do a stage takeover along the dock. But yeah, mitigate, again, you mitigate risk. You don't try to do a big bang, launch everything at once. It's more of a staged rollout to control anything bad that could happen.

Paul Lukehart 20:07

Mm-hmm.

Paul Lukehart 20:31

Yeah, and thanks for giving me a little time to collect my thoughts there as you went through those.

Paul Lukehart 20:40

I think structurally it starts with, know, when you're running a program, it starts with, have we identified all the stakeholders? There's a common list of kind of like major risks, right? Like are the stakeholders identified? Do I have an integrated team with everybody represented? Are there new technologies involved? Are there, you know, what is the experience of the team with the technology, that type of thing? But where would say pitfalls that jump out to me, in programs are having some sort of stage evaluation and approval process for program. Like you start with, know, we kind of want it, we know we want to do something in here and eventually tightening it down in terms of cost and schedule and scope too. We know we want to do this thing, right? You say, okay, we start with maybe a plus, you know, plus 30 minus 15 cost estimate or plus 40 minus 15 percent cost estimate of this program. And then you go through and you go through the exercise of refining your quote, drilling into the scope and defining what you're actually going to do. If you, if a company is not doing that, somebody is going to end up disappointed, right? No, you're going to blow a budget. You're going to blow a schedule. You're not going to get what you wanted. The second pitfall that I, that I would note that jumps out in my mind is the allocation of, of analysts. resourcing to a program. A lot of times people talk about defining what you want to do seems to be the hardest part. Actually executing it once you know what you want to do is relatively easy. But defining the business processes and defining exactly what you want to do is often a stumbling block. It often takes much longer than people want.

Paul Lukehart 22:35

That's where you have to make up all your rework and do all your change order and make it up on the back end. So investing correctly in analysis and definition upfront avoids a lot of risk on the back end. then probably the other, this is more a general observation is that everything takes longer than you think it will because like you said, I think you've talked about leases a little bit earlier, but procurement, contract, Any sort of large legal agreement will take longer? Yeah. yeah. mean, you had a post on that the other day, I think. know, like, the business leads in with the attorneys and streamline the back and forth. But that's something you have to plan for and buffer in your schedules is, these things actually going to take what we think? Is there any reserve in my schedule to account for these things being variable? Those are probably the three major things.

Paul Lukehart 23:34

some sort of gated definition process, correct analysis of your problem and your operation requirements, and then schedule buffering for those softer, less defined tasks.

Paul Lukehart 24:00

Mm-hmm. Well, this stuff's important, right? Like, people's careers are on the line. Their personal reputations are. They're personally invested. The company's putting a lot of money and time into whatever the thing is that they're doing. They want a good result. And they should be aware of, this is where that value from that project can degrade or fall off. It can degrade from bad initial forecasts. You can have schedule losses. You can have operability losses. Like, we planned for this thing to do 100 pallets a day, and it's only doing 75. Well, you know, booger, what are we going to do? Right? How do you fix it?

Paul Lukehart 24:44

Mm-hmm. I think in again looking at this from a lens of risk mitigation you have you have an idea of the costs on a project that you're going to spend you may even have quotes in hand but there there are certain things that are that are known risks that you have to plan for and certain things that are you know call it just variation or unknown risks that when you're when you're budgeting you should account account for those somehow have some sort of approach to, well, wow, we're going to buy racking in three or four months. What if the steel index goes up 10 %? Well, gee, maybe that's a risk that we need an allowance for some section of the contingency. And when that doesn't happen, then we can release that money out of the project. So you need to look at your project, your risk register, or whatever you think the big stumbling blocks may be, and say, OK, if this goes wrong, you know, what's going to cost? And then, you know, for all the stuff that we don't know that could go wrong, you know, let's account for that because when you're budgeting, know, companies are going to look at a lot of these products from a payback perspective or an MPV perspective. And if you don't have a contingency built in or some sort of planning, then something goes wrong and you blow the, you blow the payback. So you need to plan for that again upfront.

Paul Lukehart 26:25

Yeah, absolutely. think that's where some of the experience and the value add comes in too, saying, okay, let's prepare, yeah, let's prepare, do some sort of payback analysis on this automation system. Okay, let's look at the hardware, the software, the infrastructure, the difference in the capex and the op-ex that's going to occur and present a point of view on, yeah, does it make financial sense? Maybe there are some other benefits that come from it too. Yes. And then you can say as part of that project, let's put some contingencies in for the known risk and does it still make sense?

Paul Lukehart 27:17

that's tough. think it's dependent on company context. Like if you look at a 3PL with a three-year contract term or a five-year contract term with a client, their definition for a good payback might be, has to pay back in a year, has to pay back in two years, or we'll do whatever as long as the client's paying for it, Or if you have companies with a longer time horizon, they might say, automation is integral to our strategy as a company.

Paul Lukehart 27:44

the direction that we're going and so we're willing to accept the payback that five or ten years out if it means that we can mitigate labor market risk or something like that. You we're willing to do those things now instead of later.

Paul Lukehart 28:14

Probably, I don't know, call it three-quarter, three-quarters or so. We've done some infrastructure, some like civil infrastructure project, if you will, that did not involve automation. Okay, so those are sort of a different category. And then we've done some operational improvement, like pick path improvement and managed the site move for a 3PL, inventory move, fought between a couple of sites. So those did not involve automation, but... the rest have in one way or another.

Paul Lukehart 29:16

It's, I've been on both, we've been on both sides. working, you know, my, my consultant and I have been worked for 3PLs and then we've also done project as PL program for 3PL. And then also we work with folks who use 3PL, right? So kind of been on both sides. And, and what I've seen is it's sort of a, an ebb and flow. I mean, the, some of the strategy I've seen with using 3PLs and saying, they're a capacity buffer, you know, a longer term kind of higher investment capacity buffer, you kind of like you may bring in contingent labor in a warehouse, make up shortages or staffing needs at peak times. 3PLs can fill some of those non-level gap, gap up in capacity. And I think that's, I've seen that with secondhand, like Amazon, I believe use

Paul Lukehart 30:14

XPO for that reason, a few years back at least. Amazon insourced some things and they changed their warehouse strategy and so it kind of comes in and goes with the needs of the business. Of course, then you're going to run into people who use 3PLs exclusively for all their business, like all the time. So I don't know that I can make any blanket statement about when it's good or bad or a general trend.

Paul Lukehart 30:43

Mm-hmm. Yeah, I think it's gone back like looking at it starts, think, with a cost and a network analysis thing. know, where do we think the going back to forecast and sales forecast, where do we think the volume is going to be and what are we going to do to meet it? And then that leads into some real option analysis of should I bring it in-house or or should I outsource it and and talk to my 3PL provider? There's there's kind of a decision tree in there on how to approach it.

Paul Lukehart 32:03

Yeah, I think in thinking about that question, the Project Management Institute, PMI, I think recently, last couple of years, updated their definition of project success to, know, a project is successful if all the stakeholders agree that the value is worth the cost and effort. Right? It's a little bit of a self-licking ice cream cone, like everybody agrees it's good, so it was good. You have to assume the executives know what they're doing and are good intentioned. But I think that goes to how you tackle these wrinkles and these problems. If people are, if they're well informed and you make, you make your moves or your pivots based on what provides the most value in the project, then you can come through successfully. So if, for example, you're going through a project and, my goodness, like we'd said we were going to go live in January, but it's just not going to happen. It's going to happen in April, right? You have a couple of...

Paul Lukehart 33:04

Right, you have a couple options. can say, right, can, all right, stakeholders and executives, we have a couple options. Like the meteor hit our existing site, the GC has to start over, force majeure clause, like we're going to have to the cost, like that stinks. What are our options? Like, okay, we mitigate this through, we can either accept it, we can adjust scope, or we can find some sort of alternate course of action. But I think that kind of mindset is how do I create the most That sounds very like buzzwordy, but how do I create the most value with the situation? And if everybody agrees to accept a delay, like, hey, we got a delay in design, which has happened, right? Like, hey, our functional design period was supposed to be three months, it's gone six months. But along the way, we've kept all the stakeholders involved and everybody agrees, yep, the problems caused by terminating design earlier, just going ahead, the risk is too great. We're gonna finish the design as we're doing it.

Paul Lukehart 34:03

and then go on with deployment. So that's kind of like an example and how do you deal with it? You keep people in, you don't hide the bad news. You don't pretend you're gonna make a commitment you can't make. You're transparent and then you keep people informed of the trade-offs along the way. And then at the end, people have agreed along the way that the value's worth the trade-off. So I think that's the mindset.

Paul Lukehart 34:35

I think this would make contemporary figures, as a PM, you read about Elon Musk's approach to some of these things, which was cut the schedule in half. I have tremendous respect for people who can cut through the noise and do things like that, but in a lot of contexts, that's not feasible for a variety of environmental or cultural or just governance factors.

Paul Lukehart 35:04

That type of thing can happen, but again, you have to tailor your approach to the people you're working with.

Paul Lukehart 35:13

I don't know. I have great respect for Tesla and people like that.

Paul Lukehart 35:23

Right. But that's, again, it goes back to the environment you're in. What's possible in your particular project environment?

Paul Lukehart 35:40

boy, yes. I found myself doing some one too many Excel based diagrams or layout or drawing crude shapes in PowerPoint to represent real world objects. I programmed an add-in that lets you set scales in feet or meters or inches or whatever it is in your PowerPoint slide and then draw a scale diagram. there. So can actually say, I to create a building that is, you know, 1,100 feet by 700 feet on this scale on my slide. And then I want a 300 foot by 300 foot shape position within that. And it'll draw things to scale on your slide. So scales, dimensions, and measurements in PowerPoint.

Paul Lukehart 36:47

Or you're facilitating a discussion. Hey guys, there's a discussion about is this going to go here or here or how far is it from here to There's a lot of questions that can come up when you're going through various approvals, design sessions or facilitating other questions.

Paul Lukehart 37:21

Always Excel. don't think that's everybody. Everything is a front end for Excel, so no surprises there. And then I found also with our other favorite recent technology, our large language models that keep getting better and better, that it's very easy to in your language of choice, in this case, minding Python, things to answer specific questions. So I found myself doing some simulations or some like option pricing for for different procurement things like that. Hey, if we want to fix a price for this steel right now, how much is it worth to pay versus what it might be in a month or two? Like answering that type of question. So there are a lot of

Paul Lukehart 38:26

So yeah, those tools really democratize the use of code. Like can't code. I'm not a programmer, much less an actual developer. But you can say, hey, I have this problem with these parameters. Give me something that will stimulate it. And then you can figure out enough to make it work and make it relevant to answer your question. And so it really does democratize access to a lot of these. Maybe functionality, would spend a lot more time

Paul Lukehart 38:55

trying to figure out in other ways.

Paul Lukehart 39:08

Mm-hmm. Yeah, I mean, it's presenting insights, right? Like if you're working with a client and they say, I have this problem, and you can say something like, well, me help you frame the answer to this problem by introducing these different ways of looking at it. That's really vague language for the best way I can think right now to describe it. I have a decision to make. How can I illuminate that decision using different tools?

Paul Lukehart 39:50

huh. Yep. boy.

Paul Lukehart 40:21

Yeah, we've got some pipeline that could be exciting on different automation inside implementations. excuse me. From a business point of view, always looking to expand and grow the business. if I can get to a third employee, then that's great. But along the way, let's find some interesting programs where we can help people and deliver some successful, if you will, supply chain initiatives. So keeping that going. And then we've got some ongoing engagements. I want to keep my current very valued clients very happy, of course, so keep that satisfaction high. And then, what's that? Yeah. And then from a tech point of view, I don't know that there are any, I think the AI current investment levels are probably something of a bubble, but the technology is not mature yet. So we'll continue to see that mature and look forward to seeing how that affects the And that's on the horizon. And then the little kids, of course, which we talked about.

Paul Lukehart 41:55

From a tech point of view, we should keep our eye on the prediction markets that are becoming very popular. I'll bet you those have a lot of... I don't know how they're going to be used yet, but when you think about forecasting things happening and that can affect do I get a warehouse or not? Do I make some decisions about my supply chain? I would not be surprised to see...

Paul Lukehart 42:22

prediction markets integrated in interesting ways in supply chain planning.

Paul Lukehart 42:36

Mm-hmm. Yep, Yeah, I think that plus some, I don't know, AI is the answer to everything, but prediction markets and AI are going to drive a lot of planning and these types of implementations.

Paul Lukehart 43:27

Alright, and I've got yours on the way, so I'm looking forward to you. Thank you so much, Justin. I really appreciate it.