The workflow chart on the following page describes a recommended Change Control Procedure. There are eleven steps to be followed which are described on the following pages.
Figure 3: The Change Control Procedure
Change Requests need to be identified before they can be subsumed under Configuration Management. In most ICT environments, they will result from such situations as:
In all the above cases, the person issuing the Change Request should define the data needed to post the request. This is grouped under the following headings:
1. Enter the particulars of the request: source, date, code, etc
2. Classify the request according to its nature:
The source of the request should identify the type of change that is being requested. (Note that this is more specific than the sources of Change Requests defined above).
The following are typical types for Change Requests:
· New item
· Removal of item
· Change of Location
· Change of Responsible
· Change of Parent Item
· Minor Bug
· Major Bug or Error
· Minor enhancement
· Major change in software
· Major Parameter changes
· Upgrade of software (Release, version, etc)
· Software Patch
3. Document and justify the request: the problems it resolves, the opportunities it creates, the policy it follows, etc.
4. Evaluate the impact consequences of change
In most cases, changes to the Configuration do not really impact the overall Information System. Examples: moving a PC from one room to another, uninstalling a spreadsheet, etc.
In other cases, the change being requested can have a major operational, administrative and/or financial impact. Observe the following:
· Acquire new PC
· Upgrade all PCs from Windows 98 to Windows XP
· Develop a new report generator
· Convert Database from one version of Oracle to another
It is critical for the Change Control Body to have such impacts properly analyzed and assessed in order that it may have the proper grounds upon which to base its approval decision.
5. Estimate the time and cost needed to carry out the change
6. Define the party responsible to carry out the change.
Using the selected Configuration Management software, the source of the request must now create a new Request on the system filling it in with all the required data.
On the following page, a typical Change Request is shown. It need not be the one used in the Ministry or Agency but it can be the basis for the design of a new form. The form is also available on OMSAR’s website for ICT Standards and Guidelines at www.omsar.gov.lb/ICTSG/CM.
Note: This form is assumed to work with a Configuration Management software system so all the subsequent changes, actual work done, actual date completed, etc, are not included. Should such a system not be available, the form would need to be modified to cater for the full cycle of information.
Figure 4: The Change Request Form
The posted request must now be submitted to the Change Control Body. This can be in either of the following forms:
The Change Control Body now studies the Change Request form and based on the submitted documentation. It may come out with the following responses which are shown on the diagram as Steps 3 to 7:
Each of these steps is clarified in the following sections.
The Change Request will need to be submitted with all required technical information. However, the CCB may decide to have further review on some technical issues.
It routes the Request to this step and after the results of the Technical Review are completed by the concerned parties, the Change Request is rerouted to Step 2 above.
The Change Request will need to be submitted with all required information. However, the CCB may decide to have further review on some other issues such as different options, additional costing analysis, impacts, etc.
It routes the Request to this step and after the additional analysis is completed by the concerned parties, the Change Request is rerouted to Step 2, above.
The CCB will issue an approval for the Request and route it to Step 6 where the action will be completed.
At this stage, a Change Order form should be filled by the party approving the request. This would be routed to the party that would actually carry out the change as per the next step.
The Change Order form will not be described in this SOP as it varies depending on the type of item being changed.
Now that the request has been approved, the related party will complete the change as requested in the Change Order form.
As per Quality Management principles, since clearly documented changes would have been stated, it should be possible to verify that such changes have actually been carried out.
Step 6 and Step 7 are a cycle. The Change Control mechanism expects the Change to be properly completed. If not, the cycle reverts back to Step 5 and so on.
On completion of Step 7, the Configuration Data records need to be updated.
Updating includes such information as relevant dates, costs, work done, etc. This will be of use should similar changes be required in the future.
This step is also reached when a Request is rejected (See Step 10) to document the rejection and its reasons.
On completing the change and updating the database records, the Change Request status should be changed to “Closed”.
The CCB may select to reject the Request for a variety of reasons. It will inform the source of the request and proceed to Step 8 to update the database by entering such data as reason for rejection, date of rejection, etc.
The CCB may also select to suspend the Request. This may happen in situations when it has no clear path to take. The request may be too early or too costly, etc. However, it is not to be rejected.
This is a step that also leads to Step 8 where the database will be updated by changing the status of the Request to “Suspended”, entering the reasons for such suspension. The source of the request is then informed of the decision.