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

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.

posted about 4 years ago

CC BY-SA 4.0

4y ago

coquelicot‭

704 reputation 17 33 90 142

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.

posted about 4 years ago

CC BY-SA 4.0

4y ago

Olin Lathrop‭

8059 reputation 18 332 961 469

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!

posted about 4 years ago

CC BY-SA 4.0

Adam Lawrence‭

141 reputation 0 2 14 0

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.

posted about 4 years ago

CC BY-SA 4.0

Lundin‭

1553 reputation 35 55 279 70

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.

posted about 4 years ago

CC BY-SA 4.0

4y ago

TonyStewart‭

391 reputation 0 46 36 82