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 |
| … | … | … | … | … |