The Assembly That Brought a Company to Its Knees

It was 4:47 PM on a Thursday when the entire engineering department stopped working.

Not by choice. Their computers had simply… given up.

The assembly file—a custom industrial packaging machine for a major client—had grown to 6,847 components over eight months of design work. That afternoon, when lead engineer Thomas tried to open it for a routine check, SolidWorks loaded for 47 minutes before crashing with an “out of memory” error.

His workstation had 64GB of RAM. Top-of-the-line graphics card. Latest SSD drives. The IT department’s pride and joy—$4,500 worth of “SolidWorks certified hardware” purchased specifically to handle large assemblies.

The hardware wasn’t the problem.

Five other engineers tried opening the assembly on their machines. Same result. The assembly had crossed an invisible threshold from “slow but workable” to “completely unusable.” The client presentation was Monday morning. Manufacturing needed final drawings by Friday evening. And nobody could open the file.

That night, Thomas discovered something that would change how his company designed everything: Large assemblies aren’t defeated by better hardware. They’re defeated by better strategy.

This is the story of what makes assemblies “large,” why they fail, and how understanding the real problem prevents disasters before they happen.

The Definition Nobody Expects

Thomas spent that Thursday night Googling “how many parts make a large assembly?”

He found forums debating arbitrary numbers:

• “Over 1,000 parts is large”
• “I work with 10,000+ part assemblies daily, they’re not large”
• “500 parts brought my computer to its knees”
• “We have 50,000 part assemblies that open fine”

The confusion was maddening. How could 500 parts be “large” for one person while 10,000 parts were “normal” for another?

Then Thomas found a definition that changed everything:

An assembly is “large” when it exhibits two characteristics:

1. It uses all your system resources
2. It hurts productivity

That’s it. Not the number of parts. Not the file size. Not the physical dimensions. An assembly is “large” when it consumes your computer and your time.

Thomas’s 6,847-part assembly was definitely large—it had consumed all 64GB of RAM and made productivity impossible. But his colleague’s 12,000-part assembly that opened in 90 seconds? Not large, despite having twice as many components.

The difference wasn’t hardware. It was how they were designed.

The Three Faces of “Large”

Over the following weeks, as Thomas worked with a SolidWorks consultant to rescue his assembly, he learned that “large” comes in three distinct flavors:

1. Physically Large: The Layout Monster

Example: A chemical processing plant. 400 components. Pipes, vessels, pumps, valves spread across 50 meters of factory floor.

The challenge isn’t the number of parts—it’s positioning them correctly in 3D space. You need layout sketches, reference geometry, coordinate systems. Without a skeleton model or master layout, engineers spend hours hunting for the correct X/Y/Z coordinates.

Thomas’s colleague Maria worked on these assemblies. Her trick? Start with a 2D layout sketch showing all major equipment positions. Create reference planes at key interfaces. Build everything relative to this skeleton. When the client moved equipment locations, she updated the skeleton and 400 components repositioned themselves automatically.

Physically large without the skeleton? Engineers manually positioned each component, creating hundreds of dimension mates with typed-in values. When changes came, they manually updated hundreds of mates. Errors were inevitable. Rebuild times were brutal.

2. Complex: The Relationship Web

Example: A six-axis robotic arm. 180 components. Every movement of the base affects every downstream component through intricate mate relationships.

Thomas’s assembly fell into this category. It wasn’t physically large—everything fit in a 3-meter cube. But it had:

• 2,847 mates (many redundant or conflicting)
• In-context relationships between 47 parts
• Circular reference loops (part A references part B, which references part C, which references part A)
• Patterns of sub-assemblies containing patterns
• Configurations with different mate schemes

The symptoms:

• Opening the assembly: 47 minutes (before the crash)
• Rotating the view: 3-8 seconds lag
• Adding a single mate: 2 minutes to solve
• Rebuild: 15+ minutes
• Switching between configurations: crashed every time

The computer wasn’t slow. The relationship web was so tangled that SolidWorks spent 99% of its time solving mate equations, not displaying geometry.

3. Multi-Disciplinary: The Integration Nightmare

Example: Thomas’s packaging machine combined:

• Custom machined parts (designed in-house)
• Weldment frames (SolidWorks Weldments)
• Pneumatic systems (SolidWorks Routing)
• Electrical conduit (SolidWorks Electrical)
• Purchased components (vendor STEP files)
• Toolbox fasteners (thousands of them)
• Library parts (bearings, motors, sensors)

Each discipline brought its own complexity:

• Weldments with cut lists and configurations
• Routing with complex 3D paths and fittings
• Vendor files with unknown quality and excessive detail
• Toolbox parts loading from network drives
• Library parts stored in seven different folders

The file management nightmare:

• Some files on local drives
• Some on network shares
• Some in PDM vault
• Vendor files in email attachments
• Reference files scattered across folders

When one engineer moved a folder, 200 assembly references broke. When someone updated a library part, 30 assemblies using that part became corrupted. When the network was slow, opening assemblies took 30+ minutes just loading external references.

The Performance Pain Points

Thomas created a spreadsheet tracking where time was lost. The results shocked him:

His broken 6,847-part assembly (before fixes):

• Opening: 47 minutes (then crashed)
• Saving: 12 minutes (when it worked)
• Rebuild: 15 minutes
• Creating drawing: 35 minutes for first view
• Rotating view: 3-8 second lag
• Panning/zooming: 2-5 second lag
• Inserting component: 8 minutes
• Adding a mate: 2-4 minutes
• Switching to part mode: 3 minutes
• Switching back to assembly: 5 minutes

Total time lost per day: Engineers estimated 3-4 hours waiting for SolidWorks. Out of an 8-hour workday, only 4-5 hours were productive work.

His colleague’s 12,000-part assembly (properly designed):

• Opening: 90 seconds
• Saving: 8 seconds
• Rebuild: 12 seconds
• Creating drawing: 45 seconds for first view
• Rotating/panning: Instant
• Inserting component: 15 seconds
• Adding a mate: 5 seconds
• Switching modes: Instant

Time lost per day: Maybe 10 minutes of waiting. 7 hours and 50 minutes of productive work.

The difference: Same computer. Same SolidWorks version. The assembly design strategy made the difference between 50% productivity and 98% productivity.

The 80/20 Rule That Changes Everything

The SolidWorks consultant who saved Thomas’s project showed him something profound:

Performance problems breakdown:

• 20% caused by software/hardware (bugs, algorithms, code efficiency, slow computers)
• 80% caused by user decisions (modeling practices, file management, design strategy)

“Everyone wants to blame SolidWorks or buy a faster computer,” the consultant said. “But I see the same pattern everywhere: Give poor designers faster computers, they just create slower assemblies faster.”

He pulled up Thomas’s assembly and started pointing:

Software/Hardware Issues (20%):

• SolidWorks graphics algorithm inefficiency with certain geometry types
• Windows file system overhead when loading thousands of files
• Graphics driver compatibility with specific GPU model

User-Created Issues (80%):

• No simplified configurations (loading full detail on every part)
• In-context relationships creating circular references
• Redundant mates (five mates where two would suffice)
• Patterns of patterns of patterns
• Library parts stored on slow network drives
• No file management system (PDM)
• Imported vendor files with excessive detail never cleaned up
• Configurations at assembly level causing constant rebuilds
• Cosmetic threads modeled on 847 bolts
• No assembly structure (flat 6,847-part list instead of organized sub-assemblies)

“You’ve got a $4,500 computer trying to overcome $0 worth of planning,” the consultant said. “That math never works.”

The Small Fixes That Accumulate Into Disaster

Here’s what Thomas didn’t understand: His assembly didn’t become unusable overnight. It died slowly, one small bad decision at a time.

Month 1: “We’ll add detailed vendor models. They look professional.”
Cost: 200 vendor parts with excessive detail, +8 minutes open time

Month 2: “Let’s use in-context modeling for these brackets. So convenient!”
Cost: 47 in-context parts creating relationship web, +5 minutes rebuild time

Month 3: “We’ll model threads on all bolts for the renderings.”
Cost: 847 bolts with helical threads, +12 minutes open time, +4GB file size

Month 4: “No time for sub-assemblies. We’ll organize it later.”
Cost: Flat 6,847-part structure impossible to manage, +15 minutes for any operation

Month 5: “These mate errors? We’ll fix them when we have time.”
Cost: Redundant and conflicting mates creating solve errors, +8 minutes rebuild

Month 6: “Simplified configurations? That’s extra work. Skip it.”
Cost: Every part loading full detail, +18 minutes open time

Month 7: “The assembly is slow but still works. Keep going.”
Cost: Engineers working around problems, 2-3 hours per day lost waiting

Month 8: Crash. Assembly unusable. Project in jeopardy.

Each decision seemed insignificant at the time. Together, they compounded into catastrophe.

The consultant’s wisdom: “Slower performing assemblies are the accumulation of many small mistakes. There’s no quick fix because there wasn’t one big problem. You need to undo months of bad decisions.”

The Blame Game That Solves Nothing

Thomas’s immediate instinct after the crash: “We need better computers!”

His manager’s response: “We just spent $27,000 upgrading the entire department six months ago. What we need is better designers.”

That stung. But Thomas eventually realized it was true.

He saw it play out with a new engineer, Kevin, who joined the team:

Kevin’s approach:

• Started new assembly
• No planning, just started inserting components
• “I’ll organize it later”
• Added mates randomly as needed
• Used full-detail vendor models without simplifying
• Created in-context features liberally
• No simplified configurations
• No sub-assembly structure

After 2 months: Kevin’s 800-part assembly took 8 minutes to open and was nearly unmanageable.

Maria’s approach:

• Spent first week planning assembly structure
• Created sub-assembly breakdown
• Defined file naming conventions
• Simplified all purchased components
• Created simplified configurations for reusable parts
• Built skeleton model for layout
• Organized into logical sub-assemblies from the start

After 2 months: Maria’s 3,200-part assembly opened in 45 seconds and was easily manageable.

Same computer. Same SolidWorks version. Opposite results.

Kevin wanted faster hardware. Maria wanted better processes. Guess whose career progressed faster?

The Strategy That Saved Thomas’s Project

The consultant laid out a brutal truth: “You can’t fix this assembly. You have to rebuild significant portions with proper strategy.”

The three-pillar strategy:

Pillar 1: Effective Part Modeling

Every part was reviewed and fixed:

Problems found:

• Parts with origins far from geometry (from in-context creation)
• Unnecessarily complex features
• Circular references between parts
• No simplified configurations
• Excessive detail (cosmetic features, text, tiny fillets)

Solutions applied:

• Fixed part origins to sensible locations
• Simplified feature trees (combined features, removed redundancy)
• Broke all in-context relationships
• Created “SIMPLE” configuration for every part
• Suppressed cosmetic features in simplified configs

Result: Average part file size dropped 40%. Average part rebuild time dropped 70%.

Pillar 2: Effective Assembly Organization

The flat 6,847-part list was restructured:

New structure:

• Frame sub-assembly (347 parts)
• Drive system sub-assembly (892 parts)
• Conveyor sub-assembly (1,243 parts)
• Control panel sub-assembly (234 parts)
• Pneumatic system sub-assembly (678 parts)
• Electrical routing sub-assembly (421 parts)
• Purchased components sub-assembly (2,847 parts)
• Fasteners sub-assembly (1,185 parts)

Each sub-assembly was independently loadable and testable. Changes to one didn’t force rebuilding everything.

Mate optimization:

• Removed redundant mates (had five mates where two sufficed)
• Fixed conflicting mates causing solve errors
• Used proper mate types (coincident, not distance=0)
• Added mate references to frequently-used parts
• Organized mates by sub-assembly

Result: Mate solve time dropped from minutes to seconds.

Pillar 3: Reducing Memory Load

The assembly was configured to load only what’s needed:

Techniques applied:

• Quick Open (loads assembly structure without loading all components)
• Lightweight mode (loads only envelope data, not full geometry)
• Simplified configurations (opened all components in SIMPLE config)
• SpeedPak for sub-assemblies (only external faces loaded)
• Draft quality drawings (lower resolution for working drawings)

Purchased component cleanup:

• Vendor models simplified (removed internal detail, threads, tiny features)
• Para-solid bodies created for complex vendor parts (geometry only, no features)
• Library parts stored locally, not on network

Result: Memory usage dropped from 64GB (crashing) to 18GB (comfortable).

The Recovery Numbers

Thomas’s assembly transformation:

Before (Month 8 – Unusable):

• Opening: Crashed
• When it worked: 47 minutes
• Components loaded: 6,847 in flat structure
• Memory usage: 64GB+ (crashed)
• Mates: 2,847 (many redundant/conflicting)
• Engineer productivity: 50% (3-4 hours per day waiting)

After rebuild (Month 10 – Fully Functional):

• Opening: 2.3 minutes (first open)
• Opening: 12 seconds (subsequent opens with Quick Open)
• Components: 6,847 organized in 8 sub-assemblies
• Memory usage: 18GB
• Mates: 1,247 (optimized, no redundancy)
• Engineer productivity: 95% (maybe 20 minutes per day waiting)

Cost of rebuild:

• Consultant fees: $12,000
• Engineering time: 3 weeks (2 engineers full-time)
• Total cost: ~$45,000

Cost of not rebuilding:

• Project would have been canceled
• Client would have been lost ($2.4 million contract)
• Company reputation damaged
• Engineers would have continued struggling with unusable tools

The choice was obvious.

The Practices That Prevent Disaster

Thomas became evangelical about large assembly strategy. He created a checklist used before starting any project:

File Management (Foundation)

Questions to answer before starting:

• Where will files be stored? (Local? Network? PDM?)
• Who needs access to which files?
• How will we prevent accidental overwrites?
• Are file properties/metadata standards defined?
• What’s our naming convention?
• How will we track revisions?

The disasters to prevent:

• Engineers unable to locate files
• Working on wrong version of files
• Files accidentally overwritten
• Network problems preventing file access
• Missing references breaking assemblies

Thomas’s rule: “Plan file management first, model parts second. Never the other way around.”

Component-Level Strategy

Decisions to make:

• Will we use in-context features? (Use during design, lock/break before release)
• How many configurations per part? (Limit to 2-3: Full Detail, SIMPLE, maybe Drawing)
• Will library parts be simplified? (Always—never use full-detail vendor models)
• Will we use para-solid bodies for purchased components? (Yes, when appropriate)

The simplified parts philosophy:

• Every reusable part gets a SIMPLE configuration
• Suppress fillets under R2mm
• Suppress text engravings
• Suppress cosmetic features
• Use cosmetic threads, never modeled threads

Thomas’s measurement: “If a part takes more than 0.5 seconds to rebuild, it needs simplification.”

Assembly-Level Strategy

Structure decisions:

• How will sub-assemblies be organized?
• What’s the proper level of detail for each sub-assembly?
• What mate types will we standardize on?
• Will we use SpeedPak for sub-assemblies?
• How will we handle configurations at assembly level?

The sub-assembly philosophy:

• Group by function, not by arbitrary size
• Each sub-assembly should be independently loadable
• Limit sub-assembly nesting to 3-4 levels maximum
• Use SpeedPak for large sub-assemblies (1,000+ parts)

Data Sharing Strategy

The four requirements:

• Access to all necessary files (organized storage, proper permissions)
• Access to most current version (PDM system or strict file protocols)
• Ability to make changes responsibly (check-in/check-out system)
• Protection from accidental overwrites (PDM locks or strict procedures)

Thomas’s hard lesson: “Without proper data sharing, even the best-designed assembly becomes unusable when five engineers need simultaneous access.”

The Truth About “Quick Fixes”

After Thomas’s success, other engineers approached him: “Can you fix my slow assembly?”

His answer disappointed them: “There are no quick fixes.”

Why no quick fixes exist:

1. Slow assemblies are accumulations
Like gaining weight—it doesn’t happen from one meal, it happens from months of small decisions. Reversing it requires addressing each decision.

2. Problems are interconnected
Fix the parts, and assembly structure is still wrong. Fix the structure, and file management still causes problems. Fix file management, and mate strategy still creates solve errors. Everything must be addressed.

3. Symptoms have multiple causes
“My assembly is slow to open” could be caused by:

• No simplified configurations
• Excessive detail in parts
• Files stored on slow network
• Too many mates
• Poor assembly structure
• Inefficient graphics settings
• In-context relationships
• … and 20 other factors

Quick fixes address symptoms. Proper strategy addresses causes.

Thomas’s reality check: “People want a magic button. They get angry when I say their assembly needs restructuring. But that’s the truth: Professional work requires professional processes. There are no shortcuts.”

The Company Transformation

The near-disaster with Thomas’s assembly triggered company-wide changes:

New Project Requirements:

Week 1 of any project:

• Create file management plan
• Define sub-assembly structure
• Create part templates with simplified configs
• Establish mate standards
• Document assembly strategy
• Get approval before modeling starts

Monthly reviews:

• Assembly performance checks
• File organization audits
• Mate efficiency reviews
• Part simplification status

Before release:

• All in-context relationships locked/broken
• All parts have simplified configurations
• Sub-assembly structure finalized
• SpeedPak created for large sub-assemblies
• Assembly performance verified

Training Changes:

New engineers now receive:

• Two weeks of large assembly strategy training
• Practice projects with performance requirements
• Mentorship on proper modeling practices
• Access to example assemblies (good and bad)

Kevin (the struggling engineer) was retrained.
His next assembly: 2,800 parts, opened in 38 seconds, functioned perfectly. He later became the company’s assembly strategy advocate.

The Results After 18 Months:

Before strategy implementation:

• Average assembly open time (>1,000 parts): 12-25 minutes
• Engineer productivity: 60-70% (3-4 hours daily waiting)
• Assembly-related project delays: 40% of projects
• Computer upgrade requests: Constant
• Emergency assembly rebuilds: 4-5 per year

After strategy implementation:

• Average assembly open time (>1,000 parts): 45-90 seconds
• Engineer productivity: 90-95% (20-30 minutes daily waiting)
• Assembly-related project delays: <5% of projects
• Computer upgrade requests: Almost none
• Emergency assembly rebuilds: Zero in 18 months

Financial impact:

• Saved computer upgrade costs: ~$80,000 (avoided unnecessary hardware)
• Reduced project delays: ~$340,000 (faster delivery, fewer penalties)
• Increased engineer productivity: ~$520,000 per year (5 engineers × 2 hours daily × $50/hour × 250 work days)

Total 18-month benefit: $1.46 million
Investment in training and process development: $85,000
ROI: 1,620%

The Definition Revisited

Thomas now teaches new engineers: “An assembly is ‘large’ when it uses all your resources and hurts productivity. But here’s what I learned: That definition describes your strategy, not the assembly.“

Good strategy = Small assemblies
Even 20,000 parts can be manageable with proper planning.

Poor strategy = Large assemblies
Even 500 parts become unmanageable without planning.

The assembly doesn’t make itself large. Your decisions make it large.

The Questions to Ask Before Starting

Thomas’s final checklist—printed and posted in every engineer’s cubicle:

Before opening SolidWorks, answer these:

□ Do we have a file management plan?
□ Do we know our sub-assembly structure?
□ Have we defined our simplified configuration strategy?
□ Do we know how purchased components will be handled?
□ Have we established mate standards?
□ Do we have a plan for in-context relationships?
□ Have we set performance benchmarks?
□ Do we know when to use SpeedPak?
□ Have we defined our data sharing protocols?
□ Have we documented this strategy for the team?

If you can’t check every box, you’re not ready to start modeling. And that’s okay. Taking one week to plan prevents taking three months to fix.

The Night That Changed Everything

That Thursday night when Thomas’s assembly crashed, he thought his career was over. The project seemed doomed. The client presentation impossible.

Looking back, he calls it “the best disaster that ever happened to me.”

Because it taught him:

• Hardware is not the solution to strategy problems
• Planning prevents disasters better than fixing solves them
• 80% of performance problems are under user control
• Small bad decisions accumulate into catastrophic failures
• Professional work requires professional processes
• There are no quick fixes, only proper foundations

His advice to every engineer:

“Your assembly will eventually test your strategy. It will stress your processes. It will expose your planning failures. You can learn this lesson the easy way—by studying best practices and implementing them from the start. Or you can learn it the hard way—with a crashed assembly, a looming deadline, and a panicked all-nighter trying to salvage months of work.

The choice is yours. But understand: The lesson will come. Choose how you want to receive it.”

Have you experienced the pain of large assembly disasters? What strategies saved your projects—or what mistakes taught you hard lessons? Share your stories in the comments. We all learn from each other’s Thursday night crises.

This article is part of our Engineering Design Excellence series, where we transform technical challenges into strategic advantages.