When it comes to plan and execute hardware related projects in your organization, do you follow a specific process flow? (like e.g. requirement definition, design definition, test plan). If so, do you have any recommendation or reference I could use?
\$\begingroup\$
\$\endgroup\$
5
-
\$\begingroup\$ this seems like it could be community wiki, as no one answer will ever be correct and having people constantly posting and updating methods might fit it. \$\endgroup\$– KortukCommented Jan 22, 2011 at 15:13
-
1\$\begingroup\$ I’m voting to close this question because it's not about electrical engineering, but project management. It may or may not be on-topic at pm.stackexchange.com. \$\endgroup\$– LundinCommented Jun 9, 2020 at 8:44
-
\$\begingroup\$ @Lundin, its generally understood that the questions from SE.EE 1.0 site not closed because they had different guidelines back then. However, tag management does need to be done on these questions. We also cannot move questions older than 1 month to a different site. \$\endgroup\$– Voltage Spike ♦Commented Jun 9, 2020 at 18:10
-
\$\begingroup\$ @VoltageSpike I made a meta thread about cleaning up this tag here: electronics.meta.stackexchange.com/questions/7219/…. I suppose we could re-tag old questions that only have this tag with some other nonsense tag...? \$\endgroup\$– LundinCommented Jun 10, 2020 at 6:37
-
\$\begingroup\$ @Lundin Thanks for cleaning up the tags, Yes, there will need to be a substitute tag, I chose hardware for this one \$\endgroup\$– Voltage Spike ♦Commented Jun 10, 2020 at 15:33
Add a comment
|
2 Answers
\$\begingroup\$
\$\endgroup\$
As anything, the answer really depends on what the project is and in which environment you're developing. The process will be different if it's a senior project or a commercial board bring-up, for example. Since you have not given details about your particular environment, here are some general unordered guidelines I can think of that may help:
- Write down a plan and show it to anyone who would look at it -- take note of their advice and adopt what seems logical to you. There's definitely room for personal preference here.
- Create milestones for the project and estimate how long they will take to achieve.
- Decide on a time multiplier (this ranges from x2 to x5 and depends on your experience) and apply it to your timing predictions. This will give you a buffer, and ultimately be more realistic -- most people grossly underestimate the time and effort it takes to accomplish something, and many things are out of your control.
- Document all the problems you've encountered, and how you solved them. This will help you in the future, and in writing a report if you're required to.
- Getting supplies takes time, and sometimes stocks run out just as you want to place an order. When you design a component into your system, make sure you can source it reliably!
I hope this helps a little bit, and good luck.
\$\begingroup\$
\$\endgroup\$
1
- Define product opportunity.
- Define architecture, review, define implementation.
- Schematic capture and review
- PCB design and review
- Build
- Debug
- See if wish to launch product
answered Jan 21, 2011 at 15:55
-
1\$\begingroup\$ I'd add extra emphasis to 2. Agile methods don't work as well with hardware as they do with software, so time spent on a solid specification up front can save boatloads of time later. For novel products, there might also be some R&D steps toward the beginning to evaluate new technology or methods. \$\endgroup\$– bt2Commented Jan 22, 2011 at 16:37