The most important part of change control
is a change control board (CCB). There are certain people in the
organization who have the power to change the scope of the project.
Usually there is a senior manager or decision-maker who has the
authority to make sweeping changes at will; sometimes there are several
people in this position. For change control to be effective, these
people must be part of the CCB.
In addition, the CCB should contain people from the project team:
-
The project manager
-
An important stakeholder or user (or someone who understands and advocates their perspective)
-
Someone who understands the effort involved in making the change (usually, this is a representative from the programming team)
-
Someone who understands the
engineering decisions that the team makes over the course of the
project (a design team member, requirements analyst or, if neither is
available, a programmer who participated in the design of the software)
-
Someone who is familiar with the
expected functionality of the software and with the behavior being
discussed for each individual change (typically a tester)
This last person fulfills a very
important role in the change control process. Typically, she is
involved in the tracking of changes and defects in the product. When a
bug is reported, part of her job is to figure out whether it is a
defect (meaning that the software does not behave the way its
specification requires it to behave) or a change (meaning that the
software behaves as designed, but that this behavior is not what the
users or stakeholders need).
Change Control Process
The following script describes an effective change control process:
Name
| Change Control Process Script
|
| Purpose | To control changes by evaluating their impact before agreeing to implement them. |
| Summary | 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,
evaluates the change. The CCB either accepts or rejects the change. |
Work Products
| 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 Events
|
- 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.
- 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.
- 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.
- 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
|
- 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).
- 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.
|
