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
Manage 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
Manage 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. |
| 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 records assigned to TBD in the
Pending Approval state. Information on how records 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
Manage Workflows section.
The workflow implemented by the Change
Management template is as follows:
- 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
Manage Projects
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
- 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. 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"
- 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 record 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
- 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")
- 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.
- 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 record.
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.
- State 7 - Released
This state indicates that processing of the request
is complete.
- State 8 - Closed
This state indicates that the request will not
be processed.
- State 9 - Rejected
This state indicates the request was rejected by the Change Board.
The Reporter can re-sumit 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 record 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 record 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 record are notified
On Change of Assignment
Both the current assignee and the manager for
the current state of the record are notified
On Change of State to Released or Closed
The user who reported the record is notified when a record is moved to
a state where processing is stopped
On Change of State to Pending Approval
The Change Board is notified when a record 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 record. 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 records have
been removed from users that are not managers or Admin.
With this configuration, users can rely on the Task operation to move records
through the workflow. This can be changed within the
User Administration section of the Admin page.
NetResults Tracker
