Change Request Management

Change Request Management

Introduction

If project success means completing the project on time, within budget and with the originally agreed upon features and functionality,few software projects are rated successful.


Statement of Problem

In any enterprise software project, managing the changes in requirements is a very difficult task and it could become chaotic. If it is not properly managed, the consequences could be very costly to the project and it could ultimately result in the project’s failure.

Some Reasons for Failure

Poor requirements management: We forge ahead with development without user input and a clear understanding of the problems we attempt to solve.
Inadequate change management: Changes are inevitable; yet we rarely track them or understand their impact.
Poor resource allocation: Resource allocation is not re-negotiated consistently with the accepted Change Requests.

Changing Requirements

Software requirements are subjected to continuous changes for bad and good reasons. The real problem however, is not that software requirements change during the life of a project, but that they usually change out of a framework of disciplined planning and control processes. If adequately managed, Change Requests (CR) may represent precious opportunities to achieve a better customer satisfaction and profitability. If not managed, instead, CR represents threats for the project success.

Change Request Management (CRM)

CRM addresses the organizational infrastructure required to assess the cost, and schedule, impact of a requested change to the existing product. Change Request Management addresses the workings of a Change Review Team or Change Control Board.

Change Request

A Change Request (CR) is a formally submitted artifact that is used to track all stakeholder requests (including new features, enhancement requests, defects, changed requirements, etc.) along with related status information throughout the project lifecycle.

Change Tracking

Change Tracking describes what is done to components for what reason and at what time. It serves as history and rationale of changes. It is quite separate from assessing the impact of proposed changes as described under 'Change Request Management'.

Change or Configuration Control Board (CCB)

CCB is the board that oversees the change process consisting of representatives from all interested parties, including customers, developers, and users. In a small project, a single team member, such as the project manager or software architect, may play this role.

CCB Review Meeting

The function of this meeting is to review Submitted Change Requests. An initial review of the contents of the Change Request is done in the meeting to determine if it is a valid request. If so, then a determination is made if the change is in or out of scope for the current release(s), based on priority, schedule, resources, level-of-effort, risk, severity and any other relevant criteria as determined by the group.

Why control change across the life cycle?

“Uncontrollable change is a common source of project chaos, schedule slips and quality problems.”

Impact analysis

Impact analysis provides accurate understanding of the implications of a proposed change, helping you make informed business decisions about which proposals to approve. The analysis examines the context of the proposed change to identify existing components that might have to be modified or discarded, identify new work products to be created, and estimate the effort associated with each task.”

Traceability

Traceability provides a methodical and controlled process for managing the changes that inevitably occur during application development. Without tracing, every change would require reviewing documents on an ad-hoc basis to see if any other elements of the project need updating.

Establishing a Change Control Process

The following activities are required to establish CRM:

Establish the Change Request Process
Establish the Change Control Board
Define Change Review Notification Protocols