Something we originally did with our governance (and are in the process of re-adopting) is to set a prioritization scheme for enhancement requests (I didn't make this up, I stole - I mean borrowed/modified this).
Anyway, every factor has a numeric rating. Factors include ease of implementation (easier it is to do it the higher the priority), number of users benefited (the more people it benefits the higher the priority), whether this is mandated by compliance, senior management, etc. So if you have something that is easy to do and benefits a bunch of people, that's a no brainer. Difficult to do and only benefits a few people, not unless it's mandated by compliance/senior management. We are working on setting a minimum priority score, if it doesn't make the grade they get a thumbs down from governance. It's all math, it's very consistent and keeps people from letting passion, rather than reason make decisions (well, it helps ;) ). More fodder for the fire, happy Monday. Jack Covert Jack Covert Corporate IT Remedy Support Team Remedy Support Team Home Page http://collaborate.mckesson.com/sites/esm/remedy Remedy Q&A Sessions on Thursdays @ 10:30 AM PT Details on Remedy Support Team Home Page -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Mueller, Doug Sent: Monday, April 19, 2010 3:44 PM To: [email protected] Subject: Re: Logic in active links vs. filters --_000_5D162195414F544CAB0A9266F71BBD3913AF334EA8PHXCCRPRD01ad_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Jason, I always try and expand the question when I answer because often the real a= nswer is part of the bigger topic and just answering the details obscures the real best practice. So, as you note in your message, often there are requests to do things "jus= t because". Not for any clear benefit or business value, but just because it might be cool or someone hea= rd something that they thought sounds interesting -- regardless of value. So, first, it is to remind the = requestor that things really should have uses and clear value before just adding things. Otherwise systems get out = of control, slow, and unwieldy. This is the hardest thing for many developers to do because they know that = they could just do it and it is easier to just do it than to really work on trying to do it right/best. However, you always have a case where they say -- just do it. So, for these cases, I suggest falling back on the simple rule: Active links are for managing the current screen for the user. Whether tha= t be messing with visibility or loading data values or pushing data values to somewhere. It can be for pre= -validating or pre-checking to give more timely messages. It can be for giving lists of values to select from = or auto-filling related fields based on the response to one field. It may be to start an operation or to trigger a= n activity. At the end of the day, it is all about helping the user interact with the current screen. Filters are for everything else that is transaction based and Escalations a= re for everything that is timer based. Whenever there is a choice between a filter and an active link, select filt= er is a good general rule. If something can only be done by an active link, obviously choose it. If some= thing only by a filter, choose it. But, if both, select filter (and for those cases where you want to give fas= ter feedback for something like an _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug10 www.wwrug.com ARSlist: "Where the Answers Are"
