In our ongoing discussions about executing capital projects in the Process Manufacturing segment, we have described methodologies and shared tips for the first steps or phases in the overall project workflow that results in an installed solution.
These early phases have included the client’s reason for pursuing a capital investment (usually in the form of a problem statement with a business case), the client’s User Requirements Document which typically codifies what the client needs to accomplish through the project, then a Conceptual Design step (which involves a technology selection and then a first pass equipment/process systems design solution that meets the User Requirements), and most recently a Preliminary Engineering phase, which quantifies the process systems and equipment such that a more accurate, bottoms-up estimate can be performed, and credible cost forecasts can be generated to verify the delivery of the intended benefits and business case.
One of the intended purposes of the Preliminary Engineering step or phase is to reduce cost risk, so the client’s investment and its intended return can be validated. However, at this point in the overall project workflow, cost outcome is not the only risk that the client (and his selected integrator) has to deal with. We have found that successful projects identify and manage through mitigation planning all risks that might otherwise undermine the project ROI. This risk mitigation effort should occur prior to the customer/owner committing the majority of his funds to the execution of the project (the start of the design detailing/fabrication/procurement phase). One very useful risk reduction tool that we frequently utilize and recommend for technical issues is Proof-of-Principle work.
As we have described the progression of the project definition work from Problem Statement to User Requirements up to Concept Design, it is very possible that the project team during its technology selection activity in the Concept Design phase has chosen a new method, process, or machine that is emerging in the industry, but which has not to date been reduced to practice in the particular project application. The team may want to claim the benefits associated with this cutting edge technology, but the risk of not having a working example in their specific project domain is worrisome. A means to remove this worry is needed. This is where Proof-of-Principle can be employed.
A Proof-of-Principle activity can best be described as a parallel path series of tasks, initiated during the Preliminary Engineering phase, that is designed to allow the team to demonstrate in a limited fashion that their chosen approach will in fact work in their project application.
This Proof-of-Principle work is typified by having the following attributes:
- Utilizes a representative version of the chosen process technology, method, machine, subsystem, etc.
- Can be a smaller version (for example, ¼ scale), assuming that scaling up the Proof-of-Principle equipment will be linear and predictable
- Is only the required subset of the production subsystem where in lies the risk; the intent is not to prove the integration, only the functionality of the risky area
- Can utilize representative “Prototype” equipment that does not have to be production worthy. The intent is to demonstrate the subsystem’s ability to deliver the necessary product feature, or provide the needed reaction, etc. Proof-of-Principle is not designed to test for things like OEE, TEEP, MTF, and other mature system attributes.
- Will require the procurement of prototype equipment or process subsystem, set up, and experimental run off with results documented of associated process conditions
In conjunction with mobilizing the prototype equipment or process subsystem, Proof-of-Principle also requires that appropriate Design of Experiment work be implemented, and valid instrumentation and data collection be included, such that the prototype subsystem can be cycled under the client’s process conditions, and the needed performance metrics measured and recorded for analysis. Qualified engineering support needs to be involved to ensure that the prototype equipment, the DOE, and the data analysis all contribute to addressing the technical issues that comprise the risk in this area of the project’s process design. Engineering support will be vital in the case where the prototype performance results do not meet the client/owner’s needs, and the equipment set up may need to be modified, and the Design of Experiment revisited and re-run, until a domain or operability window is observed that finally meets the User Requirements.
At the successful completion of the Proof-of-Principle work, the responsible engineer (who was the principle for DOE, data analysis, and conclusion documentation) can now generate the necessary equipment specifications, based on the Proof-of-Principle results, and that will enable the team to move forward to complete their subsystem detailed design, then purchase or fabricate the resulting subsystem. With this important Proof-of-Principle work completed, the cost to move forward using the selected technology now has a much more acceptable risk profile, and will no longer put the project ROI in jeopardy.