Change Management Models
Every business addresses changes differently according to their needs and process maturity, and HelpMaster supports a flexible change-management system to accommodate many styles of managing change.
Icons used throughout HelpMaster
Request for Change
Pre-approved change request
Approval Required. Approval is determined via a voting system
Job Template
Job - Used for tracking and managing the implementation
Workflow step - Used within jobs for discreet steps within a process
Finalizing the change / job
What comes first, the Change Request, or the Job?
Potentially both, and perhaps neither!
It depends on the type of change, and the circumstances under which the request for change is raised. Each model serves a purpose and a business workflow. They are not mutually exclusive. It is important to note that not every change request needs to have a job logged for it that precedes the change, and similarly, not every existing job needs to transition into a change request.
Request for change first
A change-first model occurs when a request for change is created first, which then leads to logging a subsequent job in order to carry out the implementation. In order for the implementation job to be logged, the RFC must first be defined, logged, and either pre-approved, or approved via a voting system.
A “change request first” approach may occur due to one or more of the following:
- The change is a scheduled, regular change
- The change is expected
- The change is a planned change
Job First
A job-first model occurs when a request for change stems from an existing job.
This may be because a support case transitions into a change request out of necessity. This is a common progression. In ITIL terminology, this could be described by the following cycle:
Incident > Problem > Change Request > Fix and close problem > Close incident > Close Change
In this case, the incident record is logged first, then a corresponding problem record which necessitates a change.
Other times, a more complex change request may be best described and implemented as a more complex job that has a series of associated workflow steps and multiple change requests/approvals. Such a complex change might only be served best by logging an initial job that contains the sequence of changes and approvals via discrete steps within its associated workflow.
Common Change Request Models
Below are some ideas that may be useful in working with Change Management in HelpMaster.
Request for change with approval. Simple change.
Starts with an RFC which has to be approved. Once approved, the change is implemented and the RFC is closed. In this simple model, no job is used for the implementation as the type of change is simple enough to not warrant logging a separate job for tracking and managing implementation. All details of the change are documented in the RFC and this is sufficient for this type of change.
Request for change with approval leading to template-based job implementation
Starts with a RFC which has to be approved. Once approved, a pre-made job template is used to log a job that will be used to track and manage the implementation process. This type of change is usually a well-known type of change, because a job template has already been made for it. This indicates that there is a standard workflow/implementation to the change.
Pre-approved change with a job for implementation
Standard, or well-known changes may not require a formal approval process. This type of change is pre-approved, however the RFC is logged for the sake of reporting. A separate job is also logged for tracking and managing the implementation
Job-first, Multi-stage approval with workflow. Complex Change
This scenario is more complex. It starts with an existing job that has either been logged to initiate a change process, or perhaps it was logged as a regular support case (incident/problem etc.) which then requires a change. Either way, as part of the workflow, there are multiple change request items built into the workflow. Each change request could be used as a unique change, or perhaps for an approval process.
Job First, request for change with approval process
A variation on the first model, only that a job pre-dates the change. No further job is required for implementation. The implementation of the change is either documented in the change record, or in the initiating job.
Job First, pre-approved change
Similar again. A pre-existing job initiates a pre-approved request for change. No further job is required for implementation. The implementation of the change is either documented in the change record, or in the initiating job.
Your changes, your way
Ultimately, any change request within HelpMaster can be defined, classified, implemented and closed in any way that makes sense to the business and the requirements of the change itself. There are no set rules on how change requests could, or should be implemented. Use any combination of the Change Request templates, Jobs and Job Templates, and Workflow to build change management processes that work for you.
See Also
Feedback
Was this page helpful?
Glad to hear it! Please tell us how we can improve.
Sorry to hear that. Please tell us how we can improve.