Reed PS, Beware of their games

[Ardesco]

A termination clause is not the same as a notice period.

[malvolio]

I was making a different point, that as a supplier of IT services it is not in my company's interest to have such uncertainty in the contract, which after all has been let for a fixed period of time

Wrong, wrong, wrong. Apart from anything else, it will have been let on a budgetary amount that the client has expressed as a number of days to keep it simple. And that "uncertainty", as you call it, puts you inside IR35, so it's not that smart a commercial decision.

Work to deliverables for a known sum, that's commercial sense. Working for periods of time leaves you open to early termination and all the grief that entails. Sadly, that's the way the market works for 90% of us, so the best we can do is minimise the potetnial damage - and 2-4 weeks possible lost income is a lot less than losing an IR35 case.

[Generalist]

The common trait among every newbie on this site (and quite a few regulars, sadly) is that they think in terms of contract duration, not contract deliverables.

How many contractors are able to work under (genuinely) deliverable based contracts, i.e. don't get paid a day rate? Very few I would think.

[Generalist]

Ps

How many contractors are able to work under (genuinely) deliverable based contracts, i.e. don't get paid a day rate? Very few I would think.

Malvolio a point you made while I was composing my previous post!

[Ardesco]

How many contractors are able to work under (genuinely) deliverable based contracts, i.e. don't get paid a day rate? Very few I would think.

I think it depends on what you are into. I'm a tester so it makes more sense for me to get a daily rate as the delivery date is largely out of my hands, all I can do is wait for the coders to finish and then find as many problems as possible. I could not sign a contract stating that all testing will be finished by a certain point because it all depends on the quality of the code and if the devs hit thier delivery targets. I could say I will do X number of days of testing and provide a report on how many defects I have found, but if there are loads left the program obviously needs more fixes applied and more testing done to it.

The second problem is that deliverables are largely meaningless from a test point of view. I can sign a document saying I have run through X% of the program and found no more than X errors, however i may not have found the errors, testing doesn't (and will never) find every defect and does not prove that the product works. It just highlights errors so that the dev's can fix them and gives the devs a nice warm glow inside when that annoying tester cant find any more problems with thier code.

There will always be some kid out there that will hit a sequence of keys that will screw the program up somehow...

[malvolio]

True, there are always exceptions. However, you are essentially selling a service, a coder is building a program, I am delivering (hopefully) an installed and operating function. None of them are easily expressed as a number of days effort - the closest is testing, as you say, where you can't give an end-point where testing can be said to be complete, merely a date at which you stop doing it (unless we get into Six Sigma and CMMI, but let's no go there...)

[tim123]

I was making a different point, that as a supplier of IT services it is not in my company's interest to have such uncertainty in the contract,

That is a commercial decision to which most clients will respond "tough titties".

You factor the uncertainty into your costs, that is why (as I said already) you charge 400 (whatever) a day. If you can get away with charging that rate, and dictate terms as well, then IME you are very lucky, you must have a rare skill that is subject to little competition. Most B2B business is not done this way.

tim

[Generalist]

If you can get away with charging that rate, and dictate terms as well, then IME you are very lucky

I can only speak from experience and we're talking agency contracts here mainly, but I have always insisted on and got back to back terms on notice. Forget IR35 for the moment, basically the client wants some assurance that the service will continue to be provided so that their project doesn't get stalled if the contractor walks, and is usually happy to reciprocate. This is common B2B practice - if you contract for a given value there is usually a penalty if you don't take it all.

[Denny]

Once again, a notice period implies mutuality, since you can be paid for doing no work and that, as we all know, is not a good thing, remember?


The common trait among every newbie on this site (and quite a few regulars, sadly) is that they think in terms of contract duration, not contract deliverables. Get over that mental blockage and it all begins to make a lot more sense.

That's right but often it's the clients and EBs that confuse the issue. For B2B contractors operating outside IR35 a daily rate should be there for the benefit of the client to end the agreement swiftly, should that be necessary. It's not for the client to insist on full time working weeks or in essence time spent on the job at all with no expectation that the contractor can fit in other jobs as well and likely to object if they do. The fees, daily or otherwise, really amount for the estimate time the job will take at the start of the contract to finish deliverables which should be specified on a Schedule of Works, but with some latititude for the client to end earlier if the job is done or can't be done instead of being stuck with a huge 6 month bill of daily fees when the job is finished in 5.

Often EBs and end clients see the contract length as if it is full time for hours on the job not for deliverables. So when a contractor says he will accept a full time assignment on a daily fee and wants to be outside IR35 what he should really mean is 'full time' means first priority for that client, not no room to fit in other work around it and still charge the daily rate for same completion of deliverables for the main client. within a specified timeframe.