In the final semester of my undergrad we were required to work on a project that would be equivalent to the capstone project here in NJIT. Each team was assigned an Internal guide who would help us plan our project and advice us on how to move forward with our project idea. During our first meeting my internal guide heard my teams idea and asked each of us to research and write a synopsis of the topic we were working on and and come up with our own individual unique idea to make the project better. We were asked to present our finding in the next meeting. The idea that everyone mutually agreed on was then chose by the group. Each group member was asked to come up with a design of the entire project including materials and methods, map out the time it would take to complete the project with a complete understanding of what we were working on. This lead to the design review meeting with the project manager (our guide) who then helped us pick out the best protocol for our project. This way made sure that each group member was actively involved in the project and made a contribution to the project to the best of their abilities. This also indicated the pivotal role of a project manager in guiding their team member to move ahead with the project design.

In my experience working in the industry, I often took part in design review meetings. Many of the meetings resulted in a change in the design or part of the design. I expected it to be more like a meeting where one person presents the proposed design and then the team discusses the items presented. What I found out, was that each design element or note in the specification was being scrutinized for clarity, vocabulary, phrasing, etc. It was never about one item, and in the instances where it would be about one item, without fail, the team would move forward to discussing the whole specification. This is due to the fact that if there is one thing changing about the specification, not only can it affect other parts, but also any edits that need to be made, can be made, as the specification as a whole is being edited. This was very helpful because then there wouldn't be multiple projects open for small non-business-critical items. Instead, one business-critical project can be opened and can address the critical items as well as the non-critical items in one go.

I've held one design review meeting throughout my current role. Similar to a lot of people I've seen answer under this question, I think this meeting is mostly a formality (depending on how complicated the topic is under review). My review encompassed updating designs and work instructions for an R&D process. I sent out the documents two weeks ahead of time and gathered updates and adjusted accordingly. The meeting was mainly to make sure that quality and R&D reviewers aligned with all of the changes being made. This went particularly well because all of the parties involved were notified ahead of time in order to give a chance to respond and make comments.

Hello,

During my time in senior capstone design, we have had a couple design review sessions in which a few teams participated. We one by one went through a team's requirements or test plan document, stopping at sections that did not make complete sense. The receiving team was allowed to comment or reply to elucidate any concerns, though for the most part, teams took the critiques without comment. Although the design review was helpful in some areas, I felt that the most comments stemmed from a misunderstanding of the topic/technology at hand. I imagine in a industry setting, the design reviews are conducted between people that are involved in the project and/or have an understanding of the goal of the project. Our design reviews resulted in comments that aimed to make the project language more broad and understandable to the average person who is not involved.

I would change this design review to be conducted with our team, our capstone course advisor, our project advisor, and the PhD student that our project is going to help. With this concise group of people that are knowledgeable and aware of our goals, we can make productive changes to our document language and design. 

During my senior capstone project, we were assigned to have a mock design review project. In this project each team member was assigned a role like a moderator or a scribe to note down the criticisms of our design report. About a week or two prior, we were to send our design report to the professor to send out to the other project groups. Before the overall design meeting we were to read each team's design report and make corrections and/or improvements. Once we made our comments we were ready to say them once their paper was the main one being discussed during the meeting. The scribe of the team being reviewed would take note of the revisions the class suggested and then they would take them to make the final revisions of their papers. It went as I expected. The only thing I might change for productivity is to maybe send in the revisions ahead of time to each team and then during the review go over those important ones. Most revisions needed to be done, at least in our capstone class, were small spelling and grammar mistakes and there were revisions for image captions so it was a longer design meeting for spelling and grammar.