Complete guide to Consulting Engineering: concepts, services, design, Owner’s Engineering, procurement, management, risks, cost engineering, HTE, LPU, contracting, commissioning, documentation, and technical acceptance.
Check it out!
Executive summary
Consulting engineering is specialized technical practice that transforms needs, risks, and complex decisions into verifiable scopes, designs, documents, costs, criteria, and responsibilities. It is not limited to issuing a technical opinion. Its role is to structure decisions based on surveys, method, documentation, professional accountability, and traceability.
In companies, industries, institutions, and public agencies, consulting engineering is relevant because many infrastructure decisions involve financial, operational, legal, and safety impacts. A poorly defined scope can generate incomparable proposals. An incomplete design can generate rework. A weak specification can allow incompatible solutions. Technical acceptance without criteria can close a contract without proving that the contracted object was actually delivered.
In practice, consulting engineering operates before, during, and after the contracting of a project, system, or technical service. It may involve diagnostics, site surveys, due diligence, feasibility studies, basic design, detailed design, technical specifications, cost engineering, technical opinions, contracting support, technical supervision, commissioning, technical acceptance, and as-built documentation.
This guide presents the main concepts, services, deliverables, contracting models, and evaluation criteria associated with consulting engineering, with applications in Electrical and Energy Engineering, infrastructure, automation, telecommunications, networks, electronic security, lightning protection systems, mission-critical systems, and corporate, industrial, and institutional environments. The focus is to show how the discipline connects requirements, decisions, designs, contracting, implementation, verification, documentation, and acceptance throughout the project life cycle.
What is consulting engineering?
Consulting engineering is the provision of specialized engineering services focused on analysis, planning, design, guidance, verification, and decision-making support. It can be applied to projects, construction works, systems, facilities, processes, technology infrastructure, and critical environments.
Its main role is to reduce technical uncertainty before it becomes cost, delay, operational failure, contractual dispute, or nonconformity. Consulting engineering therefore tends to operate when the client needs to define what to contract, how to contract it, which technical solution to adopt, which risks to consider, which deliverables to require, and how delivery will be validated.
The Architecture and Consulting Engineering sector brings together companies dedicated to studies, design, consulting, and construction management, adding value from project conception through operation and maintenance. This definition reinforces a central point: consulting engineering is not merely occasional support. It participates in the technical value chain of a project.
Consulting engineering is more than a technical opinion
A technical opinion may be useful in preliminary discussions, but it does not replace formal consulting engineering. The difference lies in how the work is structured.
In a mature consulting engagement, conclusions need to be tied to assumptions, data, alternative analysis, constraints, documents, criteria, and responsibilities. When applicable, they must also be associated with the Anotação de Responsabilidade Técnica (ART), the professional’s technical record, and the requirements of Brazil’s Confea/Crea System.
For this reason, a consulting engineering service may produce reports, design narratives, specifications, drawings, diagrams, spreadsheets, matrices, technical opinions, technical reports, meeting minutes, inspection records, bills of materials, acceptance criteria, and closeout documents.
Consulting engineering as decision governance
Consulting engineering functions as a layer of technical governance. It organizes information, qualifies risks, defines criteria, and helps the client make decisions with less subjectivity.
This governance is necessary because technical projects rarely depend on a single variable. An infrastructure decision may involve standards requirements, budget, schedule, operations, maintenance, safety, continuity, integration across disciplines, supplier availability, and professional accountability.
In this context, consulting engineering does not replace the client’s decision. It improves the quality of that decision, makes consequences explicit, records assumptions, and provides a technical basis for comparing alternatives.
Technical decisions without assumptions, criteria, and traceability increase contracting risk.
When an organization receives demands from different areas, supplier proposals, and needs that are still poorly structured, a permanent consulting layer helps transform dispersed requests into scopes, priorities, analyses, and documented decisions.
Consulting engineering, technical consulting, and Owner’s Engineering
The terms consulting engineering, technical consulting, and Owner’s Engineering often appear together, but they do not mean exactly the same thing. The distinction matters because it changes scope, responsibility, level of involvement, and expected deliverables.
Consulting engineering vs. technical consulting
Technical consulting may be occasional and limited to a specific question. It may involve an analysis, a meeting, guidance, or preliminary validation of a particular solution.
Consulting engineering has a broader and more formal scope. It tends to involve method, surveys, documentation, assumption control, risk assessment, production of deliverables, and structured decision support. When associated with regulated engineering activities, it may also require formal professional accountability.
The difference is not merely the commercial name of the service. It lies in the level of formalization, traceability, and the impact of the work on design, contracting, implementation, and acceptance decisions.
Consulting engineering vs. Owner’s Engineering
Owner’s Engineering is a specific form of consulting engineering. Its purpose is to technically represent the owner or client in projects, contracts, integrations, and higher-criticality undertakings.
In practical terms, every Owner’s Engineering engagement can be understood as a form of consulting engineering, but not every consulting engineering engagement is Owner’s Engineering.
Consulting engineering may be occasional, discipline-specific, demand-based, project-based, opinion-based, or phase-based. Owner’s Engineering normally involves closer involvement with the project, focused on protecting the client’s technical interests during specification, contracting, execution, commissioning, and acceptance.
When a project requires independent technical representation, the relationship with the owner must be clearly defined.
Owner’s Engineering extends consulting practice into a continuous governance model on the client’s side, connecting requirements, designs, procurement, execution, changes, testing, documentation, and acceptance criteria without transferring the responsibilities that properly belong to designers, suppliers, or contractors.
Consulting engineering vs. execution
Consulting engineering should not be confused with execution. Execution physically implements a solution: installing cables, assembling equipment, building infrastructure, configuring systems, supplying materials, and performing field services.
Consulting engineering defines, analyzes, designs, recommends, supervises, verifies, or documents. In some engagements, the same company may perform different roles in different phases, but the conceptual separation is essential for controlling conflicts of interest, responsibilities, and acceptance criteria.
| Modality | Main function |
| Consulting engineering | Analyze, design, specify, guide, verify, and support decisions |
| Execution | Physically implement the contracted scope |
| Technical supervision | Verify that execution complies with the design, contract, and technical criteria |
| Owner’s Engineering | Technically represent the client in critical decisions and interfaces |
| Commissioning | Test, validate, and document the performance of implemented systems |
Where consulting engineering operates
Consulting engineering can operate at virtually every stage of a technical project. Its value increases when there is uncertainty, multiple disciplines, operational risk, high investment, public procurement, a critical environment, or a need for formal documentation.
Preliminary studies and diagnostics
The first contribution of consulting engineering is often to structure the problem. Before contracting a construction project or system, it is necessary to understand what exists, what must be solved, which constraints apply, and what information is missing.
This stage may include interviews, document analysis, field surveys, visual inspections, drawing reviews, identification of existing infrastructure, interference checks, preliminary risk assessments, and organization of the client’s needs.
The product of this stage may be a diagnostic report, needs matrix, photographic record, punch list, alternatives analysis, or technical development plan.
Site survey
A site survey is the technical assessment performed in the field. In technology infrastructure, electronic security, telecommunications, electrical, or automation projects, it may include inspection of technical rooms, routes, shafts, racks, cable trays, power points, grounding, coverage areas, mounting conditions, interfaces with existing systems, and operational constraints.
A well-executed site survey reduces vague estimates, avoids weak assumptions, and allows the design to be developed with greater adherence to the physical reality of the environment.
Technical due diligence
Technical due diligence evaluates an existing condition, a proposed solution, received documentation, an asset, an operating unit, or a set of systems. Its purpose is to identify risks, gaps, nonconformities, limitations, and issues that require a client decision.
In corporate and industrial environments, due diligence may be used before an acquisition, before contracting implementation, before a technology migration, or during review of an existing installed system.
Basic design
Basic design is an essential stage for characterizing the contracted object, defining scope, guiding contracting, and reducing the risk of change orders. It should consolidate the technical solution, requirements, preliminary quantities, performance criteria, assumptions, constraints, budget estimate, and sufficient elements to support contracting.
In public procurement, basic design plays an even more sensitive role because it influences tender documents, terms of reference, budget, evaluation, and supervision. In private contracting, it performs a similar function: it prevents suppliers from proposing incomparable solutions and allows the organization to evaluate cost, risk, and technical compliance more objectively.
Detailed design
Detailed design develops the solution for implementation. It should translate basic-design decisions into executable technical documentation with greater precision, coordination, and control.
A detailed design may include design narratives, drawings, diagrams, technical specifications, bills of materials, quantities, routes, installation details, installation criteria, infrastructure assumptions, certification requirements, point matrices, system architecture, and integration documentation.
In technology infrastructure, detailed design is decisive for avoiding field improvisation. It guides execution, supervision, purchasing, contracting, commissioning, and final documentation.
Contracting support
Consulting engineering can also support the client in preparing or reviewing contracting documents. This includes terms of reference, technical scope, responsibility matrix, qualification criteria, budget spreadsheet, evaluation criteria, team requirements, measurement criteria, and acceptance criteria.
This support is especially important when the client needs to compare technical proposals. Proposals with different prices may represent completely different scopes, assumptions, technologies, risks, and levels of documentation.
Technical supervision and monitoring
During execution, consulting engineering may monitor the alignment between what was contracted and what is being delivered. This may involve document analysis, inspections, material validation, issue tracking, verification of compliance with the design, field records, and support for decisions regarding changes.
Consulting supervision should not be confused with administrative contract management. Its focus is technical: verifying compatibility, quality, compliance, and risk.
Commissioning, technical acceptance, and as-built documentation
Commissioning validates whether systems, facilities, or equipment were delivered according to defined criteria. Technical acceptance records completion of deliverables, tests, outstanding issues, and receiving conditions. As-built documentation records what was actually implemented.
Without acceptance criteria, delivery is subject to interpretation. Without as-built documentation, the client loses traceability for maintenance, expansion, audits, warranties, and future contracts.
How A3A structures Consulting Engineering
Consulting work can begin at any point in the project life cycle, but it must clearly identify the current stage, the quality of available information, pending decisions, and responsibilities already assigned. Based on this assessment, the scope is structured to produce the documents, verifications, and evidence required for the client’s next decision.
At A3A Engenharia, the work logic seeks to maintain continuity between the identified problem, technical definition, contracting, implementation, and acceptance. This prevents requirements defined at the beginning from disappearing during purchasing or execution and allows acceptance criteria to be linked to evidence produced throughout the project.
| Area of work | Technical objective | Related route |
|---|---|---|
| Diagnostics and structuring | understand existing conditions, constraints, risks, priorities, and missing information | Continuous Consulting Engineering Services |
| Engineering Design | transform requirements and assumptions into documented, contractible solutions | Basic Design and Detailed Design |
| Owner’s Engineering | technically represent the owner and control requirements, interfaces, risks, and decisions | Owner’s Engineering |
| Technical Procurement | structure acquisitions, equalize proposals, analyze suppliers, and control submittals | Technical Procurement |
| Commissioning | verify, test, and document operation, integration, and performance against requirements | Systems and Infrastructure Commissioning |
| As-Built and final documentation | consolidate the as-installed condition and the documentation required for operations | Engineering As-Built |
| Technical acceptance | consolidate execution, testing, outstanding items, and documentation to support the acceptance decision | Technical Acceptance |
This structure does not mean that all services must be contracted together. The scope may be occasional, phase-based, or continuous. The central point is to preserve interfaces: diagnostics must feed design; design must feed contracting; contracting must preserve requirements; execution must generate evidence; and closeout must demonstrate what was actually delivered.
Technically mature contracting begins before price comparison.
Requirements, performance criteria, interfaces, documentation, responsibilities, and acceptance conditions must be clear enough for different proposals to be genuinely equalized. Technical procurement connects developed engineering to the selection of suppliers and solutions.
Main consulting engineering services
Consulting engineering can take different forms depending on the problem, the project phase, and the maturity of the demand. The services below represent the most common modalities.
Technical diagnostics
Technical diagnostics identify the existing situation and its main gaps. They can be applied to infrastructure, systems, facilities, documentation, networks, electronic security, electrical systems, lightning protection, automation, telecommunications, and critical environments.
A diagnostic should not merely list problems. It should classify criticality, indicate consequences, record evidence, identify priorities, and guide next steps.
Feasibility studies
A feasibility study evaluates whether a given solution is technically, economically, operationally, and contractually viable. It may compare alternatives, estimate costs, identify constraints, and support the decision to proceed, revise, or cancel an initiative.
In consulting engineering, feasibility is not limited to initial cost. It should consider maintenance, expansion, compatibility, operations, risks, life cycle, and implementation capability.
Technical designs
Technical designs may cover different disciplines and levels of development. They may be conceptual, basic, detailed, or complementary. In every case, they need to convert requirements and assumptions into verifiable documentation.
In technology infrastructure, this may involve structured cabling, fiber optics, CCTV, access control, networks, telecommunications, lightning protection, electrical systems, automation, data centers, technical rooms, and integrated systems.
Technical specifications
A technical specification defines performance requirements, materials, equipment, services, software, integrations, installations, certifications, compatibility, safety, maintenance, and acceptance.
A good specification avoids improper product steering while also preventing inferior solutions from meeting the scope merely by complying with a generic description. It should balance performance, competition, standardization, service life, and adherence to the client’s environment.
Cost engineering
Cost engineering structures the estimation, composition, control, and economic analysis of projects and technical services. In consulting engineering, it is essential for pricing technical hours, travel, deliverables, risks, seniority, revisions, software, equipment, administration, and professional accountability.
Cost engineering also helps the client compare proposals. The lowest price does not always represent the lowest total cost when scope is incomplete, documentation maturity is low, acceptance criteria are absent, or the risk of change orders is high.
Technical opinions and technical reports
A technical opinion is an analysis and recommendation document. It may assess a solution, proposal, specification, document, nonconformity, technical alternative, or compliance with requirements.
A technical report tends to have a more formal fact-finding character, generally associated with inspection, assessment, or technical verification. The correct designation depends on the objective, the responsibility involved, the contractual context, and applicable legal or standards requirements.
Continuous consulting engineering services
Continuous consulting engineering services provide recurring support to the client. This model is useful for organizations that frequently need to review scopes, analyze proposals, assess documents, guide decisions, structure demands, and deal with technical suppliers.
A continuous service does not replace a specific design, formal supervision, or execution. Its purpose is to maintain a permanent technical support layer, with clear rules for ordinary support, service orders, LPU, HTE, and demands that require complementary contracting.
Deliverables of a consulting engineering service
The quality of a consulting engineering engagement depends largely on the deliverables defined. A scope without clear deliverables makes measurement, acceptance, and accountability more difficult.
Design narrative
The design narrative presents the technical solution, adopted criteria, assumptions, components, implementation conditions, and main project requirements. It is one of the central documents for converting technical understanding into a formal record.
A well-prepared narrative should not be merely a generic description. It needs to explain the logic of the solution, included scope, limits of supply, interfaces, applicable standards, and the criteria that guide implementation and acceptance.
Drawings and diagrams
Drawings and diagrams graphically represent the solution. They may indicate equipment locations, routes, service points, network architecture, interconnections, flows, panels, racks, piping, zones, coverage areas, and interfaces between systems.
In multidisciplinary projects, graphical representation is essential for coordination. It allows conflicts to be identified before construction and reduces improvised field decisions.
Technical specifications
Technical specifications define requirements for equipment, materials, software, and services. They should establish sufficient parameters for purchasing, contracting, implementation, supervision, and acceptance.
In technology systems, specifications may include resolution, performance, protocols, capacity, protection, interoperability, licensing, storage, processing, cybersecurity, integration interfaces, and maintenance requirements.
Bill of Materials (BOM)
The bill of materials, or BOM, consolidates items, quantities, descriptions, and technical references. It should be aligned with the design, narrative, and specifications.
A standalone BOM does not replace design. It is a consequence of technical definition. When a bill of materials is prepared without design, there is a risk of incompatible purchases, incorrect quantities, missing accessories, infrastructure gaps, and change orders.
Cost estimate spreadsheet
The cost estimate spreadsheet organizes costs and quantities. It can be used for budget estimates, commercial proposals, contracting, supplier comparison, measurement, and cost/schedule control.
In consulting services, the spreadsheet should reflect the required technical effort. Engineering hours, reviews, coordination, meetings, surveys, travel, documentation, quality control, and professional accountability must be treated as real cost components.
Risk matrix
The risk matrix identifies events that may affect schedule, cost, quality, safety, continuity, compliance, or operations. It should classify criticality and guide responses.
In consulting engineering, the risk matrix helps transform perceptions into documented decisions. It also supports the allocation of responsibilities among the client, consultant, designer, contractor, supplier, and operator.
ABNT NBR ISO 31000:2018 reinforces that risk management must be integrated into governance and decision-making. Rather than treating risk merely as a static list, the approach involves defining scope, context, and criteria; identifying, analyzing, and evaluating risks; selecting treatments; monitoring changes; and recording decisions. In engineering projects, this logic helps relate uncertainty to the objectives actually affected, such as schedule, cost, performance, safety, operational continuity, and delivery quality.
RACI matrix
The RACI matrix defines roles and responsibilities. It indicates who is responsible for execution, who is accountable for approval, who must be consulted, and who must be informed.
In projects with multiple suppliers, units, departments, or disciplines, the RACI matrix reduces communication failures and avoids gray areas of responsibility.
Technical opinion
A technical opinion formalizes an analysis. It should present the subject, context, documents reviewed, assumptions, criteria, analysis, conclusions, and recommendations.
An opinion may be used to assess proposal compliance, validate a technical alternative, justify a selection, identify a nonconformity, support a contracting decision, or record a technical position in a disagreement.
Acceptance criteria
Acceptance criteria define how the client will verify whether a deliverable has been completed. They may involve documents, tests, evidence, reports, measurements, certifications, inspections, checklists, and records of outstanding items.
Without acceptance criteria, contract closeout depends on subjective interpretation. With criteria defined from the scope stage, measurement becomes more objective.
As-built report
As-built documentation records the condition actually implemented. It should reflect changes made during execution and serve as a reference for operations, maintenance, audits, expansion, and future contracting.
In critical systems, the absence of as-built documentation can compromise maintenance, incident response, operational continuity, and improvement planning.
Consulting engineering and project management
Consulting engineering and project management are complementary disciplines, but they are not interchangeable. Consulting engineering structures requirements, alternatives, solutions, technical criteria, documents, verifications, and professional responsibilities. Project management organizes how the project is conducted so these definitions remain integrated with governance, life cycle, scope, schedule, costs, resources, risks, quality, stakeholders, communication, changes, information, procurement, and delivery.
ABNT NBR ISO 21502:2021 addresses project management broadly: it includes governance, organization and roles, phases and decision points, planning, control, delivery management, risks, issues, changes, quality, information and documentation, procurement, and closeout. This view is compatible with engineering projects in which technical and management decisions must remain coordinated throughout the life cycle.
Within this architecture, Project Controls is a specialized control function and not a synonym for project management as a whole. Its focus is primarily on planning, baseline, schedule, costs, progress, indicators, trends, and performance forecasting. Likewise, Owner’s Engineering has its own function: technically representing the owner’s interests when that independent role is required.
In technical projects, this integration is essential because solution quality depends both on engineering competence and on the ability to coordinate decisions, interfaces, suppliers, changes, and delivery evidence. Conceptual separation between engineering, management, controls, and owner representation improves scope definition and reduces overlapping responsibilities.
Scope, schedule, cost, and quality
A consulting engineering service needs a defined scope. This does not mean eliminating uncertainty, but recording and managing it in a controlled manner.
Scope, schedule, cost, and quality are connected. Reducing schedule may require more resources. Reducing cost may limit the depth of analysis. Expanding scope may require a schedule revision. Mature consulting engineering makes these relationships explicit so the client can make informed decisions.
PMBOK applied to technical projects
PMBOK is one of the international references for project management. Its application in consulting engineering should not be mechanical. Its value lies in adapting good practices to the size, risk, maturity, and criticality of the project.
In technical projects, governance, scope, schedule, finance, stakeholder, resource, and risk domains help structure decisions and deliverables. Management should be proportionate to the challenge: simple enough to avoid bureaucracy, complete enough to control risk.
Governance, stakeholders, and communication
Consulting projects involve multiple stakeholders: executives, engineering, facilities, IT, security, procurement, legal, operations, maintenance, end users, suppliers, and external agencies.
Governance defines how decisions will be made, who approves documents, who participates in meetings, how changes will be recorded, and how outstanding issues will be handled.
Communication should not depend solely on informal messages. Meeting minutes, decision records, document revisions, issue tracking, and approval history are part of technical traceability.
Change management
Changes are common in technical projects. They may arise from new field information, operational constraints, scope changes, incompatibilities, client decisions, or budget revisions.
The problem is not change itself. The problem is changing without records, impact analysis, and approval. Consulting engineering should help control changes and indicate their effects on cost, schedule, performance, and responsibility.
Cost engineering in consulting services
Pricing consulting engineering requires a method. Technical services should not be treated as commodities because the value delivered depends on seniority, responsibility, scope, risk, productivity, documentation, review, and analytical capability.
Why technical services should not be compared on price alone
Comparing consulting engineering proposals solely by final price can lead to poor decisions. Two proposals may have the same title but completely different scopes.
One proposal may include a field survey, meetings, technical review, ART issuance, calculation notes, a risk matrix, specifications, acceptance criteria, and document review. Another may include only a simplified report. If the client compares price alone, it may select the apparently cheaper alternative and later discover that essential documents were excluded from the scope.
Technical hours, seniority, and productivity
A technical hour is not homogeneous. One hour from a senior engineer, an electronic-security specialist, a designer, a project coordinator, or a cost analyst does not represent the same type of contribution.
Cost engineering should consider professional profile, experience, productivity, complexity, responsibility, review needs, and coordination effort.
Direct costs, indirect costs, BDI, and margin
Consulting engineering services may involve direct and indirect costs. Direct costs are directly associated with the service, such as technical hours, travel, per diem expenses, surveys, specific software, measurement equipment, and document issuance. Indirect costs include administration, management, infrastructure, insurance, quality, training, and support.
BDI and margin should be handled with methodological transparency. Their composition depends on the contracting model, tax regime, risk, duration, team, and responsibilities assumed.
AACE and Total Cost Management
AACE International is an international reference in cost engineering, planning, scheduling, project controls, and Total Cost Management. Its Recommended Practices provide technical guidance for cost and control practices and may be generic or industry-specific.
For consulting engineering, this body of knowledge is relevant because it helps address estimates, accuracy classes, contingency, risks, cost control, schedule, and performance systematically.
SINAPI, DNIT, and reference cost databases
Reference databases are useful, but they need to be interpreted correctly. SINAPI, produced by Brazil’s IBGE and Caixa, supports the preparation, analysis, and evaluation of construction budgets, but its monthly series have a specific scope and do not include expenses such as design services in general, licenses, insurance, temporary facilities, administration, financing, and equipment acquisition.
For consulting services, references such as consulting price tables, proprietary compositions, productivity history, technical hours, and estimating methodology may be more appropriate than attempting to apply construction databases without adaptation.
LPU, HTE, and measurement by deliverables
In consulting contracts, three instruments are especially useful:
| Instrument | Application |
| LPU | Unit Price List for recurring or standardized demands |
| HTE | Estimated Technical Hours for variable or on-demand activities |
| Measurement by deliverables | Validation based on completed documents, milestones, reports, designs, or technical opinions |
These instruments make it possible to structure more flexible contracts without losing control of scope, cost, and acceptance.
Contractual flexibility does not eliminate the need for governance.
HTE, LPU, and measurement by deliverables work best when each demand has authorization, scope, a responsible party, an expected product, a measurement record, and an acceptance criterion. Without this structure, flexibility can become consumption without traceability or disagreement over what was actually delivered.
See the framework for contracting Consulting Engineering with governance and traceability →
How to contract consulting engineering
Contracting consulting engineering should begin with a clear definition of the problem. Before requesting a price, the client needs to understand what it wants to obtain: diagnostics, design, a technical opinion, contracting support, supervision, commissioning, continuous services, or a combination of these services.
Fixed-scope contracting
Fixed-scope contracting is appropriate when the object is well defined, deliverables are clear, and uncertainties are controlled. It works well for designs, reports, design narratives, specifications, and technical opinions with defined boundaries.
The risk lies in using a fixed scope when information is insufficient. When the demand is still uncertain, the contract may generate change orders, exclusions, disputes, or deliverables below what is actually required.
Contracting by HTE or man-hours
Contracting by Estimated Technical Hours (HTE) or man-hours is suitable for consulting support, on-demand analyses, technical meetings, document reviews, occasional assessments, and situations with greater uncertainty.
This model requires time tracking, activity descriptions, consumption limits, professional profiles, and authorization criteria. Without control, it can reduce predictability. With governance, it offers flexibility and transparency.
Contracting by LPU
A Unit Price List (LPU) is appropriate for recurring demands. It may include a technical visit, report, technical opinion, document review, meeting, proposal analysis, survey by unit, design by typology, or standardized document package.
LPU reduces the need for negotiation for each demand and allows specific service orders to be created. It is especially useful in continuous consulting engineering contracts.
Contracting by deliverables
Measurement by deliverables links payment, acceptance, or contractual progress to completion of verifiable documents or milestones. It may be applied to design narratives, designs, reports, spreadsheets, specifications, technical opinions, matrices, and as-built documentation.
This model requires well-defined acceptance criteria. The deliverable needs to have its content, format, level of detail, and approval conditions established in advance.
Technical evaluation criteria
Selecting a consulting engineering company should consider more than price. Relevant technical criteria include experience, team, technical record, methodology, multidisciplinary capability, understanding of the problem, proposed deliverables, acceptance criteria, schedule, risk management, and professional accountability.
In critical engagements, the lowest price may be inappropriate when scopes are not equivalent. Technical equalization of proposals is an essential step in comparing alternatives.
Risk and responsibility matrix
The risk matrix defines events, impacts, probabilities, responsible parties, and response measures. The responsibility matrix defines roles among the client, consultant, contractor, suppliers, users, and internal areas.
These instruments reduce contractual ambiguity. They also help prevent survey, design, coordination, purchasing, execution, or operational risks from remaining without a clearly assigned owner.
FIDIC contracts and international good practices
FIDIC contract forms are international references for engineering, construction, and consulting services. They reinforce the importance of balanced risk allocation, document clarity, communication procedures, quality management, compliance verification, and mechanisms for dispute avoidance or resolution.
Even when a FIDIC contract is not adopted, its principles help structure more mature contracts: clear scope, particular conditions, communication criteria, responsibilities, claims, quality, compliance, and risk management.
Professional responsibility, ART, and technical record
Consulting engineering may involve regulated technical activities. In these cases, professional responsibility must be handled appropriately.
When ART is required
The Anotação de Responsabilidade Técnica (ART) is the Brazilian document that legally identifies the professionals responsible for activities covered by the Confea/Crea System. Brazilian legislation made ART mandatory for contracts involving execution of engineering works or provision of engineering services and for technical activities that require professional qualification.
In practice, whenever a consulting service involves an engineering technical activity in Brazil, the applicable ART framework should be assessed. Designs, technical reports, technical opinions, supervision, expert assessments, technical studies, and related activities may require formal registration according to the nature of the scope and the rules of the competent Crea.
Technical record and evidence of capability
ART registration contributes to the professional’s technical record. This record is important for demonstrating professional technical capability in future contracting processes.
For the client, formal professional responsibility provides greater assurance because it links the professional, company, scope, and technical activity.
Professional accountability and traceability
Traceability is one of the main values of consulting engineering. It makes it possible to understand who made a decision, based on which documents, which assumptions were adopted, which alternatives were rejected, which risks were accepted, and which criteria were used for validation.
Without traceability, technical decisions are fragile. With traceability, the client gains a basis for audits, maintenance, expansion, technical defense, and contract management.
How to choose a consulting engineering company
Choosing a consulting engineering company should consider technical capability, method, experience, and responsibility. The engagement should seek competence to reduce risk, not merely the lowest price.
| Criterion | Why it matters |
| Technical record | Demonstrates experience in similar scopes |
| Engineer of record / responsible professional | Establishes professional accountability |
| Methodology | Reduces improvisation and improves traceability |
| Multidisciplinary capability | Controls interfaces between disciplines |
| Documentation | Supports supervision, maintenance, and audits |
| Cost engineering | Improves financial predictability |
| Acceptance criteria | Reduces conflict at delivery |
| Experience in critical environments | Helps anticipate operational risks |
| Technical independence | Improves the quality of client decisions |
| Certifications | Indicate knowledge of technologies, standards, and manufacturers |
Warning signs
Some signs indicate weakness in a consulting engagement:
- proposal without assumptions;
- generic scope;
- absence of defined deliverables;
- budget without supporting basis or criteria;
- lack of acceptance criteria;
- absence of a responsibility matrix;
- absence of risk analysis;
- lack of clarity regarding ART;
- documents without revision control;
- comparison based only on the lowest price;
- mixing design, execution, and supervision without addressing conflicts of interest.
Common mistakes when contracting consulting engineering
Consulting engineering engagements fail when the client treats the service as a simple purchase without considering technical maturity, risk, and responsibility.
Selecting solely by the lowest price
The lowest price may be appropriate for simple, well-defined scopes. In consulting engineering, however, the lowest total price may hide the absence of field surveys, low seniority, reduced deliverables, lack of review, no ART, weak assumptions, or relevant exclusions.
Before comparing prices, it is necessary to equalize scope, team, deliverables, acceptance criteria, and responsibilities.
Failing to define scope and assumptions
Scope and assumptions are the basis of the contract. Without them, each party may interpret the service differently.
Assumptions should record information considered true for preparing the proposal or design. When an assumption changes, its impact should be assessed.
Failing to require acceptance criteria
Acceptance criteria prevent subjective discussions at service closeout. They indicate which documents will be delivered, in what format, with what minimum content, who will review them, and which conditions constitute approval.
Confusing a cost estimate with a design
A cost estimate does not replace a design. A spreadsheet may indicate prices and quantities, but it does not necessarily define the solution, criteria, coordination, routes, responsibilities, specifications, and performance.
Weak designs generate weak cost estimates. Weak cost estimates generate weak contracts.
Failing to separate design, execution, and supervision
When design, execution, and supervision are handled without clarity, conflicts of interest may arise. The contractor may have an incentive to propose solutions that are more convenient to implement rather than necessarily more appropriate for the client.
Separating roles does not prevent integrated delivery models, but it requires well-defined governance, criteria, and responsibilities.
Conclusion
Consulting engineering is a discipline focused on risk reduction, technical structuring, and decision support. It transforms needs into verifiable documents, designs into executable criteria, costs into traceable compositions, and decisions into technical records.
In Electrical and Energy Engineering, infrastructure, automation, telecommunications, networks, electronic security, lightning protection systems, mission-critical systems, and multidisciplinary projects, its importance grows as interfaces, operational criticality, and the need to demonstrate compliance increase. These environments depend on compatibility among disciplines, suppliers, documents, and systems and may suffer significant impacts when decisions are made without requirements, risk analysis, and adequate traceability.
Contracting consulting engineering does not simply mean hiring a report or an expert opinion. It means creating a technical layer capable of guiding scope, contracting, design, execution, supervision, acceptance, and final documentation.
For companies and institutions that need to contract with responsibility, predictability, and traceability, consulting engineering is an instrument of technical governance.
An Engineering demand does not need to arrive fully defined for consulting work to begin.
The starting point may be problem characterization, a document review, a field survey, or analysis of a contracting process under preparation. From there, the scope can evolve into studies, designs, procurement, implementation monitoring, commissioning, documentation, and technical acceptance according to the project’s actual needs.
Technical references
[1] SINAENCO. The Architecture and Consulting Engineering Sector.
[2] Project Management Institute. PMBOK Guide — Eighth Edition.
[3] AACE International. Recommended Practices.
[4] IBGE. National System of Construction Costs and Indices — SINAPI.
[5] CONFEA. Anotação de Responsabilidade Técnica — ART.
[6] FIDIC. About FIDIC.
[7] FIDIC. Conditions of Contract for Construction, 2nd Edition 2017 — Red Book.
[8] ABNT NBR ISO 21502:2021 / ISO 21502:2020. Project, programme and portfolio management — Guidance on project management.
[9] ABNT NBR ISO 31000:2018 / ISO 31000:2018. Risk management — Guidelines.
Frequently asked questions
Consulting engineering is the provision of specialized engineering services for analysis, diagnostics, design, specification, planning, risk assessment, technical opinions, contracting support, supervision, commissioning, acceptance, and decision-making support.
Technical consulting may be occasional guidance. Consulting engineering tends to be more formal, with method, professional responsibility, documentation, deliverables, traceability, and structured decision support.
Owner’s Engineering is a form of consulting engineering focused on technical representation of the owner or client. Every Owner’s Engineering engagement can be understood as consulting engineering, but not every consulting engineering engagement is Owner’s Engineering.
Consulting engineering may support, design, specify, supervise, commission, and validate, but execution is a distinct function. The same company may assume different roles in specific contracts, provided scope, responsibilities, and conflicts of interest are addressed.
Typical deliverables include technical diagnostics, feasibility studies, design narratives, drawings, diagrams, technical specifications, bills of materials, cost estimate spreadsheets, risk matrices, RACI matrices, technical opinions, acceptance criteria, and as-built documentation.
It is recommended when there is a complex technical decision, operational risk, significant investment, undefined scope, multiple disciplines, critical public or private contracting, a need for design, proposal evaluation, supervision, or technical validation.
Under Brazil’s Confea/Crea System, when a service involves a regulated technical engineering activity, the need for ART must be assessed. Designs, technical reports, technical opinions, supervision, and engineering services may require formal registration according to the scope and applicable rules.
Cost may consider technical hours, seniority, field surveys, travel, software, equipment, reviews, coordination, professional responsibility, indirect costs, taxes, margin, risk, and deliverable complexity.
LPU stands for Unit Price List. In consulting contracts, it allows recurring or standardized demands to be priced, such as visits, reports, technical opinions, reviews, surveys, and designs by typology.
Measurement by deliverables is a model in which validation or payment is linked to completion of defined documents, milestones, or technical products, such as a design narrative, design, technical opinion, spreadsheet, report, or as-built documentation.
Basic design characterizes the contracted object and guides contracting. Detailed design develops the solution for implementation with a greater level of specification, coordination, drawings, narratives, quantities, and execution criteria.
Yes. Consulting engineering can support the preparation or review of terms of reference, basic design, budget estimates, risk matrices, technical criteria, proposal analysis, supervision, and acceptance.
Complementary technical materials
Related solutions
- Project, Program, and Portfolio Governance
- Requirements, Evidence, and Acceptance Criteria Management
- Engineering Document Management
- Issues, RFIs, and Nonconformities Management
Related engineering services
- Continuous Consulting Engineering Services
- Owner’s Engineering
- Engineering Basic Design
- Detailed Design
- Technical Procurement
- Systems and Infrastructure Commissioning
- Engineering As-Built
- Technical Acceptance of Engineering Works and Services
Related technical content
- Owner’s Engineering vs. Consulting Engineering: differences, services, and deliverables
- Consulting Engineering vs. Technical Consulting: is there a difference?
- Basic Design vs. Detailed Design: differences in consulting engineering contracting
- PMBOK: fundamentals, principles, and practices for project management
- Risk Matrix in Engineering Projects
- RACI Matrix in Engineering Projects
- Engineering Technical Proposal Evaluation
- Technical Acceptance in Engineering Projects
- What Is Project As-Built Documentation?
- Processes and Governance in Engineering Projects
