1. Start with the Most Common Questions from Practitioners
In the previous Configuration Management Series 1, we covered the basic concepts and importance of configuration management.
Many readers shared a common question:
“Now I understand the concept. So what do I actually do in real projects?”
In Series 2, we summarize a practical 5-step configuration management process that can be implemented immediately in engineering teams.
This includes key check points, checklists, and ready-to-use practical templates, all explained in one place.
2. Why Do Organizations Fail in Execution Even with Perfect Documents?
Even when companies possess configuration management documentation, execution often collapses due to the following reasons:
Process procedures exist, but engineering work is not performed according to the defined process.
Only the configuration manager understands the changes, while developers and test engineers are unaware of them.
Documents and real workflows operate independently and never synchronize.
On the other hand, organizations that successfully build configuration management as an internal capability share these traits:
Start small and improve rapidly.
Maintain a structure that can be understood by all engineers after hearing it once.
Keep documents aligned with real project workflows and ensure full traceability, including past history.
3. Practical 5-Step Configuration Management Framework for Real Engineering Work
Step 1 — Create the Configuration Management Plan (A Plan is More Than Documentation)
The configuration management plan is defined as a mandatory requirement in ISO 26262 Part 8.
However, writing the document alone is not planning. The real purpose of planning is team-level agreement on how configuration work will actually operate inside the project.
Core Elements of the Plan
Scope Definition
Clearly classify:
Which projects apply configuration management
Which work products must be managed
Which artifacts are excluded from control
Configuration Management Organization & Role Structure
Define organizational boundaries, responsibilities, and authority for configuration activities.
Naming & Version Identification Rules
A practical and widely-used engineering pattern:
[ProjectCode][ArtifactType][ModuleName]v[Version][Date].Extension
Example:
CM01_SRS_BrakeModule_v1.0_20251127.xlsx
- Baseline Definition
Specify baseline points through formal review and approval flows, marking a confirmed version as the reference baseline. - Tools, Schedule, Status, and Change History Management Policies
Ensure tools are defined and compatible with project needs
Set policies for scheduling, history logging, version status, and archiving
Checklist for Step 1
Has the artifact scope been shared with all project members?
Are all teams applying the same naming & identification rules?
Have document storage location, baselines, and approval rules been agreed upon?
Step 2 — Identify What to Manage
All major work products and engineering decision evidence created throughout the safety lifecycle must be configuration-managed.
Example Artifacts to Control
Requirements specifications
Design descriptions
Test cases and results
Safety plan & safety case
Decision meeting records
Manuals & guidelines
Release versions
Change history logs
Checklist for Step 2
Are there missing artifacts?
Is ownership assigned for each work product update responsibility?
Are versions kept up-to-date regularly?
Step 3 — Control Change Flow
Change itself is natural. But uncontrolled change becomes safety risk, failure risk, and certification risk.
Typical Uncontrolled Change Failure Cases
A developer modifies code, but the team is unaware, leading to system failure after release.
Test teams repeat outdated test cases because they never received the update.
A failure occurs after release, but root cause analysis is impossible due to lack of history tracking.
Safety Impact Analysis (Mandatory for Every Change)
Does the failure mode change?
Is the safety goal impacted?
Are safety mechanisms affected?
Are additional safety measures required?
Ready-to-Copy Change Request Template
| Item | Description |
|---|---|
| Change ID | CR-YYYY-001 |
| Change Target | documents / design / code / system |
| Reason for Change | background & issue description |
| Change Description | detailed modification |
| Impact Analysis | safety impact & risk impact |
| Priority | Critical / High / Medium / Low |
| Owner | execution responsible |
| Schedule | implementation closure |
| Status | Draft / Approved / Archived / etc |
Configuration work repeats the flow: Change Request → Review → Approval → Implementation → Re-verification → History Logging.
Step 4 — Build Traceability as a Core Capability
Audit and certification assessments always include the question:
“How was this requirement designed, implemented in code, and validated in test?”
Poor Responses When Traceability is Missing
“It should exist somewhere…”
“I think we tested it…”
“Let me check again…”
Result: audit failure or assessment failure.
Strong Benchmark Response When Traceability Exists
REQ-001 was designed in DES-005 → implemented in MOD-010 → validated in TC-025/026.
(And traceability matrix is presented immediately.)
The ability to retrieve and explain evidence instantly proves configuration success.
Step 5 — Audit as a Maturity Gate
Configuration maturity splits at audit execution:
Does the system satisfy safety requirements?
Is audit frequency defined?
Is audit ownership assigned?
Is failure verification performed per module?
4. Three Core Operating Principles for Success
Execution fails if attempting perfection too early.
Configuration fails if owned by only one person.
Documents must update when reality updates.
Following these principles automatically prepares teams for version history control → traceability → ISO audit readiness.
5. Why Organizations Trust Configuration Management from Hermes Solution
Expertise from Hermes Solution comes from over 10+ years and 100+ successful ISO consulting and project experiences across multiple industries.
Industry-specific configuration strategies for:
Automotive (ISO 26262)
Aviation
Semiconductor
Industrial embedded systems
What Makes This Approach Different
Templates that can be applied instantly by practitioners
CCB process and configuration culture design included
Document-driven trigger architecture
Execution and documentation remain synchronized
Supports baseline and change control flow design for real engineering teams
Hermes Solution does not build document-only configuration.
It builds configuration where the document becomes the engineering trigger.
6. Conclusion — Real Configuration Feels Different for Practitioners
The 5-step method introduced here is not a theoretical document guide.
It is an execution-driven engineering reality guide.
Change immediately triggers request → safety impact analysis → agreement → implementation → verification → history.
Traceability originates from document architecture design.
Audits evaluate execution more than documentation review.
Success can be defined as:
Configuration that anyone can understand, apply, and trace back through history.
7. Ready to Start?
Build configuration with a trigger-driven process structure together with Hermes Solution—not as separate document work and separate project execution work.
The next post will return with a document management process guide, following configuration management.
