Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations cowski on being selected by the Eng-Tips community for having the most helpful posts in the forums last week. Way to Go!
Designing reviews stages wuestion 3
- Thread starter tota123
- Start date
-
2
- #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.
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.
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.
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! faq731-376 forum1529 Entire Forum list
> 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! faq731-376 forum1529 Entire Forum list
thaidavid40
Structural
The ACOE has a whole manual addressing this question. It can be found for free here: Link
Dave
Thaidavid
Dave
Thaidavid
-
1
- #6
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
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
- Status
