Realistic Time to Market (2)
Technology Readiness Level
EPISODE 2/2
In the first episode of this article, I presented the TRL (Technology Readiness Level) scale and showed how it could be used to ask questions about your plan and what assumptions you have behind it.
In this episode I'll continue and discuss Risk aspects and provide an example. Then give tips and links for your to develop this concept further with your team.
Before we continue, I'd like to emphasizer that TRLs do not provide a roadmap or a plan; they don't provide instructions how to progress between levels, and cannot tell you how difficult or expensive it is to move from one level to another.
However, each level can focus your team's attention on the relevant risks and uncertainties to be addressed and discovered. Also it shows you that if you didn’t pass a certain level, you probably shouldn’t move to other levels just yet - if you don't have all the subsystems working and tested don't rush into establishing a full production environment for example; thus you can avoid the pain of rushing in your plans, and spend unnecessarily.
TRL of risks
Similar to the "TRL of your Assumptions" section, here we will focus on Risks. I find TRLs especially useful for managing project risks in two main aspects:
First, the levels provide necessary conditions in the journey of product realisation. Missing a maturity-related risk will usually cause pain in the project.
Second, it can provide a simple reference, a checklist, for analysing the project’s risks, where missing a level or questions related to a level will probably increase the chance of things going wrong later.
I think an example will clarify a lot; let’s examine a common chargeable battery in your product; you probably won’t go and develop your own chargeable battery (unless you are competing with Tesla, for example), so you'll need to buy it off-the-shelf. Nevertheless, here are some TRL questions you should ask about such battery before you make up your mind, and incorporate it in your product design.
To clarify, in this example, these are the TRLs related to your product,
not the battery’s development!
In this example, I believe you should start at level 3 (Assuming you already have a proper datasheets for the battery, otherwise you probably want to avoid this component)
TRL 3 (Critical Function)
Are there specific conditions for the design around such battery, and are they considered in the project’s design? For example, can the battery work while being charged all the time?
TRL 4 (Lab Environment)
Are the datasheets accurate for the batches of batteries used? And what lab tests are going to approve the numbers?
TRL 5 (Relevant Environment)
After building a version of the product, what is the expected operation time with the battery? How often does the user need to recharge it?
TRL 6 - Subsystems
Is the battery certified? And is the supplier certified?
TRL 7 - System Development
What shipment arrangements are needed for the battery?
TRL 8 - System Validation
Is it easy to install the battery in production, are there issue that might cause harm to the battery during installation?
TRL 9 - System Operations
How often will the battery be replaced, and by whom (the user or technician?), and if they do so improperly could it impact a failure in the operation of the product?
I hope you start to get the idea. For example, you might skip testing a battery in your lab (question under TRL 4 above) and trust the datasheet only, which has a statistical deviation anyway); is it worth the risk of finding out later that you need a bigger battery or a different one? Or think if you defer TRL6 questions about certification in design stage, first if the battery and the supplier are certified this will make it easier and cheaper(!) to certify your product, if not, however, the certification will cost more, and might even fail in extreme cases requiring further fixes to your design at a late stage.
Moreover, although these issues are technical in nature, they automatically become project obstacles as well. Any issue arising with the battery will probably cause more unplanned work, which requires more time and budget for the project – hence, a project risk. Soon, scrutinising questions will come asking why this wasn’t discovered before, and a technical matter becomes an organisation issue with impact on sales forecast, business obligations and agreements, let alone internal rapport.
IRL (I for Integration)
TRL does not directly address the issue of integrating subsystems or components. Even when two technologies or components are proven with a high TRL, it doesn’t automatically mean their integration will be trivial!
A classic example for integration readiness is the failure of Mars Climate Orbiter (MCO) from 1998, attributed to integration problems between Metric and Imperial (English) measuring systems. Think about the battery example above, what if you need several batteries to increase the power or operation time in your product, how easy would it be to “integrate” those batteries together, whether these are multiples of the same battery, or maybe of different types?
There have been further efforts to develop an IRL (Integration readiness level) methodology, by applying a matrix that combines the TRL of each component, and estimated risk of integration. This is a fairly new subject of research and certainly suits more complex systems.
If your product's architecture is mostly about integration of components you can find this article interesting:
From TRL to SRL: The concept of systems readiness levels.
Sauser, Brian & Verma, Dinesh & Ramirez-Marquez, Jose & Gove, Ryan. (0002).
empower your team
I encourage organisations to develop their own product realisation process; including maturity checklists and readiness levels, in a way that suits the organisation, its potfolio of products , and its teams.
While It is good to have a reference how other organisations do it, eventually you need to adopt what you need. For example, your organisation may never invest in pure scientific research, so TRL1 is irrelevant: you will use only scientifically-proven technologies. Or your organisation may decide only to focus on proven off-the-shelf technologies without any in-house labs, and build from TRL6 and above.
Also, as all this sounds more suited for hardware based products, a word on software development is very relevant here. Are you using libraries, cloud services, freeware, Etc? intuitively you want the “established” proven services – in the language of this article a “TRL 9”. You could adopt a TRL scheme to decide what services you want to adopt, and how much development you are willing to invest before using them (for example to trade-off buying a license vs. developing a TRL 6 or 7 software component)
To conclude, think of TRLs as alarms for the "cost of failure", that gets much higher the more the program advances: think the difference between finding of a wrong parameter that must be changed, say size of a component, in the tests of lab environment, as opposed to finding the same issue just before handover to production. Let alone finding a problem after product launch.
Like any other tool, The TRL, is not a silver bullet or an absolute truth “commandments” list, just like any other tool you may use. It adds to teams alignment by providing a common language and a common scale among all stakeholders, when discussing “where you are”, and “how far you are” from the market.
It might seem as a long journey through nine levels, but it will still be much shorter than a blind “trial and error” by inexperienced teams, which I’ve observed to cost teams double or more the time to market.
NEXT steps
Observe:
Cost of delays and failures in your organisation, and how often you hear questions like "how could this happen?"
Don’t:
Copy and Paste a process from somewhere else, without internal discussion and adaptation.
Do:
Define your TRL and align your teams and stakeholders to your organisation's journey from ideas to market.
Read:
Detailed definition and application of TRL from NASA’s website:
https://www.nasa.gov/pdf/458490main_TRL_Definitions.pdfDetailed definition and application of TRL from MRMC for medical devices:
https://mtec-sc.org/wp-content/uploads/2016/12/TRL-definitions.pdf
