Understand how the LPU — Unit Price List — can organize consulting engineering services with predictability, scope, HTE, service orders, deliverable-based measurement, and document traceability.
Check it out!
In consulting engineering contracts, many demands arise over time. An organization may need to review a proposal, analyze a technical document, support a meeting, issue a technical opinion, structure a risk matrix, validate a scope, or support a contracting decision.
If each request is handled as an isolated negotiation, contracting tends to become slow, subjective, and poorly traceable. On the other hand, if every demand is treated as a simple hour bank, the client loses clarity over scope, deliverables, measurement criteria, and technical responsibility. For a broader view of the topic, also see the Complete Guide to Consulting Engineering.
It is in this context that the LPU — Unit Price List becomes a relevant instrument for ongoing consulting engineering services.
The LPU should not be understood merely as a price table. In technical services, it should function as a contractual organization mechanism capable of linking types of demand, reference units, deliverables, measurement criteria, and scope boundaries.
When properly structured, an LPU allows consulting engineering to be contracted with greater predictability, scope clarity, and traceability.
What is an LPU in consulting engineering services?
The LPU — Unit Price List — is a reference structure that organizes services, technical units, measurement criteria, and unit prices for previously classified demands.
In construction, supply, or installation services, unit price lists usually organize physical items or execution compositions. In consulting engineering, the logic must be adapted: the primary object is not only material or physical production, but analysis, documentation, technical responsibility, decision support, and verifiable consulting deliverables.
Therefore, an LPU applied to consulting engineering should make clear:
- which type of service is being contracted;
- which demand can be classified under that item;
- which deliverable is expected;
- which level of depth is included;
- which measurement criterion will be used;
- which assumptions and exclusions apply;
- when the demand no longer fits a unit item and requires a specific proposal or integrated cycle.
This structure prevents contracting from depending solely on informal interpretations or one-off negotiations for every new need.
Why an LPU is not just a commercial price table
A commercial table presents prices. A technical LPU organizes contracting conditions.
The distinction matters. In consulting engineering, the client does not only need to know how much an item costs. The client needs to understand what is included, how the demand will be formalized, how effort will be measured, which deliverable will be produced, and which criteria will be used to accept the delivery.
Without this clarity, an LPU can produce the opposite of the intended effect: scope disputes, overlapping items, double-counting of effort, subjective deliverables, and measurement difficulties.
The LPU should help answer questions such as:
- is this demand included in ordinary support or should it be measured separately?
- does the LPU item cover only preliminary analysis or also the issuance of a report?
- is review by the responsible technical professional included?
- does the activity include a meeting, record, matrix, technical opinion, or only guidance?
- which document proves delivery?
- what is the acceptance criterion?
That is why the LPU must be connected to the consulting engineering methodology, not only to pricing.
Relationship among LPU, HTE, and cost engineering
The LPU connects directly to the HTE — Consulting Technical Hour and to cost engineering.
HTE helps represent equivalent consulting technical effort. The LPU organizes this effort into items, reference units, and contracting criteria. Cost engineering contributes to structuring the logic of composition, productivity, risk, responsibility, and indirect costs.
Together, these elements avoid two extremes:
1. contracting consulting engineering as simple man-hours; 2. turning every small interaction into an isolated charge unrelated to deliverables.
A properly structured LPU balances commercial predictability with technical control. It does not eliminate the need for case-by-case analysis, but it creates a basis for classifying recurring and special demands.
This logic also applies to services such as detailed design, technical due diligence, and technical procurement when the client needs to organize demands before contracting, executing, or accepting deliverables.
How the LPU improves predictability
Predictability is one of the LPU’s primary functions.
In recurring contracts, new requests commonly arise during the contract term. Without a prior reference, each demand requires a new negotiation, new estimate, new scope discussion, and new commercial alignment.
With an LPU, the client gains a previously agreed basis for recurring or special demands. This reduces response time, facilitates budget planning, improves interaction with procurement and legal teams, and decreases discussions over unit prices.
Predictability, however, should not be confused with rigidity. Not every demand fits a unit item. When a request requires integration of several activities, deeper technical analysis, or expanded responsibility, it should be handled as an integrated cycle or a specific engagement.
A good LPU does not force inappropriate classifications. It helps identify what can be measured by item, what should be handled through a Service Order, and what requires its own proposal.
How the LPU protects scope
Poorly defined scope is one of the greatest sources of conflict in technical services.
An adequate LPU should define the boundary of each item. This means stating what is included, what is excluded, and which conditions must exist for the item to apply.
For example, a “preliminary technical proposal analysis” may include document review, identification of apparent gaps, and recording points of attention. But it may not include a detailed comparative matrix, supplier meetings, in-depth standards analysis, or a conclusive technical opinion.
If this boundary is unclear, the item may be interpreted differently by the client, consulting firm, procurement, and internal departments.
The LPU protects scope because it turns the request into a measurable unit. It helps distinguish ordinary support, special services, OS-LPU, OS-CIC, and specific engagements.
How the LPU strengthens traceability
Traceability makes it possible to reconstruct the technical history of a demand.
In consulting engineering, this is essential. The client needs to know what was requested, which item was activated, which document was analyzed, which assumptions were considered, which deliverable was issued, which limitations were recorded, and how the delivery was accepted.
When the LPU is associated with a Service Order, traceability becomes clearer. The Service Order records the demand; the LPU classifies the item; HTE represents the technical effort; the deliverable documents the result; and the measurement report records what was measured and accepted.
This structure reduces dependence on memory, scattered emails, or informal messages. It also improves auditing, accountability, and technical governance.
OS-LPU: when the demand is specific and measurable
OS-LPU is a Service Order linked to a specific item in the Unit Price List.
It is suitable when the demand is objective, bounded, and individually measurable. It can be used for requests such as:
- preliminary technical review;
- objective document analysis;
- simple comparative matrix;
- specific technical opinion;
- participation in a technical meeting with a record;
- preliminary risk assessment;
- targeted technical contracting support;
- acceptance checklist or verification documentation.
In these cases, OS-LPU helps define the request scope, expected deliverable, schedule, measurement criterion, and acceptance criterion.
OS-LPU should be avoided when the demand appears simple but depends on multiple integrated activities or broader multidisciplinary analysis.
OS-CIC: when an isolated LPU item is not enough
Some demands should not be fragmented into isolated items.
A technical due diligence, support for Owner’s Engineering, a commissioning process, or delivery validation may involve meetings, document analysis, evidence gathering, a risk matrix, reports, review, and presentation of results.
If each microactivity is measured separately, there is a risk of double counting, loss of context, and disputes about what is included in each item.
In these cases, the demand can be structured as an OS-CIC — Service Order linked to an Integrated Engineering Services Cycle. The cycle consolidates stages, internal activities, deliverables, and acceptance criteria into a coherent technical unit.
OS-CIC does not eliminate the LPU. It indicates that, for certain demands, the simple sum of unit items does not adequately represent the technical effort and responsibility involved.
Deliverable-based measurement
An LPU applied to consulting engineering should be associated, whenever possible, with deliverable-based measurement.
Deliverable-based measurement does not ignore technical effort. It recognizes that effort must produce a verifiable result.
Possible deliverables include:
- technical report;
- technical opinion;
- risk matrix;
- comparative proposal matrix;
- technical meeting minutes;
- acceptance checklist;
- action plan;
- measurement report;
- commissioning documentation;
- technical memorandum or contracting-support document.
This model improves interaction among engineering, procurement, legal, and management teams. Instead of discussing only the number of hours, the parties discuss scope, evidence, delivery, and acceptance.
Deliverable-based measurement also strengthens technical acceptance in engineering projects, because it links validation of the demand to objective criteria.
Practical example: supplier contracting support
Imagine an organization needs to contract the implementation of a technical system. It receives proposals with different scopes, different schedules, non-standard assumptions, and incomplete documentation.
Without an LPU or classification methodology, the consulting firm may be engaged informally through successive requests: review one proposal, attend a meeting, answer a question, check one item, review another document, and provide an opinion on the supplier.
With an LPU structure, the demand can be organized more clearly. The first analysis can be classified as a preliminary review item. A comparative matrix can be handled as a specific deliverable. A meeting with records can be formalized through an OS-LPU. If the contracting process requires a complete analysis, risk matrix, technical equalization, and documented recommendation, an OS-CIC can be opened.
This organization reduces improvisation and creates a documentary basis for decision-making.
Risks of a poorly structured LPU
A poorly structured LPU can create problems similar to those it was intended to solve.
The main risks are:
- items that are too generic;
- overlap among items;
- absence of measurement criteria;
- lack of defined deliverables;
- difficulty distinguishing ordinary support from special services;
- charging microactivities without a result-oriented view;
- trying to classify complex cycles as simple items;
- poor document traceability;
- later disputes over scope and acceptance.
That is why the LPU must be integrated into a consulting engineering methodology. It should be clear enough to guide contracting and flexible enough to recognize when a demand requires its own treatment.
How A3A structures LPU in consulting engineering
A3A structures the LPU as part of a technical-governance architecture, connecting recurring support, HTE, OS-LPU, OS-CIC, deliverable-based measurement, and document traceability.
This structure is applied especially in Ongoing Consulting Engineering Services, but it also connects to demands for Detailed Design, Technical Procurement, Owner’s Engineering, EPCM, and Design Coordination.
The objective is to allow the client to understand what is being requested, how the demand will be classified, which deliverable will be produced, and how the delivery will be validated.
This logic also connects to the whitepaper Consulting Engineering Contracting with Traceability, Governance, and Cost Engineering, which presents the technical contracting methodology using HTE, LPU, service orders, integrated cycles, and acceptance criteria.
Recommended complementary content
To explore topics related to contracting, scope, and technical governance in greater depth, see also:
- Complete Guide to Consulting Engineering;
- HTE in Consulting Engineering: Why a Technical Hour Is Not a Man-Hour;
- Engineering Technical Proposal Analysis;
- Risk Matrix in Engineering Projects;
- RACI Matrix in Engineering Projects;
- Basic Design vs Detailed Design;
- Technical Report, Technical Note, and Technical Opinion.
Conclusion
An LPU in consulting engineering services should not be treated as a simple price table.
When properly structured, it organizes demand types, reference units, measurement criteria, deliverables, scope boundaries, and document traceability.
Its function is to provide predictability without eliminating technical analysis. It helps distinguish ordinary support, OS-LPU demands, integrated OS-CIC cycles, and specific engagements.
Together with HTE, service orders, and deliverable-based measurement, the LPU makes consulting-engineering contracting clearer, more measurable, and more defensible.
In critical environments, this matters. Engaging engineering services is not merely buying hours or items. It is structuring technical decisions with predictability, scope clarity, and traceability.
Talk to our Engineering Department
If your organization needs to structure ongoing consulting engineering services, organize demands through an LPU, define measurement criteria, or improve traceability in technical contracting, contact A3A’s Engineering Department.
A3A supports private companies, industrial organizations, public agencies, and institutions in engaging consulting engineering with method, technical governance, cost engineering, and documented accountability.
Technical references
[1] A3A Consulting Engineering. Consulting Engineering Contracting with Traceability, Governance, and Cost Engineering. Available at: https://a3aengenharia.com.br/conteudo/whitepapers/contratacao-engenharia-consultiva-governanca-rastreabilidade/.
[2] SINAENCO. Roteiro de Preços.
[3] AACE International. Cost Estimate Classification System in EPC for Process Industries.
[4] DNIT. Manual de Custos SICRO: Conceitos e Metodologias.
Frequently asked questions
LPU is the Unit Price List applied to the organization of technical services, reference units, deliverables, measurement criteria, and scope boundaries in consulting engineering demands.
No. In consulting engineering, the LPU should organize scope, reference unit, deliverable, measurement criterion, assumptions, and acceptance method. It should not be merely a commercial table.
HTE represents equivalent consulting technical effort. The LPU organizes that effort into items, reference units, and contracting criteria, enabling greater predictability and traceability.
OS-LPU is appropriate when the demand is specific, bounded, and measurable through a specific LPU item, such as document review, comparative matrix, technical opinion, or targeted technical support.
OS-CIC is appropriate when the demand involves several interdependent activities, such as due diligence, technical procurement, Owner’s Engineering, commissioning, or multidisciplinary review, requiring an integrated cycle and consolidated deliverables.
