I treat change management as a controlled way to effect or deny a requested change of a work product. First, I set a clear goal for the change process. Next, I define roles and responsibilities. For example, I assign a Change Control Board (CCB) role. Furthermore, I include the project manager, user representatives, IT staff, and a requirements manager on the board. In addition, I accept change requests from departments, from Problem Management, and from users.
I keep the process simple. Therefore, I define input criteria for change requests. Then, I check each request against those criteria. Also, I classify requests. For instance, I decide whether a change is corrective, adaptive, or exceptional. Moreover, I involve the requirements manager to find the cause. Because of that, I reduce confusion later.
I perform an impact analysis for every viable request. First, I estimate effects on requirements. Then, I trace effects to architecture, source code, tests, and training materials. In addition, I use traceability information to find all affected artifacts. As a result, I can estimate effort and risk. Consequently, the CCB can decide to accept, reject, or postpone the change.
I ask experts for facts before the CCB meeting. For example, I request a cost estimate, usability assessment, and security impact. Also, I request the importance of the change. Thus, I provide the CCB with clear input. Meanwhile, I keep stakeholders informed.
I define unique statuses and status transitions. First, I define a “new” status. Next, I add “under review,” “analyzed,” “approved,” “rejected,” and “implemented.” Then, I map transitions between these states. Furthermore, I record each decision and reason. In addition, I set output criteria for the process. For example, I require an approved implementation request and a documented impact analysis.
I keep the process lean. Therefore, I avoid unnecessary steps. Also, I make escalation paths clear. For instance, I let the CCB decide routine changes. Meanwhile, I reserve higher governance for high-risk changes. Because company processes differ, I adjust the process to fit the organization. However, I keep basic activities consistent across projects.
I hand accepted changes to Release and Deployment Management. Then, the implementation team executes the change in an existing project or in a new project. After implementation, I verify that requirements artifacts return to a consistent state. In addition, I update version baselines. Finally, I confirm traceability after the change.
I report changes regularly. First, I log all change requests. Then, I create status reports that show trends. Also, I highlight risks and blocked requests. Moreover, I share summaries with stakeholders. As a result, I keep visibility and control.
In short, I run change management to control the lifecycle of changes. I define goals, roles, inputs, statuses, and outputs; I use traceability to assess impact; I involve the CCB for decisions; and I keep the process lean and aligned with company practice. Consequently, I enable beneficial changes with minimal disruption.