How change requests moved through a device-plus-service program.
Eight teams. Named signatures. One audit trail.
The Change Control Board (CCB) process used on the Internet appliance program. Defines how change requests are submitted, reviewed, signed, and implemented across Development, Test, Support, Network Ops, Supply Chain, Release, Finance, and Marketing.
Key Takeaways
Four things to remember.
Level the change, then route it
Emergency requires immediate attention and a disposition plan. Normal queues into the regular CCB meeting. Running rolls into the next normal change. One request form covers all three.
Signatures have criteria
A Test signature does not mean "we looked at it." It means "the change has been subject to the complete set of tests and the results have been posted to the team." Every team has comparable criteria.
Attachments depend on change type
Device changes: specification, drawing, test plan, test results. Client software: release notes, tar file, test plan, test results. Server: release notes. Documentation: revised drawings.
Release Management closes the loop
Once all approvals are in, Configuration Management communicates the approved ECO to all parties for implementation — and captures the audit trail.
Overview
This CCB process governed every change to the Internet appliance product family — hardware, client software, server software, documentation, and packaging. It is deliberately heavyweight because the blast radius of a bad change (a shipped device in a consumer living room) is heavy.
Adapt it to the weight of your own change: a SaaS web app does not need eight-team signatures on a copy change. But the shape — defined request form, named reviewers, signature criteria, attachment requirements — translates cleanly to every context we have deployed it in.
01
1. Scope
The Change Control Board will facilitate change requests at "Some IA Maker" for initial release and changes to production released products.
02
2. Submit Change Request
Change requests should be submitted through Development or Program Management. A change request must be written and should include, at minimum, the following criteria:
- Definition of the change: What is the change and why is it needed
- Areas impacted (Device HW, Client SW, Server Team, Network Team, Industrial Design, Manufacturing Process)
- Documentation to be updated (Plan of Record document, Engineering Specification(s), UI spec, user guide)
- Level of Change: Emergency (immediate attention + disposition plan), Normal (process normally), Running (roll into next normal change)
- Dependencies (on other pending changes, on pending decisions, on assumptions)
- Estimated dollar impact to the organization, as applicable (savings or cost)
- Requested date of implementation
03
3. CCB Review
Configuration Management shall solicit approvals from required parties. Normal change requests queue for review at regularly scheduled CCB meetings. Urgent requests are immediately hand-carried and/or emailed to appropriate parties for approval.
Required signatories
- Development (Device only, Client only, Device + Client, Server only, Server + Device/Client)
- Test
- Support
- Network Operations
- Supply Chain
- Program Management / Release Management
- Finance
- Marketing
Signature criteria
- Device Team — signature indicates the change has no impact to device functionality, or the impact has been fully tested with no major customer-impact issues.
- Client Team — signature indicates the change has no impact to the software image, or the impact has been fully tested with no major customer-impact issues.
- Server Team — signature indicates the change has no impact to the server environment, or the impact has been fully tested with no major customer-impact issues.
- Test Team — signature indicates the change has been subject to the complete set of tests and the results have been posted to the team.
- Support Team — signature indicates the change has not introduced customer-impact issues, or any issues introduced have a documented customer response on the support database.
- Network Operations — signature indicates the network infrastructure is ready to support the change.
- Supply Chain — signature indicates supply is available and the Bill of Material has been updated.
- Release Management — signature indicates all CCB signatures captured, all required attachments under document control, and the approved ECO will be communicated to all parties.
- Finance — signature indicates financial impacts are understood and acceptable.
- Marketing — signature indicates the change is required.
Attachment requirements
- Device changes — specification, drawing, test plan, test results
- Client software changes — release notes, tar file, test plan, test results
- Server changes — release notes
- Documentation / packaging changes — revised drawings and documentation
04
4. Approved?
Each member of the Change Control Board, as outlined in section 2 and as required above, must give approval for each change request. The approval should include a commit date representing the readiness date for the approver's functional area. Once all approvals are received by Configuration Management, a notice is sent out to all parties. If one or more approvers do not approve a particular change, the initiator is notified and the change is withdrawn.
05
5. Implement Change
All affected parties are responsible for implementing the change as committed to during the approval cycle. The Configuration Manager is responsible for communicating all changes to the appropriate parties, and for collecting related documentation as necessary.
Take it with you
Download the piece you just read.
We keep this library free. All we ask is that you tell us who you are, so we know who to follow up with if we release an updated version. One-time form, this browser remembers you after that.
Related in the library
Pair this with.
Need a QA program to back this up in your organization?
If a checklist is not enough and you want help applying it to a live engagement, we can have a call this week.
Related reading
Articles, talks, guides, and case studies tagged for the same audience.
- Whitepaper
Evaluation Before Shipping: How to Test an AI Application Before It Hits Production
The release-gate playbook for AI features. Covers the five evaluation dimensions, how to build a lean golden set, where LLM-as-judge is trustworthy and where it lies, rollout mechanics with named exit criteria, and the regression suite that keeps a shipped AI feature from quietly rotting in production.
Read → - Whitepaper
Choosing the Right Model (and Knowing When to Switch)
A practical framework for matching LLM model tier to task. Covers the four axes (capability, latency, cost, reliability), cascade routing patterns that cut cost 60 to 80 percent without measurable quality loss, switching costs you did not plan for, and the worked economics at 10K, 100K, and 1M decisions per day.
Read → - Whitepaper
Beyond ISTQB: A Multi-Domain Certification Roadmap for Technical L&D
Most engineering L&D programs over-index on a single certification family, usually ISTQB on the QA side, AWS on the infrastructure side, and under-invest across the rest of the technical domains the org actually needs. This paper covers a multi-domain certification roadmap (QA, AI, cloud, data, security, project management, software engineering) with sequencing logic for each level of the engineering ladder, plus the maintenance discipline that keeps the roadmap relevant as the technology shifts underneath it.
Read → - Guide
The ISTQB Advanced Level path, mapped
The Advanced Level landscape keeps changing — CTAL-TA v4.0 shipped May 2025, CTAL-TM is on v3.0, CTAL-TAE is on v2.0. This guide maps all four core modules, prerequisites, exam formats, sunset dates, and which module a given role should take first. Links directly to the authoritative istqb.org syllabi.
Read → - Whitepaper
Bug Triage: A Cross-Functional Framework for Deciding Which Defects to Fix
Bug triage is the cross-functional decision process that converts raw defect reports into prioritized action. Done well, it optimizes limited engineering capacity against risk; done poorly, it becomes a backlog-management ritual that neither fixes the important defects nor drops the unimportant ones. This whitepaper covers the triage process, the participants, the six action outcomes, the four decision factors, and the governance disciplines that keep triage effective in continuous-delivery environments.
Read → - Whitepaper
Building Quality In: What Engineering Organizations Do from Day One
Testing at the end builds confidence, but the most efficient quality assurance is building the system the right way from day one. This whitepaper covers the upstream disciplines — requirements clarity, lifecycle selection, per-unit programmer practices, and continuous integration — that make system-level testing cheap and fast rather than the only thing holding a release together.
Read →
Where this leads
- Service · Quality engineering
Software Quality & Security
Independent test programs, security testing, and quality engineering for systems where defects cost real money.
Learn more → - Solution
Risk Reduction & Clear Decisions
Quality programs and decision frameworks that shift risk discussions from anecdote to evidence.
Learn more → - Solution
Reliable Software at Scale
Quality engineering programs for organizations whose software is now operationally critical.
Learn more →