Who Is Holding Your Product Launch Together?

For the last few months, I had multiple conversations with people responsible for delivery hardware products – complex equipment, high-tech products, special vehicles and others. The questions that come often are about how to help manufacturers coordinate complex product deliveries. The situation typically involved a product built in small numbers, a program launch or similar when the work distributed across an engineering team and several outside organizations. Contractors developed parts of the product. Suppliers provided components and subsystems. All of it had to come together for final assembly and delivery.

The difficult work was keeping everyone aligned on what had been promised and what needed to happen next. Requirements were understood differently. Sales commitments had not been communicated clearly enough. Information was spread across emails, messages, documents, and spreadsheets. Someone had to reconstruct the situation and keep it current.

If you manage product launches or manufacturing programs, how familiar does that sound?

In the article Is Your BOM Accurate? That May Be the Wrong Question., I explored why an accurate BOM can still not aligned with the information needed to build the product. In Every System Says “Ready.” But Are You Actually Ready to Deliver?, I connected that problem to a specific commitment and the person accountable for it.

I now want to look more closely at the work behind that work project, and an idea we are exploring at OpenBOM is under the working name – Launch Master Agent.

One delivery depends on several organizations

Think about the situation from the launch or program manager’s chair. The organization expects a particular configuration, working to agreed requirements, on a committed date. Engineering is still resolving details. A specialist contractor is developing a subsystem. Another company is fabricating mechanical parts. Component suppliers have their own lead times. The final assembler needs the right combination of hardware, instructions, and test arrangements.

Here is an illustrative example of how those dependencies can become a problem.

Engineering selects a revised control module. Its supplier confirms that it can arrive before assembly begins. But the revision requires a different harness, and the harness contractor is waiting for an approved interface drawing. The assembler’s integration slot assumes that both components will be available together.

The module supplier can meet its date. The harness contractor can be following its agreed process. Yet the time available to protect the integration slot is running out. The program manager needs to connect the engineering decision, the contractor’s unanswered question, and the assembler’s schedule before the delay becomes unavoidable.

A launch review needs to examine those relationships. That examination has a structure, and it is simpler than the systems that hold the information.

Six Questions Every Build Must Answer

Every build must answer six questions. 

1. What are the parts? 
2. Do they fit together? 
3. Where do we buy or fabricate them? 
4. What are the delivery lead times? 
5. How do they route through the plant? 
6. What happens at each station (or manufacturing steps)? 

A bill of materials answers the first. CAD answers the second. Sourcing, ERP, routing plans, and process sheets answer the rest. Different companies keep the answers in different places — enterprise systems, spreadsheets, or someone’s memory. The systems are not the point, but the data from these systems is the most important contributing factor.

A blocker is an inconsistency between answers to these questions. A station expects a part that is not in the BOM. A part in the BOM has no station assigned. The harness situation above is the same kind of problem: the answer to “do they fit together” changed when engineering selected the revised module, and the answer to “what are the delivery lead times” no longer aligns with it. Each blocker feels like a local surprise. Each one is an inconsistency between two answers that were never checked against each other.

This is what a manufacturing delivery readiness problem looks like up close. In the previous article, I argued that every system can report “ready” while the delivery is at risk. Blockers are where that risk becomes concrete — not inside any one system, but between the answers those systems hold.

The work continues after the meeting

In the experience I captured from all these conversations is that earlier steps always require capturing the information and people’s reports . It can be anything – getting access to enterprise systems, producing reports and just sharing Excel files. Once the data is available it needs to be organized and aligned with the teams. Also, communication was brought into a more consistent and collaborative working environment (real time comments and contextual chats actually can. Someone then had to maintain the situation as the work continued.

That last part interests me. A meeting can settle today’s questions. Tomorrow a supplier changes a commitment, engineering revises an interface, or a contractor asks for a decision. Someone has to determine whether yesterday’s plan still holds, bring the affected people together, and follow the action until there is evidence that the issue is resolved. This is where a contextual collaborative environment is the place that can help to close the loops.

How much of a launch manager’s week goes into rebuilding that picture? And how much time remains to make the decisions that require their experience?

OpenBOM’s roots in engineering to procurement

At OpenBOM, we have been working on the connection between engineering and procurement – engineering BOM, orders, PO/RFPs. A design needs to become an organized product structure. That structure needs to support decisions about suppliers, required quantities, and purchasing. The people buying or making the parts need the relevant engineering documents.

Our engineering-to-procurement workflow connects CAD and BOM information with supplier data, purchasing planning, and purchase orders with supporting files. It gives teams a foundation for carrying product information into the work of obtaining the parts.

The harness example shows why that foundation matters. The BOM establishes which module and harness belong in the product. Their revisions and documents help explain what must agree. Purchasing information connects them to the organizations doing the work. The next question is how those relationships affect a particular launch as the information changes.

I see the Launch Master Agent idea growing from this work. Understanding the product and its production and procurement relationships gives us a place to begin examining the wider delivery commitment.

What Is a Launch Master Agent?

The concept I want to test is an assistant working alongside the person responsible for a launch or complex delivery. It would start with a defined commitment: the product configuration, quantity, milestone, and date. Its job would be to help that person see what threatens the commitment and what needs attention next.

For an initial test, I would start with the data sets the team already uses to answer the six questions: BOMs, engineering documents, supplier commitments, contractor updates, and the assembly plan. If those answers live in enterprise systems, we can connect to them. If they live in spreadsheets, we can take the spreadsheets. Together with the team, we would establish which versions apply, what has changed, and where the answers depend on information that is still missing.

The first useful result could be a blocker and action report. For the illustrative harness example, I would want a finding along these lines:

Integration slot at risk. The selected module revision requires the updated harness interface. The harness contractor has not received the approved drawing. Its stated lead time leaves no room before the planned integration slot unless that drawing is released this week.

Evidence and action. Link the applicable module revision, interface drawing, contractor’s dated lead-time response, and assembly schedule. Ask the engineering lead to resolve the interface by Friday. Purchasing must then obtain a revised harness commitment, and the assembler must confirm that the slot still works. Keep the issue open until those dependencies are confirmed.

That example assumes the team has supplied the relevant dates and lead times. If the contractor’s information is stale or the interface impact is uncertain, the finding should say what needs verification. Engineering still needs to confirm technical compatibility, and the program manager still owns the delivery decision.

Over time, I would want the assistant to revisit the finding when a drawing, supplier response, or schedule changes. It could prepare follow-up questions, flag an overdue decision, and show why an issue is ready to close or needs to reopen. This is where I see an agent becoming useful in the recurring coordination work.

This is an exploration. I want to test which parts of the work can be made repeatable with software and AI, where specialist judgment is essential, and whether a team would pay for the resulting support.

Questions for launch and program managers

I would like to hear how this compares with your actual work. Pick whichever question brings a specific experience to mind:

• The commitment. What is your next important milestone, who decides whether to proceed, and what happens if you miss it?
• The last surprise. What recently threatened a launch or delivery? How early did the information exist, and when did someone connect it to the commitment?
• The weekly effort. How many hours do you and your team spend collecting updates and resolving conflicting answers before a readiness meeting?
• The outside organizations. When engineering changes something, how do you establish that the affected contractor, supplier, and assembler have understood and acted on it?
• The decisions. Which unanswered question or overdue decision most often holds up work? How do you make sure it reaches someone who can resolve it?
• The current process. What spreadsheet, program tool, meeting, or personal routine already catches these problems well? Where does it still depend on someone remembering to ask?
• The evidence. What would an assistant have to show before you trusted a warning enough to act? What would prove the issue was resolved?
• The value. What work would this support need to take off your team’s plate to justify paying for it, and who would make that decision?

The experience that prompted this article showed how much effort can go into maintaining a shared understanding of one delivery. I want to learn whether we can make that work easier for the people who carry the responsibility.

What did you personally have to chase down last week to keep a launch or delivery on track?

Share one example in the comments, or contact me at oleg@openbom.com if it is easier to discuss privately. I would be glad to compare notes.

Meantime REGISTER FOR FREE and check how OpenBOM can help you.

Best, Oleg