Step: Define Change Review Notification Protocols

Decide on who should review the various artifacts

Input to this step is the list of artifacts to be developed during the course of the project.

Members of staff need to review product related artifacts to decide on whether they meet defined project quality standards to be passed on to the next stage of development. If a product fails a review, it is subject to re-work, change and re-review.

For a review to be ‘effective’ the product has to be assessed by the right people who understand the scope and impact of a proposed change or enhancement. Furthermore, reviews need to be ‘cost effective’ such that staff time of key implementers and integrators is not being wasted on yielding ‘low impact’ defects.

Members of staff who need to be involved in a review are representatives from the ‘product’ producer, recipient and management sides. This is to ensure that all stakeholders with a vested interest in the product quality can decide on whether the product can progress to the next level of development.

In team environment, the overall project is broken down into work packages. Work packages are allocated to responsible individuals for implementation and integration. For example, the overall system is divided into subsystems, and then into individual packages. Workers responsible for implementing a package need to be sure that their changes are reviewed by peers within the subsystem, and anyone else in other subsystems who may be impacted by the changes.

The review and change notification principle is to communicate to peers and team leaders, and recipients of the proposed changes, and to give them an opportunity to review and comment on the proposals.

Guidance on who needs to be informed depending on state of a Change Request is provided in Concepts: Change Review Notification Protocols.