Use Change Management rules

Enable Change Management (CM) rules in the Administration Console to gain tighter control over planning, implementing, and closing changes.

Note: This functionality is available for items and Dimensions CM requests only.

Guideline for CM rules

In the Object Types section of the Administration Console, you can enable the following Change Management (CM) rules:

Rules for a Dimensions CM request type organize a request's lifecycle states into phases. These phases determine the relationships that can be established in each state, and the tasks that can be performed.

The rules also determine how parent-child requests affect each other.

Note: A request cannot be related to another request if rules are in force for one of their types and not for the other.
Rules for an item type connect a Dimensions CM request lifecycle and an item lifecycle. These rules require item revisions to be related to requests at various states in its lifecycle. In this way, CM rules bring version management and change management closer together, ensuring that related items and requests progress through their lifecycles in tandem. For details, see Link version and change management.

For details about the CM Rules tab where you manage these rules for items and requests, see Object Types content area.

To set Change Management rules, you need the Manage Object Types permission.

You enable rules for specific types of items and requests. This means that the same lifecycle can be reused in a product or across products with different rules applied per object type.

You can override CM rules for a project to make item operations in the project behave in the following ways:

To take effect based on whether the CM rules are enabled on the individual item and request types.
To behave as if CM rules were enabled for all item and request types.
To behave as if CM rules were disabled for all item and request types.

Note: The override of CM rules is not available for streams.

Most rules are related to states on the normal path through the relevant lifecycle.

Rules can be applied only to object types that are allowed to be in valid relationships. For items, you can specify relationships between two item types. For Dimensions CM requests, you can specify relationships between two requests types or a request type and an item type.

CM rules functions

CM rules for item types

Define when a request is required in order to perform certain functions on the item.
Specify the minimum state an item must be in before an associated Dimensions CM request can be closed.

CM rules for request types

Specify the states for which the request is in the phases: Analysis, Work, Frozen.

The phase associated with a lifecycle state determines what kind of processing of the request is permissible while it is at that lifecycle state.

Specify the minimum state a child request must be in before its related parent request can be closed.

These rules apply to item types and request types for which the CM rules enabled option has been set. They can also become applicable to item operations in projects which have the CM rules Always enabled option set.

CM rules for request lifecycles

When you apply CM rules to a Dimensions CM request type, you must group its lifecycle states into phases. A phase is a system-defined stage that determines what kind of processing can take place while a request is at that state.

The following table describes the phases.

Phase	Description	Permitted tasks
HELD	Specifies the stage in which an originator prepares and holds a request. A held request is not visible to any other users. It appears in the originator's inbox with the status $TO_BE_DEFINED. This phase does not correspond to an actual lifecycle state. The phase automatically applies to held requests.	Relate design parts Update attributes
CREATE	Specifies the normal lifecycle states (if any) which precede the ANALYSIS phase. The phase automatically applies to new requests.	Relate design parts Relate items as Affected Update attributes Add action descriptions Action
ANALYSIS	Specifies the normal lifecycle states in which you analyze and plan the implementation of the change. Good analysis during this phase ensures that you understand the change, and identify the dependencies and items that require changing. To set the phase, select the normal lifecycle state that signifies the start of the ANALYSIS phase. If you select the first state in the lifecycle, then the CREATE phase does not exist, and its activities are merged with those in the ANALYSIS phase.	Relate design parts Relate items as Affected Relate requests Update attributes Add action descriptions Action
WORK	Specifies the normal lifecycle states in which you implement the change. You can work on items that have been related as Affected in this phase. On check in, these items are automatically related as In Response To. If item rules require that a request is specified on check out, and an item has not yet been related as Affected, then Change Manager must relate the item as In Response To in this phase. To set the phase, select the normal lifecycle state that signifies the start of the WORK phase. You cannot select a state that precedes the state specified for the ANALYSIS phase.	Relate items as In Response To Update attributes Add action descriptions Action
FROZEN	Specifies the normal lifecycle states (if any) which follow the work phase but may precede the final normal state. This phase includes the states in which testing, baselining, and qualification of the software may take place. Consequently, no changes are permitted to any of the relationships, nor to any of the related item revisions. The related item revisions are also frozen by this stage, through baselining and/or actioning. Note: The restrictions on updating relationships do not apply to users with the CHANGE MANAGER role. To set the phase, select the normal lifecycle state that signifies the start of the FROZEN phase. If you select the final normal state, then the FROZEN phase does not exist. The request becomes frozen only when it is closed. You cannot select a state that precedes the state specified for the WORK phase.	Update attributes Add action descriptions Action
CLOSED	Specifies the final normal state. No further changes are permitted. The phase automatically applies to the final normal state.	None
REJECTED	Specifies all final states except the final normal state. No further changes are permitted. The phase automatically applies to any off-normal final states.	None
OFF NORM	Specifies all other states that are not in the normal lifecycle and are not final states. The phase automatically applies to all off-normal, non-final states.	Update attributes Add action descriptions Action
AN+WORK	A composite phase that specifies all normal lifecycle states between the CREATE phase and the FROZEN phase, as an alternative to assigning separate ANALYSIS and WORK phases. Using this phase works best on small teams, where some implementation may be allowed during analysis. For larger teams or projects, separate ANALYSIS and WORK phases are recommended for more control. To set the phase, select the same state for the WORK and ANALYSIS phases.	Relate design parts Relate items as Affected Relate items as in Response to Relate requests Update attributes Add action descriptions Action

Note: A request is described as open when it is in any phase except HELD, CLOSED, or REJECTED.

In addition to using these phases, you can define a rule for parent-child requests. This rule specifies the minimum state that the child request must reach so that the parent request can close. Also, the parent request can close if the child document is actioned to the REJECTED phase.

The tasks permitted in each phase can be performed only by the Dimensions CM users who hold a role on the current state. In the case of the HELD phase, the only authorized user is the originator. If the leader responsibility is enforced, then only the users with the leader responsibility can action the request and update its attributes.

Change Managers have additional permissions. They can relate and unrelate objects at any lifecycle state except the final state, as well as action any Dimensions CM request to any of its lifecycle states. They can also reactivate a closed or rejected request by actioning it to a non-final state.

CM rules for item lifecycles

For item types, you can enable CM rules so that the development of items is subject to the required level of change control and authorization. These rules provide the flexibility to introduce change control on items at whatever stage in the process is most applicable to them.

The rules for item types and their normal lifecycle states are described below. Note that rules are only applicable when the related request is on a normal lifecycle path.

Rule	Description	Sample scenario
Creation	Requires a request to be specified when creating a new item. When the item is created, it is related to the request as In Response To.	You need to enforce change control right from the beginning of a project.
New Revision	Specifies the state in the item's lifecycle in which all new item revisions based on the revision at the specified state must be related to a request as In Response To. If you specify the first lifecycle state, this requires every new revision to be related to a request.	You want to enforce change control after a beta release of the project.
Action	Specifies the state in the item's lifecycle in which an item cannot be actioned to the next normal state unless it is related to a request as In Response To.	You want to make sure that only the appropriate revisions progress far enough in their lifecycles to be baselined. You set this rule to catch item revisions from progressing without approval.
Closure	Specifies the state in the item's lifecycle that an item must reach in order for a related request to close.	You do not want to allow a request to be closed while any related item revision has not reached a quality state in its lifecycle.

Note: For the New Revision and Action rules, a request must be related as In Response To, which means that a previous revision of the same item must first be related as Affected. If the latter condition cannot be fulfilled, the Change Manager can override it when establishing the In Response To relationship.

Examples of applying CM rules

The following examples demonstrate how two development teams apply CM rules for item and request types to meet their needs.

Example 1: A highly controlled and visible project

Team A is working on a highly controlled and visible project that requires a high level of control and visibility. From the start of the project, the team needs to use CM rules to ensure that no new revision is created unless it is related to a request and approved.

For item types, the team sets these rules:

Creation rule. Set so that any new item requires a request.
New Revision rule. Set to the initial state so all subsequent revisions require requests.
Action rule. Set to a state just prior to a test state so that only controlled item revisions can be included in release baselines. This rule would also be used to catch any item revisions that might become unrelated from a request for any reason.
Closure rule. Set to a quality state in the item's lifecycle so a request can only close when the item reaches this state.

For request types, the team does the following:

Specifies different normal lifecycle states for the ANALYSIS, WORK, and FROZEN phases for full control.
Specifies that a child request must reach a quality state before the parent request can close.
Enforces the Leader role responsibility to maximize control.

Example 2: Prototype project

Team B, a small group of designers, must produce a prototype of a system in a short amount of time. The goal is to demonstrate capability and win a contract. After winning the contract, the team expands to a larger development group and needs to impose more product controls to ensure consistent and repeatable overall functionality.

During the initial stages of the prototype project, the team disables CM rules for items and request types. This way, revisions can be freely created and actioned.

Just before delivery, the team enables CM rules to ensure that items in the release baseline cannot be further developed without request authorization.