Project change control
It is very rare to define the entire project up front. There might be outside forces that affect the project during it lifetime. Therefore, change is part of the project. It is important to have a process in place that is agreed upon by the client.
Change control is the management of anything that was not in the original scope, requirements, schedule or cost estimates of the project. It involves updating and maintaining the project documents and the resulting changes to quality, risk, cost, schedule etc.
It includes: adding new requirements based on new functionality that is needed. Deleting requirements of features that have been canceled. Schedule changes, fixing errors in the baseline documents.
This can affect the project cost, schedule, requirements documents, risk management, quality management etc.
Submitting a change is done using the ‘Change request’ form. It could be done on paper, digital document or using a software form, that is part of the control management system.
A change request should follow a mini-requirements creating process and go through the stages that were described earlier.
The change request should contain the complete snapshot of the change. It should include the description of the change, the reason for the change, and an explanation of the benefits to be received from the change.
The change request should be sent to the development team for analysis, time and cost estimation and design. It should also be passed to all other stakeholder that might be impacted by this change.
When the process is done, it is very important to update the requirements documents with the changes and notify the teams about the change.
The change-control process
A change-control process lets the project’s leaders make informed business decisions that will provide the greatest customer and business value while controlling the product’s life cycle costs. The process lets you track the status of all proposed changes, and it helps ensure that suggested changes aren’t lost or overlooked. Once you have baselined your requirements, follow this process for all proposed changes to that baseline.
• All requirements changes should follow the process. If a change request is not submitted in accordance with the process, it won’t be considered.
• On design or implementation work shall be performed on unapproved changes.
• Simply requesting a change doesn’t guarantee that it will be made. The project change control board will decide which changes to implement.
• The contents of change database shall be visible to all project stakeholders.
• The original text of a change should not be modified or deleted.
• Impact analysis should be performed for every change.
• Every incorporated requirement change shall be traceable to an approved change request.
There should be a defined team that is responsible to review and approve or decline change requests.
A change request passes through a defined life cycle, having a different status at each stage in its life.
There should be a procedure, known to all, on how to submit a change request.
Once a change request has been submitted, it is evaluated for technical feasibility and alignment with the project’s business requirements and resource constraints.
The appropriate decision makers approve or reject the request change. Once approved, the change request is assigned with a priority level and target date. It is added to the work schedule and assigned to a developer. They approval team notifies the team members who might be involved or needed to modify work products. Affected work products could include the requirements documentation, design description and models, user interface components, code, test documentation, help screens, and user manuals.
Change request form
• Change origin – the person who asked for the change.
• Change request ID
• Change type: defect, enhancement, feature, requirement change.
• Date submitted
• Date updated
• Description – description of the change being requested.
• Priority – the priority in which the change should be implemented. Determined by the change board: low, medium, high, critical.
• Assigned to – the person who is mainly responsible for implementing the change.
• Originator priority – the relative importance of making the change from the originator point of view: low, medium, high, critical.
• Planned release – product release for which an approved change is scheduled.
• Project/product – name of the project in which the change is being requested.
• Feature – name of the feature for which the change is being requested.
• Response – free text of responses made to the change request. Multiple responses could be made overtime (message board).
• Title – the one line summary of the change.
• Status – the current status of the change request.
• Verifier – the name of the person who is responsible for determining whether the change was made correctly (test).