Refine & scale
Iteration & release cadence
A predictable rhythm for pushing configuration changes through without slipping back into project mode. Sprint, month or quarter, pick the pace that fits and stick to it.
Updated May 18, 2026
Refine · 6.2
Why this matters now
Two common patterns after go-live: (1) nothing changes any more (“we’re live, done”) and (2) everything changes ad hoc (every change is a crisis). Both lead to standstill or chaos. A release cadence is the way to avoid both — small changes, predictable, with the same steps.
What do you deliver?
Release calendar
Fixed rhythm (e.g. monthly first Tuesday) with scope and freeze windows.
RFC flow
Request for Change template: request → triage → impact → approval → release.
Test strategy
Acceptance environment + smoke tests per release, with sign-off per service owner.
Communication template
What changes, when, for whom — release notes users understand.
Three change types — three cadences
Small & safe
When needed
Add a field, publish a KB article, change a template. Owner pushes it through, logs in change register.
Medium
Monthly release
Workflow change, classification extension, new report. RFC flow, accept test, communication.
Large / structural
Quarterly release
Activate a new module, add an integration, move AI to the next level. Mini-project, steering-committee decision.
Key questions
- 1Which rhythm fits — sprint (2 weeks), month, or quarter for the "medium" layer? How much change can users absorb?
- 2Who does the triage of incoming change requests? Which criteria (impact × frequency × effort) do you use?
- 3Approval — which change board approves what? Which changes can an admin make alone, which need the sponsor?
- 4Acceptance environment — do you have one? How do you sync production config to test? How long do you test before going to production?
- 5Smoke tests per release — a minimal set of scenarios that always has to pass, regardless of release content.
- 6Roll-back per change — especially for workflow tweaks: can you revert if behaviour goes wrong?
- 7Release notes — who writes them, in which language, at what level of detail? For users: short & in their language. For admins: technical detail.
- 8Freeze moments — no changes during audit week, fiscal close, year-end period? Lock into the calendar.
- 9Backlog — where does the list of open change requests live? Who prioritizes, how often?
- 10Product updates from Gfacility itself — read release notes, check regressions, inform end users. Who owns that rhythm?
Template — RFC fact sheet
| Field | Example value |
|---|---|
| Title | Add "AI assistant" category to IT ticket flow |
| Requester / service owner | Sara Janssen (Service manager) |
| Type | Medium — classification extension |
| Why | 15% of tickets are about Copilot/AI tools, currently "other" |
| Impact | Reporting, AI routing rule, KB tags |
| Risks | Existing "other" tickets need reclassification |
| Roll-back | Deactivate the category — existing tickets retain their value |
| Proposed release | Monthly release November |
| Approval | CAB (service mgr, configurator, PM) — no sponsor needed |
Template — Release calendar
| Month | Release date | Freeze from/to | Scope focus | Communication |
|---|---|---|---|---|
| Oct | Tue 7 Oct 20:00 | Fri 3 Oct — Wed 8 Oct 9:00 | Workflow changes IT | Release notes Fri |
| Nov | Tue 4 Nov 20:00 | Fri 31 Oct — Wed 5 Nov 9:00 | Classification extension | Release notes Fri |
| Dec | — (none) | Entire month | Freeze for year-end close | Announcement end of Nov |
| Jan | Tue 13 Jan 20:00 | Fri 9 Jan — Wed 14 Jan 9:00 | Quarterly release: new dashboard | Release notes + briefing session |
| … | … | … | … | … |