Process Design Package Development

A process design package is the technical bridge between a process concept and an executable industrial project. It defines what the process must do, what assumptions apply and what information engineering contractors, suppliers and investors can rely on.

Promacon supports PDP development for technology companies, licensors and industrial clients that need a practical, reviewable and connected process package.

What is included in PDP development

Typical deliverables are concrete, reviewable artefacts that help the project move from discussion to decision. Depending on the scope, Promacon can support:

• basis of design and design criteria
• process description and operating philosophy
• mass and energy balance
• PFDs and P&ID input
• equipment list and process datasheets
• utility summary and battery limits
• control philosophy and safety basis input
• assumptions register, open item list and document index

When you need this

This support is useful when the project needs more structure than internal teams can provide alone, but does not need a large consultancy layer. Common triggers include:

• A technology is ready to move from development into FEED or industrial design.
• A licensor needs a consistent package for clients, EPC partners or investors.
• Existing documents are fragmented and need a controlled PDP structure.
• The project needs a better basis for cost estimates, vendor discussions or safety review.

How Promacon approaches it

Promacon starts by defining the purpose of the PDP. A package for investor confidence, licensor handover or contractor pricing may need different emphasis, but all require consistency.

The work then connects process information into a structured document set. Design basis, descriptions, balances, drawings, equipment data and assumptions must tell the same story.

A strong PDP does not hide uncertainty. It identifies open items clearly so the next engineering phase can resolve them without rediscovering basic questions.

Why PDP quality matters before FEED

A weak process design package pushes uncertainty into the next project phase. FEED contractors then have to interpret missing assumptions, reconcile inconsistent documents and make decisions that should have been owned by the technology or process team. That creates cost, delay and technical risk.

Promacon builds PDPs to reduce that uncertainty. The package should be complete enough for the next engineering party to understand the process basis, but honest enough to show which items still need confirmation.

What a strong PDP leaves clear

A strong PDP makes the process intent, operating cases, boundaries, utility needs, equipment duties, control expectations, safety inputs and open items visible. It also gives the project a document structure that can be reviewed and updated without losing control.

For technology developers and licensors, this is often the first point where process knowledge becomes a transferable engineering package. That makes consistency and traceability more important than presentation polish.

Turning process knowledge into a transferable package

Many technology teams hold important process knowledge in people, spreadsheets, test reports and informal assumptions. A PDP turns that knowledge into a form that other parties can review and use. That transfer is a critical step before a project is priced, licensed, engineered or built.

Promacon helps identify what must be written down, what can remain as an open item and what needs more evidence. The result is a package that supports decisions without pretending to be more mature than it is.

PDP discipline for scale-up and licensing

For licensors and scale-ups, PDP discipline also supports repeatability. A clear document index, consistent terminology, controlled assumptions and traceable equipment data make it easier to update the package as new information becomes available.

How a PDP reduces procurement and execution risk

A process design package gives suppliers and execution teams a stable technical basis. Without it, quotations may be based on different assumptions, equipment may be sized against incomplete cases and later design changes can become commercial disputes. A good PDP makes the intended process, boundaries and responsibilities clear before the project moves too far.

Promacon treats PDP development as a structured engineering conversation. Each deliverable should support a decision: what must be purchased, what must be designed in detail, what must be tested, and what risks remain open before execution.

Frequently asked questions