A change can affect business results, data or other work steps. Before adoption, Grassroot IT records why it is needed and which components are affected. Users must be able to identify the currently approved version clearly.
Record the context
A change record identifies the reason, old and new versions, actual modifications, test results and approval. Readable source storage helps explain differences. Operational use also requires matching settings and dependencies.
Test the new version using suitable examples. If an input column changes, examine dependent imports, calculations and outputs. Testing and approval must concern exactly the version subsequently distributed.
Connect introduction with a way back
Before introduction, establish how existing use will be replaced and what happens if the change fails. Rollback may also require a matching data version or separate handling of intervening changes. Preserve existing business data.
Microsoft includes change and release management in application lifecycle management. Grassroot IT’s particular procedure depends on the application and organisation. Operations tracks changes alongside incidents.