Deliverables

[VectraMan]

I know I should know better by now, but everybody talks about having deliverables specified in the contract.

So how does that actually work? If you're a developer, then do you have a specification of a project, or part of a project, and an end date written into the contract? Surely you couldn't have a detailed spec, that would require too much work in forming the contract, and the client might not want to divulge that to a third party (i.e. an agent).

I have sole responsibility for one project, but it's ongoing maintenance and development of features for future releases, not a contract to get to a certain point on a certain date. Am I doomed? Should I be trying to pin down a firm specification and release schedule and get that in writing? And then what happens if I don't meet that schedule?

My previous role, I again had sole responsibility for one project, but in the last few weeks I did help out on another project basically because the client was short staffed and I'd run out of work. I assume that's probably quite bad from an IR35 point of view.

[chicane]

Should I be trying to pin down a firm specification and release schedule and get that in writing?

No, because:

1) The client just wants a bum-on-seater. If you start getting fussy about the way you engage with the client, they will go off and find somebody else who isn't fussy.
2) You don't want to be a victim of scope creep and all the other nasties that come as a result of fixed-price contracts.

I would suggest that you just accept the (very minor) IR35 risks inherent in the way in which the client wishes to engage with you, and get on with the job. The risks to your business of working to fixed deliverables are considerably higher.

[VectraMan]

I would suggest that you just accept the (very minor) IR35 risks inherent in the way in which the client wishes to engage with you, and get on with the job. The risks to your business of working to fixed deliverables are considerably higher.

That's always been my feeling. I'm just curious as to how all the people who talk about having deliverables actually work it.

[where did my id go?]

I've done exactly what you propose.

I did one contract for maintenance/support. renewed on a yearly basis.

Each enhancement / major upgrade/ development was specified and quoted for with a separate Purchase Order or contract for that piece of work.

I was in the situation that it suited the it department i was working for because they also had to provide quotes for the business units for specific bits of work and also an infrastructure charge (a yearly cost per user to have a pc on the desk with the appropriate network/software etc)

I did quite well because what started as oracle support on unix spread to other applications, design work and general consultancy (they were mainly a windows shop and had little unix/rdbms skill)

edit:
I should say that I worked through a small software house rather than a trad agent. I agreed up front with them the daily rate I charged them and the daily rate to the end user - sometimes I billed direct then paid the software house their comission, sometimes I billed the software house and they doubled the cost before billing the end user. I had the conversation about employee vs business up front.

[where did my id go?]

.
2) You don't want to be a victim of scope creep and all the other nasties that come as a result of fixed-price contracts.

Scope creep?

Ahhh, you mean specification changes. Delighted to quote for that. Fill in a change request form or provide a spec and I'll get back to you.

What no spec? I can write one but that's on T&M I'm afraid. Just raise a PO and we'll get started.

[chicane]

Ahhh, you mean specification changes. Delighted to quote for that. Fill in a change request form or provide a spec and I'll get back to you.

What no spec? I can write one but that's on T&M I'm afraid. Just raise a PO and we'll get started.

It might work in the world of big corporates, but try that on with a small business and you'll know the meaning of 'sour business relationship'

[where did my id go?]

It might work in the world of big corporates, but try that on with a small business and you'll know the meaning of 'sour business relationship'

Maybe, but they key point about that is that you are making clear to them that any changes have an impact on the timescale and hence cost. You need to make sure that someone with authority/responsibility knows about the requested change and the impact it will have. There is no such thing as a change that has no impact.

Try putting it in context for them - If their customers started asking for changes or freebies after agreeing a deal how would they feel?

That said I have done 'freebies' for some customers - but only when I understand the requirement, know that it is v.minor and that they know that it is a one off and I'm not going to get involved in continual fiddling.

[chicane]

Maybe, but they key point about that is that you are making clear to them that any changes have an impact on the timescale and hence cost. You need to make sure that someone with authority/responsibility knows about the requested change and the impact it will have. There is no such thing as a change that has no impact.
Try putting it in context for them - If their customers started asking for changes or freebies after agreeing a deal how would they feel?

You are correct in principle, and in an ideal world things would work as you describe. Indeed, this is how things work between, for example, the public sector and EDS which results in the wastage of millions of pounds of taxpayer money.

The biggest problem with fixed time & cost is the difference between what a customer wants prior to commencement of the project, and what they realise they actually want later in the cycle. If it is hard for us as software professionals to get our heads around the complexity of a solution - just imagine how difficult it is for the average business person!

Small businesses don't have money to throw around - they therefore want to be certain that they can accomplish business objective X with exactly Y amount of cash. If you were to be honest up-front about the possibility of extra expenditure resulting from changes later in the cycle, they view this as you "trying it on" and will simply go to another supplier who will not be quite so honest.

The only way I've ever got around this is to allocate a change budget and say something to the client like "The work will cost 10k, but in the event of our understanding of the requirements changing, you may need to be prepared to spend up to 12.5k". Generally speaking, they're ok with this - the potential cost of delivery is variable, but at least it's within a commonly understood range. In theory at least, you can keep within this range by managing/prioritising changes during the course of the project and learning to say "no" to the client when there's a good justification for doing so.

The size of the change budget is derived from the perceived risk of change - this can generally be derived by looking in detail at the personality of the client and how much you're able to hammer down the spec before development work begins.