Change Control Board :

In project environment a central control mechanism is needed to ensure that every change is properly considered and coordinated. vEmployee has established a Change Control Board which includes the members from design, development and test teams.

The change control process ensures that the impact of each change is evaluated before the decision is made to implement that change. A change is proposed by anyone evaluating the software. A change control board (CCB), made up of the decision-makers, project manager, stakeholder or user representatives and selected team members and evaluates the change. The CCB either accepts or rejects the change.


Work Product :

Input : Issue report in the defect tracking system that describes the change.
Output : Modified issue report that reflects the impact of the change and the decision on whether or not to move forward with it.

Entry Criteria :

A change has been discovered and an issue report that describes it has been entered into the defect tracking system.

Basic Course of Event :

  1. A CCB member (typically a tester) who is familiar with the expected functionality of the software reads and understands the issue report which describes the requested change.
  2. The CCB member familiar with the change meets with the project manager to explain its scope and significance. Together, they identify all project team members who will be impacted by the change and work with them to evaluate its impact. The project manager updates the issue report to reflect the result of that evaluation.
  3. At the next CCB meeting, the project manager presents the scope and significance of the change, along with its expected impact. The CCB discusses the change and performs a cost-benefit analysis to determine if its benefits are worth the cost. The CCB approves the change.
  4. The project manager updates the issue report to indicate that the change has been approved and then updates the project plan to reflect the change. The team members begin implementing the change.

Alternative Paths :

  1. In step 1, if the CCB member does not understand the change, it can be returned to the submitter for further explanation. The submitter may choose to either update the issue report to clarify the change (in which case the script returns to step 1) or drop it entirely (in which case the change control process ends).
  2. In step 3, if the CCB determines that the benefits of the change are not worth the cost, they can reject it. The change control process ends and no changes are made to the project. The project manager updates the issue report to reflect the fact that it was rejected.

Exit Criteria :

The project plan has been updated to reflect the impact of the change and work to implement the change has begun.