How This Principal BizDev Leader Uses the V Model to Tackle Complex Engineering Issues

Yeah, so going back to the framework that I designed at uh Inquitel, um, we call it the system engineering V model. It's literally a,

the model, the V. Uh, and so it starts from the top, um, and it's got I got to count 123. It's got 5 components. It's very similar to what I talked about earlier. First thing is understanding. Um, I asked each of my engineers, um, each of my engines, so let me step back. We manage about 150 to 200 active work programs. I have about 10 engineers under me. So it's about 15 to 20 startups that each of my engineers manages. And you're right, there are issues that are cropping up all the time, and I only need to face the issues that I have to, that they're, I have to understand how to prioritize education. And every engineer and startup has their own way of, um, presenting the problem, which can be difficult because we're working with contractual documents, um, requirements specs, um, actual products and the technology so. Diverse. One day I'm working with machine learning. Another day I'm working with the drone. Another day I'm working on a satellite. Oh, and then another day I'm working on a biological experiment. And so the issues are just very diverse. I developed a system where, um, I, I asked my engineers to When they face a problem, tell me where in the phase in the system engineering the model is the problem, right? And it's a very simple model. Is it, and the model is The customer use case is number 1, what is the customer's need? 2 is what are the requirements. 3 is the design phase, 4 is the test and validation phase, and number 5 is customer pilot is when the customer is using the product.

Yeah, so 3 is the design and development phase where the startup thrush is designed. Uh, 4 is when we test the product. The engineers, once they design developing, uh, the engineer is testing the product. So when an engineer comes up and says, I have an issue, right? This thing, uh, the company is not meeting the needs. Well, Before they do that, I ask them, tell me where in the phase they're not meeting the needs. So they'll tell me they're not meeting the needs and the requirements. That helps me understand, OK, I don't need to read the contract. I don't need to read the design document. I don't need to read the test report. Give me access to the requirements. And then we focus on that requirement and then I go through it, um, and I ask them what's the step before, what was the customer's, uh, use case? They'll provide that to me and I'm only circled in that, um, uh, I'm only locked into those two phases. Where before, where I struggled was an engineer would bring me every document and, and be like, all right, here's the problem. I need you to read everything, which takes a lot of time. My process helps me figure out, OK, give me these two documents only. If it's not being tested, I don't need to know that. Only give me those two and it helps me prioritize. All right, let's focus on here. When it comes to priority. Our customers are, um, they care a lot about how Intel test the product. So when an engineer brings a product to me and they say to me, well, we don't have a customer use this problem. But if another engineer customer or find I'm, I'm, I'm having a testing issue. I know that our customers care about the testing. I'll put the customer use this problem in second, prioritize the testing first. When that's resolved, move to the next, uh, issue.

Yeah, it's a good question. When I came from Boeing, um, We, the system engineering VO is an industry variant. It's used in automotive. It's used in building helicopters. It's, it's never been used, um. Uh, aside from manufacturing. When you think of Incutel, people think venture capital firms. Can you imagine telling a venture capital firm to use the Toyota Way or 6 Sigma? Um, we are a very unique firm where we are managing. Uh, a lot of designs. And so the predecessor before me, um, the way they work with single thread. I'll work one company and see what the needs are of the customer. My model breaks that down so that it's simple enough that we can walk the startups and the customers through and they understand, oh, it's in design development. I know where the issue is. It also makes it easy for my engineers and my leadership to understand when I bring them a problem that I'm not going through every document. I coached them in training the V model that they now know that, oh, it's a requirement problem. Tell me about the customer use case first. And so this expedited and reducing the amount of issues that are rising and prioritize issues to deal with, uh, rather than dealing with every little fire that gets sparked.

Yeah, so a typical delivery, so when we're talking about testing, we are measured by, uh, testing and delivery. A delivery takes about 45 days from the minute the startup delivers to before it gets into our customer's hands to satisfy the mission. It takes about 45 days. When I inherited this team, they were averaging around 30 to 35 days from the fact the minute they got 30 to 35, 30 to 35 days. My process reduced it down to 15 days. Now we're, we're averaging between 20 to 15 days of handling the product and getting it to our customers' hands.

10 to 15 days,

And the reason is it wasn't the technology. People think, wow, you're able to understand technology in, in half that time. It wasn't really technology. It's the amount of documents, the amount of reading we have to do. This process just pinpoints that I don't have to read every single document. I just need to read the requirements back in the South. I got my information. I know what I need to do.

Our customers are the intelligence community and the DOD. They're out there satisfying missions. And as you know, missions aren't like the consumer place where we can wait a delay to launch a product. Missions are happening all over the world and they need that tech at that point to staff on the mission. There's a window of opportunity to get the tech in their hands to satisfy what they're trying to do. If you miss that mark. They no longer want, they spent money, but they no longer want to use that tech because they missed that window of time. And so that loses the credibility reputation that started, not because they're delivering the product, it's just no one now uses their product and so they're not able to grow their market within the government space. By reducing the time from 45 days down to 10 to 15, we're getting that product into our customers' hands before the admission is even um executed so that there's training, there's using, we resolve issues so that when they use it in the actual mission, it, it It increases the probability that they can use that to satisfy the mission, which then they can then spread that knowledge within the community, within the intelligence community, and more people can jump on board. So, by reducing the time, we're getting it into their hands rather than waiting till the 11th hour and where an opportunity may not exist to use that tool.