A technical change management plan is the governance document that defines the process by which changes to a system’s configuration, code, or infrastructure are requested, assessed for impact, approved, tested, scheduled, and deployed to production — and reversed if they cause problems. It is distinct from organisational change management (the programme of activities to help people adopt a new system). The technical change management plan is about controlling what changes go into the system, when, and with what validation — ensuring that production stability is not compromised by uncontrolled modifications. In ERP and EPM environments where the production system runs live financial close cycles, an uncontrolled configuration change deployed to production on the last day of a close period is not an inconvenience; it is a close-cycle risk.
Plan Structure and Content
A technical change management plan defines:
- Change categories: Standard changes (routine, pre-approved, low-risk — e.g. adding a new user, updating a report distribution list), normal changes (requiring assessment and approval), and emergency changes (requiring expedited approval for critical production issues)
- Change request process: How a change is initiated, what information must be provided (description, business justification, systems affected, rollback procedure, testing evidence), and who can submit requests
- Impact assessment: The technical review of a change request — what systems will be affected, what interdependencies exist, what the risk of unintended consequences is, and what testing is required before production deployment
- Approval authority: Who approves changes at each risk level — technical lead, programme manager, business sponsor, IT security — with escalation paths for changes that exceed a reviewer’s authority
- Promotion and deployment process: How approved changes are moved from the development environment through testing to production, with the evidence required at each stage
- Post-deployment verification: The verification steps performed after a change is deployed to production — confirming the change achieved its intent without unintended side effects
- Change freeze periods: Defined periods (close windows, statutory reporting periods) during which no non-emergency changes may be deployed to production
Common Gaps and Failure Modes
The failure that most reliably produces production incidents during live close cycles is the absence of a defined change freeze period. A change freeze period explicitly prohibits non-emergency changes to the production environment during the monthly close window — typically the five business days around period end. Without a formally defined and communicated freeze, a developer who identifies a configuration improvement makes the change in production during the close because “it was a small fix.” The small fix interacts with the close-period data in an unexpected way, the consolidation run fails, and the close team spends four hours diagnosing a change they were not informed about. A change freeze period, enforced through the change management process, makes this scenario impossible by policy.
How Loop Wise Solutions Produces This
Loop Wise Solutions documents the technical change management plan as part of the implementation governance framework, established in the programme initiation phase — before any configuration changes are made to any environment. The plan is reviewed and approved by the client’s IT governance function before configuration build begins. We specifically include change freeze period definitions aligned to the finance close calendar, because EPM and ERP systems are most vulnerable to change-induced incidents precisely during the periods when their outputs are most critical.
