How do you quote for embedded software development?

[ricko_uk]

Hi,
I am curious about the various ways you could quote for a firmware development job.

Until now I always provided a fixed quote but some projects might be delivered with more bugs than others and sometimes it take a lot longer to debug after you think the project is completed.

How do you account and quote to cover yourself financially for such situations?

Thank you

[AndyC_772]

Always think about this from the customer's point of view.

Sometimes the nature of a job is that the thing you're working on is experimental and may simply not work, or not work well, or not work as well as it could do without further effort. This is completely OK provided both you and the customer are agreed that you're doing R&D, and that there's an element of risk involved. You can charge for all of your time, including time spent revisiting the design and making it better.

(As an aside, this is exactly what R&D tax credits are for under UK company law).

If, however, you're being asked to deliver a complete, working design, and you're confident that it's something that's within your capabilities, then any bugs are your responsibility. Only you know how good you are at writing good quality code and getting the bugs out of it before it's delivered to the customer, and you should use your own experience to quote accordingly.

If it then turns out that the first draft of your code actually works better than you expected, then that's great - you win. If, on the other hand, it has some nightmare bugs that take you ages to track down and fix, then they're absolutely 100% your problem and not your customer's. Spend the time on fixing them, make sure you're 100% happy with the end result, and deliver the proect to your customer with a smile. Provided your wins and losses balance out, you're doing it right.

The real problem with quoting for firmware isn't bugs, it's feature creep. This can be the dreaded "can you just make it do...?" after you've already quoted a price, but it can also be a spec that turns out to be incomplete, such as one which covers all normally expected conditions but omits unexpected or error states. Spot these in advance, and you'll end up with a much better relationship with your customer.

[SiliconWizard]

Yeah, first thing is spending a little more time studying the customer's specs BEFORE signing anything. Of course that may imply not getting the job if the customer won't give you complete enough specs or you decide that it's not going to work out for some reason - but this will save you a lot of pain down the line. Sometimes turning down a job is much more profitable than taking it.

The benefit of this extra step is that, not only you'll have a clearer view of what the customer wants, but you'll get to see how easy or how hard it is to work with them, before even "starting".

Also, for future unknown events that may change the execution time and that are not under your own control, you should always have a contract clause about this. Do not just hope you'll manage to arrange something with your customer if you haven't anticipated it in the contract.

In particular, events that could fall into this category would be customer requirements that were not given upfront, or difficulties to get complementary requirements/answers from the customer you might need during the project's execution. Any "unreasonable" delay in getting required information from your customer should be duly noted, and then you can use this to remind your customer the contract clause, and  negociate extra fees for instance.

OTOH, obviously, bugs that are pure implementation bugs (and not due to erroneous or incomplete specs) are your own concern. They are by definition very hard to anticipate, but you can anticipate you'll have bugs, and take this into account in your quote.

[rstofer]

IBM used to estimate that a good programmer could produce 100 lines of debugged and documented code per day.  So, 12 lines per hour...  And that assumes you already know about the component choices.  If you have to learn about a CPU in order to program it, the output could be less.

If you estimate the job will require, say, 12,000 lines of code, it should take about 1000 hours to produce.  Then you just need to decide what your labor rate (pre-tax) should be.  Is it $50 per hour?  $100 per hour?  Whatever, just multiply by 1000 hours.

Then add 20% for contingency - there will always be problems.  The thing is, everybody wants to eliminate the contingency from an estimate.  I always bury some contingency in every line item and then let them delete the block contingency at the end of the quote.  I'm still covered.

When estimating projects, I find it useful to come up with as many distinct line items as possible.  It's a lot harder to attack the total when it is composed of dozens of line items.  The customer may not like the price but it's difficult to attack the detailed breakdown.

I spent most of my career working on projects.  Not computer projects but, rather, building construction projects.  My customers were almost always internal.  It's amazing how money moves around inside a company.

Nevertheless, the approach is sound.  Many small line items which individually include contingency add up to the project budget which should include some additional contingency which will always be attacked.

Sometimes the customer doesn't want to know about details.  That's fine but it doesn't change the total.  If I had to code a display driver and I thought it would take 12 hours, that's what I would include in my internal estimate.  If the keypad driver was estimated at 6 hours, so be it.  If the interrupt handlers would take another 10 hours and porting FreeRTOS would take 40 hours, that's what goes in the estimate.  I would list as many 'tasks' as I thought the project would have.  Among other things, this approach prevents me from missing major pieces of work.

There is also a strategy of bidding:  You bid low and hope for change orders when you need to keep working or keep your crew working.  You bid high when you are busy and don't really want the job but you don't want to lose the long term relationship.  If you get the job, be worried that you forgot something!  Don't assume your competition is incompetent!

[bson]

Depends on your role.

If you're a contract worker, working on their product, bill hourly.

If you're a business and are licensing software, then there's a license fee paid up front and a separate support agreement that's recurring.  You should let them evaluate what you have, and they may require specific changes or a support period.  Figure out how much you'll want to charge for that on top of the base license and give them a quote.

It sounds like the former would be more applicable.  Basically, as long as you work for them they pay you by the hour.  If they don't feel you're productive enough or don't need you anymore they can end the agreement.  (So can you.  It takes two to tango.)

If you bill by the hour be very specific about any existing code you bring in, like libraries or such - that needs to be spelled out plain text that you only give them a license and what the scope of that license is.  Otherwise you may find they own it, but didn't pay you to create it.  It's VERY common for contractors to reuse existing code developed outside of contract work, exactly to get stuff done rapidly.  This can be a major selling point!

I'd strongly recommend incorporating if you do a lot of contract work.  It makes it easier to structure agreements, hire additional help, license existing code bases, etc.

[NorthGuy]

Fixed amount is the best for everyone. Fixed requirements even more so.

Bugs are your responsibility. You have to fix them for free. Even after the project is over.

[bson]

Oh, and I should mention if it's not a commodity item (i.e. not something listed on a website they can stick in a cart, or the IRL equivalent) - then the  license price needs to be high.  They will demand things like support, maybe various changes, and such - and you want pricing headroom without having to increase the license fees.  It also gives you room to negotiate, and the customer will be MUCH happier having talked you into a 35% discount than you having tacked on 40% for various asks - even if the total is the same!  So "base" here means BOTTOM LINE.  You never go below the bottom line; this is a predetermined price at which point it's no longer worth your while and you walk away.  Not every deal will close; if they do, you're leaving money on the table.  Some you will simply walk away from, or the other party will.  You should set and continuously adjust your base price accordingly.  And never share it with anyone.  Never yield on it during a conversation.  You can always adjust it when you have time to sit and think it over, never adjust it during a meeting.  Then go to the next meeting with your adjusted base price (or, bottom line if you prefer that term).

[mikeselectricstuff]

Bugs are your responsibility. You have to fix them for free. Even after the project is over.

Debatable for the case of bugs discovered after the customer has tested & approved the code though.

[mikeselectricstuff]

but it can also be a spec that turns out to be incomplete, such as one which covers all normally expected conditions but omits unexpected or error states. Spot these in advance, and you'll end up with a much better relationship with your customer.

If you don't raise multiple queries about missing/ambiguous/incompleteness issues in a customer-supplied spec, then you've probably not looked at it carefully enough. As someone who will be implementing it, you will see things that haven't been considered from the functional design/spec angle.

IME I usually have to write a complete new spec based on what the customer has told me & get them to agree, as theirs is typically woefully inadequate and incomplete.

[SiliconWizard]

Bugs are your responsibility. You have to fix them for free. Even after the project is over.

Debatable for the case of bugs discovered after the customer has tested & approved the code though.

A decent contract usually includes some warranty period after the execution is over, so that includes possible bugs discovered during this period. That period may be anywhere from a few weeks to a few months depending on the project. A customer that would accept signing without such a clause would be pretty dumb.

[nctnico]

Bugs are your responsibility. You have to fix them for free. Even after the project is over.

Debatable for the case of bugs discovered after the customer has tested & approved the code though.

A decent contract usually includes some warranty period after the execution is over, so that includes possible bugs discovered during this period. That period may be anywhere from a few weeks to a few months depending on the project. A customer that would accept signing without such a clause would be pretty dumb.

Indeed. Once the customer has signed off the project is done. Any changes that need to be made are a new project / contract.

Fixed amount is the best for everyone. Fixed requirements even more so.

Yes. In reality there ain't not such thing as a blank cheque to develop for as long as you want. Try to avoid such situations because in the end nobody will be happy. IOW: any kind of price you mention will be considered a fixed price even if you state it is an estimation. An exception is doing small jobs for a customer where there is enough mutual confidence that price versus the amount of work will be reasonable. But that is rare.

[T3sl4co1l]

If you bill by the hour be very specific about any existing code you bring in, like libraries or such - that needs to be spelled out plain text that you only give them a license and what the scope of that license is.  Otherwise you may find they own it, but didn't pay you to create it.  It's VERY common for contractors to reuse existing code developed outside of contract work, exactly to get stuff done rapidly.  This can be a major selling point!

Could you recommend any standard license terms for this?

Tim

[nctnico]

If you bill by the hour be very specific about any existing code you bring in, like libraries or such - that needs to be spelled out plain text that you only give them a license and what the scope of that license is.  Otherwise you may find they own it, but didn't pay you to create it.  It's VERY common for contractors to reuse existing code developed outside of contract work, exactly to get stuff done rapidly.  This can be a major selling point!

Could you recommend any standard license terms for this?

You have to define what the customer is paying for, what kind of third-party libraries you intend to use (beware of GPL code!) and which part of the code falls under your own copyright (libraries). By default the copyright of any software you develop entirely by yourself at your own premises is yours even if someone is paying you to do so. Not everyone is aware of that. In my terms & conditions I have defined that the client becomes the copyright owner after they have paid the sum in full, except for third-party and my libraries. For my libraries they get a non-transferable license for use.

[ricko_uk]

Thank you very much to all, very interesting feedback and useful information!!

Appreciated as always!!

[passedpawn]

Fixed amount is the best for everyone. Fixed requirements even more so.

Bugs are your responsibility. You have to fix them for free. Even after the project is over.

Utter nonsense.  Fixed is worst for everyone.  I've been consulting for a long time, electrical design, layout, firmware, software.  I refuse to do a fixed-price job anymore. 

For experienced developers, it's pretty easy to quote a project as an "estimate" and be fairly close to target.  But in my quotes, I state that "scope creep", unexpected difficulties, and the normal difficulty of inventing the customer's time machine could push the costs to 2x. 

[NorthGuy]

Fixed amount is the best for everyone. Fixed requirements even more so.

Bugs are your responsibility. You have to fix them for free. Even after the project is over.

Utter nonsense.  Fixed is worst for everyone.  I've been consulting for a long time, electrical design, layout, firmware, software.  I refuse to do a fixed-price job anymore. 

For experienced developers, it's pretty easy to quote a project as an "estimate" and be fairly close to target.  But in my quotes, I state that "scope creep", unexpected difficulties, and the normal difficulty of inventing the customer's time machine could push the costs to 2x.

Contractor is a business, not an employee. The business sells products or services and takes full responsibility for the things it sells. This is not customer's concern how the services are produced. If there's something unexpected, the business absorbs the cost. The business may actually lose money if the costs are much higher than expected. And conversely, If there's a mission creep, it's up to the business to agee or refuse. You may agree to do extra for additional pay, but you may refuse as well, for example if you're busy doing other stuff.

What you portray, looks more like employer - employee relationship, where the employers buys your time and then he decides what to do with it - he can push any mission creep on you as he wants. If something goes wrong, even if you fail to produce what he wanted, even if you do nothing, he still pays you for your time.

[Siwastaja]

The business sells products or services and takes full responsibility for the things it sells. This is not customer's concern how the services are produced.

Except that outsourcing HW/FW engineering usually isn't providing a black box product. It can be, but often this is design and implementation in cooperation with the customer. Customer may directly participate, for example write another layer of software. At least it's completely normal for the specification to flex during the project, which immediately makes the process completely different to that of just selling a product.

So it really depends, fixed cost can be very good if the work is mostly as you say delivering a product to the customer, but if it's more about working together with the customer then it's closer to the employment as you say.

It's not black&white, it can be a strange mix of those approaches.

[aandrew]

Contractor is a business, not an employee. The business sells products or services and takes full responsibility for the things it sells. This is not customer's concern how the services are produced.

IF the spec is clear.

IF the acceptance criteria is clear.

IF the customer actually knows what they want.

Those are some enormous ifs.

No, fixed-bid is a fool's errand. Every customer wants it, but damn near every customer also refuses to sit down and develop (at their cost!) a full specification, including acceptance criteria. Every customer wants some scope creep as things progress.

So no; much like building a house, you hire contractors (who are ALL paid hourly), and as it's being built you realize you want that wall moved a little, or you want something that wasn't in the original plans, or want something that was in the plans changed or removed. Development, like construction, is a highly dynamic process. You can't realistically bid a fixed price without also absolutely locking down the requirements and clearly defining the finish point, which is damn near impossible. And yes, you can stipulate that changes require re-bidding, but then you get into pissing matches over "it's not THAT big a change" -- it's not worth it.

I've been doing this a long, long time now. Fixed bid contracts are a unicorn.

[T3sl4co1l]

¿Por que no los dos?

Contracts are malleable, simply a statement of what the parties have agreed upon; if they are open to the option, milestones can always be added onto an initial "fixed" bid.  It needn't be a dichotomy, there's a continuum of possibilities between fixed-at-start bid and pure hourly.  Could even do hourly with different rates for different segments, etc. (though I'm not sure why you'd bother, heh).  And it can be written in that all steps are mandatory (so for overall project purposes, it doesn't matter if it's broken into stages; what amounts to structuring of payments), or that some steps are optional (given that some can't be done out of order, some will be dependent on completion of earlier steps).

The way to deal with feature creep in fixed projects, is to simply remind the client what they agreed upon, and suggest that, if they are interested, such features can be added on for this-and-that additional time and cost.

Tim

[nctnico]

Contractor is a business, not an employee. The business sells products or services and takes full responsibility for the things it sells. This is not customer's concern how the services are produced.

IF the spec is clear.

IF the acceptance criteria is clear.

IF the customer actually knows what they want.

That is why you have to turn things around. My motto is 'don't make what the customer wants but make what the customer needs'. Usually there are only 2 things clear to the customer: the budget and what a product may cost. So what I do is listen and observe the processes and wishes from the customer very carefully. From there I make a detailed description of what is going to be delivered and how much it is going to cost. From there the customer can accept the quotation, negotiate to make it cheaper or hire someone else.

Whatever needs to be altered or added later on, goes into a new quotation and basically is a new project.

[ejeffrey]

You have to define what the customer is paying for, what kind of third-party libraries you intend to use (beware of GPL code!) and which part of the code falls under your own copyright (libraries). By default the copyright of any software you develop entirely by yourself at your own premises is yours even if someone is paying you to do so. Not everyone is aware of that. In my terms & conditions I have defined that the client becomes the copyright owner after they have paid the sum in full, except for third-party and my libraries. For my libraries they get a non-transferable license for use.

Be careful that this isn't legal advice because that varies from jurisdiction to jurisdiction and the exact nature of the relationship.  Sometimes in the US at least, things can qualify as a "work for hire" and copyright defaults to the person paying the bills.  But it's always best to have an explicit ownership statement in the contract to avoid confusion.

The way we usually do it is that there is a general statement about "background IP" vs "developed IP".  Then there is a section to list each parties background IP that they expect will be used in the project.

[ejeffrey]

Contractor is a business, not an employee. The business sells products or services and takes full responsibility for the things it sells. This is not customer's concern how the services are produced.

IF the spec is clear.

IF the acceptance criteria is clear.

IF the customer actually knows what they want.

Those are some enormous ifs.

No, fixed-bid is a fool's errand. Every customer wants it, but damn near every customer also refuses to sit down and develop (at their cost!) a full specification, including acceptance criteria. Every customer wants some scope creep as things progress.

Fixed bid a good way to avoid scope creep?  Jumping into a non-trivial project on time and materials basis without a clear goal is a way to have an unhappy customer.  Even if you are doing hourly, you need to have a well defined goal so that you can give an estimate that the customer understands.  It doesn't have to be all or nothing, if your customer doesn't understand enough to build a detailed spec, you can charge them consulting fees to develop the spec.

So no; much like building a house, you hire contractors (who are ALL paid hourly), and as it's being built you realize you want that wall moved a little, or you want something that wasn't in the original plans, or want something that was in the plans changed or removed. Development, like construction, is a highly dynamic process. You can't realistically bid a fixed price without also absolutely locking down the requirements and clearly defining the finish point, which is damn near impossible. And yes, you can stipulate that changes require re-bidding, but then you get into pissing matches over "it's not THAT big a change" -- it's not worth it.

I'm not sure what your point is, construction projects are very often done fixed bid.  I just did one. Yes, the trade workers are paid hourly, but the general contractor bids a fixed price and the subcontractors generally bid fixed price to them.  Part of the job of the contractors is to be able to accurately estimate the amount of work. Fixed price puts them on the hook to do a good job. If you want to make a change that materially affects cost, they do a change order.  Not everything needs to be set ahead of time, our contractor put in allowances for things  like carpet and tile choices and then updates the bid when they were chosen, and since it was an addition to an existing structure they identified specific cases that might need to change based on what was discovered during construction.  It was fine. 

[peter-h]

If you are good and know the hardware, and there is a clear spec, quote fixed price, plus an hourly rate for additional work.

If you will be learning on the job, and/or aren't good, quote hourly The customer will probably not be happy though...

This is a very difficult area. Most customers will feel ripped off by any contractor who is less than very good, and of course most contractors are considerably less than very good.

[westfw]

Contractor is a business, not an employee.

Actually, it could be either one.  At least, the US is full of "contracting agencies" that will rent you a person with supposed expertise in some area, at prices very much like normal wages, but apparently with a lot less "red tape" for the company getting the end work.

You can also say "I'm an expert at XYZ and can make and license you an obvious variant of that for a fixed fee and it will have this list of features for flat $$$", and that's cool too.
The good relationships are the ones where both the contractor and the person/company that is hiring them are in good agreement as to which thing they are getting (time, or product.)

[Kjelt]

Split the project up in a couple of deliveries and get feedback.
So if there are ten "features" create 5 deliveries, 5 terms of  payments and demand feedback from the customer, being agreed sign off or not ok need rework or different implementation.
Agree that between deliveries both parties are allowed to break up the contract if there serious reasons.

The reason I would do it lije that is that most customers do not have a 100% understanding of what they want at the start. Accept that and take it into account. As the work progresses they get a better understanding and change requirements. In the above contract you can then also adapt the schedule (project adds more deliveries and payments or less depending)

The reason that both parties should be able to break up is for the customer the project in total will cost way more then expected or the result is not what they would like. In your case it could be lack of timely payment but also fir instance you find out that what the customer wants is just not feasible, for instance the choosen and provided microcontroller is too light weight for the task or other hardware or software restrictions you encounter.