Reply to: Fixed price contract

[WordIsBond]

above all else, you need to have a degree of mutual trust.

That mutual trust is not absolutely necessary, but if you don't have it, you have to nail down every little thing in advance. But if you have it, this can work great.

[MrMarkyMark]

Good stuff guys, very interesting, I may have some of this coming up myself.

[jamesbrown]

= A cheap way of getting a highly skilled contractor with little or no risk, and without having to deal with the usual overheads of hiring a permie.

FPC's are IMHO rarely the best way to go unless you can build in a decent risk premium above what you can command on a daily rate basis. My experience is that you'll usually find the Punter (Client) is wanting a resource on the cheap.

Personally I always avoid.

I think you're confusing fixed-price with fixed-term (as in a fixed-term employment contract). Otherwise, your experience couldn't be further from my experience. The whole point is that you can, indeed, profit far more from a FFP than T&M, providing you know what you're doing, while the client benefits from an upfront costing. Generally speaking, they're also about as far away from (disguised) employment as you could possibly get (not because of the payment mechanism itself, but the type of work/arrangement that it's well suited to).

[Gordon Ice]

Fixed Price Contract =

= A cheap way of getting a highly skilled contractor with little or no risk, and without having to deal with the usual overheads of hiring a permie.

FPC's are IMHO rarely the best way to go unless you can build in a decent risk premium above what you can command on a daily rate basis. My experience is that you'll usually find the Punter (Client) is wanting a resource on the cheap.

Personally I always avoid.

[jamesbrown]

This has been stated several times. Absolutely right.

I like fixed price jobs. For one thing, they are very hard for HMRC to drag into IR35, they probably won't even try.

And there is potential for much more profit, if you've scoped the job right, because of that risk. You are charging them for the amount of work you think it will be AND for the risk that it is more than that. I build at least a 25% premium into a fixed price job, if the client can't do it for 125% of what I think my normal hourly billing would be, I'm not interested. If I deliver on the expected schedule, I'll get a 25% bonus. If I deliver ahead of schedule, it's a bigger bonus.

They can shift the risk to you, but they should pay something for doing so. Call it overrun insurance -- don't give them overrun insurance for free. The cost of that insurance depends on the size of the job, how confident you are, etc.

Absolutely agree. I know a couple of people have stated that clients love them, but suppliers should love them too! I've made some incredibly good deals on FFP work, way beyond anything I could ever get on a T&M basis. I've had very few go wrong (as in, fewer than I have fingers ). That being said, you need to take a very conservative approach with your estimates, agree the acceptance criteria, as far as possible and, above all else, you need to have a degree of mutual trust. If either party wants things to go south (e.g. client trying to get something on the cheap, rather than fixing a budget), they will. A little experience goes a long way in judging a client and negotiating a FFP (it's an art as much as a science), but you have to start somewhere, and I think the OP is on the right track.

[WordIsBond]

The key thing to remember about fixed-price is that it shifts the majority of the risk onto the supplier.

This has been stated several times. Absolutely right.

I like fixed price jobs. For one thing, they are very hard for HMRC to drag into IR35, they probably won't even try.

And there is potential for much more profit, if you've scoped the job right, because of that risk. You are charging them for the amount of work you think it will be AND for the risk that it is more than that. I build at least a 25% premium into a fixed price job, if the client can't do it for 125% of what I think my normal hourly billing would be, I'm not interested. If I deliver on the expected schedule, I'll get a 25% bonus. If I deliver ahead of schedule, it's a bigger bonus.

They can shift the risk to you, but they should pay something for doing so. Call it overrun insurance -- don't give them overrun insurance for free. The cost of that insurance depends on the size of the job, how confident you are, etc.

[meridian]

I think that is a good approach, i.e. a fixed price for a requirements analysis and design. Make sure you also include a test accept spec. as part of the initial phase. Then it's bomb proof.

The test accept spec. is the key to no misunderstandings.

i.e. you have very simple straightforward tests and when they run through they pay. Any changes which require a change to the Test Spec. are then extra.

I found this was the key to controlling scope.

I'd be interested to see how this was written up.

I've worked on Fixed Price before and although in theory that sounds fine (tests passed = implied acceptance = payment trigger), it usually ends up in a bunfight with the system integrator over how many tests and which ones are included in scope. If you can't define your deliverables up front, then accurately defining the tests to pass would be near impossible?

You're right though about scope creep, it makes change control even more important. Oh the fun we had arguing whether an issue was a defect or a CR, and the man hours we wasted doing so....

[tomtomagain]

The key thing to remember about fixed-price is that it shifts the majority of the risk onto the supplier. If they expect you to be in their office 5 days a week, only paying once it is "Complete" and dicking around for 6 months making simple decisions then you will rapidly become a very unhappy bunny.

Do not agree to fixed price unless you are really sure it can be delivered to a fixed price. Some work, Software Development without a specification, does not lend itself to fixed priced work. Some work does - Painting a room, buying and installing a server.

I produce a Statement of Work for each of my fixed price pieces of work. It is a standard template and i've posted the section headings below.

If I was in your position ( and I have been ) then my initial Statement of Work describes the steps I will take to build the PLAN to deliver the project and not the project itself.

I hope these prompt some thoughts for you.

==============================

Project Deliverables

What’s going to be delivered – itemized by cost.


Description of Development Work

Bit of verbiage.



Deliverable 1. XXXXXXX.

One section per deliverable. Bit more detail.



Scope of Work

Explicitly In-Scope

List everything you will do ( including status reporting, following their processes etc )

Explicitly Out-of-Scope

REALLY IMPORTANT – LIST WHAT IS OUT OF SCOPE
For example I take “Deployment to production out of scope” and “End user Testing” because I am not getting myself into a situation where the end-user expects me as an external supplier to navigate their internal bureaucracy.

Key Assumptions and Dependencies

What do they need to do? Provide desk? Resources? Access to their IT? Access to their staff?

Scope Management Process

How is change going to be managed?

Work Location

Where are you doing the work? Don't list hours or times. It is fixed price and therefore the time it takes you is not important. Its the value you are delivering.

Engagement related expenses

What is expensable. Be explicit. For example trips to their regional offices.

Intellectual Property

I try and retain it.

Warranty and Defect Fixes

What warranty are you offering?

High Level Project Schedule

Put some dates around the deliverables.

Rate Card and Roles

Be upfront about your hourly/daily rate. This should include a profit margin. For example it should be a contractor day rate + 25% ( Worst-case you need to hire someone from the market to complete some of the work. You still want to make a profit. )

Contract Method and Payment Schedule

How is it the work to be contracted? T&M, Fixed Price, T&M with a cap?

Payment Milestones

List of milestones.

Acceptance and authorization

Get them to sign it. If they won’t sign it. Don’t do business with them.

[TheFaQQer]

So not knowing the exact deliverables how do I go about quoting/ accepting this? Should I quote for a short let's say 5 day consultancy to get more detailed requirements and after that accept/reject the full project?

That's how I used to do it when I was a consultant - you need to sell them the initial phase of the project to define what needs to be done, and then you can bid for the next phase.

Of course, once you do that initial plan, there's nothing to stop them from dispensing with your services and finding someone else who will do the rest of the project fixed price - that might be something that you can play up, though, as something that this approach offers as an advantage to the client.

[Eirikur]

Thanks to all, some very good advice indeed

[MrMarkyMark]

Clients love fixed price .... because it puts all the risk onto the supplier. Fixed price without fixed scope is even better, because then they don't have to think about any of the details.

Consultancies rarely do "fixed-price" because they want to push the risk on to the customer.

Putting those to obvious statements aside, I have done fixed price work successfully for a number clients in the last 12 months.

You need to get them to agree to an investigation phase, one week or whatever, and with the deliverable being either the scope for the full project or the next phase. Obviously they will kick back and claim it's easy ( and they may genuinely believe that ) but there is no way I'd be signing a fixed price contract without a fixed scope.

So you need to think about:

"A rate card" - for T&M elements of the project ( for example if there is "data cleansing" element, that could be a T&M element to a project as these are notoriously difficult to estimate) - I have different rates depending on whether I am wearing a architecture, PM, developer or tester hat. You might have a single rate, but you need something in the contract that says "Any work outside of the agreed scope will be charged on a T&M basis at ........".


"Change/Scope control" - fixed price contract == fixed price scope. Needs to be formalised.

"Payment milestones" - depending on the size of the project these should be regularly spaced out. For example I request 50% on issuing on the PO, 30% on completion of deliverables, 20% on user acceptance. You really need to avoid a contract which says "100% on delivery". T&M elements bill them monthly.

"Commitment" - you need to be asking questions to ensure they are committed to giving you access to the staff required to do the job.

"Acceptance Criteria" - obvious really. But unless you are clear how you define "DONE", it is easy for the customer to keep withholding payment.

Very useful advice, thanks

[LondonManc]

Key items:

Scope - the exact set of deliverables and, just as crucially, disambiguation about what will not be delivered as part of your engagement
Acceptance criteria - a set of criteria against which you are to be measured
Assumptions and/or prerequisites - things that must be in place for you to deliver, such as availability of resources, including people
Payment cycle - when you should be paid for what

[tomtomagain]

Clients love fixed price .... because it puts all the risk onto the supplier. Fixed price without fixed scope is even better, because then they don't have to think about any of the details.

Consultancies rarely do "fixed-price" because they want to push the risk on to the customer.

Putting those to obvious statements aside, I have done fixed price work successfully for a number clients in the last 12 months.

You need to get them to agree to an investigation phase, one week or whatever, and with the deliverable being either the scope for the full project or the next phase. Obviously they will kick back and claim it's easy ( and they may genuinely believe that ) but there is no way I'd be signing a fixed price contract without a fixed scope.

So you need to think about:

"A rate card" - for T&M elements of the project ( for example if there is "data cleansing" element, that could be a T&M element to a project as these are notoriously difficult to estimate) - I have different rates depending on whether I am wearing a architecture, PM, developer or tester hat. You might have a single rate, but you need something in the contract that says "Any work outside of the agreed scope will be charged on a T&M basis at ........".


"Change/Scope control" - fixed price contract == fixed price scope. Needs to be formalised.

"Payment milestones" - depending on the size of the project these should be regularly spaced out. For example I request 50% on issuing on the PO, 30% on completion of deliverables, 20% on user acceptance. You really need to avoid a contract which says "100% on delivery". T&M elements bill them monthly.

"Commitment" - you need to be asking questions to ensure they are committed to giving you access to the staff required to do the job.

"Acceptance Criteria" - obvious really. But unless you are clear how you define "DONE", it is easy for the customer to keep withholding payment.

[jamesbrown]

Yes, if the deliverables are very unclear, this is the approach I would take (although view the short consultancy as a scoping exercise, rather than an accept/reject exercise). However, if you can reasonably define the detailed deliverables (i.e. you may be nervous, but you cannot eliminate all uncertainty with a fixed price contract), you should consider using that to your advantage. The whole point of a fixed price contract is that the client can budget upfront, but you need to factor a considerable margin of uncertainty into your pricing. You should be pricing this far above your best estimate of the accrued time on a T&M basis.

In terms of travel, I've always factored this separately (in the few times that travel has been involved in a fixed-price contract), but also as a firm fixed price, because it was very occasional travel and it was defined upfront. I'm not sure why the client would be paying for your routine home-to-work travel though(?)

[BlasterBates]

I think that is a good approach, i.e. a fixed price for a requirements analysis and design. Make sure you also include a test accept spec. as part of the initial phase. Then it's bomb proof.

The test accept spec. is the key to no misunderstandings.

i.e. you have very simple straightforward tests and when they run through they pay. Any changes which require a change to the Test Spec. are then extra.

I found this was the key to controlling scope.