Reply to: un-usual clauses

[Lance]

In any large or medium sized company the requirements have to be documented somewhere.

So they can come up to you and ask you to do something but either you or they have to as a minimum send an email with what is agreed.

Normally there is some other processes involved which means the requirement is logged elsewhere as well.

or at the very least, as a professional, you document (email) the new requirement so it's not just verbal

[SueEllen]

But in many places, if a client comes up to you with a verbal requirement, they just expect it to be done. Basically I wouldn't want this clause on a contract without a very precise definition of what "defective or otherwise unacceptable" means.

In any large or medium sized company the requirements have to be documented somewhere.

So they can come up to you and ask you to do something but either you or they have to as a minimum send an email with what is agreed.

Normally there is some other processes involved which means the requirement is logged elsewhere as well.

[BR14]

Have you never had a conversation along the lines of "Why does it do that?", "That's what you asked for?", "No I didn't!"?

https://i0.wp.com/www.fressadi.com/b...ize=1024%2C743

[northernladyuk]

I always stick to the mantra of:
- say what I'm going to do (Statement of work)
- do it (the work)
- prove it (testing)

- sign it off

[pauldee]

It is called email.

But in many places, if a client comes up to you with a verbal requirement, they just expect it to be done. Basically I wouldn't want this clause on a contract without a very precise definition of what "defective or otherwise unacceptable" means.

[SueEllen]

Have you never had a conversation along the lines of "Why does it do that?", "That's what you asked for?", "No I didn't!"?

It is called email.

[Lance]

Do what the solution suppliers do, and get code signd off in testing. Once it's signed off, any issues raised become a change request.

I always stick to the mantra of:
- say what I'm going to do (Statement of work)
- do it (the work)
- prove it (testing)

[northernladyuk]

In order to explain a bug there must be a line or lines of code that need to be fixed. Any version control system will tell you who wrote those lines of code, i.e. the customer puts in an order id and the system brings up a user input screen with a completely different order. Clearly that is a bug and should be fixed. There are also problems caused by mistakes in the way the customer used the system. Sometimes the customer will simply ask for an improvement or simply complain what he asks for isn't actually adequate i.e. typically it is a bit slow, however those aren't bugs and can just be refused unless it can be demonstrated that it makes the system unusable.

Do what the solution suppliers do, and get code signd off in testing. Once it's signed off, any issues raised become a change request.

[pauldee]

In order to explain a bug there must be a line or lines of code that need to be fixed. Any version control system will tell you who wrote those lines of code, i.e. the customer puts in an order id and the system brings up a user input screen with a completely different order. Clearly that is a bug and should be fixed. There are also problems caused by mistakes in the way the customer used the system. Sometimes the customer will simply ask for an improvement or simply complain what he asks for isn't actually adequate i.e. typically it is a bit slow, however those aren't bugs and can just be refused unless it can be demonstrated that it makes the system unusable.

Have you never had a conversation along the lines of "Why does it do that?", "That's what you asked for?", "No I didn't!"?

[BlasterBates]

Really? I've experienced significant arguments over this (not me directly, but my client/their client).

Fair point though, if you spend time investigating something and it turns out not to be your fault, you should have a clause in there to invoice them. You're going to need to seriously keep copies of the specification. A lot of clients will try to pass of mis-specification as 'bugs'.

In order to explain a bug there must be a line or lines of code that need to be fixed. Any version control system will tell you who wrote those lines of code, i.e. the customer puts in an order id and the system brings up a user input screen with a completely different order. Clearly that is a bug and should be fixed. There are also problems caused by mistakes in the way the customer used the system. Sometimes the customer will simply ask for an improvement or simply complain what he asks for isn't actually adequate i.e. typically it is a bit slow, however those aren't bugs and can just be refused unless it can be demonstrated that it makes the system unusable.

[pauldee]

It is easy to distinguish a bug caused by you as opposed to a customer's own problem or obvious new requirement which you can then charge out for.

Really? I've experienced significant arguments over this (not me directly, but my client/their client).

Fair point though, if you spend time investigating something and it turns out not to be your fault, you should have a clause in there to invoice them. You're going to need to seriously keep copies of the specification. A lot of clients will try to pass of mis-specification as 'bugs'.

[BlasterBates]

With respect to fixing bugs. I spend a lot of my time investigating problems. It is easy to distinguish a bug caused by you as opposed to a customer's own problem or obvious new requirement which you can then charge out for. I would therefore try and get something in there to that effect, i.e. you'll sort out bugs but you will be paid for unnecessary call outs.

[malvolio]

£145 for a sensible review is probably not a bad outlay if it secures you a multi-thousand pound contract (against which you can reclaim the cost anyway). And with solicitors' fees being what they are I doubt you will find anything cheaper.

The VAT is largely irrelevant if YourCo does all the paying directly, i.e. not by you paying and reclaiming it, since it all works out level in due course.

[Lambert Simnel]

Sounds like the first point potentially leaves you on the hook for any required bug-fixes for a year after leaving, and the third means that you are to let their auditors pop into your house (err, I mean business premises) at any point they fancy in the next three years?

I doubt either would ever come to pass, but personally I'd steer well clear of it.

[diesel]

The last point is the least of your worries.

They want you as a self employed person but under the cloak of your company.

Agree, unlikely I will incurring any business travel expenses with this client, unless it moved to a longer term contract.

any recommendations where one can get a contract reviewed for Legality aspects?