Why the Technology Readiness Level is vital in innovation

Terminology is vital in most sectors but never more so in the innovation process. For an industry in its relative infancy, getting the nomenclature correct will help innovators articulate the benefits of what we do to others. And one area I believe we’re struggling with at the moment is the definition of evidence when testing solutions as part of the innovation process.

I’ve long maintained that the cornerstone of innovation is the trial. The trial does all the hard work for you: it evidences the benefits, highlights the risks and, crucially for scaling and wider adoption, tells the story. But the evidence definition actually has three different flavours, and we do need to differentiate between them based on their ISO-approved technology readiness level (TRL). The TRL was developed originally by NASA, and today, innovators can use it to select the most appropriate evidence pathway to demonstrate their solution. The following graphic, explains what this means:

Proof of Concept (TRL 1-3)

Even for large corporations, it can still be hugely beneficial to experiment with technology straight out of the laboratory. While probably too early to scale, be fully de-risked and lacking any kind of commercial proposition, there are still significant learning opportunities to be had.

About 10 years ago during the height of excitement about blockchain, a supplier contacted our innovation team to ask if we wanted to be part of a study into it with other partners. The idea was that each organisation would have its own node with the orchestration handled by the supplier. We would provide the data, and learn about the way blockchain works while the supplier would be able to undertake some early product development. True, the supplier would probably stand to benefit more than the partners, but it would be low-risk and generate a useful return for all involved. This is a proof-of-concept.

There was never any intention at the conclusion of the project to jump straight into procurement, and nor was there any need to. With a low TRL, this would be all about learning and raising awareness of the capability with internal colleagues for future reference. Anything beyond that becomes a trial.

Trial (TRL 4-6)

For technology with a higher TRL, and critically, where we would need or want to test with different user groups, the trial comes in. Most of the time, PoCs are too early for end users as expectations can vary wildly. But once you’re ready to do that, and have some objectives and measures of success in mind, the solution is ready to go to a trial.

Trials require an element of design to them and this is the major difference beyond the PoC. You need a scope, timeline and objectives as a minimum. Objectives should be broad and you must allow all groups involved in the trial – even the supplier – to set them. When the trial completes, a report is compiled and the objectives revisited to measure success.

In my experience, solutions with mid-level TRLs can be scaled into outturn solutions. But more often than not, you can scale up the trial into a pilot, as described next.

Pilot (TRL 7-9)

It’s possible that you’d encounter a scenario where a trial is successful but there’s still some doubt. Perhaps the ability to work at scale. Or work with a greater variety of end users. A pilot is where the same trial approach can be tested – but at a much larger scale. More users, more installations and a longer timeframe are the hallmarks of a pilot.

Typically, a pilot would have Innovation support but would be project-managed as if it was a business-as-usual (BAU) programme. You would definitely want to bring in external project or delivery resources to handle the business change and scaling up. If the pilot run as a project, you’ll also learn about scaling and installation, including what’s involved. This approach makes it easy to settle into a fully-funded and supported outturn solution, too.

Pilots offer the flexibility of steaming straight into BAU but with some well-placed controls. At the end of a pilot, you can still back out if it’s not working. Similarly, your team might happen upon a solution that is well-proven and ready to go. But the business is concerned about the adoption, and this is where a pilot would work well in serving both needs.