Seema Sonkiya: Change Management Important Notes

This article is based on PMBOK 4 and ITIL V3. My article is detail interpretation of PMBOK 4 and some incorporation from ITIL v3 standard.

Objective of change management is to respond changing environment, plan, and business requirements.  It is an effective response to a business and IT requests to align product, service and result with business needs.

Changes should be managed with standard process, which may be tailored to the specific need of the project. A centralized system for the project should be present to record all changes.

Change management ensures that changes introduced in controlled manner. Every change request must be made formal.  Every change request that is made verbally, directly, indirectly, externally, internally; it must be recorded in RFC document. All changes are recorded.

Change management plan defines how integrated change control process will work whenever a change request come. This change management plan should be formally developed for each project and approved. It’s project manager responsibility to get buy-in from all especially from key stakeholders for the approved change management plan and  in case if project is initiated due to external customer request then customer should be educated about the integrated change control process

Change management is closely related with configuration management. Configuration management record and report the list of all configuration items. CI is basically defined as any asset and component of service, product or result which is under control of configuration management system. Configuration management system also records relationship of CI with other CI (A change can affect multiple CI). According to ITIL V3, configuration management stores relationships between CIs, and also relationship with incidents, problems and change records. All CIs are subject to change management control.

 What is a change: It is addition, modification or removal of any service, product, or result or addition, modification or removal of configuration item.

In PMI terms change is defined any addition, modification, or removal in the baselines, project documents especially project charter, contract, policies, procedures, SOW, and it may also change in environment which does not make changes in above documents.

ITIL defines three categories of changes:

1.                            Normal Change: Generally managed by CAB (CCB in PMI), PMI says that project managers has authority to approve some minor changes without CAB/CCB meetings as per the authority defined in change management plan.

2.                            Standard Changes: Pre authorized with an established procedure, task are well known, documented and usually have low risk like upgrade PC.

3.                            Emergency Change: When there is insufficient time for normal handling. In these types of changes we should use normal process but we need to speed up because impact can be high, more prone to failure, and our focus is to kept them minimum. E-CAB members selected as per need of the change.

I observed sources of changes:

1.                            Agile methodology says that it is difficult to predict in advance which requirement will change and which will persist. When design and construction are interleaved so that models are proved as they are created. It is difficult to predict how much design is necessary before construction to prove the design. Analysis, design, construction and testing are not as predictable as we might like. So to manage these unpredictable environment works is performed with small duration releases. So rapid changes in environment is primary driver in agility. Agile methodology is adaptable to rapidly changing project and technical conditions. As per PMI phase to phase relationship is iterative in undefined, unpredictable environment and scope is managed with frequent small increments.

2.                            In ITIL other processes like Incident management problem management trigger changes.

3.                            As per PMI executing and monitoring & controlling processes trigger change request. It includes defect repair, corrective or preventive actions and changes to baselines, project documents. Example like change request identified when we meet up with customer to gain acceptance of completed interim deliverables, measuring performance against baselines, when we are doing project audit to make sure that we are using correct processes and identify improvements in policies, procedures and processes. When creating performance reports, when working with project team and discover that project team member is not performing, when we notice that there are many unidentified risk occurring, when we identified that seller performance is not meeting expectations, when we are doing quality control of completed deliverables, when we are communicating with stakeholders to resolve issues and manage their perceptions about the project. All are example of either executing or monitoring & controlling processes.

Care should be taken by the project manager that changes should not come due to poor planning, approach should be proactive. Example of poor planning can include lack of stakeholder engagement, rolling wave planning used as an excuse and scope is not defined clearly, lack of risk management efforts, lack of stakeholder buy-in, gold platting, estimates are padded and reserves had not established, lack of clear role and responsibilities  etc. In other words if we do not have realistic project management plan and we have not defined complete product or project scope either for whole project   or for current release in case of iterative phase to phase relationship then large number of changes will come, that’s why project manager must analyze sources of change request.

Integrated change control process is integrative process because a change request can impact all other knowledge areas and impacts are analyzed for all aspect of project like scope, cost, schedule, quality, risk, human resource, communication and procurement.

In addition to control changes we need to have process to control changes, define roles and responsibilities for CAB/CCB members including project manager/change manager and we should have templates to request changes. In ITIL incident, problem and change record are referenced each other.

 Steps to process a change request:

1.                            Assess the change: When change request created it should be evaluated, if we have already a reserve for a change then this is managed by a risk management as it is already identified risk and has occurred.  We should have contingency plan for most of problems to create hassle free environment. We need to evaluate complete impacts and we need to see effect on other project constraints like scope change need to be evaluated for impact on schedule, cost, quality, resources, risk, communication, procurement etc. It may be needed to use suppliers if change request approved. ITIL recommended analysis of 7 R’s of change like:

                                                               i.      Who RAISED the change?

                                                             ii.      What is the REASON for the change?

                                                            iii.      What is the RETURN required from the change?

                                                           iv.      What are RISKS involved in the change?

                                                            v.      What RESOURCES are required to deliver the changes?

                                                           vi.      Who is RESPONSIBLE for the build, test and implementation of change?

                                                         vii.      What is the RELATIONSHIP between this change and other change?

If we are working for a customer then my recommendation is to provide impact analysis to customer first because if impacts are high then it may be possible that customer will reject the changes, considerably time will be saved before looking options. Customer may be involved in impact analysis. We provide customer list of effected CIs.

2.                            Create options:  Basic objective is to balance the competitive constraints. It may include compressing the schedule, adding resource to project, adjust quality, add scope etc. If change is logical and correspond to new scope added to the project by the customer then project should get extension in normal circumstances.

3.                            Get the Change request approved internally first then get customer buy-in.

4.                            Adjust the project management plan, project documents baselines.

5.                            Manage stakeholder’s expectations by communicating the change to stakeholders effected by change

6.                            Manage the project to the revised project management plan and project documents.

Project Manager make sure that process is followed, either he/she coordinate or authorize change manager (if change manager appointed for project) to facilitate CAB/CCB meetings; make sure necessary information is available to evaluate change. Key challenges of effective change management may include pressures of “just do it”, inaccurate and incomplete configuration management system, misunderstanding of emergency changes, vendor/contact compliance and adhoc nature of people.

Seema Sonkiya