Patrick Sullivan (00:09):
All right hello everybody. Welcome to another episode of ArcherGrey’s PLM Quick 30 where we talk all things PLM, and I’ve been … Dave, you don’t know this, but I’ve been excited about this one for a very long time. When we started compiling a list of potential guests to have on the Podcast you were on the top three, so I’m glad that we’re finally taking the time to do this. So our guest today is Dave Slater from Raytheon Technologies who is … Well, he’s played many roles, and he’s the director of something. I’ll let him introduce himself right now because he just shifted roles. The topic of today for everybody who’s pursuing anything in PLM you can’t do it unless you have funding, and Dave in my opinion is one of the best in the business in securing funding and building a story that not only appeals to executives but ultimately delivers on the expectations that he set. So Dave Slater is here to talk to us about the secrets of how to secure funding. Dave, things for joining us.
Dave Slater (01:22):
Hey Patrick, thanks for having me. I really appreciate it. This is kind of a really difficult subject because there are a lot of trials and tribulations and obstacles. Pretty much everything is going against you when you try to get funding for a large deployment of any kind of PLM system. And just for context we’re not talking just bringing in some software and standing up a hundred seats. We’re talking about enterprise level, hundreds of millions to billions of dollars worth of funding as well as benefits. And that’s kind of where I wanted to go. Most of my … I’ve been working this for seven years, and we’ve done four appropriation requests, and we have been pretty successful at it. So I wanted to share some of the traps that people fall into and some of the tricks to get out of them.
Patrick Sullivan (02:19):
Yeah, I’m excited to hear all of them, so thanks for being willing to share all the information. Before we start diving into that since I didn’t really give you a great introduction if you wouldn’t mind taking a few minutes to introduce yourself and give us a little background and bring us up to current day.
Dave Slater (02:43):
Sure. I started way back at McDonnell Douglas in ’85 and was on the International Space Station. I was a lead engineer on that. Actually C17 prior to that at McDonnell Douglas and the International Space Station, lead on both of those for large pieces of the structure. So that’s my background, structural engineer, mechanical engineering type stuff. Then I realized there comes a time in your life when it’s not about you, it’s kind of about what your company needs, and you have to make that transition and step up. Your kids are getting older and you see college ahead of you, and it’s like, “Okay, how do I move up in the company?” And basically I just did an about face and said, “What do you need?” And there’s a number of things that they needed, and I was able to move through the organization. Then after the Boeing merger was picked up by Raytheon as a chief engineer.
Dave Slater (03:39):
And from there I led the Product Integrity Center as the director of that, about 130 people. It was configuration management check, quality checks, quality CM for software and other elements like that. And then we had a previous program manager for bringing in the PLM system. Had a bit of a stress attack and was in the hospital, and I was thrown on an airplane and sent because they were doing a workshop, and I was thrown on an airplane and landed, and the team is like, “Okay, tell us what to do.” And just imagine that for a moment that you’re just thrown into this situation for which I knew the tool but other than that I had no idea what this team was doing or who anybody was or anything, and it’s like here’s Dave.
Patrick Sullivan (04:34):
Warning signal number one, the person responsible was out of commission due to a stress attack.
Dave Slater (04:42):
Correct.
Patrick Sullivan (04:43):
Dave, I have two updates for you. First one, the person in charge was stressed out. Second, can you get on a plane in a half hour?
Dave Slater (04:53):
Exactly. And this is kind of the way it goes in the executive realm. I was like, “Yeah, no I don’t want to do that.” And they’re like, “Okay, I need you to go there right now because everyone’s there, and then in two weeks we’ll find somebody else,” and seven years later I have all this experience on how to put PLM systems together and get them funded and work the process to get to where we are today.
Patrick Sullivan (05:21):
I can tell you out of the years that we’ve been dialoguing, which has been I think for the last seven, eight years cool heads prevail. We joked about the stress side of it, and I’m sure I don’t know whether or not you were stressed throughout that time or not, but you said it a little bit ago at a certain point you’ve got to decide what the company needs is the priority and then just step up to the plate and navigate your way through it. And every time regardless of the amount of pressure you’ve been under you’ve always had a cool head.
Dave Slater (06:02):
I appreciate that. So, yeah, that moment was they needed clearances, you needed managers, and needed system engineers, so I did all three of those in one year. And that’s when my career just took off because everyone knew me as a designer, and once I said I’m open to the market, and I don’t mean changing jobs or I should say changing companies, I just mean being able to serve the company. I found out that there was a deep desire for people who have a strong technical background and can have the demeanor and the protocols to work at an executive level.
Patrick Sullivan (06:45):
Well, you’ve gained a ton of insight, so I appreciate you walking through your beginning days and bringing us up to speed.
Patrick Sullivan (07:02):
Starting to talk about the topic at hand, and I know you have somewhat of a methodology that you follow, so can you give a high level summarized version of how you look at the pursuit of getting funding?
Dave Slater (07:19):
Yeah, there are four things that you have to really pay a lot of attention to. The first one, which is probably the least fun, is you have to understand the funding cycle of your business. And that means that if you screw that up, so if you are trying to get something funded in October and they wanted funding requested in June you’re out a year, so you quickly lose a year. And a year from now you might not even be in the same job or the people that you were relying on to help you may not be in the same job, so you lose synergy and you lose advocates. So knowing the funding cycle is super important and what’s expected when is really important.
Dave Slater (08:12):
The second one is to properly scope it based on what you think the funding allocation is going to be. The bottom line is that there’s a certain temperature in the room for how big a bit your company is willing to take in a given year or a given project over multiple years. Hopefully you have an advocate as a VP or something like that that can help take the temperature of the room and say, “Yeah, I think it’s going to be one project a year long, and you probably need to be in the $10 million range or something like that,” and then you can then scope out what can I do for that kind of money or if you scope it from the ground up you typically wind up having too much, which is fine.
Dave Slater (09:05):
I’ve done that … That’s how I started a lot of these things. And then just keep peeling back and peeling back and peeling back until you figure out what the executives are going to be able to bite on and what they won’t be able to bite on. A lot of that, too, is understanding if it’s going to be a multi-phase, multi-funded thing or like multiple years, one big AR appropriation request. And that way you can build on stuff as you go.
Patrick Sullivan (09:32):
So when you say properly scope a lot of times people try to tie themselves to business objectives or they see a new technology and want to implement it as pointed. So when you think about getting a temperature do you start with how much money could I potentially get, and then you try to find out what type of initiatives might be appealing or when you say properly scope how do you …
Dave Slater (09:58):
Sure. Generally there’s something not working today in the business, so the first thing you want to do is solve that problem that is well recognized. So what we would do is, because we wouldn’t have any money to start with, so we would find people who are managers who charge indirect versus direct and then you’d have to pay them so to speak like you’d have to have a budget for if I needed a mechanical engineer to help me scope something out that mechanical engineer is directly billing a customer I would have to be able to get that budget. I would start with the managers, find out what problems we need to solve, so I would start from that perspective. And then we’d kind of figure out okay what does it take to solve that problem. In my case it was across the entire business because we weren’t just trying to solve it locally. So you have to scope in and scale it to figure out what you’re going to do. But it’s okay to overshoot and peel back. That’s the key there.
Dave Slater (10:57):
The tricky part is to get the feeling in the boardroom is what are they willing to swallow and in what kind of increments are they willing to fund it. I can get into it deeper in a minute, but the last thing is create a killer business case. You have to have a killer business case because ultimately these size projects, and again I’m saying tens of millions to hundreds of millions, are going to be signed off by the CFO. So the CFO all they care about is if I invested money in the market I’d probably get 5%. Why don’t I just do that? So that’s the kind of people you’re going up against.
Dave Slater (11:40):
They really don’t care about your ideas and the vision and all your passion about it. They just look at it purely as an investment, so you have to have a killer business case to survive, and the business case will be the life blood of the project because the business case has to absolutely drive the actual execution of what’s getting done, and then the business case will drive the metrics at the back end to validate that the company literally saved money that you said it would. So that business case is last on my list, but it’s the most important.
Patrick Sullivan (12:21):
So if I walk through these again, first you said understand the funding cycle as far as timing of when you need to be pitching and scoping and requesting budget. Two, you need to properly scope, and you started by saying to properly scope it you’ve got to understand what’s the appetite. Is it $1 million or is it 50 million because the scope that you’re going to bite off depends on what people are willing to consider. And then that third item that you had mentioned was having a killer business case, so is that part of properly scoping or is that subsequent to scoping?
Dave Slater (13:05):
It’s part of scoping, and I probably left one out. I think it’s the vertical versus horizontal stakeholders too. Those are your advocates, so having those people aligned as well. But your business case is what supports … It’s the analysis of the scope is probably the best way to think of it. Think of the scope as the design and the business case as the analytical margin from a business perspective.
Patrick Sullivan (13:31):
Got it.
Dave Slater (13:32):
That’s probably the best way to do it. And then I didn’t mention the vertical and horizontal stakeholders, and with that it’s important to have advocates. I call them stakeholder advocates. And those folks, when I say vertical I’m saying from the mechanical engineer to the mechanical manager to his department manager to the director to the VP. That’s my vertical chain, so if I’m only going to do something for that mechanical engineer or the group of mechanical engineers, the department of mechanical engineers that’s what I would call a pretty easy chain to follow, and I can pretty much drive enthusiasm and advocacy saying these are what your people need, and we just need to go get that funding and go get that done.
Dave Slater (14:18):
Horizontal is now saying, which by the way it’s not vertical or horizontal, it’s vertical or vertical and horizontal because no matter what you have to drive it from the entry level position all the way up to the vice presidents. And the more horizontal stakeholders you pick like I’m going to do configuration management, I’m going to do supply chain, I’m going to do operations, manufacturing, we’re going to do systems engineering, and we’re going to connect software to the product. When you have that many horizontal elements and then you think vertically up the chain you wind up with a massive problem on your hands because that’s where you get into this kind of take from Peter to pay Paul kind of thing. I’m going to have this guy do a little more work, and that guy’s going to get a lot more benefit. So trying to justify that limits not just the myopic function because quite a bit harder, which is what we really talk about when we say product life cycle management, digital thread, digital twin. These elements are all about horizontal integration, so you’re making a huge mistake if you’re not thinking about horizontal integration of the data.
Patrick Sullivan (15:39):
So let me ask this. I can just tell the amount of experience and I suspect lessons learned to be able to make that comment about horizontal. Now a lot of folks use the word digital thread, but when you started seven years ago on this journey in your career digital thread was not being used with regard to PLM. It was integration TRP or it was a lot of integration talk. And you guys were, I think, at the heels of a lot of migration activity that were going on to consolidate all of your systems into one instance. So were you when you first started taking that vertical approach, and how did you identify because I feel like a lot of folks in the industry go to get the vertical funding. The manager that they go to speak with they’re talking about a specific problem, and typically historically PLM was associated with engineering. Today PLM is truly across the life cycle. People talk about it in that terms and in fact I more often hear digital thread than I hear the words PLM. So at what point or what major initiative was an eye opening scenario for you to say, “I need to get buy-in horizontally in order for all of this to happen?”
Dave Slater (17:17):
Yeah. It was … Remember that guy who wound up in the hospital, so I came in and that was the huge what was really a PDM initiative, and it was centered on the CM organization. And the goal as you mentioned was to consolidate CM tools. So it was a very vertical, narrow vision of what we needed to do. It was literally upgrade our tool, our CM tool, and get everybody to agree on the processes, which that was a knockout, drag out fight. That was before my time, and I thank God that they got that out of the way. It took years to just do that, but just consolidate people of the same function to using a single tool and a single process. And there were a lot of carve outs for business unique stuff. It was very difficult.
Dave Slater (18:24):
What we took on after that was okay now … So what happened was as that was tailing off, and we had to completely rebid the program because it was under water, and we were successful at that, and the company was very happy, and they said essentially what else could you do. So we started looking at it horizontally and saying our biggest problem is we have no connectivity to any of the other functions, and if this is going to be the core source of truth for the engineering it needs to connect. So that’s when we started the next four appropriation requests over the next seven years to pull that together.
Patrick Sullivan (19:09):
So you said the program was underwater, and you had to rebid the program, and then you said that the organization was happy. Was it a paradigm shift? What happened?
Dave Slater (19:26):
We kept the same scope, so we kept it vertical, but the goal was to close. We weren’t closing. We weren’t deploying and getting the software to the users. So that was the fundamental program. Once we were able to show that we could execute that program based on the funding. We had to go back and request funding to finish the program that I came in the middle of it. And we were able to bring it in under budget and on time from our rebid if you will that’s when they gained confidence and they became more interested in other parts, other interactions of that system with other systems that they had.
Patrick Sullivan (20:09):
Okay. It’s amazing how delivering starts to raise confidence on folks.
Patrick Sullivan (20:23):
There’s a few people in the industry, you being one of them, that I speak with, and they oftentimes get funding, and when they get funding it’s in comparison a large amount of funding. And it’s been years of delivering. There’s not a year that goes by where they’re not delivering something successfully to the end user community and tying it back to what your point was, having a killer business case and in some instances just turning around and showing the value and having the users engaged in the momentum that you’re creating and building upon. And they just don’t get questioned. They consistently get funding.
Dave Slater (21:06):
Yup, that’s true. So some of the things that we found in doing this is going back to the funding cycle is that there’s a capital plan out there that’s usually multiple years, and you need to get your name in that capital plan for expenditures. Even if you just have to do a wild ass guess at how much you want to target just putting a number into a capital plan that may be executed next year or the year after or the year after that is huge because it gets visibility. You can always work the scope into whatever number you gave. You’ll probably be asked what could you do for half that, but that’s kind of where it starts. If you think of whatever your fiscal year is and if you think of like Q1 is maybe even the year before or at least by Q1 you want to try and be thinking about the capital plan and how do I get money into that. How do I get a request so that it begins to get some legs.
Dave Slater (22:14):
You can’t come in at the last minute and ask for money. So that was one of the key things. So you try to formulate that opportunity, and then you go get your stakeholder advocates to look at it. You start doing some executive briefings. You have to get awareness on what you’re trying to do so that people who want to be part of it will jump on and help build some momentum. But by midyear you pretty much have to have that killer business case ready to go and the plan pretty well set. You don’t have to know how to execute. You don’t have to know the specifics around the design, but you do need to commit to the amount of money you’re going to need in capital and the amount of money you’re going to need in expense. And there are strategies to that. We kind of like to go about 20% expense, 80% capital.
Dave Slater (23:08):
Expense comes directly out of the profit for the year that you spend it or the month that you spend it and so it’s a real hit to the community, to the departments whereas capital gets … You get a capital sum from corporate, and then that gets depreciated over years, and the businesses don’t see that until after the program’s done. So there’s strategies around how much capital and how much expense that you have into that.
Patrick Sullivan (23:36):
What’s your approach … I’ll tell you another scenario we run into frequently. We get asked to provide statements of work or bid on a particular project. Yes, funding is in place or they say that they have funding, and then we provide them the statement of work and they can’t believe. There’s a mismatch in the budget that they have and the estimate of what we believe it’s going to take. When I ask them how did they request the budget, and they said, “Oh, I took a swag of what I thought may be able to take.” What’s your process in anticipating the amount of budget that you’re going to need, and how do you know that it’s going to be accurate or it’s going to be enough?
Dave Slater (24:27):
Sure. I relied heavily on our IT team. They are experts at this. They bring in the suppliers into that negotiation, and it’s not a negotiation. It’s a collaborative effort. And you absolutely have to know what these costs are because you can’t even begin your business plan without knowing what the costs are and being able to question those costs and being able to look for smarter ways of accomplishing the end goal. And that’s the key is what is the end goal. Where do I think I’m going to save the money, and how can I get there in a cheap, for the best price, but also, and this is the key, Patrick, is not with a lousy solution that is going to limit my ability to continue doing PLM or continue doing digital thread.
Dave Slater (25:27):
One of the big obstacles or traps is that you put out some piece of software that captures all the ROI that you were looking for or 80% of the ROI, but it’s impossible for you to get out of that corner because you’ve deployed something that has no ability to integrate with another system. So we were always being wide-eyed and watching what the other part of the business was doing to try and make sure that any of our large digital thread or PLM plans for connecting up the information. So I imagine you’re going to develop an architecture for this, and if somebody comes in with some crazy way to get 80% of that ROI it could derail the entire architecture of this.
Dave Slater (26:27):
So you have to work with your suppliers, work with the experts in the area, make sure that you don’t get disrupted by some low technology solution that steals away your business case, and show what the spending is going to be, what’s the spending curve going to be, what’s the period of performance it’s going to go over, and when do the benefits start showing, and how you’re going to measure those benefits to prove to the organization that they got what you said they would get. So there are a lot of pieces to it. There is definitely a lot of pieces to it.
Patrick Sullivan (27:12):
I appreciate you walking through that because I think that’s helpful for folks to understand especially when you’re getting funding, just treating it as a task and putting a number in because it’s the budgeting cycle isn’t setting yourself up for the best possible situation. Yes, you’re looking for the best price, but best price doesn’t mean the lowest price. Balancing it with a quality solution that’s vetted and really a collaboration gets you to the place ultimately where you want to be because anybody participating hopefully is looking out for the longterm future, whether that’s you as the customer or us as the vendor you’ve got to have your sights on the right place, which brings me to one comment that you had made in a previous conversation. You said, “How you win is by keeping the business case in front of you. Someone has to do more work for the organization to win.” I’m interested in that comment. What do you mean?
Dave Slater (28:22):
Great story. For years we’ve been pounding our head against the wall and we were trying to figure out because you couldn’t do anything with the data because it was just too dirty. And people … Just real quick, so supplier has a part number that comes into your business. You change the part number in engineering. And then when it goes into the manufacturing system they change the part number again, and it may even get another number when they go to procure it. So how on Earth are we supposed to do a digital thread of part data when the part number through our own fault changed three or four times from the time that the vendor said, “Here, use this part number,” to the time my procurement guy went out and bought it in that whole thread there. So for years we were trying to figure out how to put a business case around this thing.
Dave Slater (29:22):
And finally after failing with a couple of different requests we came up with the idea let’s start with the procurement. Let’s start with the end. Let’s start with the result we want at the very end. So we went to the procurement team, and we said, “Can you send us the database of parts that you’ve purchased and the price of those parts?” So we got the massive spreadsheets with all the procurements they had done, and then we traced those numbers back to the manufacturing system, and then we traced them back to the engineering system and then to the supplier. So we created that daisy chain all the way across.
Dave Slater (30:11):
That approach starting with the end in mind enabled us to focus on the parts that we knew were going to go save us money because we knew we were buying them. When you just look at your PDM system and the library of parts in there you have no idea how many of those parts are being used or whether any of them. Some of them may have never even made it to piece of product. And you don’t know how many of them had their numbers changed or which ones went through this whole process. And by working from the back forward we were able to identify all of the ones that matter, which ones are being procured at a high rate, and how much we thought we could save.
Dave Slater (30:54):
So what we did is we actually looked at if a part had four different numbers, and sometimes it got procured under the supplier part number, sometimes under a company number or a manufacturing number or design number, we looked at all those prices that they got, and then we realized that we could save a significant amount of money on our annual spend just if we had ordered it per this one number because, number one if I used the supplier number typically it was cheaper than if I tagged on Raytheon numbers. If I consolidated my spend into a single PO, and we could see the same part numbers we’re buying 10,000 of them every year. So it’s like, hey the economy of scale allows you to save a lot of money. So that’s how we put together that business case, and that’s exactly what I meant by you’ve got to keep the business case in mind. So now as you create the solution … So now I have the justification for the solution.
Dave Slater (32:01):
Now when we get into the design of the solution we have to focus to make sure that we have a clean handoff all the way if we have to have these part numbers that they’re digitally connected so that we’ll know when we get to the procurement that we could procure to the original part number or we could procure to the engineering number or to the manufacturing number or what have you. But there’s so much legacy information in these systems to try and work the process from the beginning to the end you’ll never get there. But working it from the back to the front and focusing on last year’s procurements fantastic. We had a great result. And you’re talking about spend in the hundreds of millions to billions of dollars. And if you can save half a percent then that gives you a number. Let’s call it 50 million a year, okay so now I know my benefit’s 50 million in one year.
Dave Slater (33:06):
That gives me a lot of operating capital to put a solution in place that can go capture that 50 million. So from the time you write the requirements you’re thinking how do I get to 50 million? From the time you execute the software you’re thinking will this get me to 50 million. And from the time that you put your measures in place you’re focused on how much of the 50 million did I get this month.
Patrick Sullivan (33:31):
Let me ask who does more work in the organization in that scenario that you described?
Dave Slater (33:39):
So the lesson learned was before we had it figured out the first year we went to look for engineering support to get engineers to connect the parts the way we wanted them connected, and they said, “Where’s the benefit, Dave?” It’s procurement. That’s where you’ll see it. Well, why should we spend engineering money for procurement to get money. And then the next year we went to operations and procurement, and they said, “Yeah, but we only have so much money and we don’t want to spend it on engineering tools. We want to spend it on things having to do with supply chain.” So this is that horizontal order magnitude issue where now you’re going to ask the engineers. You’re going to create software that makes it easy, but you’re going to have to ask engineering to do a little more than what they used to do. And as a company we’re going to be mature enough to say we’re going to do a little more over here so that your procurement people can find a bigger savings in buying the parts.
Patrick Sullivan (34:52):
I love that you were brave enough to say that engineering is going to have to do some more work for the enterprise to win.
Dave Slater (35:02):
That’s right, for the enterprise to win.
Patrick Sullivan (35:05):
That in and of itself you said at the beginning of the conversation that what does the company need, and not everybody has that perspective because a lot of folks have ownership related to their discipline within their organization, and they don’t think about … They’re oftentimes measured on the work that they’re producing not the efficiency or the completeness of the job that they’re doing and how that affects others throughout the organization. And if people can have that perspective, and I like your word for it of horizontal, you end up being ultimately in a better place. That story is great that your epiphany came after two years of knocking on the engineering’s door and then going on procurement’s door, and as a consequence you gained that horizontal support, and ultimately you got the funding, correct.
Dave Slater (36:03):
The third time. Yeah, the third time it worked. So, yeah, it’s a lot of lessons learned. I think that you’re really biting off a lot when you try to do horizontal integration on PLM. And it’s so important to figure out who your advocates are and where they sit and what influences they have. Vertically that’s true of your frontline engineers, managers, and directors and all the way up. Where am I going to derive support because it can’t be just Dave. It can’t be just Dave because that just doesn’t go anywhere. And organizations are hard to move. There aren’t too many CEOs that just stand up and say, “We’re headed in this direction, and we’re going to go.” And just a lot of CEOs don’t do that.
Dave Slater (37:04):
The push/pull there is if I’m wrong as a CEO and I point us down the direction I won’t be here very long. However, my leadership can really add gas to the fire. So what they may do is … And we’ve had both because that’s just the way it is. What they may do is say, “I don’t want to be prescriptive. I want the ideas to come up from the company, and I want them to fight for it, and I want them to prove their case, prove their case in court almost with the business case and have everyone sign off on it, and then I’ll support it.” I’ve seen it both styles. When you’re slogging through horizontal and vertical integrations with a lot of different people you wish the CEO would just say, “Just make it happen.” Everybody will fall in line really quick. But I think to be fair to our CEOs we owe them the proof. We owe them the goods, so if we can show them the goods then we’ll get their leadership and make it successful.
Patrick Sullivan (38:15):
So Dave, I love hearing you tell the stories about all of this. After talking about all of this it’s clear that you’re creative, resourceful, and you care about the work that you do. My question is why do you care so much in the first place?
Dave Slater (38:40):
I’m a huge believer in hard work creating passion. I think for kids coming out of school I don’t think they realize and understand the concept of the word passion. I think they think they just have to have passion, and wherever it takes them is fine. And that’s not productive, and it’s not helpful, and it’s deleterious to our youth. The reality is that you have to work hard. You have to work hard, and then you become passionate. It’s like my first car. I worked so hard on my first car and I was so passionate about that car after the work got done. And when I finally had to sell it because I was leaving the East Coast to the West Coast it hurt because you put work into it.
Dave Slater (39:35):
It’s like anything. It’s like your first car, your marriage, all these things become passionate through your work. And when I made the life change of what does the company need that was when I realized what an impact I could actually have on the company, so that’s where that passion comes from because it was like I’m slogging it through and became … They wanted to make me a manager after five, 10 years of work I’m like, “No way. I’m having way too much fun being an engineer. I love being an engineer. Go away, go away.” And then when I turned the corner and said, “Okay, what do you need?” That’s when I started putting in the work and I started making myself much broader, not anywhere as deep as I was in engineering but much broader and started learning about a lot of other things and taking on jobs that I had no idea what to do, but I said I’d figure it out, so that made me pretty agile and made me pretty horizontal I guess.
Dave Slater (40:47):
It’s a lot of work, and you don’t get a lot for it, and then you see an opportunity like this and you go, “Wow. If I’m successful at this you’re looking at tens, maybe hundreds of millions of dollars per year of savings if you can pull this off.” And it’s a slog, like I said. I guess I didn’t say this, but we had to convince … Basically at the time we were four different businesses, and there’s Vice President of Engineering, Vice President of Operations, Vice President of Supply Chain, and the CFO, so four times four is 16, so it’s 16 executives that you pretty much have to get aligned for a project like this. And by the time you get 10 aligned three or four have changed jobs. So you absolutely do need passion, but I think it comes with hard work. I really do.
Patrick Sullivan (41:49):
I’m so glad I asked that question, and I appreciate you answering it. I’m totally inspired. I appreciate that comment, hard work creating passion. And then your comment of folks graduating thinking that passion needs to lead them there, but it actually happens in reverse is really insightful. That’s a great perspective, so thanks for sharing that.
Patrick Sullivan (42:13):
Well, it is called the PLM Quick 30, and Maria was harassing me a little bit earlier saying, “Well, maybe one of these days you’ll keep it to a quick 30,” but I think it’s just a goal to aspire to because this conversation has been so insightful and valuable, and I know everybody listening is going to get a number of things that they can take away and put to action. So with that do you have any closing thoughts or remarks?
Dave Slater (42:45):
It’s a little more detail. It’s probably because I’m an engineer, but it’s one final nugget that occurred to me after about the second time we went through this. It has to do with the funding cycles, and the nugget is don’t make an annual plan. We’re going to start the project in January, and we’re going to end it in December if you’re on a calendar year. It’s not good. What you want to do is you want to stagger, so whatever your midpoint is, in this case we’ll say July, you’d like to start in July, and let’s say it’s a one-year project, and then you want to end in July because then you have funding split across … There’s a whole bunch of good things.
Dave Slater (43:32):
Number one, you’re splitting the funding for the project across two seasons, two annual budget seasons so it’s half as much because all they really care about when they down select who’s going to get funded next year is how much money you’re going to take next year. And if all your project is in the next year then it’s going to be a lot harder for them to fit you into the budget then if only half your project is in next year.
Dave Slater (44:02):
And then the other thing is if your project ends in December, and you’ve already missed the funding cycle for the following year. So if you run over in schedule or money there is nothing in the next year to support you because you thought you’d be done. So much better if you straddle the years, so if it’s a two-year project you want to straddle three years. So if it’s a four-year project you want to straddle six years and make sure you start in the middle of a year and end in the middle of a year so to speak so that you always have funding in the beginning and the end, and you reduce your chance of getting cut because you only needed half as much in your first year.
Dave Slater (44:50):
It’s the first year that’s the hardest to get funded because nobody’s worried about year two. And every time you go for funding they’re always going to say, “Well, this is a really bad year, Dave. This is a really bad year.” The following year, a year and a half now, much better. So by straddling your program you know they’re not going to care about it next year. So to me that was probably one of the things that we started employing after doing this one or two times. We realized that it’s a huge mistake.
Dave Slater (45:27):
And the other thing is it’s almost impossible to staff a program in January. It’s almost impossible. So you’re better off trying to plan it for a July start, and then you have a half year to figure out who your staff’s going to be and everything else.
Patrick Sullivan (45:41):
That’s, again, a great nugget that speaks to your years of experience and your persistence. Chasing funding for three years, going to different groups I’m grateful that everybody listening gets the benefit of all the hard work that led to you being able to talk about this so passionately.
Dave Slater (46:01):
Well, me too.
Patrick Sullivan (46:04):
Well, Dave, again thank you. I know that you’re busy, but I really appreciate you taking the time to spend with us today and share your experience and journey. It’s been really a joy to listen to.
Dave Slater (46:17):
Thanks for the opportunity. I think you’re providing a great service to all the PLMers out there, and ArcherGrey is a fabulous organization to work with, so thank you Patrick.
Patrick Sullivan (46:29):
I appreciate that. All right, thanks everybody, and we will see you next episode.