Process deliverables

The following innovation process deliverables apply to all projects within the research. Although all project leaders should adhere to the general guidelines of these deliverables, projects should not be forced into any type of rigid framework. The project team may decide not to include certain subcategories or add others where they see fit. 

Review Current Maintenance Processes. This activity is the start of a very important phase. This can be an opportunity to modify workflow processes for optimal efficiency. Review how maintenance is done currently before modifying existing processes. Deliverables information from this step includes the following ... 

Kerridge has provided an excellent article on the interface betw een the operating company and the contractor to define all requirements in complete and standardized detail. This includes who is responsible for every deliverable. The operating company and contractor must work as a team. An example of one area that needs to be reviewed often with the contractor is the provision of secondary systems as packages, perhaps from a third party. Such systems can easily become orphans. This problem is discussed in the Process Definition section of Chapter 16. 

Refinement results in realistic deliverables for each development cycle depending on what development process is most suited to the project. 

O 14. Standards deliverables, templates, process, QA (inspection, test, CM, ), tool. Cl 15. feckage structure, vertical/horizontal slices, increments, tools,... 

The roles and responsibilities of the transfer lab and the receiving lab as well as an outline describing deliverables and timelines should be defined clearly at the initiation of the assay transfer process. Once a transfer protocol is defined, any deviation from the protocol during execution should be discussed in the transfer report. Explanations as to why the deviation is acceptable should be included in the report. The transfer report should also be approved by relevant functional departments. Due to the complexity of multi-site involvement, having a good change control system in place is important for making SOP modifications or updates. 

Typical FEL Deliverables Every process engineer assigned to a project should be acutely aware of which deliverables or end products are required by those who must commission their work. This should be very well understood by all parties prior to starting the work. Further, the splits of work (who will do which aspect of the work) must be well understood. Today, it is very common to have multiple operating companies form a joint venture to authorize major projects. It is also common for multiple engineering contractors to form joint ventures to execute the engineering for the FEL phases of the ... 

Typical Conceptual Phase (FEL-1) Deliverables These are listed below. Each project will customize these deliverables to suit the particular needs of the project. There is no such thing as a standard FEL. Therefore, the process engineer must understand what the details are for each deliverable needed, what the minimum level is for the engineering required to meet those requirements, and in which formats that information and data will be needed. 

Typical FeasihiUty Phase (FEL-2) Deliverables These are listed below. In this phase, emphasis is on determining the best technical and economic flow scheme, as well as the support systems required to provide the necessary annual production rate at the sales quality required. The focus for the process engineer should be on confirming the number and type of process and technology studies needed, as well as the number of alternate cases required to be evaluated and/or simulated. 

Typical Definition Phase (FEL-3) Deliverables These are listed below. In this phase, emphasis is typically on optimizing the best flow scheme and support systems combination. This optimum includes consideration of the plot plan and equipment arrangements for the entire facility. Process optimization cannot be done in isolation. Significant and continuous interaction with operations, maintenance, and construction... 

Process owners require a defined set of responsibilities to maintain a vibrant and effective process that continues to support product quality deliverables. Having roles and responsibilities defined provides owners with the structure and parameters... 

A dedicated team or review board should be developed to review and approve all maturity-level deliverables upon completion of the attributes for the current level. This review board s purpose is to ensure that all deliverables meet a consistent level of quality and documentation. This board can provide feedback to process owners or QMS program group to communicate best practices and lessons learned. 

There are several deliverables from process chemistry [16], but perhaps the two most important are the rapid development of a supply route to the target molecule (necessary to meet the critical inihal development requirements) and the discovery and development of a robust commercially viable route of synthesis (required to meet the demands of the patient population). 

There are numerous advantages to this improved process. First, most of the gas stored in the cavern can be produced and the cushion gas requirement is minimal. Gas deliverability can also be maintained longer at the same level, since water injection keeps gas pressure in the cavern higher. Moreover, every time the cavern is refilled with water, more capacity is created for storage. Finally, the cavern can be further developed by resuming SMUG. 

Gather the requirements for the systems including functional (e.g. operational checks) requirements, nonfunctional (e.g., coding standards) requirements, users, company-wide regulatory compliance (e.g., Part 11 technical control), safety, process, and other applicable requirements Characterize information, assess its value to the organization, and incorporate information quality as part of the project plan Conduct a system (hardware, software, and process) risk analysis. New requirements may be found as the result of the risk analysis. Any new requirements must be documented in the requirements specification deliverable... 

The system requirements are captured in the requirements specification deliverable, which describes what the system is supposed to do from (a) the process, (b) the user s, and (c) the compliance perspectives. The requirements specification deliverable may be used as a framework to select the supplier/ integrator and to develop the PQ protocol. 

The requirements specification deliverable must include an overview of the process in order to familiarize the application software developer with the user, process and data acquisition requirements of the system, as well as special considerations for the project. The system functionality must be well defined at the outset, in order to provide the prospective supplier/ integrator with enough information to provide a detailed and meaningful quotation. 

The computer system specification includes information on how the operation can be controlled using the features in the selected application package. A review of the process must be conducted to familiarize the computer technology supplier and/or developer (external or in-house) with the requirements defined in the requirements specification deliverable. This system view is essential, particularly when the software must interface with other elements such as hardware, people, and databases. The review of the process includes the further gathering of requirements at the system level, and top-level design. 

The design process and resulting deliverable are based on, and clause traceable to, the information in the requirements specification deliverable. The technical design specification must specify how the combined hardware and software products will satisfy the requirements. 

During each software or system development step, the developer provides documented evidence that implementing the requirements specified in the requirements specification deliverable developed the product. During the design, the in-process (internal) audit must be carried out in order to verify that the design of the computer system satisfies the requirements described in the computer system specification deliverable, and that the code has been developed in accordance with the technical design specification deliverable. 

In a mature software development environment, software is developed as individual components or small units. Each unit is tested individually and integrated with other units to form a module. The accurate implementation of each module is achieved by following the technical design specification deliverable. The output of the software development process is an assembled system. 

The OQ must demonstrate that the functionality of the system is as established in the computer system specification deliverable. During the OQ, all systems interfacing with the computer system must be operational throughout the entire process. Document evidence must be obtained verifying execution of the various steps and functions detailed in test. The protocol must be approved and completed by the appropriate personnel. 

The computer system needs a comprehensive PQ test designed to determine the degree of accuracy with which the system conforms to the requirements specification deliverable. The computer system PQ should not be confused with the process PQ and the product qualification as described in the FDA Guideline on Principles of Process Validation. The PQ occurs under operational conditions but not as part of the actual operational process. The specific test cases include ... 

---