Defect, Feature Request, or “Functioning as Designed”

[#1]

When you use a piece of software there are undoubtedly times when you think to yourself, “It’s supposed to do X”, or more likely “It’s not supposed to do that.”  So how do you qualify this behavior?  Would you call it a defect?  Would you say it’s a Feature Request?  What if the developer says it’s functioning as designed?  Maybe it will help to take a look at it this way…

 

You use SalesLogix to tracks widgets (what the heck is a ‘widget’, anyways?).  There's a button that counts how many widgets are in the system.  You know that there are 214 widgets, and verified that is what's in the raw data in the database.  However, when you use the button in the software to get the count, it reports there are 189 widgets in the system. 

è The designed behavior is different than the experienced behavior. This is a Defect in the software.

 

In your company, there absolutely must be two tokens to go with each widget.  You can’t sell a widget without the two tokens, so it’s imperative that you know how many tokens are in the system.  Therefore when you click the button to count the widgets, by default it needs to also display the number of tokens. Because it doesn’t display the number of tokens you consider this to be a product defect. 

è The functionality to count tokens is not part of the software. This would be a Feature Request.

 

In your company, widget can be classified in two distinct categories, “Available” and “Sold Awaiting Delivery”.  SalesLogix Architect allows you to add these categories and display them accordingly.  Your business process requires that report on only those widgets that are Available.  However, when you click the button to count the widgets, it counts every one that is in the system.  Because this gives you an inaccurate picture of how many widgets you have available, you think this is a product defect.

è The count button is designed to count all widgets in the system and does not take into account whether a widget falls into a specific category or not.  This is Functioning as Designed.

 

A key point to remember is that a Feature Request can include a request to change the design.  So if you feel that something is designed poorly, incorrectly, or in such a way that produces inaccurate (or maybe unusable) results, by all means submit an idea to have it considered for a change.  The best place to submit your ideas is right here, in the IdeaLogix forum.

 

[#2]

Paul,

 Got to thinking about the "FAD" (Functioning As Designed) example. Would it not be more appropriate to say:

     Functioning As Implemented (FAI). 

To me, FAD is really a reflection of a Specification rather that the result of a developer's "keystrokes". Under that definition, FAD is really another type of Defect.

[#3]

Paul,

I gave you kudos for your courage in addressing this very sensitive topic. "Functioning As Designed" has to be the most infuriating terminology ever created by IT and you bravely tried to shed some much needed light on the topic.

RJ,

I gave you kudos too because you accurately point out that FAD should probably be considered in a different light and while your FAI may be accurate I prefer an acronym for your "Defect In Specification" (DIS) which can also be considered as an abbreviation for DISconnect! But for now, I will settle on uFAD for "undesirable FAD".

Paul,

In 7.2.2 if I want to *Move* a Contact to another Account I am forced to assign all associated History to another Contact within the departed Account. In essence I am forced to corrupt my data - any user coming back to those History entries will be misled into thinking that they took place with the newly associated Contact when they absolutely did not! Defect or uFAD?

I am told I will have to submit a Feature Request to undo the (corrupting u)FAD feature that found it's way into Production. And you suggest I submit my request into IdeaLogix?

First, you need to look closely at your QA process to determine how puFAD (i.e. painfully ...) finds its way into Production.
Second, whether Defect or Feature Request, a team including developers, BPs and Clients need to determine urgency.
Third, the life cycle of all Feature Requests and Defects should be tracked in a data base with appropriate transparency.

Thanks,
Larry Esposito

[#4]

Hi Larry, thanks for the reply.

I guess with your specific scenario there are a couple of ways to look at it.

1. Lou Balbo get fired form Abbott Limited and goes to work for XYZ Corp.  One would think that in real life someone else in Abbot Limited would pick up where Lou left off?  Or would that pile of paper on Lou's desk just sit there with no one responsible for going through it? (as would be the case in 6.2.6 when the History just sat there at the Account level under the ex-contact's name.)

2. Lou leaves Abbott on amicable terms.  Wouldn't you think again that someone else at Abbot would take over all the ongoing stuff that Lou left behind?  As a salesperson wouldn't you want to know that you could count on Susan to be your contact moving forward?  And wouldn't you want her to have ready access to all the stuff you and Lou worked on in the past?

3. Lou leaves Abbott (for whatever reason) and takes all his history with him.  Ethical?  Is that even our call?

As to the change from 6.2x to 7.x, the newer system has a new requirement that you move the history to a different contact.  That is built into the software now, so yes, the software is FAD.  Was it a good or not-so-good design change?  I'm not the one to answer that question - I'm certain there are very good arguments on both sides of that coin.

Thanks,

Paul

[#5]

Hi Paul,

It has always been my pleasure to philosophize about CRM with you. I wish we could discuss this over a latte at the Village Coffee Roastery but I suppose the SalesLogix Journal will have to do ...

1. So a year later, Lou's boss goes rifling through Lou's replacement's files just like he had done with Lou and finds meeting notes with our company, who Lou's boss hates, so he fires Lou's replacement without even giving her a chance to explain that someone had removed Lou's names from the files and placed her name there instead. She never spoke with our company - Lou did! But really, why are we talking about Lou's company reviewing History? That History is in *our* CRM, not Abbott's and yes I *do* want that History to reflect Lou's name in 6.2 and 7.2 and 8.2 and ...

2. It would be nice if Susan was familiar with Lou's interactions with us and made it clear that she was taking over for him going forward. But wouldn't Susan expect the same from a replacement for *our* Sales Person? How confused would she be if *our* Sales Person sent her a dozen golfballs because he noticed that his predecessor would occasionally meet her on the golf course, or so he thought - SalesLogix had actually forced that predecessor to link all Lou's History to Susan. She hates golf and wonders why Lou would do business with a company that is clearly out of touch with its clients.

3. I'd argue that it is unethical for Lou to take all that History - it belongs to Abbott. And it is equally unethical to replace his name with Susan's on every correspondence. Is it your call? Absolutely not! So why are you making it! Beware of forcing your ethics or business rules on your customers! Try to maintain as much neutrality as possible in your software design and give them the choice to make their own decisions.

So the question remains: who made the puFAD decision to force data corruption with every Contact move? Was it Sage? The BPs? SalesLogix Clients? Is there a QA department that explores potential consequences of new specifications? And most importantly, why aren't you up in arms that one of *your* clients (me) believes that your software is corrupting my data? You know my phone number. Don't you want to get to the bottom of this, or at lease have someone in your company do so? If this was an isolated incident, I'd chalk it up to the nature of the business, but it is not. Sage has left me with pie on my face more than once and I don't support them with management like I used to.

Thanks,
Larry Esposito

[#6]

Paul,

Thanks for following up with me via e-mail and sharing this with your Product Management Group.

Ironically, we've had a recent incident that has legal implications that may serve as a good example of the problems that can arise from the current Move Contact functionality

Yesterday a user asked me how to Move a Contact. I mistakenly told him how but I asked him to send me an e-mail so I can do it since it is problematic. I didn't get to his request immediately and I suppose he wanted to save me the effort so he did it himself.

The problem is that we have a regulatory requirement to identify which Contacts we send certain correspondences to and as you may have guessed while that History was moved with the Contact, a copy was retained with an arbitrarily selected Contact. When you open that Contact, it appears that he was sent these weekly correspondences - he was not! So how do we defend the integrity of our data to our legal department going forward?

I'm not sure if the problem can be demonstrated any simpler than this. I guess my next question is, what follow-up would you recommend in getting this addressed sooner rather than later? Is there any chance that Product Management would get back to me or should I escalate via Edward's team? I had escalated at one point but quickly found a workaround. This recent event suggests I may want to begin escalation again!

Thanks,
Larry