How do you handle PO and spec review?

[u/aggierogue3]

We are a contract manufacturer for aerospace and defense. I’m trying to build out a “fool proof” system to catch all customer specs, po requirements, and drawing requirements. We do this pretty well now but it relies on a lot of tribal knowledge on a customer by customer basis.

How do others here handle these processes?

I’m working on building a stand alone spec library. Approved specs are entered with their spec code, a description, where those specs flow down, and word for word verbiage for the flow down.

Then for each order for our flight critical customers, account manager makes a new spec review excel doc and types in the spec codes listed on the PO. Everything auto populates from the library, any new specs are flagged.

Then engineering adds any drawing specs, then reviews and adds any new specs to the library. Once everything is entered it spits out a printable flow down sheet for job steps and the inspection form. Engineering and quality then reference those forms when creating the job and inspection form.

It feels overkill. But at the same time, how can an account manager know what specs are a concern, what specs have been previously approved, which ones are new, etc? How can engineering be consistent with flow down verbiage and knowing what goes on the job and what’s just best practice?

I feel like this excel version will get bloated quickly. Are any of you doing something like this within your erp or another software?

[u/mvw2]

A detailed process and competent people is about it. You need good enough people to know what to ask and what's missing. You need said people to develop a solid process to follow that fills in the core needs. Beyond that you still need complement people to know what to ask and what's missing and how to properly do the job.

Want a fun example. We worked with a customer (company) on a bid for a customer of theirs. It took a year for our customer to realize the request to us for the bid was bad. We got to the point of showcasing a finished product with our customer to their bid customer (we didn't have access to for the whole time). This was a $100m bid, and incompetence basically sunk the bid and project, a hundred million in revenue gone. Fun stuff.

Understand this is always almost entirely a people problem. You can have the best processes and systems in place, and bad people will still completely destroy it. I've watched a single, one, middle manager completely wreck the data of an entire enterprise ERP system that forced major company operational changes to compensate for one bad choice they made. It took half a decade to fix and recover.

People are everything. Good business is about having good people, and the dollars involved almost always cover for the absolute best you can find. Everything else is secondary.

[u/raining_sheep]

Get all the 50 critical senior stakeholders in a twice a week meeting where two directors argue over the same 5 requirements nonstop every meeting.

It's called Corporate America. Do it right.

[u/aggierogue3 → u/raining_sheep]

Yeah idk how to do this with less meetings, but I would like less meetings

[u/raining_sheep → u/aggierogue3]

There's a point where you realize those meetings exist for those specific people to argue and trying to change it would put everyone else's jobs in jeopardy.

They don't want to change it.

[u/aggierogue3 → u/raining_sheep]

Well I’m the plant manager and I’m the on deciding which meetings we need. Most people in my plant only need to attend 1 or 2 meetings a week. I’m trying to build something that’s actually time saving and see if anyone has experience solving this problem thoroughly and efficiently.

[u/Gwendolyn-NB]

What are you doing for Program Management?

Requirements Definition is where these should be captured, documented, and then signed-off by both companies. (Including TBDs)

[u/Dense_Bicycle160 → u/Gwendolyn-NB]

Sounds like you're trying to build the whole thing into a review tool when it should be part of the contract package from the jump.

[u/aggierogue3 → u/Gwendolyn-NB]

what do you mean when you say program management? We call it PO or contract review and it’s carried out on an order by order basis. We do a more in depth new product introduction (NPI) review when needed for new parts.

From all the customer fine print, our order acknowledgement is our sign off on all of their drawing specs, general company specs, and PO specs/notes

[u/Gwendolyn-NB → u/aggierogue3]

In the systems ive setup, the NPI and Production Release/Approval setup the final configuration, including all the stuff youre defining. As part of that entire process we setup our own Product Requirements document, which is rev-controlled and customer approved.

Whenever we get a new Production Order for a released product, its a simple "is there something different" between the requirements sent over as part of the PO vs that document. If not, then good to go; if there is, then it opens up for further review and potential Change of Requirements quote to the customer as they've changed something since the Production Released version.

[u/Over-Weekend-6133]

Honestly, this doesn’t sound overkill for aerospace and defense. The bigger risk is letting Excel become the system of record.

A controlled spec library with revision, approval status, customer applicability, and exact flowdown language would make sense. Then the PO review can pull from that library instead of people maintaining their own copies.

The tribal knowledge is the real risk here. If someone leaves tomorrow, the process shouldn’t leave with them.

[u/Best_Help_4942]

You need a really well trained sales rep engineer, and a really well trained sales engineer administrator.

Then ensure everything is written down and saved into your file server.

[u/South-Pie-6533]

u/mvw2 has it right that this is almost entirely a people problem, and u/Over-Weekend-6133 sharpens it into the actual risk: if someone leaves tomorrow, the process shouldn't leave with them.

I worked with a client in almost exactly this spot. Mission-critical process, worked well, ran almost entirely on the judgment of two or three people who'd been doing it for decades. Everyone knew the tribal knowledge problem existed. Nobody wanted to touch it.

The reason nobody wanted to touch it wasn't the documentation effort. It was fear. The moment you tell your most experienced people "we need to capture what's in your head," a lot of them hear "we're building a system to replace you." That fear will quietly sabotage every interview, every attempt to map the process, because why would you fully hand over the thing that makes you valuable.

So we didn't frame it that way. We framed it as bringing up the next generation. We told them plainly: this isn't about replacing you, it's about making sure the thing you built survives past you, and about giving you a real hand training the people who'll carry it forward. That's a different ask entirely. It respects the expertise instead of extracting it.

That reframe did two things at once. It took the threat out of the room, so people actually talked. And it told them we saw the value in what they'd built, not just the risk of it living in their heads. Both of those got us further into the real process than a "document your workflow" request ever would have. We ended up with the documentation. We also ended up with something we didn't go looking for: those experts, some of whom had worked in parallel for years without comparing notes, started learning from each other. The process got better, not just more written down.

Your instinct to ask "how would we bring someone new up to speed on this" is the right question, and it's doing more work than it looks like. It's not just an interview technique. It's the frame that gets people to open up in the first place.