The following examples show how two development teams apply CM rules for item and request types to meet their needs.
Example: 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:
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: 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 will expand to a larger development group, and will need 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 allows revisions to 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.
For item types, the team sets these rules:
Creation rule: Disabled so that the team can still create completely new items without requests.
New Revision rule: Set to the initial state so that it is immediately effective. This means that all subsequent revisions of an item require requests.
Action rule: Set to a state just prior to the state specified in the baseline template. Item revisions that existed prior to the rules being enabled are prevented from progressing beyond a certain state without a request, ensuring that they do not get included in any future baseline without this control. This rule would also be used to catch any item revisions that might become unrelated from a request for any reason.
NOTE Any item revisions that have already progressed beyond the state specified in the Action rule can still be actioned without the need for a request. The team must manage these items outside the scope of the rules specifications.
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:
Combines the ANALYSIS and WORK phases.
Specifies that a child request must reach a quality state before the parent request can close.
Following the delivery of the prototype, the team imposes further controls to prevent any unauthorized changes being made.