WO2005031710A2

WO2005031710A2 - Technology assessment, planning, and risk management process

Info

Publication number: WO2005031710A2
Application number: PCT/US2004/031324
Authority: WO
Inventors: Richard L. Brown
Original assignee: Brown Richard L
Priority date: 2003-09-25
Filing date: 2004-09-24
Publication date: 2005-04-07
Also published as: WO2005031710A3

Abstract

A method for technology assessment comprises developing a customer-driven requirement (202) that satisfies a customer expectation (102), developing a design concept/solution (108) for a system that satisfies the customer-driven requirement (202), identifying one or more science/engineering capabilities (110) needed to bring the design concept/solution (108) to fruition, and assigning a current capability readiness level for each of the one or more science/engineering capabilities (110), the current capability readiness level indicates the current capability of each of the one or more science/engineering capabilities (110) to validate the customer-driven requirement (202) and enable the design concept/solution (108).

Description

TECHNOLOGY ASSESSMENT, PLANNING, AND RISK MANAGEMENT PROCESS

STATEMENT REGARDINGFEDERALLY SPONSORED RESEARCH ORDEVELOPMENT This invention was made with U.S. Government support under contract number NAS8-02053 awarded by the National Aeronautics and Space Administration

(NASA). The government has certain rights in this invention.

Related Application The application claims the benefit of priority under 35 U.S.C. § 119(e) of U.S. Provisional Application Number 60/413,338, filed on September 25, 2002, the entirety of which is incorporated herein by reference.

BACKGROUND Field The present invention relates generally to management processes and, in particular, to a process for the definition, planning, and management of technology, determination of technology readiness for application and for risk management.

Description of the Related Art Demands in product performance, reliability and sophistication have escalated in recent decades. This has resulted in even more demanding customer-driven, engineering requirements, which in turn can significantly over-extend the existing engineering technology base capabilities. The inability to comprehensively identify these "strains" (technology shortfalls, associated uncertainties and risks) in the engineering technology base capabilities throughout the definition and design, development, verification, introduction and use cycles of a system or product, or portion(s) thereof, is a critical problem. Another problem is the inability to more objectively determine the technology maturation progress. Over the years, several methods/approaches, including personal experience and various forms of "gap" analysis, have been used to address this problem. Conventional technology readiness level scales (such as that introduced by Mankin of NASA in the early 1980's) have been widely used. A major drawback to the existing technology readiness level scales is their definitions. In particular, the definitions of the levels have varied widely and a consistent method that identifies and considers the basic or root sources of uncertainty involved in the levels does not exist. Techniques such as the Analytical Hierarchical Process (AHP) and Quality Functional Deployment (QFD) have been used to gain insight into critical technology needs, priorities and risks. These have had varying degrees of success in identifying needed critical technologies and reducing the number of unanticipated problems, but have not resolved the underlying problem of consistently identifying the root sources of uncertainty in a system. Conventional methods/approaches typically look at the "gaps" between performance, design, validation, fabrication, and verification processes, and operations characteristics needed to meet the customer-driven requirements and the past and current design and development experience bases. From this, the critical technologies and risks associated with bringing a new product to fruition are identified. However, these conventional methods/approaches lack the structure, comprehensiveness, and specificity needed to identify a specific suit of technology shortfalls and risks across the spectrum of disciplines in the engineering technology base (e.g., materials and materials processing, design, analysis and validation capabilities, fabrication and verification capabilities, life and reliability, and fielding and operations capabilities) relative to customer-driven design requirements. These conventional methods/approaches also fail to provide a structured, systematic method/process to iterate and integrate the information from the various designers and discipline specialists into a unified, consistent result and to synthesize specific critical enabling engineering technology base technologies and risks across the spectrum of disciplines. Moreover, these methods/approaches do not provide an accurate, consistent method for establishing technology readiness levels. Experience shows that the resulting technological and programmatic problems usually surface during or after development when they are costly to resolve. SUMMARY In one embodiment, a method for technology assessment comprises developing a customer-driven requirement that satisfies a customer expectation, developing a design concept/solution for a system that satisfies the customer-driven requirement, identifying one or more science/engineering capabilities needed to bring the design concept/solution to fruition, and assigning a current capability readiness level for each of the one or more science/engineering capabilities, the current capability readiness level indicates the current capability of each of the one or more science/engineering capabilities to validate the customer-driven requirement and enable the design concept/solution. hi another embodiment, a method for technology assessment, planning and risk management comprises developing a customer-driven requirement that satisfies a customer expectation, developing at least one macro-technology that satisfies the customer-driven requirement, identifying a plurality of micro-technologies needed to bring the macro-technology to fruition, and assigning a current capability readiness level for each of the plurality of micro-technologies, the current capability readiness level indicates the current capability of each of the micro-technologies to validate the customer-driven requirement and enable the macro-technology. These and other embodiments of the present invention will also become readily apparent to those skilled in the art from the following detailed description of the embodiments having reference to the attached figures, the invention not being limited to any particular embodiment(s) disclosed.

BRIEF DESCRIPTION OF THE DRAWINGS The following drawings incorporated in and forming a part of the specification illustrate, and together with the detailed description serve to explain the various aspects of the implementation(s) and/or embodiments of the invention and not of the invention itself. Figure 1 illustrates a flow diagram of an exemplary Technology Assessment, Planning and Risk Management Process (TAPRMP), according to one embodiment of the present invention. Figure 2 illustrates a block diagram of the tasks comprising a Goal Decomposition Phase, according to one embodiment of the present invention. Figure 3 illustrates an exemplary technology readiness assessment matrix, according to one embodiment of the present invention. Figure 4 illustrates another exemplary technology readiness assessment matrix, according to one embodiment of the present invention. Figure 5 illustrates a block diagram of the tasks comprising an Functional requirements and Design Concept/Solution Development, according to one embodiment of the present invention. Figure 6 illustrates a flow diagram of one embodiment of the steps comprising a Capability Assessment, Shortfall Identification and Readiness Determination Task, according to the present invention. Figure 7 illustrates an exemplary technology readiness assessment matrix showing the assessment process, according to one embodiment of the present invention. Figure 8 illustrates an exemplary uniform set of CRL definitions/scale for aerosciences, a typical micro-technology suitable for CRL determination, according to one embodiment of the present invention. Figure 9 illustrates an exemplary TRL scale depicting a plurality of TRL levels and associated definitions for a system hardware/software and/or technology readiness determination. Figure 10 illustrates a flow diagram depicting the activities for improving the accuracy and utility of a TRL, according to one embodiment of the present invention. Figure 11 illustrates a graphical representation of an exemplary 3 -dimensional continuum suitable for quantifying an element based on its design intent and subsequent performance, according to one embodiment of the present invention. Figure 12 illustrates an exemplary table suitable for performing an H-TRL assessment, according to one embodiment of the present invention. Figure 13 illustrates an exemplary technology readiness assessment matrix showing a process for determining a C-TRL, according to one embodiment of the present invention. Figure 14 illustrates a flow diagram of an exemplary thought process in determining a C-TRL by a simple combination of the results of the H-TRL and CRL determinations at a given level in an assessment for an exemplary space vehicle system, according to one embodiment of the present invention.

DETAILED DESCRIPTION A process is described that seeks to facilitate technology definition, prioritization, planning, development, and risk management by considering the engineering concepts and/or design solutions that address the challenges posed by a program, project, and/or product that satisfies a customer expectation and the readiness of the engineering technology base to bring these design solutions to fruition. Moreover, the process can be used to identify the underlying or root sources of uncertainties, such as cost, schedule, reliability, and/or performance risks. In the following detailed description, for the purpose of explanation, numerous specific details are set forth in order to provide a thorough understanding of the various embodiments of the present invention. However, it will be apparent to one of ordinary skill in the art that some of the specific details may be combined or expanded into additional, separate details. Some of the details may also be implemented in differing order and, furthermore, the present invention may be practiced without some of these specific details. In certain embodiments, the present invention comprises various steps, which will be described below. Even though the steps of the present invention may be performed by human beings and are described as such in the description that follows, one or more steps or parts of one or more steps of the present invention may be performed by hardware components or may be embodied in program logic or other substrate configuration. The program logic or other substrate configuration (collectively referred to herein as "program logic") may be used to cause a general- purpose computer or special-purpose computer (collectively referred to herein as a "computer") to perform the steps or parts of the steps. Alternatively, the steps may be performed by a combination of human beings, hardware components and software. The computer may be a uniprocessor or multiprocessor machine. The computer includes a memory storage device or an addressable storage medium (collectively referred to herein as "memory storage device"), which refers to any medium that participates in providing the symbolic representations of operations to a processor for execution. The memory storage device includes, by way of example and not limitation, random access memory (RAM), read-only memory (ROM), disk drives, tape storage, optical or magnetic disk, optical or magnetic cards, flash memory, electronic transmission media or other suitable volatile or non- volatile data storage facility. The program logic may reside on the computer and, in particular, the computer memory, and cause the computer to operate in a specific and predefined manner as described herein. The program logic may advantageously be implemented as one or more modules. The modules may advantageously be configured to reside on the computer memory and execute on the one or more processors. The modules include, but are not limited to, software or hardware components that perform certain tasks. The program logic conventionally includes the manipulation of data bits by the processor and the maintenance of these bits within data structures resident in one or more of the memory storage devices. Such data structures impose a physical organization upon the collection of data bits stored within computer memory and represent specific electrical or magnetic elements. These symbolic representations are the means used by those skilled in the art to effectively convey teachings and discoveries to others skilled in the art. Furthermore, reference in the specification to "an embodiment," "one embodiment," or "various embodiments" means that a particular feature or aspect of the invention described in conjunction with the particular embodiment is included in at least one embodiment of the present invention. Thus, the appearance of the phrases "in one embodiment," "in another embodiment," or variations thereof in various places throughout the specification are not necessarily all referring to its respective embodiment.

Definitions To facilitate a complete understanding of the present invention, the following terms set off by quotation marks and their variants, used throughout the detailed description, shall have the following meanings: "Technology Program" is a program, project, or sub-project, the primary purpose of which is to advance the state of the art in a particular engineering design, design aspect, or application, or area of science or engineering. "Top-Level Customer Requirements" are the requirements that are derived directly from one or more customer values, goals, mission statements, etc. (referred to herein as the "customer expectations"). For example, a customer's values/goals can be to have a very quiet, efficient, reliable automobile, hi this instance, the top-level customer requirements may include reducing the noise level in the cabin to a specific decibel level, increasing the miles per gallon efficiency of the vehicle to a specific figure, specific maintenance intervals for specific parts of the vehicle, a maximum sales price, etc. "Functional Requirements" are requirements used by the engineers in originating a solution(s) (i.e., designs, concepts, systems, etc.) to satisfy the top-level customer requirements. Typically, the functional requirements come directly from or flow-down from the top-level customer requirements (flow-down requirements), are derived to fulfill a higher level customer-driven requirement, or are assumed, for example, by engineers, as necessary to complete the engineering to fulfill the customer-driven requirements. "Customer-Driven Requirements" are requirements that result from top-level customer requirements. The customer-driven requirements include, for example and not limitation, functional requirements, engineering requirements, as well as any other requirements that are derived from top-level customer requirements. Moreover, one or more customer-driven requirements can be derived from another one or more customer- driven requirements. "Macro-Technologies" are the management, system hardware, software and operations technologies needed to meet a customer's expectations. Macro-technologies are the approaches/design solutions ardware/software that satisfy customer-driven requirements and are generally the things that are ultimately delivered to a customer. For example, the macro-technologies are the arclritectures, concepts, hardware/software designs and hardware/software needed to meet the customer-driven requirements and, thus, satisfy the customer values/goals/needs. They can be any tangible item or thing that is delivered, such as, by way of example and not limitation, an engine, a controller, a ball bearing, a ball in a ball bearing, and the like, or the associated software and operating and maintenance timelines and processes. The macro-technologies are the constituent part(s) of a system. "Macro-Technologists" are a broad range of managers and engineers ranging from system architects and concept designers to the detail hardware/software designers who design, prefect, and sustain a system. This term generally includes the broad range of managers and/or engineers/scientists who generate the ideas, architectures, design concepts, and/or intermediate and detailed designs/methods, and who perfect the system (including operating methods and procedures) needed to satisfy the customer-driven requirements and who sustain the system in their application or usage, i general, these may be said to be the hardware/software design, development and fielding people, and includes systems analysis, engineering, and integration. "Micro-technologies" are the underlying management, science and engineering technology base capabilities (i.e., analytical tools, databases, models, codes, materials and processes, manufacturing, test and evaluation methods, etc.) needed to bring the design concepts/solutions (i.e., macro-technologies) to fruition. Micro-technologies are the management, science and/or engineering discipline capabilities needed to identify/resolve uncertainties and risks and to validate that the design solutions that can meet the customer-driven requirements. For example, the micro-technologies are the engineering technology base capabilities needed to define and design the requisite hardware/software, build it, verify what was built, verify the design, field and operate it, and the like. "Micro-Technologists" are the broad range of management, science and engineering discipline specialists (i.e., materials and materials processing people, analysts, etc.) who provide the underlying enabling discipline capabilities needed to enable a concept or design, to ascertain the uncertainty/risk associated with the perfecting or application/use of a particular system and/or the risk/uncertainty associated with use or insertion of technologies at varying stages of maturity in such systems, products, or portions thereof. Included are the disciplines needed to validate or verify that the concept or system can be expected to satisfy customer-driven requirements and/or to identify the uncertainties in the respective elements in the SBS for the specific disciplines. "Technology Readiness Level" (TRL) addresses the readiness of a system or a technology to be used in a particular application. A TRL may be evidenced by the level of testing of the hardware/software, the relevancy of the test article to the final article that meets the customer-driven requirements, and the relevancy of the test environment to the expected operating or usage environment for a particular piece or set of hardware/software. TRL relates to the macro-technologies. "TRL Limiter" is an unknown in the engineering technology base that controls or sets the TRL. "Capability Readiness Level" (CRL) is the readiness of the underlying science and engineering capability (i.e., materials and processes, codes/models, database, manufacturing capabilities, test and evaluation capabilities, etc.) needed to analyze and predict the performance and operation of the design(s) relative to the top-level customer requirements and/or the customer-driven requirements. CRL is typically based on an assessment of a micro-technology capability relative to the top-level customer requirements and/or the customer-driven requirements for a specific WBS or SBS element and relates to the micro-technology's readiness to support the design and development process and validate these requirements. Stated another way, the CRL addresses the level of uncertainties or risks associated with the science/engineering capability needed to analyze and predict the performance and operations of the hardware/software. "Entry CRL" is a CRL that designates a current micro-technology's capability to enable one or more macro-technologies to satisfy the top-level customer requirements and/or customer-driven requirements. The entry CRL can vary by project as well as by parts of the system or product, or elements of either. "Exit CRL" is associated with a micro-technology, and indicates the capability readiness level the micro-technology needs to acquire in order, for example, to be infused into a design or program/project. The exit CRL can vary by project as well as by parts of the system or product, or elements of either. "Shortfall" is the difference between the current underlying science/engineering capabilities (micro-technology capabilities) and the capabilities needed to provide design solutions that address the technical challenges inherent in the customer-driven requirements, and concepts and design solutions that respond to those requirements, hi other words, it is a deficit in the underlying engineering capability (micro-technologies) relative to what is needed to design with confidence, and to validate that the design solutions will meet customer expectations as defined in the customer-driven requirements. Generally, shortfalls are the root causes of uncertainties/risks, the determinants in establishing technology readiness, and the specific weak elements or links in the technology chain relative to the capability needed to meet the customer- driven requirements. Shortfalls are the determinants in establishing the TRL and are in effect the TRL limiters. "Work Breakdown Structure" (WBS) or "Systems Breakdown Structure" (SBS), used interchangeably herein, is a logical framework around which all work or system elements can be organized. It is a product-element or system-element tree, which starts at the highest level of the product or system and goes down to as much detail as necessary (at the particular stage of the program, project or product cycle) to identify, define, and control all of the constituent elements of the system, subsystem, or product. "Engineering Capabilities Breakdown Structure" (ECBS) or "capabilities

Breakdown Structure" (CBS), used interchangeably herein, is a breakdown of the micro- technology capabilities involved in design, development, verification, and fielding of a system or system element, or in the introduction of a product into the market. It is a tree of the micro-technologies organized under general categories such as, by way of example, program/project management, systems analysis, management, and integration, materials engineering and processes, design, analysis, and predictive capabilities, fabrication/manufacturing, requirements validation, safety and mission assurance, fielding and operations, and the like. It goes to the level of detail needed to provide specific and discrete micro-technology shortfalls per SBS element. The detail elements may vary based on the particular system, element, or product under consideration, its point in the system/product cycle, the kinds and maturity of macro-technologies being considered, and may include all or some of the general categories listed above. "Advancement Degree of Difficulty" or often "Degree of Difficulty" addresses the anticipated difficulty in advancing the CRL for a specific micro-technology for an SBS element from a current CRL to a specified exit CRL. Stated another way, the degree of difficulty addresses how hard it is expected to be to reach an exit CRL from a current state of readiness of that particular micro-technology relative to customer-driven requirements. Advancement Degree of Difficulty can also be applied to advancement of the TRL from the current level to the specified exit level.

General Overview The Technology Assessment, Planning, and Risk Management Process

(TAPRMP) provides a disciplined process that leads to a clear definition of the weakest elements in a technology structure (i.e., weakest links in the technology chain), the identification of the associated uncertainties and risks, and the development of mitigation plans and metrics. This provides a solid basis for the definition and prioritization of the critical technologies and a sound basis for management of the technological progress. The TAPRMP brings together the myriad of management and technical disciplines involved in defining and advancing a particular technology or suite of technologies needed to meet customer-driven requirements into an interactive and "organic" process (i.e., a process in which the focus is on the roles, functions, interdependencies, integration, inputs and outputs), hi one embodiment, the TAPRMP allows its users to identify critical technologies, assess the readiness of the current science/engineering capabilities to support a program, project, or product goals, assess the level of difficulty in developing the technologies to a point where they can be successfully used or infused into a program, project, or product with acceptable cost, schedule, and performance risk. In the process, the necessary information to develop sound costs and schedule projections, to prioritize critical tasks, and manage technological progress is generated. The TAPRMP activities are organized around the tenet that, in order to successfully manage a technology program, there are two basic components of technology development that need to be considered in an integrated manner. The components of technology development are the macro-technologies needed to meet a customer's expectations and the micro-technologies needed to bring the macro- technologies to fruition. Both the micro- and macro-technologies need to be considered in relation to each other, and need to be kept in balance as the program proceeds if the risks associated with the program are to be minimized, and a sound decision is to be made with regard to the use or infusion of a particular macro- or micro-technology. By considering the micro- and macro-technologies in this manner, a more comprehensive view of what is needed to design, build, validate, and operate the design(s) that meets the customer-driven requirements is taken, and the specific uncertainties/risks inherent in the macro-technologies are exposed. Moreover, the micro-technologists become more productive because they can better relate their work to specific customer-driven requirements, which leads to validation of their models and databases in relation to "real-world" customer-driven requirements. Figure 1 illustrates a flow diagram of an exemplary TAPRMP, according to one embodiment of the present invention. As depicted, the TAPRMP comprises a Gathering and Understanding the Customer's Values, Goals and Expectations Phase 102, a Goal Decomposition Phase 104, and a Technology Readiness Assessment Phase 106. In this embodiment, the three Phases 102, 104, and 106 are coupled or linked one after another. Each of the Phases 102, 104, and 106 may comprise one or more activities and/or tasks, and each of the activities and/or tasks may produce deliverables that are utilized in subsequent activities, tasks, and/or phases. In one embodiment, a listing of the phases, activities, and/or tasks, along with the one or more deliverables may be provided on a computer storage device (i.e., diskette, CD-ROM, etc.) for use by loading and execution on a computer. It will be appreciated that the present invention need not require all three phases discussed above. The TAPRMP can be customized to meet the needs and requirements of a particular technology program at hand. Therefore, it is contemplated that one or more embodiments of the present invention may not comprise all three Phases 102, 104, and 106. For example, though not limited to this example, in various embodiments of the TAPRMP, Gathering and Understanding the Customer's Values, Goals and Expectations Phase 102 may not be included in the TAPRMP. hi these embodiments, a customer's values and expectations may have been previously determined and may have remained unchanged since the prior determination. In this instance, there would not be a need to determine this information again in performing the TAPRMP for the same customer. Other embodiments of the present invention may comprise iterative repetitions of one or more of Phases 102, 104, and 106. For example, the results of a first iteration of the TAPRMP can cause in a modification of the top-level customer requirements and/or customer-driven requirements that are the basis for a subsequent iteration of the TAPRMP. Moreover, in embodiments where the TAPRMP is performed as an iterative process, one or more phases, activities and/or tasks may be omitted in subsequent iterations of the TAPRMP. Stated another way, subsequent iterations of the TAPRMP may not include one or more phases, activities and/or tasks. By way of example and not limitation, a second iteration of the TAPRMP may involve performing all three phases, skipping a phase (e.g., performing Phases 104 and 106 while omitting Phase 102), or skipping one or more activities and/or tasks in a phase.

Gathering and Understanding the Customer's Values, Goals and Expectations Phase During the Gathering and Understanding the Customer's Values, Goals, and Expectations Phase 102, a customer's expectations are gathered and analyzed to identify and understand what the customer wants (i.e., what the customer desires; what the customer wants to purchase; what the customer wants delivered; etc.). Typically, during this phase, marketing and/or system people strive to understand what it is that the customer wants delivered. This may involve learning to think like the customers and/or the benefiting users (if they represent different interests or constituencies) by, for example, interacting with the customer to develop scenarios, analyzing such things as the customer's strategic plans, goals, mission statements, directives, etc., identifying who the benefiting users are likely to be, and, generally, understanding the customer(s). Understanding the customer may also involve understanding the customer sensitivities, expected outcomes, time frames and constraints. Goal Decomposition Phase In one embodiment, and as illustrated in Figure 2, Goal Decomposition Phase 104 comprises a Customer Needs Decomposition Task 202, a Top-level Options Development Task 204, and a Concept or Design Options Development, Trade Studies and Analysis Task 206. During Goal Decomposition Phase 104, the information developed during Phase 102 (i.e., customer expectations) is decomposed into one or more top-level customer requirements that will satisfy the customer's expectations (Task 202). Once the top-level customer requirements are determined, broad, encompassing top-level options (i.e., broad schemes/approaches or architectures) that satisfy the top-level customer requirements are developed (Task 204). An SBS is then constructed for each of the top-level options, and each constructed SBS lists the constituent elements of its respective top-level option. SBS construction is well known to those of ordinary skill in the art. An exemplary SBS is depicted as part of an exemplary technology readiness assessment matrix in Figure 3. The technology readiness assessment matrix is further discussed below. In one embodiment, each of the one or more top-level customer requirements is included in an element of the SBS constructed for a top-level option. These top- level customer requirements are further decomposed into functional requirements for each element of the SBS. In one embodiment, based on the customer-driven requirements, one or more candidate design concept/design that best meets the customer-driven requirements is identified. The identification process may involve performing concept studies, assessing design options, conducting trade studies, and related analysis (Task 206). Even though the aforementioned terms (i.e., expectations, requirements, studies, etc.) are stated in the plurality, it will be appreciated that the present invention is not limited to the terms being in the plurality, but is intended to and does cover one or more of the terms being in the singular. Gathering and Understanding the Customer's Values, Goals and Expectations Phase 102 and Goal Decomposition Phase 104 are not each limited to the tasks and activities described above. In various other embodiments, either or both of Gathering and Understanding the Customer's Values, Goals and Expectations Phase 102 and Goal Decomposition Phase 104 may include fewer tasks and/or activities or additional tasks and/or activities than those described above. Generally, Phases 102 and 104 provide the necessary input for the Technology Readiness Assessment Phase 106 which is described next. Even though the detailed description herein discusses the SBS in the context of a "system," it will be appreciated that the system can also be a reference to a "product" or an "element" or a "component" in a system or product. Thus, SBS, as used herein, is not only an acronym for "system breakdown structure," but can also an acronym for "product breakdown structure," "element breakdown structure," and the like.

Technology Readiness Assessment Phase Technology Readiness Assessment Phase 106 is a phase during which the engineers, managers, and/or other interested parties obtain a more accurate, complete, and substantive picture of the technology, uncertainty/risks, and readiness, h one embodiment, this phase is designed to uncover or surface embedded critical assumptions/uncertainties and high-risk shortfalls by constructing a dual breakdown matrix. The SBS for the system, element, or product under examination appear on one side of the dual breakdown matrix, and an ECBS or CBS tailored for that system, element, or product appear on the other side of the matrix. Such a matrix illustrated in Figure 3. The dual breakdown matrix may be refeπed to as a technology readiness assessment matrix. While the aforementioned embodiment addresses technology readiness assessments, in various other embodiments, the same matrix and process may be used to perform risk assessment and to identify the root sources of unreliability in a design, functioning system/product, or the entire infrastructure supporting a design, system, or product. In this instance, a matrix such as this can be used to structure a sequential and interactive process involving both the macro- technologists and the micro-technologists to find shortfalls in the underlying micro- technologies (the weakest links in the technology chain), to ascertain the associated uncertainties/risks associated with these shortfalls, to prioritize the shortfalls, to develop mitigating action plans, and to define metrics to measure progress in mitigating the uncertainty/risk, thereby advancing the CRL for that ECBS element and that SBS element. In Phase 106, the risks/readiness of the engineering technology base technologies needed or necessary to support the requirements and design concepts/solutions is systematically evaluated at a level of detail that permits well informed judgments to be made about the uncertainty/risks/readiness of a system or macro-technology. This assessment determines the specific critical technologies, both micro- and macro-technologies, that need attention, and the readiness of the system or technology to proceed in the maturation cycle, or the risk of proceeding if the decision-makers decide to proceed. Phase 106 comprises CRL, TRL, and advancement degree of difficulty (AD ) assessments, and also includes definition of action plans with metrics and milestones to measure progress toward the exit CRLs and exit TRLs. In one embodiment, the technology readiness assessment matrix provides a viable vehicle for performing the technology definition, characterization, and assessment portions of the TAPRMP. Figure 3 illustrates an exemplary technology readiness assessment matrix, according to one embodiment of the present invention. This dual element (i.e., (1) the proposed requirements and design concepts/solutions (also referred to as macro- technologies), and (2) the engineering technology base disciplines (also referred to as micro-technologies)) breakdown structure facilitates the discovery of the technology shortfalls, identification of the critical technology tasks, determination of the technology readiness, and the degree of difficulty in advancing to higher levels of technology readiness. As depicted in Figure 3, on the left side of the technology readiness assessment matrix is the SBS established during Goal Decomposition Phase 104. Depending on the phase of definition and or design, the SBS may be expanded or further broken- down to lower levels for Technology Readiness Assessment Phase 106. On the top of the technology readiness assessment matrix is an ECBS. The ECBS displays the one or more micro-technologies that are needed to identify the weak links in the technology chain relative to the requirements and proposed design concepts/solutions (i.e., the SBS elements appearing on the left side of the technology readiness assessment matrix). Figure 4 illustrates another exemplary technology readiness assessment matrix, according to one embodiment of the present invention. The SBS and the ECBS in this technology readiness assessment matrix is different from the technology readiness assessment matrix illustrated in Figure 3. Depending on the type of project and the phase of the project (e.g., early definition vs. development), either or both the SBS or ECBS may vary. Moreover, the SBS or the ECBS may vary based on circumstances that are unique to a particular project, such as the critical areas on a project that need greater granularity. It is appreciated that other embodiments of the TAPRMP may not utilize the technology readiness assessment matrix. In these embodiments, the engineering technology base disciplines and the proposed requirements and design concepts/solutions may be addressed and assessed using other data/information display arrangements suitable for displaying and analyzing data and information. As depicted in Figure 1, Technology Readiness Assessment Phase 106 comprises a Functional Requirements and Design Concept/Solution Development Task 108 and a Capability Assessment, Shortfall Identification and Readiness Determination Task 110. Generally, the macro-technologists document the functional requirements they are using, and the proposed design concept/solution and associated characteristics, assumptions, analysis, approaches, their estimated TRL, and other items and factors necessary to characterize the macro-technologists' design responses to the customer- driven requirements for each element of the SBS during Task 108. For example, not knowing the requirements is a risk to proceeding with system. Thus, an item of interest may be how well the requirements are defined at the various levels of the SBS. Stated another way, while the process can work at various phases or levels of engineering (e.g., concept to detailed design to existing hardware) the completeness of the definition of the requirements at the respective phases or levels is a key element in the uncertainty/risk assessment. Moreover, the micro- technologists' determination of the shortfalls is made relative to the requirements, as is the current capabilities assessments, CRL and AD² determinations, and other micro- technologists' findings. Functional Requirements and Design Concept/Solution Development Task 108 maybe a "living" process. For example, early in a program, the process requirements may be at a more summary level. This allows for the definition of critical technologies early in the program and an early assessment of the complexity, time, cost, etc., of incorporating them. This may in turn result in re-examination and iteration of the requirements, and a search for other design solutions that require less taxing technological solutions. The assessment may be periodically revisited as the requirements are better defined. In one embodiment, and as illustrated in Figure 5, Functional Requirements and Design Concept/Solution Development Task 108 comprises an Expanding the SBS Task 502, a Decomposition of Top-Level Customer-Driven Requirements Into Functional Requirements for Each Element in the SBS and Documenting Them in Their Respective SBS Elements Task 504, and a Creating, Describing and Documenting the Design Approaches/Solutions and Associated Descriptive and Defining Characteristic that Satisfy the Functional Requirements Task 506. Task 502 involves determining the elements and the level of the SBS relative to the engineering phase and the objectives of the assessment, and expanding the SBS developed during Goal Decomposition Phase 104 to accommodate the functional requirements. The SBS is a framework and tree for documenting what is known about the customer-driven requirements and the engineering responses to those customer- driven requirements, given the phase or level of engineering involved. Task 504 involves assessing/decomposing the top-level customer requirements and developing the functional requirements for each element in the SBS against which design concepts/solutions can be formulated. The level of detail can vary depending on the maturity of the concept or design, and the objectives of the assessment. As a part of this task, the functional requirements may be documented relative to the appropriate SBS element. Task 506 involves creating the design approaches/solutions (i.e., macro- technology solutions) that satisfy the customer-driven requirements. Again, the level of detail can vary depending on the maturity of the concept or design, and the objectives of the assessment. Generally, at a minimum, the level of detail needs to be such that the basic engineering characteristics developed, and assumptions made in the process of satisfying the top-level customer requirements, are evident. Having completed developing the macro-technology solutions, Task 506 also involves populating each respective SBS element with as much knowledge the system architects, concept designers, and/or hardware/software designers, as the case may be, have at that point in time regarding the concepts and/or designs. For example, this may include the general attributes, engineering assumptions, applications, technical issues and concerns, technology assumptions and the TRL assumed by the respective macro-technologist, operational information and other descriptive information that sets forth the nature of the concept or design solution and its form and functional characteristics. Initially, the level of detail may be low, but that does not preclude an early assessment to identify broad underlying risks in the engineering technology base shortfalls and the underlying uncertainties and risks for a particular concept. As the design progresses and matures during the process, further details of the design can be added and the cycle repeated. In one embodiment, the cycle comprises the following activities: a) Determining the functional requirements. The functional requirements can come directly from the top-level customer requirements (flow- down requirements), be derived by the engineers as needed to fulfill a higher level customer-driven requirement, or be assumed by the engineers as necessary to complete the engineering to fulfill the customer-driven requirements. b) Describing the design concept/solution, including key factors/assumptions and their description/characterization and criticality relative to requirements. Among other things, this can include infoπnation and data that is needed to test the critical assumptions as the process proceeds. c) Determining alternate or fall-back design concepts/solutions, if any. d) Identifying the analysis tools and databases used for the design and the accompanying pedigree and assumptions. . e) Estimating or declaring the hardware/software TRL (H-TRL) and providing a justification for the estimate made (micro-technologist's perspective of the TRL). f) Identifying a number (e.g., the top five) of perceived technical challenges. For example, the perceived technical challenges can be things that worry the designer the most, and places that present the most uncertainty in the analysis performed to generate the concept and/or design. Referring again to Figure 1, Capability Assessment, Shortfall Identification and Readiness Determination Task 110 is primarily focused on identifying the weak links in the technology chain and defining and characterizing the micro-technologies needed to support the requirements and macro-technologies used in the concept(s)/design(s). During this task, the results of Functional Requirements and Design Concept/Solution Development Task 108 may be assessed using the technology readiness assessment matrix (i.e., Figures 3 and 4) discussed above. Generally, and as can be seen in the technology readiness assessment matrix (Figures 3 and 4), there are two operative interests that need to be considered. The operative interests are the interests of the macro-technologists and the interests of the micro-technologists, both of which need to be involved in the process. The approach is to have knowledgeable micro-technologists "drill down" into the evaluation matrix to "discover" technology shortfalls, develop one or more mitigating plans for turning these shortfalls into knowledge, and develop technical performance measures or metrics to track progress. . In one embodiment, Capability Assessment, Shortfall Identification and Readiness Determination Task 110 comprises steps 602, 604, 606, 608, and 610, which will be described with reference to Figure 6. Step 602 is an assessment setup period during which the basic structuring and organizing is performed. For example, an assessment leader is selected, a framework and an information capture system established, the micro-technologists selected, the participants in the assessment instructed as to the assessment procedures, a worksite and/or workspace designated, and an information repository identified. At step 602, the information packages (i.e., the information contained in the SBS) prepared by the macro-technologists may be reviewed and qualified for completeness and consistency. If an information package is incomplete, the responsible macro-technologist may be requested to provide the required information. At step 604, the micro-technologists review the information developed during

Functional Requirements and Design Concept/Solution Development Task 108. During this step 604, the micro-technologists "drill" into the information provided by the macro-technologists for each SBS element (i.e., the elements appearing on the left side of the matrix) to "discover" those SBS elements where the requirements and design concepts/solutions significantly exceed the underlying capabilities of the current engineering technology base (i.e., where there are critical micro-technology shortfalls relative to the SBS requirements). Figure 7 illustrates an exemplary technology readiness assessment matrix showing the assessment process, according to one embodiment of the present invention. For each micro-technology appearing on the top of the technology readiness assessment matrix, the respective micro-technologist examines the information provided by the macro-technologists, and ascertains the SBS elements in which his/her micro-technology is a factor. For each identified or ascertained SBS element, the micro-technologist uses his/her expertise and knowledge to determine whether the designs and requirements associated with the ascertained SBS element can be met with his/her existing micro-technology capabilities. If the existing micro- technology capabilities are not able to satisfy the designs and requirements, the deficiency in the micro-technology is identified as a shortfall. Stated another way, the designs and requirements associated with the ascertained SBS element exceed the current capabilities of the micro-technology. For the identified elements whose design concepts/solutions exceed the current capabilities of the micro-technology, the micro-technologist may prepare a current capability statement and, using his/her expert opinion and a uniform set of definitions and levels for each micro-technology discipline, can assign a CRL. Figure 8 illustrates an exemplary uniform set of CRL definitions/scale for aerosciences, a typical micro-technology suitable for CRL determination, according to one embodiment of the present invention. It is appreciated that, depending on the particular system involved, the micro-technologists may vary, and other discipline specific CRL definitions may need to be developed for that particular system. During step 604, the micro-technologists can prepare shortfall write-ups that describe specific shortfalls in the engineering technology base that need to be eliminated or mitigated to improve the current CRL for a particular discipline to the exit CRL. These shortfalls are then prioritized, first by the micro-technologists, and then reviewed with, and a consensus reached with the respective macro-technologists. For the agreed to higher priority shortfalls, mitigating tasks can be developed, which include costs, schedules, and technical performance metrics, which may be used for measuring progress in reaching the exit CRL and the resulting exit TRL for each SBS element under consideration. The relationship of the CRL to the TRL is further discussed below. Another consideration may emerge, that is, how difficult it may be to go from the current CRL to the exit or infusion CRL. For example, it may be more difficult to advance one level in one micro-technology SBS element than it is to advance two or three levels in another micro-technology (i.e., all shortfall mitigation efforts do not have the same degree of difficulty and this need to be recognized). The respective micro-technologists can use their expert judgment to estimate the AD² in advancing from the current capability level to the next or exit level (i.e., the difficulty in advancing from the current CRL to the exit CRL). For example, the AD² rating can be determined by using an AD definition and scale which was developed by John Mankin, and further adapted by James Bilbro, both at NASA, and which is generally known to one of ordinary skill in the art. In one embodiment, the micro-technologists can use the estimated AD as one factor to priontize the shortfalls and select the most critical shortfalls (usually the top four or five) in each discipline area. These findings and plans are documented against the respective SBS elements for each micro-technology. The micro-technologists can also report the findings to the macro-technologists to facilitate review and evaluation of the micro-technology findings by the macro-technologist. At step 606, the macro-technologists evaluate the micro-technologists' findings and priorities. The macro-technologists can review the finding of the micro- technologists shortfall by shortfall, and make a determination as to whether they agree or disagree with the shortfalls, shortfall priorities, CRL, and AD² presented in the micro-technology findings developed in step 604. hi doing this, they may use their best judgment as designers and developers as to the merits of the shortfalls identified by the micro-technologists. By way of example, a typical priority rating scale that may be used by the macro-technologists' to rate the shortfall can be:

First Priority: Absolutely essential, enabling, cannot be delayed, timing is important, low CRL, high degree of difficulty, without a substantive database and methodology. Second Priority: Essential, moderate degree of difficulty, moderate CRL and/or degree of difficulty. Third Priority: Important, but high CRL and low degree of difficulty, or may be enhancing rather than enabling, could be time phased. Fourth Priority (shelf position): Not required, too generic, not specific, on the fringe, not clear. Will be re-examined only after reformation and submission of justification by the micro-technology team. Fifth Priority (not considered further): Already available, with CRL past threshold or redundant or a repeat task.

At step 608, the macro-technologists and the micro-technologists conduct interactive discussions to reach a consensus on the shortfalls and their priorities. Typically, these discussions take place in one or more workshops, but may be by teleconferencing, virtual communication over the Web, or other means suitable for achieving dialog on the shortfalls, priorities, CRLs and the resulting TRLs, AD², tasks, and other matters pertinent to reaching a consensus between the two perspectives. A technical advantage is that this interactive process yields a high degree of confidence that the correct shortfall priorities have been identified for resolution, such that "must have" enabling engineering capabilities technologies needed to bring the hardware/software/operational technologies design solution to fruition are identified, as are the tasks and metrics. At step 610, There may be follow-up on the outstanding actions from the interactive discussions (e.g., workshop) between the micro-technologists and the macro-technologists. The workshop typically produces one or more action items that need to be performed and/or deficiencies that need to be corrected in the information developed/provided by the micro- and/or macro-technologists during the portion of the process executed so far. This information may reside in a database, or other accessible file structure, structured around the SBS and ECBS. For example, once the database of information developed in the course of Tasks 108 and 110 is complete, it can then be used in both long range and short range technology planning and budget formulation. Alternately, if the primary purpose of conducting the assessment is risk management, the output of the process can proceed directly into the project's risk management system. Also during step 610, one or more reports may be prepared for organizational and/or program/management, for other management, for budgetary and technical personnel who have an interest in the outcome, as well as for other people having a need to know.

Exemplary Process for Developing a C-TRL Utilizing the TAPRMP By way of background, a TRL is a shorthand method of communicating a description of the "performance" history of a system, subsystem, or component relative to a set of a plurality of levels. Generally, a TRL describes the state-of-the-art of a given hardware system, subsystem, or component, and provides a "baseline" from which development is leveraged. Figure 9 illustrates an exemplary TRL scale depicting a plurality of TRL levels and associated definitions for a system hardware/software and/or technology readiness determination. The underlying constituents and dynamics of TRLs typically are not well understood and have frequently been misinterpreted, which results in undertaking programs without fully understanding either the state of the key technologies or what is needed to develop these key technologies to the required level. Stated another way, it is very difficult, if not impossible, to understand the magnitude and scope of a development program without having a clear understanding of the technology baseline. As can be noted from examining the exemplary TRL levels/definitions illustrated in Figure 9, the TRL levels and definitions for the most part address two factors: (1) the relevancy of the test article to the contemplated flight article, and (2) the relevancy of the test environment to the expected flight environment. One drawback in the current TRL methodology is that this TRL methodology is basically one-dimensional in that it is based only on the "performance history" of a system, subsystem, or component, which is a very inadequate measure of the technology readiness. Another drawback is the methods by which the TRL is determined. The exemplary TRL levels/definitions illustrated in Figure 9 are a widely recognized set of definitions of the technology readiness levels. In application, the lack of specificity and precision, coupled with a heavy reliance on "expert judgment" to ascertain a TRL (whether for a particular technology's readiness for infusion or the technology readiness of a given system), has led to varying degrees of success, hi some cases the results have been misleading. Figure 10 illustrates a flow diagram depicting a process for improving the accuracy and utility of a TRL, according to one embodiment of the present invention. The activities in the process include a Conduct a More Rigorous Test Article/Performance/Test Relevancy Evaluation to Establish the Hardware/Software TRL (herein after referred to as the H-TRL) Task 1002, a Rigorously Evaluate the Engineering Technology Base Capabilities Task 1004, an Assess the AD² in

Advancing a Technology to a Higher Readiness Level 1006, and an Integrate CRL, AD² and TRL Into a Composite TRL (C-TRL) 1008.

Conduct a More Rigorous Test Article/Performance/Test Relevancy Evaluation to Establish the H-TRL 1002 In one embodiment, this task begins with establishing a common set of terminology that is needed to develop a uniform H-TRL assessment. The definitions need not be exact and may be somewhat arbitrary, but they do need to be reasonably comprehensive. Upon first impression, the descriptions in Figure 9 appear to be relatively straightforward, but they are very general, which leads to broad range of interpretations in the process of trying to assign levels. For example, based upon background, experience, and perspective, most everyone knows what a "breadboard" is, but it maybe that not everyone's definition is the same. Also, a "relevant environment" may mean different things to different people. What is relevant to one person may or may not be relevant to another, again depending on the person's background, experience, and perspective. Even so, while specificity is desired, a more general or generic set of definitions/terminology can be used, provided they are common and consistent, and provided that a means is available to better quantify the "judgment calls" regarding relevancy on the basis of past experience(s). For example, even with clear definitions, there may be a need for "judgment calls" when it comes time to assess just how similar a given element is relative to what is needed (i.e., is it "close enough" to a prototype to be considered a prototype, or is it somewhere down the line of development/engineering units closer to the breadboard?). In one embodiment, the factors of in terms of form, fit, and function are addresses as a means of quantifying an element based on its design intent and subsequent performance. Figure 11 illustrates a graphical representation of an exemplary 3-dimensional continuum suitable for quantifying an element based on its design intent and subsequent performance, according to one embodiment of the present invention. In particular, elements such as, by way of example and not limitation, models, breadboards, engineering units, prototypes, etc., can be plotted in the 3-dimensional continuum illustrated in Figure 11. As depicted in Figure 11, the X-axis of the graph represents "function," the Y- axis represents "form," and the Z-axis represents "fit." A breadboard, according to one common definition, would demonstrate only function, without regard to form or fit, and would consequently fall somewhere along the X-axis. For example, if the breadboard was of the full "system," then it would be at the 100% mark. If, instead, it was a breadboard of a subsystem or component, it would fall somewhere to the left of the 100% mark. Another example is that of a wind tunnel model. These models are typically less than 1% scale, but demonstrate aerodynamic properties associated with "form." On the other hand, a mass model could demonstrate fit, but would have neither function nor forai. In contrast, a prototype would be as close to the final article as possible and would consequently demonstrate form, fit, and function. By plotting the element or device under question, it becomes easier to classify its state of developmental maturity from a test article relevancy standpoint, but not for other critical factors. Figure 12 illustrates an exemplary table suitable for performing an H-TRL assessment, according to one embodiment of the present invention. The expertise of systems, subsystems and/or component engineer(s) that have knowledge relative to the current state-of-the-art in the applications of the relevant designs and technologies being used to satisfy customer-driven requirements is needed for an H-TRL assessment. As depicted in Figure 12, the SBS elements (i.e., the systems, subsystems, and components) that are under assessment appear as rows on the left-hand side of the table. The columns at the top of the table identify the categories that are used to determine the H-TRL (i.e., what units have been built, to what scale, in what environment have they been tested, etc.). Answers to these questions then determine the H-TRL of an item under consideration. In one embodiment, the H-TRL of the system is determined by the lowest H- TRL present in the critical part of the system. For example, a system is considered to be at H-TRL 4 if any single critical element ("critical element" being defined as those that very significantly affect the satisfying of the top level customer requirements) somewhere in the system is at H-TRL 4, even if the all the other elements in the system are each at a level higher than H-TRL 4. Conversely, if, in the same system, there is a critical element at H-TRL 3 (H-TRL 3 being lower than H-TRL 4), then the system would be at H-TRL 3 (i.e., H-TRL 3, being the lowest H-TRL, and, consequently the one that determines the H-TRL of the system). In other embodiments, methods that use combinations and weightings can also be used. As illustrated in Figure 12, the intersection of the row and columns where an "X" appears can be ranked on a scale of 1 to 10 based on a judgment of relevancy, and aggregated arithmetically or by formula or algorithm. Rows having multiple entries can be averaged or a weighting algorithm could be developed to determine the aggregate H-TRL of a particular element of the system. In some cases, they may simply be assessed qualitatively and used in the assessment. It will be appreciated that the issue of the level of hardware and/or software integration is included with every system, subsystem, and component. For example, all of the elements comprising a system may be at a higher H-TRL, but the fact that the elements have never been integrated as a unit would result in a lower H-TRL for that system. This is taken into account as you aggregate the results from the H-TRL assessment to higher levels of integration.

Rigorously Evaluate the Engineering Technology Base Capabilities 1004 hi one embodiment, accuracy and utility in a TRL can be markedly improved by considering the micro-technology (i.e., underlying enabling engineering technology base) elements. These are constituent elements of the TRL rating and can be viewed as the "links" in the technology chain. The overall TRL for a system, subsystem, or component can be no better than the weakest link in the technology chain, thus, the CRL becomes a key component of a TRL determination. CRLs address the uncertainty/risk associated with the underlying engineering capabilities needed to analyze and predict the performance and operations of the system (i.e., needed to analyze and validate the design), and the lowest CRL reflects the weakest link in the technology chain. The CRL determination referenced here is that done as a part of Task 110. In one embodiment, the H-TRL and the CRL are combined into a more comprehensive and more accurate composite TRL estimate for a system that reflects both the H-TRL and the CRL. As used herein, the term "composite TRL" (C-TRL) will be used to refer to the TRL arrived at by combining the H-TRL with the CRL. Figure 14 illustrates a flow diagram of an exemplary thought process in determining a C-TRL by a simple combination of the results of the H-TRL and CRL determinations at a given level in an assessment for an exemplary space vehicle system, according to one embodiment of the present invention. It is implicit in the thought process depicted in Figure 14 that there is a progression to higher levels of assembly and integration as the technology readiness is increased. The level of integration is a factor in progressing up the technology readiness scale. As is the case with the H-TRL component of the C-TRL, all of the elements of the system or product can be at a higher C-TRL, but the fact that they have not been integrated into higher level assemblies and tested would result in a lower C-TRL for that unit. Generally, the lowest CRL reflects the weakest link in the technology chain and has the biggest impact on the C-TRL. This is because, as a part of the TARMP, the shortfalls are prioritized. Work on those elements that have a low CRL but also a low AD² rating can be deferred or phased later without threat to the C-TRL of the program or project. This is an input to the program/project/product planning because this is an indication that work in this particular area can be delayed and considered at a later time without negatively impacting the overall advancement of a C-TRL, and, therefore, on the overall program/project/ product.

Assess the AD² in Advancing a Technology to a Higher Readiness Level 1006 As indicated previously, normally, the C-TRL for an SBS element cannot be any higher than the weakest link(s) among the CBS elements. Figure 13 illustrates an exemplary technology readiness assessment matrix showing a process for determining a C-TRL, according to one embodiment of the present invention. As illustrated in Figure 13, a weakest link in the technology chain is determined by going across the columns for each element of the SBS in the technology readiness assessment matrix and selecting the CBS element with the lowest CRL. hi other embodiments, one can also develop an algorithm or mathematical formula, if that better suits a specific assessment for a particular system. If there are several elements that have the same low CRL rating, the AD² can be used as a factor to pick among them (i.e., select the weakest link). Generally, the most critical shortfalls are those that have the lowest CRL and the highest AD² rating. As previously stated, it takes both the H-TRL and the CRL to get an accurate picture of the technology readiness. Combining the results of the H-TRL assessment matrix (i.e., Figure 12) with the CRL assessment results from the technology readiness assessment matrix (i.e., Figure 3) yields a C- TRL, which more accurately reflects the true TRL. The matrix illustrated in Figure 13 shows the combining of both the results of the H-TRL assessment matrix and the CRL assessment results from the technology readiness assessment matrix into a C-TRL. Integrate CRL. AD² and TRL Into a Composite TRL 1008 As previously stated, it takes both the H-TRL and the CRL to get an accurate picture of the technology readiness. Combining the results of the H-TRL assessment matrix (i.e., Figure 12) with the CRL assessment results from the technology readiness assessment matrix (i.e., Figure 3) yields a C- TRL, which more accurately reflects the true TRL. The matrix illustrated in Figure 13 shows the combining of both the results of the H-TRL assessment matrix and the CRL assessment results from the technology readiness assessment matrix into a C-TRL. This invention may be provided in other specific forms and embodiments without departing from the essential characteristics as described herein. The embodiments described above are to be considered in all aspects as illustrative only and not restrictive in any manner. The following claims rather than the foregoing description indicate the scope of the invention.

Claims

CLAIMS 1. A method for technology assessment comprising: developing a customer-driven requirement that satisfies a customer expectation; developing a design concept/solution for a system that satisfies the customer-driven requirement; identifying one or more science/engineering capabilities needed to bring the design concept/solution to fruition; and assigning a current capability readiness level for each of the one or more science/engineering capabilities, the current capability readiness level indicates the current capability of each of the one or more science/engineering capabilities to validate the customer-driven requirement and enable the design concept/solution. 2. The method of Claim 1 further comprising determining whether the design concept/solution exceeds the current capability readiness of at least one of the one or more science/engineering capabilities. 3. The method of Claim 1 further comprising describing a shortfall in at least one of the one or more science/engineering capabilities that needs to be mitigated to improve the current capability readiness level to a higher capability readiness level. 4. The method of Claim 1 further comprising, for at least one of the one or more science/engineering capabilities, estimating an advancement degree of difficulty in advancing from the current capability readiness level to a higher capability readiness level. 5. The method of Claim 1, wherein the customer-driven requirement comprises a functional requirement. 6. The method of Claim 1 further comprising: decomposing the design concept/solution into functional requirements; for each functional requirement, identifying one or more science/engineering capabilities needed to bring the functional requirement to fruition; and assigning a current capability readiness level to the identified one or more science/engineering capabilities needed to bring the functional requirement to fruition. 7. The method of Claim 1 further comprising: determining an H-TRL for the design/concept solution; and combining the current capability readiness level for the one or more science/engineering capabilities and the H-TRL for the design/concept solution to determine a C-TRL for design/concept solution. 8. The method of Claim 7 further comprising: estimating an advancement degree of difficulty in advancing from the current capability readiness level to a higher capability readiness level for at least one of the one or more science/engineering capabilities; and combining the advancement degree of difficulty , the current capability readiness level and the H-TRL to determine a C-TRL for design/concept solution. 9. A method for technology assessment, planning and risk management comprising: developing a customer-driven requirement that satisfies a customer expectation; developing at least one macro-technology that satisfies the customer- driven requirement; identifying a plurality of micro-technologies needed to bring the macro-technology to fruition; and assigning a current capability readiness level for each of the plurality of micro-technologies, the current capability readiness level indicates the current capability of each of the micro-technologies to validate the customer-driven requirement and enable the macro-technology. 10. The method of Claim 9 further comprising identifying one or more shortfalls for each of the plurality of micro-technologies using the current capability readiness level for each of the plurality of micro-technologies. 11. The method of Claim 10 further comprising: prioritizing the identified one or more shortfalls; and developing at least one mitigating action for at least one of the prioritized shortfall.