SmartSuite for the Change and Release Manager

Change. Runs change requests through risk assessment, CAB approval and scheduling with every change recorded against the services it affects.

Release and deployment. Plans releases with scope, test status, deployment windows and rollback steps tracked.

Incident. Links incidents to the changes that caused them for post-implementation review.

Reporting. Reports change volume, success rate and change-related incidents.

What does a Change and Release Manager govern?

The Change and Release Manager governs every change to production: assessing change risk, routing changes for the right level of approval, running the change advisory board and the change schedule, coordinating release planning, testing and deployment windows, and ensuring every change has a plan, a test and a rollback. They report change success rates and the incidents changes cause. In SmartSuite that practice runs in Change Management and Release Management.

How does SmartSuite help a Change and Release Manager run the CAB?

SmartSuite runs each change request through risk assessment, CAB approval and scheduling in Change Management, with every change recorded against the services it affects. The manager sees the change schedule with each item's risk and approval status, so the CAB agenda is the queue itself rather than a list compiled beforehand, and a change to a service with another change already scheduled is visible before it is approved.

How are releases planned with testing and rollback tracked?

Release Management plans each release with its scope, test status, deployment window and rollback steps tracked on the record, so the manager can confirm before the window opens that testing is complete and a rollback exists. Release Management & Planning supports the wider schedule across teams, which is where the DevOps Engineer and Engineering Manager see the windows their work must land in. Nothing goes to production without a plan, a test and a way back.

How are incidents linked back to the changes that caused them?

IT Incident Management links each incident to the change that caused it, which is the input for post-implementation review. The manager can see which changes produced incidents, which types of change or which services fail most often, and bring that evidence to the CAB when setting approval levels. The Incident and Problem Manager works from the same link to see whether a problem traces back to change.

How does the manager report change success to the IT Service Manager?

SmartSuite reports change volume, success rate and change-related incidents from the change and incident records, so the manager's report to the IT Service Manager is a view rather than a monthly compilation. The IT Operations Director sees the same figures for the services they run, and because changes are recorded against services, the report can show which services carry the most change risk and where approval levels may need tightening.

How does SmartSuite fit alongside the team's existing deployment tooling?

SmartSuite is the governance record for change and release, holding the request, the risk assessment, the approval, the window and the rollback plan, while engineering teams keep using their build and deployment tools. New customers can start with SmartSuite Onboarding, a guided four-week program around one or two priority workflows; the first is the change request: load the service list, set risk criteria and approval routes and bring in changes in flight. Change management is an IT general control, so the record also serves the auditors who test it.