The problem: informal change in formal organizations
Weak change management happens when requirements, scope, config, or process shift without records. Verbal OK from a stakeholder, immediate implementation, then "why did we ship this?" in audit or retro.
Regulated or enterprise contexts add legal and compliance cost. Small agile teams still pay in rework and trust. "Agile means no CR" is a myth—agile wants lightweight CRs, not zero trace.
Symptoms and costs
| Symptom | Cost |
|---|---|
| Scope creep without CR | Budget and time |
| Emergency change without post-review | Repeat incidents |
| Unclear approver | Delay or bypass |
| Config drift | Incidents |
| "I don't remember deciding" | Disputes |
| BPMN diagram with no instances | Theater |
Weak change creates unpredictable delivery—teams cannot tell authorized work from noise. Unauthorized work erodes sprint commitment.
Framework: Request → Assess → Approve → Record
1. Request — structured intake
Change requests include:
- Description and impact
- Requester
- Urgency class
- Business reason
Use forms or task templates—not Slack DMs. Incomplete CRs return to requester.
2. Assess — impact before work
PM or tech lead:
- Scope, time, risk estimate
- Dependency check
- Goal link—is this misaligned?
Skipping assessment guarantees mid-sprint surprises. simulate_scenario helps for medium-plus impact.
3. Approve — gated ownership
Approval workflow:
- Standard vs emergency path
- Approver roles defined
- Response SLA
Chronic emergency without post-approval is an anti-pattern.
4. Record — decision log
Decision log entry:
- What changed, why, who approved, when
- Link implementation tasks
Audit and onboarding feed from records. search_decisions answers "why config X" invaluable later.
BPMN for repeatable change
For recurring changes (release, access, infra):
- BPMN models with roles and handoffs
- Process instance tracking
- Integration with the task board
BPMN is overkill for one-offs—strong for regulated paths.
Where WKFGo helps
WKFGo offers BPMN/process, task approvals, decision log (MCP record_decision, search_decisions), and form intake. It is not full ITIL—traceability for real software and project change.
Decision inbox fits escalated changes in executive rhythm.
Workflow: form CR → assess task → approver notify → record_decision → implementation task → post-implementation review at thirty days.
Standard vs emergency change paths
| Standard | Emergency | |
|---|---|---|
| Intake | Form | Verbal plus urgent ticket |
| Assess | Before work | Parallel minimal |
| Approve | 24–48h SLA | Verbal plus retroactive |
| Record | Before deploy | Within 48h post |
Emergency without post-record is a culture problem. Track emergency frequency—chronic use signals process gaps.
When BPMN earns its keep
Production release, privileged access, contract amendments—repeatable and auditable. Small feature experiments need lightweight CRs only.
Lightweight change advisory board
For orgs above fifty people: weekly thirty-minute change review—only standard CRs with medium-plus impact. Emergencies in a separate digest. Goal is visibility, not committee paralysis.
Searchable decision logs stay audit-ready without scramble.
Minimum CR template fields
Description, business reason, impact (time/cost/risk), rollback plan, approver, implementation task link. Incomplete CRs return to requester—not verbal clarify loops.
Post-implementation review
Thirty days after medium-plus changes: outcome vs forecast—update decision log. Calibrates change process—not blame. "Predicted plus two sprints, actual plus three" improves assess skill.
Common scenario: "just a small change"
Stakeholder in hallway: "Add one field." Dev implements—no CR. Next sprint: "That was not in scope." Rework plus dispute. Audit: no record.
Fix: mandatory CR form for user-facing work; emergency path with forty-eight-hour post-record; sponsor rejects unauthorized work.
Change notification for stakeholders
When a CR is approved, notify Tier 1 stakeholders via digest—not every comment ping. Link the implementation task and expected deploy date from the release module. Transparency reduces "why did this ship?" disputes even when the change was correct.
Recovering from unauthorized change
Retroactively decision-log unauthorized changes—acknowledge the pattern. Sponsor message: unauthorized work does not merge without CR. Culture shift needs leadership backing.
Anti-patterns
- "We are agile so no CR"
- Approver = everyone
- BPMN diagrams with no instances
- Logs only when auditors arrive
- Emergency path as default
Getting started this week
Publish CR form plus named approver. Decision-log one recent unauthorized change retroactively—break the pattern. BPMN only if the path repeats.
Frequently Asked Questions
Is change management anti-agile?
No—lightweight CRs add transparency, not waterfall committees.
Emergency change?
Fast path plus mandatory post-review within forty-eight hours—track patterns.
BPMN vs Kanban?
Complementary—BPMN for repeatable change; Kanban for daily delivery.
Tool vs culture?
Sponsors must reject unauthorized work—tools alone are insufficient.
Summary
Change management should be light but traceable: request, assess, approve, record. BPMN for repeatable paths; CRs for the rest. Unauthorized change is cultural—post-implementation reviews calibrate the process.
Start now
Trace one recent unauthorized change. Ship a CR template and approver role—enforce next sprint.