Spineless
-
Ok, this is more of a rant than a WTF. We have some customers (interestingly always the SAME ones) who do this:
(When I'm working on an software enhancement for them)
Them: We decided we want it to work this way, but after they use it for a few weeks they'll probably change their minds. Can you change it later on if we want?
Me: NOOOOOOOOOOOOOOOOOOOOOO
Of course management always lets them do it. On the one hand, sure it's job security for me. On the other (sane) hand, it makes me want to stomp through Tokyo going "AAAIIIIIAAAAAAAAGHHHH". And *I'm* the unreasonable one. Hmph.
-
I strive to make software in a way that makes (reasonable) changes as easy as possible. Because it generates both customer satisfaction and steady income when changes can be made quickly and relatively cheap. In my experience, predictable change requests after a few weeks are something to expect, something to be prepared for.
-
Better than:
"We don't like how this works."
"Well how you you like it to work?"
"It's your product, figuring that out is your job."
facepalm.
-
@redwards29a said:
You get technical specs that explicit? I envy you."We don't like how this works."
"Well how you you like it to work?"
"It's your product, figuring that out is your job."
-
@ammoQ said:
I strive to make software in a way that makes (reasonable) changes as easy as possible. Because it generates both customer satisfaction and steady income when changes can be made quickly and relatively cheap. In my experience, predictable change requests after a few weeks are something to expect, something to be prepared for.
Change requests after implementation are to be expected, but not necessarily something to be acted upon. Humans are creatures of habit and if you put in a new piece of software that replaces the original, you'll more often than not find that end users want the new one to act exactly like the old one (including the WTFs the new one supposed to avoid). If you want the new software to work exactly like the old software, why are we changing again?
I've seen this behavior on multiple occasions with ERP implementations and it always ends up with a bastardized system where we can't implement new modules cause it is screwed up royally with user exits, misused fields, etc. I personally believe that after any large implementation, there should be a lockdown period of 2-3 months where only bug fixes are addressed - new features are not considered. What you'll find is that after the lockdown period, the fickle change requests have gone away because the users have gotten used to the new system.
-
@lpope187 said:
Change requests after implementation are to be expected, but not necessarily something to be acted upon. Humans are creatures of habit and if you put in a new piece of software that replaces the original, you'll more often than not find that end users want the new one to act exactly like the old one (including the WTFs the new one supposed to avoid). If you want the new software to work exactly like the old software, why are we changing again?
True, and something to be aware of. On the other hand, many change requests are little things that could make users' lifes easier. Something like "I'd like to be able to call form x directly from form y, copying the values of fields a and b as initial values into x". Or "after finishing task x, only fields x,y, and z should be cleared, while a and b keep their values." or "the confirmation dialog in form x is pointless, cut it out".
I've seen this behavior on multiple occasions with ERP implementations and it always ends up with a bastardized system where we can't implement new modules cause it is screwed up royally with user exits, misused fields, etc.
That kind of problem is not uncommon. ERP systems must have an inflexible core that can be updated to a new release later. But that static core induces all kinds of abuse, since features are added in tricky ways instead of changing the core.
-
Our product is based on flexibility and quick customization so in principal it's not a problem for me. When I posted the OP, I was thinking of one specific customer who has a track record. I hate them and the horse they rode in on despite the fact that they're one of our best customers because they make frequent purchases with us. They are the textbook example of a customer who tries to force the system to model their business even when their business changes every week. They're flighty, irrational and completely immune to logic. An example of their typical change request process (until I pitched a fit) is this which actually happened a few years ago:
I wrote a program for them that compared two files containing geographical data. It compared the components of the addresses in each file, for example direction, street name, street type, city, etc. They didn't like the statistical results so asked me to omit comparing the city. A few weeks later they didn't like the statistical results and asked me to include the city. A few weeks later they asked me to omit the city. A few weeks later... etc. So when they asked me "if we don't like this later can we change it?" I started twitching.
-
Oh, and they're also completely immune to education, otherwise I would definitely take the obvious strategy of teaching them how to make their own modifications (after say the first one or two). We've given them several training classes, in person. Not a single thing sunk in. And these are their supposedly "technical" in-house IT people.
-
Two words: Job security. A customer that frequently asks for changes and is not clever enough to learn it for himself might cause a lot of work, but that's what we actually get paid for.
-
@jetcitywoman said:
I wrote a program for them that compared two files containing geographical data. It compared the components of the addresses in each file, for example direction, street name, street type, city, etc. They didn't like the statistical results so asked me to omit comparing the city. A few weeks later they didn't like the statistical results and asked me to include the city. A few weeks later they asked me to omit the city. A few weeks later... etc. So when they asked me "if we don't like this later can we change it?" I started twitching.
That's what a Yes/No dialog is for:
"About to generate statistics, would you like to include the city?" Yes | No
-
Ah yes, great idea! It's a tad oversimplified, though, because in reality it would have to include similar options for every component of the address. And when you extend that from that simple program to their actual production system.... Let me just say that a computer aided dispatching system for a large 911 agency that interfaces to phones, radios, state and federal law enforcement agencies etc etc and requires 99.99% uptime is NOT a good system for this kind of flightiness.
And to the person who mentioned job security: keep in mind that's not the same as job satisfaction. I do support lots of OTHER customers and don't truly have time to honor the whims of this one agency. What they need is competent in-house staff that can do these things for them.
-
@jetcitywoman said:
What they need is competent in-house staff that can do these things for them.
Sounds like a good chance for a side job consulting.
-
You're welcome to it!
-
@jetcitywoman said:
And to the person who mentioned job security: keep in mind that's not the same as job satisfaction. I do support lots of OTHER customers and don't truly have time to honor the whims of this one agency. What they need is competent in-house staff that can do these things for them.
Sounds like you need to charge them more, make it so it's financially viable to learn. ;)
-
Heh, funny story that... about the time of the address-matching fiasco was going on, I was so fed up that I once ranted about them to our customer service manager. He's not in my chain of command, more like a lateral coworker, I guess. Part of the rant was to jokingly say we should bill them for the nearly full-time hours I had spent for the last year on chasing their wild geese. A couple months later, the project manager assigned to this customer was ranting to ME, and related how the CS manager had sent them a bill. The customer (like all the others) pays a yearly software maintenance to us which covers this kind of thing, so sending them another bill was a large no-no. The CS manager got his backside handed to him on a plate. I felt sooooo bad because it was my idea. I had no idea he would act upon it, though. (Lesson learned #405: be careful who you rant to, and about what)
Which kind of relates back to the topic title: our spineless management who lets customers walk all over us. Oh, and a side comment: yearly maintenance fees should cover *reasonable* amounts of tech support. Customers who try to suck your staff into the role of their own full-time help desk should pay extra, IMHO. Either that or the support organization/policies need to be reworked somehow.
-
@jetcitywoman said:
...
Which kind of relates back to the topic title: our spineless management who lets customers walk all over us. Oh, and a side comment: yearly maintenance fees should cover *reasonable* amounts of tech support. Customers who try to suck your staff into the role of their own full-time help desk should pay extra, IMHO. Either that or the support organization/policies need to be reworked somehow.
Are your support prices clearly documented? Would you have scope to increate the charge for that one particular customer? The company I work for was trying to get rid of a customer so upped their rates by 35%, and they ended up paying it!
Yeah, you're right about the 'reasonable' bit, there should always be that kind of clause in contracts, unfortunatly it's a trap a lot of companies get sucked into, desperatly worrying that they might loose a customer whilst ignoring the fact that the financial rewards aren't actually /that/ great. The company I used to work at was a great example, they would always charge very little (otherwise customers might go elsewhere! The horror!!), but then projects would invariably overrun (as we had to do several at once due to not charging enough) and customers would pay even less as we were late.
