Electronics > Microcontrollers

How do you quote for embedded software development?

(1/8) > >>

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.

Navigation

[0] Message Index

[#] Next page