Re: Working as designed type defects
To: arslist@ARSLIST.ORG Subject: Working as designed type defects ** I'm sending this post to the list community to see what is the general feeling about issues that BMC Support classifies as working as designed The category of issues I am referring to specifically here is inconsistencies in functionality between ITSM modules or within a single specific module. More specifically, and to name only a few, in ITSM 7.5.1 but apparently still present in 7.6.3: - Assigned group searches in tasks are different than assigned group searches in change - Assigned group searches, change manager group searches, and change implementer group searches are different - Task tab in problem investigation is different than the task tab in the incident form When I raise these issues with BMC support, I get the reply that it's working as designed. Well the problem with that, is that customization is required to make functionality, and look and feel consistent. It seems to me that BMC should create a Design Defect classification in addition to the existing defect classification, which are essentially implementation defects. I mean why should I need to create an RFE for something that should work consistently in the first place? Seems like Working As Designed is simply an easy way out of the situation. Quality Assurance **should** catch these defects. Is this too much to ask? A defect is a defect because the customer perceives that as a defect, that should be the bottom line. This is not new functionality, only making the functionality and user interface work to the way it is expected. Thoughts? Guillaume _attend WWRUG11 www.wwrug.com ARSlist: Where the Answers Are_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: Where the Answers Are
Re: Working as designed type defects
Doug, Thanks for the clarifications. I guess there are multiple schools of thought on this but your logic makes sense. One issue, though, is with the RFE process itself. I've never worked on applications that were being sold outside of my employer so I haven't had to deal with it before, but it seems like the RFE process is a bit mysterious. We can submit RFEs, but there doesn't seem to be a good way to tell what is going on with them. If I were to submit an RFE that I was passionate about, but there was no way of knowing if BMC engineering were evaluating it or actually going to enhance the feature in the next version, I would be discouraged from submitting many more RFEs after that. It does seem like our RFEs often go into a black hole, which has an impact on those of us that do both ARS development and support ITSM. For example, if I submit an RFE and get no feedback from BMC, I don't have sufficient information to decide whether to go ahead and build the solution myself as a customization, or if I should tell my customers it would be released in a patch in two months or if it will be included in ITSM 8.0 to be released even further out. I think if the RFE process were a little less mysterious, we would be more inclined to submit them. Thanks, Shawn Pierson Remedy Developer | Southern Union From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Mueller, Doug Sent: Friday, November 19, 2010 1:49 PM To: arslist@ARSLIST.ORG Subject: Re: Working as designed type defects ** Everyone, This topic has several different facets. I will try and address the different aspects I see. 1) Consistency of functionality across application is important. Absolutely. Everything from using consistent wording to consistent options, to consistent interaction. This should be true across all applications. Now, are the applications as good as they should be in some cases? No. Are they getting better with every release? Yes Is the goal to keep working on things so that there is more and more consistency of interaction? Yes There are times when there are changes to interaction that hit different applications at different times. That can introduce some temporary inconsistency until the other application(s) catch up with the new approach. But, those are a different type of issue. The things called out on this thread are about wording and operation and function for specific operations type consistency. This should be done better. 2) As designed response from support Well, there is always the balance of something being wrong or something working the way the product was intended. So, yes, even when there is some inconsistency of operation, if the product is working as it was intended (we will get to whether the intended was good or not in a bit), the answer you are getting is an accurate one. If something isn't working, then that is different. That may be a design error if it is not working. If something is not working, then you should push back on the as designed labelling. If it is working but is just not doing what you would like (or is not the same as some other application) this is not a design error -- it is doing what it was designed to do -- but it is something that could be done better to allow the solution as a whole to do better. What I have seen in this thread is that things are working but you would like them to be working differently so that the same things are the same way in different applications (and that is a justified desire) 3) The RFE (Request for Enhancement) process Now, if something is working and you want it to work differently, that is an enhancement request to the system. This is true whether it is just to work differently in isolation or whether it is to change it to work like it does somewhere else. This is no different than asking for a new capability of the system. Customers are always encouraged to submit enhancement requests to add to or alter the behavior of the system to do better for them. We have to treat RFEs differently than defects (bugs). A bug is not working and it should be fixed so that it works. No one will be disrupted by a feature that didn't work that now does. However an enhancement that adds functionality or changes how something interacts when it was working before can be disruptive and so needs to come in as a new feature in a release. I understand that there is subtlety here and that there are gray areas between things. And, you should feel free to have a discussion if something does fall into the gray area. But, most things will clearly fall on one side of the line or the other. There is a process for handling things on either side of the line to allow the best and most orderly response. Would it be better if there were no inconsistencies? You bet! But, they do creep in sometimes. We need to be diligent about working them out of the system. So
Re: Working as designed type defects
Hi Doug, The RFE process is documented here: Request for Enhancement (RFE) process for distributed systems productshttp://media.cms.bmc.com/documents/ESM_RFE_Process.pdf. And you can always find the status of an RFE here: Product Defectshttp://apps.bmc.com/server/available.cfm?fc=REMDEFECTS. You can even search for RFEs that you yourself did not submit - i.e. you can see all known defects/RFEs submitted by all customers. Hopefully this makes the process less mysterious and gives you a method to track RFEs. -David J. Easter Sr. Product Manager, Enterprise Service Management BMC Software, Inc. The opinions, statements, and/or suggested courses of action expressed in this E-mail do not necessarily reflect those of BMC Software, Inc. My voluntary participation in this forum is not intended to convey a role as a spokesperson, liaison or public relations representative for BMC Software, Inc. From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Pierson, Shawn Sent: Friday, November 19, 2010 12:02 PM To: arslist@ARSLIST.ORG Subject: Re: Working as designed type defects ** Doug, Thanks for the clarifications. I guess there are multiple schools of thought on this but your logic makes sense. One issue, though, is with the RFE process itself. I've never worked on applications that were being sold outside of my employer so I haven't had to deal with it before, but it seems like the RFE process is a bit mysterious. We can submit RFEs, but there doesn't seem to be a good way to tell what is going on with them. If I were to submit an RFE that I was passionate about, but there was no way of knowing if BMC engineering were evaluating it or actually going to enhance the feature in the next version, I would be discouraged from submitting many more RFEs after that. It does seem like our RFEs often go into a black hole, which has an impact on those of us that do both ARS development and support ITSM. For example, if I submit an RFE and get no feedback from BMC, I don't have sufficient information to decide whether to go ahead and build the solution myself as a customization, or if I should tell my customers it would be released in a patch in two months or if it will be included in ITSM 8.0 to be released even further out. I think if the RFE process were a little less mysterious, we would be more inclined to submit them. Thanks, Shawn Pierson Remedy Developer | Southern Union ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: Where the Answers Are
Re: Working as designed type defects
Doug, thanks for your reply. The issue that I have with the working as designed label is that it implies that someone consciously made the decision for the design to be the way it is. That someone would be a product/application architect, a lead product/application developer, or lead business/system analyst. In any case, there is evidence of what the original intention was. If there is no evidence of the decision or intention of the design at fault, how can we classify this issue as working as designed? This is a problem of semantics Maybe it's better to classify this type of as working as not expected or something along those lines. BTW, when I convey to the customer the exact response from BMC support, the working as designed, they are like WTF ?? You see what I meanit's an corporate image/marketing issue here too. Guillaume From: Action Request System discussion list(ARSList) [arsl...@arslist.org] on behalf of Mueller, Doug [doug_muel...@bmc.com] Sent: Friday, November 19, 2010 2:48 PM To: arslist@ARSLIST.ORG Subject: Re: Working as designed type defects ** Everyone, This topic has several different facets. I will try and address the different aspects I see. 1) Consistency of functionality across application is important. Absolutely. Everything from using consistent wording to consistent options, to consistent interaction. This should be true across all applications. Now, are the applications as good as they should be in some cases? No. Are they getting better with every release? Yes Is the goal to keep working on things so that there is more and more consistency of interaction? Yes There are times when there are changes to interaction that hit different applications at different times. That can introduce some temporary inconsistency until the other application(s) catch up with the new approach. But, those are a different type of issue. The things called out on this thread are about wording and operation and function for specific operations type consistency. This should be done better. 2) As designed response from support Well, there is always the balance of something being wrong or something working the way the product was intended. So, yes, even when there is some inconsistency of operation, if the product is working as it was intended (we will get to whether the intended was good or not in a bit), the answer you are getting is an accurate one. If something isn't working, then that is different. That may be a design error if it is not working. If something is not working, then you should push back on the as designed labelling. If it is working but is just not doing what you would like (or is not the same as some other application) this is not a design error -- it is doing what it was designed to do -- but it is something that could be done better to allow the solution as a whole to do better. What I have seen in this thread is that things are working but you would like them to be working differently so that the same things are the same way in different applications (and that is a justified desire) 3) The RFE (Request for Enhancement) process Now, if something is working and you want it to work differently, that is an enhancement request to the system. This is true whether it is just to work differently in isolation or whether it is to change it to work like it does somewhere else. This is no different than asking for a new capability of the system. Customers are always encouraged to submit enhancement requests to add to or alter the behavior of the system to do better for them. We have to treat RFEs differently than defects (bugs). A bug is not working and it should be fixed so that it works. No one will be disrupted by a feature that didn't work that now does. However an enhancement that adds functionality or changes how something interacts when it was working before can be disruptive and so needs to come in as a new feature in a release. I understand that there is subtlety here and that there are gray areas between things. And, you should feel free to have a discussion if something does fall into the gray area. But, most things will clearly fall on one side of the line or the other. There is a process for handling things on either side of the line to allow the best and most orderly response. Would it be better if there were no inconsistencies? You bet! But, they do creep in sometimes. We need to be diligent about working them out of the system. So, if you have had things that are as designed that are working but you wish they worked differently, please enter an RFE for the change to have it considered for a product enhancement. If you have things that are as designed but are NOT working, then it is fair to ask how something can be designed to not work! Your input is invaluable in helping to move the product forward. Input from customers has led to a number
Re: Working as designed type defects
Guillame, I tried to be clear in my statement. If the feature is working -- it is doing the job requested and generating the results expected -- it is doing the work that the developer designed it to do. If that implementation is inconsistent with a similar function in a different application, that is the consistency issue that was brought up on the thread. That means that different people designed the same function or a similar function in two different ways in two different products. Each may work, but they work differently. So, both are working as they were designed, but they are not working consistently across the two products which is less than optimal. If a feature is not working, it is broken. Whether that brokenness is because the design is bad or because a code error or because of the environment is a part of the detail. The feature is not doing the job. The cases that were brought up on the thread were all falling into the working but working differently in different applications. That is where the RFE process is the way to get things worked on. BMC tries to bring these things together and is more successful in some areas than others. But, there are clearly areas where there is a lack of consistency. By the way, working as designed does not mean working in the best way possible. It is simply working in the way the software was intended to work by the folks who implemented it. In discussing an issue with an end user, it doesn't change the fact that they are having an issue or would like to have something be different. But, the question is does the function do the job or not. Not is a bug, Yes but would like to be different about how it does it is an RFE. There are differences in how to go about addressing things in the two different categories. Now, if in your opinion, the operation is not doing the job that that feature should be doing, you should definitely feel justified in opening a support issue and working it through the support team. If the answer is that the product is doing the job it was designed to do, an enhancement request is possible. It would be like you wanting your car to go 500 miles per hour and you had a Ford Pinto from the 70s or 80s. You can say it is a bug that the car doesn't go 500 miles per hour when you press on the accelerator but the answer that the design limit is really 80 (or should it be 50) miles per hour is the limit is the design limit. It would very definitely be an enhancement request to ask for that car to go 500 miles per hour. On the other hand, if no matter what you do, it went only 5 miles per hour. The answer that it was how it was designed and it is limited to that is not an enhancement since it is not doing what its reasonable and expected function is -- to allow you to move around town reasonably. Is there a gray area around 70 mph or so? Sure there is. But that is for a subjective measure like this one. Most features have a more objective mearsure about what they are doing. Again, most of this thread was not about things not working but about not working in the same way in different applications. There was, in general, no disagreement about working. It was about doing it in the same way. Note that I have suggested filing BOTH types of things with BMC -- just one is a bug and the other an enhancement request. I also wanted to call out the fact that there is the enhancement request process that is available to all customers for any type of a change/extension/improvement to the product that they can think of. Our product management team does pay a lot of attention to these requests for future functionality. Doug Mueller From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Guillaume Rheault Sent: Friday, November 19, 2010 12:19 PM To: arslist@ARSLIST.ORG Subject: Re: Working as designed type defects ** Doug, thanks for your reply. The issue that I have with the working as designed label is that it implies that someone consciously made the decision for the design to be the way it is. That someone would be a product/application architect, a lead product/application developer, or lead business/system analyst. In any case, there is evidence of what the original intention was. If there is no evidence of the decision or intention of the design at fault, how can we classify this issue as working as designed? This is a problem of semantics Maybe it's better to classify this type of as working as not expected or something along those lines. BTW, when I convey to the customer the exact response from BMC support, the working as designed, they are like WTF ?? You see what I meanit's an corporate image/marketing issue here too. Guillaume From: Action Request System discussion list(ARSList) [arsl...@arslist.org] on behalf of Mueller, Doug [doug_muel...@bmc.com] Sent
Re: Working as designed type defects
In ref to Risk Level being consistent with Urgency, Impact and Priority: Support tells me that numerous RFEs to get Risk Level changed to be consistent with Urgency, Impact and Priority have been rejected. I insisted on my own RFE to add to the pile. I'll let you know how it turns out. Tim From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Mueller, Doug Sent: Friday, November 19, 2010 2:49 PM To: arslist@ARSLIST.ORG Subject: Re: Working as designed type defects ** Everyone, This topic has several different facets. I will try and address the different aspects I see. 1) Consistency of functionality across application is important. Absolutely. Everything from using consistent wording to consistent options, to consistent interaction. This should be true across all applications. Now, are the applications as good as they should be in some cases? No. Are they getting better with every release? Yes Is the goal to keep working on things so that there is more and more consistency of interaction? Yes There are times when there are changes to interaction that hit different applications at different times. That can introduce some temporary inconsistency until the other application(s) catch up with the new approach. But, those are a different type of issue. The things called out on this thread are about wording and operation and function for specific operations type consistency. This should be done better. 2) As designed response from support Well, there is always the balance of something being wrong or something working the way the product was intended. So, yes, even when there is some inconsistency of operation, if the product is working as it was intended (we will get to whether the intended was good or not in a bit), the answer you are getting is an accurate one. If something isn't working, then that is different. That may be a design error if it is not working. If something is not working, then you should push back on the as designed labelling. If it is working but is just not doing what you would like (or is not the same as some other application) this is not a design error -- it is doing what it was designed to do -- but it is something that could be done better to allow the solution as a whole to do better. What I have seen in this thread is that things are working but you would like them to be working differently so that the same things are the same way in different applications (and that is a justified desire) 3) The RFE (Request for Enhancement) process Now, if something is working and you want it to work differently, that is an enhancement request to the system. This is true whether it is just to work differently in isolation or whether it is to change it to work like it does somewhere else. This is no different than asking for a new capability of the system. Customers are always encouraged to submit enhancement requests to add to or alter the behavior of the system to do better for them. We have to treat RFEs differently than defects (bugs). A bug is not working and it should be fixed so that it works. No one will be disrupted by a feature that didn't work that now does. However an enhancement that adds functionality or changes how something interacts when it was working before can be disruptive and so needs to come in as a new feature in a release. I understand that there is subtlety here and that there are gray areas between things. And, you should feel free to have a discussion if something does fall into the gray area. But, most things will clearly fall on one side of the line or the other. There is a process for handling things on either side of the line to allow the best and most orderly response. Would it be better if there were no inconsistencies? You bet! But, they do creep in sometimes. We need to be diligent about working them out of the system. So, if you have had things that are as designed that are working but you wish they worked differently, please enter an RFE for the change to have it considered for a product enhancement. If you have things that are as designed but are NOT working, then it is fair to ask how something can be designed to not work! Your input is invaluable in helping to move the product forward. Input from customers has led to a number of significant cleanups in the applications in the past few releases and we are getting good response to the 7.6.3 release and another wave of consistency is coming in the next few releases. Also, some modularization going on inside the applications is making it more likely that consistent interaction will occur in many areas with more sharing of logic and interaction. This is a good discussion and it is important to keep BMC honest and not just hide behind an as designed shield. Please keep up the pressure. But, I hope
Re: Working as designed type defects
Hello Tim, Thanks for the quick reply. I let 1 of the users know that he is now a recognized bug ;-) On the other hand: what does RFE stand for. I found about 2 dozen possibilities on google. Thanks, Larry From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Timothy Powell Sent: Friday, November 19, 2010 3:13 PM To: arslist@ARSLIST.ORG Subject: Re: Working as designed type defects ** In ref to Risk Level being consistent with Urgency, Impact and Priority: Support tells me that numerous RFEs to get Risk Level changed to be consistent with Urgency, Impact and Priority have been rejected. I insisted on my own RFE to add to the pile. I'll let you know how it turns out. Tim From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Mueller, Doug Sent: Friday, November 19, 2010 2:49 PM To: arslist@ARSLIST.ORG Subject: Re: Working as designed type defects ** Everyone, This topic has several different facets. I will try and address the different aspects I see. 1) Consistency of functionality across application is important. Absolutely. Everything from using consistent wording to consistent options, to consistent interaction. This should be true across all applications. Now, are the applications as good as they should be in some cases? No. Are they getting better with every release? Yes Is the goal to keep working on things so that there is more and more consistency of interaction? Yes There are times when there are changes to interaction that hit different applications at different times. That can introduce some temporary inconsistency until the other application(s) catch up with the new approach. But, those are a different type of issue. The things called out on this thread are about wording and operation and function for specific operations type consistency. This should be done better. 2) As designed response from support Well, there is always the balance of something being wrong or something working the way the product was intended. So, yes, even when there is some inconsistency of operation, if the product is working as it was intended (we will get to whether the intended was good or not in a bit), the answer you are getting is an accurate one. If something isn't working, then that is different. That may be a design error if it is not working. If something is not working, then you should push back on the as designed labelling. If it is working but is just not doing what you would like (or is not the same as some other application) this is not a design error -- it is doing what it was designed to do -- but it is something that could be done better to allow the solution as a whole to do better. What I have seen in this thread is that things are working but you would like them to be working differently so that the same things are the same way in different applications (and that is a justified desire) 3) The RFE (Request for Enhancement) process Now, if something is working and you want it to work differently, that is an enhancement request to the system. This is true whether it is just to work differently in isolation or whether it is to change it to work like it does somewhere else. This is no different than asking for a new capability of the system. Customers are always encouraged to submit enhancement requests to add to or alter the behavior of the system to do better for them. We have to treat RFEs differently than defects (bugs). A bug is not working and it should be fixed so that it works. No one will be disrupted by a feature that didn't work that now does. However an enhancement that adds functionality or changes how something interacts when it was working before can be disruptive and so needs to come in as a new feature in a release. I understand that there is subtlety here and that there are gray areas between things. And, you should feel free to have a discussion if something does fall into the gray area. But, most things will clearly fall on one side of the line or the other. There is a process for handling things on either side of the line to allow the best and most orderly response. Would it be better if there were no inconsistencies? You bet! But, they do creep in sometimes. We need to be diligent about working them out of the system. So, if you have had things that are as designed that are working but you wish they worked differently, please enter an RFE for the change to have it considered for a product enhancement. If you have things that are as designed but are NOT working, then it is fair to ask how something can be designed to not work! Your input is invaluable in helping to move the product forward. Input from customers has led to a number of significant cleanups in the applications in the past few releases
Re: Working as designed type defects
Request for Enhancement From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Larry Barnes Sent: Friday, November 19, 2010 3:22 PM To: arslist@ARSLIST.ORG Subject: Re: Working as designed type defects ** Hello Tim, Thanks for the quick reply. I let 1 of the users know that he is now a recognized bug ;-) On the other hand: what does RFE stand for. I found about 2 dozen possibilities on google. Thanks, Larry From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Timothy Powell Sent: Friday, November 19, 2010 3:13 PM To: arslist@ARSLIST.ORG Subject: Re: Working as designed type defects ** In ref to Risk Level being consistent with Urgency, Impact and Priority: Support tells me that numerous RFEs to get Risk Level changed to be consistent with Urgency, Impact and Priority have been rejected. I insisted on my own RFE to add to the pile. I'll let you know how it turns out. Tim From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Mueller, Doug Sent: Friday, November 19, 2010 2:49 PM To: arslist@ARSLIST.ORG Subject: Re: Working as designed type defects ** Everyone, This topic has several different facets. I will try and address the different aspects I see. 1) Consistency of functionality across application is important. Absolutely. Everything from using consistent wording to consistent options, to consistent interaction. This should be true across all applications. Now, are the applications as good as they should be in some cases? No. Are they getting better with every release? Yes Is the goal to keep working on things so that there is more and more consistency of interaction? Yes There are times when there are changes to interaction that hit different applications at different times. That can introduce some temporary inconsistency until the other application(s) catch up with the new approach. But, those are a different type of issue. The things called out on this thread are about wording and operation and function for specific operations type consistency. This should be done better. 2) As designed response from support Well, there is always the balance of something being wrong or something working the way the product was intended. So, yes, even when there is some inconsistency of operation, if the product is working as it was intended (we will get to whether the intended was good or not in a bit), the answer you are getting is an accurate one. If something isn't working, then that is different. That may be a design error if it is not working. If something is not working, then you should push back on the as designed labelling. If it is working but is just not doing what you would like (or is not the same as some other application) this is not a design error -- it is doing what it was designed to do -- but it is something that could be done better to allow the solution as a whole to do better. What I have seen in this thread is that things are working but you would like them to be working differently so that the same things are the same way in different applications (and that is a justified desire) 3) The RFE (Request for Enhancement) process Now, if something is working and you want it to work differently, that is an enhancement request to the system. This is true whether it is just to work differently in isolation or whether it is to change it to work like it does somewhere else. This is no different than asking for a new capability of the system. Customers are always encouraged to submit enhancement requests to add to or alter the behavior of the system to do better for them. We have to treat RFEs differently than defects (bugs). A bug is not working and it should be fixed so that it works. No one will be disrupted by a feature that didn't work that now does. However an enhancement that adds functionality or changes how something interacts when it was working before can be disruptive and so needs to come in as a new feature in a release. I understand that there is subtlety here and that there are gray areas between things. And, you should feel free to have a discussion if something does fall into the gray area. But, most things will clearly fall on one side of the line or the other. There is a process for handling things on either side of the line to allow the best and most orderly response. Would it be better if there were no inconsistencies? You bet! But, they do creep in sometimes. We need to be diligent about working them out of the system. So, if you have had things that are as designed that are working but you wish they worked differently, please enter an RFE for the change to have it considered for a product enhancement. If you have things that are as designed but are NOT working, then it is fair to ask how something can
Re: Working as designed type defects
Don't get me wrong. The reason for the Risk Level design sounded fairly valid (or at least reasonable). I just didn't know why the design principle (if truly valid) wasn't applied across all the areas in question, which by default, would then make them behave consistently. So: . Do the Risk Level calculations and subsequent derived values work and produce a valid result? Absolutely. So the response of Working as Designed is accurate. This is no longer a support issue. . Do I want Risk Level to work differently and be consistent with the Urgency/Impact/Priority values (or do I want Urgency/Impact/Priority to work differently and be consistent with Risk Level values)? Yes. Now it's an RFE. :-) Thanks Doug for taking the time to respond. Tim _ From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Timothy Powell Sent: Friday, November 19, 2010 3:13 PM To: arslist@ARSLIST.ORG Subject: Re: Working as designed type defects ** In ref to Risk Level being consistent with Urgency, Impact and Priority: Support tells me that numerous RFEs to get Risk Level changed to be consistent with Urgency, Impact and Priority have been rejected. I insisted on my own RFE to add to the pile. I'll let you know how it turns out. Tim From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Mueller, Doug Sent: Friday, November 19, 2010 2:49 PM To: arslist@ARSLIST.ORG Subject: Re: Working as designed type defects ** Everyone, This topic has several different facets. I will try and address the different aspects I see. 1) Consistency of functionality across application is important. Absolutely. Everything from using consistent wording to consistent options, to consistent interaction. This should be true across all applications. Now, are the applications as good as they should be in some cases? No. Are they getting better with every release? Yes Is the goal to keep working on things so that there is more and more consistency of interaction? Yes There are times when there are changes to interaction that hit different applications at different times. That can introduce some temporary inconsistency until the other application(s) catch up with the new approach. But, those are a different type of issue. The things called out on this thread are about wording and operation and function for specific operations type consistency. This should be done better. 2) As designed response from support Well, there is always the balance of something being wrong or something working the way the product was intended. So, yes, even when there is some inconsistency of operation, if the product is working as it was intended (we will get to whether the intended was good or not in a bit), the answer you are getting is an accurate one. If something isn't working, then that is different. That may be a design error if it is not working. If something is not working, then you should push back on the as designed labelling. If it is working but is just not doing what you would like (or is not the same as some other application) this is not a design error -- it is doing what it was designed to do -- but it is something that could be done better to allow the solution as a whole to do better. What I have seen in this thread is that things are working but you would like them to be working differently so that the same things are the same way in different applications (and that is a justified desire) 3) The RFE (Request for Enhancement) process Now, if something is working and you want it to work differently, that is an enhancement request to the system. This is true whether it is just to work differently in isolation or whether it is to change it to work like it does somewhere else. This is no different than asking for a new capability of the system. Customers are always encouraged to submit enhancement requests to add to or alter the behavior of the system to do better for them. We have to treat RFEs differently than defects (bugs). A bug is not working and it should be fixed so that it works. No one will be disrupted by a feature that didn't work that now does. However an enhancement that adds functionality or changes how something interacts when it was working before can be disruptive and so needs to come in as a new feature in a release. I understand that there is subtlety here and that there are gray areas between things. And, you should feel free to have a discussion if something does fall into the gray area. But, most things will clearly fall on one side of the line or the other. There is a process for handling things on either side of the line to allow the best and most orderly response. Would it be better if there were no inconsistencies? You bet! But, they do creep in sometimes. We need to be diligent
Re: Working as designed type defects
Like most, I'm frustrated with the inconsistencies that have been around since version 7.0. Many are cosmetic and merely a matter of rearranging objects. I'm on the bandwagon there, just fix it and make it work the same from form to form. I'm concerned with changing the values of the fields. Is it worth breaking backwards compatibility, modifying all your existing data just to make things more consistent? Is the consistency gained worth the tradeoff in making that change? Ben Cantatore Remedy Manager (914) 457-6209 Emerging Health IT 3 Odell Plaza Yonkers, New York 10701 jdso...@shyle.net 11/10/10 6:37 PM ** Alternately you could customize some of the most frequently used forms to have the Logout button that looks the same as the Home Page and drive that button with a Perform-Application-Exit process.. might take some work, but that would give some degree of consistency on where you can find the Logout link/button.. I absolutely agree that it should have been available a little more through the application to maintain some sort of visual as well as functional consistency.. Joe From: Meyer, Jennifer L Sent: Wednesday, November 10, 2010 6:23 PM Newsgroups: public.remedy.arsystem.general To: arslist@ARSLIST.ORG Subject: Re: Working as designed type defects ** We reported that Risk Level/Approval Level defect last year, Tim. It's working as designed!And the Close buttons are a royal pain. There is a fix for the missing workflow, but when there just isn't a Close button*that's frustrating. Check out the Object List on the Mid-Tier: no Close, Logout, Home, or New Search. That one drives me up the wall. To log out, you have to search for and open the Home Page, then click Log Out. Jennifer MeyerFrom: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Timothy Powell Sent: Wednesday, November 10, 2010 5:39 PM To: arslist@ARSLIST.ORG Subject: Re: Working as designed type defects ** How about the simple fact that Close buttons and/or links are not always in the same location and sometime are not present at all. In CM, Urgency, Impact and Priority use a scale of 1 * x with 1 being the most severe and x being the least severe. But the Risk Level values run 1-x with 1 being the least severe and x being the most severe. That ISS ticket came back to us as Working as Designed. The reasoning was that a 1-x scale with 1 being the least severe and x being the most gave the customer the opportunity to extend the Risk Level to accommodate custom risk calculations. But if that is the true design reason, then my argument is that Priority, Impact and Urgency should also be designed that way and also allow that extension capability. I'm going to change the ISS ticket to an RFE and see what happens.Like you point out, I just want it to be consistent. Tim From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Meyer, Jennifer L Sent: Wednesday, November 10, 2010 4:50 PM To: arslist@ARSLIST.ORG Subject: Re: Working as designed type defects ** Guillame, I feel your pain. I want to respond, not to gripe about the lack of consistency across applications, but because I also noted this while testing the ITSM 7.6 applications. Tasks perform differently across applications, Problem and Known Error have minimal interaction with Task at all, and Saved Searches aren't consistent in the consoles. This is how it's designed, however, and we are reporting a large number of other defects, so I'm personally hoping that providing consistency across lesser-loved applications is BMC's next focus. Jennifer MeyerRemedy Technical Support SpecialistState of North CarolinaOffice of Information Technology Services Service Delivery Division ITSM ITAM ServicesOffice: 919-754-6543ITS Service Desk: 919-754-6000jennifer.me...@nc.govhttp://its.state.nc.us E-mail correspondence to and from this address may be subject to the North Carolina Public Records Law and may be disclosed to third parties only by an authorized State Official.From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Guillaume Rheault Sent: Wednesday, November 10, 2010 1:54 PM To: arslist@ARSLIST.ORG Subject: Working as designed type defects ** I'm sending this post to the list community to see what is the general feeling about issues that BMC Support classifies as working as designed The category of issues I am referring to specifically here is inconsistencies in functionality between ITSM modules or within a single specific module. More specifically, and to name only a few, in ITSM 7.5.1 but apparently still present in 7.6.3: - Assigned group searches in tasks are different than assigned group searches in change - Assigned group searches, change manager group searches, and change implementer group searches are different - Task tab in problem investigation is different than the task tab
Working as designed type defects
I'm sending this post to the list community to see what is the general feeling about issues that BMC Support classifies as working as designed The category of issues I am referring to specifically here is inconsistencies in functionality between ITSM modules or within a single specific module. More specifically, and to name only a few, in ITSM 7.5.1 but apparently still present in 7.6.3: - Assigned group searches in tasks are different than assigned group searches in change - Assigned group searches, change manager group searches, and change implementer group searches are different - Task tab in problem investigation is different than the task tab in the incident form When I raise these issues with BMC support, I get the reply that it's working as designed. Well the problem with that, is that customization is required to make functionality, and look and feel consistent. It seems to me that BMC should create a Design Defect classification in addition to the existing defect classification, which are essentially implementation defects. I mean why should I need to create an RFE for something that should work consistently in the first place? Seems like Working As Designed is simply an easy way out of the situation. Quality Assurance **should** catch these defects. Is this too much to ask? A defect is a defect because the customer perceives that as a defect, that should be the bottom line. This is not new functionality, only making the functionality and user interface work to the way it is expected. Thoughts? Guillaume ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: Where the Answers Are
Re: Working as designed type defects
Guillame, I feel your pain. I want to respond, not to gripe about the lack of consistency across applications, but because I also noted this while testing the ITSM 7.6 applications. Tasks perform differently across applications, Problem and Known Error have minimal interaction with Task at all, and Saved Searches aren't consistent in the consoles. This is how it's designed, however, and we are reporting a large number of other defects, so I'm personally hoping that providing consistency across lesser-loved applications is BMC's next focus. Jennifer Meyer Remedy Technical Support Specialist State of North Carolina Office of Information Technology Services Service Delivery Division ITSM ITAM Services Office: 919-754-6543 ITS Service Desk: 919-754-6000 jennifer.me...@nc.govmailto:jennifer.me...@nc.gov http://its.state.nc.ushttp://its.state.nc.us/ E-mail correspondence to and from this address may be subject to the North Carolina Public Records Law and may be disclosed to third parties only by an authorized State Official. From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Guillaume Rheault Sent: Wednesday, November 10, 2010 1:54 PM To: arslist@ARSLIST.ORG Subject: Working as designed type defects ** I'm sending this post to the list community to see what is the general feeling about issues that BMC Support classifies as working as designed The category of issues I am referring to specifically here is inconsistencies in functionality between ITSM modules or within a single specific module. More specifically, and to name only a few, in ITSM 7.5.1 but apparently still present in 7.6.3: - Assigned group searches in tasks are different than assigned group searches in change - Assigned group searches, change manager group searches, and change implementer group searches are different - Task tab in problem investigation is different than the task tab in the incident form When I raise these issues with BMC support, I get the reply that it's working as designed. Well the problem with that, is that customization is required to make functionality, and look and feel consistent. It seems to me that BMC should create a Design Defect classification in addition to the existing defect classification, which are essentially implementation defects. I mean why should I need to create an RFE for something that should work consistently in the first place? Seems like Working As Designed is simply an easy way out of the situation. Quality Assurance **should** catch these defects. Is this too much to ask? A defect is a defect because the customer perceives that as a defect, that should be the bottom line. This is not new functionality, only making the functionality and user interface work to the way it is expected. Thoughts? Guillaume _attend WWRUG11 www.wwrug.com ARSlist: Where the Answers Are_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: Where the Answers Are
Re: Working as designed type defects
How about the simple fact that Close buttons and/or links are not always in the same location and sometime are not present at all. In CM, Urgency, Impact and Priority use a scale of 1 - x with 1 being the most severe and x being the least severe. But the Risk Level values run 1-x with 1 being the least severe and x being the most severe. That ISS ticket came back to us as Working as Designed. The reasoning was that a 1-x scale with 1 being the least severe and x being the most gave the customer the opportunity to extend the Risk Level to accommodate custom risk calculations. But if that is the true design reason, then my argument is that Priority, Impact and Urgency should also be designed that way and also allow that extension capability. I'm going to change the ISS ticket to an RFE and see what happens. Like you point out, I just want it to be consistent. Tim From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Meyer, Jennifer L Sent: Wednesday, November 10, 2010 4:50 PM To: arslist@ARSLIST.ORG Subject: Re: Working as designed type defects ** Guillame, I feel your pain. I want to respond, not to gripe about the lack of consistency across applications, but because I also noted this while testing the ITSM 7.6 applications. Tasks perform differently across applications, Problem and Known Error have minimal interaction with Task at all, and Saved Searches aren't consistent in the consoles. This is how it's designed, however, and we are reporting a large number of other defects, so I'm personally hoping that providing consistency across lesser-loved applications is BMC's next focus. Jennifer Meyer Remedy Technical Support Specialist State of North Carolina Office of Information Technology Services Service Delivery Division ITSM ITAM Services Office: 919-754-6543 ITS Service Desk: 919-754-6000 jennifer.me...@nc.gov http://its.state.nc.us/ http://its.state.nc.us E-mail correspondence to and from this address may be subject to the North Carolina Public Records Law and may be disclosed to third parties only by an authorized State Official. From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Guillaume Rheault Sent: Wednesday, November 10, 2010 1:54 PM To: arslist@ARSLIST.ORG Subject: Working as designed type defects ** I'm sending this post to the list community to see what is the general feeling about issues that BMC Support classifies as working as designed The category of issues I am referring to specifically here is inconsistencies in functionality between ITSM modules or within a single specific module. More specifically, and to name only a few, in ITSM 7.5.1 but apparently still present in 7.6.3: - Assigned group searches in tasks are different than assigned group searches in change - Assigned group searches, change manager group searches, and change implementer group searches are different - Task tab in problem investigation is different than the task tab in the incident form When I raise these issues with BMC support, I get the reply that it's working as designed. Well the problem with that, is that customization is required to make functionality, and look and feel consistent. It seems to me that BMC should create a Design Defect classification in addition to the existing defect classification, which are essentially implementation defects. I mean why should I need to create an RFE for something that should work consistently in the first place? Seems like Working As Designed is simply an easy way out of the situation. Quality Assurance **should** catch these defects. Is this too much to ask? A defect is a defect because the customer perceives that as a defect, that should be the bottom line. This is not new functionality, only making the functionality and user interface work to the way it is expected. Thoughts? Guillaume _attend WWRUG11 www.wwrug.com ARSlist: Where the Answers Are_ _attend WWRUG11 www.wwrug.com ARSlist: Where the Answers Are_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: Where the Answers Are
Re: Working as designed type defects
We reported that Risk Level/Approval Level defect last year, Tim. It's working as designed! And the Close buttons are a royal pain. There is a fix for the missing workflow, but when there just isn't a Close button...that's frustrating. Check out the Object List on the Mid-Tier: no Close, Logout, Home, or New Search. That one drives me up the wall. To log out, you have to search for and open the Home Page, then click Log Out. Jennifer Meyer From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Timothy Powell Sent: Wednesday, November 10, 2010 5:39 PM To: arslist@ARSLIST.ORG Subject: Re: Working as designed type defects ** How about the simple fact that Close buttons and/or links are not always in the same location and sometime are not present at all. In CM, Urgency, Impact and Priority use a scale of 1 - x with 1 being the most severe and x being the least severe. But the Risk Level values run 1-x with 1 being the least severe and x being the most severe. That ISS ticket came back to us as Working as Designed. The reasoning was that a 1-x scale with 1 being the least severe and x being the most gave the customer the opportunity to extend the Risk Level to accommodate custom risk calculations. But if that is the true design reason, then my argument is that Priority, Impact and Urgency should also be designed that way and also allow that extension capability. I'm going to change the ISS ticket to an RFE and see what happens. Like you point out, I just want it to be consistent. Tim From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Meyer, Jennifer L Sent: Wednesday, November 10, 2010 4:50 PM To: arslist@ARSLIST.ORG Subject: Re: Working as designed type defects ** Guillame, I feel your pain. I want to respond, not to gripe about the lack of consistency across applications, but because I also noted this while testing the ITSM 7.6 applications. Tasks perform differently across applications, Problem and Known Error have minimal interaction with Task at all, and Saved Searches aren't consistent in the consoles. This is how it's designed, however, and we are reporting a large number of other defects, so I'm personally hoping that providing consistency across lesser-loved applications is BMC's next focus. Jennifer Meyer Remedy Technical Support Specialist State of North Carolina Office of Information Technology Services Service Delivery Division ITSM ITAM Services Office: 919-754-6543 ITS Service Desk: 919-754-6000 jennifer.me...@nc.govmailto:jennifer.me...@nc.gov http://its.state.nc.ushttp://its.state.nc.us/ E-mail correspondence to and from this address may be subject to the North Carolina Public Records Law and may be disclosed to third parties only by an authorized State Official. From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Guillaume Rheault Sent: Wednesday, November 10, 2010 1:54 PM To: arslist@ARSLIST.ORG Subject: Working as designed type defects ** I'm sending this post to the list community to see what is the general feeling about issues that BMC Support classifies as working as designed The category of issues I am referring to specifically here is inconsistencies in functionality between ITSM modules or within a single specific module. More specifically, and to name only a few, in ITSM 7.5.1 but apparently still present in 7.6.3: - Assigned group searches in tasks are different than assigned group searches in change - Assigned group searches, change manager group searches, and change implementer group searches are different - Task tab in problem investigation is different than the task tab in the incident form When I raise these issues with BMC support, I get the reply that it's working as designed. Well the problem with that, is that customization is required to make functionality, and look and feel consistent. It seems to me that BMC should create a Design Defect classification in addition to the existing defect classification, which are essentially implementation defects. I mean why should I need to create an RFE for something that should work consistently in the first place? Seems like Working As Designed is simply an easy way out of the situation. Quality Assurance **should** catch these defects. Is this too much to ask? A defect is a defect because the customer perceives that as a defect, that should be the bottom line. This is not new functionality, only making the functionality and user interface work to the way it is expected. Thoughts? Guillaume _attend WWRUG11 www.wwrug.com ARSlist: Where the Answers Are_ _attend WWRUG11 www.wwrug.com ARSlist: Where the Answers Are_ _attend WWRUG11 www.wwrug.com ARSlist: Where the Answers Are_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList
Re: Working as designed type defects
Alternately you could customize some of the most frequently used forms to have the Logout button that looks the same as the Home Page and drive that button with a Perform-Application-Exit process.. might take some work, but that would give some degree of consistency on where you can find the Logout link/button.. I absolutely agree that it should have been available a little more through the application to maintain some sort of visual as well as functional consistency.. Joe From: Meyer, Jennifer L Sent: Wednesday, November 10, 2010 6:23 PM Newsgroups: public.remedy.arsystem.general To: arslist@ARSLIST.ORG Subject: Re: Working as designed type defects ** We reported that Risk Level/Approval Level defect last year, Tim. It’s working as designed! And the Close buttons are a royal pain. There is a fix for the missing workflow, but when there just isn’t a Close button…that’s frustrating. Check out the Object List on the Mid-Tier: no Close, Logout, Home, or New Search. That one drives me up the wall. To log out, you have to search for and open the Home Page, then click Log Out. Jennifer Meyer From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Timothy Powell Sent: Wednesday, November 10, 2010 5:39 PM To: arslist@ARSLIST.ORG Subject: Re: Working as designed type defects ** How about the simple fact that Close buttons and/or links are not always in the same location and sometime are not present at all. In CM, Urgency, Impact and Priority use a scale of 1 – x with 1 being the most severe and x being the least severe. But the Risk Level values run 1-x with 1 being the least severe and x being the most severe. That ISS ticket came back to us as “Working as Designed”. The reasoning was that a 1-x scale with 1 being the least severe and x being the most gave the customer the opportunity to “extend” the Risk Level to accommodate custom risk calculations. But if that is the true design reason, then my argument is that Priority, Impact and Urgency should also be designed that way and also allow that “extension” capability. I’m going to change the ISS ticket to an RFE and see what happens. Like you point out, I just want it to be consistent. Tim From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Meyer, Jennifer L Sent: Wednesday, November 10, 2010 4:50 PM To: arslist@ARSLIST.ORG Subject: Re: Working as designed type defects ** Guillame, I feel your pain. I want to respond, not to gripe about the lack of consistency across applications, but because I also noted this while testing the ITSM 7.6 applications. Tasks perform differently across applications, Problem and Known Error have minimal interaction with Task at all, and Saved Searches aren’t consistent in the consoles. This is how it’s designed, however, and we are reporting a large number of other defects, so I’m personally hoping that providing consistency across lesser-loved applications is BMC’s next focus. Jennifer Meyer Remedy Technical Support Specialist State of North Carolina Office of Information Technology Services Service Delivery Division ITSM ITAM Services Office: 919-754-6543 ITS Service Desk: 919-754-6000 jennifer.me...@nc.gov http://its.state.nc.us E-mail correspondence to and from this address may be subject to the North Carolina Public Records Law and may be disclosed to third parties only by an authorized State Official. From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Guillaume Rheault Sent: Wednesday, November 10, 2010 1:54 PM To: arslist@ARSLIST.ORG Subject: Working as designed type defects ** I'm sending this post to the list community to see what is the general feeling about issues that BMC Support classifies as working as designed The category of issues I am referring to specifically here is inconsistencies in functionality between ITSM modules or within a single specific module. More specifically, and to name only a few, in ITSM 7.5.1 but apparently still present in 7.6.3: - Assigned group searches in tasks are different than assigned group searches in change - Assigned group searches, change manager group searches, and change implementer group searches are different - Task tab in problem investigation is different than the task tab in the incident form When I raise these issues with BMC support, I get the reply that it's working as designed. Well the problem with that, is that customization is required to make functionality, and look and feel consistent. It seems to me that BMC should create a Design Defect classification in addition to the existing defect classification, which are essentially implementation defects. I mean why should I need to create an RFE for something that should work consistently in the first place? Seems like Working As Designed is simply an easy way out
