Urgent: Fixed Price Contract question

**malvolio** · 21 March 2011, 13:04

Originally posted by Amar View Post

Hi Guys,

I am being offered a contract which is a Fixed Price Contract. I am currently a permie and going back into contracting. Previously I was using an umbrella company but now I want to go LTD. I am a software developer so the contract will be for the development of a new software. I dont like the idea of fixed term and fixed price for software development so Could someone please help me understand how this works in IT related contracts?

Can you please tell me what is involved in Fixed Price Contract and what I need to look out for?

Any specific insurances I should take out before starting the contract etc?

Many Thanks.

You write the software, they approve it you get paid. Doesn't matter how long it takes (in theory), you get paid the same amount, so the trick is to write it quickly and get a better effective day rate. However:

1. Ensure you have some kind of deliverables-based stage payments if you want to earn while you're working

2. Make sure the acceptance and quality criteria are fully estabished and agreed by both sides

3. Ditto payment terms.

4. Ensure you sort your IPR and when, if ever, this is handed over to the client - ideally on full and final settlement.

PCG do a suitable template contract with explanatory notes if you're a member (and if you're not why not?

) which may help.

**Amar** · 21 March 2011, 13:27

Thanks for the reply,

I guessed that much from the name but you have cleared few things. Does a typical fixed rate contract contain a deadline and penalties? I am not sure whether the client is trying to just keep their costs down by offering the fixed rate contract as I previously contracted with them on a daily rate and due to not my fault the project overran.

Anything special I should watch out for when accepting a fixed rate contract? What do you mean by IPR, If i get paid at the end or throughout then doesn't the client owns the software?

Thanks for the PCG tip, going to register now.

**malvolio** · 21 March 2011, 13:48

Originally posted by Amar View Post

Thanks for the reply,

I guessed that much from the name but you have cleared few things. Does a typical fixed rate contract contain a deadline and penalties? I am not sure whether the client is trying to just keep their costs down by offering the fixed rate contract as I previously contracted with them on a daily rate and due to not my fault the project overran.

Anything special I should watch out for when accepting a fixed rate contract? What do you mean by IPR, If i get paid at the end or throughout then doesn't the client owns the software?

Thanks for the PCG tip, going to register now.

They'[re offering fixed rate to control their own costs; they know the cost before they start, which always appeals to the accountants. AS I said, deadline and penalties are up for negotiation, make sure you have them settled before signing anything.

Intellectual Property Rights (IPR) are about who owns the code. You don't want them to have a working copy for final test, decide it's not fit for purpose and pay you off (possibly with penalties), then complete the code themselves. Until IPR is signed over, it remains your property an d they can't use it without your express permission. If it's a one-off, then it's OK to sign IPR over on completion, but if it's something that you may want to develop further, or sell to someone else,or offer ongoing maintenance on, then you need to keep the IPR.

If you join the PCG, get on to their Legal and Accounting fora and ask questions there. There are plenty of people who have done this kind of thing on those boards and can offer real world experience.

**PSK** · 21 March 2011, 14:06

"I previously contracted with them on a daily rate and due to not my fault the project overran"

It might be helpful to consider the dependencies out of your control (client having a clear requirement that doesn't change again and again) and establish clarity in your contract and ongoing communications during delivery to help ensure you don't have disputes over whose fault it is that timely delivery doesn't happen with the risk sitting clearly with you.

Penalties aren't allowed but if you sign up for a liquidated damages scheme, your risks may extend beyond that of having to do more work that you planned in the costing.

As well as the IPR issue mentioned earlier, (potentially selling to other clients), equally you might want to think about the commercial implications of the ongoing development and support of the product for this client, both for improvements in functionality and for any necessary changes to enable it to continue to run in their environment. They may come to you for these anyway as you would be well placed but you'd want to think in the contract about rights and obligations to amend, develop and so on.

**TheFaQQer** · 21 March 2011, 14:15

As well as those points raised by Mal, ensure that you have a documented, agreed and contracted procedure for change control and defect resolution.

If the client changes their mind halfway through and wants more doing, who pays for it? Even if you haven't started work, if they change their mind, then you need to agree whether it's a change you are accepting, and at what cost (£0 or more).

Make sure that everyone knows what timescale they have to approve the work that you deliver. I've worked on projects where the client has taken delivery from a consultancy and done no testing or review for 6 months and expected the consultancy to fix defects for free at that stage. Give them a few weeks from delivery to test it and report any defects.

Remember the first rule of calculating your cost - think of a number and double it. Whatever you think it will cost, ensure you add contingency.

If you plan for three weeks development - what do you do if there is no-one available from the client for two of those weeks? Who pays for that time? Ensure that there is something in the contract about the right people being available to you.

I'm sure there are more things to be aware of, though.

Good luck.

**Amar** · 21 March 2011, 15:34

Guys , Just want to say thanks to all of you who replied. You have been most helpful. I firmly believe that as a contractor I have learnt more and continue to do so. So this new type of contracting with additional risk/rewards will also be a good (hopefully) learning experience.

Lets see how the discussions go. Please continue to post if anyone has something new to add.

Amar

**jmo21** · 21 March 2011, 15:38

I tend to avoid fixed term contracts at all costs, just seems like too much hassle.

Last one I discussed was for a recruitment agency believe it or not. Their usual IT guy (owners brother in law) said they could build a small website to do a specific thing in 5 days.

They were willing to pay X amount, which when averaged over 5 days was half my typical day rate. Plus I reckoned it would take 2-3 weeks.

Now maybe the other guy was tulip hot and could do it 5 days but it seemed a ludicrous timescale to me.

Plus the owner was a total slimeball, seemed way more hassle than it was worth.

**PSK** · 21 March 2011, 15:39

If the contract value is larger enough to be a worry and they push for liquidated damages, it might be an idea to ask to be put in touch with any other one man band contractors who have or are delivering under a fixed price contract to see what difficulties they've had that you might want to avoid or address in the contract.

Good luck.

**TykeMerc** · 21 March 2011, 16:08

As the others have said, fixed price contracts are ok, but there are a few absolute musts which have to be in the contract.

1. Well and clearly defined statement of deliverables
2. Well and clearly defined statement of work
3. Well and clearly defined statement of requirements
4. Well and clearly defined change control process
5. Mutually understood payment scheme (milestones, stages, deliverables etc)
6. Statement of IPR ownership, how and under what circumstances it transfers and when.
7. Statement of liabilities during coding and post delivery
8. Statement of dependencies as they're understood now and how if those change the change control process kicks in

All of the above must be absolutely clear and unambiguous, without them you're unwise to agree to take on a piece of fixed price work.

Urgent: Fixed Price Contract question