IT guys - when the client knows you cant prove something
Discussion
Hi all,
I work in an IT Consultancy. Requirements in software engineering are of course paramount.
With one client, they know we implemented the system badly (originally) and they know we have no documentation. So when we claim that what they think is a bug (Fix) is a change request (thus billed differently etc), they will state this is what they asked for originally but they know that as we have no docs, we have to prove it (which we can't).
Of course, this means we lose money etc. Is there a way to avoid this "deadlock"?
Thanks
I work in an IT Consultancy. Requirements in software engineering are of course paramount.
With one client, they know we implemented the system badly (originally) and they know we have no documentation. So when we claim that what they think is a bug (Fix) is a change request (thus billed differently etc), they will state this is what they asked for originally but they know that as we have no docs, we have to prove it (which we can't).
Of course, this means we lose money etc. Is there a way to avoid this "deadlock"?
Thanks
There is absolutely no specs, user guides or sign offs?
Nothing signed off from the original release of the system at all?
Test plans, issues logs, feasibility reports, prototypes, proposal documents, nothing?
What about email chains or anything email related?
If not, then sorry to say you are s
t out of luck and to be honest your company deserves it.
Nothing signed off from the original release of the system at all?
Test plans, issues logs, feasibility reports, prototypes, proposal documents, nothing?
What about email chains or anything email related?
If not, then sorry to say you are s
t out of luck and to be honest your company deserves it.On a side note, who is claiming its a CR instead of a bug fix?
If your person claiming its a CR, then surely they have evidence to back this up, rather than simply say the client is wrong and your company is right?
Still quite stunned you can have a system released to a customer and support it, but have no documentation at all.
If your person claiming its a CR, then surely they have evidence to back this up, rather than simply say the client is wrong and your company is right?
Still quite stunned you can have a system released to a customer and support it, but have no documentation at all.
Create the documentation for currently design functionality. Ask customer to review and agree to it? Of course this risks them coming back to you claiming you didn't deliver other requirements, however, if they don't then at least you have a new 'baseline' to bug/cr requests against.
As above though there must be something 'documented' - emails, minutes etc?!
As above though there must be something 'documented' - emails, minutes etc?!
Du1point8 said:
You are s
t out of luck and to be honest your company deserves it.
This.
t out of luck and to be honest your company deserves it.On a more helpful note, look at the payment milestones agreed in the contract - there MUST be an agreement of "Deliver X, Get paid £Y".
Acceptance into service?
Customer signoff\payment?
Overall, look at the contracts side of it. You HAVE to get to a baseline position, or you will NEVER be free of this situation. I'd be tempted to turn it back on them and ask them to show you the agreed requirements document that shows the CR is in fact originally requested functionality. An email trail will do.
And stop delivering changes until this is sorted out. They're taking you for mugs.
(Also, go read some ITIL.)
shtu said:
Du1point8 said:
You are s
t out of luck and to be honest your company deserves it.
This.
t out of luck and to be honest your company deserves it.On a more helpful note, look at the payment milestones agreed in the contract - there MUST be an agreement of "Deliver X, Get paid £Y".
Acceptance into service?
Customer signoff\payment?
Overall, look at the contracts side of it. You HAVE to get to a baseline position, or you will NEVER be free of this situation. I'd be tempted to turn it back on them and ask them to show you the agreed requirements document that shows the CR is in fact originally requested functionality. An email trail will do.
And stop delivering changes until this is sorted out. They're taking you for mugs.
(Also, go read some ITIL.)

Du1point8 said:
There is absolutely no specs, user guides or sign offs?
Nothing signed off from the original release of the system at all?
Test plans, issues logs, feasibility reports, prototypes, proposal documents, nothing?
What about email chains or anything email related?
If not, then sorry to say you are s
t out of luck and to be honest your company deserves it.
Pretty much, no. This was a project done under naivety and bad management. Email chains would be very hard to find as this was 5 yrs+.Nothing signed off from the original release of the system at all?
Test plans, issues logs, feasibility reports, prototypes, proposal documents, nothing?
What about email chains or anything email related?
If not, then sorry to say you are s
t out of luck and to be honest your company deserves it.As previously mentioned, your company are a bit silly for putting themselves in this position. If you had some kind of agreement as to what should have been delivered, the resolution would be very simple to determine.
In this case, I think you'd need to take a few things in to account such as how effort/cost would be required to put it right, have other customers asked for it or have the same configuration etc etc.
If the change can be implemented and the associated management to SIGN IT OFF within a reasonable threshold and there is resource available, I'd be inclined to just do it, it was implemented badly in the first place so all you could do to put it right should have been done by now.
If what they are asking for would ultimately be resource hungry and costly, it is still your fault you're in this position, I'd be inclined to obtain some kind of compromise. Tell them the work is chargeable but offer them a better rate or throw in some other changes they are after also. While I still maintain that your company is the professional in this relationship so should have led the process once you'd engaged with them, I am quite surprised that they cannot provide any record of them asking for whatever has prompted this dispute. Lesson learned on both counts I think!
In this case, I think you'd need to take a few things in to account such as how effort/cost would be required to put it right, have other customers asked for it or have the same configuration etc etc.
If the change can be implemented and the associated management to SIGN IT OFF within a reasonable threshold and there is resource available, I'd be inclined to just do it, it was implemented badly in the first place so all you could do to put it right should have been done by now.
If what they are asking for would ultimately be resource hungry and costly, it is still your fault you're in this position, I'd be inclined to obtain some kind of compromise. Tell them the work is chargeable but offer them a better rate or throw in some other changes they are after also. While I still maintain that your company is the professional in this relationship so should have led the process once you'd engaged with them, I am quite surprised that they cannot provide any record of them asking for whatever has prompted this dispute. Lesson learned on both counts I think!
You need to either agree a plan to close this down or get out.
I assume you are still doing work because some form of contract exists? What are the break clauses because it may be simpler/cheaper to tell them to do one. Yes, you lose a customer but they sound like a cost not a stream of revenue.
I have had a customer where the requirements were not nailed down sufficiently (although better than this) someone higher up the food chain made a few concessions and the customer proceeded to take the proverbial. It would have been cheaper for us to give them £100k and tell them to fk off at the RFP stage.
I assume you are still doing work because some form of contract exists? What are the break clauses because it may be simpler/cheaper to tell them to do one. Yes, you lose a customer but they sound like a cost not a stream of revenue.
I have had a customer where the requirements were not nailed down sufficiently (although better than this) someone higher up the food chain made a few concessions and the customer proceeded to take the proverbial. It would have been cheaper for us to give them £100k and tell them to fk off at the RFP stage.
I'd consider turning this round.
"This is a CR for the works requested. If you believe this was originally requested functionality, 5 years after implementation, you need to prove it. If you don't like that, see you in court."
As a business, growing a pair is required, right at the top. Bear in mind that as above, sacking a customer that is costing the business money is not a bad thing. I *cannot* believe they are profitable.
"This is a CR for the works requested. If you believe this was originally requested functionality, 5 years after implementation, you need to prove it. If you don't like that, see you in court."
As a business, growing a pair is required, right at the top. Bear in mind that as above, sacking a customer that is costing the business money is not a bad thing. I *cannot* believe they are profitable.
shtu said:
I'd consider turning this round.
"This is a CR for the works requested. If you believe this was originally requested functionality, 5 years after implementation, you need to prove it. If you don't like that, see you in court."
As a business, growing a pair is required, right at the top. Bear in mind that as above, sacking a customer that is costing the business money is not a bad thing. I *cannot* believe they are profitable.
This."This is a CR for the works requested. If you believe this was originally requested functionality, 5 years after implementation, you need to prove it. If you don't like that, see you in court."
As a business, growing a pair is required, right at the top. Bear in mind that as above, sacking a customer that is costing the business money is not a bad thing. I *cannot* believe they are profitable.
Gassing Station | Jobs & Employment Matters | Top of Page | What's New | My Stuff


