Selecting PDMS or SmartPlant 3D Without a Demo Trial

On your selection panel, the fault looks simple: both PDMS and SmartPlant 3D appear capable, but neither supplier provides a trial that lets your engineers test real work. Start here: treat a polished demonstration as a screening step, not proof that the software fits your projects. Build a controlled acceptance test around your own engineering changes, deliverables, and administration requirements.

Identify the decision that is actually blocked

The immediate problem is not the missing demo license. It is the lack of comparable operating evidence. Training on both systems before screening them wastes time, while buying from a presentation alone transfers every unanswered question into implementation.

Symptom	Likely cause
Both presentations look equally capable	The suppliers demonstrated different workflows or selected only favorable functions.
PDMS appears difficult to use	The observed release, interface, or configured environment may not match the version being offered.
Undo behavior is unclear	Reports conflict across PDMS environments; verify the exact release and command scope live.
SmartPlant 3D looks better in product material	Descriptions have not been tested against your project data and change cases.
Migration risk dominates the discussion	The evaluation mixes a new installation with replacement of an established production system.

Your first reading is the exact product release, configuration, and deployment scope proposed by each supplier. If either supplier cannot identify what will be demonstrated and delivered, stop that branch until the offer is specific.

Confirm the exact release and operating context

Do not score the product family name. Score the offered release in the configuration you would deploy. PDMS usability reports differ: older observations describe limited undo behavior, while PDMS 11.6 is described with Windows-style interfaces and Undo/Redo functions. That means “PDMS has no undo” is not a useful acceptance statement.

1. Record the complete release shown during the demonstration.
2. Ask the supplier to identify which commands support Undo/Redo and which changes require another recovery method.
3. Have the operator create, modify, undo, redo, save, close, and reopen the same object.
4. Record whether reversal operates at the command, object, transaction, or session level.
5. Repeat the test using the release named in the commercial proposal.

If the demonstrated behavior matches the offered release, continue to the workflow test. If it differs, require another demonstration on the offered build. Changing training material or interface preferences will not correct a release mismatch.

SmartPlant 3D is positioned as the next generation of PDS. That relationship does not make migration automatic or prove that an early release is ready for your workload. An established PDS v7.0 installation was retained in one reported case while SmartPlant 3D matured and migration problems were addressed. A company starting without legacy project data faces a different branch: it can test the new platform directly without first protecting an operating PDS workflow.

Force the model through a real design change

Start the functional demonstration with a change, not a clean modeling sequence. Initial model creation hides the cost of revision, which is where plant projects consume engineering hours.

1. Provide both suppliers with the same small, representative model scope and written change request.
2. Have the operator build the initial condition while your engineers observe every command and prerequisite.
3. Change a piping line size after components have been placed.
4. Record which connected components update, which require replacement, and which relationships must be repaired manually.
5. Inspect the model for disconnected items, invalid specifications, or stale derived output.
6. Undo or otherwise reverse the change, then apply it again.

PDS/SmartPlant capability was specifically described as allowing a line-size change without deleting and replacing every component. Treat that as a testable acceptance criterion, not a product-wide assumption. Require the offered SmartPlant 3D release to perform the change on screen using your representative case.

If either system completes the revision without reconstructing the line and produces correct downstream results, move it to output testing. If both require extensive repair, determine whether your supplied model rules, catalogs, or specifications caused the result before rejecting the platform.

Test reports, drawings, and recovery behavior

A model is not the final deliverable. Run the outputs your disciplines issue and check whether a change propagates into them correctly. PDMS has been credited with strong graphics and report production, but those broad observations do not prove that your templates, attributes, naming rules, or approval workflow will work without configuration.

1. Give each supplier a short list of required reports and graphical deliverables.
2. Generate them from the initial test model.
3. Apply the controlled line-size change.
4. Regenerate every affected output.
5. Compare quantities, identifiers, dimensions, and revision state against the modified model.
6. Introduce one deliberate modeling error and show how the system finds, reports, and corrects it.
7. Close the application unexpectedly in a disposable test session, then demonstrate the supported recovery process.

If the outputs update correctly and the error is traceable, continue to administration. If the operator repairs results outside the system, record that work as a recurring project cost. More user training will not fix a missing data relationship or unsupported deliverable.

Separate new deployment from migration

Read the deployment branch before comparing price. A new installation mainly needs catalogs, specifications, conventions, interfaces, hardware, licensing, training, and project templates. A migration must also preserve legacy model meaning, identifiers, deliverables, and active-project continuity.

For a new installation, ask each supplier to configure one representative project and explain who owns each administrative task. Count the proposed licenses by role and concurrency rather than naming an unverified total. The number of required licenses was a material selection question, but no universal count applies.

For migration from PDS or another established system, require a pilot conversion. Compare object counts and key attributes before and after conversion, regenerate deliverables, then execute the same design-change test. A successful model opening is not migration acceptance; usable data and repeatable revisions are.

If the pilot preserves the selected data and workflows, proceed to commercial comparison. If it loses required information, price training and remediation explicitly or keep the existing system until the gap is resolved.

Run a scored demonstration and verify the choice

Close the resolving branch with two supplier-led demonstrations performed against one script. Do not let either supplier substitute a prepared showcase.

1. Write pass/fail criteria for release identity, modeling, line-size revision, Undo/Redo scope, reports, graphical output, error detection, recovery, administration, and migration where applicable.
2. Send the same script and sample data to both suppliers before the session.
3. Require the proposed production release and record every unavailable function, manual workaround, and prerequisite.
4. Have your engineers repeat the critical workflow under supplier supervision. This is a focused evaluation session, not full product training.
5. Score completion, operator actions, repair effort, output correctness, and supplier commitments.
6. Put unresolved claims into the purchase acceptance criteria, including the exact release and tested workflow.

Verify the selected system by repeating the complete model-change-output cycle after the evaluation environment is rebuilt from documented configuration. The result passes only when another assigned engineer can follow the procedure and obtain the same model and deliverables.

FAQ