Is it wrong...
-
Unfortunately, with any method, including Agile, this can be a problem. The OP stated the client denies signing off, etc. There is no methodology to deal with lying clients. You should always get a 50% deposit upfront before any work begins.
There are only 10 types of people in the world, those who understand binary and those who don't.
-
...to want to rip the arms off your client and beat them with the bloody appendages? I'd say beat them senseless, but they already are. Four months of requirements, design, coding, testing and multiple review sessions and now, once in production, the client wants a major redesign and flatly refuses to acknowledge sign-off on requirements and design, even denies any meetings or conversations that have taken place regarding the functionality. I'm seriously considering wearing a video camera and microphone any time I'm with the client.
Failure is not an option; it's the default selection.
Been there, done it and got a T-Shirt. :) I don't envy you! Good luck.
VS2010/Atmel Studio 6.0 ToDo Manager Extension
Version 3.0 now available. There is no place like 127.0.0.1 -
Unfortunately, with any method, including Agile, this can be a problem. The OP stated the client denies signing off, etc. There is no methodology to deal with lying clients. You should always get a 50% deposit upfront before any work begins.
There are only 10 types of people in the world, those who understand binary and those who don't.
ryanb31 wrote:
There is no methodology to deal with lying clients.
I think you'll find................[^]
Henry Minute Girl: (staring) "Why do you need an icy cucumber?" “I want to report a fraud. The government is lying to us all.” I wouldn't let CG touch my Abacus! When you're wrestling a gorilla, you don't stop when you're tired, you stop when the gorilla is. Cogito ergo thumb - Sucking my thumb helps me to think.
-
Who said anything about the methodology and would any solve the problem with the user not acknowledging any requirements or design?
Failure is not an option; it's the default selection.
-
ryanb31 wrote:
There is no methodology to deal with lying clients.
I think you'll find................[^]
Henry Minute Girl: (staring) "Why do you need an icy cucumber?" “I want to report a fraud. The government is lying to us all.” I wouldn't let CG touch my Abacus! When you're wrestling a gorilla, you don't stop when you're tired, you stop when the gorilla is. Cogito ergo thumb - Sucking my thumb helps me to think.
-
I agree entirely. If you insist on coding in a waterfall, you're going to run many more risks - including damage to your computer equipment as the water pours into the back of it.
*pre-emptive celebratory nipple tassle jiggle* - Sean Ewington
"Mind bleach! Send me mind bleach!" - Nagy Vilmos
CodeStash - Online Snippet Management | My blog | MoXAML PowerToys | Mole 2010 - debugging made easier
-
Yeah, Agile rescued me from a burning building, cured cancer, gave a loving home to 4 orphans, paid down the national debt, and still had time create a killer app. ...seriously, breakdowns like this can happen everywhere, no matter what process or tools you use. I would recommend that you read "No Silver Bullet" by Frederick Brooks (PDF)[^]
Be The Noise
-
...to want to rip the arms off your client and beat them with the bloody appendages? I'd say beat them senseless, but they already are. Four months of requirements, design, coding, testing and multiple review sessions and now, once in production, the client wants a major redesign and flatly refuses to acknowledge sign-off on requirements and design, even denies any meetings or conversations that have taken place regarding the functionality. I'm seriously considering wearing a video camera and microphone any time I'm with the client.
Failure is not an option; it's the default selection.
-
Unfortunately, with any method, including Agile, this can be a problem. The OP stated the client denies signing off, etc. There is no methodology to deal with lying clients. You should always get a 50% deposit upfront before any work begins.
There are only 10 types of people in the world, those who understand binary and those who don't.
Agreed - don't dispute the OP's view, but the client may have an equally valid view of the world. I was called in to look into a similar situation, and I found that neither "side" was lying. Waterfall requires "sides" and while it works well lots of times, it doesn't guarantee that the parties won't finish up accusing teh other of lying.
-
Who said anything about the methodology and would any solve the problem with the user not acknowledging any requirements or design?
Failure is not an option; it's the default selection.
-
What is not written does not exist. Have you protocolled the meetingsd, and have him signed the specifications ?
Did you read the part about the client refusing to acknowledge the signoff ?
Failure is not an option; it's the default selection.
-
I agree entirely. If you insist on coding in a waterfall, you're going to run many more risks - including damage to your computer equipment as the water pours into the back of it.
*pre-emptive celebratory nipple tassle jiggle* - Sean Ewington
"Mind bleach! Send me mind bleach!" - Nagy Vilmos
CodeStash - Online Snippet Management | My blog | MoXAML PowerToys | Mole 2010 - debugging made easier
-
...to want to rip the arms off your client and beat them with the bloody appendages? I'd say beat them senseless, but they already are. Four months of requirements, design, coding, testing and multiple review sessions and now, once in production, the client wants a major redesign and flatly refuses to acknowledge sign-off on requirements and design, even denies any meetings or conversations that have taken place regarding the functionality. I'm seriously considering wearing a video camera and microphone any time I'm with the client.
Failure is not an option; it's the default selection.
Mark Nischalke wrote:
I'm seriously considering wearing a video camera and microphone any time I'm with the client.
Forget wearing it. Setup one in the corner of the room on a tripod and tell them what it's for. It will seriously keep them VERY honest.
A guide to posting questions on CodeProject[^]
Dave Kreskowiak -
...to want to rip the arms off your client and beat them with the bloody appendages? I'd say beat them senseless, but they already are. Four months of requirements, design, coding, testing and multiple review sessions and now, once in production, the client wants a major redesign and flatly refuses to acknowledge sign-off on requirements and design, even denies any meetings or conversations that have taken place regarding the functionality. I'm seriously considering wearing a video camera and microphone any time I'm with the client.
Failure is not an option; it's the default selection.
Don't you have written minutes of the meetings, email records and tracable sign-off documents with their name on it? If not, that's pretty dumb ... but if they persist in making impossible demands, tell them that if they don't pay you for phase 1 you own the IP and demand that they take the production system down, and walk away from any payment for the next phase.
-
Sorry - maybe you didn't use Waterfall, but I was suggesting the Waterfall type methods that require agreement on requirements can lead to the type of problems you experienced. That is all.
Are you saying that agile does not require or expect requirements or design to be approved? :confused:
Failure is not an option; it's the default selection.
-
Did you read the part about the client refusing to acknowledge the signoff ?
Failure is not an option; it's the default selection.
So the client denies that the signature is his? Or are you talking about a virtual signature?
-
Are you saying that agile does not require or expect requirements or design to be approved? :confused:
Failure is not an option; it's the default selection.
Don't know about Agile, but I'm lucky, my customer is always on my team. He is part of the process. Not everyone can work this way, but having reviewed sign off battles before, I don't work any other way - except, I confess, with some US clients and then I cringe.
-
Read it, and I agree with it. OP seems to believe that agreeing requirments solves the problem - it doesn't.
The OP believes in the client keeping his word, which he didn't. This has nothing to do with anything the OP did wrong or with an methodology. Since the client doesn't want to pay the bill, the only option is to record the entire conversation in video and play it back for them when they get upitty. I very recently went the through the same thing myself with a Vice President. He kept changing the requirements on me on the day of release, after betas, testing and approvals, 4 straight times. When you're deploying the app to 10,000 machines, this gets a bit annoying...
A guide to posting questions on CodeProject[^]
Dave Kreskowiak -
The OP believes in the client keeping his word, which he didn't. This has nothing to do with anything the OP did wrong or with an methodology. Since the client doesn't want to pay the bill, the only option is to record the entire conversation in video and play it back for them when they get upitty. I very recently went the through the same thing myself with a Vice President. He kept changing the requirements on me on the day of release, after betas, testing and approvals, 4 straight times. When you're deploying the app to 10,000 machines, this gets a bit annoying...
A guide to posting questions on CodeProject[^]
Dave KreskowiakOK - but I don't fancy working in an environment where respect, never mind trust, is not present. But then I'm lucky. I have remarked in this thread that I have reviewed disputes of this kind before, and in all three cases, it was a complete breakdown in understanding on both sides - not lying by one side. This may well be different.
-
Your development methodology has no effect whatsoever when your client is a lying sack of dung. They can be 'engaged', and a 'stakeholder', and 'part of the process', but if they decide to stiff you, they're going to do it anyway. The only way I've found to deal with this problem is to bill them often as the work proceeds. If they stop paying, I stop working, and I'm never more than one billing cycle in the hole.
Software Zen:
delete this;
