What Should Be Included in a Process Design Package?

Introduction

A Process Design Package, or PDP, is one of the most important technical deliverables in an industrial project.

It translates process knowledge, test results, assumptions and operating requirements into a structured engineering basis. A good PDP turns scattered technical information into a package that engineers, suppliers, project managers, operators and decision-makers can use consistently.

For industrial companies and technology developers, the PDP often marks the point where an idea, concept or pilot result starts becoming a real project. It helps teams move from concept or pilot stage into engineering, procurement, construction, commissioning and operation with a clearer understanding of scope, risk and technical maturity.

A weak PDP has the opposite effect. It creates ambiguity, vendor uncertainty, rework, poor estimates, scope gaps and start-up problems. The project may still move forward, but it moves with assumptions hidden inside emails, sketches, test reports and individual memories instead of controlled engineering documents.

What Is a Process Design Package?

A Process Design Package defines the process basis for an industrial facility. It describes what the process must do, how it is expected to operate, which equipment and utilities are required, which assumptions have been made and which information still needs to be confirmed.

A PDP can be used for pilot plants, demonstration plants, first-of-a-kind plants, commercial plants and technology scale-up projects. The level of detail may differ, but the purpose is the same: create a structured technical basis that supports the next phase of engineering and project execution.

A PDP is not the same as detailed engineering. It should define the process and technical basis, but it normally does not include every final piping detail, civil calculation, cable schedule, structural drawing or construction isometric.

Detailed engineering turns the approved process basis into construction-ready documents. The PDP sits before that. It gives detailed engineering, procurement, cost estimating, permitting, safety review and commissioning planning a coherent starting point.

Where the PDP Fits in the Project Lifecycle

The PDP usually sits between early concept development and the later execution phases of a project. It may be developed during basic engineering, as part of FEED, or as a separate package before an EPC tender or investment decision.

In a typical project lifecycle, the process basis develops through concept development, feasibility, basic engineering, FEED, detailed engineering, procurement, construction and commissioning. The PDP helps connect these phases. It captures what is known, identifies what is still uncertain and gives the next phase a controlled technical reference.

The PDP is often used as the basis for:

• FEED development
• EPC tendering
• vendor enquiries
• cost estimating
• permitting support
• HAZOP preparation
• project execution planning
• commissioning planning

This is why the PDP should be practical rather than academic. It must be clear enough for a process engineer, but also useful for procurement, project controls, construction planning and operations readiness.

Why the PDP Matters

A good PDP improves engineering quality because it forces the project team to define the basis before large commitments are made. It makes design cases, equipment duties, utility loads, operating assumptions, control intent and battery limits visible.

It improves scope definition because the package shows what is included, what is excluded and where interfaces exist. It improves vendor quotations because suppliers receive a clearer technical basis. It improves cost estimating because estimators can see the process assumptions behind equipment size, utility demand and package scope.

A strong PDP also improves project planning, risk management, commissioning preparation and start-up readiness. It gives the project team a better chance of understanding which systems need to be available first, which vendor packages require support, which utilities are enabling systems and which assumptions may affect start-up.

A weak PDP creates predictable problems:

• technical queries that should have been resolved earlier
• inconsistent assumptions between engineering disciplines
• vendor clarification loops
• missing utility loads
• incomplete equipment definition
• late P&ID changes
• poor cost control
• unclear responsibilities
• commissioning delays

The issue is rarely one missing document. The real issue is an unclear basis. When the process basis is not controlled, every downstream activity has to absorb the uncertainty.

Basis of Design

The Basis of Design is the anchor of the PDP. It defines the conditions, constraints, standards and assumptions used to develop the process design. If the Basis of Design is vague, the rest of the package will usually become vague as well.

A useful Basis of Design should include the technical and project conditions that influence the design. Typical contents include:

• project objective
• design capacity
• design cases
• operating cases
• turndown requirements
• feed specifications
• product specifications
• waste stream assumptions
• site conditions
• ambient conditions
• utility availability
• battery limits
• standards and codes
• redundancy philosophy
• design margins
• assumptions
• exclusions
• project constraints

The Basis of Design should be specific enough to guide decisions. For example, stating that cooling water is available is not enough. The package should define temperature levels, pressure, quality, flow availability, seasonal limitations and the responsible party at the battery limit where relevant.

The problem is not that early-stage projects contain uncertainty. The problem is when uncertainty is hidden. A good PDP makes assumptions visible, labels their maturity and shows what still needs validation before the project moves into later phases.

Design Cases and Operating Cases

Design cases matter because industrial plants do not operate at one perfect steady-state point. Equipment, utilities, controls and safety systems may need to handle different conditions at different moments in the plant lifecycle.

A PDP should identify the cases that are relevant for the project, such as:

• normal operating case
• maximum capacity case
• minimum turndown case
• start-up case
• shutdown case
• cleaning or flushing case
• abnormal operating case
• future expansion case

Different equipment and utilities may be sized based on different cases. A pump may be governed by maximum flow. A heat exchanger may be governed by a cleaning or start-up condition. A vent system may be governed by an abnormal case. A utility header may be governed by a peak demand that never occurs during normal operation.

If these cases are not defined, the project can end up with inconsistent sizing decisions. Some items may be oversized without reason, while others may be unable to support start-up, turndown or future capacity requirements.

Process Description

The process description explains how the plant is intended to operate. It should be understandable for engineers, operations, project managers and technical decision-makers, not only for the person who developed the concept.

A strong process description describes the main process steps and the logic behind them. Depending on the project, it should cover:

• feed receipt
• pre-treatment
• reaction or conversion steps
• separation
• filtration
• drying
• product handling
• off-gas treatment
• waste handling
• utility use
• start-up
• shutdown
• abnormal operation
• cleaning and flushing
• batch or campaign operation where applicable

The description should not just repeat the PFD in words. It should explain why each section exists, how the process is controlled, which operating modes are expected and where the practical limits are.

This section is often where hidden assumptions become visible. If nobody can clearly describe how a system starts, stops, drains, isolates, recovers from an upset or prepares for maintenance, the design is not mature enough.

Mass and Energy Balance

The mass and energy balance is one of the core documents in the PDP. It defines the flows, compositions, temperatures, pressures and duties that underpin the process design.

A good balance should include feed streams, product streams, recycle streams, purge streams, waste streams, off-gas streams, water balance, solvent balance where relevant, reaction conversion, yield assumptions, heating duties, cooling duties, evaporation loads, condensation loads and utility consumption.

The mass and energy balance should align with the PFDs and equipment sizing. Stream numbers, operating cases, units, compositions and duties should be consistent. If the balance and the diagrams do not match, suppliers and engineers will spend time resolving contradictions instead of progressing the design.

For technology scale-up projects, small errors can create large downstream consequences. A small change in conversion, moisture content, recycle ratio or heat duty can affect equipment size, utility systems, waste handling, control strategy and start-up behaviour.

Process Flow Diagrams

Process Flow Diagrams, or PFDs, show the main process arrangement. They are not P&IDs, but they should be complete enough to understand how the process works.

PFDs should show:

• major equipment
• process streams
• stream numbers
• key operating conditions
• major control concepts
• high-level utility connections
• recycle streams
• purge streams
• waste streams
• stream table reference

The PFD should communicate process intent without becoming overloaded. It should show enough information for a reviewer to understand the process route, main equipment, stream relationships and key design conditions.

The PFD also provides a bridge between the mass and energy balance and later P&ID development. If the PFD is incomplete, the P&IDs will often inherit uncertainty and become a place where basic process questions are solved too late.

Utility Summary

Utilities are often underestimated. A process may look simple when only the main process equipment is shown, but industrial operation depends on support systems that must be available, sized and integrated correctly.

The PDP should define requirements for:

• electricity
• steam
• cooling water
• chilled water
• hot water
• thermal oil
• instrument air
• plant air
• nitrogen
• process water
• demineralized water
• natural gas
• wastewater
• ventilation
• drainage

For each utility, the PDP should mention normal demand, peak demand, pressure, temperature, quality, availability requirements and redundancy requirements where relevant.

The utility summary should also consider commissioning and start-up. Instrument air may be needed for control valve testing. Cooling water may be needed for rotating equipment trials. Nitrogen may be required before process materials are introduced. Electrical distribution and control systems often need to be available before many other systems can be tested.

Equipment List

The equipment list translates the process concept into physical assets. It is one of the main scope control tools in the PDP because it shows what equipment is included, how it is identified and how mature the definition is.

Typical fields include:

• tag number
• equipment name
• service
• equipment type
• capacity
• design pressure
• design temperature
• material of construction
• duty or size
• package scope
• remarks
• status or maturity

The equipment list should be controlled and consistent with PFDs, datasheets and cost estimates. If an item appears on the PFD but not in the equipment list, the project needs to resolve the mismatch. If a cost estimate includes a package that is not clearly defined, the project needs to understand what is actually included.

Status is important. Early equipment lists often contain preliminary capacities, assumed materials or vendor-dependent details. That is acceptable if the maturity is visible. It becomes a problem when preliminary values are treated as final.

Equipment Datasheets

Equipment datasheets translate process requirements into structured information that suppliers and engineers can use. They are used for vendor enquiries, technical clarification, budget pricing, procurement preparation and later detailed engineering.

Datasheets may be needed for:

• tanks
• vessels
• pumps
• heat exchangers
• filters
• reactors
• dryers
• compressors
• blowers
• dosing systems
• skids
• packaged units

Datasheets should include process requirements such as flow, pressure, temperature, composition, duty, materials, operating range, design conditions, special requirements, cleanability, maintainability and vendor interface requirements.

For packaged units, the datasheet or package specification should define what the vendor scope must achieve and how it connects to the wider plant. Utilities, controls, drains, vents, data exchange, maintenance access and commissioning support should not be left to assumption.

Instrument List and Control Philosophy

The PDP should include the key instrumentation and control basis. It does not need to contain every final instrument detail, but it should define the main measurements and control functions needed to operate the process safely and reliably.

The instrument and control basis should cover:

• main measurements
• control loops
• alarms
• trips
• interlocks
• shutdown functions
• operator interface
• local control panels
• package control systems
• manual versus automatic operation
• data logging
• safety-related instrumentation

A process must not only work in theory. It must be controllable in practice.

The control philosophy should explain what the control system is trying to achieve. Which temperatures protect product quality? Which pressures protect equipment? Which levels prevent overflow, dry running or unstable operation? Which measurements are required for start-up, troubleshooting and performance verification?

These decisions affect P&IDs, automation scope, supplier packages, commissioning tests and operator training. If the control basis is left too late, the project may discover during commissioning that the process is installed but difficult to operate, test or start.

Safety and Operability Inputs

The PDP should provide enough information to support safety and operability reviews. It does not replace formal safety studies, HAZOP, LOPA, ATEX review or detailed relief design, but it should give those activities a strong technical basis.

Relevant safety and operability inputs include:

• hazardous materials
• operating limits
• relief and venting considerations
• hazardous area assumptions
• chemical compatibility
• abnormal scenarios
• overpressure scenarios
• start-up risks
• shutdown risks
• sampling requirements
• emissions and waste considerations
• preliminary HAZOP input
• safeguards
• interlocks

The aim is not to close every safety question inside the PDP. The aim is to prevent safety-critical assumptions from being invisible. If the process has known limits, hazardous materials, abnormal modes or venting constraints, they should be visible before later engineering phases make the design harder to change.

Battery Limits and Interfaces

Battery limits are critical because they define where one scope ends and another begins. In industrial projects, many problems are not caused by the process itself, but by unclear interfaces between owners, EPC contractors, licensors, vendors, utilities and existing facilities.

The PDP should define interfaces for:

• process feeds
• products
• utilities
• waste streams
• off-gas streams
• control systems
• electrical systems
• civil and structural scope
• vendor packages
• tie-ins to existing facilities
• owner, EPC and licensor responsibilities

Each interface should have a clear technical condition, owner and responsibility. That includes flow, pressure, temperature, composition, availability, control signals, documents, physical connection points and operational constraints where relevant.

Unclear interfaces cause scope gaps, commercial disputes and execution delays. They also create commissioning problems because systems cannot be tested properly when responsibility at the boundary is unclear.

Plot Plan and Layout Inputs

A PDP may include preliminary layout information. It does not need to solve detailed layout, but it should identify layout constraints that affect engineering, procurement, construction, operation and maintenance.

Useful layout inputs include:

• equipment arrangement
• access requirements
• maintenance space
• lifting requirements
• hazardous area considerations
• operator access
• logistics
• tie-in points
• utility corridors
• future expansion space

These inputs help the project avoid designs that look acceptable on a process diagram but are hard to build, maintain or operate. A pump may be correctly sized but inaccessible. A filter may be technically suitable but impossible to open safely. A skid may fit the plot but leave no practical route for maintenance or lifting.

Vendor Package Requirements

Many industrial projects rely on vendor packages. These may include skids, reactors, filters, dryers, compressors, dosing units, control panels, utilities or specialist process equipment. The PDP should define the requirements for these packages before procurement starts.

Vendor package requirements should address:

• technical scope
• process guarantees
• required documentation
• FAT requirements
• SAT requirements
• vendor attendance during commissioning
• spare parts
• training
• controls interface
• utilities interface
• operating manuals
• maintenance manuals

Vendor requirements should be defined before procurement, not discovered during commissioning. If a package needs vendor support for start-up, special software access, test certificates, preservation requirements or specific utility conditions, those requirements belong in the technical basis before orders are placed.

Commissioning and Start-Up Considerations

The PDP should already consider commissioning. Commissioning is not a separate world that starts after construction. It depends on engineering decisions made much earlier: system boundaries, drain points, utilities, isolation philosophy, control logic, vendor support and handover documentation.

Commissioning and start-up considerations include:

• systemization
• mechanical completion
• flushing
• cleaning
• leak testing
• loop checks
• functional testing
• utility availability
• start-up sequence
• vendor support
• operating procedures
• PSSR
• handover documentation

Thinking about commissioning during PDP development helps reveal practical questions. Can the system be flushed without contaminating downstream equipment? Can the control valves be tested before process materials arrive? Which utilities need to be available first? Which vendor packages need site support? Which documents are required before handover?

Documentation Deliverable List

The exact PDP deliverable list depends on project phase, complexity, technology maturity and the contracting strategy. A pilot plant PDP may be lighter than a commercial plant PDP, but both need a controlled basis.

Typical PDP deliverables include:

• Basis of Design
• Process Description
• Design Case Summary
• Mass and Energy Balance
• Process Flow Diagrams
• Stream Table
• Utility Summary
• Equipment List
• Equipment Datasheets
• Instrument List
• Control Philosophy
• Preliminary Cause and Effect input
• Battery Limits / Interface Matrix
• Preliminary Layout Inputs
• Safety and Operability Input
• Vendor Package Requirements
• Assumptions and Risk Register
• Open Items List

The list should be agreed early. That prevents teams from assuming that someone else is developing a document that is actually missing from the scope.

What Happens When the PDP Is Weak?

A weak PDP rarely fails in one obvious moment. It creates friction across the project. Technical queries increase. Vendors issue clarification rounds. Equipment is sized against inconsistent assumptions. Utilities are missing or underestimated. Battery limits remain unclear.

Common consequences include:

• technical queries
• vendor clarification rounds
• inconsistent equipment sizing
• missing utilities
• unclear battery limits
• late P&ID changes
• weak cost estimates
• poor procurement packages
• unclear operating procedures
• missing commissioning requirements
• unrealistic start-up assumptions
• weak cost and schedule control

The later these issues are discovered, the more expensive they become. A missing utility or unclear interface may be a simple discussion during PDP development. During construction or commissioning, it can become a schedule-critical problem.

PDP for Technology Scale-Up Projects

Technology scale-up projects need extra care because the process basis is often still developing. Laboratory data, pilot results and vendor experience may not yet describe all industrial operating conditions.

The PDP should separate:

• proven data
• assumptions
• pilot results
• test limitations
• scale-up factors
• design margins
• unresolved risks
• validation needs
• future test work

Uncertainty is normal in scale-up work, but it must be structured. A good PDP does not pretend that everything is proven. It shows what is known, what is assumed, what still needs testing and how uncertainty affects the next project decisions.

Pilot or demonstration plants should also define what the project needs to learn. That may include fouling behaviour, control stability, heat transfer, separation performance, operability, maintenance needs, cleaning frequency, waste generation or start-up sequence.

Common PDP Mistakes

Most PDP problems are practical rather than theoretical. The package may exist, but it may not be strong enough to support the decisions the project needs to make.

• Treating the PDP as a paperwork exercise. A PDP should guide engineering and execution, not just satisfy a document list.
• Copying lab assumptions directly into industrial design. Laboratory conditions rarely include all industrial constraints, utilities, maintenance needs or start-up behaviour.
• Missing design cases. Normal operation alone is not enough when start-up, shutdown, turndown, cleaning or abnormal cases drive equipment and utility needs.
• Underestimating utilities. Support systems often define whether the plant can be commissioned and operated reliably.
• Unclear battery limits. Interface gaps create scope disputes and late technical questions.
• Incomplete equipment datasheets. Vendors cannot provide reliable input when process requirements are incomplete.
• No control philosophy. A process that is designed but not controllable will create problems during start-up.
• No commissioning input. Testing, cleaning, flushing and handover requirements should influence the design basis.
• No operations input. Operators need access, procedures, maintainability and practical operating modes.
• Hiding open assumptions. Open questions are manageable when visible and dangerous when buried.
• Using vendor quotes before the process basis is mature. Early vendor input can help, but quotations built on weak data can create false confidence.

What Good Looks Like

A strong PDP is clear, consistent, traceable, practical and reviewable. It is aligned with project maturity and explicit about assumptions. It does not try to look more certain than the project really is.

Good PDPs are useful for engineering, procurement, cost estimating, safety review and commissioning. They help different disciplines work from the same technical basis and make it easier to challenge decisions before they become expensive to change.

The best PDPs also keep open items visible. They show what is known, what is assumed, who owns the next action and what decision depends on the answer.

Conclusion

A strong Process Design Package gives the project team a better basis for scope, cost, schedule, risk, procurement, commissioning and start-up. It turns process knowledge into a structured engineering basis that can be reviewed, challenged and developed further.

A PDP does not remove all uncertainty, especially in scale-up projects, but it makes uncertainty visible and manageable. That is where much of its value sits.

The better the Process Design Package, the better the project can move from concept to operation.