Clarity

Our organization is looking to migrate to a PMBOK scaled for measuring our risks.  Which unfortunately, Clarity is hard coded to 1,2,3 scale for the Low, Medium, High. 

My first thought is to create a very low (.5) and a very high (3.5) so we can have the full range. But I wasn't sure if anyone has implemented this before and had some insights into best practices.

          I am considering creating a new attribute to support this scale (1-5) and adjust the math to support, but not sure how to update the Risk Score setup screen to read the new attributes.

Also, any tips for the Risk Score setup would be awesome!  Unfortunately it is still assuming the three levels (L,M,H).

We are on SaaS, upgrading to 14.3 tomorrow!

Thank you in advanced, and please be kind I'm still learning

Hello Nikky,

As per the out-of-the-box CA Clarity PPM functionality, the values for the attribute - Risk Level are set to be Low (1), Medium (2) and High (3), and the attribute - Risk Score is a mathematically calculated field that sums up all the Risk Levels depending on the values selected and generates a final Risk Score of the Project. You can try to create a custom sub-object - Risk_Custom under the master object - Project, where you can create custom attributes for the Risk Levels and a mathematically calculated field - Risk Score. I have not really worked on such a customization in the past, but, just felt like sharing my views on this.

Suhail.

I've heavily customised the stock Risk functionality in the past ; adding a new custom attribute(s) to Risk that has your 1-5 measures is fairly easy , but you have to take into account all the "downstream" MI type information that you might be using based around Risk scores though.

I've been involved with much customization of risks and issues in CA PPM, going all the way back to Niku 6.

Don't do it.  IMO, its not worth it.  If more detail is needed, then define the impact, expected value - provide numbers, info that can help the user make a decision to do something, to differentiate a red on one project from a red on another project; associate risks/issues with tasks, so that one can see what part of the project is impacted.  Give management information that can be acted on, not more colors to decipher.

The message I keep hearing from successful CA PPM customers is "Use CA PPM as is, out of the box - get good at managing your processes; configure, fine, but quit customizing."

(I did mean configure really, not customise oops)

Hehehehe

I've been on this slide, so I meant customize - we went down that path, even paying CA to build a trigger for us.  I just see this whole thing starting with configure and then leading to customize.  And do the projects' customers pay for these changes or notice anything being done better as a result of all this?

No.

Yes, we've seen improvement in risk/issue management - but not as a result of our stoplight configuration/customization - it started improving when management got involved with the process, the content.  When management thinks its important, it will improve.

I'm still hoping for a 'do-over' - where we can get back to simple.

Dale Stockman wrote:

 

....starting with configure and then leading to customize.....

 

Yeah fair comment!  I'm all for being clever with "configure" (thats what I get paid to do ) but people now tend to listen to me when I tell them "no" (because that leads to "customize")

We are actually in the process of a "fresh start" so trying to stay as OOTB as possible. My thoughts are to update the LU values to the following:

• Very Low (1)
• Low (2)
• Medium (3)
• High (4)
• Very High (5)

And then update the logic for the overall risk score to the following ranges green (1-8), yellow (9-17), red (18-25) and setting our "threshold" to 13.

This way the only thing I'm modifying is the LUs names and adding two values to the probability and impact scores. (no new attributes!!)

Side Story: we had an outside company assist with standing up our instance, and they attempted this but added the new values of Very Low and Very High as 0 and 4 respectively.  As you can imagine, anything multiplied by 0 is 0, so the logic is all sorts of messed up right now... (GRRRR ARRG).

Hi Nikky

Like another poster said, you need to think about the downstream impact of making this change. The OOTB portlets and reports, especially Jaspersoft reports, will be affected by this change so be prepared to tweak those to get them to work with the increased LU options.

Another consideration is the Risk Settings matrix. Adding values to the Impact and Probability LUs will give you the additional columns and rows in Risk Settings but the values in the cross-overs will still be Low, Medium, High. These are driven by a System-restricted lookup (RCF_STANDARD_LMH) so no matter how many columns and rows you add you're always going to have to choose Low, Medium, High in the Risk Settings.

Maybe sometime in the future that'll change but for now it is what it is.

I did notice that!  I had to come up with a bit of a creative solution for it, which I built out the risk diagram and then did the demarcation for where H,M,L sit with the risk matrix.

The only challenge to that is the PMBOK measures risk on a 5 point scale and project management as a standard is moving that direction.  It's difficult when all our PMs are trained one way, but the tool has them following a different format.

I'm thinking I may just need to update the LU values so I'm not customizing too much, but raise a flag to CA.

No great pain to add some new values to RIM_IMPACT lookup I would think.

This TEC document How do I manage the list of values for the Risk Categories Lookup (RIM_CATEGORY_TYPE)  (TEC439187) discusses a bit on how the Risk Score works

This one too look at  How are Risk Scores calculated and what determines the color of the Risk Score?   (TEC439319)