Conceptual Engineering & Design:
Putting the right emphasis on conceptual engineering at the start of a project generally pays off extremely well in terms of well-contained or even lowered costs during the execution and completion phases. Good cost-containment or reduction is made possible by requiring fewer iterations through the design / review process, achieving much better coordination between the engineering disciplines, and generating far fewer mistakes. Better tracking and control of overall project cost is attained by being much more specific about individual cost elements of the project at an earlier stage. Our experience has shown that early identification of the High Risk aspects of a project, and their associated costs permits better management of these elements. More resources can be applied if deemed necessary, or, the higher risk elements may be dropped from the scope of the project at an earlier stage, before they negatively impact the rest of the project in a significant way. P-L has standardized on the design methodology outlined in I.S.P.E.’s Good Automated Manufacturing Practices guideline (GAMP4) referred to as the “V-model”. This model provides a solid framework within which to develop, document, and build upon the body of project knowledge. This, in turn, insures that good engineering practice (GEP) including Engineering Change Management and Design Qualification will be followed during the detailed design phase.
Economic Evaluation of Alternatives:
It is important to remember that a Capital Project represents a significant financial investment on the part of the Owner, and the Owner has a right to expect a reasonable return on that investment. Installing and upgrading Control Systems is an expensive and complicated undertaking. It is not uncommon for Control System vendors to extrapolate benefits far beyond what is actually achievable. Hand in hand with Conceptual Engineering & Design is the evaluation of alternatives for technical feasibility, economic viability, and overall payback on the investment in the project. We are the first to admit, maybe even the first to point out, that a capital solution may not be the most effective way of dealing with a problem. Our philosophy is that each and every project should be rationally analyzed with respect to its total installed or life cycle cost versus its anticipated life cycle benefits. In the course of performing this analysis, we often arrive at non-capital or capital-deferring solutions that present the better path for our clients.
Development of Standards and Specifications:
A factor that is often critical to the success of the project is the identification and development of suitable standards and specifications before detailed work begins on the project. Our familiarity with the standards and requirements of national and international regulatory agencies helps us to make sure that the project meets all applicable regulations. Beyond the issue of regulatory compliance is the absolute necessity of defining functional specifications and standards for the complete system, including hardware components, software functionality, operator interface appearance and behavior, and any other system attributes that have a bearing on the operation or support of the system. A large portion of the work done at the front end of a project is to fully understand the regulatory environment in which the client company operates. It’s important to know what the standards are that must be adhered to, and then interpret and articulate those standards into a set of project specifications for the executing groups to follow.
Scope Definition and Budget Preparations:
Occasionally we take on a project with little more than a problem-statement in hand. Our process knowledge and manufacturing experience allows us to work with that customer to enhance their understanding of the problem, analyze the underlying causes, and develop a comprehensive User Requirements Document, so that the final project, when completed, has fully addressed the original problem and is deemed to be completely successful. Once the User Requirements for a project have all been documented, and the risks and alternatives for the project have been thoroughly identified, reviewed and agreed upon, our approach has been to put together highly detailed documents and spreadsheets that specify the scope of a given project and we assemble a budgetary worksheet correlated to that scope. Our customers have used these documents in the preparation of their own funding request documents. Quite often, our work involves the putting together of complete project proposals that detail not only the scope of the project, but also include well-estimated budgets for the projects. This allows the client to view the project not merely as a whole, but also as a combination of all the elements and sub-elements that make up the overall scope. The client then has the tools necessary to consider and decide on each element as an incremental cost, knowing what its impact to the overall project cost will be.
Selection of System Architectures and Definition of Control Strategies:
One of the chief advantages of working with Process-Logic is our ability to provide cost-effective, function based control solutions that meet our customer’s needs and requirements, without gouging or over-specifying a system. We consider the immediate needs of the process and the status of any currently installed systems. Next, we consider the requirements for future expansion, along with the likelihood and the timeframe in which that expansion may occur. Finally, we consider the skill sets and training requirements of our customer’s employees. Based on these and other factors, we are able to design a system architecture that maximizes the return on our customer’s investment and minimizes the learning curve and ancillary spending (training, spare parts, etc.) required to install and support the completed system. Our second chief advantage is our ability to immerse ourselves into the production environment and understand, articulate, and document the System Functional Requirements into a comprehensive Software Design Specification. We have developed a systematic approach to developing Software Specs that allows equipment functionality and operator interface interactions to be detailed down to the finest level of granularity. Our method also allows for taking our Spec and directly translating it into an element-by-element Qualification Protocol, supportive of the V-model outlined in GAMP4. At the end of our projects, our Software Specification is quite often converted into a reference document that supports the ongoing training of the plant operations and maintenance personnel.