Charger programmes rarely run late because the engineering was hard. They run late because requirements were incomplete when architecture began, and architecture decisions had to be revisited once the gaps surfaced.
The sequence below is ordered so that each stage's inputs are settled before it starts. Compressing it is possible; reordering it is what costs months.
Requirements that actually constrain the design
A requirement set naming a power level and a protocol is a heading. The seven above are the ones that determine what can be built.
- Target markets, because they determine the certification schemes and therefore the protection architecture.
- Supply configuration, single or three phase, and the voltage and earthing arrangements to be supported.
- Connector standard and whether the cable is tethered or socketed.
- Environmental range, mounting and ingress expectations.
- Communications bearers and the regions they must work in.
- Backend and protocol requirements, including which platform it must interoperate with.
- Volume, because it changes the design rather than only the price.
Architecture decides most of the cost
Controller topology, protection strategy, metering approach, connectivity and thermal design are settled here, and each closes off options downstream. Changing any of them later is a redesign rather than an adjustment.
This is the stage worth spending disproportionate time on, and the one most often compressed because it produces no visible hardware.
Prototypes answer questions
Each build should have a defined list of unknowns it exists to resolve: thermal behaviour under continuous load, protection response, connectivity in representative conditions, mechanical fit and serviceability.
A prototype built to demonstrate rather than to interrogate teaches nothing, and the questions it did not ask return during validation when they are more expensive.
Validation, with pre-compliance first
Electrical, thermal, environmental and EMC pre-compliance before formal submission. Discovering an emissions problem at an accredited laboratory converts a filter change into a booking, a failure report, a redesign and a second booking.
Protocol interoperability belongs here too, tested against the platform the product will actually connect to rather than against the specification alone.
Design for manufacture is a design input
Whether a fastener can be reached with a calibrated driver, whether a harness can be routed the same way every time, and whether the unit can be tested without partial disassembly all determine production yield.
These are cheap to change at architecture and expensive at pilot. A design that is elegant and difficult to build costs money every shift for the life of the product.
Design for service, which is usually forgotten
The product will be maintained for years by people who did not design it, at sites nobody visits often. Diagnosability, safe access to serviceable parts, and firmware that can be updated and rolled back are design requirements rather than later additions.
The cost of omitting them does not appear in the programme budget. It appears in the service budget, permanently.
Decide the manufacturing intent early
If the product may later be built elsewhere, under licence or by the customer, designing for that transfer is inexpensive at architecture and difficult afterwards. Documentation discipline, test coverage and component choices all differ when transfer is anticipated.
Saying so at the start costs nothing. Discovering it after production has begun means revisiting decisions that are awkward to unwind.