Your question is a fundamental problem and does not have a single way to be handled. IMHO it boils down to the management of engineers and designers and is fundamental to the success of a company.
IMHO (it might be very simplistic compared to what Jonathan R. Swift might have to offer, since I've only worked in a small company with less than 20 engineers and designers), it boils down to two vectors:
- Workflow for Engineering components design
- Software tools
This is the back bone. This is how it was traditionally done, and its an arbitrary decision by the management of how they seem better fit to address the problems within the company.
So, it boils down to workflows like the following for an Engineering Change Request (Which I consider one of the fundamental blocks of the process).
Figure 1: Workflow for ECR (source SAP)
Basically the engineering Change Request workflow, describes the steps that need to be taken from the moment an request is made to change a part in an assembly to the actual manufacturing of the object and beyond.
IMHO, this is in the core of a successful engineering design team. This type of product management existed before software tools, and nowadays, the software tools (in the best of cases) adapt to a well thought of and designed workflow. If there are flaws in the process, then the software will only replicate these flaws.
Additionally, in order for the workflow to be successful in the implementation, it is important that users are trained to it.
Finally, one common problem with these workflows is that they tend to be too lax or too restrictive/pedantic. Finding the right balance is a complex matter and it even involves understanding and adapting to the core values of any team.
Nowadays (for the past 30 or maybe 40 years) there are tools and even companies that specialize in setting up those systems. It can be from:
- a very generic enterprise resource planning (ERP) software like SAP which includes other aspects of the business.
- Software Tools from 3D CAD companies that help with the management (the problem is that they work mainly for their product usually). For example for solidworks there PDM and EPDM, for CATIA there is ENOVIA I think
- Additionally companies can seem fit to create their own products.
- Finally products like Onshape take the approach to the extreme in their basic product. Basically when you are developing a component, they are doing it similar to software product.
Figure 2: example of version and branching from Onshape
Continuing on from the last note on Onshape, there are a lot of other things that can be borrowed from software engineering about product development methods (btw PeteW's answer which is great, revolves around the concept of encapsulation which is one of the tenets of OOP), in a modern design environment.
(Although some times nothing more than buzz-words) "SCRUM" and "Agile software development" and similar methodologies can offer useful insights, tools and ultimately solutions to the complex and dynamic environment of modern enterprises. The problem they set to achieve is improving the communication and the setting of aims of a group which are all working in the same problem.
So, IMHO, it boils down to improve communication between people and departments of the same company.