Taking over a DriveWorks project someone else built

When you inherit a DriveWorks project, do four things before changing a single rule: take a full copy of the group and its files, write down what the implementation is made of, find out which parts are still being changed, and run one real order through it while watching. Most of the damage done to inherited projects happens in the first week, by someone tidying up things they did not yet understand.

This is the situation: the person who built the configurator has left, or the reseller who set it up has moved on, and it is yours now. It mostly works. Nobody can say exactly how.

Day one: secure it

Take a complete copy. A DriveWorks implementation is more than the project file. It is the group, the project files, the master models and drawings, the document templates, and the folders that generated files are written to. Data Management has two tools for this. Pack and Go produces a single package file and suits smaller data sets. Copy Group suits larger ones. Store the copy somewhere the live system cannot write to.

Find out what kind of group it is. An individual group is a single file used by one person. A shared group is a SQL Server database served by DriveWorks Pro Server, and it needs a SQL Server backup as well.

List the machines and accounts. Where does Administrator run? Is there an Autopilot, and on which machine? Is DriveWorks Live running under IIS? Which Windows account do the services run as, and who knows its password? I have seen a Live site go down with a misleading "folder not found" error because a service account's password was changed while it was signed in.

Record the versions. The DriveWorks version and service pack, the SOLIDWORKS version, and the license types. Do not upgrade anything yet.

Map what exists

Open the project in Administrator and take stock. You are building a one-page description, not reading every rule.

Projects in the group, and which of them are actually used. Old experiments are common.
Forms and navigation. Walk through as a user would. Note which fields are required and which appear only for some options.
Variables and constants. How many, and whether they are in categories with sensible names. This is the best quick measure of how the project was built.
Tables. Which hold product data, and where that data comes from: typed in, pasted from Excel, or read from a database.
Captured models. Which master models are driven, and how many drawings.
Documents, such as quotes, BOMs, and emails.
Specification flow and macros. What happens on save, finish, and release.
Connections. Any database, web service, PDM vault, or ERP the project reads from or writes to.

Then look outside DriveWorks. Models that are still full of SOLIDWORKS equations and configurations are doing some of the logic themselves, and a rule change may not have the effect you expect.

Find out what is still moving

A large project is less daunting once you know that most of it has not changed in years.

Compare backups. If there are old copies of the project anywhere, on a file share, in someone's Documents folder, or in a server backup, compare the oldest with the current one. Projx Diff, a free tool I built, writes a single report of every variable, table, macro, form control, and model rule that differs. Areas with many changes are where the product is still evolving. Areas with none are stable, and are the ones to leave alone. See how to compare two DriveWorks projects.

Read the rule revisions. In the Rules Builder, the Revisions button shows earlier versions of a rule with the date, the user, and the comment. On the rules that matter most, such as price and the main dimensions, this shows who changed what and sometimes why.

Start a nightly archive now. From today you want a record of every change, including your own.

Run one real order

Pick a recent, typical order and specify it again, in a development copy, with the diagnostic tools on.

Specification Test Mode runs the whole specification, including navigation and macro buttons, and lets you analyze any rule: the values it used, the steps it took, and a drill-down to where each value came from.
The Rule Profiler logs every event while a specification runs, and helps find the rule that makes a form slow.
Specification Reports and Model Reports say what was driven into each model and whether it worked. Warnings that everyone has learned to ignore are listed there.

Compare the output with what was actually shipped. The differences are your real backlog, and they are usually not what people told you was broken.

Ask the users

Spend an hour with the people who use it. Ask:

What do you fix by hand after it runs?
Which options do you avoid because they do not work?
What do you still do in a spreadsheet beside it?

A workaround everyone knows about is documentation. Write it down.

What not to do in the first week

Do not edit the live project. Set up a development copy, and move changes across deliberately.
Do not rename variables or reorganize categories. It feels like progress, and it makes every later comparison unreadable.
Do not upgrade DriveWorks or SOLIDWORKS. Understand the system on the versions it was built for first.
Do not delete "unused" items. A variable with no visible references may be read by a document, a macro, or a child project.
Do not change a service account, a folder path, or a server name without knowing everything that uses it.
Do not plan a rewrite. Rules and tables that hold years of product knowledge are worth keeping, even when the structure around them is not.

Then make it yours

When the map is on paper, pick one small improvement that users will notice, make it in development, compare before and after, and release it. That first clean release proves the route from development to production works. It also makes the project yours.

If the project is stalled, not just inherited, and you want a second pair of eyes, that is a large part of what I do. See rescuing a stalled DriveWorks implementation.

Common questions

How do I understand a DriveWorks project I did not build?

Take a full copy first. Then list its forms, variables, tables, captured models, documents, macros, and outside connections. Compare old backups with the current project to see what has been changing, and run a real order in Specification Test Mode to see how the rules calculate.

How do I back up a DriveWorks implementation before changing it?

Use DriveWorks Data Management. Pack and Go creates a single package file for smaller data sets, and Copy Group suits larger ones. A shared group also needs a SQL Server database backup.

How can I find out what changed in a DriveWorks project over time?

Compare two copies of the project with Projx Diff, which reports every changed variable, table, macro, form control, and model rule. For a single rule, the Revisions button in the Rules Builder shows its history.

Should I rebuild an inherited DriveWorks project from scratch?

Usually not. Most inherited projects need fixes or restructuring, and the existing rules and tables hold product knowledge that is expensive to recreate. A rebuild is justified only when the foundation fights every change.

How do I debug a rule in DriveWorks?

In DriveWorks Pro, Specification Test Mode's Analyze Rule tool shows the rule, the values it used, the steps taken, and a drill-down into each referenced value. The Rule Profiler logs events as a specification runs.