Technology Readiness Levels
In a previous blog “Are the Requirements Attainable?”, we mentioned that one reason requirements may be not be attainable was because the ability to meet a given requirement was based on an immature technology.
Engineers, scientists, and marketing personnel often tend to be overly optimistic as to their ability to meet performance requirements that go beyond state-of-the-art. Because of this, they tend to define requirements based on technologies that are not mature enough to be included in a product’s development plans. This often causes cost and schedule overruns due to the need to fix problems later in development or failure of the system or product to meet stakeholder expectations.
For organizations involved in developing technology-driven products, these problems are often the norm rather than the exception. And no one is immune…this is an issue faced by government units and commercial organizations and are encountered on both hardware and software projects. So the question… “how can one assess the requirements and the maturity of the technology needed to meet those requirements before beginning product development?” The answer lies with the concept of Technology Readiness Levels.
Technology Readiness Levels (TRLs)
TRLs were developed by NASA and the Department of Defense (DoD) to address the risks of basing a project’s success on a given technology. TRLs have been developed for all types of projects: spacecraft, weapon systems, software, medical devices, etc. While the wording in the definitions may differ for different types of systems being developed, the concept is the same.
There are nine levels of maturity defined for technologies as shown in Table 1. The lower the TRL level, the lower the maturity of the technology and the higher the risk to the project. As a general guideline, a project should not base success on a technology that is not at least TRL 3 at the start, and should be at TRL 6 by the Preliminary Design Review (PDR). The project plan and Systems Engineering Management Plan (SEMP) need to include a technology maturation plan for maturing the technologies needed for project success and meeting stakeholder expectations for performance.
Table 1 - Technology Readiness Levels
- Basic principles observed and reported: Lowest level of technology readiness. Scientific research begins to be translated into applied research and development. Examples include paper studies of a technology’s basic properties.
- Technology concept and/or application formulated: Invention begins. Once basic principles are observed, practical applications can be invented. Applications are speculative and there may be no proof or detailed analysis to support assumptions. Examples are limited to analytic studies.
- Analytical and experimental critical function and/or characteristic proof-of-concept: Active research and development is initiated. This includes analytical studies and laboratory studies to physically validate analytical predictions of separate elements of the technology. Examples include components that are not yet integrated or representative.
- Component and/or breadboard validation in laboratory environment: Basic technological components are integrated to establish that the pieces will work together. This is relatively “low fidelity” compared to the eventual system. Examples include integration of “ad hoc” hardware in the laboratory.
- Component and/or breadboard validation in relevant environment: Fidelity of breadboard technology increases significantly. The basic technological components are integrated with reasonably realistic supporting elements so that the technology can be tested in a simulated environment. Examples include “high fidelity” laboratory integration of components.
- System/subsystem model or prototype demonstration in a relevant end-to-end environment: Representative model or prototype system, which is well beyond that of TRL 5, is tested in a relevant environment. Represents a major step up in a technology’s demonstrated readiness. Examples include testing a prototype in a high fidelity laboratory environment or in simulated operational environment.
- System prototype demonstration in an operational environment: Prototype near, or at, planned operational system. Represents a major increase in maturity from TRL 6, requiring demonstration of an actual system prototype in an operational environment. Examples include testing the prototype in a test bed integrated with other parts of the system.
- Actual system completed and qualified through test and demonstration: Technology has been proven to work in its final form, integrated into the overall system, and under expected operational conditions. In almost all cases, this TRL represents the end of system development. Examples include development test and evaluation during system verification in its intended use and operational environment to determine if it meets the requirements.
- Actual system proven through successful operations: Actual application of the technology in its final form and under operational conditions, such as those encountered in operational test and evaluation during system validation. Examples include using the system under operational conditions.
- ‘basic’ research in new technologies and concepts (targeting identified goals and objectives, but not necessarily specific system requirements),
- focused technology development addressing specific technologies for one or more potential system applications,
- technology development and demonstration for each specific application before the beginning of full system development of that application,
- system development (through first unit fabrication), and
- system ‘launch’ and operations.
TRLs 1-3 are considered the concept stage moving from basic to applied research where research to prove feasibility is conducted. TRLs 4-5 are the validation stage where the technologies are developed and demonstrated in the laboratory. TRLs 6-7 are the prototype demonstration phase where the technologies move out of the lab to relevant and operational environments ending with an actual system that is “operational qualified”. TRLs 8-9 are the testing, evaluation, and application phase were final system verification and validation takes place with TRL 9 the final stage using the “operationally proven” system.
In the TRL model, technology maturity increases while risk decreases as we progress through each level. While it may not always be necessary to develop a technology through every level, the risk associated with skipping levels should be accessed against the cost of progressing through each level. The TRL model is designed to be used with individual technologies, those enabling technologies that have been identified in the concept stage as showing promise in meeting the system requirements.
One key management function is assessing the progression of the technologies of interest through each of the TRLs. The key question asked is, “when will the technology be mature enough to be considered viable?” In the acquisition world, technologies are not normally considered viable candidates until they reach TRL 3. Technology candidates that are at TRL 3 then go through the assessment stage in TRLs 4 and 5 and a functional prototype demonstration in a relevant environment at TRL 6. It is highly recommended that a given technology be at TRL 6 before being chosen for inclusion in the final product’s pre-production development phase. The technology level should be at TRL 6 by the preliminary design review and TRL 7 at the critical design review of the final product. Once the system is built and has been verified that it meets the requirements, the TRL is at 8, and once system validation is complete, the TRL level will be at 9.
An important note: TRLs are based on the specific application (use) of the technology AND the operational environment in which the system will be used. Thus an existing system may be at TRL 9 for its specific use and operational environment, but if you plan to use the system in for a different use and a different operational environment, the TRL drops to at least a 6 until you can prove otherwise.
The purpose of some projects is to develop an interim product that can be used to demonstrate technologies in a relevant environment. Thus there may be projects whose sole purpose is to mature a technology. Even with these types of projects, projects can use TRLs to manage risk by ensuring the technologies are mature enough to meet the objectives of the technology demonstration activity.
I go into a lot more detail about TRLs in my paper, “Developing Requirements for Technology-Driven Products” from which Table 1 was taken.
How do you determine the maturity level of a technology?
A key question is how to determine the maturity level of a technology. The TRL is dependent on the assessment of the maturity of the technologies used in all parts that make up the system. Conducting this assessment is the subject of a new document released by the Government Accountability Office (GAO): “Technology Readiness Assessment Guide”. As the title suggests the focus of the Guide is on assessing the technical readiness of technologies critical to the success of a project. To learn more about Technology Readiness Assessments (TRA) see my blog: Technology Readiness Assessment Guide – GAO.
- Don’t be mislead when you hear the statement: “the technology exists to do this…..” When you hear this statement always ask: “what is the TRL level of the technology needed?” If the answer is a low TRL, then your next questions should be: “is there a clearly defined strategy for maturing the needed technology?”, “do you have a technology maturation plan in place?”, and “can you get the technology to a high enough TRL within the given budget and schedule for the project?” The answers to these questions will help to understand and manage the risk.
- To minimize the risk of writing unattainable requirements, it is essential that requirement writers work with the stakeholders to ensure that their wants, needs and expectations are attainable in the context of cost, schedule, and technology. Unattainable expectations need to be reset. Don’t be afraid to push back when customers or other stakeholders provide you with requirements that are not attainable (at least within the stated cost and schedule) because of the low maturity of the technology needed to meet the requirements.
- Involve the developers and verifiers during elicitation and requirement writing. If they feel the requirement is not attainable due to the low maturity of the technology needed to meet the requirement, do not accept the requirement.
- Define risk as an attribute of each requirement. Attainability is often not a black/white determination. Access the risk of not meeting a requirement as part of your attainability assessment. If the TRL level is low for the technology needed to meet the requirement, then the risk to the project is high. Indicate this in the risk attribute. This will provide management a tool to manage the product development activities and to put risk mitigation steps in place before problems occur.
Remember, allowing unattainable requirements because of low maturity of the technology needed to meet the requirement will place a project at risk of significant cost overruns, schedule delays, performance shortfalls, and project failure. So, always consider TRLs!
