Solving the R&D to Product Conundrum

March 12, 2020

The journey from research and development to product is an arduous one - but it doesn't have to be this way. Learn how OEMs can simplify the process with multi-level testing and sound documentation.

Critical Software Image

To Think Big or Not to Think Big?

The great equaliser of ideas, big or small, is where they are born: in the mind. In the defence sector, arguably the biggest challenge is the journey from idea to product. OEMs in the defence sector are time-pressured when it comes to developing new products, mainly due to the resources needed to service demands made by existing products. As a result, R&D often takes a backseat role for OEMs. However, things don’t need to be this way…

Let’s take a look at some of the key challenges faced by defence OEMs when making the journey from R&D to product, and how the approach adopted by partners like Critical Software can help OEMs innovate with their R&D while also maintain their existing product lines.

Baby Steps…

Much of the issue surrounding R&D relates to the size of the task that OEMs are faced with. However, this can be overcome through a more incremental approach to dealing with each stage of the R&D and production processes. Let’s explore what we mean by this…

OEMs may get some way through their R&D but will face some challenges to ‘productise’ the research and development because of the various other product lines that they must deal with. Yet an incremental, step-by-step approach to R&D and ‘productisation’ naturally unlocks the potential for this journey to be more manageable, splitting each part into bite-sized chunks which make progress more likely to be achieved while also minimising disruption to existing product pressures.

The R&D process begins with the bigger picture. A holistic view of the project in hand needs to be achieved, usually involving considerable field work to assess the conditions that the product will be used in. This provides the perfect scenarios for significant prototype testing, which can help identify and resolve issues at an early stage of the process, leading to efficiency savings later on.

While useful, this is just the first step in a longer process which sees R&D dreams become product realities. Yet the close co-operation between Critical and the client ensures initial testing is completed properly and efficiently, reducing workloads further down the line.

Testing, Testing…

Testing poses a great challenge to product development in defence. Naturally, mission-critical applications need to be tested rigorously to achieve maximum operational safety. These will often be multi-layered, with an array of tests being applied to the product to ensure compliance with multiple different sets of standards. The process used by Critical Software involves a multi-level testing system, including:

  • Expert review (where product operationality is reviewed by specialists)
  • Usability testing
  • Functional testing
  • Performance testing
  • Security testing
  • Laboratory integration testing (where hardware add-ons are tested once implemented with software systems in a laboratory environment)
  • Real field testing
  • Interoperability testing (to confirm whether the product can operate alongside other products as required)

Most of these are tests you’d expect to be carried out during the development phase of a new product, ensuring that it functions as it should; is usable from a user experience point-of-view; secure when in use; and allows for easily integration into other systems if required.

Of course, testing is only as good as the documentation produced of its results. Let’s look at best practices when it comes to documenting a product during its journey from R&D to product…

Taking Notes

Documentation is inevitably a key part of the ‘productisation’ of any R&D activities. If the correct documentation isn’t produced during this process, then everything from product functionality to testing validity could be compromised.

Documentation will also allow that the product ultimately created complies with both standard agreements and, to a lesser extent, regulatory standards, ensuring that the product is standardised and interoperable with other products. In some cases, these standards are set by supranational defence authorities (for example, NATO) with the purpose of ensuring systems used by the organisation are fully compatible with each other.

When it comes to compiling documentation and presenting it in the correct way, a certified quality management system (QMS) can help. Using certification methods such as the Capability Maturity Model Integration (CMMI), the QMS’ effectiveness as an easily accessible pool of resources documenting key technical processes can be quantified. This ultimately promotes both an efficient mindset when working on the project, as well as improves team and customer understanding of how the project is developing and the processes that need to be followed to reach standard agreement compliance.

Putting Things Together

Through dividing R&D into bite-sized chunks, as well as adopting a user-first approach to the entire process, ‘productisation’ doesn’t have to be the all-consuming task. Having an engineering partner organise a process which regularly involves the client, but ultimately takes on a considerable portion of responsibility for the R&D delivery itself, lessens the workload for the OEM yet still ensures the product’s functionality, usability, security, and interoperability.

Learn more about how teamwork can make the dream work by checking out our case study on navigating the R&D to product journey.