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

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

Parent

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

+4
−0

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?

History
Why does this post require attention from curators or moderators?
You might want to add some details to your flag.
Why should this post be closed?

1 comment thread

General comments (1 comment)
Post
+4
−0

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!

History
Why does this post require attention from curators or moderators?
You might want to add some details to your flag.

1 comment thread

General comments (7 comments)
General comments
Olin Lathrop‭ wrote about 4 years ago

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.

Adam Lawrence‭ wrote about 4 years 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.

Olin Lathrop‭ wrote about 4 years 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.

Lundin‭ wrote about 4 years 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‭ wrote about 4 years ago · edited about 4 years 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.

coquelicot‭ wrote about 4 years ago

Let be honest, there may be good surprises as Lundin said, but in general, if you don't consider competitors, sooner or later you are dead. This does not contradict the "honest assessments" claim of Olin though. My opinion is that you should be as competitive as possible, as far as you remain inside the limits of honesty.

Adam Lawrence‭ wrote about 4 years ago

It can certainly go both ways - overly aggressive and overly conservative estimation are both common enough.