NetResults Tracker Help
The Change Management Template

Overview

The Change Management template supports a typical change management process. Common to this process is the review of proposed change requests before they can be implemented. This model assumes the following organizations are involved in the change management process:

Change Board - Responsible for reviewing and approving proposed change requests

Development - Responsible for implementing change requests.

QA - Verifies that the change request has been successfully implemented by the Development organization.

Build - Places the updated files into the final product package.

Quick Links

Projects

A default project called "Change Management" is available in this template and is visible to all user groups. This project can be customized and additional projects can be added via the Projects section.

Return to Topics List

Forms

A default form called "Change Request" is available in this template, is associated with the "Change Management" Project and is visible to all user groups. This form can be customized and additional forms can be added via the Forms section.

Return to Topics List

Fields

The Change Request form contains the following fields. Note that you can customize the database by adding to or removing fields, or changing any pulldown menu values. Field names with an asterisk are required by the system and cannot be removed from any form(s).
PRN* Numeric record identifier. Assigned at the time the request is created.
Summary A one line text summary of the change being proposed. Set at the time the request is created.
Change Level* Identifies the level of change being proposed. Set at the time the request is created.
Last Updated Date* The date and time the request was last modified. Set automatically as the request is processed through the workflow.
Reported In Version Version number of the product where related to the proposed change. Set at the time the request is created.
Area The area related to the proposed change. Possible values are: Hardware, Network, Software, Other and Unknown. Set at the time the request is created.
Severity Describes how serious the change is. Set at the time the request is created.
Description Full description of the change. Ideally describes the nature of the change and all ramifications of making the change. Set at the time the request is created.
Reported By* Name of the user that reported the problem. Initially set to the name of the current user logged in. Set at the time the request is created.
Date Reported The date the request was created. Automatically initialized, and set at the time the request is created.
Status* Current state of the request. Changes as the request is processed through the workflow.
Assigned To* User the request is currently assigned to for processing. Set either manually or automatically during processing of the workflow.
Est. Completion Date The date the change is estimated to be implemented.
Approval Date The date the change was approved. Set by the Change Board when the change is approved. Automatically initialized to the current date/time.
Pending Issues Full description of the reasons a change has been rejected. Set by the Change Board when the change is rejected.
Estimated Size Used to enter an estimated amount of time it will take for a change to be implemented.
Planned for Version Identifies the release number of the product in which the change is planned to be included.
Total Time Used to enter the actual amount of time spent implementing the change.
Implementation Date Date when the change was implemented. Set by Development when the change is implemented. Automatically initialized to the current date/time.
Implementation Detail A Description of the action taken by a developer to implement the change. Set by Development when the change is implemented.
Test Date Date when the implementation of the change was tested. Set by QA when the implementation is tested. Automatically initialized to the current date/time.
Test Description A Description of the action taken by a QA Engineer to test the implementation. Set by QA when the implementation is tested.
Priority Describes the relative importance of handling this change compared to other changes entered in the system.
Released in Version Identifies the release number of the product in which the change will be included.
Close Date Date when the change was closed. Set when no implementation work will be done for the change. Automatically initialized to the current date/time.
Close Detail A Description of the reason a change will be closed. Set when no implementation work will be done for the change.
Deleted* Denotes whether the request has been deleted.

Return to Topics List

Change Board Queue

A Home Page report can be set up as a queue for the Change Board members to use when reviewing and processing incoming change requests. TBD will be the user to which incoming change requests are assigned while they are in the queue. To represent a queue for the Change Board, the saved query Pending Approval [Change Board] was created to display all requests assigned to TBD in the Pending Approval state. Information on how requests are processed within the queue are discussed in the Workflows section below.

Return to Topics List

Workflows

It is assumed that requests will be processed and moved through the workflow process by using the Task operation. A default workflow called "Change Request Process" is available in this template and is associated with the "Change Request" Form and is in use in the "Change Management" Project. You can customize this workflow or add additional workflows via the Workflows section. The workflow implemented by the Change Management template is as follows:

  1. Pending Approval

    When a request is created, it is set to the state Pending Approval and is assigned to the Change Board. It is assumed that the Change Board is responsible for reviewing all incoming requests and deciding whether to approve each change. The Change Board can choose one of the following:

    • Approve the change request by selecting the transition called Approve. This transition will assign the request to the Development Manager and place the request in the Approved state. The Description field has been configured as a read-only task field for the Approver's reference while processing the request. The Approval Date will be set automatically to the current date/time. The Approver has the option to set a Planned for Version and Priority for the request.
    • Reject the change request by selecting the transition called Reject. This transition will assign the request to the Reporter and place the request in the Rejected state. The Description field has been configured as a read-only task field for the Approver's reference while processing the request. The Approver is required to enter comments into the Pending Issues field to explain the reasons for rejecting the request.
    • Close the change request by selecting the transition called Close. This transition will assign the request to TBD (no one - since this request will not be processed any further) and will place the request in the Closed state. The Description field has been configured as a read-only task field for the Approver's reference while processing the request. The Close Date will be set automatically to the current date/time. The Approver is required to be enter comments into the Close Detail field to explain why the request has been closed.

    This is implemented by:

    Default Add State Settings

    • Configuring Default Add State Settings to be based on the Change Level field
    • Defining Pending Approval as the Default Add State when a request is added for all products
    • Defining All as the state group for Allowed Add States when a request is added for all products
    State Managers State Managers are configured in the Form State Managers section.

    • Configuring TBD as the state manager for the Pending Approval state
    • Configuring the Development Manager as the state manager for the Approved state
    Transitions
    • Defining a transition to move a request to the Approved state where the assignee is the State Manager
    • Defining a transition to move a request to the Rejected state where the assignee is the Reporter
    • Defining a transition to move a request to the Closed state where the assignee is TBD
    Task Fields
    • Configuring Description (read only), Approval Date (read only and initialized), Planned for Version (optional) and Priority (optional) to be presented during the transition to the Approved state
    • Configuring Description (read only) and Pending Issues (required) to be presented during the transition to the Rejected state
    • Configuring Description (read only), Close Date (read only and initialized) and Close Detail (required) to be presented during the transition to the Closed state

  2. Approved

    The Development Manager is assumed to be a manager responsible for assigning change requests to the developers for implementation. The Development Manager uses the transition Assign to Resource to assign the request to a member of the Developers user group and has the option to set the Est. Close Date. This places the request in the In Process state.

    This is implemented by:

    Transitions

    • Defining a transition to move a request to the In Process state with the assignee to be chosen from a list of developers (user group called "Developers")
    Task Fields
    • Configuring Est. Close Date (optional) to be presented during the transition

  3. In Process

    The Developer assigned to the request implements the change and can either update how much time has been spent implementing the change by entering the time spent into the Total Time field in the Update Total Time transition or mark the task complete by selecting the Mark Fixed transition. The developer can enter the time spent implementing the change and is required to enter the details of the work done to implement the change and will place the request in the Implemented state and assign the request to the QA Manager. The Implementation Date will be set automatically with the current date/time.

    This is implemented by:

    State Managers

    • Defining QA Manager as the manager for the Fixed state
    Transitions
    • Defining a transition to keep the request in the same state and assigned to the same assignee
    • Defining a transition to move a request to the Fixed state where the assignee is the State Manager
    Task Fields
    • Configuring Total Time (required) to be presented and History Comment to be required during the update transition
    • Configuring Description (read only), Implementation Date (read only and initialized), Total Time (optional), Implementation Detail (required) to be presented during the transition to the Implemented state
  4. Implemented

    Once the request has been routed to the Implemented state, the QA Manager assigns it to a QA Engineer, a member of the QA user group. The request is routed to the In Test state using the transition Assign to QA.

    This is implemented by:

    Transitions

    • Defining a transition to move a request to the In Test state with the assignee to be chosen from a list of QA Engineers (members of a user group called "QA")
  5. In Test

    The QA Engineer verifies that the request has been implemented correctly and then uses the transition called Mark Tested to advance the request to the Tested. The transition will assign it to the Build Manager (bld_mgr). If a request has not been implemented correctly and needs to be returned to Development, the QA Engineer can move the request back to the In Development state using the transition Reject, which will assign it to the developer who worked on it. For each of these possible paths, the QA Engineer enters information in the Test Date and Test Description fields.

    This is implemented by:

    State Managers

    • Configuring bld_mgr to be the manager of the Tested state
    Transitions
    • Defining a transition to move a request to the Tested state where the assignee is the state manager
    • Creating a transition to move a request to the <Previous State> (In Development) where the assignee is the Last Assignee for the New State.
    Task Fields
    • Configuring Implementation Detail (read only), Test Date (read only and initialized) and Test Description (required) to be presented during the Task operation for the transitions to the In Development and Tested states.
  6. Tested

    The Build Manager (bld_mgr) user is assumed to be the user in charge of packaging the product for release, and responsible for ensuring that all the desired changes are included in the release. The Build Manager does what is necessary to make sure that the changes are included in the release, enters the released in version for the request, then advances the state of the request to "Released" using the transition called Release.

    This is implemented by:

    Transitions

    • Defining a transition to move the request to the Released state where the assignee is TBD. TBD ("no one") is selected since the release is the last step in the processing of the request.

    Task Fields

    • Configuring Planned for Version (read only), Released in Version (required) as a field to be presented during the transition to the Released state.

  7. Released

    This state indicates that processing of the request is complete.

  8. Closed

    This state indicates that the request will not be processed.

  9. Rejected

    This state indicates the request was rejected by the Change Board. The Reporter can re-submit the change request to the Change Board using the Re-Submit transition. This transition will place the request in the Pending Approval state and assign it to TBD (to represent the Change Board). The Reporter has the option to update the Description field and is required to update the Pending Issues field.

    This is implemented by:

    Transitions

    • Creating a transition to move the request to the Pending Approval state and assign it to the state manager

    Task Fields

    • Configuring Description (optional) and Pending Issues (required) to be presented during the transition to the Pending Approval state

Return to Topics List

Sample Saved Charts

A set of sample saved charts are included in this template. The default Project and Form will be selected as part of the criteria. If your workgroup contains multiple projects and forms, these charts can be edited to include additional projects or choose a different form, if desired:

Project Status (default) [Users]

This metric will generate a pie chart, which displays the relative number of requests in each possible state. It is designed to give you a quick breakdown of the overall status of a project. To limit the chart to a particular project or release, select a Saved Query that only displays (matches) the requests for the project or release as the value for Input Records and click Show Chart.

Add Rate [Users]

This metric will generate two dimensional line chart with the number of requests added during each week for the previous 26 weeks broken down by Area (one line per Area that has at least one request added in the last 26 weeks). It is designed to give you display trend information about the number of new reports (requests added) for each Area over the last six months.

Average Implementation Time [Users]

This metric will generate a two dimensional bar chart with the average number number of days it takes to implement a request, with one bar for each Severity. The time is calculated by using the difference between the Date Reported field and the Implementation Date field of each input record. It is designed to easily see differences in how fast particular changes are implemented based on their Severity.

Average Total Time

This metric will generate a bar chart, which shows the average value of the Total Time field for the group of input records, with one bar for each Area. It is designed to easily see the total time spent implementing changes in different Areas.

Implementation Rate [Users]

This metric will generate a line chart, which shows the number of requests that were implemented in each of the last 12 months. There is one line for each Change Level. And, the most recent month is a partial month (unless today is the last day of the month). A request is considered implemented if it moved into the Implemented state during the month. It can be used to view the number of changes implemented each month for the previous year. It allows you to distinguish by Change Level (e.g. 1 - Urgent, 2 - Standard, 3 - Non urgent).

Implementation Totals [Users]

This metric will generate a stacked line chart, which shows the cumulative number of requests that have been implemented as of the end of each month for the last twelve months. As with Implementation Rate, there is one (filled) line for each Change Level and the most recent month is a partial month (unless today is the last day of the month). A request is considered implemented if it has moved into the Implemented state at some point prior to the end of the month. It can be used to see running totals of changes that were implemented in the previous year, broken down by Change Level (e.g. 1 - Urgent, 2 - Standard, 3 - Non urgent).

Request Approval Rate

This metric will generate a line chart which shows the number of requests that have been approved in each of the last 12 months. There is one line for each Area. And, the most recent month is a partial month (unless today is the last day of the month). A request is considered approved if it moved into the Approved state during the month. It can be used to view the number of changes approved each month for the previous year. It allows you to distinguish by Area (Hardware, Software, etc.).

Request Rejection Rate

This metric will generate a line chart which shows the number of requests that have been rejected in each of the last 12 months. There is one line for each Area. And, the most recent month is a partial month (unless today is the last day of the month). A request is considered approved if it moved into the Rejected state during the month. It can be used to view the number of changes rejected each month for the previous year. It allows you to distinguish by Area (Hardware, Software, etc.).

Severity Trend [Users]

This metric will generate a three dimensional bar chart that displays the number of requests added during each of the last twelve weeks, broken down by Severity. It can be used to see if the severity of requests being added is changing over time.

Test Fail Rate [Users]

This metric will generate a line chart, which displays the number of times QA rejected an implementation (a request moved from "In Test" to "In Process") during each of the last twelve months. There is one line per Area. The most recent month may be a partial month. It is used to see how many requests that were marked as Implemented, subsequently failed quality assurance testing. Note: a single request may have failed multiple times.

Test Pass Rate [Users]

This metric will generate a line chart, which displays the number of times QA accepted (passed) an implementation (a record moved from "In Test" to "Tested") during each of the last twelve months. There is one line per Area. The most recent month may be a partial month. It is used to see how many requests that were marked as Fixed, subsequently passed quality assurance testing.

Workload [Users]

This metric will generate bar chart, which displays the number of requests assigned to each user. This can give you a rough idea of the current workload. If you have a field that represents the actual work required for a particular item (e.g. Estimated Size), you can create your own chart to total the value(s) of that field for each user and display it in a similar fashion.

Return to Topics List

Email Notification

The Change Management template is set up to notify users as follows:

On Add of a Record: The current assignee, the manager for the current state, the reporter of the request and the Change Board are notified

On Delete of a Record: The current assignee, the manager for the current state, and the reporter of the request are notified

On Change of Assignment: Both the current assignee and the manager for the current state of the request are notified

On Change of State to Released or Closed: The user who reported the request is notified when a request is moved to a state where processing is stopped

On Change of State to Pending Approval: The Change Board is notified when a request is moved to the Pending Approval

Return to Topics List

Security

The Change Management template assumes a very simple security model reflecting a workgroup situation where all users are able to see any request. This is implemented by setting Enable Record Visibility option under General Preferences in the Administration Task page to No.

In addition, the privileges related to editing fields within the requests have been removed from users that are not managers or Admin. With this configuration, users can rely on the Task operation to move requests through the workflow. This can be changed within the User Accounts section of the Admin page.

Return to Topics List

 

NetResults Tracker © 1997-2021 NetResults Corporation. All rights reserved.