INSIGHTVolume 16, Issue 3 p. 23-24 Special Feature When One Size Doesn't Fit All: How Important Is Good Tailoring? Richard Beasley, Richard Beasley Rolls-Royce PLCSearch for more papers by this authorChris Unger, Chris Unger GE HealthcareSearch for more papers by this authorDerek Price, Derek Price Network Rail Infrastructure ProjectsSearch for more papers by this authorDouglas Hamelin, Douglas Hamelin Idaho National LaboratorySearch for more papers by this authorKerry Lunney, Kerry Lunney Thales AustraliaSearch for more papers by this authorMeaghan O'Neil, Meaghan O'Neil MIT, System Design and ManagementSearch for more papers by this authorAnne O'Neil, Anne O'Neil INCOSE Director for Industrial OutreachSearch for more papers by this author Richard Beasley, Richard Beasley Rolls-Royce PLCSearch for more papers by this authorChris Unger, Chris Unger GE HealthcareSearch for more papers by this authorDerek Price, Derek Price Network Rail Infrastructure ProjectsSearch for more papers by this authorDouglas Hamelin, Douglas Hamelin Idaho National LaboratorySearch for more papers by this authorKerry Lunney, Kerry Lunney Thales AustraliaSearch for more papers by this authorMeaghan O'Neil, Meaghan O'Neil MIT, System Design and ManagementSearch for more papers by this authorAnne O'Neil, Anne O'Neil INCOSE Director for Industrial OutreachSearch for more papers by this author First published: 23 June 2015 https://doi.org/10.1002/inst.201316323AboutPDF ToolsRequest permissionExport citationAdd to favoritesTrack citation ShareShare Give accessShare full text accessShare full-text accessPlease review our Terms and Conditions of Use and check box below to share full-text version of article.I have read and accept the Wiley Online Library Terms and Conditions of UseShareable LinkUse the link below to share a full-text version of this article with your friends and colleagues. Learn more.Copy URL Share a linkShare onFacebookTwitterLinked InRedditWechat No abstract is available for this article. Volume16, Issue3September 2013Pages 23-24 RelatedInformation

AbstractFrom its inception in the defense and aerospace industries, SE has applied holistic, interdisciplinary tools and work‐process to improve the design and management of “large, complex engineering projects.” The traditional scope of engineering embraces the design, development, production, and operation of structural, hardware, and software systems, and SE, as originally conceived, falls within that scope.While this “traditional” view has expanded over the years to embrace wider, more holistic applications, much of the literature and training currently available is still directed almost entirely at addressing the large, complex, NASA, defense, and other industry systems wherein the “ideal” practice of SE provides the cradle‐to‐grave foundation for system development and deployment. Under such scenarios, systems engineers are generally viewed as an integral part of the system and project life‐cycle from conception to decommissioning. In smaller, less complex, and far less “ideal” applications, SE principles are equally if not more applicable to a growing number of systems and projects that need to be “rescued” from overwhelming challenges that threaten imminent failure.The medical profession provides a unique analogy for this latter concept and offers a useful paradigm for tailoring our “practice” of SE to address the unexpected dynamics of applying SE in the real world. In short, we can be much more effective as systems engineers as we change some of the paradigms under which we teach and “practice” SE.

AbstractMany SE practitioners, particularly those who are new to the discipline, can become overwhelmed by the high‐end tools and techniques often viewed as necessary for conducting “real” systems engineering. Even though such tools and techniques are common in our applications of systems engineering, INL systems engineers have a long history of using simple, tailored methods to achieve significant success on complex projects. This half‐day (4‐hour) tutorial is designed to introduce new‐comers and seasoned practitioners alike to the overall systems engineering process as it relates to typical project life‐cycle phases and to present a few of the “simple” tools (with practical examples) that we have found useful in conducting systems engineering work. Ultimately, attendees will learn how to use items as simple as a white board, pad of engineering paper, and standard desktop software to help a project get from concept to system design without the need for high‐end tools and technologies.

Integrated Product Development Teams (IPDT) are a key component of any systems engineering (SE) application, but since they are formed primarily from technical considerations, many IPDTs are far less productive than they otherwise could be. By recognizing specific personality types and skill sets, a random group of 'technical' individuals can be structured to become a highly effective team capable of delivering much more than the sum of its members.

INSIGHTVolume 14, Issue 3 p. 9-10 Special Feature INCOSE's Twenty-First Annual International Symposium Douglas Hamelin, douglas.hamelin@inl.gov Search for more papers by this authorBob Kenley, robert.kenley@incose.org Search for more papers by this author Douglas Hamelin, douglas.hamelin@inl.gov Search for more papers by this authorBob Kenley, robert.kenley@incose.org Search for more papers by this author First published: 23 June 2015 https://doi.org/10.1002/inst.20111439AboutPDF ToolsRequest permissionExport citationAdd to favoritesTrack citation ShareShare Give accessShare full text accessShare full-text accessPlease review our Terms and Conditions of Use and check box below to share full-text version of article.I have read and accept the Wiley Online Library Terms and Conditions of UseShareable LinkUse the link below to share a full-text version of this article with your friends and colleagues. Learn more.Copy URL Share a linkShare onEmailFacebookTwitterLinked InRedditWechat No abstract is available for this article. Volume14, Issue3September 2011Pages 9-10 RelatedInformation

The “crown jewels” of nuclear energy research facilities (i.e., hot cells, analysis systems, and scientists) have been centered at the Idaho National Laboratory for over 40 years, but in recent years, emphasis and funding for nuclear fuel research and development have declined to adversely affect the readiness and effectiveness of research facilities and equipment. Conversely, the current national nuclear renaissance forces the need for immediate enhancements in facilities, equipment, capabilities, and staff for the postirradiation examination (PIE) of nuclear fuel. PIE characterizes the “burn‐up” and structural integrity of fuel elements and defines the effectiveness of new fuels/alloys in search for optimum fuel burn‐up and alloys for current and next generation nuclear reactors. This paper details how a team of system engineers adapted simple system engineering tools and techniques for a customer unfamiliar with the power and effectiveness of system engineering, to achieve project success.

The INCOSE Systems Engineering Handbook is the official INCOSE reference document for understanding systems engineering (SE) methods and conducting SE activities. Over the years, the Handbook has evolved to accommodate advances in the SE discipline and now serves as the basis for the Certified Systems Engineering Professional (CSEP) exam. Due to its evolution, the Handbook had become somewhat disjointed in its treatment and presentation of SE topics and was not aligned with the latest version of International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC) 15288:2008, Systems and Software Engineering. As a result, numerous inconsistencies were identified that could confuse practitioners and directly impact the probability of success in passing the CSEP exam. Further, INCOSE leadership had previously submitted v3.1 of the Handbook to ISO/IEC for consideration as a Technical Report, but was told that the Handbook would have to be updated to conform with the terminology and structure of new ISO/IEC15288:2008, Systems and software engineering, prior to being considered.

AbstractApplying basic systems engineering (SE) tools to the mission analysis phases of a 2.5‐million dollar biomass pre‐processing project for the U.S. Department of Energy directly assisted the project principal investigator understand the complexity and identify the gaps of a moving‐target project and capture the undefined technical/functional requirements and deliverables from the project team and industrial partners. A creative application of various SE tools by non‐aerospace systems engineers developed an innovative “big picture” product that combined aspects of mission analysis with a project functional flow block diagram, providing immediate understanding of the depth and breath of the biomass preprocessing effort for all team members, customers, and industrial partners. The “big picture” diagram became the blue print to write the project test plan, and provided direction to bring the project back on track and achieve project success.

AbstractZoned analysis (ZA) is a decomposition methodology, which ultimately evolves into a graphical “big picture” of a project. This methodology maps the “journey” a systems engineer uses during the mission analysis phase to facilitate collaboration of team members, enhance management understanding of the project, show team members their responsibilities, link requirements to deliverables, and aid in the gap analysis between what is wanted and what is tasked. A ZA appears as a bull's‐eye or target with partitioned pie‐shaped sections emanating from the center circle to outer circles, or zones. The title of the project or program is placed in the center zone. Subsequent partitioned zones facilitate the decomposition hierarchy of the project, with the outer‐most zones or elements evolving as terminal elements or deliverables. This paper show how a ZA was used to flesh out the details in between top‐down and bottom‐up approaches during the mission analysis phase.

Zoned analysis (ZA) is a graphical decomposition methodology initially practiced in academia to ensure that all aspects of a curriculum were addressed with lesson plans, but this method has been adapted as a systems engineering tool with multiple end uses to facilitate collaboration of team members, enhance management understanding of the project, show team members their responsibilities, link requirements to deliverables, and aid in gap analysis. A ZA appears as a bull's‐eye or target with partitioned pie‐shaped sections emanating from the center circle to outer circles. The title of the project or program is placed in the center circle. Subsequent partitioned circles, or zones, facilitate the decomposition hierarchy of the project with the outer‐most zones or elements evolving as terminal elements or deliverables. This article shows examples of ZAs and provides instruction on how to construct a ZA.