Integrated Change Control

Very few projects run exactly to plan. This happens for a number of reasons (one example is scope creep). The bottom line is that you should expect changes to happen! Integrated change control (ICC) is the process of reviewing all change requests, approving changes, and managing changes to deliverables with documentation. It also involves communicating decisions that have been made. ICC consists of many overlapping areas, such as change management, project management, configuration management (CM), and the change control board (CCB). See Figure 1.1 below.

Let’s look at each area:

• Change Management: Within information technology (IT) systems and quality managing systems (QMS) is a strategy and process used to insure that changes to a product or service are introduced in a controlled and contained way. This ensures that any negative effects of a change are minimized. The core of ICC is establishing the CCB, thus documenting the extent of its’ authority. Therefore, change management will impact the decisions made by the CCB and is a key factor to reducing failures and having successful project management.
• Project Management occurs when project managers (PMs) strive to meet the specific scope, time, cost, and quality goals of their baselined projects. In doing so, they use knowledge, skills, tools, and techniques to meet their project requirements. The PM notifies everyone affected by their approved CCB changes in a timely manner.
• Configuration Management (CM) involves identifying and controlling the functional and physical design compositions of the product or service. Common document control software used by CM is Information Technology Infrastructure Library (ITIL), which contains a set of practices on aligning its’ services with the needs of the business. It boils down to figuring what you have, controlling who can make changes, and keeping a record of the changes made.
• Change Control Board (CCB): The CCB consists of a formal group of people (i.e., key stakeholders and subject matter experts/PMs, as needed) who are responsible for reviewing, approving, rejecting, and/or deferring changes within a project. The key functions of a CCB (see Figure 1.2) are to provide guidelines for preparing project change requests (PCRs or CRs), assessment/analyzing CRs, and managing the implementation of approved changes.

Typically in large organizations, CCB meetings are scheduled on a weekly basis (these meetings may be done by conference call). It is the responsibility of the change manager to send out the CRs for discussion prior to the meetings. Each participant has the chance to review proposed changes and gather any relevant information before the scheduled meeting. During a typical CCB meeting, the change proposals are reviewed and a “go” or “no go” decision is made for each proposal. The approved CRs are then prioritized for scheduling purposes because there is usually a limit on available resources and money. Keep in mind that maintaining quality is an important part of this decision making process.

Here are some guidelines to follow when conducting CCB meetings:

• When you have a large number of small changes, it may be more efficient to bundle them together into one CR package, so that everyone’s time is managed more effectively. Keep in mind, some changes can likely be made at zero or near zero cost.
• Trigger automatic approval for CRs that have little or no effect on schedule, cost, or scope with a set threshold (for example, those at a $500 or below cost).
• Have a special process in place to handle emergency CRs (for example, a backup disaster recovery system that stopped working). These are items that need to be addressed immediately. With a process for handling such issues, changes can be put into place before the next scheduled CCB meeting.
• Check to see if there are any relationships between the submitted CRs and ones already being worked on. A lot of different outcomes may happen depending on the scenario, and you want to avoid duplication. For example, combining CRs, rescheduling the work, stopping work on an approved CR, or not approving a submitted CR because of its’ being a duplicate.
• It’s important to discuss the risk/rewards of each CR. Analyze the impact both to the project and to the organization.
• Don’t be hesitant about saying “No” to CRs in order to promote a steadier work environment and ensure that only critical CRs are implemented. Furthermore, if a CR is incomplete or not worth the time to analyze, it should be rejected immediately.
• Change process documentation (for example, CR Submission Forms or CR Tracking Documents) is important because it helps to manage the flow of requests through the process. These forms can be easily generated in Microsoft Word or Excel. In the long run you would be better off using Excel because it would be easier to track changes and display selected data using the Sort and/or Filter features.
• Compile a list of lessons learned after completion and final acceptance of the change. This includes input from the person initiating the CR and the affected customers. This information could be invaluable for future projects.

Configuration Management in Integrated Change Control

A big part of the documentation control process is CM where the flow of product and project documents are controlled in the CM libraries filed by documentation type with version control references. The ICC process utilizes CM for the supporting documentation (for example, functional and physical characteristics of the project’s products) as it moves through the decision process. ITIL is a broad set of references that explain effective ways to handle many aspects of IT support and delivery, including asset and configuration management, change management, release management, and problem management.

Also the CM repository can be used for Incident Management (IM). An incident is an unplanned event that could lead to a loss or a disruption of running a business. A few examples:

• Cybersecurity threats
• Supply chain disruption
• Brand reputation attacks on social medium
• Product quality issues
• Workplace violence
• Terrorist activities
• Data breach
• Natural disasters

Software tools such as ServiceNow and BMC Remedy have been widely adopted and integrated with other systems (especially ITIL) to manage problem resolution. BMC Remedy automates standard ITIL processes out of the box. Extensive configuration options enable you to tailor chosen applications to the needs of your organization. This is based on a response plan that defines what constitutes an incident and delivers step-by step procedures for each defined incident. If you want more information on this topic, visit the Institute of Configuration Management website (www.icmhq.com).

Summary

Successful change management depends on identifying, evaluating, and managing change events in a project and eventually in the end user environment. The ICC process or components are controlled by the CCB or steering committee, and thus supported by a formal workflow process and appropriate communication technology. The key functions of CCB are to provide guidelines for preparing CRs, evaluating them, and managing the implementation of the approved changes.

Another good idea is for the PM to create custom field(s) in Microsoft Project to flag change request tasks, which later can be filtered to only view the tasks with the change request tag. For example, the custom flag field could have the CR number or date of the approved CR. Better still, you could have two custom flag fields – one for CR number and one for date approved. PMs should be involved in managing the project changes by delegating the work and/or being part of the team making the changes. Keep in mind, CRs will more than likely change the original critical path (Note: Microsoft Project will show the critical path using the Filter feature), resulting in a new estimated completion date for the project.

Another key factor in change control is for the PM to use written and oral reports to notify everyone affected by a change in a timely manner. Some major approved changes may mean rewriting the project’s charter and/or scope statement. Remember, good project communication is always a critical key to successful projects.