Home / Industry / Proofs of concept of Defense and Aerospace

Proofs of concept of Defense and Aerospace

A proof of concept is a demonstration of how a particular business idea works. You can use a proof of concept to show the feasibility of a product, service, business plan, or work process. Unlike a prototype, which is a working model of the proposed product, a proof of concept is a theoretical demonstration of the idea’s potential production and use.  A proof of concept focuses on the viability of a project, so you can determine whether your idea is worth pursuing and what might be required to bring the concept to fruition.

Companies often produce a proof of concept before pitching their ideas to investors. Employees or team leaders within a company might also develop proof of concept documentation to present a new product idea to management. Additionally, project managers can use POC documents as a framework for determining the final product development process.

A proof of concept should include an explanation of what the proposed product, service, or process does and how it is expected to work. Typically, a proof of concept is a document or presentation that introduces the audience to the idea, defines the target market, and gives an overview of the steps required to create the real-life version. Your final POC document should answer the following questions:

  • Can you reliably produce the product or service in a real-world setting?
  • What is the existing or potential market for this product or service?
  • Does the proposed idea work as predicted?
  • What technologies are necessary to smoothly run this project and produce the intended results?
  • Is there feedback received during the POC process that you can incorporate into the final project?

A POC that shows your proposed project has a high likelihood of a successful outcome can spur investors to approve the project. Completing a proof of concept will give you a clear idea of the final project’s overall costs. The POC process helps you spot risks or potential obstacles before you launch a product or service, so you can find ways to mitigate problems before they develop. You might uncover hidden costs during this process or find new ways to save money once the main project is underway.  A proof of concept gives you a chance to get feedback before the full project is in motion. This lets you make any necessary modifications before you fully invest in the idea.

Pharmaceutical companies use proof of concept to assess whether new drugs meet efficacy requirements and can be produced in a way that generates profit for the manufacturer. A proof of concept for a new type of snack food might begin with consumer surveys gauging interest in the flavor and style of the proposed snack.

Software products

POC in Software products or its separate function shows if it is suitable for solving a particular business problem. The availability of measurable criteria for assessing the success of the concept is an important point. Otherwise, you won’t be able to correctly interpret the results of the finished work. Here are a few questions, the answers of which will help you to draw up the necessary criteria list:

  • Why do we do this and what goals do we want to achieve?
  • Do you need to test a specific process, function or a general idea?
  • What hardware will be used for implementation?
  • Is there something that can be compared with this concept?
  • What real value do we want to achieve?
  • How will this be implemented into the workflow?

POC in software engineering provides you with two important advantages:

You can get proof that your idea is really worth making the effort to implement it.
You can avoid losing money by refusing to spend a budget on what is not viable or unnecessary for the market.

Biomedical

It is well-known fact that bringing a new drug to the market is a business of high risk. Indeed, it generally costs about $2.5 billion and lasts more than twelve years (Avorn, 2015) while the attrition rate along the life cycle is tremendous (Waring et al, 2015). Moreover, following the tradition of modern medicine as an evidence-based practice and responding to the excesses that have marked our history, the pharmaceutical and biomedical industry sectors are today characterized by one of the most regulated environments related to safety and ethics.

According to the Pharmaceutical Research and Manufactures of America (PhRMA), “[t]he POC demonstrates that the drug did what it was intended to do, that is, interacted correctly with its molecular target and, in turn, altered the disease” (Corr and Williams, 2009). Contrary to later stages of clinical trials, ‘proof of concept’ studies “typically involv[es] a small number of subjects and more latitude in statistical requirements” (Preskorn, 2014). Such ‘proof of concept’ or ‘POC’ studies must “provide evidence that a molecule is likely to be successful in later stages of drug development process (i.e., late phase II and large-scale phase III studies required for U.S. Food and Drug Administration [FDA] approval)”

 

Defense and Aerospace Products

Acquisition programs and projects in many organizations are broadly divided into phases of technology development, product development, production, and operation activities. These phases may be further divided by decision points or stage gates with criteria and activities that should be met or completed before committing additional resources to the project. Passing from one decision point to the next requires evidence and documentation, such as test reports, data analysis, and other assessments to demonstrate that these criteria have been met.

A Technology Readiness Assessment (TRA) is a systematic, metrics-based process that assesses the maturity of, and the risk associated with, critical technologies to be used in Major Defense Acquisition Programs (MDAPs). During the acquisition life-cycle, TRAs can monitor the progress of maturing technologies and determine how ready a technology is to make a transition from technology development to subsequent phases. A TRA is a systematic, evidence-based process that evaluates the maturity of CTs (hardware, software, process, or a combination thereof) that are vital to the performance of a larger system or the fulfillment of the key objectives of an acquisition program.

The TRA frequently uses a maturity scale—technology readiness levels (TRLs)—that is ordered according to the characteristics of the demonstration or testing environment under which a given technology was tested at defined points in time. The scale consists of nine levels, each one requiring the technology to be demonstrated in incrementally higher levels of fidelity in terms of its form, the level of integration with other parts of the system, and its operating environment than the previous, until the final level where the actual operation of the technology is in its final form and proven through successful mission operations.

TRL 2:  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 the assumptions.  Examples are limited to analytic studies. Publications or other references that out- line the application being considered and that provide analysis to support the concept.

TRL3  technology maturity level is  Analytical and experimental critical function and/or characteristic proof of concept. At this step in the maturation process, active research and development (R&D) is initiated. This must include both analytical studies to set the technology into an appropriate context and laboratory-based studies to physically validate that the analytical predictions are correct. These studies and experiments should constitute “proof-of-concept” validation of the applications/concepts formulated at TRL 2. Examples include components that are not yet integrated or representative.

Supporting information:  Results of laboratory tests performed to measure parameters of interest and comparison to analytical predictions for critical subsystems. References to who, where, and when these tests and comparisons were performed.

For example, a concept for High Energy Density Matter (HEDM) propulsion might depend on slush or super-cooled hydrogen as a propellant: TRL 3 might be attained when the concept-enabling phase/temperature/pressure for the fluid was achieved in a laboratory.

Moreover, the costs to achieve that were previously presented as low and unique are therefore presented as “low to moderate” because “the costs can vary significantly from one area of research and development to another”. The article also stated that “because of the relatively high risk and long lead times, it is less likely that funding at TRL 3 or below would be available from most types of venture funding sources” (Mankins, 2009).

In a handbook published in 2008, ESA declared that “the purpose of timely and accurate technology readiness assessments is to inform management and support decisions as part of the implementation of advanced technology system development projects” and “[t]he Technology Readiness Levels have been defined to provide a common metric by means”

In its report, GAO applied the framework of the TRL scale to assess various programs to better understand why some of them well or poorly performed. They found that DoD integrated technologies anywhere from TRL 2 to TRL 9 and programs that integrated TRL 6-technologies no longer experienced any additional cost. The main message of this report was therefore that by formalizing the maturity of technologies on the TRL scale and by refusing to support technologies that are too immature (below TRL 7 in any circumstances, with the preferred TRL 8 TLR 9), DoD will improve the performance of these acquisition programs (GAO, 1999; Jean, 2018). The DoD adopted the TRL scale in 2000.

 

References and Resources also include:

https://monday.com/blog/project-management/proof-of-concept/

https://lvivity.com/proof-of-concept-meaning

https://hal.archives-ouvertes.fr/hal-02570321v2/document

 

 

About Rajesh Uppal

Check Also

Designing for Success: Principles and Best Practices in Software Design

Introduction: In the realm of software development, success is often determined not only by the …

error: Content is protected !!