It is sometimes necessary that the progress of a request is measured by the minimum status of its related child requests. For example, when a Problem Report (PR) is raised, a Problem Assessor may want to create a number of Change Requests (CR) from it and assign these change requests to individual developers for implementation. In this scenario the originator of the PR may want to assess the progress of the PR in terms of the minimum status of the CRs that are related to it.
Dimensions provides a "status auto-tracking" option in the process model for every possible pair of parent request types and children request types. When this option is enabled for a pair such as <PR, CR>, Dimensions will track the minimum status of the related CRs for each PR in a user-defined attribute for PR specified by the project manager. The value of this attribute may be browsed or reported on using standard Dimensions browse and report facilities.
As well as providing the minimum status information, maximum status may also be tracked if required. The combination of minimum and maximum status may be used to provide a better indication of the progress of the requests in general.
Only requests that are on the normal lifecycle path can have their status combined in a parent request. If more than two requests are related to the parent request, the attribute value will be set to the minimum status of those requests that have a status in the normal path.
For example, "WP_1" has an attribute "min_cn_status" which tracks the minimum status of requests "CN_1" and "CN_2" that are related to it as Dependent. "CN_1" is actioned to an off normal state, so the attribute will contain the status of "CN_2."
If there are no requests related as Dependent, then the minimum status attribute will be NULL, even if requests were related at some earlier time.
If all dependent requests are off the normal lifecycle path, then the combined status will be $OFF-NORMAL.
You can only track the minimum status of one type of request by using a specified attribute for that request. You can use a different attribute to track a different request type.
The minimum status is only calculated based on requests in direct relationship to the parent request. It does not take into account the dependents of the child requests.
Example: Tracking the Minimum Status
The Product Manager wants to track the minimum status of requests of type CN (Change Note) in relationship to requests of type WP (Work Package). The Product Manager defines a new attribute for the WP request type called min_cn_status, and unchecks the Display In options so the attribute is not visible to users. Then the Product Manager defines a valid relationship between the CN request type (child) and the WP request type (parent), and specifies the newly created attribute min_cn_status for the minimum status setting.
Example: Tracking Status with a Product-Level Lifecycle
Suppose the following lifecycles exist, with dependent request types assigned to them at the "product-level" and design parts "DP_1" and "DP_2".
|
Product-level |
DP_1 |
DP_2 |
|
Created |
Initial |
Created |
|
Active |
|
|
|
Review |
|
Fix |
|
Working |
Working |
|
|
Integrate |
|
Done |
|
Tested |
Tested |
|
|
Released |
Released |
Released |
|
Prod_integrate |
|
Supplied |
|
Prod_test |
|
|
|
Closed |
Closed |
Closed |
In this case, if a request follows the product-level lifecycle and has status "Active" and another request follows the DP_1 lifecycle and has status "Tested", then the minimum status is "Active" and the maximum is "Tested".
The DP_2 lifecycle states "Fix", "Done", and "Supplied" do not have an equivalent in the product-level lifecycle, so "Fix" and "Done" map to "Created", which is the previous state that maps to an equivalent, and "Supplied" maps to "Released". So, if a request is on the product-level lifecycle state "Active" and another is on the DP_2 at "Done", then their combined minimum is "Created" and maximum is "Active."
Related Topics