Understand how deliverable-based measurement structures consulting engineering services through scope, evidence, acceptance criteria, document traceability, and technical governance.
Check it out!
In consulting engineering, measuring only hours consumed may be insufficient to assess whether a technical demand was actually delivered. Professional time is relevant, but by itself it does not represent the result produced, the responsibility assumed, the documentation generated, or the usefulness of the deliverable to the client’s decision.
For this reason, in consulting engineering contracts, deliverable-based measurement is an important instrument for connecting scope, technical production, evidence, acceptance criteria, and document traceability.
The logic is simple: technical effort must produce a verifiable deliverable. This deliverable may be a report, technical opinion, matrix, checklist, memorandum, design package, measurement bulletin, technical meeting record, action plan, or commissioning documentation.
This concept is connected to the Complete Guide to Consulting Engineering, the whitepaper Consulting Engineering Contracting with Traceability, Governance, and Cost Engineering, and the HTE, LPU, OS-LPU, and OS-CIC methodology adopted by A3A.
What is deliverable-based measurement?
Deliverable-based measurement is the method of verifying and recording the execution of a technical service based on the deliverable produced, rather than only on the time consumed.
Instead of asking only how many hours were used, deliverable-based measurement asks:
- what demand was requested;
- what scope was approved;
- what deliverable was expected;
- what evidence was produced;
- what acceptance criteria were defined;
- what was actually delivered;
- who validated the deliverable;
- what pending items or limitations were recorded.
This model brings measurement closer to the reality of consulting engineering, where technical value lies in analysis, documentation, interpretation, responsibility, and the ability to support decisions.
Why measuring only hours may be insufficient
An hour measures duration. By itself, it does not measure technical complexity, quality of analysis, documentation depth, assumed risk, professional responsibility, or the usefulness of the deliverable to the client.
Two demands may consume the same amount of time and still generate completely different results. One may result in verbal guidance with no record. Another may produce a risk matrix, technical report, documented recommendations, and acceptance criteria.
For this reason, consulting services should not be evaluated only as an hour bank. Hours may be part of the estimate, but measurement needs to be linked to the expected technical result.
The article HTE in Consulting Engineering: Why a Technical Hour Is Not a Man-Hour explores this distinction in greater depth.
Relationship with HTE, LPU, OS-LPU, and OS-CIC
Deliverable-based measurement is directly connected to the operating structure of consulting engineering.
HTE — Consulting Technical Hour represents equivalent consulting technical effort. The LPU — Unit Price List organizes services, reference units, and contracting criteria. OS-LPU formalizes specific demands linked to the LPU. OS-CIC formalizes integrated engineering cycles when a demand involves several interdependent activities.
Within this arrangement, deliverable-based measurement verifies whether the formalized demand generated the expected technical result.
| Element | Function |
| HTE | Represent equivalent consulting technical effort |
| LPU | Organize services, units, and contracting references |
| OS-LPU | Formalize a specific demand linked to the LPU |
| OS-CIC | Formalize an integrated engineering cycle |
| Deliverable | Materialize technical production |
| Measurement | Record what was delivered and validated |
| Technical acceptance | Formalize validation by the client |
The relationship between OS-LPU and OS-CIC is detailed in the article OS-LPU and OS-CIC in Consulting Engineering.
What can be considered a deliverable
A deliverable is any previously defined, documented, and verifiable technical result.
Common deliverables in consulting engineering include:
- technical opinion;
- technical note;
- analysis report;
- risk matrix;
- proposal comparison matrix;
- technical meeting record;
- acceptance checklist;
- due diligence report;
- action plan;
- measurement bulletin;
- technical memorandum;
- detailed design;
- commissioning documentation;
- open-items report;
- evidence record;
- technical contracting recommendation.
A deliverable does not always need to be extensive. It needs to be appropriate to the scope, risk, complexity of the demand, and the decision it is intended to support.
Acceptance criteria
Deliverable-based measurement works well only when acceptance criteria exist.
The acceptance criterion defines how the client verifies whether the deliverable meets the approved scope. Without this criterion, acceptance becomes subjective and may depend on perception, informal expectations, or later interpretation.
Acceptance criteria may include:
- delivery of the specified document;
- adherence to the approved scope;
- inclusion of the minimum topics defined in the Service Order;
- recording assumptions and limitations;
- analysis of reference documents;
- identification of risks and pending items;
- presentation of technical recommendations;
- internal review or validation by the responsible technical professional;
- presentation meeting, when required;
- formal approval by the client.
The article on technical acceptance in engineering projects explores the difference between completing a deliverable and technically validating it.
Documentary evidence
Deliverable-based measurement depends on evidence.
Evidence consists of the records that prove what was requested, produced, reviewed, delivered, and accepted. It may exist in documents, meeting minutes, reports, matrices, checklists, formal emails, measurement bulletins, or system records.
Without evidence, measurement loses strength. The discussion becomes dependent on memory or perception. With evidence, the technical history can be reconstructed.
Document traceability makes it possible to answer:
- who requested the demand;
- what scope was approved;
- which documents were analyzed;
- which assumptions were adopted;
- which risks were identified;
- which deliverable was produced;
- when it was delivered;
- who validated it;
- which pending items remained.
This structure is especially important for private companies, industrial organizations, public bodies, and institutions that need to contract engineering services with documentary accountability.
Measurement in OS-LPU
In an OS-LPU, measurement is usually linked to a specific LPU item.
For example, a document review, a simple comparison matrix, a preliminary proposal analysis, or a specific technical opinion may have clearly defined deliverables.
In these cases, measurement can verify:
- whether the Service Order was opened with clear scope;
- whether the LPU item was applicable;
- whether reference documents were identified;
- whether the expected deliverable was produced;
- whether the acceptance criterion was met;
- whether pending items or limitations were recorded.
OS-LPU works well when the demand is bounded and does not depend on several integrated stages.
Measurement in OS-CIC
In an OS-CIC, measurement needs to consider the integrated cycle.
Technical due diligence, technical procurement, owner’s engineering, commissioning, or support for technical acceptance may involve several connected activities. In these cases, measuring each microactivity separately can cause fragmentation and loss of context.
Measurement can be performed by stages, milestones, or sets of deliverables, such as:
- document-gathering stage;
- preliminary risk matrix;
- intermediate technical report;
- validation meeting;
- final report;
- action plan;
- acceptance checklist;
- consolidated documentation.
This structure preserves cycle coherence and reduces disputes about isolated microactivities.
Practical example: technical procurement
Imagine an organization that needs to contract the implementation of a critical system.
The process involves requirements gathering, solicitation of proposals, technical analysis, supplier leveling, risk matrix, clarification list, technical recommendation, and decision support.
If each activity is treated as an isolated charge, contracting can become fragmented. If everything is treated only as an hour bank, the client may lose clarity over the expected result.
In this case, deliverable-based measurement can organize the process by milestones:
- requirements matrix;
- proposal-analysis report;
- bid-leveling matrix;
- risk matrix;
- technical recommendation;
- decision record.
This logic connects to the Technical Procurement service and to the article on technical proposal analysis in engineering.
Benefits for the client
Deliverable-based measurement improves the technical control of contracting.
Key benefits include:
- greater clarity over scope and expected result;
- fewer disputes over hours with no associated deliverable;
- better communication among engineering, procurement, legal, and operations;
- records of evidence and decisions;
- greater predictability in measurement;
- support for technical acceptance;
- document traceability;
- reduced ambiguity in recurring contracts;
- better organization of ongoing consulting engineering services.
This structure helps ensure that contracting is evaluated by verifiable technical results, not only by time consumed.
Risks of measuring without a deliverable
Measuring consulting services without a deliverable can create significant problems.
Main risks include:
- difficulty proving what was produced;
- divergence between expectations and delivery;
- disputes over hours consumed;
- absence of acceptance criteria;
- weak traceability of technical decisions;
- weak accountability;
- loss of technical history;
- difficulty justifying payments or approvals;
- dependence on informal communications.
For this reason, measurement needs to be associated with scope, Service Order, deliverable, and acceptance.
How A3A applies deliverable-based measurement
A3A applies deliverable-based measurement as part of a technical-governance architecture for consulting engineering.
This architecture connects HTE, LPU, OS-LPU, OS-CIC, measurement bulletins, acceptance criteria, and document traceability. The objective is to structure technical demands clearly for the client, consultant, procurement, legal, operations, and suppliers.
This logic is applied in services such as:
- Ongoing Consulting Engineering Services;
- Technical Procurement;
- Detailed Design;
- Technical Due Diligence;
- Owner’s Engineering;
- EPCM;
- Commissioning.
Recommended complementary content
To explore the methodology further, also see:
- Complete Guide to Consulting Engineering;
- HTE in Consulting Engineering;
- LPU in Consulting Engineering Services;
- OS-LPU and OS-CIC in Consulting Engineering;
- Technical Acceptance in Engineering Projects;
- Risk Matrix in Engineering Projects.
Conclusion
Deliverable-based measurement is an essential instrument for organizing consulting engineering services with clarity, traceability, and technical accountability.
It does not eliminate the importance of technical effort, but it links that effort to verifiable results, acceptance criteria, and documentary evidence.
When applied together with HTE, LPU, OS-LPU, and OS-CIC, deliverable-based measurement makes consulting contracts more predictable, auditable, and defensible.
In engineering, good measurement is not only about counting hours. It is about verifying that the technical deliverable was produced, documented, validated, and accepted according to scope.
Talk to our Engineering Department
If your organization needs to structure deliverable-based measurement, ongoing services, service orders, LPU, or acceptance criteria in consulting engineering contracts, talk to A3A’s Engineering Department.
A3A supports private companies, industrial organizations, public bodies, and institutions in contracting consulting engineering with method, document traceability, and technical governance.
Technical references
[1] A3A Consulting Engineering. Complete Guide to Consulting Engineering. Available at: https://a3aengenharia.com.br/conteudo/guias-tecnicos/guia-completo-sobre-engenharia-consultiva/.
[2] 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/.
[3] AACE International. Recommended Practices for Cost Engineering.
[4] PMI. PMBOK Guide.
Frequently asked questions
It is the verification of technical-service execution based on documented deliverables, acceptance criteria, and evidence rather than only on hours consumed.
Because an hour measures duration, but by itself it does not measure technical quality, responsibility, documentation, risk, usefulness of the deliverable, or adherence to scope.
Technical opinions, reports, matrices, checklists, memoranda, detailed designs, measurement bulletins, commissioning documentation, action plans, and evidence records.
Measurement records the deliverable produced, while technical acceptance validates whether it meets the scope and criteria defined by the client.
HTE represents consulting effort, LPU organizes items, OS-LPU and OS-CIC formalize demands, and deliverable-based measurement verifies the technical result produced and accepted.
