INTELLIGENT WORK FORUMS
FOR ENGINEERING PROFESSIONALS

Log In

Come Join Us!

Are you an
Engineering professional?
Join Eng-Tips Forums!
  • Talk With Other Members
  • Be Notified Of Responses
    To Your Posts
  • Keyword Search
  • One-Click Access To Your
    Favorite Forums
  • Automated Signatures
    On Your Posts
  • Best Of All, It's Free!

*Eng-Tips's functionality depends on members receiving e-mail. By joining you are opting in to receive e-mail.

Posting Guidelines

Promoting, selling, recruiting, coursework and thesis posting is forbidden.

Jobs

Designing reviews stages wuestion

Designing reviews stages wuestion

(OP)
Hello,

Some capital projects asks for design reviews in 30%, 60%, 90&, 100% while others asks for 50% and 100% only.

what is the difference and when we follow option 1 and when is 2?


thank you

RE: Designing reviews stages wuestion

2
It depends on the expectations of the individual client, but typically the major difference is the level of detail on the drawings. 30% may be referred to "schematic design" where you show the general layout and concept of the project. 50% and 60% are usually the "design development" phase where you provide a few details, but they may not be completely tailored to your project yet. 90% and 100% are usually drawings issued for construction or permits and are complete or substantially complete. The purpose for the various reviews is so the owner can see your progress and provide comments and input throughout the design process. The percent complete is rather arbitrary. For instance, no one will argue that your drawings are only 50% complete if you claim they are 60% complete.

RE: Designing reviews stages wuestion

It costs time and money to put design progress submittals together, but they provide the client and stakeholders a chance to weigh in thereby reducing the risk of do-overs. In my experience, the number of submittals depends on the size and complezity of the project.

With each design progress submittal, it is a good idea to include a letter containing the following information: description of the anticipated construction scope of work (written in a simple way so all of the stakeholders can understand); list of drawings number and titles, list of specification sections, discussion of any critical issues, and notes and questions for specific reviewers. In other words, make it as easy as possible for stakeholders to weigh in, and make sure to document the review, comments and resolution in your files.

RE: Designing reviews stages wuestion

In classical Systems Engineering, there are a number of reviews:

> System Requirements Review (SRR) to verify that the customer and contractor are on the same page w.r.t. interpretation of requirements and functionality

> Preliminary Design Review (PDR) to review the preliminary design -- presentation of a design that's compliant to all requirements, prior to detailed design

> Critical Design Review (CDR) to review to the completed design prior to fabrication

> Test Readiness Review (TRR) to review status of hardware prior to actual acceptance testing -- this would be most likely equivalent to something that done prior to building inspection

TTFN (ta ta for now)
I can do absolutely anything. I'm an expert! https://www.youtube.com/watch?v=BKorP55Aqvg
FAQ731-376: Eng-Tips.com Forum Policies forum1529: Translation Assistance for Engineers Entire Forum list http://www.eng-tips.com/forumlist.cfm

RE: Designing reviews stages wuestion

The ACOE has a whole manual addressing this question. It can be found for free here: Link
Dave

Thaidavid

RE: Designing reviews stages wuestion

IRstuff,
Have you actually SEEN a company successfully follow the Systems Engineering approach?
My current experience is that the customer's engineers write the SRR in isolation, and only managers go to the PDR.
When the CDR is presented, half the people in the room are totally gobsmacked, and the other half start re-writing the SRR to mean what they really wanted.
I was once on a project where the engineering kick-off happened with the SRR at revision "C". By the time testing began 3 years later, the SRR was at revision "K".

Griping aside,
I don't believe that Systems Engineering is inherently bad. It just relies on everyone paying very close attention to the details and communicating with each other before commitments are made. When people shrug because they don't know what they want, and write something vague, trouble is soon to come!

STF

Red Flag This Post

Please let us know here why this post is inappropriate. Reasons such as off-topic, duplicates, flames, illegal, vulgar, or students posting their homework.

Red Flag Submitted

Thank you for helping keep Eng-Tips Forums free from inappropriate posts.
The Eng-Tips staff will check this out and take appropriate action.

Reply To This Thread

Posting in the Eng-Tips forums is a member-only feature.

Click Here to join Eng-Tips and talk with other members!


Resources


Close Box

Join Eng-Tips® Today!

Join your peers on the Internet's largest technical engineering professional community.
It's easy to join and it's free.

Here's Why Members Love Eng-Tips Forums:

Register now while it's still free!

Already a member? Close this window and log in.

Join Us             Close