Mixing
Inconsistent Client [closed]
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
-4
down vote
favorite
Is it common in software industry to have a client that is always inconsistent in their word?
Client almost always asks us to change business rules in our app that are not inside Functional Specification (not signed though) and consider them as bugs.
After we done some changes from A to B, this client will ask again to change from B to A, or even worse, from A to B, B to C, then C to A again.
Note:
This does not happen only once, but hundreds in months.
professionalism software-industry clients
asked Jun 26 '16 at 18:08
Lewis
1,29141222
closed as off-topic by Jim G., paparazzo, gnat, HorusKol, Rory Alsop Jun 27 '16 at 13:54
This question appears to be off-topic. The users who voted to close gave this specific reason:
- "Real questions have answers. Rather than explaining why your situation is terrible, or why your boss/coworker makes you unhappy, explain what you want to do to make it better. For more information, click here." – Jim G., paparazzo, gnat, HorusKol, Rory Alsop
suggest improvements |Â
up vote
-4
down vote
favorite
Is it common in software industry to have a client that is always inconsistent in their word?
Client almost always asks us to change business rules in our app that are not inside Functional Specification (not signed though) and consider them as bugs.
After we done some changes from A to B, this client will ask again to change from B to A, or even worse, from A to B, B to C, then C to A again.
Note:
This does not happen only once, but hundreds in months.
professionalism software-industry clients
asked Jun 26 '16 at 18:08
Lewis
1,29141222
closed as off-topic by Jim G., paparazzo, gnat, HorusKol, Rory Alsop Jun 27 '16 at 13:54
This question appears to be off-topic. The users who voted to close gave this specific reason:
- "Real questions have answers. Rather than explaining why your situation is terrible, or why your boss/coworker makes you unhappy, explain what you want to do to make it better. For more information, click here." – Jim G., paparazzo, gnat, HorusKol, Rory Alsop
Some times they think they need to change stuff just so they are participating. I say listen let's get the whole thing working and tested per the specification. Then you can list any changes and I will provide a quote. Not a valid question in my opinion. Voting to close.
– paparazzo
Jun 26 '16 at 18:41
3
Chances are, they didn't know their requirements when the functional specification was written - or couldn't understand how to express their business rules into such a document. And yes, this happens all the time.
– HorusKol
Jun 26 '16 at 22:23
Did you check this topic on programmers stackexchange? Search for 'changing requirements'.
– Brandin
Jun 27 '16 at 0:05
suggest improvements |Â
up vote
-4
down vote
favorite
up vote
-4
down vote
favorite
Is it common in software industry to have a client that is always inconsistent in their word?
Client almost always asks us to change business rules in our app that are not inside Functional Specification (not signed though) and consider them as bugs.
After we done some changes from A to B, this client will ask again to change from B to A, or even worse, from A to B, B to C, then C to A again.
Note:
This does not happen only once, but hundreds in months.
professionalism software-industry clients
asked Jun 26 '16 at 18:08
Lewis
1,29141222
Is it common in software industry to have a client that is always inconsistent in their word?
Client almost always asks us to change business rules in our app that are not inside Functional Specification (not signed though) and consider them as bugs.
After we done some changes from A to B, this client will ask again to change from B to A, or even worse, from A to B, B to C, then C to A again.
Note:
This does not happen only once, but hundreds in months.
professionalism software-industry clients
asked Jun 26 '16 at 18:08
Lewis
1,29141222
asked Jun 26 '16 at 18:08
Lewis
1,29141222
asked Jun 26 '16 at 18:08
Lewis
1,29141222
asked Jun 26 '16 at 18:08
Lewis
1,29141222
1,29141222
closed as off-topic by Jim G., paparazzo, gnat, HorusKol, Rory Alsop Jun 27 '16 at 13:54
This question appears to be off-topic. The users who voted to close gave this specific reason:
- "Real questions have answers. Rather than explaining why your situation is terrible, or why your boss/coworker makes you unhappy, explain what you want to do to make it better. For more information, click here." – Jim G., paparazzo, gnat, HorusKol, Rory Alsop
closed as off-topic by Jim G., paparazzo, gnat, HorusKol, Rory Alsop Jun 27 '16 at 13:54
This question appears to be off-topic. The users who voted to close gave this specific reason:
- "Real questions have answers. Rather than explaining why your situation is terrible, or why your boss/coworker makes you unhappy, explain what you want to do to make it better. For more information, click here." – Jim G., paparazzo, gnat, HorusKol, Rory Alsop
Some times they think they need to change stuff just so they are participating. I say listen let's get the whole thing working and tested per the specification. Then you can list any changes and I will provide a quote. Not a valid question in my opinion. Voting to close.
– paparazzo
Jun 26 '16 at 18:41
3
Chances are, they didn't know their requirements when the functional specification was written - or couldn't understand how to express their business rules into such a document. And yes, this happens all the time.
– HorusKol
Jun 26 '16 at 22:23
Did you check this topic on programmers stackexchange? Search for 'changing requirements'.
– Brandin
Jun 27 '16 at 0:05
suggest improvements |Â
Some times they think they need to change stuff just so they are participating. I say listen let's get the whole thing working and tested per the specification. Then you can list any changes and I will provide a quote. Not a valid question in my opinion. Voting to close.
– paparazzo
Jun 26 '16 at 18:41
3
Chances are, they didn't know their requirements when the functional specification was written - or couldn't understand how to express their business rules into such a document. And yes, this happens all the time.
– HorusKol
Jun 26 '16 at 22:23
Did you check this topic on programmers stackexchange? Search for 'changing requirements'.
– Brandin
Jun 27 '16 at 0:05
Some times they think they need to change stuff just so they are participating. I say listen let's get the whole thing working and tested per the specification. Then you can list any changes and I will provide a quote. Not a valid question in my opinion. Voting to close.
– paparazzo
Jun 26 '16 at 18:41
Some times they think they need to change stuff just so they are participating. I say listen let's get the whole thing working and tested per the specification. Then you can list any changes and I will provide a quote. Not a valid question in my opinion. Voting to close.
– paparazzo
Jun 26 '16 at 18:41
3
3
Chances are, they didn't know their requirements when the functional specification was written - or couldn't understand how to express their business rules into such a document. And yes, this happens all the time.
– HorusKol
Jun 26 '16 at 22:23
Chances are, they didn't know their requirements when the functional specification was written - or couldn't understand how to express their business rules into such a document. And yes, this happens all the time.
– HorusKol
Jun 26 '16 at 22:23
Did you check this topic on programmers stackexchange? Search for 'changing requirements'.
– Brandin
Jun 27 '16 at 0:05
Did you check this topic on programmers stackexchange? Search for 'changing requirements'.
– Brandin
Jun 27 '16 at 0:05
suggest improvements |Â
4 Answers
4
active
oldest
votes
up vote
2
down vote
I suspect the answer is "no" - because most people wouldn't work to a specification that hasn't been signed off by the customer.
You should be getting the customer to sign off the specification as part of the contract negotiation. After that, any specification changes are chargeable extras.
answered Jun 26 '16 at 21:23
Simon B
2,5422716
Nice in theory, excellent way to ensure no further business from that customer in practice.
– Carson63000
Jun 27 '16 at 2:00
suggest improvements |Â
up vote
2
down vote
Sometimes the client simply doesn't know how to get what they need, and it becomes a real mess.
A real business situation I dealt with is a client sending in data in various date formats (US based, MMM-DD-YYYY, MMMM-DD-YYYY, MM-DD-YYYY, MM-DD-YY, M-D-YYYY, M-D-YY). It changes every, single, day, and causes production error every time. They tried changing the specifications to deal with what they think they can stick with, but they just couldn't remember their own chosen format.
What I did was make a system that handled every US format available in Excel (that's the source of the problem). Took about 4 hours to code, but I made it, and no production errors since. The client would have never had the balls to ask us to support 6 date formats, and we probably wouldn't think it would only take me 4 hours to complete.
answered Jun 27 '16 at 1:25
Nelson
3,21921225
It could also be the client doesn't understand the impact of changes between systems or between users. Ex user A might input it as MM-DD-YY but user B might like reading it as MMM-DD-YY but doesn't know or understand the impact of changes required. You as a developer should know the impact.
– Dan
Jun 28 '16 at 16:57
suggest improvements |Â
up vote
0
down vote
I'm ashamed to admit that I've done that (From A to B to C to A) many times when I was on the client side. The reason, more than stupidity or craziness, is that often on the client side it's only when they see the application live that they can comment. Also, the client often doesn't know how much time it takes to integrate the changes he/she requires. It's good to explain him/her the consequences of the changes he/she requests and to charge for them when they are requesting more than 10 minutes work, for example.
answered Jun 26 '16 at 22:00
Serena De Maio
1
suggest improvements |Â
up vote
0
down vote
It's common enough, but only when both sides don't know what they're doing.
Clients are clients, you get all sorts. But the business is making the biggest mistake by not having a clear cut plan to be stuck with agreed and signed off, with everything else as extra billable costs.
With that in place, clients think a bit harder before they make changes, because it costs them money.
If they're willing to pay then it makes no difference, they can make as many silly changes as they want, it's all revenue.
answered Jun 27 '16 at 4:19
Kilisi
94.4k50216374
suggest improvements |Â
4 Answers
4
active
oldest
votes
4 Answers
4
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
2
down vote
I suspect the answer is "no" - because most people wouldn't work to a specification that hasn't been signed off by the customer.
You should be getting the customer to sign off the specification as part of the contract negotiation. After that, any specification changes are chargeable extras.
answered Jun 26 '16 at 21:23
Simon B
2,5422716
Nice in theory, excellent way to ensure no further business from that customer in practice.
– Carson63000
Jun 27 '16 at 2:00
suggest improvements |Â
up vote
2
down vote
I suspect the answer is "no" - because most people wouldn't work to a specification that hasn't been signed off by the customer.
You should be getting the customer to sign off the specification as part of the contract negotiation. After that, any specification changes are chargeable extras.
answered Jun 26 '16 at 21:23
Simon B
2,5422716
Nice in theory, excellent way to ensure no further business from that customer in practice.
– Carson63000
Jun 27 '16 at 2:00
suggest improvements |Â
up vote
2
down vote
up vote
2
down vote
I suspect the answer is "no" - because most people wouldn't work to a specification that hasn't been signed off by the customer.
You should be getting the customer to sign off the specification as part of the contract negotiation. After that, any specification changes are chargeable extras.
answered Jun 26 '16 at 21:23
Simon B
2,5422716
I suspect the answer is "no" - because most people wouldn't work to a specification that hasn't been signed off by the customer.
You should be getting the customer to sign off the specification as part of the contract negotiation. After that, any specification changes are chargeable extras.
answered Jun 26 '16 at 21:23
Simon B
2,5422716
answered Jun 26 '16 at 21:23
Simon B
2,5422716
answered Jun 26 '16 at 21:23
Simon B
2,5422716
answered Jun 26 '16 at 21:23
Simon B
2,5422716
2,5422716
Nice in theory, excellent way to ensure no further business from that customer in practice.
– Carson63000
Jun 27 '16 at 2:00
suggest improvements |Â
Nice in theory, excellent way to ensure no further business from that customer in practice.
– Carson63000
Jun 27 '16 at 2:00
Nice in theory, excellent way to ensure no further business from that customer in practice.
– Carson63000
Jun 27 '16 at 2:00
Nice in theory, excellent way to ensure no further business from that customer in practice.
– Carson63000
Jun 27 '16 at 2:00
suggest improvements |Â
up vote
2
down vote
Sometimes the client simply doesn't know how to get what they need, and it becomes a real mess.
A real business situation I dealt with is a client sending in data in various date formats (US based, MMM-DD-YYYY, MMMM-DD-YYYY, MM-DD-YYYY, MM-DD-YY, M-D-YYYY, M-D-YY). It changes every, single, day, and causes production error every time. They tried changing the specifications to deal with what they think they can stick with, but they just couldn't remember their own chosen format.
What I did was make a system that handled every US format available in Excel (that's the source of the problem). Took about 4 hours to code, but I made it, and no production errors since. The client would have never had the balls to ask us to support 6 date formats, and we probably wouldn't think it would only take me 4 hours to complete.
answered Jun 27 '16 at 1:25
Nelson
3,21921225
It could also be the client doesn't understand the impact of changes between systems or between users. Ex user A might input it as MM-DD-YY but user B might like reading it as MMM-DD-YY but doesn't know or understand the impact of changes required. You as a developer should know the impact.
– Dan
Jun 28 '16 at 16:57
suggest improvements |Â
up vote
2
down vote
Sometimes the client simply doesn't know how to get what they need, and it becomes a real mess.
A real business situation I dealt with is a client sending in data in various date formats (US based, MMM-DD-YYYY, MMMM-DD-YYYY, MM-DD-YYYY, MM-DD-YY, M-D-YYYY, M-D-YY). It changes every, single, day, and causes production error every time. They tried changing the specifications to deal with what they think they can stick with, but they just couldn't remember their own chosen format.
What I did was make a system that handled every US format available in Excel (that's the source of the problem). Took about 4 hours to code, but I made it, and no production errors since. The client would have never had the balls to ask us to support 6 date formats, and we probably wouldn't think it would only take me 4 hours to complete.
answered Jun 27 '16 at 1:25
Nelson
3,21921225
It could also be the client doesn't understand the impact of changes between systems or between users. Ex user A might input it as MM-DD-YY but user B might like reading it as MMM-DD-YY but doesn't know or understand the impact of changes required. You as a developer should know the impact.
– Dan
Jun 28 '16 at 16:57
suggest improvements |Â
up vote
2
down vote
up vote
2
down vote
Sometimes the client simply doesn't know how to get what they need, and it becomes a real mess.
A real business situation I dealt with is a client sending in data in various date formats (US based, MMM-DD-YYYY, MMMM-DD-YYYY, MM-DD-YYYY, MM-DD-YY, M-D-YYYY, M-D-YY). It changes every, single, day, and causes production error every time. They tried changing the specifications to deal with what they think they can stick with, but they just couldn't remember their own chosen format.
What I did was make a system that handled every US format available in Excel (that's the source of the problem). Took about 4 hours to code, but I made it, and no production errors since. The client would have never had the balls to ask us to support 6 date formats, and we probably wouldn't think it would only take me 4 hours to complete.
answered Jun 27 '16 at 1:25
Nelson
3,21921225
Sometimes the client simply doesn't know how to get what they need, and it becomes a real mess.
A real business situation I dealt with is a client sending in data in various date formats (US based, MMM-DD-YYYY, MMMM-DD-YYYY, MM-DD-YYYY, MM-DD-YY, M-D-YYYY, M-D-YY). It changes every, single, day, and causes production error every time. They tried changing the specifications to deal with what they think they can stick with, but they just couldn't remember their own chosen format.
What I did was make a system that handled every US format available in Excel (that's the source of the problem). Took about 4 hours to code, but I made it, and no production errors since. The client would have never had the balls to ask us to support 6 date formats, and we probably wouldn't think it would only take me 4 hours to complete.
answered Jun 27 '16 at 1:25
Nelson
3,21921225
answered Jun 27 '16 at 1:25
Nelson
3,21921225
answered Jun 27 '16 at 1:25
Nelson
3,21921225
answered Jun 27 '16 at 1:25
Nelson
3,21921225
3,21921225
It could also be the client doesn't understand the impact of changes between systems or between users. Ex user A might input it as MM-DD-YY but user B might like reading it as MMM-DD-YY but doesn't know or understand the impact of changes required. You as a developer should know the impact.
– Dan
Jun 28 '16 at 16:57
suggest improvements |Â
It could also be the client doesn't understand the impact of changes between systems or between users. Ex user A might input it as MM-DD-YY but user B might like reading it as MMM-DD-YY but doesn't know or understand the impact of changes required. You as a developer should know the impact.
– Dan
Jun 28 '16 at 16:57
It could also be the client doesn't understand the impact of changes between systems or between users. Ex user A might input it as MM-DD-YY but user B might like reading it as MMM-DD-YY but doesn't know or understand the impact of changes required. You as a developer should know the impact.
– Dan
Jun 28 '16 at 16:57
It could also be the client doesn't understand the impact of changes between systems or between users. Ex user A might input it as MM-DD-YY but user B might like reading it as MMM-DD-YY but doesn't know or understand the impact of changes required. You as a developer should know the impact.
– Dan
Jun 28 '16 at 16:57
suggest improvements |Â
up vote
0
down vote
I'm ashamed to admit that I've done that (From A to B to C to A) many times when I was on the client side. The reason, more than stupidity or craziness, is that often on the client side it's only when they see the application live that they can comment. Also, the client often doesn't know how much time it takes to integrate the changes he/she requires. It's good to explain him/her the consequences of the changes he/she requests and to charge for them when they are requesting more than 10 minutes work, for example.
answered Jun 26 '16 at 22:00
Serena De Maio
1
suggest improvements |Â
up vote
0
down vote
I'm ashamed to admit that I've done that (From A to B to C to A) many times when I was on the client side. The reason, more than stupidity or craziness, is that often on the client side it's only when they see the application live that they can comment. Also, the client often doesn't know how much time it takes to integrate the changes he/she requires. It's good to explain him/her the consequences of the changes he/she requests and to charge for them when they are requesting more than 10 minutes work, for example.
answered Jun 26 '16 at 22:00
Serena De Maio
1
suggest improvements |Â
up vote
0
down vote
up vote
0
down vote
I'm ashamed to admit that I've done that (From A to B to C to A) many times when I was on the client side. The reason, more than stupidity or craziness, is that often on the client side it's only when they see the application live that they can comment. Also, the client often doesn't know how much time it takes to integrate the changes he/she requires. It's good to explain him/her the consequences of the changes he/she requests and to charge for them when they are requesting more than 10 minutes work, for example.
answered Jun 26 '16 at 22:00
Serena De Maio
1
I'm ashamed to admit that I've done that (From A to B to C to A) many times when I was on the client side. The reason, more than stupidity or craziness, is that often on the client side it's only when they see the application live that they can comment. Also, the client often doesn't know how much time it takes to integrate the changes he/she requires. It's good to explain him/her the consequences of the changes he/she requests and to charge for them when they are requesting more than 10 minutes work, for example.
answered Jun 26 '16 at 22:00
Serena De Maio
1
answered Jun 26 '16 at 22:00
Serena De Maio
1
answered Jun 26 '16 at 22:00
Serena De Maio
1
answered Jun 26 '16 at 22:00
Serena De Maio
1
1
suggest improvements |Â
suggest improvements |Â
up vote
0
down vote
It's common enough, but only when both sides don't know what they're doing.
Clients are clients, you get all sorts. But the business is making the biggest mistake by not having a clear cut plan to be stuck with agreed and signed off, with everything else as extra billable costs.
With that in place, clients think a bit harder before they make changes, because it costs them money.
If they're willing to pay then it makes no difference, they can make as many silly changes as they want, it's all revenue.
answered Jun 27 '16 at 4:19
Kilisi
94.4k50216374
suggest improvements |Â
up vote
0
down vote
It's common enough, but only when both sides don't know what they're doing.
Clients are clients, you get all sorts. But the business is making the biggest mistake by not having a clear cut plan to be stuck with agreed and signed off, with everything else as extra billable costs.
With that in place, clients think a bit harder before they make changes, because it costs them money.
If they're willing to pay then it makes no difference, they can make as many silly changes as they want, it's all revenue.
answered Jun 27 '16 at 4:19
Kilisi
94.4k50216374
suggest improvements |Â
up vote
0
down vote
up vote
0
down vote
It's common enough, but only when both sides don't know what they're doing.
Clients are clients, you get all sorts. But the business is making the biggest mistake by not having a clear cut plan to be stuck with agreed and signed off, with everything else as extra billable costs.
With that in place, clients think a bit harder before they make changes, because it costs them money.
If they're willing to pay then it makes no difference, they can make as many silly changes as they want, it's all revenue.
answered Jun 27 '16 at 4:19
Kilisi
94.4k50216374
It's common enough, but only when both sides don't know what they're doing.
Clients are clients, you get all sorts. But the business is making the biggest mistake by not having a clear cut plan to be stuck with agreed and signed off, with everything else as extra billable costs.
With that in place, clients think a bit harder before they make changes, because it costs them money.
If they're willing to pay then it makes no difference, they can make as many silly changes as they want, it's all revenue.
answered Jun 27 '16 at 4:19
Kilisi
94.4k50216374
answered Jun 27 '16 at 4:19
Kilisi
94.4k50216374
answered Jun 27 '16 at 4:19
Kilisi
94.4k50216374
answered Jun 27 '16 at 4:19
Kilisi
94.4k50216374
94.4k50216374
suggest improvements |Â
suggest improvements |Â
Some times they think they need to change stuff just so they are participating. I say listen let's get the whole thing working and tested per the specification. Then you can list any changes and I will provide a quote. Not a valid question in my opinion. Voting to close.
– paparazzo
Jun 26 '16 at 18:41
3
Chances are, they didn't know their requirements when the functional specification was written - or couldn't understand how to express their business rules into such a document. And yes, this happens all the time.
– HorusKol
Jun 26 '16 at 22:23
Did you check this topic on programmers stackexchange? Search for 'changing requirements'.
– Brandin
Jun 27 '16 at 0:05