It's all about the answers!

Ask a question

RTC workflow - approve or promote


Norman Dignard (356688167) | asked Feb 19 '14, 10:03 a.m.

We are implementing a CR process in RTC (currently at 4.0.5) as a stand-alone project area. We support over 200 systems across the country as well as commericalized products.  We are our own end-users as well as our customers.

This CR project area is to be used for reporting issues from the field or changes requiring budgetary approvals. etc.. This PA is to be used to track and manage these records.  Day-to-day app development activities/SCM reside in other LCM project areas.  These other LCM PA's will be configured to use requests from this CR PA.

The CR area has multiple input sources, each input string, has its own "approval" process before it is sanctioned for LCM tasking.  For example: a user in Site A, raises a CR on system X.  In principal, this user's manager or Site A's tech authority would review/assess the issue and either reject/cancel it or approve it for a second level of review/approval by an Operational Authority (OA). On OA blessings, it is assigned to the system's LCM for implementation.  Similarilty a CR rasied say by a different EPD.

We are still green in defining the RTC process side but after some prototyping we opted  to use team areas for the migration of a CR through its "approval" process however this is where we hit a stumbling block.

We are using team areas to define user membership and hence who can see/mod/approve the CR. Once a CR is blessed it needs to be pushed into the next team area until it reaches a LCM team area for their action/implementation.

The problem we are having is whether to use a "approval" process or a "promotion" process to programically transfer a CR from one team area to another.  We can't seem to be able to figure out how to trigger such an event.

Has someone implemented such a process and if so can you share what you did to get this to work?

We are also open to alternative solutions.   Putting the CR process into each LCM PA is not an option for us due to control/maintenance issues that sharing a process from a master PA cannot address. With this approach, we mainatian one PA for CRs and the LCM PAs are free to us/adopt whatever internal process they choose (agile, traditional, etc...) with the association to use requests from a CR PA.

   

  


Comments
1
Arne Bister commented Feb 20 '14, 6:00 a.m.
JAZZ DEVELOPER

Norman,

are the team areas to which you want to move child areas of the CR project area? Or do they reside under other project areas, possibly on other servers?

- Arne

3 answers



permanent link
Norman Dignard (356688167) | answered Feb 20 '14, 2:27 p.m.

Our current approach is to have multiple team areas within the CR PA. Users (based on their organizational responsibility) would be put into the the appropriate team area. This is also to limit visibility during the "approval" steps/

For example in the CR project we envision the following team areas CR_Create - this is where "new" issues are raised by the most operational users. Once finalized the CR would be pushed to the next team area CR_Review

CR_Review - basically the first line managers. Users here can create new issues like in the CR_Create team as well as review/approve CRs. Approvers however are based on the system, region (ie east/west) and site (ie. toronto, montreal, etc). We may have subteams beneath this. On "approval" they push it to the OCR_Review team area.

OCR_Review - Basically a second line approval. These guys are the operational authority. They can create new requests and have final approval over CR's coming in from the CR_Review team.  On "approval" the CR is pushed into the applicable LCM_<system> team area as a NEW CR for their implementation.

The system LCM 's would then link tasks from their LCM PA to the CR. Closure of the CR would be based on a release of a new version/patch/etc.. from the LCM PA areas.

As for our JAZZ setup - we currently have only one server for everything (DNG/RTC/RQM) 

 


permanent link
Norman Dignard (356688167) | answered Feb 20 '14, 2:28 p.m.

Our current approach is to have multiple team areas within the CR PA. Users (based on their organizational responsibility) would be put into the the appropriate team area. This is also to limit visibility during the "approval" steps/

For example in the CR project we envision the following team areas CR_Create - this is where "new" issues are raised by the most operational users. Once finalized the CR would be pushed to the next team area CR_Review

CR_Review - basically the first line managers. Users here can create new issues like in the CR_Create team as well as review/approve CRs. Approvers however are based on the system, region (ie east/west) and site (ie. toronto, montreal, etc). We may have subteams beneath this. On "approval" they push it to the OCR_Review team area.

OCR_Review - Basically a second line approval. These guys are the operational authority. They can create new requests and have final approval over CR's coming in from the CR_Review team.  On "approval" the CR is pushed into the applicable LCM_<system> team area as a NEW CR for their implementation.

The system LCM 's would then link tasks from their LCM PA to the CR. Closure of the CR would be based on a release of a new version/patch/etc.. from the LCM PA areas.

As for our JAZZ setup - we currently have only one server for everything (DNG/RTC/RQM) 

 


permanent link
Arne Bister (2.6k12832) | answered Feb 20 '14, 4:15 p.m.
JAZZ DEVELOPER
edited Feb 20 '14, 4:17 p.m.
Norman,

unless I totally misunderstood your setup is straighforward and easy to resolve out of the box.
Simply use categories, map them to the appropriate team areas and restrict work item access (but not visibility). Changing the "filed against" attribute of a work item will then "move" that work item to the mapped team area.
This is a screenshot of what the categories look like in the web editor (manage project area):
Categories and Team Area Mapping

To automate things even further you can use preconditions on work items so that they can only get saved with certain "filed against" values if they have reached a certain state.
If this is helpful please mark the answer as accepted. Otherwise please clarify requirements further.

Best,
Arne

Your answer


Register or to post your answer.


Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.