Mark all as read

How to estimate time of completion while developing an electronic product?


I don't know whether this question is on-topic or not but answering this helps a lot of future electronics entrepreneurs like me understand how the product design and development time estimation takes place.

Suppose a customer approaches me and gives a project with his specifications(let us say a DC-DC converter or a Home automation System etc.). Now how should I estimate the design time, development time, test/debugging time and give him a report that by this time approximately I can handover the project?

As far as I know there are two types of products-

  1. The product which is already present in the market and customer comes to me for price optimization or some different specifications.
  2. A complete new project never been in the market.

So time varies for each one above, how to estimate time and what are all the factors to consider?

Why should this post be closed?

1 comment

Speaking from a Programmer prospective, estimating is very hard and even experienced professionals often under-estimate. The same is true in other fields, like word work or other construction in my city! dustytrash‭ 5 days ago

5 answers


There is no easy answer to time-estimation. Experience is essential, but even for experienced people it's never easy.

For simple projects, like designing a DC-DC converter inside some larger product, it comes down to having done it before and using that as the starting point. After a while, you also learn to see problems coming, like how much the customer looks like they will micro-manage the process, whether you will have access to the necessary debug and test facilities, etc. Every project is different, but starting from experience with similar ones is very useful, I'd even say necessary.

For complicated projects, break up the project into smaller tasks. The more tasks you break it into, the longer the estimate for the overall project will be. That's because unforeseen issues really derail any estimate. One purpose of breaking a large project down into many little steps is to help forsee the unforeseen issues.

The larger the project, the more slop needs to be added to the estimate. Again, it takes experience to judge this.

Note also the distinction between "estimate" and "fixed price bid". Sleazy or just unsophisticated customers will ask for an estimate first, then try to turn that into the fixed price they will pay you. Don't fall into that trap. Always make it clear that an estimate is just that.

When projects were small enough and I felt reasonably comfortable with my estimate, my fixed price would be that times 1.5. For less certainty, the factor would be 2.0 minimum, then go up from there. Personally, I eventually just tried to avoid fixed price jobs. If the customer won't trust you, and vice versa, then the job isn't worth it, no matter how much it looks like on paper you'll get paid.

If you haven't done the kind of job before, then you have no business estimating it at all. Get some experience where someone else takes the risk first. This is probably not what you want to hear, but if you have to ask how to estimate a job, you're not ready to be in that position yet.



First, consider the usual triple-constraints often discussed in project management theory: time, cost, quality (choose 2):

  • You can have it fast and cheap, but not high-quality;
  • You can have it fast and high-quality, but not cheap;
  • You can have it high-quality and cheap, but not fast.

Next, you need to allocate some time for a complete and thorough understanding of the prospective client's requirements. It is very easy to go down the wrong track if something vitally important to the client is either absent from, or misrepresented in, the specification. Requirements engineering (RE) is its own discipline and takes both product knowledge and managerial skill.

Third, you need to define a complete statement of work. If the prospective client is satisfied with a schematic and some simulation work to prove a concept, it will take significantly less time that it would to go through a traditional waterfall development process with multiple phase gates, physical product construction, debugging and qualification, external lab certification and production release.

Finally, once the statement of work is agreed upon, you must determine time and cost estimates for each of the major tasks in the statement of work. This is often the domain of professional project management teams with technical and operations inputs considered as needed. How to estimate these times and costs comes from past experience - how long previous efforts took, what industry "norms" are, how competitors perform, plus the overall workload and capabilities of your organization.

Once all this is complete, you have your initial schedule. Now you just need to deliver!


I generally agree, except that how competitors are perceived to perform should NOT be part of any estimate. For estimates to be useful, they need to be honest assessments, and not based on wishful thinking. That causes much trouble later in the project. Olin Lathrop‭ about 1 month ago

Sure, some of it is customer posturing and bluffing. That said, if you consistently lose business because your timelines are too long and you're told that company X can deliver 3-6 months faster, it may be reason to re-evaluate your processes. Adam Lawrence‭ about 1 month ago

Unfortunately all too often X can't really deliver 3-6 months faster. They are misleading the customer to get the job, figuring they'll get the extra later when the customer is already committed and can't easily go back to a more honest contractor. Olin Lathrop‭ about 1 month ago

@Adam Lawrence "if you consistently lose business because your timelines are too long". I've been through the opposite. I did a time estimate of one project and came up with something like 4 months. The competitor offered something like 1.5 months. The customer knew we were experienced, so he look our offer and dismissed the competitor's offer as wishful thinking. Turned out that my estimated time was pretty accurate too. Lundin‭ about 1 month ago

But that customer had a fairly experienced purchaser who determined who got the contract, which isn't often the case. Still, the good customers who can call the bluff on BS offers are often the ones you want too, because they appreciate professionalism and quality. Lundin‭ about 1 month ago

Show 2 more comments

First of all, it depends on how much work the customer has done in advance. Do they have a proper spec? Do they at least have a bunch of key requirements? Or is it just "out there" and you must drag the spec out of the customer through interrogation and mind reading?

If there isn't a proper spec, you should probably add a couple of weeks right there. You have to make the spec yourself, then ping pong that with the customer back and forth. Also, customers who don't quite know what they want tend to come up with requirements later, when you are already half-ways through the project. Each time that happens, it will delay the project and cause extra work.

Then you'll start to consider design and implementation time. Here you need experience from similar work but also from the market. To take the DC/DC scenario for example, it shouldn't be that much work unless there are specialized requirements. Find out the most exotic or tough requirement and base the time estimate on that one. High currents? Tough EMC requirements? Is some peculiar switch regulator topology needed? Or whatever you deem hardest to fulfil or most likely to cause hiccups. Check how much in the way of reference designs you can get from the silicon vendor and how much you think that design needs to be tweaked.

Then consider one of the biggest pitfalls: some unexpected technical problem might (will) appear at some point in the project. If (when) that happens, you don't want to end up clawing against an unresponsive or unwilling tech support wall. It might put the whole project to halt and delay it significantly.

The hardened, cynical project manager applies Murphy's Law and assumes that something like that will happen in this project as well and just toss in 2 or so weeks as "hassle margin". The larger the project, the more such time is needed.

But here, past experience market knowledge is valuable. Ok so there's a TI simple switcher that fulfils everything in the spec, it is cheap and there's a reference design. At a glance it seems like an obvious choice. But then you should recall "oh wait, my company isn't Microsoft-sized, so TI will give me the middle finger if I happen to need support". On the other hand you know that LT/Analog has excellent support, but more expensive parts. And suddenly you find yourself in a BOM cost vs time to market situation.

That's where you need to feel out/ask the EE who will do the design how confident they are in pulling off the project - how much switch regulator design have they done in the past? If it isn't a veteran designer, then they are more likely to need tech support. But if they are experienced, you might pick the company with cheap parts but non-existent support.

So lets assume you come up with something like 1 week spec/requirements gathering, 1 week design & component choices, 1 week PCB CAD, then prototype order, then 1 week test. The prototype order time is a black hole - how fast can you get PCBs, are you willing to pay extra for faster delivery, can you solder this yourself, if not - then how swift is your assembly contractor etc etc. Then once the prototype arrives, it almost never 100% correct. You'll find something that needs improving, there will most likely be at least one more board spin. Take this in account.

And then finally regulatory stuff and laws. Where in the world will it be sold? Does this need 3rd party EMC testing? EU regulations? FCC? UL? Local EMC requirements in South-East Asia? Do we need to spew RoHS paperwork all over the technical file? These can be major time and money sinks! So get them right from the start and make it clear with the customer who will pay for any testing. And involve a test house early on and book a time. Don't contact them at the point when the product is supposedly finished & working, they might have a full schedule and you might have to wait many weeks.


+1 for this answer, the best one in that it entirely focuses on time, while the other answers contain (good) things out of topics. Yours contains also practical advices. All the answers (except mine) describe in fact how to predict and manage the product development stages, what I summarized too quickly as "to detail the tasks" in my answer. Yes, of course, this is very important and is certainly of the greatest help for the OP. (continued) coquelicot‭ about 1 month ago

But when it comes to how evaluate the task "per se", all the answers invoke "experience", or "ask someone with experience". This is often not practical, especially for new entrepreneurs. This is where the rule I've given in my answer, and that I've statistically verified on me and others, could be useful. Notice It also includes Murphy's laws, and that's remarkable. coquelicot‭ about 1 month ago

@coquelicot Well, this time estimate has to be done by someone with domain experience, ideally an engineer with practical experience. I think all answers posted here come to that same conclusion. Lundin‭ about 1 month ago

@Lundin. I fully agree with you : time estimate HAS to be done by someone with domain experience (this is also an obvious consequence of my "rule 2"). But you know, so many things have to be done and are not, or are too hard to be. coquelicot‭ about 1 month ago


I'm actually an algorithmic engineer, not an electronic engineer. But your question is extremely general, and valid for every field of engineering. Also, it obviously depends upon the human and technical resources available to you. So, it cannot be answered at this level.

Nevertheless, according to my point of view that every question can be answered, it has only to be answered at the same level of generality as it has been asked, that is, the highest level.

Obviously, you have to detail each task separately to manage your project, and to arrange them in a list. Then you have to evaluate each task according to your human and technical resources, knowledge etc. That's as simple as that apparently, but that's also all the difficulty.

Now comes the secret, I mean my secret to do that, and believe it or not, it works incredibly well.

Rule 1: When you evaluate the time to allow for a task, do that as well and as carefully as you can. So far so good. Let t be the time allowed for this task.

Rule 2: Then ask yourself if you have already done some similar task, or if you have never done something similar. If you have already done something similar, multiply t by a factor between 1 and 2, according to the similarity of the task. But if you have never done something similar, multiply t by a factor of 5. Yes, you have correctly read, five time what you have evaluated. That's my secret.


Who has downvoted this answer? I usually don't ask this question, but it's so incredible to be downvoted for an answer to a question of this level of generality, and that is a matter of experience, that I cannot prevent myself. In addition my answer is much similar to that of Olin that has got 2 points. In fact, it could be argued that it is even better. What Olin said is impossible for a new entrepreneur: you have to take markets and get experience, whether or not you know about the subject. coquelicot‭ about 1 month ago

I don't think it's worthy of a downvote, so have an upvote from me. Olin Lathrop‭ about 1 month ago

Me too. It is a good answer. Adam Lawrence‭ about 1 month ago

Thank you, that helps! coquelicot‭ about 1 month ago


In my 15 yrs of intense deadline R&D for new state-of-the-art design in my 45yrs experience, estimation of time is inversely proportional to the number of mini failures from bad assumptions from which you learn to expand your understanding of everything. You don’t have to be brilliant, that helps immensely, in my case I needed to understand thousands of cases why designs fail with creative intuition and testing assumptions. e.g.

  • how much noise does an arc radiate for distance, geometry and wavelength of emitter-detectors?
  • which devices have negative resistance?
  • how do you estimate loss of phase margin?
  • how do nonlinear solutions improve or degrade performance.
  • how can you quickly verify assumptions? And which ones did you forget?

Incremental improvements always reduce the time from repetition of what you learn from others that works or your own successes of the same then factor a huge unknown depending on how skilled you are at realization of fundamentals in simulation. e.g. race conditions, ESR, DCR, impedance ratio of EMI crosstalk, PSRR, CM imbalance.

Logical inquisitive minds find solutions quickly from the library of professional solutions in high volume production. For me it was HP and Tek, then later Hitachi, Fujitsu and Toshiba. (There was a well known nationalistic reasons why new Japanese parts were never available until at least 5 yrs later and why “made in Japan” quickly reversed its connotation.) In 2 words, quality advantage.

Reading and reverse engineering are the necessary ingredients to rapid learning. Without a mentor, your time might be up to 10 times what it would take to repeat the same design next time. Our rule of thumb in the late 70’s was 2x to 3x what you optimistically expect then add documentation time to define EVERY measurable spec for interference and tolerance of all inputs and outputs as an “a priori” to every great design. That includes every environmental stress, mech.elect.climatic.aging...

A great design may follow your best specifications. Look at any datasheet to understand why.


Sign up to answer this question »