Where in the process of Change/Release/Deployment Management is an interface to Configuration Management and what exactly is the content of information required?
a) first of all in the Request for Change, who is required to initiate and document any change. There it has to be specified which components / relations are to be changed. It is beneficiary to select the affected components from a predefined fixed CI-list rather than enter the components name as free text.
b) when you run an Impact Analysis, cost, benefit and risk have to be analyzed. To do so you need to know what other components are impacted. And this not only on the technical (physical) side but preferably also up to the logical components (service / business process). Only with accurate information on the whole Configuration Tree its possible to run a sensible impact analysis. Otherwise you have to rely on not explicitly documented knowledge inside your IT specialists heads. Incorrect or outdated configuration information might lead to wrong decisions.
c) if you start to Plan the Implementation of the change(s) you have to be sure, that no interfering other change(s) are executed at the same time on the same affected components. Or, if so, you need to consolidate all this changes into one release and make sure that the dependencies are considered. To do so you have to run a forward schedule of change. If you have specified the component to be changed as free text, or you have inadequate configuration information you might face a challenge to find all relevant dependencies and you have to be prepared for bad surprises.
d) when Deploying the Change you first have to check if the base configuration on the target platform corresponds to the configuration you started developing the change on. That is why it is requested to verify the configuration on the target platform shortly before deploying the change. If you find differences its far better to not deploy the change than to encounter an error and then run a timely (and sometimes challenging) rollback.
e) and finally, before the request for change can be closed, a Post Implementation Review has to be executed. That includes a check to make sure that the now active configuration is exact the one we intended to implement with the change. Only if no differences (or explainable differences) are found and on the business side the requester/customer confirms that the change met his/her expectations the request for change can be closed.
Tags: Change Mangement, Impact Analysis, PIR, Request for Change