EEVblog Electronics Community Forum

Electronics => Projects, Designs, and Technical Stuff => Topic started by: tmadness on October 26, 2020, 09:23:12 pm

Title: Ideas on conducting complex-design reviews
Post by: tmadness on October 26, 2020, 09:23:12 pm
Every electrical engineering firm conducts design reviews. Some do it better than others. Lets say that there's a reasonably complex design, say 8+ layer board 1000+ components, analog components + digital components etc. Medium  size firm 20-30 relevant engineers, I am the lead for this project. The design has moved from proof of concept to prototype to now, REV A. I have 5 engineers who hare now pretty familiar with the project, they have helped me squash a number of bugs, but, I am the sole designer: from design to layout to some firmware (higher level stuff is another department).
What have your experiences been in a similar situation? what review systems worked? what didn't ? Should I assign subsections to review to other engineers based on their experience?
Title: Re: Ideas on conducting complex-design reviews
Post by: StefanHamminga on October 27, 2020, 08:57:05 am
My 2ยข: Interview your reviewers, make a checklist (of the underlying design criteria). Repeat regularly to improve the checklist.
Title: Re: Ideas on conducting complex-design reviews
Post by: sandalcandal on October 27, 2020, 12:30:14 pm
There's an entire discipline focused on this task (and associated activities) https://en.wikipedia.org/wiki/Systems_engineering

Even then systems engineering is just a set of tools. The real tool and the one that really matters is the one behind the wheel.

Level of control and bureaucracy depends on the project and how much risk needs to be mitigated.
Having high level systems design for any remotely complex project helps keep things organised and in check.
Systems design is particularly helpful for splitting up and delegating work effectively but has potential to be done poorly and hamper overall progress; as the sole designer/lead you're probably the most qualified to be handling this.
An exhaustive, enumerated list of system requirements is excessive in most non-critical applications, having an organised list of requirements is still handy though. I'd split up customer/user requirements vs subsystem specifications at the very least.
Like any activity involving multiple individuals, good communication is number one. If nothing else, the tools used in systems engineering are communication tools.
There's usually a trade-off between time and effort used to create documentation and other communications vs the benefits they bring in terms of lubricating and directing work to be more efficient.