How to Write a Good URS for Packaging Machinery Projects

Why a Good URS Matters

After almost 50 years manufacturing bottle unscramblers, we have reviewed hundreds of User Requirement Specifications (URS) from companies all over the world.

Every URS has been written with the same objective: to reduce project risk and make sure the supplier clearly understands the customer's expectations.

Unfortunately, the opposite sometimes happens.

Instead of simplifying the project, the URS becomes so detailed that both the customer and the OEM spend weeks reviewing comments, discussing exceptions and evaluating engineering changes.

Nobody benefits from this.

The customer spends more engineering hours reviewing the supplier's comments. The OEM spends more time evaluating deviations from its standard design.

The project becomes more expensive, deliveries become longer and, in many cases, the final machine is not significantly better.

A good URS should not describe how to build a machine.

It should describe what success looks like.

The Customer and the OEM Have Different Expertise

One lesson I have learned over the years is that the best projects happen when each party focuses on what it knows best.

The customer is the expert in its products, manufacturing process and operational requirements.

The OEM is the expert in designing reliable packaging machinery.

A URS should allow both sides to contribute their expertise.

Instead of prescribing engineering solutions, it should clearly define production objectives, quality expectations, regulatory requirements and any project-specific constraints.

The OEM can then propose the most appropriate technical solution using proven technology and previous experience.

Why Over-Specifying a URS Becomes Expensive

Long URSs are not only a problem because of their length. The problem is the amount of engineering work they generate for all parties involved.

Every non-standard requirement has to be reviewed, commented on and, in many cases, quoted separately.

The customer's engineering team then reviews those comments, discusses alternatives and decides whether each deviation is justified.

At the same time, non-standard requirements often generate custom engineering, additional programming, special components, new documentation and longer validation activities.

The result is usually more work for everyone, higher project costs and longer delivery times.

Define Priorities, Not Engineering Solutions

Instead of...

Specify a servo motor brand

Try...

Define the required positioning accuracy and global spare parts availability.

Instead of...

Specify the PLC model

Try...

Define the required communication protocol or brand your software engineers are familiar with.

Instead of...

Copy dozens of pages of safety regulations

Try...

Require compliance with the latest applicable Machinery and Safety Directives.

This approach gives the OEM enough flexibility to use proven standard solutions while still meeting the customer's objectives.

Check the Machine, Don't Describe It

One positive change in recent years is how easy it has become to share information remotely and live.

Instead of exchanging dozens of emails discussing theoretical machine designs, buyers and OEMs can organise a short online meeting in front of a similar machine already running at the manufacturer's factory.

In just 30 minutes, it is often possible to review accessibility, maintenance, changeovers, ergonomics and operating philosophy, allowing the customer to quickly decide which standard features already meet expectations and which ones genuinely require adaptation.

In my experience, those 30 minutes in front of a real machine often clarify more than twenty pages of written specifications.

Include the Information Only the Customer Knows

Some information can only come from the customer, and it is essential for a successful project.

This includes:

• Bottle drawings and product specifications.
• Production outputs and future capacity requirements.
• Plant layouts and available installation space as well as entrance of equipment.
• Level of technical skills of operators.
• Utility connections and access restrictions.
• FAT, commissioning and SAT expectations.

For bottle handling equipment, accurate bottle drawings are particularly important. Small differences in bottle geometry can significantly influence machine performance.

Separate Technical and Commercial Topics

Technical requirements and commercial conditions should not be mixed in the same document.

Payment terms, bank guarantees, insurance requirements and contractual penalties are important, but they belong in commercial negotiations rather than in a technical specification.

Keeping these discussions separate allows engineering teams to concentrate on designing the right solution while commercial teams manage contractual aspects independently.

Reuse What Already Works

One of the most effective approaches is to create a standard URS that is reused across projects.

A common core can include corporate standards, validation requirements, documentation rules and preferred communication protocols.

A second section should contain only the information specific to that project: bottle specifications, production outputs, layouts, schedules and acceptance criteria.

This saves time for both the customer and the OEM, while allowing improvements from previous projects to be carried forward instead of starting from a blank page every time.

Conclusion

After reviewing hundreds of URSs during my career, I have reached a simple conclusion.

The best projects rarely start with the longest specifications.

They start with the clearest ones. And what is not clear, should be discussed, if possible, in conversations in front of the machinery.