Concepts: Change Request States and Notifications

Topics

• Definition
• Explanation
• Use

Definition

A Change Request (CR) is a general term for a request to change an artifact or process. The general process associated with CRs is described in the process step ‘Establish Change Request Process’. However, the following outline of the CR process describes the states and statuses of CRs through their overall process, and who needs to be notified during the lifecycle of the CR.

Explanation

1. CRs can be SUBMITTED by any stakeholder on the project.
2. CRs are LOGGED into an SCM database.
3. CRs are REVIEWED by a Review Team.
4. Following the review and based on their criticality CRs are either approved for ENGINEERING, REJECTED or put on HOLD.
5. Whilst in ‘engineering’ CRs are used to create a ‘task’. Tasks themselves have the following states:

• New
• Assigned
• Design
• Implement
• Integrate
• System_Test
• Completed
• Canceled
• Pending

1. Once engineering has implemented the CR, the next step is to VERIFY/TEST the change.
2. If the change was considered to be have appropriately done, the product is then RELEASED. Together with the release are notes on what was changed and creating the necessary media for the change to be incorporated into a baseline.
3. The final step in the lifecycle is for it to be CLOSED. This signifies that all appropriate (project adopted) steps were taken in implementing the changes proposed in the original CR.
4. A CR can be REJECTED for a number of reasons. It may be lacking sufficient information or may be invalid give the project development plan. However, improperly implemented changes may also be rejected for re-submission.
5. A CR on HOLD is reviewed each time the Review Team meets to determine whether the appropriate time has been reached to implement the otherwise approved change.

The status ‘tags’ provide the basis for reporting CR (aging, distribution or trend) statistics.

CR States in the context of the CM Cube.

Use

The following example describes who should be notified through the lifecycle of a Change Request (CR) that has been approved for engineering.

The NEW state is the initial state for all new tasks. The Project Manager decides on when to schedule the task. If it is determined that the task should be worked on immediately, several decisions must be made. When a change task is created, the Project Manager determines whether the task will effect software or documentation and create sub-level tasks for each of those applicable changes. The Project Manager may also decide to subdivide the task into separate, smaller units of work and assign them to several implementers, thereby creating children tasks for the change, software, and documentation task. Once the task organization has been determined, the Project Manager will assign tasks to individual implementers and move the task to the Assigned state. In this case, e-mail is sent to the assigned implementer. If the Project Manager determines that the task should be worked on later, the task can be moved to the Pending state. If the Project Manager determines that the task should be canceled, the task can be moved to the Canceled state. In this case, e-mail is sent to the originator of the change and the Project Manager.

The ASSIGNED state indicates that a task has been assigned to a implementer, and the implementer should receive e-mail indicating the assignment of the task. Also, the implementer can query against the set of tasks to determine which tasks are assigned to him. The implementer can then place those tasks on his own personal to-do list. The implementer is then responsible for working on the task. The implementer can move the task to the Design state or, if no design is required, move it to the Implement state. If the task is moved to the Design or Implement state, e-mail is sent to the Project Manager indicating that the implementer has started the task. If the task is moved to the Canceled state, e-mail is sent to the originator of the change and the Project Manager.

The DESIGN state indicates that a implementer has changed the state of the task from Assigned to Design. This transition indicates that the task is currently being designed by the implementer. The implementer may decide to start implementing the task and move it to the Implement state. The implementer may decide to temporarily postpone this task by moving back to the Assigned state. A Project Manager may decide to assign the task to a different implementer, thereby moving the task from Design to Assigned. If the task is moved back to the Assigned state, e-mail is sent to the assigned implementer.

The IMPLEMENT state indicates that the implementer is currently making the necessary changes to the software or documentation. This is where additional sub-level tasks, software or documentation changes, would be worked on. The task could be moved back to the Assigned state if the implementer decide not to work on it right away, or if the Project Manager reassigns the task. Once the implementer has completed the implementation, the task can be moved to the Integrate state. If the task is moved to the Integrate state, e-mail is sent to the integrator indicating that the task is ready for integration. If the task is moved to the Assigned state, e-mail is sent to the assigned implementer.

The INTEGRATE state indicates that a task has been fully implemented and ready to be integrated with other changes. The Integrate state includes moving changes from the development area into the engineering integration area. The integration of a task may be stopped and sent back to the Assigned state. The integrator may determine that the change is not implemented correctly, and move it back to the Implement state. The task may be integrated and then moved to the System_Test state. If the task is moved back to the Implement state, e-mail is sent to the assigned implementer. If integration of the task is stopped, e-mail is sent to the integrator, Project Manager, and the assigned implementer. If the task is moved to the System_Test state, e-mail is sent to the tester indicating that the task is ready to be tested.

The SYSTEM_TEST state indicates that a task and any of its sub-tasks have been fully implemented, integrated, and ready for system level testing. The tester may decide that a task is not complete and send it back to the Assigned state. If the tester determines that the change is not implemented correctly, it may be sent back to the Implement state. Once the system test is complete, the tester would move the task to the Completed state. If the task is moved back to the Assigned state, e-mail is sent to the tester, Project Manager, and the assigned implementer. If the task is sent back to the Implement state, e-mail is sent to the assigned implementer. If the task is moved to the Completed state, e-mail is sent to the originator and the Project Manager.

The COMPLETED state indicates that the change has been completely implemented, integrated, and system-tested. The change has been completed from the development team perspective. The Review Team can now review the change and the release manager can start the build/release process. The change could be reconsidered and put in the Pending state. If the task is moved to the Pending state, e-mail is sent to the originator.

The PENDING state indicates that the change has been put on hold. The task can be put on hold for a future release. Or it can be put on hold because the Project Manager determines that the change was not implemented. If the task is canceled, it can be moved from the Pending state to the Canceled state. If the task is canceled, e-mail is sent to the originator and the Project Manager. If work can begin on a task, it can be moved to the Assigned state. If the task is assigned, e-mail is sent to the assigned implementer.Canceled The Canceled state indicates that a task has been canceled. Typically this is done when it is determined that the change is not necessary. The change could be reconsidered and put in the Pending state.