What to Bring to a PDM Discovery Meeting
Bring one representative job, a map of its file and approval flow, examples of the problem, and the owners of engineering and IT responsibilities to a PDM discovery meeting. Aim to leave with a scoped next test, not an unverified implementation commitment.
Teams ready to discuss an engineering data-management problem with a technical specialist.
A discovery meeting cannot certify security or implementation readiness.
Prepare one job for the PDM discovery meeting
A discovery meeting is easier to use when everyone can follow the same job. Choose a recent design that moved through engineering, approval and manufacturing. It should represent ordinary work and expose the issue you want to discuss without requiring a full tour of every folder in the company.
List the files involved, their roles and where they travel. Identify the native design, any drawing, exported deliverables and the release record. You do not need to send confidential files before agreeing on an appropriate sharing method; a sanitized inventory and workflow map can establish the initial scope.
State the decision the meeting should support. You may need to understand a revision-control problem, assess a proposed workflow or decide whether a pilot is warranted. Those are different goals from designing a complete deployment.
Bring observed problems with their boundaries
Choose a small number of examples that show the recurring issue. For each one, record what the user tried to do, what happened, the affected deliverable and the consequence. Keep suspected causes separate from observed behavior.
If the problem is finding files, show the information the user had when searching. SOLIDWORKS PDM documents searching by file details and metadata, which makes the available identifying information relevant to a discovery discussion. The exact solution still depends on the files and configured process. SOLIDWORKS PDM product overview.
If the issue is revision uncertainty, bring the package the recipient actually received and the approval reference the team expected them to use. If the issue is recovery, bring the system owner's restore-test record or explicitly state that it has not been supplied. Do not replace missing evidence with a verbal assurance.
Invite the people who own the handoffs
Engineering should describe design work and release intent. Manufacturing or another downstream recipient should describe what information makes the package usable. IT should explain the operating environment, access responsibilities and constraints that affect a proposed system.
The person who approves process changes also needs a role in the decision, even if they do not attend the entire technical discussion. Identify that person in the packet so the meeting does not end with an unowned recommendation.
Avoid asking one participant to approve another function's requirements. An engineer can describe a delay, but that alone does not confirm network architecture, security obligations or commercial authority. Mark those questions for the accountable owner.
Put the method to work
Bring the one-job packet, the affected recipient and the owner of the next decision.
Use the worksheet belowUse an agenda that produces a scoped outcome
Start by agreeing on the problem and the example job. Walk through the current process, inspect the evidence, then identify the highest-consequence uncertainty. Leave product selection until the group understands which control or responsibility needs to change.
For each proposed next action, record the output it should produce. A workflow sketch, a recipient acceptance test and an infrastructure assessment are different deliverables. Give each a named owner and a condition for considering it complete.
If a pilot is the next action, define the users, data, handoffs and exclusions. Identify how the team will determine whether the pilot addresses the observed problem. Avoid treating a broad product demonstration as a substitute for a bounded test of that requirement.
Leave with decisions and open questions separated
Send a short record of what was agreed, what remains uncertain and who owns the next action. Attach the representative workflow and evidence references so later participants can understand the discussion without relying on memory.
A discovery meeting cannot certify a deployment's security, establish complete migration effort or prove production readiness. Those outcomes require their own evidence and acceptance. Keep them listed as future work when they fall outside the meeting's scope.
If the meeting reveals that a procedure change is enough, record that result and test it. If broader evaluation is warranted, carry the same example job forward. The value of the packet is continuity: the next discussion can address the unresolved condition instead of beginning again with an introduction.
Checks to carry into the discussion
| Packet item | What to include | What it should resolve |
|---|---|---|
| Representative job | File roles and movement between people | The workflow being discussed |
| Problem evidence | Observed action, result and consequence | What actually fails |
| Responsibility map | Engineering, recipient, IT and approval owners | Who can accept a change |
| Environment summary | Confirmed versions and relevant constraints | What needs technical verification |
| Decision question | One desired outcome for the meeting | The next useful action |
Download the working worksheet
Complete the evidence and question columns before the meeting, then fill the decision columns during the closeout. Do not include credentials or unrestricted customer data. If an environment detail is unknown, assign it to the person who can verify it. Keep the packet small enough for the participants to inspect and retain the supporting records outside the summary. Share the action record through the agreed project channel after the meeting.
Fields: Packet item · Evidence reference · Observed fact · Suspected cause separately · Responsible role · Question for meeting · Agreed next action · Acceptance condition · Owner · Follow-up date.
The worksheet and decision method are original Morphos 3D guidance. Fill them with your own evidence; the file contains no customer data or assumed results.
Bring the one-job packet, the affected recipient and the owner of the next decision.
A discovery meeting cannot certify security or implementation readiness.
Frequently asked questions
Must the whole file vault be shared before discovery?
No. Start with a representative inventory and sanitized workflow evidence. Agree on any required file-sharing method and scope before sending confidential data.
Is the meeting an implementation plan?
Not by itself. Discovery should establish the problem, responsibilities and next evidence needed. Implementation requires a separately defined scope and acceptance process.
Official references and method
References reviewed October 5, 2026. Product references support the specific capabilities discussed; the worksheets and decision steps are proposed guidance, not vendor benchmarks.
Discuss the next test
Bring the one-job packet, the affected recipient and the owner of the next decision.