How change requests moved through a device-plus-service program.Eight teams. Named signatures. One audit trail.

The Change Control Board will facilitate change requests at "Some IA Maker" for initial release and changes to production released products.

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

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.

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.

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.