Risk management in contracts for the construction of special-purpose machinery: when a fixed price protects the budget and when it increases the cost of an error

In contracts for building special-purpose machines, the debate between a fixed price and an iterative approach usually frames the issue in the wrong way. Project success is rarely determined by the contract model alone. What matters far more is the point at which the parties consider the technical assumptions mature enough to fix the price, schedule, and allocation of responsibility. If that happens too early, the risk does not disappear. It shifts into the design, commissioning, acceptance, and final documentation phases.

In practice, a special-purpose machine is not a repeat product but a response to a specific process, part, shop-floor constraints, operator working methods, and maintenance conditions. That is why risk management in such a project starts not with choosing a contract label, but with identifying which decisions can still be safely adjusted and which, after purchasing and prefabrication, turn into costly rework. Only in that context can you sensibly assess when a fixed-price contract works and when controlled iteration is needed in special-purpose machine projects.

The problem is not the contract, but when the assumptions are frozen

In special-purpose machine build projects, the main source of risk is usually not the commercial model itself, but fixing the price, schedule, and responsibility too early while the technical assumptions are still immature. If the parties do not yet share an operational understanding of how the machine is supposed to function, the contract does not bring order to the project; it merely postpones the conflict.

In practice, a general description of the process objective is not enough. Before the scope is closed, the parties need to agree on how the machine is to operate in the real environment: what functions it must perform, what output it must achieve, which product variants it must handle, where the interfaces with surrounding systems lie, how changeovers should work, and how manual operation, service access, and recovery after a stop are to be handled. Equally important are the limits of automation, the division of supply, safety requirements, maintenance assumptions, and the completeness of the acceptance documentation. Without these arrangements, a fixed price does not remove uncertainty; it turns it into a dispute over whether a given correction is merely a clarification of requirements or an actual change in scope.

That is what separates a well-structured project from one that is only superficially predictable. In the latter, the parties try to close the project commercially before the engineering decisions have been made, even though those decisions will return later anyway. Most often, this happens in areas initially treated as “execution details”: the operating sequence, setup and manual modes, interlocks, dependencies on higher-level systems, changeover conditions, or the way the operator intervenes. Only later does it become clear that these very issues determine the control architecture, protective measures, cycle time, and acceptance criteria.

That is why an iterative approach should not be understood as permission to work without discipline. In a well-managed project, it means exposing uncertainty in a controlled way while removing it is still inexpensive and organizationally reversible. If the process logic, operating scenarios, operating modes, line dependencies, and the machine’s behavior after a stop are verified first, many incorrect assumptions can be corrected before the mechanics, control cabinets, and acceptance documentation are produced.

• Before a lump-sum quotation is issued, at a minimum the following should be defined: the machine’s function, required output, product variability, interfaces with the surrounding environment, operating environment, safety requirements, maintenance assumptions, and the scope of acceptance documentation.

In many projects, it is therefore more sensible to first purchase the concept, risk analysis, and design phase, and only move to fixed-price execution once the assumptions have been confirmed as mature. This is not excessive formalism, but a way to reduce the cost of decisions made too early.

This also matters for a clear allocation of responsibility. Ordering the achievement of a specific process result is one thing; ordering a machine as a product that requires conformity assessment and CE marking is another. In practice, these frameworks often overlap, but they must not be treated as the same. If the subject of the project is a machine or an assembly of machines, it must be agreed from the outset who is responsible for safety requirements, risk analysis, the completeness of the technical documentation, and the conditions for handover for use.

Where cost and risk really increase

Cost and risk increase when decisions are locked in at too low a level of assumption maturity and later cannot be reversed cheaply. At the concept stage, a correction usually means changing the operating logic, interfaces, or safety assumptions. Once the design is frozen, the same correction becomes a change to purchased components, mechanical rework, rebuilding control cabinets, software changes, repeat testing, and delayed acceptance.

After prefabrication, after the control logic has been written, and especially after FAT trials, the cost of change is no longer just a technical cost. It already includes schedule impact, commissioning logistics, revalidation, and the allocation of responsibility between the parties. For that reason, a project should be assessed not only in terms of the final price, but also in terms of the cost of change at each stage. Early on, engineering effort is the main cost. Later, material and fabrication costs are added. At the end, the most expensive element is disruption to acceptance, commissioning, and plant operation.

This shift has a simple design consequence. If the functional architecture, main interfaces, operating conditions, required performance, and the method for measuring cycle quality are not frozen early enough, the contract stops structuring the project. It merely shifts the consequences of late knowledge from one party to the other. In a fixed-price model, the contractor defends the boundaries of the agreed scope, because every ambiguity in the input data creates a real cost. The customer, in turn, tries to preserve the expected process outcome, even though knowledge of the part, utilities, line environment, and actual operating conditions only matures as the work progresses.

Most often, this is not about one obvious defect. The problem builds through a series of small gaps in definition: who provides signals from adjacent equipment, who is responsible for utilities and their parameters, who plans access zones for the operator and maintenance, how performance is measured, on what batch of parts operation is verified, and by what criterion cycle quality is assessed. Each of these issues may seem harmless on its own. Taken together, they can change responsibility, schedule, and acceptance conditions.

Safety risk rises particularly quickly when the production function is defined in detail late in the project. In that case, protective measures do not follow from the concept; they are fitted to a finished or nearly finished design. Typical tensions appear: guards interfere with changeovers, interlocks make jam clearing more difficult, stop logic is constrained by the existing drive system, and setup modes and access to hazardous zones are handled ad hoc. Such a project may still reach commissioning, but the cost of removing non-conformities and usability limitations is then incomparably higher than at the concept stage and during hazard identification according to ISO 12100.

If the order concerns a machine or an assembly of machines, late changes affect not only execution, but also conformity assessment, the completeness of the technical documentation, the instructions, and the conditions for handover for use. That is why arrangements for FAT, SAT, and acceptance criteria should combine functional requirements with safety requirements from the outset. Separating these two areas usually means the problem returns at acceptance.

An iterative approach can reveal incorrect assumptions earlier, but it does not by itself resolve cost and responsibility. If the project has no hard decision points, no agreed input data, and no measurable acceptance criteria for successive stages, it slips into a state of continuous refinement. The customer then pays for prolonged uncertainty, while the contractor loses the ability to demonstrate when the requirements were met.

How to choose the model and record decisions

The choice between a fixed price and an iterative approach should not be driven by belief, but by an assessment of how mature the assumptions are. In special-purpose machine projects, the safest option is often a hybrid model: a short concept phase, paid for separately, to close out risks, followed only then by a fixed-price execution contract for a scope that has genuinely reached the required level of maturity.

This arrangement does not weaken budget control. It simply moves the point at which the price is frozen to a stage where it is already clear what is to be built, what the process constraints are, and where the boundary of responsibility lies. If the process requirements are stable, the interfaces are known, and the acceptance criteria can be described in measurable terms, a fixed price brings order to the project and makes settlement easier. If, however, the uncertainty concerns function, ergonomics, safety, integration with the line, or process behaviour on the user side, controlled iteration is needed before procurement and execution begin.

The key is to distinguish between reversible and irreversible decisions. Iteration is managed differently for operator screens, work sequences, reports, additional equipment, or service organization than it is for the safety architecture, overall dimensions, access zones, service assumptions, drop-off points, and interfaces with adjacent equipment. This distinction should already be recorded in the user requirements specification and the project risk register. It determines which assumptions must be formally approved before components are ordered, and which can be left for functional trials.

From the customer’s perspective, this means the decision-making process itself must be structured, not just the delivery. There needs to be an owner of the requirements on the investor side, an agreed rhythm of design reviews, a transparent risk register, and formal approval of assumptions before moving into procurement, prefabrication, and commissioning. Without this, even a good contract will not be enough, because the parties will still understand differently what has already been agreed.

Most disputes arise from imprecise contract wording. The execution contract should clearly define the scope of supply, the input data provided by the customer, the change procedure, acceptance points, the conditions for partial and final acceptance, and the completeness of the documentation to be handed over after the work is completed. Before it is signed, at least the following should be ready: the process description, material flow, performance requirements, environmental conditions, interface description, maintenance expectations, safety assumptions, and acceptance criteria.

If any of these elements has not yet been defined, it should be explicitly assigned to the concept phase, with a separate charging method and a decision gate after which a fixed-price quotation is prepared. It is equally important to define the boundary between commissioning and later process optimization. Without that distinction, the contractor starts to bear responsibility for an outcome that cannot be objectively closed out at acceptance.

• low uncertainty in the assumptions, known interfaces, measurable acceptance: fixed-price contract;
• high uncertainty in functions, safety, or integration: concept and iteration phase before pricing the execution work;
• partially mature scope: a staged model in which closed items move into fixed-price execution, while open items remain under a controlled change procedure.

Finally, the structure of compliance and responsibility comes back into focus. Technical decisions must be linked from the outset to the later hidden costs of compliance and CE certification, rather than treated solely as design issues. If safety assumptions, supply boundaries, and the division of responsibility for technical documentation are not settled at the concept stage, the problem will return during risk analysis according to ISO 12100, acceptance, and preparation of the final documents. This is not about adding paperwork, but about keeping the project under control.

Example from practice and the structure of responsibility

The simplest practical conclusion is this: in a special-purpose machine project, responsibility for execution should not be finally divided until responsibility for technical decisions has been identified. When the customer defines only a performance target or the general process outcome, but the operating modes, changeover logic, required operator intervention, and constraints of the existing system have not yet been established, a fixed price effectively covers a description of expectations rather than a mature execution scope.

The typical course of events is well known. A plant orders a custom workstation to handle several product variants and assumes a specified hourly output. At the outset, the process description seems sufficient: part feeding, the working operation, discharge, and status indication. As the project progresses, however, it becomes clear that some batches require manual positioning, changeovers must be carried out several times per shift, the operator periodically reaches into the working area, and the existing line imposes constraints on space, feed height, and stop logic.

In the variant where the price is fixed too early, the contractor delivers literally what was written into the scope. Every need identified later comes back as a change: additional guards, a different motion sequence, new interlocks, control adjustments, and added interfaces with the line. The project loses momentum, and acceptance stops being a verification of operation and turns into a dispute over the interpretation of requirements. The risk analysis and documentation then try to justify an architecture that was not designed for the actual method of use.

In the staged variant, the start looks different. First, the workstation function, supply boundaries, interfaces with the surrounding environment, the main operating scenarios, and the basic safety assumptions are defined, including responsibility for integration with the existing line. Only after that stage are the execution scope, schedule, and acceptance criteria established. This does not eliminate changes entirely, but it clearly reduces the number of disputed areas, because it is already clear which decisions are refinements and which create a new scope.

This example clearly shows that safety should not be retrofitted to solutions that have already been ordered or built. It must be developed together with the machine function, operating scenarios, changeover, cleaning, and service. Otherwise, even a formally correct division of roles will not fix the wrong sequence of decisions.

Only at this stage does the formal framework applicable in Poland and the European Union meaningfully come into play. In a special-purpose machine project, it must be clear from the outset who acts as the manufacturer within the meaning of the regulations, who is responsible for the completeness of the technical documentation, who carries out the conformity assessment and certification path, and who affixes the CE marking, if required. It must also be determined whether the subject of the project is a new machine, a machine assembly, or a substantial modification of an existing system, because this affects not only the set of documents, but also the very structure of responsibility between the integrator, partial suppliers, and the end user.

That is why questions about the division of responsibility between the process part and the machine part, the point of conditional acceptance when documentation, instructions, or the risk analysis are incomplete, and the way modernization is to be managed should not arise only at acceptance. If they come back that late, it usually means the contract was closed before the project was.

The practical conclusion is fairly straightforward. In special-purpose machine design, you do not have to choose between complete rigidity and complete openness. You need to identify which parts of the project are mature enough to be fixed under a lump-sum arrangement, and which still require controlled iteration. A well-managed project does not eliminate changes entirely. It only limits the changes that arise too late, cost the most, and blur responsibility for the machine’s safety, function, and conformity assessment and certification path.