Change management

From Knowledge Kitchen
Jump to: navigation, search


There may be many changes in the lifetime of a system - bugs must be repaired, systems experience changes in their supportive environments, new features added, etc. Specialized tools can ensure that change requests are tracked, costed, prioritized, and implemented in a streamlined way.

Changes to the system are requested by stakeholders. These changes are unsurprisingly referred to as "change requests" or "issues".

A change request's lifecycle involves:

  • submission - submitting the change request - usually via a form in specialized software
  • validation - verifying whether the request is considered further, or rejected immediately
  • assessment - taking a balanced view of the request
  • feasibility analysis - determining whether the request can be accomplished, given other constraints
  • implementation - doing the change

Change requests

Most change management systems allow their stakeholders to submit 'change requests' using a form. These are typically requests for new functionality or requests to fix bugs that have been discovered. The contents of such requests, and their level of specificity, vary depending on the tool used, an organization's culture, and the sort of stakeholder who is entering the request into the change request form. Some organizations log bug reports separately from requests for new functionality, but they are ultimately all considered change requests.

Change requests may be trigered by any system stakeholders allowed to have a say in the product. For example, a request might be a triggered by direct feedback from customers, the result of changes in business goals of an organization's management, promotional desires of a company's sales and marketing teams, new feature requests or bug fixes entered by the system's developers themselves, or others.

Change management systems record the original request details, as well as a timestamped record of any additional details or decisions added by team members from then on, as it goes through review, consideration, approval, and implementation or closure. It becomes a living record of the complete and history state of a given change request at any point in its lifecycle.

Validation

Submitted change requests are first reviewed for validity. A request may be deemed invalid for a variety of reasons, such as high-level business reasons, or it may be a duplicate of another existing change request, or it may represent a misunderstanding on the part of the stakeholder of intended functionality of a product - this is common! Rejected change requests are closed, and the reasons for closure are, of course, logged in the request form within the change management system.

Assessment

If a change request is deemed valid, it is then assessed and costed. The time, effort and ultimately cost of implementing the change is estimated. This is usually handled by the development team.

Assessment includes cost estimations of any work required to be done to implement the change on the component in question, as well as any other components of the system that depend upon or in some way interact with the component that the request directly affects.

Feasibility

Following the assessment, a change request is analyzed for feasibility, prioritized, and scheduled.

A change request may prove infeasibile typically due to cost, but could be due to any other reasoning important to the product owners. Feasibility analysis typically involves answering the following questions:

  1. What are the consequences of not making the change?
    • If not making the change will lead to disaster or failure, obviously the change must be done immediately.
    • If not making the change has only minor effects, then it might be given a low priority, closed, or delayed till another development cycle.
  2. What are the benefits of making the change?
    • Will the change only benefit the proposer of the change, or could it be beneficial to many other users?
  3. How many users will be affected by the change?
    • If only a few users are affected, then the change might be assigned a low priority or closed if it requires all users to change how they use the system.
  4. What is the cost of making the change?
    • If making the change affects many system components and/or takes a lot of time to implement, then the change may be rejected.
  5. When is the proper time to implement such a change?
    • Depending on the development cycles of the organization, a given change may be scheduled immediately, or batched with other related changes in an upcoming minor revision, or scheduled for a later major release version.

Implementation

As developers implement a change to a component as the result of a change request, they may add a reference to the change request that initiated the change as a comment in the source code that they commit to the software version control system. This type of comment is known as a derivation history, and may show a log of all change requests that have been applied to the given component.

References

  • Software Engineering, 10th edition, by Ian Somerville. Chapter 25.3 - Change management


What links here