HCBBS Forum (English)
Submit Chemical Projects / Find Solutions
Amplify Your Requirements on a Broader Chemical Platform *Engineering · Technology · Equipment · Solutions*
Submit Request

The seven stages of chemical engineering technology from concept to industrialization (Issue 35/100) -- Project definition and scope

2026-06-03View Original

Thread Content

This post was last edited by xiouxingzhe on 2026-6-10 23:54. The seven stages of chemical technology from concept to industrialization (Issue 35/100) —— Technology finalization: Project definition and scope. Dear friends: Hello everyone! In the previous issue, we discussed the overall positioning of the process package – it serves as the technical “constitution” for the entire project, and the PFD is the sole data source for all subsequent documents. Starting from this issue, we will proceed to elaborate on each of the sixteen core tasks one by one. Today, let’s discuss the first item: project definition and scope. This task is the foundation for preparing the process package—first, the boundaries must be clearly defined. Whose technology is it? How big should the device be? What are the specifications of the product? Where is the boundary? What are the delivery standards? If these fundamental issues are not clarified, all subsequent work may go off track. I. Confirmation of technology origin and intellectual property rights
Before initiating the preparation of the process package, one thing must be clarified: Whose technology is this? Is it independently developed? Was it introduced from a technology provider? Are the pilot and scale-up data based on your own experiments or those of third parties? What are the ownership rights of intellectual property and the scope of licensing? Different sources of technology mean completely different starting points and risks for work. With self-developed technologies, what you have in hand is not only pilot-test data packages, but also a wealth of raw experimental records from the R&D process, lessons learned from failures, and the rationale behind the determination of key parameters. You know why each parameter is set to this value, and why each option chooses this path rather than another. When preparing the process package, if data is missing or boundaries are unclear, one can refer back to the original records or even conduct additional experiments for verification. The technologies introduced are different. What the technology provider gives you is usually a complete set of \"finished products\" – process instructions, design parameters, and performance guarantees. However, the mass transfer, heat transfer, and momentum problems that must be addressed in many engineering amplifications are not necessarily clearly described in the documentation provided by the technology suppliers. What they provide might be just a “skeleton”; the “muscles” and “nerves” that are needed to actually build the system, get it running, and ensure it generates benefits still have to be added by oneself. I gained a deep understanding of this when working on the international process package for the MDI project. The technical annex provides precise and detailed descriptions of various process parameters, control criteria, and performance guarantee values. However, much of the data is based on the other party’s own standardized design and needs to be adapted to our actual conditions. If these details are not clarified during the project definition phase, fundamental disagreements can easily arise in subsequent cooperation. Therefore, one of the things to do during the project definition phase is to clearly specify the source of the technology, intellectual property rights, scope of licensing, and the boundaries of responsibilities of the technology provider. The necessary patent approvals and licenses for the use of proprietary technology must be secured before official launch. One cannot wait until almost all of the process package has been prepared to realize that the rights to use a certain key piece of data have not yet been settled. II. Determination of plant scale and product specifications: What is the designed production capacity of the plant? How many hours are counted as annual operating time? What is the operational flexibility range? These issues need to be finally determined based on pilot plant data, in conjunction with market assessments. The designed production capacity is not a figure determined arbitrarily. Whether the annual operating time is 8,000 hours or 7,200 hours directly affects the calculation of the equipment’s capacity margin and the identification of system bottlenecks. Is the operating flexibility range 50% to 110% or 70% to 100%, with the upper limit of flexibility typically determined by the bottlenecks in critical equipment—possibly the maximum heat removal capacity of the reactor, or the maximum gas-phase load of the distillation column ; The lower limit of elasticity is usually determined by operational stability—too low a load may cause leakage in the distillation column and insufficient mixing in the reactor. The product specifications also need to be clearly defined. The purity of the main product and the upper limit for impurity content are key factors that directly influence the choice of subsequent separation methods. For example, if the required purity of a product increases from 99.5% to 99.9%, it may seem like only a 0.4 percentage point difference, but the difficulty of separation could be entirely different. The purity that could be achieved through conventional distillation may now require extractive distillation or molecular distillation – with investment and energy consumption potentially doubling. When determining product specifications, one should consider not only what one’s technology can achieve but also what the market demands. If the price difference between 99.5% and 99.9% is not significant, and you have to invest in an additional molecular distillation unit just for those 0.4 percentage points, then it’s not a cost-effective decision. Technical indicators ultimately serve economic benefits; the higher they are, the better it is, is not the case. III. Demarcation of Boundaries and Confirmation of Delivery Standards The boundaries, in simple terms, refer to the limits of responsibility. Where does your process package design extend to? Anything beyond that boundary is someone else’s responsibility. Within the defined area, your design must form a complete closed loop. All major equipment, pipelines, instruments, and control systems must form a complete process system that can operate independently within the boundary area. Outside the boundary area, you only need to clarify the handover conditions – at what temperature, pressure, and condition the raw materials enter your boundary area, under what conditions the products leave it, and where the utility pipelines meet. The boundary condition table is an important document in the process package; it corresponds to the boundary symbols on the PID. For every material and utility medium that enters or leaves the process area, it is necessary to specify its state, temperature, pressure, flow direction, flow rate, as well as whether the transfer is continuous or intermittent. This information serves as the basis for subsequent engineering design firms to carry out external supporting design. I have a small suggestion: for pipelines that appear in the zone entry table, they should be marked specially on the PID – for example, with zone boundary symbols or in a prominent color – so that reviewers can see them at a glance during verification and are less likely to miss them. The delivery standards also need to be defined during the project definition phase. Based on SHSG-052-2003, the only written standard in China for complete process packages, and taking into account the actual requirements of the project, the delivery list and level of detail required are determined. For some materials, such as the Process Manual and the Analysis and Testing Manual, it can be decided based on actual circumstances whether they should be prepared by the process package provider. It’s much better to clarify these things during the project definition phase than to end up arguing halfway through. IV. Signing of technical annexes – Project scope, plant scale, product specifications, and delivery standards – these elements need to be formally established in the form of technical annexes before official commencement. A high-quality technical annex should not only cover scope definition, but also include the design basis, scope of services, performance assurance indicators, and evaluation methods. The design basis should clearly specify the standards and specifications, meteorological conditions, geological conditions, and utility conditions on which the process package is prepared. The scope of services should clearly specify what the process package provider will and will not provide, as well as the scope of subsequent technical support and the response mechanisms. The performance guarantee indicators should clearly specify the production volume, quality, and consumption metrics after the device is put into operation, as well as how these metrics will be evaluated and what actions will be taken if they are not met. The technical annex is the “constitution” for the preparation of the process package. It not only specifies what needs to be done, but also defines what level is considered acceptable, how to assess performance, and what to do if the requirements are not met. Many potential disputes that may arise during the implementation of subsequent projects can find their basis in the technical annexes. When signing the technical annex, there is one important principle: do not make overly strict performance guarantees in order to facilitate cooperation. Technical annexes are legal documents, not marketing materials. Promise only what you can deliver; do not promise anything beyond your control. Especially when your technology has not yet been validated on an industrial scale, sufficient margin should be left when setting the performance guarantees. This margin is not for slacking off, but to absorb the inevitable uncertainties in the amplification process. In MDI projects, the precise descriptions of various process parameters and performance guarantees in the technical appendices provide clear boundaries for the advancement of the entire project. The solutions for many of the problems encountered in subsequent engineering design and commissioning tests can be found in the attachments. This is something I’ve realized quite deeply: by investing time in developing solid technical foundations early on, the management costs later on are significantly reduced. V. Common omissions in the project definition phase There are several aspects in the project definition phase that are easily overlooked; I’d like to offer some reminders based on my own experience. First, the auxiliary materials were forgotten to be listed. The medium list does not merely include the main raw materials and products; all materials that appear in the process flow must be listed as well—acids and bases used for pH adjustment, solvents used for cleaning, and nitrogen used for purging. Although these auxiliary materials do not participate directly in the reaction, they affect the selection of equipment and pipeline materials. Second, the operational flexibility only takes into account the upper limit and not the lower limit. Many people only care about “how much the best performance can be,” not about “what level is sufficient for stable operation.” But in reality, during the initial stages of driving or when there are abnormalities with the equipment, it is often necessary to operate at low load; if a lower limit is not taken into account, operations will become very difficult. Third, the boundary condition only specifies normal operating conditions and not startup conditions. The steam demand during startup can be much higher than under normal operating conditions; if the utility connections are designed only for normal conditions, they may not be able to meet the demand during startup. Preview for the next issue: Issue 36 – Collection of physical property data: the foundation of the process package. Once the scope of the project has been defined, the next fundamental task is to gather all the physical property data related to the materials used in the process. Boiling point, melting point, density, critical parameters, phase equilibrium data – these seemingly insignificant values form the foundation for all the calculations in the process package. If the foundation is not proper, anything built on it will be crooked. To be continued in the next issue.
Reply #22026-06-04
The original poster’s series is indeed packed with useful content, and the additions made by the friends who commented, such as “technical flexibility” and “material balance loop,” are also very practical. I encountered another issue in related projects: if the project definition phase is not properly aligned with the subsequent \"engineering design\" phase, it will lead to repeated rework later on due to adjustments made to parameters. It is recommended to preliminarily estimate the scaling factors for key equipment at the stage of defining the scope, such as the scaling margin for the area of heat exchangers and the power required for mixing, in order to avoid situations where everything works well during pilot testing but fails in scale-up testing. Furthermore, if \"technology finalization\" is to be included in the subsequent development of the process package, it is best to take compliance aspects (such as environmental emissions and safety distances) into account from the start. In many projects, efforts made earlier are wasted because the requirements regarding environmental or safety assessments are not met later on, forcing a reduction in the scope of the project. I look forward to the author discussing in future updates the methods for dynamically adjusting the scope boundaries when moving from pilot testing to pilot-scale testing

Submit a Project

**Looking for Chemical Technology, Equipment & Solutions?** No Registration Required Broader Platform Exposure | Global Chemical Service Provider Connections

Submit Request — Free Consultation

Disclaimer

This is an automated machine translation of the original thread. Some technical terms may have inaccuracies; the original text shall prevail. Click "View Original" at the top right to access the source page, which supports IP-based automatic real-time language translation. Please watch out for contact details and sales inducements to prevent fraud. All content and translations are for reference only, representing solely the poster's personal views. For enquiries, email service@hcbbs.com.