Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs
Community Proposals
Community Proposals
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Q&A

Post History

83%
+8 −0
Q&A How to estimate time of completion while developing an electronic product?

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 produ...

posted 4y ago by Olin Lathrop‭  ·  edited 4y ago by Olin Lathrop‭

Answer
#2: Post edited by user avatar Olin Lathrop‭ · 2020-10-21T16:25:35Z (about 4 years ago)
  • 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 take 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.
  • 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.
#1: Initial revision by user avatar Olin Lathrop‭ · 2020-10-21T16:05:21Z (about 4 years ago)
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 take 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.