Rescuing a stalled DriveWorks implementation

Most stalled DriveWorks implementations were built around the software instead of around how the shop actually quotes, designs, and ships. Getting one moving again starts with a review of what exists and what people do every day, not with a rewrite.

Why implementations stall

A lot of my work starts with implementations that stalled, and the usual cause is the same: the project was built around the software instead of around how the shop actually quotes, designs, and ships.

The second cause is the engineering mindset itself. Engineers are trained to get the whole design on paper before metal is cut, because rework is expensive. Software pays off the other way round: ship something simple, get feedback, improve it. A DriveWorks project held back until it handles every option tends never to ship.

Signs a DriveWorks project is stuck

The pilot works, but only engineering uses it. Sales still sends a request and waits.
One person understands the project, and they have a day job.
Nobody is sure what changed. Edits go straight into the live project and there is no record of what was different last month.
Old specifications cannot be reopened cleanly. Form data is stored inside the specification, frozen with the controls and rules that existed the day it was created, so every project change risks breaking the back catalog.
The models are the bottleneck. They were made "smart" with SOLIDWORKS equations and configurations first, and DriveWorks was layered on top.
The output still gets re-keyed into the ERP, so the business sees a nicer form and the same data entry.

What I look at first

How the shop runs. I start on the shop floor: how a quote becomes a drawing and a drawing becomes a part, and where people wait.
What exists. The project's variables, rules, tables, macros, and forms, and how the SOLIDWORKS models are structured. Comparing versions with Projx Diff shows what has been changing and what has not been touched in a year.
Where the time goes. The step that costs the most hours or causes the most errors, which is rarely the step the project was built to fix.

Then the plan is deliberately small: one improvement that is simple, independent of other systems, and visible to the most people. The same rule that picks a good first project picks a good restart.

Fix, restructure, or rebuild

Most stalled projects need a fix or a restructure, not a rebuild. Rules and tables that already encode the product knowledge are worth keeping even when the structure around them is not.

A rebuild is right when the foundation fights every change. One example: B & S Automação e Projeto, a conveyor manufacturer in Brazil, where a DriveWorks rebuild took drawing time per conveyor section from 1-2 days to 15-20 minutes.

For companies with several product lines, the fix is sometimes above the project level. For an HVAC equipment manufacturer the work was portfolio-level DriveWorks architecture alignment, so each product line stopped solving the same problem its own way.

Keeping it from stalling again

Your team owns the logic. The aim is a project your people can change as the business changes, without calling the original developer.
Changes are visible. Archive the projects and diff them, so "what changed?" has an answer. How to compare DriveWorks projects.
Feedback has somewhere to go. A project that helps many users generates feature requests, and that backlog is what keeps an implementation alive.

Common questions

Why do DriveWorks implementations fail or stall?

Usually because the project was built around the software's features instead of around how the company quotes, designs, and ships. Other common causes are holding the release until every option is covered, a single person carrying all the knowledge, and automating SOLIDWORKS models that were never structured to be driven.

Do we have to start over?

Usually not. Most stalled DriveWorks projects need a fix or a restructure. Existing rules and tables encode real product knowledge and are worth keeping. A rebuild makes sense only when the structure fights every change.

Can you take over a project built by someone else?

Yes. Base 10 Consultants is often brought in to get a stuck or inherited DriveWorks project moving again, starting with a review of the existing project and the day-to-day process around it.

How do we find out what changed in our DriveWorks project?

Compare two copies of the project. Projx Diff is a free tool from Base 10 that reports every changed variable, rule, table, macro, document, and form control between two versions of a DriveWorks project.