In many tenders, a clause may go unnoticed but have significant consequences: the requirement to use specific software to produce the reports. This tool may be imposed by the client and simply carried over from one contract to the next out of habit.
This requirement is not always based on a recent technical analysis. It reflects a historical choice, incorporated into internal procedures ten or fifteen years ago, at a time when a few players dominated the market and imposed their formats as de facto standards. These choices have been incorporated into standard tender specifications, passed from one tender to the next, without ever being questioned.
The market has changed. Tools have evolved. Alternatives have multiplied. Software clauses, however, have often remained unchanged. And it is the design offices that pay the price.
Furthermore, these requirements often represent only a few per cent of total turnover and could be subcontracted.
The specific risks facing your engineering consultancy
Working with a pre-selected tool means training your teams on a solution over which you have no strategic control. It means organising your processes around software over which you have no control over pricing, no influence on future developments, and no recourse if the publisher changes its terms and conditions.
It also means silently accepting a real loss of productivity. Tasks that the right tool would automate—managing cross-references, generating cable lists, updating diagrams after changes, and so on—sometimes become manual. This wasted time doesn’t show up in quotes. It is absorbed by the teams, eroded from margins, and offset by extra workload. And ultimately, it is the quality of the deliverables that suffers. A construction file produced with an unsuitable tool is less rigorous, less consistent, and more difficult to maintain. It is the design office’s reputation that is at stake, not that of the client.
Changing tools : a strategic investment, not a constraint
‘We’ve always used this software; our files are in it, and our teams are familiar with it.’ This is the most common argument. And it is also the one that keeps design offices trapped in a dependency they did not choose.
A history of files does not justify remaining tied to a single software vendor. Migrating to more suitable software represents a one-off, structured and predictable effort. Dependence on a single vendor, however, is a constant risk: non-negotiable price increases, imposed updates, no recourse in the event of a dispute, and vulnerability if the product is discontinued.
There is also a direct commercial dimension. A design office equipped with a high-performance, independent tool can cater to a wider range of markets. It is not constrained by the demands of a dominant software vendor, nor forced to turn down projects because its tool does not cover certain areas. Those who remain out of inertia are ceding market share to better-equipped competitors.
Interoperability : the right argument when dealing with clients
The most common argument used to justify imposing specific software is format compatibility. The client wants files that can be read in their environment, exported to their document management system, and integrated into their coordination tools.
This is a legitimate requirement. But it does not justify imposing a specific production tool. What matters to the client is the deliverable: standardised PDFs, open exchange formats such as DWG™, and structured, usable data. Good specialist software handles these exports natively, without any extra work. The internal production workflow need not be sacrificed to meet an output format requirement. It is precisely on this point that design offices must be able to make their case: what matters is the result, not the tool that produced it.
FTZ Informatique Industrielle
For over 30 years, FTZ has been developing CAD software specifically for technical design offices. The range is built around a simple principle: every profession deserves a tool designed specifically for it, not a general-purpose tool adapted only marginally.
The range is modular and independent. A design office can start with the scope that matches its activity and develop its tools in line with its projects, without disrupting its organisation. SchemELECT for industrial electrical design, SchemBAT for building wiring, and additional modules to cover the specific needs of each organisation. No ties to a proprietary ecosystem imposed by a large group or a client. The deliverables produced remain the property of the design office, in durable and usable formats.
Conclusion
Allowing software to be imposed on you out of habit means giving up some of your operational autonomy without even realising it. Electrical engineering firms that take back control of their tools gain in productivity, independence and the ability to win new business. Choosing the right industry-specific software is not a technical detail. It is a management decision that affects the design consultancy’s long-term competitiveness.
