1. Engineering Process IIFC Rich Stanek October 27, 2010

2. Outline History –What has changed in two years? Formal Engineering Process –Can we improve on how we do projects? Engineering Data Management –Why is it important? Benefits to IIFC Summary

3. Project Management (2008) Discipline of planning, organizing, and managing resources to bring about the successful completion of specific project goals and objectives within the project constraints. Project constraints: –Scope –Quality –Budget –Resources –Schedule

4. Project objectives should be S.M.A.R.T. (2008) S pecific M easurable A chievable R ealistic T imely (bounded) Very first hurdle to cross is to define exactly what is being built and when it will be delivered: Scope and Deliverables for the project In reality, project objectives can also include “softer” goals: Training for staff Industrial participation Improvement of infrastructure

5. Challenges of Collaboration (2008) Things that make it difficult and how to improve the situation –Distance Clear and regular communication is the key (weekly WebEx) Suggest setting up corresponding working teams at each institution –Different institution/industry conditions Need to understand the “fabrication plan” for components –Rules and Regulations (code requirements, export restrictions) Issue clear guidance on what is required, look for equivalence Things that make it easier –Additional resources Not limited by existing workforce or funding (at one institution) –Bring in new ideas from different “points of view” Design and fabrication elements can be improved –Each party is gaining something during the project execution Not just doing work for somebody  intellectual investment Must address the issue of “risk management”

6. Other Issues (2008) Document Management System –How are documents stored –Concurrent engineering puts more demand on DMS Supplying all the necessary documentation –Need to know up front what is required (hard to extract information “after the fact”) Part/material availability and standardization –Advantages to staying consistent with critical components, instrumentation, controls… –Trade off “easily available for partner” vs. “consistent with existing equipment”

7. Summary (2008) Collaborative projects have many advantages Project Management of these types of projects can be more difficult but is made easier by having –Clear and regular communication (No Surprises) –Defined scope & deliverables (Specification/Requirements Doc) –Joint Design Reviews –Opportunities for on-site inspections and defined QC checks –Project schedule with milestones updated each month In the end, these projects are successful because each party is dedicated to completing the work and each receives some benefit from being involved

8. Flash Forward to 2010 Difficulty of doing projects in collaboration is not limited to long distance remote sites Sometimes even within a Lab there are the same issues –Distance can “seem” far whether its 1 mile or 7500 miles Level of oversight and adherence to consistent engineering standards is being ratcheted up –No room for errors that could have been easily avoided Funding is tight and large projects are more costly –Collaboration is not only desirable but necessary Technology is challenging and technical input from fellow collaborators is valued

9. Defining the Problem At Fermilab, we were/are experiencing: Lack of consistency across Divisions –“Islands of Excellence” Lack of formal and organized documentation –Requirements and Specifications not written consistently –Analysis difficult to locate “after the fact” –Logic for why decisions were taken not documented –Risks not quantified nor kept up to date –Quality Control not enforced consistently Lack of communication of our Lessons Learned –Reinventing the wheel –Repeating mistakes

10. Solving the Problem Fermilab has initiated two corrective actions: Adopted a formal Engineering Policy Manual –Promote consistency and attention to the engineering process In the process of implementing an Engineering Data Management System (Teamcenter)

11. Engineering Policy Manual Engineering Manual (purposely brief ~33 pages) http://www.fnal.gov/directorate/documents/FNAL_Engineering_Manual.pdf –Intended to be a template for steps that must be followed  not too prescriptive –Expert driven system but with consistent process –Emphasis placed on Lead Engineer & Dept. Head –Works hand-in-hand with mentoring Graded approach  not all projects treated at highest level of formality (risk-based determination) Describes the process from beginning to end –Including how the system should operate/be maintained No matter how formal the process is defined  success still depends on people Appendices (shows examples > 200 pages) http://www.fnal.gov/directorate/documents/FNAL_Engineering_Manual_Appendices.pdf

12. 9 Steps to the Process Requirements and Specifications –Defines objectives and requirements Engineering Risk Assessment –Determine level of rigor required for documentation and review based on technical, cost, and schedule risks Requirements and Specification Review –Describes the process of reviewing adequacy of the specification System Design –Explains the steps of the design phase Engineering Design Review –Describes the required reviews the design must undergo Procurement and Implementation –Explains the process followed to make the design into reality Testing and Validation –Explains the process of verifying that the fabricated design meets requirements Release to Operations –Explains operating and maintenance documentation required Final Documentation –Describes documentation required before closing out the project

13. Some Definitions FRS – Functional Requirements Specification –Describes the programmatic or project needs and/or requested behavior of a system or component  functionality –Scope of Work along with constraints, interfaces, assumptions, overall requirements (technical, safety, QC, testing, operations) –Conveys what is needed but not how it is achieved Functional Requirements Specification Guidelines for SRF Projects TRS – Technical Requirements Specification –Relates back to FRS Takes functionality and converts to technical requirement –Much more detailed and specific –Still only the specification  NOT the Final Design –Could go to a vendor with TRS for a “Design & Build” Need to write equivalent Technical Requirements Specification Guidelines

14. More Definitions CDR – Conceptual Design (Report) –Early stage of System Design  CAD 3D models, overall functionality of design, interfaces, constraints… TDR – Technical Design (Report) –This is the design  includes CAD models, drawings, analysis –Everything needed to build the component –Full conformance to TRS –Formal approval to proceed (via various Design Reviews) Fabrication Plan –Describes how the component/system will be fabricated Who is responsible for what? –How will QC be handled? Are there mandated inspections and hold points? –Fabrication schedule Including testing and validation

15. Risk Evaluation 15 Areas to be evaluated A.Technology B.Environmental Impact C.Vendor Issues D.Resource Availability E.Quality Requirements F.Safety G.Manufacturing Capability H.Schedule I.Interfaces J.Experience/Capability K.Regulatory Requirements L.Project Funding M.Project Reporting Requirements N.Public Impact O.Project Cost

16. Examples of Quantified Risk If project has a risk score of 5 in any risk element (A-G) or total for the risk score (H-O) is greater than 25  more formal control

17. Technical Reviews Requirements and Specification Review –Formal approval of Documents (FRS, TRS) Engineering Design Reviews –Preliminary Design Review –Final Design Review with approval to proceed Fabrication Reviews –Review of Fabrication Plan –QC Inspections/Reviews held at fabrication site Operations Review –Operational Readiness Clearance (ORC) Assumes: –Working meetings of the project team occur often –Documentation generated as work/analysis is performed

18. Testing & Validation Verifying that a component or system satisfies the requirements Use test methods based on industry accepted standards where available

19. Final Documentation Pulling all the documentation together so that there is traceability for the engineering process followed This is where an EDMS (like Teamcenter) helps tremendously

20. Teamcenter EDMS What is Teamcenter? –Software tool to help us do our jobs better –Commercial, Product Lifecycle Management software (Siemens) –Document and Process-centric relational database (Oracle) –Used by many large, internationally based manufacturing companies, i.e. auto industry, aviation –Also used by DESY for the XFEL project (TC Enterprise) –CERN study on EDMS identified Teamcenter as an upgrade Who will it affect? –Technical, procurement and fabrication staff –Used for all major projects and for internal engineering data –Allow access for collaborators  for project-related engineering documents

21. Teamcenter EDMS What are some of the features? –Access control by user name –Document revision control and tracking –Ability to relate documents to multiple projects or components –Can hold any type of document –Strong integration with NX, AutoCAD, MS Office, MS SharePoint –Very strong search capabilities –Must load metadata properly –Visualization of CAD files without opening CAD program –Do not have to be a CAD expert to see parts/assemblies What type of documents will be stored? –Focus on engineering documents and data –CAD files, specifications, requirement documents, engineering calculations & analysis, safety documents, QC reports, and vendor data

22. Teamcenter & the Eng process

23. Organizational View 23

24. 24 CAD DATA MANAGEMENT NX, AutoCAD Drawing & 3D ACCESS CONTROL Information Security INTEGRATED VISUALIZATION Access 2D & 3D Drawing Sectioning / Measure / Clearance Check No CAD Tool Required COLLABORATION Share Documents, Conference BOM MANAGEMENT Design Re-use Variants / Options RELEASE MANAGEMENT Engineering Release Process Teamcenter Single Source of Product Data MS Office Integration Functional View

25. What are the Benefits to IIFC Following the formal Engineering Process –Better definition of the scope and requirements –Quantified risk helps to focus attention to details –Documentation will be more consistent –Design Reviews lend confidence to ongoing work –Helps to assure everyone is satisfied with the end product Working in Teamcenter with NX CAD (common systems) –Access to documentation/answers to questions immediately –Feedback on design choices can be quicker –Able to view engineering analysis for similar projects –Use of NX “common parts” –Ability to do concurrent engineering

26. Summary Collaborative projects have many advantages –Still true. Maybe now more than ever. Communication is the key Formal engineering process can provide a solid path to follow and help provide consistency –Must fight the urge to short circuit the process This collaboration can be very beneficial for the India Institutions and Fermilab Success still comes down to people working together