The 30-second answer
An EV charger engineering change request should make eight things unambiguous: request identity, current baseline, proposed delta, reason, affected items, impact review, verification plan, and disposition.
If one of those inputs is missing, the team may understand the idea but still be unable to review the change. A buyer might approve a description that engineering interprets one way, purchasing prices another way, and quality verifies against a third configuration.
Use the request to answer a narrower question before implementation begins:
Is the proposed change defined well enough for the right functions to evaluate its effects and decide the next controlled action?
That decision is not the same as certification approval, regulatory acceptance, customer authorization or mass-production release. Those decisions stay with their own evidence and authorized reviewers.
Why a change message is not a change request
“Use a longer cable,” “change the connector,” or “update the label” describes an intention. It does not identify the released configuration being changed, the exact new state, the records that move with it, or the evidence needed to close the change.
Configuration management provides a useful general discipline here. ISO 10007:2017 applies configuration-management guidance across product and service life cycles. NASA configuration-management guidance separates configuration identification, change control, status accounting and verification or audit. These are general process references, not EVSE certification rules.
For an OEM project, the practical implication is simple: the request should connect the proposed delta to a known baseline and keep the decision traceable through implementation.
The eight-input ECR completeness matrix
| Input | What the request should show | Review question | Weak signal |
|---|---|---|---|
| 1. Request identity | Unique ECR ID, requester, date and project/configuration scope | Can every discussion point to one record? | Change described only in email or chat |
| 2. Current baseline | Current drawing, BOM, firmware, label, sample or approved record revision | What exactly is being changed? | “Current version” without an identifier |
| 3. Proposed delta | Before/after statement for each affected item | Can reviewers see the precise difference? | Desired outcome without a defined delta |
| 4. Reason | Problem, requirement or project objective driving the request | Why is the change being considered now? | Generic “optimization” wording |
| 5. Affected items | Product, document, tooling, packaging, software and process records that may move | What else must remain consistent? | Only the visible part is listed |
| 6. Impact review | Functions that must evaluate technical, quality, supply, schedule or commercial effects | Who must assess the change? | One team decides for every function |
| 7. Verification plan | Evidence, configuration, owner and closure condition for the proposed state | How will implementation be checked? | “Test after change” with no traceability |
| 8. Disposition | Approve for defined next action, return for evidence, defer or reject, with owner and date | What is authorized—and what is not? | Verbal approval without scope |
This matrix is a completeness check, not a universal form. A low-complexity document correction may need a short request. A multi-item electrical, mechanical, firmware or labeling change may require linked analyses and approvals. The record should be proportional to the effect while keeping the same decision path visible.
Step 1 — name the current baseline before describing the new state
Start with the configuration the project recognizes now. Depending on the change, that baseline could include:
- drawing number and revision;
- BOM or approved component list revision;
- firmware or software build identifier;
- label artwork and language revision;
- packaging specification;
- sample ID and revision record;
- inspection, test or work-instruction revision.
Avoid a broad statement such as “change the portable charger cable.” A more reviewable starting point identifies the project, affected assembly and current controlled records. The request can then describe the delta without forcing reviewers to reconstruct the baseline from several inboxes.
If the change begins with a physical sample, use the separate EVSE sample revision record to identify the unit and its gate history. The ECR owns the proposed change package; the sample record owns which physical configuration was reviewed.
Step 2 — write the delta as before, after and unchanged
A useful delta has three parts:
- Before: the current controlled value or arrangement.
- After: the proposed value or arrangement.
- Unchanged: nearby requirements or interfaces that the request does not intend to modify.
The third part prevents scope drift. For example, a packaging-label layout request should not silently become approval to change ratings, certification marks or market claims. A cable-length request should not be interpreted as approval of a conductor, connector, enclosure or firmware change unless those items are explicitly included.
When the exact value is unpublished or commercially sensitive, do not place it in a public article or an unapproved channel. Keep the public ECR structure generic and exchange project-specific controlled documents through the authorized workflow.
Step 3 — map every affected item, not only the visible component
An engineering change often creates a consistency problem before it creates a technical problem. The physical delta may be small while the record set around it is broad.
Use an affected-item scan across six buckets:
- Product configuration: assemblies, parts, interfaces, firmware and accessories.
- Engineering records: drawings, BOMs, specifications and revision histories.
- Verification records: inspection plans, test procedures, reports and acceptance records.
- Manufacturing controls: work instructions, tooling, fixtures and process settings.
- Customer-facing records: labels, manuals, packaging and approved artwork.
- Supply and project records: purchase descriptions, approved sources, inventory disposition and milestone plans.
The request does not need to claim that every bucket changes. It should show that each relevant bucket was considered and identify which records are affected, unaffected or still under review.
Step 4 — route impact review to the right owners
One signature rarely represents every effect. Route the request according to the proposed delta and project boundary.
| Review lens | Typical question | Evidence or decision produced |
|---|---|---|
| Engineering | Does the delta remain internally consistent with the defined interfaces? | Updated technical records or reasoned no-change statement |
| Quality | Which inspection or verification records must change? | Revised evidence plan and traceability path |
| Procurement/supply | Does the delta change sourcing, inventory or supplier-controlled items? | Supply-impact statement and ownership |
| Manufacturing | Do tooling, instructions or process controls move? | Implementation scope and effective point |
| Project/commercial | Does the change affect an agreed milestone or quotation boundary? | Authorized project disposition or escalation |
| Compliance/customer authority | Does the delta touch regulated claims, approvals or customer-controlled content? | Separate authorized review; never implied by the ECR alone |
The last row is a hard boundary. Standing editorial or routine project authority must not self-approve certification scope, legal applicability, customer permission, price, MOQ, delivery, warranty, capacity, defect-rate or unpublished-specification claims.
Verification evidence should point to the exact proposed configuration and change request.
Step 5 — make the verification plan close the stated delta
“Test after change” is not yet a verification plan. A reviewable plan connects four elements:
- the ECR and proposed configuration identifier;
- the evidence activity or record to be produced;
- the responsible owner;
- the closure condition for the next decision.
The plan should be specific about traceability without inventing thresholds. If a technical threshold, certification method or market requirement is not already approved for the project, it remains outside automatic editorial or workflow approval.
NASA change-tracking guidance recommends retaining the change request, impact analysis, decision records and changed versions, and closing the request only after implementation and associated documentation are verified and approved. The guidance is written for NASA software work, so this article uses it only as a general traceability model.
Step 6 — separate disposition from implementation
A disposition should say what may happen next and what remains outside scope. Useful outcomes include:
- reviewable—advance to defined evaluation;
- return—add missing baseline, impact or evidence information;
- defer—hold until a dependency or authorized decision is available;
- reject—do not proceed under the current request.
If a change is approved, record the implementation owner, effective configuration or lot boundary where applicable, affected-document updates, and closure evidence. Do not let “approved” mean both “evaluate this change” and “release it everywhere.” Those are different gates.
Implementation should begin only after the approved change, affected records and release boundary agree.
A neutral worked example
Assume a buyer asks to reposition a cable label for a project configuration. A weak request says: “Move the label closer to the connector.”
A reviewable package would instead record:
- one ECR ID and project scope;
- the current assembly and label-artwork revisions;
- the before/after location definition in the controlled project record;
- the reason for the request;
- affected label, drawing, work-instruction, inspection and packaging records;
- which engineering, quality, manufacturing and project owners must review;
- how the revised sample and records will be identified and checked;
- a disposition that authorizes only the defined next action.
The package should explicitly hold any rating, certification-mark, language, customer-artwork or market-claim change for separate authorized review. That boundary turns a seemingly simple instruction into a controlled and auditable decision without pretending the template supplies regulatory judgment.
Five checks before the review meeting
Before inviting a cross-functional decision, ask:
- Can a reviewer identify the exact current baseline without searching another message thread?
- Is the proposed delta stated as before, after and intentionally unchanged?
- Are affected product and document records visible, including “no change” decisions where useful?
- Does the verification plan point back to the ECR and proposed configuration?
- Does the requested disposition state its scope and excluded authorities?
If any answer is no, return the package for completion. A short delay before review is usually easier to control than a broad interpretation after implementation begins.
Where this page fits in the OEM decision path
Use this article when a project already has a proposed change and needs a reviewable decision package.
- Use the OEM sourcing guide to qualify a supplier and its evidence system.
- Use the supplier RFQ checklist to define comparable quotation inputs.
- Use the sample revision record to identify which physical sample and revision reached a gate.
- Use this ECR matrix to define and route one proposed configuration change.
Turn a proposed change into a reviewable package
If you are coordinating a portable EV charger, EVSE or connector OEM project, SUPERGENIE can help structure the current baseline, proposed delta, affected records and evidence handoff for a controlled review.
Discuss a controlled OEM configuration change.
Share only approved project information. Certification, legal, customer, commercial and unpublished-specification decisions remain subject to their authorized review paths.
Frequently asked questions
Is an ECR the same as an approved engineering change?
No. The request defines a proposed change for review. Approval, implementation and closure are separate states and should retain their own evidence.
Should every small correction use the same form?
The level of detail can be proportional to the effect, but the baseline, delta, ownership and disposition should remain identifiable.
Can one ECR cover several affected documents?
Yes, when they belong to one coherent change and the request lists each affected record and revision path. Unrelated changes are easier to evaluate and close separately.
Does an approved ECR prove certification or market compliance?
No. Certification scope, legal applicability and market claims require their own authoritative evidence and reviewers.
When should the ECR be closed?
Close it only after the approved action, affected records and planned verification evidence have been completed and the authorized owner records the final disposition.
