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 follow 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.

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.

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.

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.

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.

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. State 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. 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. State 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. 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. State 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. State 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. State 7 - Released
   This state indicates that processing of the request is complete.

8. State 8 - Closed
   This state indicates that the request will not be processed.

9. State 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

Sample Saved Charts

A set of sample saved charts are included in this template. Click here to see details of these sample metrics.

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

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.